DeepEval LLM 评测框架：如何 5 分钟跑通评测闭环并接入 CI

DeepEval LLM 评测框架：如何 5 分钟跑通评测闭环并接入 CI

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

刚升级模型，客服回答的质量肉眼看起来差不多，你拿什么向团队证明新旧版本真的有差别？人工抽看十几条回复，给出的结论往往互相打架。DeepEval 的思路是把评测写成可重复执行的测试：每条样本交给指标打分，输出 0-1 的分数，版本差异从"感觉"变成可复现的数字。

先判断该测什么：RAG、智能体、多轮对话三套指标

选指标前先归类你的系统，三类系统对应三组核心指标。

• RAG 应用：回答相关性看回答贴不贴问题，忠实度看是否忠于检索上下文，上下文召回率看关键信息有没有被漏掉。
• 智能体：任务完成度衡量目标是否达成，工具正确性校验工具调用是否符合预期。
• 多轮对话：知识保留度检验多轮之后信息是否还在，每轮忠实度关注摘要与追问场景。

判断标准就一条：指标要对应你会被用户投诉的那类失败。

最快安装步骤与最小可运行用例

安装只需一条命令，Python 3.9+ 即可：

pip install -U deepeval

本地克隆仓库便于阅读示例与源码：

git clone https://gitcode.com/GitHub_Trending/de/deepeval

配置好 OPENAI_API_KEY 环境变量后，下面这个工单分类用例约 10 行就能跑起来：

from deepeval import evaluate from deepeval.metrics import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase tc = LLMTestCase( input="用户反馈 API 超时，判断工单类别", actual_output="应归类为：性能问题，建议先查服务端 P99 延迟。", retrieval_context=["性能类工单需先确认是否伴随延迟指标异常。"], ) evaluate([tc], [AnswerRelevancyMetric(threshold=0.7)])

终端会打印指标说明和结果表，每个指标一行：分数落在 0-1，PASS 或 FAIL 一目了然，分数低于 0.7 就标 FAIL，回答与问题、上下文是否对得上直接量化了。

把评测固化进流程：数据集管理、阈值设置与 CI 集成

评测要防回归，得先固化成数据集。用一个 jsonl 文件维护测试用例，每行一条，字段对应 LLMTestCase 的 input、actual_output、retrieval_context。用 EvaluationDataset 加载，阈值统一写在指标初始化处，集中管理、避免散落各处。

CI 侧加一步：

deepeval test run test_chatbot.py

低于阈值的指标会直接让构建失败，每次合并都自动跑一轮回归。数据集加载与持久化的实现在 deepeval/dataset/，集成示例见 examples/tracing/。

评分不及格时的排查顺序：输入、上下文、阈值三步走

分数偏低时按固定顺序排查，不要先动阈值。

1. 先查输入清晰度：问题本身含糊，分数低是合理的，先修样本再谈模型。
2. 再查上下文完整性：确认 retrieval_context 里真的有支撑答案的依据，漏检就查召回环节。
3. 最后才考虑调阈值：阈值是业务决策，不是掩盖问题的旋钮。

排查完仍普遍偏低，说明是模型或提示词的问题，这时换版本重跑，对比两轮的均分才是有效证据。

一句话总结：DeepEval 让你用测试代码给 LLM 应用建起 0-1 的评分闭环，版本迭代和 CI 防回归都有据可依。指标的完整清单与自定义写法，直接看 deepeval/metrics/ 源码即可。

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