RAG 失效的真正原因，长上下文救不了 RAG

最早大家做 RAG是因为模型上下文太短一次塞不进完整文档只能先检索再把相关片段交给模型回答。后来模型上下文窗口越来越长从 32K、128K 到百万 token很多人开始觉得RAG 可能只是一个过渡方案。只要模型能一次读完几十万字甚至几百万字我们还需要复杂的检索、切块、索引和重排吗Stanford OVAL 最近这篇论文Contexts are Never Long Enough: Structured Reasoning for Scalable Question Answering over Long Document Sets给了一个很冷静的回答需要而且远远不够。因为真实世界的问题不只是“上下文不够长”而是“信息无法被稳定组织、合并和计算”。论文提出的系统叫SLIDERS全称是Scalable Long-document Integration through Decomposed Extraction and Reconciliation System。它的核心观点非常直接不要再让大模型在一堆长文本里硬读而应该先把文档变成结构化数据库再让模型通过 SQL 对数据库进行推理。这篇论文最有意思的地方不是又做了一个 RAG 改进版而是把长文档问答的真正瓶颈讲清楚了RAG 的问题不只是检索不到而是检索到了以后系统仍然需要把大量证据聚合起来。chunk 越多证据越多最后合并推理越困难。论文把这个问题称为Aggregation Bottleneck也就是“聚合瓶颈”。这可能是当前 AI 系统进入真实业务场景时最容易被低估的问题。长上下文并不等于长记忆我们先想一个很普通的工作场景。一个金融分析师要回答“100 家公司哪家公司长期借款最低哪些公司长期借款为零前五大借款公司占总借款比例是多少”这不是一个简单问答。答案可能分散在 100 份财报里每份财报又有几十页相关信息可能出现在资产负债表、附注、债务说明、现金流表或管理层讨论中。有些公司明确写了长期借款有些公司只通过上下文暗示为零有些公司在不同页面给出不同口径有些数值还存在单位、币种、千美元、百万美元的转换问题。你可以把所有文件都塞给一个百万上下文模型吗理论上部分场景可以。但问题是模型即使“看到了”也未必能稳定地把这些信息抽出来、对齐、去重、计算并验证。长上下文解决的是“能不能放进去”不是“能不能精确组织”。这就是 SLIDERS 论文最重要的判断现实世界的文档集合会不断增长任何固定上下文窗口最终都会被超过而且即便暂时没有超过模型在长上下文中聚合分散证据的能力也会下降。论文在引言中指出现实中的金融、医疗、社会科学分析都需要跨多个文档、多个页面合成证据而长上下文推理仍然会受到上下文限制、检索遗漏、远距离证据整合困难、输出不可审计和推理成本高等问题影响。所以真正的问题不是上下文长度而是信息组织方式。一个人读 100 份财报也不会把所有文字都背在脑子里。他会做表格记出处统一单位标注可疑值合并同义公司名最后再用公式计算。换句话说人类做长文档分析时本能上就不是“长上下文推理”而是“结构化工作流”。SLIDERS 做的事情就是把这套工作流系统化。Chunking 不是终点它会制造新的瓶颈RAG 的经典做法是把文档切成 chunk然后检索相关 chunk再把它们交给 LLM 生成答案。这个思路对很多问题有效尤其是答案集中在少数片段里时非常实用。但只要问题需要全局聚合chunking 就会开始暴露问题。假设一个问题要统计 100 个文档中的全部公司债务情况。每个 chunk 可能都能局部抽取出一些信息但最终系统还是要把几百甚至几千条 chunk 级结果合并起来。传统方法通常会把 chunk 输出拼成文本摘要再让 LLM 做最后聚合。问题是这一步本身又变成了一个新的长上下文问题。现有 chunk-based 方法先从不同 chunk 中抽取文本中间状态然后把这些文本证据重新拼接给 LLM导致中间文本随着 chunk 数量增长而增长这等于绕了一圈又回到了上下文窗口限制里。SLIDERS 的做法则不同它把 chunk 输出转成关系数据库让系统在数据库上完成聚合、比较和计算而不是把所有证据重新塞回模型。这就是所谓 aggregation bottleneck。很多 RAG 系统看起来失败在“没检索到”但在真实复杂任务中更常见的失败其实是“检索到了但合不起来”。模型可能找到了相关表格却没统一单位找到了多个页面却没判断哪个值更权威找到了不同公司却没对齐公司名称找到了多个时间点却没区分 fiscal year 和 calendar year找到了局部事实却无法稳定完成全局排序、计数和比例计算。这不是简单增加 top-k 能解决的。top-k 越大证据越多聚合负担反而越重。RAG 的上限往往不是 retrieval而是 aggregation。SLIDERS 的关键转向把文本变成数据库SLIDERS 的技术路线可以概括成一句话把长文档问答从文本推理问题改造成数据库推理问题。它不是让模型直接在长文本中回答而是先把文档拆成局部自包含的 chunk然后让模型从每个 chunk 中抽取结构化数据存入关系数据库。每个字段不仅保存值还保存证据出处、原文 quote 和抽取 rationale。之后系统通过数据 reconciliation 清理重复、冲突和不完整记录最后让 SQL agent 对数据库写查询生成答案。Stanford 项目页也把 SLIDERS 描述为一种面向 ultra-long document QA 的结构化推理框架用关系状态替代拼接文本。完整流程第一步是 contextualized chunking给每个 chunk 保留文档标题、结构层级、页码、表格和章节上下文第二步是 schema induction根据问题自动生成关系数据库 schema第三步是 structured extraction从 chunk 中抽取表格行同时保留 quote 和 rationale第四步是 data reconciliation用 SQL coding agent 清洗数据库第五步是 question answering让模型写 SQL 查询并生成最终答案。这里最关键的是 schema。传统 RAG 的中间状态通常是自然语言摘要这种表示很灵活但也很不稳定。一个 chunk 输出“accounts payable and accrued expenses”另一个 chunk 输出“accounts payable”第三个 chunk 写“current liabilities”模型最后要靠语言理解去判断它们是否指向同一个财务概念。SLIDERS 让模型先为问题生成数据库 schema明确字段名称、数据类型、单位、尺度、归一化规则。论文给出的字段定义包括 field name、semantic description、data type、unit、scale 和 normalization rules例如金额统一成 USD、日期统一成固定格式、数值统一成 thousands 或 millions。这一步非常重要。它把模糊文本变成可计算对象。一旦信息进入数据库很多本来容易出错的问题就不必交给大模型“猜”。排序、计数、过滤、聚合、求平均、算比例、找最大最小这些操作都可以由 SQL 确定性完成。大模型不再需要记住所有证据而是负责生成合适的查询数据库负责保存、组织和计算。这其实是一个很深的系统设计思想LLM 不应该承担所有认知负担。大模型擅长理解语言、生成 schema、抽取语义、写 SQL、解释结果。但它不擅长在几百条碎片证据中稳定计数不擅长手工维护状态不擅长确保单位永远一致也不擅长在长上下文里不漏任何一个关键数值。把这些工作交给数据库才是合理分工。Data Reconciliation 才是这篇论文最有价值的部分如果只是“把文档抽成表”这篇论文还不够新。真正重要的是它加入了data reconciliation也就是数据调和。为什么需要 reconciliation因为每个 chunk 的抽取结果在局部可能都是正确的但全局合起来可能是脏的。同一个公司可能在不同页面被写成 BioLargo Inc、BIOLARGO, INC. 或 BioLargo同一个财务指标可能在资产负债表中以合并口径出现在附注中以拆分口径出现同一个人可能在维基百科不同段落中出现全名、艺名、缩写或别名同一事件可能被不同段落重复描述也可能被多个段落补充不同属性。如果不做 reconciliation数据库只是“局部抽取结果的堆积”不是一个真正可用的全局状态。论文的做法是把每一行都带上 provenance、extraction rationale 和 metadata。然后 reconciliation agent 会根据主键把相关行分组在每个组内做三类操作去重、冲突解决和信息合并。论文第 5 页的表 1 对这三类操作做了清楚定义deduplication 用于合并语义相同或近似相同的行conflict resolution 用于在互相竞争的值之间选择证据最强的值consolidation 用于把互补属性合并成更完整的记录。这一步很像一个严谨的数据分析师在清洗 Excel 表。比如两个页面都提到某公司 accounts payable一个值来自“accounts payable and accrued expenses”另一个值来自附注明细中的“accounts payable”。如果问题问的是 accounts payable系统就不能简单选择更大的数也不能把两个数相加而要看出处和 rationale判断哪个字段真正对应问题。论文用 BioLargo 的例子说明资产负债表中的 1,740 是 accounts payable and accrued expenses 的合计而附注明细中的 1,663 才是 accounts payable 总额。这就是 provenance 的价值。没有出处和理由模型只能猜有了出处和理由系统可以审计、纠错和验证。我认为这是 SLIDERS 最值得关注的地方。很多 AI 系统只追求最终答案看起来回答得很顺但错误很难追踪。SLIDERS 的答案来自数据库数据库中的每个值都有 quote 和 rationale错误分析时可以回到原文检查。论文也指出provenance tracking 增强了 auditability 和 interpretability甚至帮助作者发现了一些 benchmark gold answer 自身的错误。在金融、医疗、法律、科研这些高风险领域可审计性不是附加功能而是系统能不能用的前提。实验结果说明了什么SLIDERS 的实验结果有两个层次。第一个层次是在传统长上下文 benchmark 上比较。FinanceBench、Loong 和 Oolong 的输入长度都在 360K token 以下理论上可以放进 GPT-4.1 这样的强模型上下文窗口。结果 SLIDERS 仍然超过所有 baseline平均准确率 75.56而 GPT-4.1 base model 是 68.69RLM 是 66.46GraphRAG 是 52.87普通 RAG 是 42.77。尤其是在 Oolong 这种强调聚合的任务上SLIDERS 达到 64.67明显高于 GPT-4.1 的 45.56。这说明一个重要事实即使上下文放得下结构化推理仍然有价值。问题不是“能不能读完”而是“能不能稳定聚合”。第二个层次是在超长文档集上测试。论文构建了两个新 benchmarkWikiCeleb100 包含 100 个高访问量名人维基页面总计 3.9M tokensFinQ100 包含 100 家 SEC 上市公司的最新 10-Q 文件总计 36M tokens。传统 GPT-4.1 已经无法直接处理这些输入。SLIDERS 在 WikiCeleb100 上达到 78.91%普通 RAG 只有 31.41%在 FinQ100 上达到 55.22%普通 RAG 只有 5.00%。FinQ100 特别有代表性。它需要跨 100 份财务文件抽取长期借款信息很多公司不直接写“长期借款为零”而是要从上下文中推断。SLIDERS 抽取了 685 行候选数据而 ground truth 只有 105 行这说明原始抽取存在大量重复、冲突和冗余。没有 reconciliation准确率会从 55.22 掉到 35.81在 WikiCeleb100 上去掉 reconciliation 也会从 78.91 掉到 60.50。这进一步证明真正难的不是抽取而是整理。为什么这件事对未来 AI 系统很重要SLIDERS 论文真正值得讨论的地方不只是一个 benchmark 提升而是它代表了一种 AI 系统设计范式。过去我们容易把大模型想象成一个越来越大的脑子。上下文越长记忆越强参数越多能力越强推理越深答案越好。但真实工作流告诉我们智能不只是脑子大还要有外部工具、笔记、表格、索引、验证器和审计机制。一个专业分析师不会把所有材料一股脑塞进脑子里。他会建立表格统一字段记录出处标注不确定项清洗数据再做计算。一个工程师不会靠记忆管理复杂项目他会用 Git、issue、日志、测试、数据库和文档系统。一个科研人员不会把所有论文细节都记在脑子里他会做文献矩阵、实验表格、证据链和版本记录。AI 系统也应该这样。长上下文像短期工作记忆数据库像长期结构化记忆SQL 像确定性推理工具provenance 像引用系统reconciliation 像数据清洗和知识整理。未来强 AI 系统不会只是“一个模型读一切”而更可能是“模型 数据库 工具 结构化状态 审计链”的组合。这和当前 Agent 系统的发展也很一致。Agent 如果要长期工作不能只靠上下文记忆而要把中间状态写进外部环境。代码 Agent 需要文件系统、测试和日志科研 Agent 需要文献库和实验记录金融 Agent 需要结构化财务表医疗 Agent 需要可追溯证据链。SLIDERS 只是把这种思想放在长文档问答中做了一个非常清晰的实现。我觉得它给所有 RAG 系统一个提醒不要只优化 retrieval要认真设计 intermediate representation。也就是说不要只问“取哪些 chunk”还要问“取出来的信息应该变成什么结构”。是自然语言摘要还是实体表是知识图谱还是关系数据库是向量记忆还是 SQL 表是一次性 prompt 上下文还是可复用的结构化状态不同答案决定了系统的上限。RAG 的下一步不是更大的 top-k而是更好的状态管理很多人做 RAG 时会自然地堆模块embedding 换更强的reranker 换更大的top-k 设更多chunk size 调更细再加 query rewrite、multi-hop retrieval、GraphRAG、HyDE、agentic retrieval。它们都有价值但对于需要全局聚合的任务来说这些还不够。因为只要最终仍然把证据塞回 prompt让模型用自然语言合成答案aggregation bottleneck 就还在。SLIDERS 的思路是把中间证据从“文本”变成“状态”。文本是临时的、模糊的、难计算的状态是持久的、结构化的、可查询的。文本适合表达状态适合推理。LLM 负责从文本到状态再从状态到答案中间的保存、计算和合并交给数据库。这可能是未来企业 RAG 的一个重要方向。企业知识库不是网页搜索。它经常涉及合同、财报、病历、流程文件、会议纪要、技术文档、审计报告和项目材料。问题也不只是“某个条款是什么”而是“跨多个项目统计原因”“比较不同季度指标”“找出所有不一致描述”“归纳多个文件中的证据链”。这种任务天然需要结构化状态。所以真正的企业 RAG 不应该只是一个聊天框加向量库而应该更像一个自动数据分析系统它能读文档抽字段建表合并清洗保留证据然后回答问题。这时候大模型不是数据库的替代品而是数据库的接口和自动建模器。这篇论文的边界在哪里当然SLIDERS 也不是万能答案。论文自己也承认它依赖 schema induction因此对能够关系建模的任务更有效对于高度主观、抽象、难以表格化的跨文档推理收益可能有限。它的 pipeline 需要多次 LLM 调用端到端延迟比单次模型调用更高大约 2 到 3 分钟更适合准确性优先的分析任务而不是实时对话。论文还指出FinQ100 上 55% 的准确率仍然不足以支持高风险金融分析的全自动化因此需要 human-in-the-loop verification。这点很重要。SLIDERS 的价值不是宣布“AI 可以完全替代分析师”而是更现实地说明AI 可以把人工分析中的文档阅读、字段抽取、证据整理和 SQL 查询大量自动化但最终高风险场景仍需要人来验证。我反而觉得这种克制让论文更可信。很多 AI 系统最大的问题是把 demo 包装成自动化把生成答案包装成可靠推理。SLIDERS 至少承认系统仍然会错但它让错误更容易被发现因为每个值都有出处每个合并都有 SQL每个答案都可以回到数据库和原文。对于真实业务来说可审计的 55%往往比不可审计的 80% 更有意义。前者可以被人类接管和改进后者可能只是看起来很强。上下文不是记忆结构才是记忆这篇论文最值得记住的一句话不一定是 SLIDERS 的准确率而是标题本身Contexts are Never Long Enough。上下文永远不够长。不是因为模型工程师不够努力而是因为真实世界的信息本来就是无限增长的。企业文档会继续增加财报会继续发布论文会继续积累病历会继续变厚法律文件会继续扩展。你不可能指望一个固定窗口永远装下世界。更重要的是即使能装下也不代表能理解、整理和计算。长上下文解决的是“把信息放进模型”结构化推理解决的是“把信息变成可用状态”。前者像把一整座图书馆搬进房间后者像建立目录、索引、数据库和引用系统。真正的智能分析不是坐在一堆书里凭记忆回答而是知道如何抽取事实、合并证据、验证冲突、计算结果并且在被质疑时能指出每个结论来自哪里。这就是 SLIDERS 给我们的启示未来的 AI 系统不会只是更长上下文的大模型而会是拥有外部结构化记忆的智能系统。模型负责理解语言数据库负责保存状态SQL 负责确定性计算provenance 负责审计reconciliation 负责把碎片事实整理成可靠知识。如果说 RAG 的第一阶段是让模型能从外部知识库里找资料那么下一阶段就是让模型能把资料整理成结构化世界。真正的瓶颈不是 AI 没看到信息。真正的瓶颈是它看到之后能不能把信息整理成一个不会乱的世界。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】