面经策

如何进行 RAG 调优后的效果评估？请给出真实应用场景中采用的效果评估标准与方法 ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

我坚持一个原则：没有评估体系的 RAG 调优都是玄学，业务方也不会为"感觉变好了"买单。

评估标准分两层：

  • 检索层：命中率（Hit Rate，正确文档是否进 Top-K）、MRR（正确文档排名位置）、召回率。这层决定"找没找到"。
  • 生成层：忠实度（答案是否忠于检索文档，衡量幻觉）、答案相关性（是否答到点子上）、引用准确率（标注的出处是否真实支持答案）。这层决定"答得好不好"。

方法上分三步：

  1. 建评测集：从真实用户日志抽 100~300 条问答对，业务专家标注标准答案和出处文档，这是最值钱的资产，一次投入持续复用。
  2. 自动化评估：用 RAGAS 等工具+ LLM-as-Judge 跑批量回归，每次调参后对比。
  3. 线上闭环：埋点用户点赞/点踩、追问率、人工接管率，作为最终业务指标。

业务话术：向管理层汇报时我会翻译成业务语言——"命中率从 72% 到 85%"意味着"转人工率下降多少、客服成本省多少"，技术指标只有挂上业务指标才有预算价值。

🏗 系统架构师 ​

RAG 评估我坚持分层归因：检索和生成分开评，否则出问题不知道该改检索还是改 Prompt。

检索层指标（离线 + 在线）：

  • Recall@K / Precision@K、MRR、nDCG：基于标注的"query → 相关文档集"金标集，通常建 200~500 条；
  • 在线代理指标：引用点击率、无召回率（Top-K 相关性低于阈值的比例）。

生成层指标：

  • Faithfulness（忠实度，回答是否被检索内容支撑）、Answer Relevancy（答没答到点上）——RAGAS 是主流框架，本质是 LLM-as-Judge；
  • 业务指标：解决率、转人工率、用户点踩率——这才是最终裁判。

方法：上线前金标集回归（每次改分块/换 Embedding/调 Prompt 都要跑），上线后 A/B 测试 + 抽样人工复核（LLM Judge 有偏，需定期用人工校准 Judge 的一致性）。

架构要点：评估要做成 CI 流水线的一部分，指标劣化挡发布；trace 每条请求记录完整链路（query、召回 chunk、Prompt、回答、用户反馈），没有这份数据，RAG 调优就是盲调。预算上金标集建设是一次性投入，产出复用率极高。

💻 全栈开发专家 ​

评估必须分层做，而且要建 50~200 条的 golden set（真实用户 query + 标注的期望答案和相关文档）：

检索层指标（决定上限）：

  • Recall@k：标准答案文档是否出现在 top k；
  • MRR / nDCG：排序质量；
  • 我们卡线是 Recall@5 ≥ 0.85 才允许上线调优。

生成层指标：

  • Faithfulness 忠实度：回答是否忠于检索文档（防幻觉，RAGAS 用 NLI 分解验证）；
  • Answer Relevancy：回答与问题的相关性；
  • 引用正确率：标注的 [1][2] 是否真的支撑该论断。

工具与流程：RAGAS + LLM-as-Judge 自动化跑批，每周回归；线上再加用户反馈（点赞/点踩、追问率、转人工率）做闭环。RAGAS 一行就够：

python
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
print(evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_recall]))

真实经验：评估集要随业务演进持续补坏例（badcase 驱动）；LLM judge 有偏差（偏好长回答），重要结论要抽 10% 人工复核校准；调优时一次只动一个变量（chunk 大小、rerank 模型、prompt），否则归因不了。