尧图网站建设 
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( inputWhat if these shoes dont fit?, actual_outputWe offer a 30-day full refund at no extra cost., expected_outputYou can get a free full refund within 30 days., ) metric AnswerRelevancyMetric(threshold0.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答案相关性回答一个问题这个答案是否切题、有没有绕开用户真正想问的事threshold0.7表示及格线设为 0.7。evaluate接收两个列表——测试用例和指标——批量执行并返回EvaluationResult每个用例给出success是否全部达标metrics_data里则包含每个指标的分数score和评分理由reason。读结果的顺序建议先看reason判断裁判的打分逻辑是否符合你的预期再看分数是否符合直觉。这一步能帮你发现裁判理解歪了这种评估体系自身的 bug。更多可运行的变体见 入门示例。按场景挑选评估指标这一节解决我到底该用哪几个指标的问题。DeepEval 内置 40 指标全量定义在 指标源码目录按场景各挑几个就够场景推荐指标挑选要点RAG 检索上下文相关性Contextual Relevancy、忠实度Faithfulness、答案相关性Answer Relevancy把检索器和生成器分开考核忠实度看答案的说法能否在检索材料里找到出处智能体 / 工具调用任务完成度Task Completion、工具使用Tool Use基于 trace 追踪数据评估重点看调没调对工具、最终办没办成事多轮对话角色一致性Role Adherence、知识保留度Knowledge Retention、轮次忠实度Turn Faithfulness必须喂完整对话历史ConversationalTestCase单看一轮没意义内容安全偏见Bias、毒性Toxicity、PII 泄露PII Leakage风险模式预定义判断成本低适合大批量跑多模态图像一致性Image Coherence、图像帮助度等考察图文跨模态是否一致见 多模态指标目录指标不是越多越好建议总数不超过 5 个其中 2-3 个通用指标如相关性、忠实度保底1-2 个业务指标如客服友好度体现你的产品差异。指标贪多成本先爆信号也稀释。内置指标不够用自定义与自动化这一节回答两件事内置指标覆盖不了的业务标准怎么补评估怎么从手动跑一次变成每次改动都自动跑。G-Eval用自然语言定标准。主观评价类需求客服语气是否友好、回答是否符合品牌口吻很难写成规则G-Eval 让你直接用一段自然语言描述评价标准再由裁判模型按标准打分from deepeval.metrics import GEval from deepeval.test_case import SingleTurnParams correctness GEval( nameCorrectness, criteria判断 actual output 相对 expected output 是否正确, evaluation_params[SingleTurnParams.ACTUAL_OUTPUT, SingleTurnParams.EXPECTED_OUTPUT], strict_modeTrue, )DAG确定性的多步判断。适合必须按步骤判断的规则比如先检查是否索要订单号再检查是否给出查询途径。DAG 把评估拆成一棵决策树每个节点可以是代码判断或一次 LLM 调用路径确定、结果可复现。边界一句话标准模糊选 G-Eval规则清晰选 DAG。把评估接入日常流程抓住三点CI 回归测试测试用例写成 pytest 文件用deepeval test run执行任一指标低于阈值即判失败直接卡住合并。生产流量监控给应用函数加observe装饰器追踪模块线上每次调用都留下 trace可抽样离线评估问题在用户投诉前被发现。版本对比每次换模型、改 prompt 都记录一份结果改动前后对比分数而不是凭感觉发布。常见坑与避坑建议这一节把大家最容易踩的四个坑提前排掉一次上十几个指标成本翻着倍涨出了问题还不知道该修哪个。从 2-3 个指标起步确认有效再加。阈值照搬默认 0.5不同业务的及格线完全不同。先拿一批你人工判过好坏的样本校准阈值再固定下来。忽略评估自身的成本每个指标每次运行都要调 LLM 裁判。控制样本量、开启缓存大批量用异步执行。只看平均分平均分能掩盖个别用例的严重回归。盯单个用例的分数变化比盯整体均值更能发现问题。把评估再往前推一步评估体系的价值不在某一次跑分而在于让每次改动都有数字背书。建议你现在就用上面的 15 行代码跑通第一个用例再按场景表补齐你业务的指标。进阶资源指标源码目录40 内置指标的完整实现与文档字符串入门示例代码含 pytest 参数化与超参数记录官方文档目录指标定义、数据集与评估流程的完整说明【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepEval 完整指南：LLM 评估指标快速上手，从 RAG 到对话一次搞定
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( inputWhat if these shoes dont fit?, actual_outputWe offer a 30-day full refund at no extra cost., expected_outputYou can get a free full refund within 30 days., ) metric AnswerRelevancyMetric(threshold0.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答案相关性回答一个问题这个答案是否切题、有没有绕开用户真正想问的事threshold0.7表示及格线设为 0.7。evaluate接收两个列表——测试用例和指标——批量执行并返回EvaluationResult每个用例给出success是否全部达标metrics_data里则包含每个指标的分数score和评分理由reason。读结果的顺序建议先看reason判断裁判的打分逻辑是否符合你的预期再看分数是否符合直觉。这一步能帮你发现裁判理解歪了这种评估体系自身的 bug。更多可运行的变体见 入门示例。按场景挑选评估指标这一节解决我到底该用哪几个指标的问题。DeepEval 内置 40 指标全量定义在 指标源码目录按场景各挑几个就够场景推荐指标挑选要点RAG 检索上下文相关性Contextual Relevancy、忠实度Faithfulness、答案相关性Answer Relevancy把检索器和生成器分开考核忠实度看答案的说法能否在检索材料里找到出处智能体 / 工具调用任务完成度Task Completion、工具使用Tool Use基于 trace 追踪数据评估重点看调没调对工具、最终办没办成事多轮对话角色一致性Role Adherence、知识保留度Knowledge Retention、轮次忠实度Turn Faithfulness必须喂完整对话历史ConversationalTestCase单看一轮没意义内容安全偏见Bias、毒性Toxicity、PII 泄露PII Leakage风险模式预定义判断成本低适合大批量跑多模态图像一致性Image Coherence、图像帮助度等考察图文跨模态是否一致见 多模态指标目录指标不是越多越好建议总数不超过 5 个其中 2-3 个通用指标如相关性、忠实度保底1-2 个业务指标如客服友好度体现你的产品差异。指标贪多成本先爆信号也稀释。内置指标不够用自定义与自动化这一节回答两件事内置指标覆盖不了的业务标准怎么补评估怎么从手动跑一次变成每次改动都自动跑。G-Eval用自然语言定标准。主观评价类需求客服语气是否友好、回答是否符合品牌口吻很难写成规则G-Eval 让你直接用一段自然语言描述评价标准再由裁判模型按标准打分from deepeval.metrics import GEval from deepeval.test_case import SingleTurnParams correctness GEval( nameCorrectness, criteria判断 actual output 相对 expected output 是否正确, evaluation_params[SingleTurnParams.ACTUAL_OUTPUT, SingleTurnParams.EXPECTED_OUTPUT], strict_modeTrue, )DAG确定性的多步判断。适合必须按步骤判断的规则比如先检查是否索要订单号再检查是否给出查询途径。DAG 把评估拆成一棵决策树每个节点可以是代码判断或一次 LLM 调用路径确定、结果可复现。边界一句话标准模糊选 G-Eval规则清晰选 DAG。把评估接入日常流程抓住三点CI 回归测试测试用例写成 pytest 文件用deepeval test run执行任一指标低于阈值即判失败直接卡住合并。生产流量监控给应用函数加observe装饰器追踪模块线上每次调用都留下 trace可抽样离线评估问题在用户投诉前被发现。版本对比每次换模型、改 prompt 都记录一份结果改动前后对比分数而不是凭感觉发布。常见坑与避坑建议这一节把大家最容易踩的四个坑提前排掉一次上十几个指标成本翻着倍涨出了问题还不知道该修哪个。从 2-3 个指标起步确认有效再加。阈值照搬默认 0.5不同业务的及格线完全不同。先拿一批你人工判过好坏的样本校准阈值再固定下来。忽略评估自身的成本每个指标每次运行都要调 LLM 裁判。控制样本量、开启缓存大批量用异步执行。只看平均分平均分能掩盖个别用例的严重回归。盯单个用例的分数变化比盯整体均值更能发现问题。把评估再往前推一步评估体系的价值不在某一次跑分而在于让每次改动都有数字背书。建议你现在就用上面的 15 行代码跑通第一个用例再按场景表补齐你业务的指标。进阶资源指标源码目录40 内置指标的完整实现与文档字符串入门示例代码含 pytest 参数化与超参数记录官方文档目录指标定义、数据集与评估流程的完整说明【免费下载链接】deepevalThe LLM Evaluation Framework项目地址: https://gitcode.com/GitHub_Trending/de/deepeval创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考