很多人做文档问答，第一反应是去调提示词。但有一份工程指南给出了一个反常识的判断：解析质量才是RAG的天花板，后端的提示词调优，很难弥补源头数据的缺陷。

这份指南把RAG的构建拆成了三个环节：云端解析、本地索引、引用验证。它想说的核心只有一件事——把RAG当成一条可调试的管道，而不是一个黑盒。

解析错了，后面全错

指南里点出了两类典型的解析事故：串读，以及表格结构丢失。这类错误一旦发生，会直接导致前端生成失败。

原因不难理解。检索和生成都建立在解析出来的文本之上，如果文本本身就是错的，模型再强也只能在错误的地基上作答。这时候去改提示词，等于在漏水的桶上换水龙头。

让回答变成可审核的证据

指南提出的第二个关键设计是引用机制。具体做法是给出引用页码和原文片段，让模型的回答可以被验证。

这个动作的价值在于降低用户的信任门槛。模型输出不再是一段无法追溯的话，而是一份可以核对的证据。用户能点开原文，自己判断这句话是不是从文档里来的。

把失败案例归因到具体环节

第三个环节是验证UI。指南把它定位成诊断工具，用来把失败案例归因到解析、检索或生成这三个环节中的某一个。

这一步的意义在于思维方式的转变。黑盒实验里，回答错了就是错了，你不知道该改哪里；而在可调试的管道里，错误会被定位到具体环节，修改也就有了方向。

指南把这种能力称为「可审计性」，并认为它是从黑盒实验走向稳健生产环境的关键。整套思路可以概括为三句话：

  • 解析质量决定输出天花板
  • 引用机制让回答可验证
  • 验证UI让失败可归因

对正在做文档问答的团队来说，这份指南提醒的其实是一个顺序问题：先把解析和引用做扎实，再去谈提示词怎么写得更好。