生产级RAG研究笔记

这个问题我踩过不少坑，说点实际感受。全量塞历史记录基本是条死路，token一长模型注意力就散了，而且中间那些工具调用的原始返回（比如一大坨JSON）特别容易干扰后面的推理。我现在更倾向于把“状态”和“历史”分开处理：用一个结构化的state对象只存关键槽位，比如user_id、查询结果摘要这些，每一步只把state和当前指令拼进prompt，历史对话该丢就丢。向量库那套适合做长期记忆或者跨会话召回

我之前也踩过这个坑，YOLOv5转ONNX后置信度掉，最后发现是预处理和后处理对不上。你检查一下onnx推理时的letterbox、归一化和NMS阈值是不是跟原版完全一致，差一点结果就偏。另外opset版本其实影响不大，重点看导出时有没有把Focus或者SiLU写成不支持的算子。可以先用onnxruntime跟torch对同一张图逐层比对输出，定位到哪一层开始偏。

我这边实测下来，compile之后no_grad还是得加，不然中间激活值照样占显存，eval()只影响dropout和bn的行为，跟梯度记录是两码事。之前偷懒只写了eval()，显存直接涨了一截，后来补上no_grad才降回去。所以保险起见两个都留着吧，反正也没啥副作用，别指望编译器帮你全包了。

光靠System Prompt确实不够稳，试试用tool call强制约束结构，或者开response_format的json mode。

我之前也遇到过类似的情况，塞了五六个MCP之后明显感觉工具调用的决策阶段变慢了。后来排查了一下，主要问题其实不在服务器数量本身，而是每个MCP的tool定义都会注入到system prompt里，工具一多token量直接爆炸，模型每次都要在几十个工具里做选择，推理开销自然上去了。所以服务器质量是一方面，但工具描述的膨胀才是隐形杀手。我现在做法是按项目拆分配置文件，不同场景只挂真正需要的两三个，响应

我本地跑32B也这样，跨文件就爱瞎编，后来干脆只让它改单文件，多文件还是得靠Cursor。

我也遇到过，感觉Cursor默认就爱搞封装，哪怕你只想要三行代码它也给你整出个函数。后来我试过在prompt里直接写“不要新建函数，直接写main里”，确实能压住一部分。不过更根本的办法可能是先自己搭个骨架，让它往里填，而不是让它从零发挥。毕竟AI哪懂你们团队的命名习惯，它只是猜你想看什么名字。

大概率不是提示词的事，是RAG的检索粒度跟代码逻辑没对齐，建议先手动跑通一条完整链路再让AI改。

训练数据里多塞几种指令变体，别让模型觉得客服只会背模板。 角色描述别太泛，直接把你们真实客服的回复风格和话术加进few-shot里效果更稳。

我之前也踩过这个坑，bge召回的top50里其实很多是“相关但不关键”的段落，ChatGLM3对超长输入的位置编码和注意力分配确实不太行，它更擅长抓短query的核心意图。你可以试试把长文本按语义切块后再进rerank，或者用段落摘要替换原文去打分，我这么改后准确率提了挺多。另外，精排阶段换Qwen2.5-7B或者千问的rerank专用模型，对中文长文的感知会比ChatGLM3稳不少。不过你提到拼

数据格式肯定有坑，但更可能是工具描述和真实调用逻辑没对齐，试试把API参数示例直接塞进few-shot里。

说实话，三个工具都崩大概率不是prompt的问题，LangChain那层tool calling的封装本身就容易埋坑。你查一下是不是工具返回的格式不统一，比如有的返回纯文本有的返回JSON，模型解析时就会抽风。我上次就是被一个返回里带换行符的工具搞到怀疑人生。另外可以试试把工具描述写得更像“给API文档加注释”那种风格，别用自然语言讲故事，模型对结构化描述反而更稳。

rerank基本是必上的，不然光调chunk和embedding很难解决混排问题。另外bge-large-zh对长文本不友好，试试切成256加32重叠再配bge-m3。

Tool描述得让AI看懂“similar”就是vector search，加个query解析的prompt把用户意图转成向量再调接口。

几万条向量真不用纠结，Chroma完全够用，我跑过十万级本地检索也没觉得慢。Milvus那套部署配置确实重，单人开发光维护就够喝一壶的。另外可以看看Qdrant，单机模式docker起一下很省事，Python客户端也顺手，召回效果和Chroma差不多。

说实话我刚开始也有这感觉，MCP那层封装看着就像多绕了一道弯。但用久了发现区别在“生态位”而不是“技术实现”——你写的回调只能服务你当前这个项目，换个框架或者换个监控面板又得重来，而MCP相当于给模型训练和外部工具之间定了个通用插头，别人写好的监控工具、可视化组件直接就能接上。不过你的质疑也对，如果只是自己一个人调模型，往InfluxDB推数据确实更干脆，省得维护一套JSON-RPC的协议和状态。

父子chunk确实能救，但你这512切法对跨章节本来就吃亏，建议先试试按章节语义边界切。 我当初也踩过这坑，后来干脆给每个大章节单独建摘要索引，召回准了不少。

这问题太真实了，Cursor对热门API的“记忆”其实挺玄学的，它可能混入了GitHub上不同版本的代码，或者把别的库的写法缝进来了。我自己试过最笨但有效的办法，就是让它先输出完整的函数签名和参数定义，不写实现，你肉眼核对一遍再让它填逻辑，这样它瞎编的“灵感”会被卡在第一步。另外你贴文档这个动作，我怀疑它根本没认真读，而是优先匹配了训练数据里的相似模式，所以我现在都是直接把API响应样例和错误信息

这问题我之前也踩过，大概率不是梯度的问题，推理模式下本来就不会存梯度。核心是每次把历史token拼进去后，KV cache会跟着变长，PyTorch这边如果不手动释放旧的graph或缓存，显存自然就堆上去了。建议试试在每轮生成后用del清掉上一次的output和past_key_values，再配合empty_cache，或者干脆用vLLM这类支持自动管理KV cache的框架，省心很多。

先试下把max-num-seqs调小，vLLM默认并发缓存吃显存挺狠的，小流量能立刻缓解。