生产级数据科学开发日志

自己玩直接Ollama吧，省心多了，vLLM那报错确实劝退，等真上生产再折腾TensorRT也不迟。

合同文档这种强结构化的东西，512固定分块确实容易把关键条款切碎，建议先试试按条款标题或段落做语义分块，召回能涨一截。bge-large-zh在专有名词上未必输ada-002，但你们要是没做微调，长尾词确实吃亏，可以拿业务语料跑个对比测试。Milvus索引影响没你想的大，HNSW一般比IVF_FLAT召回稍好，但62%这锅多半在分块和embedding，不在索引。

4090跑7B其实没必要死磕FP16，试试vLLM开enable_prefix_caching加上gpu_memory_utilization调到0.9，KV cache用fp8量化，长上下文能稳不少。AWQ确实比GPTQ稳，部署麻烦点但值得，vLLM对AWQ支持已经挺成熟了。如果代码生成要求高，可以考虑Qwen2.5-Coder-7B的AWQ版本，比通用版量化后掉点少很多。量化掉效果很多时候是校

CodeLlama 7B做补全确实有点勉强，它那个预训练侧重和指令微调版本差别挺大的，你用的如果是instruct版本反而更容易触发那种“礼貌性输出”——就是拼命给你加注释显得自己很懂。我试过7B和13B，13B在纯代码续写上明显稳不少，但要说完全听话还是得看你怎么给上下文。你那个`def calculate_mean(data):`的例子，模型看不到后面的调用场景，它只能靠猜，一猜就容易往模板化

长文本里中段被忽略确实很常见，我后来是把示例拆成“输入-输出”成对用XML包起来，每对之间加个简短锚点句，比如“以下示例仅针对上一段”。另外关键约束我会在系统提示和用户输入末尾各放一次，但措辞稍微换一下，避免模型当成重复噪声。还有个土办法是让模型先输出中段摘录再总结，相当于强制它先看一遍。你要是业务上必须示例紧挨输入，可以试试在示例内部用编号分段，效果比纯换行稳不少。

我之前也踩过这个坑，ReAct在多步任务里确实容易打转，尤其是工具返回结果模糊的时候。你可以在prompt里强制让它每步先输出“当前状态+下一步唯一动作”，再加个简单的步骤计数器，超过阈值就强制切换或总结。另外记忆模块别只用默认的，试试用摘要压缩历史，能明显减少重复调用。不一定非要换框架，先把工具返回的结构化程度提上去，效果会稳很多。

我现在做类似的项目也踩过这个坑，后来加了BM25做混合检索，用RRF融合，召回准确率提升挺明显的，尤其是“年假”这种关键词明确的问题。另外query改写也值得试，比如先把“年假怎么休”扩展成“年假 休假 天数 申请流程”再检索，能拉回不少正确片段。还有个小技巧是给chunk加标题和制度名称的元数据，检索时带上过滤条件，比单纯调topk管用多了。

试试vLLM的gpu_memory_utilization调到0.9再加KV cache量化，7B用int8 KV基本不掉效果。

先查下 K8s 的 Service 有没有设 sessionAffinity，长连接被轮询到不同 Pod 就断，这坑我踩过。

这种情况太常见了，你prompt本身大概率没大问题，锅多半在检索那一段。你想想，模型再听话，喂进去的上下文里就混着不相关的段落，它没法凭空判断哪句是真的，只能顺着你给的文字编，所以才会引用不存在的文档内容。先别急着调prompt，把检索出来的chunk打出来看一眼，我赌你会有新发现。temperature降到0.1只是让它别乱发挥，但它对着垃圾上下文照样会一本正经地胡说。我一般会在prompt里加

状态被覆盖大概率是并发写同一个key导致的，LangGraph里节点返回的dict是merge不是replace，但如果你在节点里直接改state对象就会出问题。我之前也踩过这坑，后来改成每个节点只返回自己负责的字段，别去动别的key，就稳了。检索结果旧的问题可以看看是不是checkpoint没配好，或者节点间用了不同的thread_id。调试的话LangSmith挺香的，能看到每个节点进出的完整

拆成子prompt分步调更稳，每步只干一件事，幻觉少很多。硬性要求可以写“若检索结果没提到，直接说不知道”。

先Chroma跑通demo，百万级再迁Milvus也不迟，Qdrant配LangChain挺顺的。

几千份PDF固定500切分太糙了，先按标题层级切再合并试试，这块提升往往比换模型大。

几十万切片真没必要上Milvus，pgvector完全够用，省一套运维。后面量涨了再迁Qdrant也不难，接口比Milvus友好。结构化信息建议单独存PG，检索时用id关联，别硬塞进向量库。Chroma我拿来做原型挺爽，但生产环境并发一上来确实会卡。

你试试在prompt最后加一句“只输出diff，别动其他行”，我这样搞后它老实多了。

试试在prompt里加句“只依据下面内容作答，没提到就说不知道”，能压住不少幻觉。

tool描述确实很关键，别只写“查天气”，要写清楚什么时候该用、什么时候不该用，比如“仅当用户明确询问天气状况时调用”。另外提醒带伞这种其实算条件触发，可以考虑拆成两步：先解析意图，再决定调哪个工具。temperature调高反而容易乱选，建议降到0附近试试。

太真实了，我一开始也这么干过，十几个server全挂上，结果上下文里光工具描述就占了大半，模型还没开始想代码就被淹了。后来砍到只剩filesystem、git和一个数据库，明显顺畅多了。这东西不是越多越好，工具选择本身也在消耗推理预算，还不如按当前项目手动开关。可以试试配置文件里做几套预设，切换项目时换一套，比全开省心。

低并发下快那点确实爽，但QPS一高显存就炸，这取舍太真实了。