生产级RAG研究笔记

空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。

我也遇到过，感觉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差不多。