北京
RAG系统检索到了包含答案的段落。段落送到了模型面前。答案还是错的。
这种失败值得琢磨，因为光用检索质量解释不了它。还得看另一件事：模型到底怎么使用它拿到的证据。
有一个研究问题可以顺着往下挖：如果证据本身不变，只改变它在上下文里的位置，答案会不会跟着变？
这个问题背后有一篇论文撑着——《Lost in the Middle: How Language Models Use Long Contexts》，专门研究模型如何使用输入中不同位置的信息。论文的实验里，相关信息出现在开头或结尾附近时，表现往往最强；信息落在长上下文的中间位置时，表现可能下滑。论文研究的是多文档问答和键值检索两类任务。
这个发现对RAG是个现实提醒：把证据塞进上下文窗口，并不保证模型会可靠地用上它。它也给出一个可以动手验证的假设——注意，是假设，不是可以默认对所有当前模型都成立的结果。
要测的东西很明确：答案质量对支撑证据位置的敏感程度。
起点选那些各自只有一个清晰支撑段落的问题，这样在引入需要多份证据的问题之前，能先把位置这个变量单独隔出来。每个问题构造三个版本：支撑段落放开头、放中间、放结尾。问题、段落文本、干扰段落、指令全部保持不变，只动段落顺序。
举个具体的例子。问题：“客户有多长时间可以申请退款？”支撑证据：“退款申请必须在购买后30天内提交。”模型能不能在三种位置下都稳定答出“30天”，并且引用正确的段落？
一个例子说明不了什么。要用带标注的问题集，用多种打乱顺序的干扰段落重复对比，还要测不同的上下文长度。每一次对比里，模型版本、生成设置、输出预算都固定住。段落重排时，段落ID要跟着段落走。还要确认输入没有被截断，否则测到的可能是证据丢失，而不是证据位置。
再加一个只有支撑段落、没有干扰项的基线，用来识别那些模型本来就吃力的问题。
测量分三项：答案准确率，回答是否匹配标注答案；引用正确性，被引段落是否真的支撑答案——光返回一个存在的段落ID不算数；位置敏感性，开头、中间、结尾三种摆放之间准确率差多少。结果按模型和上下文长度分开报告，并带上估计的不确定性。
如果中间位置确实更差，下一个实验就可以在相同token预算下比较不同的上下文排序策略。如果看不出明显差异，这同样有用——说明论文里的模式在测试条件下没有清晰复现。两种结果都需要一个有边界的结论：这些模型、这些问题、这些上下文长度。
检索成功只是RAG答案成功的一部分。下一个问题是，模型能不能可靠地用上我们给的证据，以及我们构造上下文的方式，是在帮它还是在添乱。
这套实验计划有研究支撑，结果尚未测量。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
