隔壁后端手记

说实话你这个情况我太熟了，之前用LangChain的Agent做数据分析也是这个鬼样子，工具一多就像个走神的小孩，指令稍微绕点弯就掉链子。我觉得问题不只在prompt，ReAct这种推理模式对长链路的工具编排天生就弱，它每一步都要靠LLM自己“想”下一步干啥，中间一旦上下文被工具返回结果冲淡，决策质量就断崖下跌。我后来是把多步任务拆成显式的Plan-and-Execute，先让模型列一个工具调用清

全局提示词定死风格和公共格式，步骤里只写增量指令，不然改一处崩全链路。 调试建议先固定中间输出快照，单独测每步再串起来，不然变量太多根本定位不了问题。

试过按语义切分没？比如用句号或者标题做边界，比死磕字符数靠谱，overlap设个50-100试试。 代码和论文肯定得分开调，代码按函数块切，论文按章节切，效果会好很多。

遇到过类似情况，bge系列对通用语义还行但领域术语确实容易跑偏，尤其操作步骤这种强上下文信息，光靠向量检索本身就吃亏。你可以先试试不用embedding，直接拿bm25跑一遍同样的问题，看召回是不是反而更准，如果是的话那就不是模型问题，是检索策略该换混合了。另外有个坑是你用HyDE生成的问题如果本身不贴合真实问法，反而会把向量带偏，不如直接用原问题做查询改写。chunk粒度那边我建议你按“操作动作

固定512字符切确实容易把操作步骤里的上下文切断，尤其产品手册里“先拧A再按B”这种动作链，语义边界被破坏后embedding肯定抓瞎。建议先试试按标题/章节结构切，或者用滑动窗口+小chunk重排序，比直接换模型成本低。bge-large-zh提升不明显可能因为你的文档偏技术术语，中文预训练覆盖有限，不如试试在召回后加个BM25的RRF融合，我这边混合检索把top5命中率拉高了快20%。另外你提

说实话A10跑7B FP16确实有点勉强，24G看着够但KV cache一涨就崩，你调max-model-len到2048其实已经牺牲了实用性。我建议先别急着上量化，试试vLLM的PagedAttention加上--enable-prefix-caching，内部工具如果prompt重复率高能省不少显存。AWQ变慢我遇到过，很可能是量化后dequantize开销在A10这种卡上没被优化好，换GPT

7B+2048长度本来就这样，24G真不宽裕，试试gradient checkpointing+8bit优化器能省不少。

代码用0.3加top_p 0.9就行，别老调repeat_penalty，API和本地逻辑其实差不多。

我这边也是用vLLM跑13B，A100 80G单卡，并发一多就OOM，太真实了。你试过把max-num-seqs调小点吗？这参数直接限制同时处理的序列数，先压到16或者8，虽然吞吐会掉，但能顶住小流量不崩，属于马上能用的trick。Flash Attention确实有效，它主要是省attention那块的显存，尤其长上下文场景，但vLLM老版本默认没开，你升级到最新版再在启动参数里加上--enab

用过torch.compile跑过类似动态输入的场景，说实话你的担心是对的，compile对变长序列的优化效果确实会打折扣，因为它会尝试根据实际shape做speculation，一旦输入长度频繁变化，重编译的开销可能比省下的计算时间还多。我当时试过在输入长度波动超过2倍时，compile版本反而比eager模式慢了20%左右，后来干脆只在固定batch size的benchmark里用它。 不

这情况太典型了，loss降得漂亮不代表模型真的学好了，你拿2万条全是法律文书的数据去微调，模型注意力全被拽到法律语境里，通用能力肯定被冲淡。我觉得不光是r值的问题，你试试在数据里混个30%的通用指令数据，哪怕是很简单的问答都行，能明显缓解这种偏科。另外eval真别只看loss，生成效果才是硬指标，尤其要测几道跟法律无关的常识题，不然你都不知道模型啥时候开始“飘”的。我自己之前做医疗微调也踩过这坑，

之前也遇到过类似情况，后来发现多半是特征没归一化的问题。ResNet提的特征如果不做L2归一化，直接算L2距离，向量的模长差异会主导结果，导致颜色、亮度这些低层特征干扰了语义相似度。你可以先试试把向量归一化再存，召回的准确率一般会有明显提升。 另外IVF_FLAT这个索引本身对高维向量的细粒度区分度就一般，nlist设1024其实已经不小了，但nprobe参数也影响召回质量，查询时如果nprob

把prompt里加上“只输出代码，用pandas或csv都行，别加注释”，能稳不少，我试过有效。 其实把需求拆成“输入、处理、输出”三行写清楚，再限定库和格式，随机性就小多了。

我之前也踩过类似的坑，后来发现主要问题不一定在向量库参数，而是chunk方式太机械了。可以试试按语义段落切分，或者用parent-document retriever，让检索粒度更细。另外温度别超过0.3，top_p0.9左右就行，不然生成模型确实容易飘。嵌入模型换成text-embedding-3-large或者bge-m3会稳很多，特别是中文场景下差距挺明显的。

我之前也踩过这个坑，光调chunk_size效果真的有限。后来改成按markdown标题层级切分，再把表格单独提取出来做结构化存储，检索准确率明显上来了。你可以试试用unstructured库做分区解析，它对PDF的多级标题和表格支持不错。另外，检索的时候最好把标题和段落拼成上下文一起embedding，不然只匹配正文内容很容易答非所问。你现在的召回结果是靠向量相似度排序还是加了重排模型？

这种情况太典型了，模型对“不基于”的理解其实很弱，它本质上是个概率生成器，价格这类高频信息很容易被硬拽出来。我试过的办法是给每条检索内容加个可信度标注，然后prompt里加一句“如果检索内容没提到，就直接回答不知道”，比单纯强调“只基于”管用。另外你检查下检索结果是不是真的够准，有时候是召回片段里隐含了误导信息，模型顺着就编了。

维度不是越高越好，128对复杂语义确实吃力，中文技术文档建议384维起步，先拿小批量数据对比测试下检索效果再定。

试试把top-k降到3，再精调reranker阈值，比堆片段数量管用，我这边效果稳定多了。

光调切块没用，建议直接上reranker，像bge-reranker这种轻量模型效果立竿见影。 **或者**：切块策略得按语义边界来，别死磕固定size，配合小模型reranker召回率能提不少。

其实问题可能不在长度，而是LLM对“示例”的权重天然低于对“指令”的权重，200行代码在注意力机制里容易被当成背景噪音。你可以试试把示例代码直接放在生成任务的前面，并且用“保持变量名不变，只修改逻辑部分”这种更具体的操作指令，别用“严格”这种模糊词。另外我自己的经验是，如果示例太长，可以拆成两轮对话，第一轮让它总结出代码风格规范，第二轮再让它基于这个规范去生成，效果会稳定很多。