通过找出第一个出错的阶段来调试RAG

当知识助手给出糟糕的答案时，改变提示语是一种简单的应对方式。只有在该模型获得了充分的证据却处理不当的情况下，这种做法才有用。

文档缺失、信息提取不完整以及结论缺乏依据，这些都是不同的故障类型。将它们统一用一个质量评分来表示会降低调试效率，因为该评分无法指示应修改哪一部分。

一个实用的评估流程应当保留从原始材料到用户看到的答案的完整路径。

用证据构建示例，而不仅仅是答案

对于每个测试问题，都要记录能够支撑合理答案的相关段落。同时要明确说明答案必须保留的内容以及应当避免的表述。

一个示例可能如下所示：

{
  "question": "When should this deployment be rolled back?",
  "required_evidence": ["handbook-v3:section-8"],
  "must_include": ["the failed health-check condition"],
  "must_not_claim": ["every warning requires rollback"],
  "answerable": true
}

这种记录比单一的预期句子更有用。它允许多个表述良好的答案存在，同时保留使其正确的条件。

添加语料库无法回答的问题。否则，总是能生成内容的系统可能会显得比那些能够正确承认证据缺失的系统更强大。

首先检查最早的失败点

从源数据开始。索引文本中是否存在所需信息，且该信息是否属于指定的文档？如果不存在，则需修复源数据采集环节。

接着检查检索过程。相关证据是否进入了候选集？如果进入了，它是否通过了过滤、重排序和上下文整合等步骤？这些都是独立的检查点。通过搜索找到但在生成前被移除的段落无法用于支撑最终答案。

最后，检查答案是否准确反映了证据、保留了例外情况，并避免了无依据的陈述？如果上下文足够但答案仍有缺陷，那么对模型的提示或生成行为进行优化便成了合理的目标。

这样的顺序可以防止强大的模型在简单问题上掩盖其检索能力的不足，从而在无法通过已有知识回答的问题上出现不可预测的错误。

使用能够揭示不同类型错误的指标

在选定阈值下的召回率衡量的是被检索出的标记为相关的项目的比例；精确度则衡量返回项目中真正相关的比例。命中率仅判断是否至少出现了一个相关项目，这一标准比恢复多部分答案所需的所有证据要宽松。

排名指标有助于区分处于首位的证据与接近阈值处的证据。但相关性标签需谨慎处理：某篇文本可能仅提及主题，而另一篇则直接回答问题。若将二者视为同等有用，可能会鼓励错误行为。

在生成任务中，需分别评估支持度、正确性、完整性以及引用一致性。答案可能准确复述过时的来源内容，也可能包含正确陈述但缺乏相应证据支持的情况。针对这些情形需要采取不同的修正措施。

在同一实验中保持操作质量一致

除质量评估外，还需记录响应时间、故障情况以及资源使用情况。应保留语料库版本、检索设置、提示词版本及模型标识符，以便进行有意义的比较。

在诊断性能下降问题时，应一次只更改一个主要变量。例如，在保持候选项池不变的情况下，比较开启与关闭重新排序功能的效果。同时更改分块处理、检索方式以及提示词可能会提升得分，但却无法明确问题根源。

自动化评分工具可以帮助批量审查大量输出结果，但需手动检查存在分歧的情况以及敏感的边缘案例。评分工具给出的分数只是另一种具有局限性的衡量标准，并不能替代明确的评估准则。

评估最终呈现给用户的内容

如果界面允许处理过时的请求，正确的后端响应仍可能在错误的查询下被返回。应在端到端测试中包含React搜索交互功能的测试。

评估带来的实际价值在于能明确下一步该采取的行动：修复信息提取、扩展检索范围、保留上下文、修改生成内容或调整呈现方式。这远比仅仅知道某个答案“感觉不对”要有用得多。