DeepEval LLM 评估实战指南3 步跑通第一次评测5 类场景指标一次讲清【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepevalDeepEval 是一个开源的 LLM 评估框架把RAG 检索准不准、对话有没有跑题、智能体干没干对事这类主观判断变成 0-1 之间可以打分、可以进 CI 的数字。它内置 40 个评估指标底层是 LLM-as-a-Judge——由一个裁判 LLM 按 QAG、DAG、G-Eval 等方法给每个测试用例打分同时输出推理过程reason默认阈值 0.5低于它就是不及格。评估前先回答三个问题选指标之前先想清楚体检项目不然分数再细也没人看得懂。三个问题按顺序问评什么场景是 RAG 问答、多轮对话、会调工具的 Agent还是内容安全审查场景决定你从哪组指标里选。DeepEval 的指标大致分成 RAG、对话、智能体、安全、多模态五组完整定义见 docs/content/docs/metrics-introduction.mdx。评哪一层RAG 系统里检索器查回来的东西对不对和生成器照着上下文答得准不准会犯不同的错。检索层看 Contextual Precision/Recall/Relevancy生成层看 Faithfulness 和 Answer Relevancy也可以直接端到端对比 expected_output。层选错了分数高不代表系统好。多少分算合格所有指标默认阈值 0.5但这只是出厂设置。阈值应该拿 20-50 条真实业务数据先跑一遍人工看哪些分数对应的回答你愿意发给用户再定线。不同指标的阈值要分别校准别一次定死。按场景挑指标套餐 官方文档明确建议单次评估不超过 5 个指标2-3 个通用 1-2 个业务定制因为裁判 LLM 每次都要付费跑请求指标越多越慢越贵。按场景对号入座场景推荐指标盯住的信号RAG 系统ContextualRelevancyMetric、FaithfulnessMetric、ContextualRecallMetric查回的上下文和查询相不相关答案有没有拿上下文编造幻觉参考答案需要的信息检索器能不能捞到需配 expected_output多轮对话RoleAdherenceMetric、ConversationCompletenessMetric、KnowledgeRetentionMetric人设全程守不守得住用户目标最后达没达成第 1 轮说的信息第 5 轮还记不记得工具型 AgentTaskCompletionMetric、ToolCorrectnessMetric任务最终完没完成该调的工具调没调、参数对不对依赖 tracing 数据安全审查BiasMetric、PIIDetoxificationMetric、ToxicityMetric回复有无偏见、泄露手机号/身份证等 PII、带毒内容多模态ImageCoherenceMetric 等图文是否一致、图像参考是否准确三步跑通第一次评估 第一次上手不用翻完文档三步就能出分第一步建用例。单轮用LLMTestCase填input用户输入、actual_output模型实际回答、retrieval_contextRAG 检索到的上下文多轮用ConversationalTestCase里面是一串Turn(roleuser/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_outputDeepEval 是一个开源的 LLM 评估框架。, retrieval_context[DeepEval 支持 RAG、对话与智能体评估], ) evaluate( test_cases[test_case], metrics[ContextualRelevancyMetric(threshold0.7), FaithfulnessMetric(threshold0.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], threshold0.6, ) cs_quality.measure(LLMTestCase( input我的订单还没到帮我查下, actual_output您好非常抱歉。请提供订单号我马上为您查询。, )) print(cs_quality.score, cs_quality.reason)经验法则能写成 if-else 的标准上 DAG跑得快且分稳定要靠语义理解的标准上 G-Eval但记得固定裁判模型不然分数会有波动。从本地验证到持续监控 本地跑通只是开始真正值钱的是把评估变成日常动作分三步升级接 CI评估文件按 pytest 写用deepeval test run test_llm_app.py执行它比普通 pytest 多了异步、重试、重复跑等 8 个以上可选开关。放进 GitHub Actions 后每次 PR 都跑同一套用例指标掉线就红灯拦住。配置细节参考 docs/content/docs/evaluation-unit-testing-in-ci-cd.mdx。看线上流量给 LLM 调用函数加observe装饰器源码见 deepeval/tracing/tracing.pyDeepEval 会记录每次调用的输入输出和耗时。从生产 trace 里捞出真实 bad case反哺成测试用例评估集才不是拍脑袋。对比模型版本换模型或改 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.mdxCI/CD 集成的完整示例docs/content/docs/evaluation-unit-testing-in-ci-cd.mdx【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考