狐狸偶尔重构日记

500字切法对法律条款太粗了，试试按条文语义边界切，再配合rerank比HyDE见效快。

试过把chunk size调小到两三百吗？重叠也可以再大点，比如128。片段太碎的话，就算top_k调大，拿回来的还是零散信息，模型很难自己理清顺序。 另外可以试试在检索后加一步重排，按时间或者逻辑关系排一下序再塞给模型，比单纯扩大召回有用。我之前用bge-m3也遇到这问题，后来改成按段落层级检索，效果好了不少。

试试把检索粒度调细+rerank，比硬截断靠谱，上下文窗口留20%余量给回答生成。 我们这边是直接改MCP的tool schema，支持分批返回，每次带个cursor继续拉，实测比MapReduce省事。

召回前几段就不相关，大概率不是重排序能兜住的，先拿256按段落切试试，往往立竿见影。

先调切块吧，512太长噪声多，bge-m3配256按语义段切效果立竿见影。

这个问题太典型了，我当初用LangChain也踩过这坑。核心问题其实不在模型，而是你把多步状态都塞给LLM去管理，它天生就不擅长这个。建议把中间结果显式存到结构化变量里，或者直接用LCEL的RunnablePassthrough把数据流打通，别让Agent自己“回忆”。另外试下gpt-3.5-turbo-16k，上下文长点至少能减少部分“失忆”概率，但根治还是得从架构上把依赖关系写死，别指望模型自

你这显存占用其实挺正常的，vLLM默认会给每个request预留挺大块的KV cache池，加上7B模型int8实际加载也得10G出头，两张卡没跑起来八成是tensor parallel的配置没生效，检查下是不是启动命令里少了`--distributed-executor-backend`之类的参数。速度20 tok/s如果是加了长上下文或并发请求的话也不算太离谱，benchmark那些40+多半

我最近也在折腾类似的东西，试下来感觉把步骤拆成多个子Prompt调用，比硬塞在一个Prompt里更稳。因为一旦中间某步错了，后面全跟着歪，分开调还能单独检查工具返回的数据是不是合理。至于防止编造，我会在每次工具调用后加一句“如果检索结果里没有对应信息，直接说不知道，别补全”，然后配合few-shot给个反例，效果比单纯说“必须基于检索”好不少。另外你那个“请逐步思考”不稳定，可能是它偶尔会触发模型

这个问题我最近也刚踩完坑，说下我的实际观察。你提到的第一种“query+answer”模式，我试过之后发现模型确实容易“偷懒”——它会把few-shot里的回答格式当成金科玉律，哪怕检索回来的chunk里明明有更准确的信息，它也倾向于按示例的句式硬套。比如示例里写“保修期2年”，结果chunk里其实是“保修期1年，延保可购2年”，模型照样输出“2年”，这就很要命。 第二种“context+que