上下文永远不够长：面向长文档集合可扩展问答的结构化推理框架 SLIDERS

把长文档拆成结构化关系数据库,用 SQL 而非长上下文做聚合问答,36M 也能跑通

前置知识

检索增强生成 (RAG)

RAG 通过将外部文档切成固定长度的 chunks、建立向量索引，在用户提问时检索 top-k 相似 chunk 并拼接到 prompt 中送给 LLM 生成回答。它是当前最常见的知识接入手段，但当 chunk 数量增多时，'把所有 chunk 输出拼回去'本身又变回了长上下文问题。

SLIDERS 的核心动机正是 RAG 的扩展形态：即使把文档切成 chunk，仍然要在生成阶段重新聚合所有 chunk 输出，这就形成了'聚合瓶颈'。理解 RAG 才能体会为什么 SLIDERS 选择把信息结构化进数据库。

Text-to-SQL 与代码即推理

让 LLM 把自然语言问题翻译成可在数据库/代码解释器上执行的程序，把符号计算（如求和、过滤、连接）外包给确定性引擎，是提升 LLM 在结构化任务上准确率与可审计性的常用做法。代表工作如 Code Interpreter、CHESS、MAC-SQL 等。

SLIDERS 把 Text-to-SQL 作为其问答阶段的执行机制——LLM 生成 SQL，SQLite 执行确定性聚合。作者认为这是 LLM 最擅长的薄弱环节（符号计算）能被机器精准补足的最佳范式。

模式 (Schema) 与关系数据库

关系数据库要求每张表有明确的字段名、类型 (τ)、单位 (u)、量级 (σ) 和规范化规则 (ρ)。这与 LLM 自由文本抽取天然不同：抽取前必须先归纳出 schema，才能保证后续 SQL 能做类型安全的聚合。

SLIDERS 的核心创新之一是 Schema Induction 任务——让 LLM 根据问题+文档元数据自动推导关系模式。理解 schema 的严谨性才能体会为什么需要 schema library、relevance gate、字段归一化等设计。

数据对账 / 实体消解 (Data Reconciliation / Entity Resolution)

在数据库与知识图谱领域，把同一实体的不同表达（如 'J. Smith'、'John Smith'、'Smith, John'）归并、把冲突值选最优、把部分字段补全的过程。传统上靠两两比较，复杂度 $O(n^2)$。SLIDERS 用主键 (Primary Key) 划分将问题降维，并让 LLM 编写 SQL 完成对账。

SLIDERS 把'对账'升级成 LLM 代理任务，利用每条记录自带的 provenance（来源片段）、extraction rationale（抽取理由）和 metadata 作为决策证据。这是本文最关键的方法论创新。

研究动机

真实世界的多文档问答（如金融分析师整合 100 份 10-Q 报表、研究者跨数十篇论文综述）要求 LLM 在超大文档集合上做证据整合与聚合推理。然而，即使 GPT-4.1 已具备 1M token 上下文窗口，金融、生物医学、社会科学场景的文档量仍远超这一上限。现有三大类方法各有硬伤：(1) 单次整篇输入的 LLM 在跨远距离/跨文档推理时频繁出现遗漏、重复、矛盾输出，论文引用 Liu 2023a、Hsieh 2024 等工作量化了这一'迷失在中间'问题；(2) RAG 类方法把文档切成 4K chunk 后检索 top-k，但当答案需要聚合几十甚至上百个 chunk 时，必须把所有 chunk 输出重新拼入上下文，等价于把长上下文问题在生成阶段复现——作者称之为 Aggregation Bottleneck；(3) DocETL、Chain-of-Agents 等多 agent 流水线用 summarization 把 chunk 输出压缩，但仍以文本为中间态，聚合开销随 chunk 数线性增长。在 FinQ100（36M token）上，RAG 准确率仅 5.0%，RLM 在 10 篇子集上也只有 7.4%，正是因为没有任何中间结构能撑住这种规模的全局聚合。

本文的目标是本文的具体目标是设计一个能在任意规模文档集合上完成高质量多文档问答的框架 SLIDERS（Structured Long-document Integration through Decomposed Extraction and Reconciliation System），其核心指标包括：(a) 在能塞进上下文窗口的中等规模基准（≤360K tokens）上超越所有 baseline 平均 6.6 点（已超过 GPT-4.1 直跑）；(b) 在 3.9M token 的 WikiCeleb100 上达到 78.91%，比次优 baseline RLM 高 19.1 点且成本低 13×；(c) 在 36M token 的 FinQ100 上达到 55.22%，比 RAG/RLM 高 30+ 点。同时要求抽取过程具备完整 provenance 可审计、LLM 生成 SQL 可执行、整体流水线对底层 LLM 选择具有鲁棒性。

与已有工作不同的是，SLIDERS 的独特切入角度是把'信息表示'与'推理'解耦——先用 LLM 把文档抽取进一张关系数据库（带 provenance 的结构化中间态），再用 LLM 生成 SQL 在数据库上做符号推理。区别于 DocETL 等同样基于 schema 的工作，SLIDERS 额外引入一个 Data Reconciliation 阶段：每条抽取记录同时携带来源 span（provenance）、抽取 rationale 与文档级 metadata，reconciliation agent 在主键划分的分组内编写 SQL 完成去重 (deduplication)、冲突解决 (conflict resolution)、合并 (consolidation) 三类操作，将局部的、噪声的、可能冲突的抽取结果合并成全局一致的近规范行（约每主键 1 行）。这是首次将 provenance 与 extraction rationale 视为信息抽取对账的一等信号，也是首次在百万到千万 token 级别上验证'结构化中间态 + SQL 推理'范式的可扩展性。

核心方法

SLIDERS 的整体思路可一句话概括：把多文档问答这件事拆成'建库'与'查库'两个阶段。直觉上，与其让 LLM 在 prompt 里看完全部文档再做心算，不如把文档里的事实预先抽到一张可查询的表中，所有聚合、过滤、比较都通过 SQL 完成，LLM 只负责'把问题翻译成 SQL'和'审阅最终结果'。技术上 SLIDERS 由五个任务串联：(1) Contextualized Chunking——给文档加元数据后切块，确保每块自带足够上下文；(2) Schema Induction——让 LLM 根据问题与文档类型从 schema library 中自动选择并生成关系 schema（带类型、单位、量级、规范化规则）；(3) Structured Extraction——每个 chunk 经过 relevance gate 后用 in-context learning 抽出带 provenance 的行；(4) Data Reconciliation——按主键分组后用 SQL-coding agent 完成去重/冲突解决/合并；(5) Question Answering——QA agent 在已对账的数据库上迭代生成并执行 SQL，得到最终答案。前四步是一次性投入的离线成本，第五步可以对新问题反复复用，摊薄成本。

SLIDERS 与已有 chunking-based 方法（如 DocETL、Chain-of-Agents）的本质区别有两点。第一，中间态从非结构化文本变成关系数据库，这一步把'聚合瓶颈'彻底转化为'数据库查询'：无论 100 篇还是 1 万篇文档，只要 schema 设计合理，SQL 在 SQLite 上的执行时间是多项式级且确定性的，而不再受 LLM 注意力衰减影响。第二，把 provenance + extraction rationale 提升为一等信号驱动对账。已有对账方法（如传统 entity resolution）要么靠两两字符串相似度、要么靠 embedding 聚类，SLIDERS 则让 LLM agent 直接读 quote 原文、抽取理由和文档 metadata，然后撰写 SQL 选择更精确/上下文支持更强的值或合并部分字段。这一设计既避免 $O(n^2)$ 比较，又让每一步决策都可追溯到原始文本与推理理由，是审计与错误定位的关键。

方法步骤详情

Contextualized Chunking 阶段：每个文档 $d$ 先被赋予元数据 $m_d = (m_d^G, m_d^L)$，其中 $m_d^G$ 由 LLM 生成的标题与简要描述构成（提供全局上下文），$m_d^L$ 抽取自结构信号如章节标题、表格标题、图表说明。SLIDERS 按语义/结构边界（如不切到表格中间）切成 chunk $c$，每个 chunk 自带 doc id、页码、结构标签。Schema Induction 阶段：输入问题 $q$ 与元数据 $M$，从 schema library 中按问题类型（Ordering/Multiple Choice/Others）与文档类型（Narration/Policy/Dataset/Others）选取指南，LLM 产出 schema $S = \{S_1, ..., S_k\}$，每张表 $S_i = \langle s_n, f_1, ..., f_n \rangle$，字段 $f = \langle f_n, d, \tau, u, \sigma, \rho \rangle$ 同时记录名称、描述、类型、单位、量级与规范化规则。Structured Extraction 阶段：每个 chunk 先经过 relevance gate $R(q_e, c, m_c, S)$ 判断是否相关（只有 0.4% 假阴性，516 个 chunk 中拒绝 282 个仅错放 1 个），通过后用 in-context learning 抽取记录，输出 $SE(q_e, c, m_c, S)$，每个字段值附带原始引用 $p$ 与抽取理由 $r$。Data Reconciliation 阶段（Algorithm 1）：Phase 1 选主键——LLM 看 schema+样本行+理由后选主键，三次取多数投票；再做主键实体消解——文档内逐列用 LLM 判断语义等价，文档间用 LLM 生成 SQL 做归一化；最后 GROUP BY 主键形成对账分组。Phase 2 每个分组由 reconciliation agent 循环：先 SELECTRECONOP 决定去重/冲突解决/合并中的一种操作，再 RECONCILEGROUP 写 SQL 应用操作，直至该组无需再改；最后对非主键列再做一次实体消解。QA 阶段：QA agent 拿到 schema+已对账数据库，反复 (1) 生成 SQL、(2) 执行、(3) 审视结果、(4) 必要时改写查询，直到得到满意答案。

技术新颖性

SLIDERS 的技术新颖性体现在四个层面。技术路线层面，首次把'抽取到关系数据库 + SQL 推理'作为可扩展多文档问答的通用框架在百万至千万 token 上验证，区别于 DocETL 等只用 schema 做抽取而不做显式对账的工作。算法层面，将 provenance、extraction rationale 与 metadata 联合作为 reconciliation agent 的决策依据，提出按主键分组的并行化对账策略，避免传统 entity resolution 的 $O(n^2)$ 开销；reconciliation 平均仅 1.28 次迭代每组即可收敛。系统层面，引入 relevance gate 抑制在无关 chunk 上的幻觉（结构化抽取的 strict schema 会放大幻觉），实测假阴性仅 0.4%。评测层面，新发布 WikiCeleb100（100 份 Wikipedia，3.9M tokens，22 道聚合题）与 FinQ100（100 份 SEC 10-Q，36M tokens，25 道长期借款题）两个超长文档基准，把研究社区对长文档 QA 的关注从'塞进 1M 上下文'推向'36M 也能答'的量级。

**Figure 3**: SLIDERS overview showing the process of (1) Contextualization of chunks, (2) Inducing the schema, (3) Structured Extraction, (4) Data Reconciliation, and (5) Question Answering over the final database.

实验结果

在 ≤360K token 的 long-context 基准上（Table 3），SLIDERS（GPT-4.1 + GPT-4.1-mini）在 FinanceBench、Loong、Oolong 三个基准上分别取得 89.33%、78.57%、64.67%，平均 75.56%，超过最强 baseline GPT-4.1 直跑的 82.00%/76.74%/45.56%（平均 68.69%）共 6.87 点，超过 RAG（42.77）、LongRAG（51.03）、GraphRAG（52.87）、DocETL（62.44）、Chain-of-Agents（47.62）、RLM（66.46）等所有 baseline；paired t-test 相对最强基线 $p < 0.005$。Loong 子领域分解显示 SLIDERS 在 Chinese Legal、English Finance、Chinese Finance、English Papers 分别为 59.9%/74.8%/89.2%/91.3%，只在 Chinese Legal 这种短文本分类任务上略输 baseline（chunking 与 reconciliation 引入开销但无收益）。在 3.9M token 的 WikiCeleb100 上，SLIDERS 78.91% vs RAG 31.41%、LongRAG 43.20%、GraphRAG 48.59%、RLM 59.80%，提升 19.1 点同时比 RLM 便宜 13×；在 36M token 的 FinQ100 上，SLIDERS 55.22% vs RAG 5.00%、LongRAG 28.87%（GraphRAG/RLM 因成本 ≥ $2000 未跑全量），10 篇子集上 RLM 仅 7.4% 而 SLIDERS 65.1%。消融实验（Table 4，220 个 validation 任务）显示去掉 chunking 准确率从 74.79 降到 60.34（Oolong 上从 64.67 直接崩到 40.00），去掉 reconciliation 从 74.79 降到 72.71（FinBench 76.70→80.00 范围内波动最大），再去掉 SQL-based QA 降到 70.74，证明三块缺一不可。Schema Induction 在 GPT-4.1-mini / 4.1 / 5 三档模型上（schema 复杂度从 1.0 表 3.3 字段到 1.54 表 13.3 字段，4× 跨度）下游准确率波动仅 2-7 点，鲁棒性良好。Question type 分解（Figure 4）显示 Oolong 的 Counting 类（需精确数字推理）只有 60.3%，是模型自身能力瓶颈；Loong Legal 全程低于 73%，验证了该场景下结构化开销不划算。成本方面 SLIDERS 平均 $0.76/问题，FinQ100 全量 $34.63 vs 假设无限上下文 GPT-4.1 估算 $1800（52× 便宜），WikiCeleb100 $13.10 vs $171.60（13×）。

**Table 1**: Executor agents for data reconciliation.

**Table 3**: Performance comparison across long document QA benchmarks.

**Table 4**: Ablation study on the val set, removing chunking, reconciliation, and SQL-based QA individually.

**Table 5**: Accuracy across schema-induction models.

**Table 6**: Manual evaluation on 50 questions each.

**Figure 4**: Model accuracy across difficulty levels and question types.

**Figure 5**: Accuracy vs. token length across benchmarks.

**Figure 6**: Analysis of the reconciliation agent across seven datasets.

查看结构化数据

任务	指标	本文	基线	提升
FinanceBench (单文档财务 QA)	Accuracy (LLM-as-judge)	89.33	GPT-4.1: 82.00; Qwen3.5-122B: 84.67; RAG: 62.67	+5.33 over GPT-4.1, +4.66 over Qwen3.5-122B
Loong (多文档 QA, ~11 文档/题)	Loong 官方 LLM-judge 准确率	78.57	GPT-4.1: 76.74; GraphRAG: 61.28; RLM: 72.64	+1.83 over GPT-4.1, +5.93 over RLM
Oolong-Synth 256K (聚合推理)	Oolong 官方数值偏差分数 + LLM-judge	64.67	GPT-4.1: 45.56; DocETL: 49.00; RLM: 51.42	+19.11 over GPT-4.1, +13.25 over RLM
WikiCeleb100 (3.9M tokens, 100 Wikipedia)	LLM-as-judge Accuracy	78.91	RLM: 59.80; GraphRAG: 48.59; LongRAG: 43.20; RAG: 31.41; GPT-4.1: N.A. (超上下文)	+19.11 over best baseline RLM, 13× cheaper
FinQ100 (36M tokens, 100 SEC 10-Q)	LLM-as-judge Accuracy	55.22	LongRAG: 28.87; RAG: 5.00; RLM (10 docs): 7.4	+26.35 over LongRAG, +47.82 over RAG on full set
Loong 子领域平均 (ZH Legal, EN/ZH Finance, Papers)	Loong 子领域准确率	59.9 / 74.8 / 89.2 / 91.3	GPT-4.1: 略优 ZH Legal，其他领域低于 SLIDERS	除短文本分类 ZH Legal 外全部超越 GPT-4.1

局限与改进

作者明确承认四点局限性：(1) 强依赖 schema induction 来约束抽取，对高度主观或抽象的跨文档推理任务（如'哪篇论文更具开创性'）不适用，因为这类问题难用关系模式表达——Table 5 也显示 schema 复杂度从 1.0 表 3.3 字段到 1.54 表 13.3 字段，4× 差距但准确率波动 2-7 点，复杂 schema 的边际收益递减；(2) 多阶段串行 LLM 调用导致延迟 2.6-3.0 分钟（Loong/FinanceBench），不适合实时场景；(3) 评测用 LLM-as-judge，judge 标准差 FinanceBench 0.47、Loong 0.31、Oolong 1.02、WikiCeleb 0.21、FinQ100 0.38，虽人工核对 100 题 Cohen's κ=0.758（substantial）但仍有噪声；(4) FinQ100 上 55% 准确率不足以让高风险金融分析完全自动化，作者建议 human-in-the-loop。我的独立观察还包括：(a) SLIDERS 在 WikiCeleb100 上把 685 行原始抽取压缩到 105 行（主键级别）后才得到 78.9% 准确率，说明 reconciliation 几乎是该基准的胜负手——如果主键选错整个流水线会崩塌；(b) Chinese Legal 基准准确率低于 GPT-4.1 直跑，说明当 chunk 数不足以触发聚合瓶颈时 SLIDERS 的结构化开销是纯成本；(c) 仅在 Oolong Counting 类 60.3% 准确率暴露了'LLM 生成 SQL 出错'作为新的失败模式——这与 DocETL 等暴露的失败模式不同，需要新工具调试。

独立分析的弱点

独立观察到的弱点与改进方向：(a) 主键选择的脆弱性——Algorithm 1 的 Phase 1 用 LLM 三次投票选主键，但若文档集主键不止一个候选（如既可按'公司名'又可按'财报年度'消重），当前策略会强制选一个；改进方向是允许 LLM 输出主键组合 + 加 fallback 规则。(b) reconciliation agent 的 SQL 错误无法被自动捕获——如果 SELECTRECONOP 选错操作或 RECONCILEGROUP 写错 SQL，结果会污染全库；改进方向是在 apply SQL 前加入 dry-run 验证（如在小样本上对比前后分布），或在事后用一致性问题检测器反查异常。(c) relevance gate 仅用单次 LLM 判断，缺乏对照实验验证不同 prompt 下的稳定性——0.4% 假阴性是基于 516 chunk 子集，对长尾文档可能放大。(d) 当前 reconciliation 三类操作（去重/冲突/合并）无法处理更复杂的情况，比如'同一公司不同年度报表的同一字段（如 long-term debt）应被视作时间序列而非冲突'，需要引入 temporal 主键或版本控制。(e) Chunk-level 抽取仍依赖 LLM 一次性输出 JSON，对超长表格（如 10-Q 附录里的几十行明细）可能出现截断或字段错位，改进方向是 streaming extraction 或基于 layout 的多模态抽取。(f) SQL 生成阶段对 Counting 类问题准确率仅 60%，说明 LLM 写聚合 SQL 的能力本身是瓶颈，可考虑外部求解器或代码-自然语言混合模板辅助。

未来方向

作者明确提出的未来方向：(1) 对 FinQ100 这类高风险场景推进 human-in-the-loop 验证闭环，provenance 可让审核员高效核对每条抽取——已通过 410 事实核对验证 provenance 99.03% 准确。(2) 把同一文档集合的抽取成本摊到多轮问答上（已展示的 offline 16 分钟 + online 25 秒/问的 amortized 模式）。(3) 用 SLIDERS 思路拓展到非 QA 任务，已在多文档摘要案例研究中验证：自动诱导 5 张表（PaperSummary / Contributions / Methods / Findings / Conclusions），抽取 117 条记录后聚合。基于成果可延伸的方向还包括：(a) 跨模态——把表格、图像 OCR 也统一进同一张关系表，因为金融 10-Q 中的图表常含关键数字；(b) 增量更新——当前流程对新增文档需重跑 reconciliation，可设计增量主键合并算法；(c) 自动化模式发现——超越 schema induction，从抽取结果中反向学习更优字段（类似知识图谱本体对齐）；(d) 接入 graph + SQL 混合推理——GraphRAG 在 WikiCeleb100 上仅 48.59% 但补足了'实体间关系'，可与 SLIDERS 的表结构互补；(e) 把 structured reasoning 扩展到代码仓库分析、法律卷宗、临床记录等 schema 友好领域。

复现评估

复现评估整体良好：(a) 代码与 demo 已开源：https://github.com/stanford-oval/sliders 与 https://sliders.genie.stanford.edu/，仓库应包含五个任务的 prompt 模板、schema library、reconciliation agent 等关键实现。(b) 数据集方面，FinanceBench、Loong、Oolong 公开可下载，新提出的 WikiCeleb100 与 FinQ100 应随论文附录 B 一同释出。(c) 算力要求中等：主实验用 GPT-4.1/GPT-4.1-mini 与 Qwen3.5-122B-A10B，运行 FinQ100 全量约 $34（API 成本），单问题平均 $0.76；开源 Qwen 配置可本地化部署，参考其论文给出的 offline 16 分钟/100 文档时间。(d) 复现难度：中等偏上，需要同时配置 GPT-4.1 API、SQLite/PostgreSQL、文本分块器；pipeline 有 5 个串联阶段（chunking/schema/extraction/reconciliation/QA），每阶段 prompt 与 schema library 都需要准确还原；recommend 用其 val set（220 题随机样本）先验证 reproduce Table 4 的消融数字。(e) LLM-as-judge 的方差需要自行做三次重复测量以保证评测稳定；judge 模型与被测模型都用 GPT-4.1 可能引入 bias，作者用 50 题人工标注做 Cohen's κ=0.758 验证，但完整复现实验最好复用其人类标注子集。

上下文永远不够长：面向长文档集合可扩展问答的结构化推理框架 SLIDERS Contexts are Never Long Enough: Structured Reasoning for Scalable Question Answering over Long Document Sets