本文探讨了当前大模型在处理长文档问答任务中的瓶颈，指出单纯依靠增加模型上下文长度并非长久之计。Stanford OVAL提出的SLIDERS系统，通过将文档转化为结构化数据库，并利用SQL进行推理，有效解决了信息组织、合并和计算难题。该系统通过分解抽取和调和重组，克服了传统RAG方法中的“聚合瓶颈”，实现了对超长文档的高效问答。实验证明，即使上下文窗口足够大，结构化推理依然能显著提升准确率。SLIDERS代表了AI系统设计的新范式，即模型应与数据库、工具和结构化状态协同工作，而非单靠增强自身“记忆”。这一思路对推动企业级RAG发展和实现更可靠、可审计的AI应用具有重要意义。
过去一年，大模型圈有一种非常朴素的信仰：只要上下文足够长，很多问题就会自然消失。
最早大家做 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.69，RLM 是 66.46，GraphRAG 是 52.87，普通 RAG 是 42.77。尤其是在 Oolong 这种强调聚合的任务上，SLIDERS 达到 64.67，明显高于 GPT-4.1 的 45.56。
这说明一个重要事实：即使上下文放得下，结构化推理仍然有价值。问题不是“能不能读完”，而是“能不能稳定聚合”。
第二个层次是在超长文档集上测试。论文构建了两个新 benchmark：WikiCeleb100 包含 100 个高访问量名人维基页面，总计 3.9M tokens；FinQ100 包含 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 没看到信息。
真正的瓶颈是，它看到之后，能不能把信息整理成一个不会乱的世界。
最后
对于正在迷茫择业、想转行提升，或是刚入门的程序员、编程小白来说，有一个问题几乎人人都在问：未来10年，什么领域的职业发展潜力最大？
答案只有一个：人工智能（尤其是大模型方向）
当下，人工智能行业正处于爆发式增长期，其中大模型相关岗位更是供不应求，薪资待遇直接拉满——字节跳动作为AI领域的头部玩家，给硕士毕业的优质AI人才（含大模型相关方向）开出的月基础工资高达5万—6万元；即便是非“人才计划”的普通应聘者，月基础工资也能稳定在4万元左右。
再看阿里、腾讯两大互联网大厂，非“人才计划”的AI相关岗位应聘者，月基础工资也约有3万元，远超其他行业同资历岗位的薪资水平，对于程序员、小白来说，无疑是绝佳的转型和提升赛道。
如果你还不知道从何开始，我自己整理一套全网最全最细的大模型零基础教程，我也是一路自学走过来的，很清楚小白前期学习的痛楚，你要是没有方向还没有好的资源，根本学不到东西！
下面是我整理的大模型学习资源，希望能帮到你。
👇👇扫码免费领取全部内容👇👇
最后
1、大模型学习路线
2、从0到进阶大模型学习视频教程
从入门到进阶这里都有，跟着老师学习事半功倍。
3、 入门必看大模型学习书籍&文档.pdf（书面上的技术书籍确实太多了，这些是我精选出来的，还有很多不在图里）
4、AI大模型最新行业报告
2026最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
5、面试试题/经验
【大厂 AI 岗位面经分享（107 道）】
【AI 大模型面试真题（102 道）】
【LLMs 面试真题（97 道）】
6、大模型项目实战&配套源码
适用人群
四阶段学习规划（共90天，可落地执行）
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
硬件选型
带你了解全球大模型
使用国产大模型服务
搭建 OpenAI 代理
热身：基于阿里云 PAI 部署 Stable Diffusion
在本地计算机运行大模型
大模型的私有化部署
基于 vLLM 部署大模型
案例：如何优雅地在阿里云私有部署开源大模型
部署一套开源 LLM 项目
内容安全
互联网信息服务算法备案
…
👇👇扫码免费领取全部内容👇👇
3、这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
