生产级RAG研究笔记

老项目依赖盘根错节，Agent一改就牵一发动全身，真不是prompt能救的。

我习惯在prompt里塞个极简状态机，比硬堆数据稳不少。参数名出错可以查下训练数据里工具定义是否对齐，别混用别名。

两个都用过，说下真实感受。Milvus功能全分布式强，但部署运维真挺重，小团队容易劝退，之前升个版本踩了半天坑。Qdrant轻量很多，上手快，不过集群这块成熟度还是差点意思，数据量大了要自己多盯着。如果数据量不大、追求省心，我个人倾向Qdrant，规模上去了再考虑Milvus。

这个思路不错，收藏了。

检查下有没有动态增长的缓存或list在累积，比如日志或metrics没清理。

我最近也在用Cursor的Agent模式搞类似的事，感觉你这个情况不完全是prompt的问题。像“递归扫描目录”和“跳过__init__.py”这种细节，其实属于隐式的边界条件，你prompt里没明说它就默认按最常见的方式处理了，而ast分析本身又牵扯到作用域判断，Agent很容易在“看起来对”和“真的对”之间翻车。我的经验是别指望它一次写对，而是把任务拆成几步：先让它只写遍历文件的部分，你跑通了

你这配置跑7B确实有点勉强，6G显存扣掉系统占用能分给模型的也就4G多，int4量化后7B大概占4.5G左右，塞不下就只能往内存扔，速度自然崩。llama.cpp里把n-gpu-layers调到20-24试试，别贪心全offload，剩下的层交给CPU反而更稳，线程数设成物理核数就行。代码补全和简单问答的话，Qwen2.5-Coder-3B或者4B体验真不差多少，速度能快两三倍，日常用完全够。

7B写长函数确实容易断片，我也遇到过，换成14B后顺畅不少，vLLM采样策略影响不大。

学到了，感谢分享！

空catch和事务边界确实是重灾区，我一般只让它写纯逻辑，涉及DB和并发的地方手动来。

两个都用过，Milvus 功能确实全，但部署那套依赖太重了，etcd、MinIO、Pulsar 一堆组件，小团队维护起来真的累。Qdrant 单二进制就能跑，Rust 写的性能也稳，就是生态和文档比 Milvus 薄一点。如果数据量没到亿级，我个人更倾向 Qdrant，省心。你们场景大概多大规模？

我之前也踩过这个坑，vLLM配LangChain的tool calling确实容易出幺蛾子，后来换成SGLang顺手不少，它原生支持OpenAI接口，Agent那边基本不用改。显存这块最有效的还是把embedding模型单独丢到CPU或者另一张小卡上，bge-small这类模型CPU推理完全够用，没必要跟LLM抢显存。7B换3B要慎重，工具调用能力掉得挺明显，不如先把上下文长度压一压，或者用AWQ

角色设定肯定有用，但它的作用更像是给模型圈定一个概率范围，而不是精确控制每一句话。你那个“10年汽车销售”的设定太抽象了，模型脑子里可能同时激活了“专业”“热情”“礼貌”“客服”好几套模式，一不留神就滑回最安全的客服腔去了。我自己的经验是，光给风格关键词远远不够，得往里塞具体的语言习惯，比如“说话时偶尔用‘咱’‘哥们儿’这种词”“不要用‘尊敬的客户’开头”“每句话控制在两行以内”，这些硬约束比形容

同感，我之前也踩过这个坑。后来发现规则堆太多反而互相打架，模型每步都在纠结“我是不是该走流程”。试试把硬规则改成目标描述，比如“周报要简洁，能一句话说清就别展开”，让它自己判断。我现在控制在500字以内，效果比2000字好多了。

这个问题我踩过不少坑，说点实际感受。全量塞历史记录基本是条死路，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。