DeepEval LLM 评估实战:RAG 与多轮对话的完整质量评测方案
【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval
DeepEval 是一个开源 LLM 评估框架,它把"回答感觉不太好"变成 0 到 1 之间可对比的分数。这篇文章讲 RAG 评测与多轮对话质量怎么量化:五分钟跑通第一次评估,给出 RAG 和多轮对话两套可直接抄的指标配方,内置指标不够用时再讲 G-Eval 与 DAG 怎么选。所有默认阈值和 API 写法都来自仓库源码,不是印象分。
五分钟跑通第一次评估:assert_test 就够了
先上可运行的最小示例,再拆每一块在干什么。下面是个 pytest 文件,跑通即代表这次 RAG 回答"有据可依":
# test_rag_quality.py import pytest from deepeval.test_case import LLMTestCase from deepeval.metrics import FaithfulnessMetric, ContextualRelevancyMetric from deepeval import assert_test def test_refund_answer_is_grounded(): case = LLMTestCase( input="这个产品退款政策是什么?", actual_output="7 天内可以全额退款。", retrieval_context=["购买后 7 天内可申请退款,审核通过后原路退回。"], ) assert_test( test_case=case, metrics=[FaithfulnessMetric(threshold=0.7), ContextualRelevancyMetric(threshold=0.6)], )逐块看:LLMTestCase装一次请求的完整现场——用户问什么、模型答了什么、检索器吐了哪些片段;FaithfulnessMetric检查回答里的每个事实是否都能从检索片段里找到出处,ContextualRelevancyMetric反过来检查检索片段与问题是否相关。assert_test跑完后任何一个指标低于阈值就抛AssertionError,测试直接变红,所以它天然适合放进 CI。所有内置指标的默认阈值都是 0.5,在各自__init__里能直接验证。指标全集见 metrics 介绍文档。
你的系统该配哪几个指标:先归类,再查表
选型只问一个问题:坏答案坏在哪个环节。RAG 答非所问时先分清是检索拉了偏( relevancy 掉分)还是生成放飞(faithfulness 掉分);智能体看目标达成和工具调用;多轮对话盯跨轮记忆;安全类指标当硬门槛。确认类别后,查这张表定起点:
| 场景 | 推荐指标组合 | 阈值起点 | 该盯什么信号 |
|---|---|---|---|
| RAG(检索+生成) | ContextualRelevancyMetric + FaithfulnessMetric,有标准答案再加 ContextualRecallMetric | 0.6 / 0.7 / 0.6 | faithfulness 下滑=生成端开始编;relevancy 下滑=检索器召回变差 |
| 工具型智能体 | TaskCompletionMetric + ToolCorrectnessMetric | 0.7 | 任务完成度掉但工具调用正确=模型用错了正确的信息 |
| 多轮对话 | ConversationCompletenessMetric + KnowledgeRetentionMetric | 0.5~0.6 | 会话后半程分数骤降=用户前面说过的被忘了 |
| 安全红线 | PIILeakageMetric + BiasMetric + ToxicityMetric | 0.5,建议开 strict_mode | 任一红线指标不过,直接阻断而不是平均分 |
这套分法与 RAG 评估指南 里的 RAG 三元组思路一致:检索质量、生成忠实度、答案相关性各管一段。
RAG 评测配方:三指标组合与阈值起点
给 RAG 系统一套就够: relevancy 管"检索准不准",faithfulness 管"生成有没有飘",recall 管"必要事实有没有漏",它要求测试用例额外给expected_output作对照。阈值从 0.6 起步,faithfulness 单独提到 0.7,因为幻觉是 RAG 最不能忍的错。
from deepeval.test_case import LLMTestCase from deepeval.metrics import FaithfulnessMetric, ContextualRelevancyMetric, ContextualRecallMetric case = LLMTestCase( input="不满意能退货吗?", actual_output="可以,7 天内申请退货,通过后原路退回。", retrieval_context=["购买后 7 天内可申请退货,退货通过后款项原路退回。"], expected_output="7 天内可退货。", ) metrics = [ ContextualRelevancyMetric(threshold=0.6), FaithfulnessMetric(threshold=0.7), ContextualRecallMetric(threshold=0.6), ]打分对照(分数由裁判 LLM 给出,以下为典型量级):
- 好答案:上面这句"可以,7 天内……"每个词都能在检索片段里找到依据,faithfulness 通常落在 0.9 以上,三项全过。
- 差答案:换成"可以,30 天无理由退款,还送一张 9 折券"——"30 天"和"9 折券"在上下文里根本不存在,faithfulness 常掉到 0.3 以下,断言失败,CI 红给你看。
多轮对话评测配方:把"越聊越差"变成分数
多轮对话最常见的两个毛病:忘了用户前面说的、聊完没解决问题。这正对应两个指标——KnowledgeRetentionMetric检查早期轮次的信息在后续是否被记住,ConversationCompletenessMetric检查整段对话是否达成用户目标(默认window_size=3,用滑动窗口看局部连贯性)。阈值从 0.5~0.6 起步,业务有明确角色设定可再加一个 ConversationalGEval 管语气。更多组合见 多轮评估指标指南。
from deepeval.test_case import ConversationalTestCase, Turn from deepeval.metrics import ConversationCompletenessMetric, KnowledgeRetentionMetric conversation = ConversationalTestCase( turns=[ Turn(role="user", content="我要改一下收货地址。"), Turn(role="assistant", content="好的,请提供订单号。"), Turn(role="user", content="A10086,地址换成武康路 1 号 2 栋。"), Turn(role="assistant", content="已更新,A10086 的新地址是武康路 1 号 2 栋。"), ] ) conv_metrics = [ ConversationCompletenessMetric(threshold=0.6), KnowledgeRetentionMetric(threshold=0.5), ]打分对照:
- 好对话:示例里第 4 轮准确复述了订单号和新地址,completeness 约 0.8 以上,knowledge retention 接近 1.0。
- 差对话:把第 4 轮换成"我没听到您的订单号,麻烦再说一次"——用户第 3 轮明明给过,knowledge retention 直接跌破 0.5,这类"失忆"在单轮测试里完全看不见,必须用
ConversationalTestCase才能暴露。
G-Eval 还是 DAG:二选一判断标准
内置指标盖不住业务标准时,先问一句:这条标准能不能写成确定性的 if/else?能,选 DAG——把判断拆成决策图,DAGMetric(name=..., dag=DeepAcyclicGraph(...))接收节点(LLM 判断节点或纯函数节点),边是确定的,同一输入多次跑分稳定,适合"第 1 步必须问订单号、第 2 步必须给查询入口"这类可枚举规则。不能枚举、只能整体感受的(语气、专业度、说服力),选 G-Eval,一段自然语言标准交给裁判模型出分:
from deepeval.metrics import GEval tone = GEval( name="语气友好度", criteria="回复是否友好、专业,且不把责任推给用户", threshold=0.6, )简单记:要可复现选 DAG,要灵活主观评价选 G-Eval,两个都嫌麻烦就先拿 G-Eval 顶一周再回来看要不要固化。
上线前避坑清单
阈值怎么定?别拍脑袋。先全用默认 0.5 跑一轮,人工看 30 到 50 条样本,把"这条明明该挂"的共识分数标出来,再逐指标收紧。安全相关项直接开strict_mode,源码里它会把阈值强制成 1,一票否决。
为什么指标别贪多?每个指标都是一次裁判 LLM 调用,成本、延迟和分数噪声都随指标数线性涨。控制在 5 个以内,单场景 2~3 个通常就够,加一个先说清它要抓什么信号。
怎么接进 CI/CD?测试就用上面的 pytest 写法,GitHub Actions 里执行deepeval test run test_rag_quality.py即可,指标不过就抛断言、流水线变红。CI/CD 回归测试指南 里有现成的 workflow 模板。
生产流量怎么持续观测?用 tracing 模块 里的@observe包住入口函数,线上每次调用自动落 trace,把 bad case 捞回数据集当回归用例,评测集随线上问题一起长大。
同一批答案分数会漂移?裁判本身是 LLM,锁住裁判模型版本、别频繁改 criteria;关键卡点用 strict_mode 或 DAG 兜底,别指望模糊裁判守红线。
接下来
- 入门与安装:docs/content/docs/getting-started.mdx
- 全部指标定义与参数:docs/content/docs/metrics-introduction.mdx
- 从 trace 到数据集的完整闭环:docs/content/guides/guides-tracing-rag.mdx
【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考