登录
首页 >  文章 >  python教程

DeepEval与RAGAS:LLM评估新工具推荐

时间:2026-04-16 13:11:53 320浏览 收藏

本文深入剖析了在RAG系统评估中DeepEval与Ragas两大主流Python框架的实际落地痛点:DeepEval因强制依赖expected_output而难以适配无标准答案的RAG场景,Ragas的context_recall则因严格依赖人工标注的ground_truth_contexts导致易返0分,二者在retrieval_context格式、嵌入模型配置及指标默认行为上存在隐蔽但关键的不兼容性;文章不仅直击报错根源(如ValidationError、静默丢数据、embedding卡死),更给出可立即生效的实操方案——从伪造占位字段、统一字符串拼接、手动加载轻量模型,到按需启用指标和规避标注瓶颈,真正帮开发者绕过文档没写的“坑”,把精力聚焦在评估逻辑本身而非框架调试上。

Python LLM 评估的 DeepEval / RAGAS 框架

DeepEval 报错 ValidationError 说 missing expected_output

DeepEval 默认走“有标准答案”的评估路径,如果你在测 RAG 场景(比如问答、摘要),没给 expected_output 就直接跑 AnswerRelevancyMetricFaithfulnessMetric,它会立刻抛 ValidationError —— 不是因为你写错了,而是它根本没设计成支持“无参考答案”的评估模式。

实操建议:

  • 对 RAG 输出做无参考评估(比如只看是否忠实于上下文),改用 Ragasfaithfulnessanswer_relevance,它们天然接受空 expected_output
  • 非要用 DeepEval?得伪造一个 expected_output,哪怕填 "N/A" 或空字符串,再配合 ignore_errors=True 参数绕过校验(但注意:部分指标如 AnswerCorrectnessMetric 仍会失效)
  • 检查你传入的 test_case 是不是用了 LLMTestCase 而不是 LLMTestCase 的子类(比如 RAGTestCase)——后者才支持 retrieval_context 字段,前者硬塞会静默丢数据

Ragas 的 context_recall 总是返回 0.0

context_recall 是唯一需要人工标注“哪些上下文片段真正支撑了答案”的指标,不是模型自己能猜出来的。如果你没提供 ground_truth_contexts(即标注好的、真正被用到的 chunk 列表),它就默认找不到依据,统一判 0.0。

实操建议:

  • ground_truth_contexts 必须是字符串列表,每个元素对应一个原始 chunk 的完整文本,不能是 ID、索引或摘要
  • 确保这些 chunk 和你实际喂给 LLM 的 retrieval_context 内容完全一致(包括换行、标点、空格);差一个句号都可能匹配失败
  • 如果人工标注成本高,先别用 context_recall,改用 context_precision(它只看你检索出的 chunk 里有多少真被用了,不需要 ground truth)

DeepEval 和 Ragas 混着用时,retrieval_context 格式不兼容

DeepEval 的 LLMTestCase 要求 retrieval_context 是字符串列表,而 Ragas 的 SingleTurnSample 接受字符串或字符串列表——但当你把 DeepEval 的 list 直接塞进 Ragas,某些指标(比如 context_relevancy)内部会把它当单个长字符串切分,导致误判。

实操建议:

  • 统一用字符串拼接: "\n\n".join(retrieval_context_list) 再传给 Ragas,避免它误触发 list 处理逻辑
  • DeepEval 中若要保留 chunk 边界信息,别用 retrieval_context 字段,改存到自定义字段如 metadata["chunks"],后续单独处理
  • 两个框架都调用 LLM 打分时,注意它们默认用的模型不同:DeepEval 走 gpt-4(可配),Ragas 默认用 gpt-3.5-turbo,混用前先对齐 base model,否则分数不可比

本地跑 Ragas 指标卡在 embeddings 步骤

Ragas 默认启用 HuggingFaceEmbeddings(基于 sentence-transformers/all-MiniLM-L6-v2),首次运行会自动下载 400MB 模型。如果网络受限或没设缓存路径,它会在 transformers 的默认目录下卡住,且不报错,只干等。

实操建议:

  • 手动下载模型:去 HF 页面pytorch_model.bin + config.json + tokenizer.json,解压到本地路径如 /models/minilm,再初始化时指定:HuggingFaceEmbeddings(model_name="/models/minilm")
  • 临时关 embedding:用 RagasEvaluator(..., embeddings=None),跳过所有需向量的指标(context_relevancy, answer_similarity 等),先验证 pipeline 其他环节
  • 别用 ragas.evaluate() 一键全跑——它默认开全部指标,包括最耗 embedding 的几个;按需传 metrics=[faithfulness, answer_relevance]
RAG 评估真正的麻烦不在装包或写 metric 名,而在数据格式的隐式约定和标注成本。哪个字段该是 list、哪个必须是 string、哪个空值能忍哪个空值直接崩——这些细节不试三次根本记不住。

本篇关于《DeepEval与RAGAS:LLM评估新工具推荐》的介绍就到此结束啦,但是学无止境,想要了解学习更多关于文章的相关知识,请关注golang学习网公众号!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>