RAG系统上线三个月后最常见的困境用户反馈答得还行但你不知道是检索对了还是模型硬编的。传统QA只管功能跑通RAG的质量问题出在两层——检索层拿没拿到对的资料生成层有没有照着资料说。评测必须拆开打检索层看上下文精确率Context Precision和上下文召回率Context Recall生成层看忠实度Faithfulness和答案相关性Answer Relevancy。工具直接用 Ragas 或 DeepEval别自己造轮子但指标的计算逻辑必须吃透否则阈值怎么定、分数怎么解读都是黑盒。跑通之后把评测脚本接进 CI每次改 prompt、换 embedding、调 chunk 策略都能拿到回归数据。指标先分层检索归检索生成归生成RAG 评测最常见的错误是把所有问题都归到模型不行。实际上不同层的问题要用不同指标暴露指标所属层回答的问题计算方式上下文精确率 Context Precision检索检索结果里有多少是真正相关的相关文档排前面了吗逐位置看命中情况按位置加权上下文召回率 Context Recall检索该拿到的资料拿全了吗标注的相关文档中被检索到的比例忠实度 Faithfulness生成回答有没有超出上下文瞎编回答拆成声明逐条核对上下文支持答案相关性 Answer Relevancy生成答的是用户问的吗用 LLM 打分或生成反向问题比对检索层和生成层的分界线很明确检索层指标不碰 LLM 的输出只看上下文窗口里有什么生成层指标才看模型基于这些上下文说出了什么。定位问题的时候先看检索层再看生成层——检索层挂了生成层分数再高也是空中楼阁。忠实度的实现原理声明拆解 逐条核验忠实度是整个 RAG 评测里最值得吃透的指标因为它直接对应幻觉检测。实现思路分三步让 judge 模型把回答拆成独立的原子声明claim每条只表达一个事实对每条声明判断它是否被给定的上下文支持支持 / 不支持 / 上下文无相关信息忠实度 被支持的声明数 / 总声明数。伪代码长这样def faithfulness(answer: str, contexts: list[str]) - float: claims judge_llm( f把下面的回答拆成原子声明每条一行只输出声明本身\n{answer} ).splitlines() supported 0 for claim in claims: verdict judge_llm( f判断声明是否被上下文支持。只输出 SUPPORTED / NOT_SUPPORTED / fNO_INFO。\n上下文{contexts}\n声明{claim} ) if SUPPORTED in verdict: supported 1 return supported / len(claims) if claims else 1.0这个设计的巧妙之处在于把这段回答对不对这种模糊问题拆成N 个小判断题。判断题比整体打分稳定得多而且声明级别的结果可以直接喂给调试流程——哪条声明挂了就知道是检索漏了资料还是模型在编定位成本大幅下降。注意 NO_INFO 这个第三分类不能省。上下文里根本没提这件事和上下文明确矛盾是两种完全不同的 failure mode前者是检索召回不足后者是模型无视上下文。混在一起算你会分不清该优化检索还是换模型。检索层指标命中位置和覆盖度上下文精确率看的是排序质量。假设一个 query 检索出 5 个 chunk标注其中 chunk 2 和 chunk 4 相关那么def context_precision(relevant_positions: list[int], k: int 5) - float: # relevant_positions: 相关文档在检索结果中的位置从1开始 score 0.0 for i in range(1, k 1): if i in relevant_positions: # 位置越靠前分母越小贡献越大 score len(relevant_positions) / i return score / len(relevant_positions)位置 2 的命中贡献是 2/21.0位置 4 的命中贡献是 2/40.5总分 1.5/2 0.75。也就是说相关文档排得越靠前分数越高——这个指标直接反映 reranker 和混合检索的调优效果。上下文召回率则简单粗暴标注的相关文档里检索到了多少。它暴露的是切分策略和 embedding 的问题——chunk 切太碎语义被截断相关文档就召回不全。实践中这两个指标要一起看精确率低召回率高说明检索结果里噪声多该上 reranker精确率高召回率低说明该调 chunk size 或换 embedding 模型。用 Ragas 落地 接进 CI原理清楚之后落地直接用 Ragas 的evaluate接口把 metrics 显式传进去from ragas import EvaluationDataset, evaluate from ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall, ) dataset EvaluationDataset.from_dict({ user_input: [我们的退款政策是几天], response: [根据文档退款申请需在购买后7天内提出。], retrieved_contexts: [[退款政策购买后7天内可申请退款...]], reference: [退款申请应在购买后7天内提出。], # context_recall 需要 }) result evaluate( datasetdataset, metrics[faithfulness, answer_relevancy, context_precision, context_recall], ) print(result)几个落地细节reference 列只有 context_recall 需要。如果只关心生成质量可以只跑 faithfulness answer_relevancy减少标注成本judge 模型用比你线上模型强的。线上用 7B 小模型judge 就用 GPT-4o / Claude 级别的judge 太弱会把噪声带进指标里结果带个 seed 重跑三次看方差。LLM-as-judge 天然有抖动方差超过 0.05 说明测试集或 judge prompt 有问题。测试集怎么来三条路线上真实 query 采样最靠谱但量少、用 LLM 基于知识库文档合成量大注意别让合成 query 和文档措辞太像否则指标虚高、人工构造对抗样本专门测边界情况。比例建议 5:3:2。CI 集成是这套东西价值最大化的地方每次 PR 自动跑# .github/workflows/rag-eval.yml name: RAG Evaluation on: [pull_request] jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: { python-version: 3.11 } - run: pip install ragas - run: python scripts/eval_rag.py --dataset tests/rag_cases.jsonl - name: 分数门槛检查 run: python scripts/check_threshold.py \ --metric faithfulness --min 0.85 \ --metric context_precision --min 0.7check_threshold.py里就是读评测结果 JSON低于阈值就sys.exit(1)把 PR 挡下来。阈值建议从宽松开始忠实度 0.8、上下文精确率 0.6跑两周拿到基线再收紧一上来定死高标准只会让团队天天跟 CI 搏斗。踩坑记录与对比数据噪声敏感度是隐性杀手把 3 段不相关的噪声 chunk 塞进上下文忠实度从 0.92 掉到 0.61但 answer_relevancy 几乎没变。所以别只看生成层指标——构造相关文档 N 段噪声的测试样本看忠实度随 N 的下降曲线Ragas 默认 judge 走 OpenAI国内网络环境要配 base_url 走代理或换成国产模型兼容端点否则 CI 一跑就超时DeepEval 的 metric 用 pytest 风格写断言适合已经用 pytest 的团队Ragas 的 dataset 驱动方式适合批量回归。两者指标定义有细微差别同一条数据跑出来分数会差 0.05 左右换工具后别直接拿旧阈值对比先重新标定chunk size 从 512 调到 1024context_recall 涨了 0.11但 context_precision 掉了 0.04——大 chunk 覆盖全但噪声多这就是为什么要同时盯两个指标而不是只看总分。进阶方向先把离线评测golden dataset CI 门槛跑稳再往两个方向走一是线上评测对真实流量抽样用轻量 judge 打分接告警二是从单轮问答走向 agent 评测轨迹级别trajectory-level的指标——工具调用是否正确、规划是否合理——这已经是 Agent 测试的范畴Ragas 和 DeepEval 都在往这个方向补能力。评测体系的建设顺序永远是先分层指标再建测试集最后自动化别跳步。如果你也在做 AI 应用RAG / Agent / LLM不知道质量怎么测——我最近在给 AI 应用做免费质量体检出一份可执行的测评报告检索命中率、回答忠实度、噪声敏感度等维度感兴趣可以直接私信我。
