AI 长文档问答为什么答不准：分块、表格解析与引用溯源的三道关

云上的幻象2026-10-148 分钟阅读2,900 字100

100%

长文档问答答不准，八成不是模型能力不够，而是检索链路在三处掉了链子：切分把语义切断、 PDF 表格被解析成一堆散字、答案没有引用无法验证。结论是按「先修解析、再做上下文化检索、最后强制引用溯源」的顺序处理，这个顺序对准确率的提升最明显，反过来做则基本白费。

先判断：你到底需不需要检索

在很多团队里，RAG 是被过度使用的。 Anthropic 在介绍 Contextual Retrieval 时给过一个很实用的界线：知识库小于 20 万 token（约 500 页材料）时，直接把全部内容放进提示词，不需要任何检索，配合提示缓存还能大幅降本。检索是为了解决”放不下”，不是为了”显得高级”。

判断标准很简单：把你的文档总量换算成 token（中文大致按 1 字 ≈ 1.5 token 估），小于 20 万就走长上下文路线，大于 20 万再上检索。跨越这条线之前硬上向量库，只会引入一堆检索错误。

第一关：解析，决定了准确率的上限

检索做得再好，也找不回解析阶段丢掉的内容。 PDF 解析的四个高发问题：

问题	表现	处理办法
表格塌陷	表格变成按行拆开的纯文本，单元格关系全丢	用专门的表格解析（如 PDF 表格抽取库），把表格转成 Markdown 表或 CSV 单独存储
页眉页脚污染	每一页都带一遍公司名、页码，检索时相似度虚高	按坐标去重：出现位置高度一致且全篇重复的行直接剔除
双栏错序	左右两栏被按物理行混在一起，读不通	按 x 坐标切栏，先左栏后右栏拼接
扫描件无文本层	抽出来是空字符串	先 OCR，并把 OCR 置信度低的页标记出来人工复核

其中表格是最容易被低估的一项。财报、合同、技术参数表这类文档，关键信息几乎全在表里，一旦塌陷，后面所有优化都是在错误数据上做文章。

第二关：切分与上下文化检索

传统 RAG 把文档切成几百 token 的小块后，单个块往往缺少上下文。典型例子：一个块里写着「公司营收环比增长 3%」，但没说是哪家公司、哪个季度，既检索不到，检索到了也没法用。

解法：给每个块补一段上下文

Contextual Retrieval 的做法是，在切好块之后，用模型为每个块生成一段 50–100 token 的摘要，说明这个块出自哪篇文档的哪一部分，再把”摘要 + 原文”一起送去嵌入和建 BM25 索引。官方数据：

仅用 Contextual Embeddings + Contextual BM25：检索失败率下降 49%
再叠加重排序（rerank）：下降 67%

检索环节的推荐组合（点击展开）

双路召回：向量检索负责语义相似，BM25 负责精确词匹配。用户查「错误码 TS-999 」这类带唯一标识的问题时，向量检索几乎必失手，只有 BM25 能命中。
融合去重：两路结果用 RRF（倒数排名融合）合并，而不是简单拼接。
重排序：取融合后的 top 50，用小模型精排出 top 5 再送给生成模型。这一步的性价比通常高于换更大的生成模型。
块大小：中文文档建议 300–500 字一块、重叠 15% 左右，具体参数参考RAG 文档切分的四种策略。

第三关：强制引用溯源

这一关既提升准确率，也解决”不敢信”的问题。做法分两层：

生成侧：先引用后回答

Anthropic 的长上下文提示建议很直接：对于长文档任务，先让模型引用文档中的相关原文，再执行任务。这会迫使模型先定位再作答，实测在复杂多文档输入下，把查询放在提示末尾可以带来最高 30% 的质量提升。提示词结构建议是「长文档放最上面 → 指令 → 查询放最后」。

产品侧：答案必须带出处

把引用做成硬约束，而不是可选项：

请只根据提供的文档回答，并遵守：
1. 先输出引用的原文片段及其出处（文档名 + 章节/页码）；
2. 再基于引用内容作答；
3. 若文档中找不到依据，直接回答"文档中未提及"，不要推测。

第三条尤其重要——它把”幻觉式回答”变成了可观测的”拒答率”指标，你可以据此判断是检索没召回，还是文档确实没覆盖。

不要只看答案对不对，要同时统计”拒答率”。一个永远有答案的系统，往往是在编；有 10%–20% 明确拒答的系统，反而更可信。

怎么评估：造一份自己的评测集

准确率优化没有评测集就是盲调。最省力的做法是让模型帮你造题：把文档切段，让模型为每段生成若干选择题（1 个正确 + 3 个干扰项），再把这些段落随机拼成”长文档”来测试召回。造题时注意三点：

剔除模型不看文档也能凭常识答对的题——那测的是记忆不是检索。
剔除模型在短上下文下也答错的题——那说明题本身有问题。
题目要求指明具体文档/章节，否则拼成多文档后无法确定它问的是哪一份。

三种典型场景的取舍

场景	推荐方案	关键配置
单份合同 / 论文问答	长上下文直塞 + 引用	文档置顶、查询置尾、强制引用
产品手册 / 知识库（数十到数百篇）	上下文化检索 + 双路召回	块 300–500 字、重叠 15%、 top 50 重排到 5
法规 / 财报（表格密集）	表格单独抽取 + 结构化存储	表格转 CSV 单独建索引，与正文分开召回

如果你的场景还需要跨会话记住用户偏好或历史结论，那就超出了检索的范畴，属于记忆系统的设计问题，可以参考AI Agent 记忆的长短期架构。而对检索增强本身还不熟悉的读者，建议先看一遍RAG 检索增强生成的基本原理，再回来看这三道关会更顺。

是不是换成更大的模型就能解决答不准？

大多数情况下不能。如果检索阶段根本没召回相关块，再大的模型也只能编。应按解析 → 检索 → 生成的顺序排查，通常修好前两环的收益远大于换模型。

块切多大合适？

没有通用值。中文文档从 300–500 字、重叠 15% 起步，然后用评测集跑一遍，看调整块大小后召回率是升是降。语义完整性比字数更重要：尽量在标题、段落边界切，不要从句子中间切断。

向量检索和关键词检索只能二选一吗？

不建议二选一。向量检索擅长语义相近，关键词检索（BM25）擅长精确匹配编号、专有名词、错误码。二者融合后的召回率明显高于任何单一路，这是当前的主流做法。

PDF 里的表格怎么单独处理？

用表格抽取工具把表格转成 Markdown 或 CSV，作为独立条目存储并单独建索引，检索时与正文分别召回后合并。让表格和正文混在同一块里，几乎必然在切分时被截断。

答案带引用的开销会不会很高？

会增加少量输出 token，但换来的是可验证性和更低的幻觉率。对问答类产品来说，引用是让用户敢于采纳答案的前提，这个开销通常值得。

一句话收尾：长文档问答的准确率瓶颈，90% 在模型之前。先把解析修干净、给每个块补上上下文、强制模型先引用再回答，这三步做完，多数系统不需要换模型就能明显变准。