RAG 不只看回答：建立可诊断的评估闭环

1. 把 RAG 当成一条链路，而非一个黑盒

一个典型 RAG 系统至少包含：文档处理、分块、向量或关键词索引、召回、可选重排、上下文拼接、模型生成。最终回答差，不等于模型本身差；检索未拿到证据、拿到却没有放进上下文、证据与问题不匹配，都会产生看似“模型幻觉”的结果。

因此评估应拆成两个层面：检索是否找到了有用证据，以及回答是否忠实且充分地使用了证据。

2. 建立一个小而可信的评测集

不要一开始追求几千条数据。先收集几十条真实、高频且覆盖不同难度的问题，并为每条标记：期望答案要点、可接受的证据来源、是否允许“资料不足”的回答。

3. 分层记录指标

• 检索层：目标证据是否进入 Top-K；召回内容是否相关；是否存在重复或过时文档。
• 上下文层：传给模型的文本是否太长、冲突、缺关键段落，或把无关信息挤掉了。
• 生成层：答案是否覆盖关键要点；是否能引用或指向证据；是否引入证据之外的断言。
• 体验层：首字延迟、总耗时、失败率、拒答质量与用户追问率。

4. 不要迷信单一指标

Top-K 命中、相似度分数、人工评分、模型裁判都各有盲点。更稳妥的做法是把自动指标用于趋势监控，把人工抽样用于校准，把失败案例用于迭代。

例如，当回答分数下降时，先检查目标证据是否仍在检索结果中；如果证据存在但答案没有引用，再检查提示词、上下文排序与输出约束。这样每一次回归都能变成可行动的工程问题。

5. 切分策略要用数据验证

按固定长度切分、按标题或段落切分、语义切分都不是天然正确答案。文档结构、问题类型和检索器都会影响结果。应对同一评测集比较不同切分方案的检索命中、延迟与成本，而不是只根据直觉选择“更智能”的切分方式。

6. 每次改动都留下可比较的记录

为索引版本、嵌入模型、检索参数、重排模型、提示词和知识库快照赋予版本号。只有输入与配置可追溯，才能判断一次提升究竟来自哪里，也才能在效果变差时回滚。