可追溯文档问答Agent-工程化指南

RAG 应用最让人不放心的地方，是它给出来的答案看起来合理，但你无法验证。上传一份长 PDF，AI 给出的引用页码点过去一看，确实有那句话，但表格里的数字配错了列头，引用页码正确但答案依然是错的。

文档问答 Agent 的核心挑战不是让模型更聪明，而是让答案可审计——这就是 Grounded 工程的含义。

很多人以为 RAG 系统的瓶颈在模型或 prompt。基础文本提取会把双栏论文串读、把财务表格打散成无主数字、对扫描件完全无能为力。答案质量的上限在管道最前端就定死了，多数人在后端调 prompt、换模型，方向本身就偏了。

工程上的解法是"云端解析一次，本地无限迭代"。云端解析用 LlamaParse 生成布局感知的结构化文本，保留页码元数据；文件哈希缓存，避免重复消耗解析额度。本地层用 ollama 的 nomic-embed-text 做嵌入，LlamaIndex 向量索引持久化，检索 top-4 片段，再用本地 qwen3:4b-instruct 生成回答。

引用层：粒度是个权衡

引用块设为 512 字符：块越小引用越精确，但推理上下文越破碎。这个参数需要按文档类型实测。LlamaIndex 的 CitationQueryEngine 把上下文切成编号块，强制模型以 [1]、[2] 格式内联引用，这是把"答案可追溯"落到工程层面的关键一步。

但引用 ≠ 正确。如果解析时表格数值配错了列头，即使引用页码完全正确，答案依然是错的。所以"可追溯"不等于"可信"。解法是把验证 UI 当作诊断工具：页码、原文、相关性分数全部可见，让任何一次失败都能被归因到解析、检索、生成三段之一。这是把黑盒 RAG 变成可调试管道的思路。

三段管道：每段都能独立失败

一个文档问答 Agent 的失败可能发生在三段中的任意一段：

解析段负责把 PDF、Word、扫描件等原始文档转成结构化文本。这段最容易出问题——双栏论文被串读、财务表格被打散、扫描件识别不出表格结构。问题出在这里时，后面再调 prompt、换模型都没用。

检索段负责把用户的问题和文档库里的相关片段匹配上。向量检索、BM25、混合检索各有适配场景，单一策略很难覆盖所有问题形态。

生成段负责把检索到的证据组织成人话回答。这一段出错往往体现在幻觉——模型引用了不存在的段落，或者把检索结果拼接成了看似合理但其实跑偏的答案。

把失败归因到具体哪一段，是工程化 RAG 和"调 prompt"式 RAG 的根本区别。

验证 UI：把黑盒变白盒

构建 UI 的时候需要展示四样东西：页码、检索到的原文、查询词高亮、相关性分数。这四样东西缺一不可。

页码给用户一个物理定位，原文让用户能逐字核对。查询词高亮让用户看到模型到底"看到"了什么；相关性分数让用户判断检索结果的质量，不是每个返回的片段都该被引用。

任何一个维度的缺失都会让验证变成形式。用户对单一指标的信任度是有限的，需要多维度交叉验证。这也是为什么 LLM-as-a-judge 在 RAG 评估里经常失效——它只能给出一个总分，看不到失败发生在哪一段。

几个反直觉的工程结论

结论一：解析投入的回报远高于模型调优。 把 80% 的工程精力放在解析层、把 20% 放在后端 prompt 和模型选型上，是更合理的资源分配方式。一份高质量的结构化文本能让下游的所有环节都受益。

结论二：引用粒度是个权衡。 引用块越小、引用越精确，但模型的推理上下文也越破碎。512 字符是一个常见起点，但实际项目里需要根据文档类型做实测。技术报告和财务报表的最佳粒度可能差好几倍。

结论三：可追溯不等于可信。 用户看到页码、看到引用，会倾向于相信答案；但如果解析层有 bug，引用页码对应的那段文字本身就是错的。"可追溯"是工程要求，"可信"是业务要求，两者之间需要验证 UI 来连接。

我的评价

文档问答 Agent 的工程化，核心是把"信任"这件事拆解成可以单独验证的环节。解析、检索、生成这三段，每一段都有独立的失败模式，需要独立的诊断工具。

值得注意的一点是：很多团队在搭建 RAG 时，会把主要精力放在 prompt 工程和模型选型上，但实际收益的天花板在解析层就定死了。这条工程教训来自大量项目的复盘，值得在文档类 RAG 项目里反复强调。

反面观点

也有团队认为"可追溯"是被高估的工程目标。理由是：用户在日常使用中并不会逐字核对引用，他们要的是一个能用、好用的答案，不是一个工程上完美的答案。这部分用户体验研究和工程严谨性之间存在张力，工程团队需要找到一个平衡点，而不是把可追溯性推到极致。

a4 关键素材

• • 解析是天花板，而不是模型：基础文本提取会把双栏论文串读
• • 引用粒度设为 512 字符，块越小引用越精确但推理上下文越破碎
• • 引用 ≠ 正确：解析时表格数值配错列头，答案依然是错的
• • 验证 UI 展示：页码、检索原文、查询词高亮、相关性分数
• • 工具栈：LlamaParse + nomic-embed-text + LlamaIndex + qwen3:4b-instruct
• • CitationQueryEngine 强制模型以 [1]、[2] 格式内联引用
• • 解析 80% 精力 vs 后端 20% 精力的资源分配

关键补充

进一步补充几个关键细节,帮助读者更好理解相关话题。

细节一,追溯粒度。文档问答 Agent 的追溯粒度选择需要平衡性能和准确性。

细节二,索引效率。索引效率和查询性能密切相关,需要综合考虑。

细节三,场景适配。不同应用场景的追溯要求有所不同,需要灵活适配。

细节四,持续改进。基于用户反馈的持续改进是质量提升的关键。