把更多文档放进模型，是解决知识缺口的一种办法，却不是答案正确的保证。二〇二三年的Lost in the Middle论文在多文档问答与键值检索任务中发现，所测模型的表现会随相关信息位置变化：开头或结尾通常较好，中间位置可能明显变差。本文重访这项既有研究，不把历史实验结果当作当下所有模型的能力结论。
它留下了一个仍有工程价值的问题：系统能够接收多长的输入，与它能否稳定使用输入中的证据，需要分别测试。所谓长上下文容量，首先描述可装入的范围；用户真正关心的是资料进入后，回答有没有正确引用和解释。
让同一份证据换几个座位
团队可以从自己的文档中挑选明确有答案的问题，把关键段落分别放到开头、中间和结尾，同时保持其他材料与提问基本相同。比较结果时，不只记录答对与否，也记录引用是否对应原文，以及模型是否添加了原文没有的条件。这是一项位置稳健性检查，而不是新的通用排行榜。
如果只有中间位置容易出错，后续优化就应围绕材料组织与检索流程展开。如果所有位置都答错，则可能是题意、资料质量或领域能力的问题。先把原因拆开，通常比直接增加输入长度更容易找到可以修改的环节。
删减也可能提高可读性
知识库系统可以试验先检索少量相关材料，再根据证据缺口补充的流程。但检索也可能漏掉重要文件，因此应同时保留一组需要跨文档连接的问题。只测试单一段落内的答案，很容易高估系统处理复杂业务问题的能力。
我们还建议给相互冲突的材料单独设计样本。例如，新旧制度文件都出现时，系统应说明日期与适用范围，而不是把两份规则混合成一个听起来合理的版本。这里的目标是让读者知道答案依据什么，而非让输出看起来越完整越好。
长上下文的实际价值，需要在具体模型版本与任务上重新测量。保存提示、资料顺序和运行配置，才能在更新后比较。对开发者而言，最大的窗口只是一个起点；能够稳定找到、引用并保留证据的边界，才构成可靠知识服务。
归档说明：本篇于二〇二六年十月十二日补写并上线，按十月十日栏目归档；文中资料在该归档日期前已公开。