RAG 改变了什么，又不能解决什么

例子：根据内部制度回答问题

同事询问报销申请必须在多少天内提交。一个有用的 RAG 系统应找到适用的制度、当前版本以及写明期限的具体段落。模型解释这段内容，并链接到来源。

如果只找到了旧版本或另一个国家适用的制度，就应该说明证据不足。语气肯定、附带引用，却引用了错误制度，仍然是错误答案。这个例子说明：文档的适用范围与文本相似度同样重要。

追踪证据链

典型流程是问题、检索、选取片段、生成答案。每个片段应保留文档标题和位置。找不到可靠依据时，应说明限制，而不是用听起来合理的说法填补空白。

先搭建最小的有效流程

从少量可靠文档开始。提取可读文本，保留标题，把内容切成不会割裂规则和例外的片段。为每段保留文档名称、版本、章节和访问权限。检索若干相关片段，再要求模型根据这些证据回答。

小型文档集合可以先使用关键词检索，确认系统确实有帮助。向量检索适合处理不同措辞，混合检索结合文本与向量结果。起步时不必先搭建大型基础设施，也不必预设一个适用于所有文档的切块长度。

单独评估检索

先检查是否找到了所需片段，再检查片段能否支持答案。片段太短可能失去上下文，太长可能淹没关键信息。应使用有代表性的问题测试切分方式。

把三种错误分开诊断

答案错误时，先检查实际检索到的片段。如果需要的信息根本没有出现，应检查索引、过滤条件和检索。如果找到了规则，却丢失了例外，应检查切块边界与片段选择。如果证据完整而模型仍然曲解，应检查生成步骤。

准备一小组代表性问题：直接提问、换一种说法、需要考虑例外，以及文档中没有答案的问题。记录期望找到的段落和应该拒答的情况。这样可以比较调整前后的效果，而不是凭一次漂亮的演示判断质量。

控制访问权限与成本

在文本进入模型之前，就按用户权限过滤文档。提示词里的警告不能代替访问控制。检索文档内的指令只是文档内容，不应获得修改系统规则的权力。

限制检索片段数量和输出长度，在合适情况下使用缓存，并在文档变更后更新索引。既衡量答案是否有用，也记录花费。增加重排序或另一次模型调用之前，先说明它要解决哪类错误；每个新增步骤也会增加延迟和运行成本。