企业官网建设流程全解析

DeepEval 完整指南：LLM 评估指标快速上手，从 RAG 到对话一次搞定

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

这是一份基于 DeepEval 的 LLM 评估实战入门。我们从 RAG 答错、对话丢上下文这些真实痛点出发，教你按场景挑选 LLM 评估指标，5 分钟跑通第一次评估，并把评估融进日常研发流程。

为什么不能只看回答本身

这一节回答一个问题：为什么人工抽查撑不起 LLM 应用的评估。

第一个痛点出现在 RAG 系统：检索阶段拿了错误的文档，模型却"自信地"基于它编出流畅的答案。你盯着回答本身看不出问题，错在检索环节。

第二个痛点在多轮对话：客服机器人到第 5、6 轮才丢掉前面确认过的订单信息，用户已经走了，你才从投诉里发现上下文丢失。

第三个痛点在迭代：你换了模型版本或改了一行 prompt，效果到底变好还是变差？没有分数，你只能靠"感觉"。

这三个问题的共同解法是自动化评估：固化一批测试用例，每次改动后自动跑一遍，用分数说话。下面这张图是 DeepEval 的 LLM 评估运行界面，每个用例、每个指标都有独立的分数记录：

先对齐 3 个基础概念

这一节用 60 秒讲清后文反复出现的三个词，避免你被术语卡住。

• LLM-as-a-Judge（用大模型当裁判）：LLM 输出本身不稳定，人工阅卷规模上不去，所以 DeepEval 用一个更强的模型按你给的标准自动阅卷。相当于给每条回答自动配一名裁判，既出分也出评语。
• 测试用例（Test Case）：一条"输入 + 回答"的记录。LLMTestCase里常见的字段有input（用户问题）、actual_output（模型实际回答）、expected_output（参考答案），RAG 场景再加retrieval_context（检索到的材料）。完整定义见 测试用例源码。
• 0-1 打分与阈值：每个指标输出 0-1 之间的分数和一条评分理由（reason），并与阈值（默认 0.5）比较，高于即通过。裁判打分，阈值就是及格线。

5 分钟跑通你的第一次 LLM 评估

这一节给你全文最核心的最小示例，跑完它你就有了第一个 LLM 回归测试。

from deepeval.test_case import LLMTestCase from deepeval.metrics import AnswerRelevancyMetric from deepeval import evaluate test_case = LLMTestCase( input="What if these shoes don't fit?", actual_output="We offer a 30-day full refund at no extra cost.", expected_output="You can get a free full refund within 30 days.", ) metric = AnswerRelevancyMetric(threshold=0.7) result = evaluate(test_cases=[test_case], metrics=[metric]) for r in result.test_results: print(r.name, r.success, r.metrics_data)

逐行拆解：前 3 行导入测试用例类、指标类和evaluate入口。LLMTestCase三个字段分别是问题、模型实际回答、参考答案。AnswerRelevancyMetric（答案相关性）回答一个问题："这个答案是否切题、有没有绕开用户真正想问的事"，threshold=0.7表示及格线设为 0.7。evaluate接收两个列表——测试用例和指标——批量执行并返回EvaluationResult：每个用例给出success（是否全部达标），metrics_data里则包含每个指标的分数（score）和评分理由（reason）。

读结果的顺序建议：先看reason，判断裁判的打分逻辑是否符合你的预期，再看分数是否符合直觉。这一步能帮你发现"裁判理解歪了"这种评估体系自身的 bug。更多可运行的变体见 入门示例。

按场景挑选评估指标

这一节解决"我到底该用哪几个指标"的问题。DeepEval 内置 40+ 指标，全量定义在 指标源码目录，按场景各挑几个就够：

指标不是越多越好：建议总数不超过 5 个，其中 2-3 个通用指标（如相关性、忠实度）保底，1-2 个业务指标（如客服友好度）体现你的产品差异。指标贪多，成本先爆，信号也稀释。

内置指标不够用：自定义与自动化

这一节回答两件事：内置指标覆盖不了的业务标准怎么补，评估怎么从"手动跑一次"变成"每次改动都自动跑"。

G-Eval：用自然语言定标准。主观评价类需求（客服语气是否友好、回答是否符合品牌口吻）很难写成规则，G-Eval 让你直接用一段自然语言描述评价标准，再由裁判模型按标准打分：

from deepeval.metrics import GEval from deepeval.test_case import SingleTurnParams correctness = GEval( name="Correctness", criteria="判断 actual output 相对 expected output 是否正确", evaluation_params=[SingleTurnParams.ACTUAL_OUTPUT, SingleTurnParams.EXPECTED_OUTPUT], strict_mode=True, )

DAG：确定性的多步判断。适合"必须按步骤判断"的规则，比如"先检查是否索要订单号，再检查是否给出查询途径"。DAG 把评估拆成一棵决策树，每个节点可以是代码判断或一次 LLM 调用，路径确定、结果可复现。边界一句话：标准模糊选 G-Eval，规则清晰选 DAG。

把评估接入日常流程，抓住三点：

1. CI 回归测试：测试用例写成 pytest 文件，用deepeval test run执行，任一指标低于阈值即判失败，直接卡住合并。
2. 生产流量监控：给应用函数加@observe装饰器（追踪模块），线上每次调用都留下 trace，可抽样离线评估，问题在用户投诉前被发现。
3. 版本对比：每次换模型、改 prompt 都记录一份结果，改动前后对比分数，而不是凭感觉发布。

常见坑与避坑建议

这一节把大家最容易踩的四个坑提前排掉：

• 一次上十几个指标：成本翻着倍涨，出了问题还不知道该修哪个。从 2-3 个指标起步，确认有效再加。
• 阈值照搬默认 0.5：不同业务的"及格线"完全不同。先拿一批你人工判过好坏的样本校准阈值，再固定下来。
• 忽略评估自身的成本：每个指标每次运行都要调 LLM 裁判。控制样本量、开启缓存，大批量用异步执行。
• 只看平均分：平均分能掩盖个别用例的严重回归。盯单个用例的分数变化，比盯整体均值更能发现问题。

把评估再往前推一步

评估体系的价值不在某一次跑分，而在于让每次改动都有数字背书。建议你现在就用上面的 15 行代码跑通第一个用例，再按场景表补齐你业务的指标。

进阶资源：

• 指标源码目录：40+ 内置指标的完整实现与文档字符串
• 入门示例代码：含 pytest 参数化与超参数记录
• 官方文档目录：指标定义、数据集与评估流程的完整说明

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