先抛结论往大模型上下文里塞的检索片段不是越多越好。塞个十几段进去模型对排在中间那几段经常视而不见——开头记得、结尾记得、夹在中间的有用资料被它跳过去了。这现象有个名字叫 lost in the middle我吃过它的亏今天讲清楚怎么发现、怎么治。我是怎么撞上的做一个产品答疑助手为了「保险」我把检索 top k 从 5 调到了 15想着多给点资料总不会错。结果准确率不升反降。有个问题正确答案明明就在召回的第 8 段里模型却答了句风马牛不相及的理由是「资料中未提及」。我把第 8 段单独拎出来放第 1 位重问它立马答对了。那一刻我才明白资料在不在上下文里和模型有没有真看到是两码事。窗口越长、片段越多中间地带越容易成为模型的盲区。这不是哪个模型的 bug是长上下文的通病研究里复现过很多次——模型对首尾位置的注意力天然比中间高。三个能立刻用的招1. 少塞先把召回质量做上去。治标先治本。与其塞 15 段赌模型能翻到中间不如靠重排把最相关的 3 到 5 段拣出来精准喂。我后来把 top k 从 15 砍回 6前面加一层重排序准确率比塞 15 段那会儿还高。片段精了根本用不着那么长的窗口。2. 把最相关的放两头次要的塞中间。如果片段数确实压不下来就别按相似度从高到低顺排。利用首尾注意力高的特性把最关键的两三段分别放开头和结尾没那么重要的塞中间。def reorder_for_attention(docs): # docs 已按相关度从高到低排好 head, tail, mid [], [], [] for i, d in enumerate(docs): if i % 2 0: head.append(d) # 偶数名次放前段 else: tail.insert(0, d) # 奇数名次倒着放后段 return head mid tail思路就是让 rank 高的占据首尾黄金位。我实测这招对「片段没法减少」的场景挺管用改个排序不要钱。3. 让模型显式列依据逼它逐段看。prompt 里要求它「回答前先列出你用到了哪几段资料的编号」。逼它走一遍逐段核对的流程中间段被跳过的概率会降。代价是输出啰嗦点、慢一点。做法中间段被忽略成本无脑塞 15 段严重窗口浪费重排后塞 5 段明显缓解多一次重排首尾放关键段缓解几乎为零一个反直觉的体会做 RAG 久了我才扭过弯来上下文窗口大是给你「装得下」的能力不是让你「装满」的许可。塞满它约等于把重点淹了。真正决定效果的是「喂进去的少而准」不是「喂进去的多而全」。我现在默认 top k 不超过 6宁可在召回和重排上多下功夫也不靠堆数量赌运气。这套检索重排我搭得挺省事。智能体在一个零代码就能配 RAG 的平台上拖的知识库托管、向量化自动做top k 和重排在界面上调省了我自己维护检索链路。但「片段怎么排序喂给模型」这种细活平台默认就是按相似度顺排想做首尾重排还得我自己在中间插一段逻辑——它给的是地基盖法还得自己来。(底层大模型走的讯飞星辰 MaaS现成模型直接调没自己部署算力)你们碰到过中间片段被模型无视的情况吗是靠减数量还是改排序解决的评论区交流下。