企业官网建设流程全解析

DeepEval LLM 评估实战指南：3 步跑通第一次评测，5 类场景指标一次讲清

【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval

DeepEval 是一个开源的 LLM 评估框架，把"RAG 检索准不准、对话有没有跑题、智能体干没干对事"这类主观判断，变成 0-1 之间可以打分、可以进 CI 的数字。它内置 40+ 个评估指标，底层是 LLM-as-a-Judge——由一个裁判 LLM 按 QAG、DAG、G-Eval 等方法给每个测试用例打分，同时输出推理过程（reason），默认阈值 0.5，低于它就是不及格。

评估前先回答三个问题

选指标之前先想清楚"体检项目"，不然分数再细也没人看得懂。三个问题按顺序问：

1. 评什么场景：是 RAG 问答、多轮对话、会调工具的 Agent，还是内容安全审查？场景决定你从哪组指标里选。DeepEval 的指标大致分成 RAG、对话、智能体、安全、多模态五组，完整定义见 docs/content/docs/metrics-introduction.mdx。
2. 评哪一层：RAG 系统里，检索器（查回来的东西对不对）和生成器（照着上下文答得准不准）会犯不同的错。检索层看 Contextual Precision/Recall/Relevancy，生成层看 Faithfulness 和 Answer Relevancy，也可以直接端到端对比 expected_output。层选错了，分数高不代表系统好。
3. 多少分算合格：所有指标默认阈值 0.5，但这只是出厂设置。阈值应该拿 20-50 条真实业务数据先跑一遍，人工看哪些分数对应的回答你"愿意发给用户"，再定线。不同指标的阈值要分别校准，别一次定死。

按场景挑指标套餐 📦

官方文档明确建议单次评估不超过 5 个指标（2-3 个通用 + 1-2 个业务定制），因为裁判 LLM 每次都要付费跑请求，指标越多越慢越贵。按场景对号入座：

三步跑通第一次评估 🚀

第一次上手不用翻完文档，三步就能出分：

第一步，建用例。单轮用LLMTestCase，填input（用户输入）、actual_output（模型实际回答）、retrieval_context（RAG 检索到的上下文）；多轮用ConversationalTestCase，里面是一串Turn(role="user"/"assistant", content=...)。

第二步，选指标并设阈值。从deepeval.metrics里导入，构造时传threshold。

第三步，跑 evaluate 看分数和 reason。入口是deepeval.evaluate(test_cases=..., metrics=...)，每个指标会输出 0-1 的 score 和一段文字理由，score 达到 threshold 才判通过：

from deepeval import evaluate from deepeval.metrics import ContextualRelevancyMetric, FaithfulnessMetric from deepeval.test_case import LLMTestCase test_case = LLMTestCase( input="什么是 DeepEval？", actual_output="DeepEval 是一个开源的 LLM 评估框架。", retrieval_context=["DeepEval 支持 RAG、对话与智能体评估"], ) evaluate( test_cases=[test_case], metrics=[ContextualRelevancyMetric(threshold=0.7), FaithfulnessMetric(threshold=0.5)], )

跑完先看 reason 再看分数：分数告诉你过没过，reason 告诉你为什么。

把业务标准写进评估：G-Eval 还是 DAG 🧮

内置指标覆盖不了"我们公司要求客服回复必须带道歉语"这类私有标准时，自己写一个。两条路线，选择标准只有一条：这条规则能不能写成"如果…就…"。

• DAG 指标（DAGMetric）：把判断组织成一张有向无环图，每个节点是一个可确定性验证的条件（精确匹配、正则、字段检查等），最后按节点结果算分。规则明确、要求可复现、不想每次多付 LLM 钱的时候选它。比如"回复必须含订单号格式 → 必须先道歉 → 语气评分"，前两步纯代码，最后一步才交给 LLM。
• G-Eval：用自然语言写criteria，由裁判 LLM 按标准打分，适合主观标准（"是否友好且专业"这种没法正则化的东西），还能用evaluation_steps拆成多步思考。

G-Eval 的最小用法：

from deepeval.metrics import GEval from deepeval.test_case import LLMTestCase, LLMTestCaseParams cs_quality = GEval( name="客服回复质量", criteria="回复是否友好、专业，并给出明确处理步骤", evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT], threshold=0.6, ) cs_quality.measure(LLMTestCase( input="我的订单还没到，帮我查下", actual_output="您好，非常抱歉。请提供订单号，我马上为您查询。", )) print(cs_quality.score, cs_quality.reason)

经验法则：能写成 if-else 的标准上 DAG，跑得快且分稳定；要靠语义理解的标准上 G-Eval，但记得固定裁判模型，不然分数会有波动。

从本地验证到持续监控 📊

本地跑通只是开始，真正值钱的是把评估变成日常动作，分三步升级：

1. 接 CI：评估文件按 pytest 写，用deepeval test run test_llm_app.py执行，它比普通 pytest 多了异步、重试、重复跑等 8 个以上可选开关。放进 GitHub Actions 后，每次 PR 都跑同一套用例，指标掉线就红灯拦住。配置细节参考 docs/content/docs/evaluation-unit-testing-in-ci-cd.mdx。
2. 看线上流量：给 LLM 调用函数加@observe装饰器（源码见 deepeval/tracing/tracing.py），DeepEval 会记录每次调用的输入输出和耗时。从生产 trace 里捞出真实 bad case，反哺成测试用例，评估集才不是拍脑袋。
3. 对比模型版本：换模型或改 prompt 后，用 Arena G-Eval 让裁判 LLM 对两份输出做同标准 A/B 对比，比单看分数更直观地回答"新版本到底有没有变好"。

避坑清单 ⚠️

• 指标贪多：5 个以上指标既拖慢 CI 又抬高 LLM 账单，还让团队没人看得完。按套餐挑，宁缺毋滥。
• 阈值一刀切：0.5 是默认值不是标准。安全类指标（PII、偏见）通常应该定在 0.8 以上，相关性类可以放宽，分开校准。
• 只评一头：只评检索不评生成，会漏掉"查对了但答歪了"；反过来也成立。RAG 至少一检索一生成各一个。
• 只看分数不看 reason：分数是结果，reason 才是定位问题的入口。批量跑完先抽 10 条不及格的 reason 读，比盯着平均分有用得多。
• 把单次分数当真理：LLM-as-a-Judge 本身有随机性，同一输入重跑可能差 0.05-0.1。重要结论跑多次取均值，并且固定裁判模型，别今天用 A 模型当裁判、明天换成 B。

收尾

一句话总结：先用"场景-层级-阈值"三个问题定套餐，再用evaluate三步出分，私有标准交给 G-Eval 或 DAG，最后用test run、@observe和 Arena G-Eval 把它变成日常。

想深入的话，从这三处开始：

• 全部指标的定义与用法：docs/content/docs/metrics-introduction.mdx
• 多轮对话评估的端到端写法：docs/content/docs/evaluation-end-to-end-multi-turn.mdx
• CI/CD 集成的完整示例：docs/content/docs/evaluation-unit-testing-in-ci-cd.mdx

【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval