DeepEval LLM 评估框架实战从第一个评估测试到 CI 集成【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval你刚改完提示词、换了模型却不知道效果到底是变好还是变坏直到用户投诉才发现答案跑偏了。DeepEval 这个开源 LLM 评估框架就是干这个的把模型输出好不好变成一条可以反复执行、能进 CI 的测试。它到底是什么DeepEval 是一个开源的 LLM 评估框架定位类似 Pytest但测试对象是模型输出。你像写单测一样写测试用例它用 LLM-as-a-judge 加本地运行的 NLP 模型给输出打 0~1 的分数。它覆盖 AI agent、RAG 管线和聊天机器人三类项目也支持对 agent 的完整决策轨迹做评估而不只是黑盒看最终答案。维度人工判断传统单测DeepEval判断依据经验与感觉精确断言40 指标0~1 打分可重复性低因人而异高高可进 CI 每次跑评估粒度抽样仅确定性输出端到端 / 单组件 / 多轮轨迹主要成本人力时间低judge 模型有 API 费用三步跑起来克隆并安装git clone https://gitcode.com/GitHub_Trending/de/deepeval cd deepeval然后pip install -U .需 Python 3.9。配置密钥judge 模型要调 API 打分先export OPENAI_API_KEY...。跑首个示例deepeval test run examples/getting_started/test_example.py内置用AnswerRelevancyMetric和GEval给示例用例打分终端直接输出通过与否。注意所有 LLM-as-judge 类指标都依赖外部模型没有配置好 judge 的 API key 之前测试无法真正出分。能力地图能力解决的问题适用场景40 内置指标AnswerRelevancy、Faithfulness、Hallucination 等好答案没有统一标准单轮问答、端到端黑盒评估GEval / DAG 自定义指标通用指标表达不了业务规则礼貌度、合规性、格式要求RAG 指标组Contextual Precision / Recall / Relevancy分不清问题出在检索还是生成RAG 管线调优多轮指标Knowledge Retention、Conversation Completeness单轮正常多轮就跑偏聊天机器人Agent 指标Task Completion、Tool Use、Step Efficiencyagent 决策路径无法量化带工具调用的 LLM 应用合成数据集生成评估数据不够单轮/多轮测试集构建框架集成LangChain、OpenAI Agents、CrewAI、LlamaIndex、Pydantic AI 等手动埋点成本高已有框架的项目Tracing 与轨迹评估中间步骤看不到agent 逐步回溯两个典型场景深入场景一RAG 端到端评估场景客服 RAG 上线你换了分块策略需要确认检索质量和答案质量没有回退。参考 examples/rag_evaluation/rag_evaluation_with_qdrant.py 的写法最小化版本import deepeval from deepeval.test_case import LLMTestCase test_case LLMTestCase( inputWhats the return policy?, actual_outputWe offer a 30-day full refund., expected_outputFree full refund within 30 days., retrieval_context[All customers are eligible for a 30 day full refund.], ) deepeval.evaluate(test_cases[test_case], metrics[ deepeval.metrics.FaithfulnessMetric(), deepeval.metrics.ContextualRecallMetric(), deepeval.metrics.ContextualPrecisionMetric(), ])输出看三样每个指标的 score0~1、reasonjudge 给的解释、以及 threshold 是否通过。Faithfulness 低说明答案里有上下文支撑不了的内容是生成端问题Contextual Recall / Precision 低说明检索没捞对、没排对是检索端问题。两类分数一拆回退原因基本就定位了。场景二多轮对话评估场景聊天机器人前几轮都答得对但用户追问时就忘了上下文。多轮评估用ConversationalTestCase每一轮是一个Turnfrom deepeval import evaluate from deepeval.test_case import Turn, ConversationalTestCase from deepeval.metrics import ConversationCompletenessMetric convo ConversationalTestCase( turns[ Turn(roleuser, contentWhats the return policy?), Turn(roleassistant, content30-day full refund.), Turn(roleuser, contentHow long does shipping take?), Turn(roleassistant, content3~5 business days.), ] ) evaluate( test_cases[convo], metrics[ConversationCompletenessMetric(threshold0.5)], )ConversationCompletenessMetric衡量整段对话是否满足了用户需求官方文档把它当作用户满意度的代理指标。如果分数偏低再看 reason 里指出的是哪一轮断裂再决定是补检索还是补提示词。接进工程链路CI 侧deepeval test run本身就是命令行入口任何 CI/CD 环境都能跑让每次合并请求都过一遍评估门禁name: llm-evals on: [push, pull_request] jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-pythonv4 with: python-version: 3.11 - run: pip install -U deepeval - run: deepeval test run tests/ env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}生产侧运行deepeval login登录 Confident AI 平台或代码里deepeval.login(CONFIDENT_AI_API_KEY)后测试用例会自动上报可以对比不同 prompt 版本、不同模型在同一数据集上的回归表现并监控线上 trace。常见坑与调优问题分数忽高忽低同一用例两次跑出不同结果。原因judge 是 LLM本身有随机性。解法固定 temperature对同一数据集跑多轮取平均对稳定性要求高的维度用确定性的 DAG 指标替代纯 LLM 打分。问题跑起来报 401 或模型相关错误。原因judge 模型要调 APIOPENAI_API_KEY没配置或没生效。解法运行前export OPENAI_API_KEY不想用 OpenAI 也可以换成自定义模型做 judge。问题评估成本上去了。原因LLM-as-judge 类指标对每个用例都会多次调用 judge 模型。解法先把evaluate的缓存机制用起来避免重复计算大集合同时先抽样跑子集确认方向后再全量。问题阈值设了 0.8几乎全军覆没。原因阈值拍脑袋没有按真实数据校准。解法先跑一批 golden 样本看分数分布再用人工确认过的好答案把阈值锚定在合理分位上。经验先上一两个指标如AnswerRelevancyMetric、FaithfulnessMetric跑通链路再逐步加维度比一次堆十个指标再逐个排查要快得多。下一步从一两个指标起步跑通deepeval test run的闭环再谈扩展。把评估放进 CI 门禁红了就不合并prompt 漂移才能被拦住。阈值用真实数据校准不靠直觉。示例可以直接看 examples/指标全量列表在 deepeval/metrics/更多文档见 docs/。把examples/getting_started/test_example.py拷走改成你自己的用例今天就跑通第一次评估。【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepEval LLM 评估框架实战：从第一个评估测试到 CI 集成
DeepEval LLM 评估框架实战从第一个评估测试到 CI 集成【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval你刚改完提示词、换了模型却不知道效果到底是变好还是变坏直到用户投诉才发现答案跑偏了。DeepEval 这个开源 LLM 评估框架就是干这个的把模型输出好不好变成一条可以反复执行、能进 CI 的测试。它到底是什么DeepEval 是一个开源的 LLM 评估框架定位类似 Pytest但测试对象是模型输出。你像写单测一样写测试用例它用 LLM-as-a-judge 加本地运行的 NLP 模型给输出打 0~1 的分数。它覆盖 AI agent、RAG 管线和聊天机器人三类项目也支持对 agent 的完整决策轨迹做评估而不只是黑盒看最终答案。维度人工判断传统单测DeepEval判断依据经验与感觉精确断言40 指标0~1 打分可重复性低因人而异高高可进 CI 每次跑评估粒度抽样仅确定性输出端到端 / 单组件 / 多轮轨迹主要成本人力时间低judge 模型有 API 费用三步跑起来克隆并安装git clone https://gitcode.com/GitHub_Trending/de/deepeval cd deepeval然后pip install -U .需 Python 3.9。配置密钥judge 模型要调 API 打分先export OPENAI_API_KEY...。跑首个示例deepeval test run examples/getting_started/test_example.py内置用AnswerRelevancyMetric和GEval给示例用例打分终端直接输出通过与否。注意所有 LLM-as-judge 类指标都依赖外部模型没有配置好 judge 的 API key 之前测试无法真正出分。能力地图能力解决的问题适用场景40 内置指标AnswerRelevancy、Faithfulness、Hallucination 等好答案没有统一标准单轮问答、端到端黑盒评估GEval / DAG 自定义指标通用指标表达不了业务规则礼貌度、合规性、格式要求RAG 指标组Contextual Precision / Recall / Relevancy分不清问题出在检索还是生成RAG 管线调优多轮指标Knowledge Retention、Conversation Completeness单轮正常多轮就跑偏聊天机器人Agent 指标Task Completion、Tool Use、Step Efficiencyagent 决策路径无法量化带工具调用的 LLM 应用合成数据集生成评估数据不够单轮/多轮测试集构建框架集成LangChain、OpenAI Agents、CrewAI、LlamaIndex、Pydantic AI 等手动埋点成本高已有框架的项目Tracing 与轨迹评估中间步骤看不到agent 逐步回溯两个典型场景深入场景一RAG 端到端评估场景客服 RAG 上线你换了分块策略需要确认检索质量和答案质量没有回退。参考 examples/rag_evaluation/rag_evaluation_with_qdrant.py 的写法最小化版本import deepeval from deepeval.test_case import LLMTestCase test_case LLMTestCase( inputWhats the return policy?, actual_outputWe offer a 30-day full refund., expected_outputFree full refund within 30 days., retrieval_context[All customers are eligible for a 30 day full refund.], ) deepeval.evaluate(test_cases[test_case], metrics[ deepeval.metrics.FaithfulnessMetric(), deepeval.metrics.ContextualRecallMetric(), deepeval.metrics.ContextualPrecisionMetric(), ])输出看三样每个指标的 score0~1、reasonjudge 给的解释、以及 threshold 是否通过。Faithfulness 低说明答案里有上下文支撑不了的内容是生成端问题Contextual Recall / Precision 低说明检索没捞对、没排对是检索端问题。两类分数一拆回退原因基本就定位了。场景二多轮对话评估场景聊天机器人前几轮都答得对但用户追问时就忘了上下文。多轮评估用ConversationalTestCase每一轮是一个Turnfrom deepeval import evaluate from deepeval.test_case import Turn, ConversationalTestCase from deepeval.metrics import ConversationCompletenessMetric convo ConversationalTestCase( turns[ Turn(roleuser, contentWhats the return policy?), Turn(roleassistant, content30-day full refund.), Turn(roleuser, contentHow long does shipping take?), Turn(roleassistant, content3~5 business days.), ] ) evaluate( test_cases[convo], metrics[ConversationCompletenessMetric(threshold0.5)], )ConversationCompletenessMetric衡量整段对话是否满足了用户需求官方文档把它当作用户满意度的代理指标。如果分数偏低再看 reason 里指出的是哪一轮断裂再决定是补检索还是补提示词。接进工程链路CI 侧deepeval test run本身就是命令行入口任何 CI/CD 环境都能跑让每次合并请求都过一遍评估门禁name: llm-evals on: [push, pull_request] jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-pythonv4 with: python-version: 3.11 - run: pip install -U deepeval - run: deepeval test run tests/ env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}生产侧运行deepeval login登录 Confident AI 平台或代码里deepeval.login(CONFIDENT_AI_API_KEY)后测试用例会自动上报可以对比不同 prompt 版本、不同模型在同一数据集上的回归表现并监控线上 trace。常见坑与调优问题分数忽高忽低同一用例两次跑出不同结果。原因judge 是 LLM本身有随机性。解法固定 temperature对同一数据集跑多轮取平均对稳定性要求高的维度用确定性的 DAG 指标替代纯 LLM 打分。问题跑起来报 401 或模型相关错误。原因judge 模型要调 APIOPENAI_API_KEY没配置或没生效。解法运行前export OPENAI_API_KEY不想用 OpenAI 也可以换成自定义模型做 judge。问题评估成本上去了。原因LLM-as-judge 类指标对每个用例都会多次调用 judge 模型。解法先把evaluate的缓存机制用起来避免重复计算大集合同时先抽样跑子集确认方向后再全量。问题阈值设了 0.8几乎全军覆没。原因阈值拍脑袋没有按真实数据校准。解法先跑一批 golden 样本看分数分布再用人工确认过的好答案把阈值锚定在合理分位上。经验先上一两个指标如AnswerRelevancyMetric、FaithfulnessMetric跑通链路再逐步加维度比一次堆十个指标再逐个排查要快得多。下一步从一两个指标起步跑通deepeval test run的闭环再谈扩展。把评估放进 CI 门禁红了就不合并prompt 漂移才能被拦住。阈值用真实数据校准不靠直觉。示例可以直接看 examples/指标全量列表在 deepeval/metrics/更多文档见 docs/。把examples/getting_started/test_example.py拷走改成你自己的用例今天就跑通第一次评估。【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考