三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

RAG评估工具深度对比：Ragas与DeepEval的核心差异与选型指南

发布时间：2026/8/13 4:08:48 三亩地 编程学习日记
RAG评估工具深度对比：Ragas与DeepEval的核心差异与选型指南

1. 项目缘起：为什么我们需要认真对待RAG评估？

如果你最近在折腾RAG（检索增强生成）项目，大概率会和我有同样的感受：模型换了一个又一个，向量数据库从Milvus试到Pinecone，提示词工程调得眼花缭乱，但每次改动后，心里都没底。这个新版本到底比旧版本好多少？是检索更准了，还是生成更流畅了？用户问“公司今年的战略目标是什么”，系统却回答“公司的咖啡机型号是XXX”，这种让人哭笑不得的“幻觉”到底减少了没有？

这就是RAG评估要解决的问题。它不是一个“有了挺好，没有也行”的装饰品，而是项目从“玩具Demo”走向“生产级应用”的生死线。没有量化评估，所有的优化都像是在黑暗中摸索，全凭感觉。而一旦开始寻找评估工具，两个名字会高频出现：Ragas和DeepEval。它们都宣称能帮你系统化地评估RAG管道，但究竟该选哪个？这不仅仅是选工具，更是选择一套评估方法论和未来技术栈的适配方向。

我花了相当一段时间，在几个真实的业务场景中深度使用了这两套框架。从简单的知识库问答，到复杂的多跳推理和Agent场景，我都用它们跑了一遍。这篇文章，就是这次深度对比的完整记录。我不会只罗列功能表格，而是会结合真实踩坑经历，告诉你每个工具的设计哲学、擅长领域、那些官方文档没写的“坑”，以及在不同阶段、不同需求的团队面前，那个“更优解”究竟是谁。

2. 核心定位与设计哲学：两种不同的评估“世界观”

在深入代码和指标之前，理解Ragas和DeepEval背后的设计哲学至关重要。这决定了它们解决问题的根本方式。

2.1 Ragas：以“度量”为中心的模块化评估库

Ragas的核心理念是“评估即度量”。它将自己定位为一个提供丰富、可靠评估指标的“工具箱”。它的设计非常Unix哲学：每个评估维度（如事实性、相关性、忠实度）都是一个独立的、可组合的“度量器”（Metric）。你可以像搭积木一样，选取需要的度量器，组装成你的评估流程。

这种设计带来的优势非常明显：

  1. 灵活性与透明度高：你可以清晰地知道每个分数是怎么算出来的。例如，它的“答案正确性”（Answer Correctness）度量，通常会分解为“答案相似度”和“事实一致性”两个子分数，再综合起来。整个过程是可解释、可追溯的。
  2. 专注于核心算法：Ragas团队花了大量精力在研究如何用LLM（大语言模型）或传统NLP方法更好地计算这些抽象指标。比如，它的“上下文相关性”（Context Relevance）度量，会巧妙地让LLM判断“如果去掉文档中的某段，是否还能回答这个问题”，以此来量化检索内容的质量。
  3. 与框架无关：Ragas不关心你的RAG管道是用LangChain、LlamaIndex还是自定义代码构建的。你只需要给它最终的问题（query）、检索到的上下文（contexts）和生成的答案（answer），它就能进行评估。这种“事后评估”的模式，使其侵入性极低。

但硬币的另一面是：

  • “管道”概念弱：Ragas本身不提供构建、运行RAG管道的组件。它假设你已经有了一个能产出(query, contexts, answer)三元组的系统。你需要自己写代码来生成这些评估样本。
  • 实验管理需外接：评估会产生大量数据（问题、上下文、答案、各项分数）。Ragas本身不提供实验跟踪、版本对比、结果可视化的强大内置工具。你通常需要借助MLflow、Weights & Biases（W&B）或自定义数据库来管理这些实验历史。

简单说，Ragas像一个提供顶级测量仪器的实验室，但实验室的布局、实验流程的记录本，需要你自己准备。

2.2 DeepEval：以“测试”为中心的端到端评估框架

DeepEval则采用了完全不同的视角。它的核心理念是“评估即测试”，深受软件工程中单元测试思想的启发。在DeepEval的世界里，你对RAG系统的每一个质量要求，都应该被定义为一个“测试用例”（TestCase）。

这种范式转换带来了独特的价值：

  1. 开发者友好，集成度高：DeepEval提供了evaluate()方法，你甚至可以直接把你的RAG链（比如一个LangChain Chain）丢给它，它会自动运行测试、生成报告。它内置了与LangChain、LlamaIndex的深度集成，减少了大量的胶水代码。
  2. 强大的实验管理：DeepEval自带一个轻量级的“实验”跟踪系统。每次评估运行都会被记录，你可以方便地对比不同版本（比如调整了检索Top-K参数前后）的测试通过率、分数变化。这为持续迭代提供了直接支持。
  3. 面向生产流程：它的“测试”思维天然契合CI/CD（持续集成/持续部署）流程。你可以像跑单元测试一样，在代码合并前自动运行RAG评估测试，确保新改动没有导致质量回退。

当然，这种设计也有其权衡：

  • 黑盒化程度相对较高：为了提供开箱即用的便利性，DeepEval将很多评估逻辑封装了起来。虽然你也可以自定义度量标准，但它的默认测试用例（如AnswerRelevancyTest,FaithfulnessTest）的内部计算细节，不如Ragas的度量器那样透明和易于拆解。
  • 框架绑定稍强：虽然它也支持原始数据输入，但其最流畅的体验往往在与LangChain等流行框架配合时才能体现。如果你的RAG系统是完全自研的底层架构，可能需要做一些适配工作。

DeepEval更像一个配备了标准操作流程、自动记录仪和对比分析功能的现代化测试车间。你开车（RAG系统）进去，它给你出一份详细的性能检测报告。

特性维度RagasDeepEval
核心范式度量 (Metrics)测试 (Tests)
设计哲学提供精准的测量工具提供完整的评估工作流
集成方式非侵入式，事后评估侵入式较强，可集成到管道中
实验管理需借助外部工具 (W&B, MLflow)内置轻量级实验跟踪与对比
上手难度中等，需自行组织评估流程较低，提供更“傻瓜式”的入口
定制灵活性极高，可深度定制和组合度量高，但默认封装较多

3. 关键评估指标深度拆解：它们到底在测什么？

无论是Ragas还是DeepEval，评估的核心都围绕一组关键的指标展开。理解这些指标的具体含义和计算方式，比单纯比较分数高低重要得多。

3.1 事实性与忠实度：你的AI在“胡说八道”吗？

这是RAG评估的生命线。目标是确保生成的答案严格基于提供的上下文，没有捏造信息（幻觉）。

  • Ragas的实现 (faithfulness)： Ragas的做法非常直观。它会要求LLM（默认是gpt-3.5-turbo）执行以下步骤：

    1. 从生成的答案中，提取所有独立的、可验证的“事实陈述”。
    2. 针对每一个事实陈述，判断它是否能够从给定的上下文中推断出来。
    3. 最终分数是（可被上下文支持的事实数）/（总事实数）。

    实操心得：Ragas的faithfulness度量对LLM的指令遵循能力很敏感。有时LLM会过度“严格”，将一些合理的同义转述或总结也判为不支持。在实践中，我通常会用一个更强大的LLM（如GPT-4）作为这个度量的评估模型，虽然成本高，但结果更可靠，尤其是在处理复杂、专业的文本时。

  • DeepEval的实现 (FaithfulnessTest)： DeepEval的FaithfulnessTest在逻辑上与Ragas类似，但更强调“测试”结果。它输出的是一个“通过/失败”的布尔值，以及一个置信度分数。其默认阈值通常设置得比较保守（例如，任何无法被支持的事实都会导致测试失败）。 它的一个便利之处在于，当测试失败时，报告会明确指出是答案中的哪一部分构成了“幻觉”，这对于调试非常有帮助。

    关键差异点：Ragas给出的是一个连续分数（0到1），让你知道“幻觉”的程度；而DeepEval默认给出的是一个二元的判定，更符合“测试”的思维——要么通过，要么不通过。当然，DeepEval也允许你调整阈值或查看原始分数。

3.2 答案相关性与正确性：答非所问 vs 答得不准

这两个指标经常被混淆，但它们衡量的是不同的事。

  • 答案相关性 (Answer Relevancy)：答案是否直接回应了问题本身？即使答案本身是事实，但如果它针对的是另一个问题，那也毫无意义。

  • 答案正确性 (Answer Correctness)：在答案相关的前提下，它是否准确、完整地包含了上下文中的所有正确信息？

  • Ragas的精细划分：

    • answer_relevancy：这个度量很巧妙。它会让LLM根据生成的答案，反过来“生成”一个问题。然后计算这个生成的问题与原始问题的相似度。如果答案高度相关，那么从答案反推的问题应该和原问题很接近。
    • answer_correctness：这是一个复合度量。它结合了answer_similarity（将标准答案与生成答案进行对比）和faithfulness。如果没有标准答案，它会主要依赖faithfulness。这体现了Ragas模块化的优势——你可以清晰地看到正确性是如何被分解和计算的。

  • DeepEval的整合测试： DeepEval的AnswerRelevancyTest主要对应“相关性”检查。它的ContextualRelevancyTest和ContextualPrecisionTest则更侧重于评估检索阶段的质量，即检索到的上下文是否与问题相关。对于“正确性”，DeepEval更依赖于你提供“标准答案”（Ground Truth），通过GroundednessTest或自定义的相似度计算来评估。

    踩坑记录：在评估一个法律咨询RAG系统时，我发现answer_relevancy分数很高，但answer_correctness很低。仔细分析发现，系统生成的答案格式规范、语言专业，看起来非常“相关”，但其中引用的法律条款版本是过时的。这说明，相关性高不等于正确性高。Ragas的这种指标分离，帮助我精准定位到了问题是出在知识库的更新上，而不是检索或生成模型上。

3.3 上下文相关性：垃圾进，垃圾出

这个指标评估的是检索器的性能：你捞上来的那些文档片段，到底有多少是真正有用的？

  • Ragas的context_relevancy： 这是我个人非常欣赏Ragas的一个度量。它的计算逻辑是：

    1. 将检索到的长上下文拆分成更小的句子或片段。
    2. 针对每个片段，让LLM判断：“如果从上下文中移除这个片段，系统是否还能回答这个问题？”
    3. 最终分数是（必要的片段数）/（总片段数）。 这种方法能有效识别出那些虽然被检索出来，但对回答问题毫无帮助的“噪声”文本。

  • DeepEval的ContextualRelevancyTest： DeepEval也提供了类似的测试。它更直接地让LLM判断每个检索到的上下文是否与问题相关。它的输出会列出哪些上下文被判定为相关，哪些不相关。

    使用建议：如果你的检索结果经常包含大量无关文本（例如，因为使用了基于段的检索，而段落本身包含多种信息），Ragas的context_relevancy能给你一个更精细、量化的“信噪比”。如果你只需要一个快速的、二元的“相关/不相关”过滤视图，DeepEval的测试更直观。

3.4 其他重要维度

  • 毒性/安全性：DeepEval内置了ToxicityTest等安全性测试，这对于面向公众的应用至关重要。Ragas目前在这方面需要更多自定义。
  • 延迟与成本：虽然这不是质量指标，但却是生产部署的关键。两个框架都允许你记录每次LLM调用的延迟和token消耗。Ragas需要你手动集成或使用其回调系统；DeepEval在实验报告中会直接展示这些信息。
  • 自定义度量/测试：两者都支持。Ragas允许你继承Metric类，实现自己的init_model和score方法。DeepEval允许你继承TestCase类，实现measure和is_successful方法。Ragas的接口更偏向于“计算一个分数”，DeepEval的接口更偏向于“运行一个测试并判断通过与否”。

4. 实战对比：从安装到出报告的全流程体验

理论说再多，不如亲手跑一遍。我们用一个简单的场景来对比：评估一个基于公司内部文档的问答系统。

场景：我们有100个预设的问答对（query和ground truth answer）。我们的RAG系统会针对每个query，检索3段上下文，并生成一个答案。

4.1 使用Ragas进行评估

# 安装：pip install ragas import asyncio from datasets import Dataset from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy, context_relevancy, answer_correctness # 1. 准备数据。Ragas期望的数据格式是Hugging Face Dataset。 # 你需要自己运行RAG管道，生成以下数据。 data = { "question": ["公司今年的营收目标是多少？", "我们的主要竞争对手是谁？"], "answer": ["根据2024年规划，公司营收目标为1亿美元。", "主要竞争对手包括A公司和B公司。"], "contexts": [ ["2024年公司战略规划文档指出，营收目标设定为1亿美元，同比增长20%。", "公司文化强调创新...", "办公室位于硅谷..."], ["市场竞争分析报告显示，A公司在北美市场份额领先。", "B公司在亚太地区是我们的主要挑战者。", "公司团建活动将于下周举行。"] ], "ground_truth": ["1亿美元", "A公司和B公司"] # 可选，用于answer_correctness } dataset = Dataset.from_dict(data) # 2. 选择评估指标并运行评估。注意：evaluate默认是异步的。 async def run_evaluation(): result = await evaluate( dataset, metrics=[faithfulness, answer_relevancy, context_relevancy, answer_correctness], llm=your_llm, # 可配置，如OpenAI、AzureOpenAI等 embeddings=your_embeddings # 用于answer_relevancy等需要向量计算的指标 ) return result # 同步运行 loop = asyncio.get_event_loop() evaluation_result = loop.run_until_complete(run_evaluation()) # 3. 查看结果 print(evaluation_result) # 输出是一个包含各指标分数的数据集，例如： # {'faithfulness': 0.95, 'answer_relevancy': 0.88, 'context_relevancy': 0.67, 'answer_correctness': 0.90}

Ragas流程的体会：

  1. 数据准备全靠自己：你需要编写一个循环，遍历你的100个问题，调用你的RAG系统，收集答案和上下文，然后组装成Dataset。这个过程有点繁琐，但给了你最大的控制权。
  2. 异步评估：evaluate是异步函数，这在评估大量数据时能有效利用IO等待时间，提升效率。但需要你处理好异步环境（如在Jupyter notebook里用await，或在脚本里用asyncio.run）。
  3. 结果分析：输出是一个字典或包含每行分数的新Dataset。要生成漂亮的对比图表或历史趋势，你需要自己用pandas、matplotlib或者接入MLflow/W&B。

4.2 使用DeepEval进行评估

# 安装：pip install deepeval from deepeval import evaluate from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric, ContextualRelevancyMetric from deepeval.test_case import LLMTestCase, LLMTestCaseParams from your_rag_system import YourRAGPipeline # 假设你的RAG系统封装成了一个类 # 1. 创建测试用例列表 test_cases = [] rag_pipeline = YourRAGPipeline() for query, ground_truth in your_qa_pairs: # 运行你的RAG管道 result = rag_pipeline.run(query) generated_answer = result.answer retrieval_context = result.contexts # 构建DeepEval测试用例 test_case = LLMTestCase( input=query, actual_output=generated_answer, expected_output=ground_truth, # 可选 context=retrieval_context ) test_cases.append(test_case) # 2. 定义要使用的评估指标（在DeepEval中叫Metrics，但概念上更接近Ragas的度量） faithfulness_metric = FaithfulnessMetric(threshold=0.7) # 设置通过阈值 answer_relevancy_metric = AnswerRelevancyMetric(threshold=0.8) contextual_relevancy_metric = ContextualRelevancyMetric(threshold=0.5) # 3. 运行评估 evaluation_result = evaluate( test_cases=test_cases, metrics=[faithfulness_metric, answer_relevancy_metric, contextual_relevancy_metric] ) # 4. 查看丰富的报告 print(evaluation_result) # 打印整体摘要 # DeepEval会自动生成一个详细的HTML报告，保存在本地，包含每个测试用例的详情、通过/失败状态、分数、使用的LLM、耗时等。

DeepEval流程的体会：

  1. 与管道集成更紧密：LLMTestCase的创建过程自然地嵌入了你运行RAG的循环中。如果你的RAG系统本身就是基于LangChain的Chain，DeepEval有更简洁的集成方式（如DeepEvalCallbackHandler）。
  2. 同步评估：evaluate是同步函数，逻辑更直白，对新手更友好。
  3. 开箱即用的报告：这是DeepEval的一大亮点。运行完毕后，它会自动生成一个结构清晰的HTML报告，你无需任何额外配置。报告里可以看到每个测试用例的详情，哪个失败了，为什么失败（例如，指出了幻觉的具体句子），以及所有测试的总体通过率、平均分、耗时统计。这对于团队协作和快速汇报价值巨大。

4.3 性能与成本考量

  • LLM调用开销：两者都严重依赖LLM（如GPT-4）作为“裁判”，这是评估成本的大头。100个问题，每个问题评估4个指标，可能意味着400次LLM调用。Ragas和DeepEval在这方面没有本质区别，成本取决于你选择的评估模型和评估的数据量。
  • 本地模型支持：两者都支持使用本地部署的模型（如通过Ollama调用Llama 3、Qwen等）作为评估器，这可以显著降低成本，但评估质量可能有所波动，需要仔细验证。
  • 速度：对于大规模评估，Ragas的异步评估模式在理论上可能更有优势。但DeepEval的同步模式在代码逻辑上更简单。实际速度差异更多取决于网络和LLM API的响应速度。

5. 进阶场景与生态整合：谁更能适应复杂需求？

当你的RAG项目从原型走向复杂生产系统时，评估需求也会升级。

5.1 处理复杂问答（多跳推理、Agentic RAG）

对于需要串联多次检索-生成循环的Agentic RAG，或者需要综合多份文档才能回答的多跳问题，评估变得更具挑战性。

  • Ragas的应对：由于其模块化设计，你可以为每个循环步骤单独计算指标。例如，你可以分别评估第一跳检索的上下文相关性、中间答案的忠实度，以及最终答案的综合正确性。但这需要你精心设计评估流水线，手动组织多步骤的数据流。
  • DeepEval的应对：DeepEval的TestCase可以容纳更复杂的数据结构。你可以将多轮对话的历史、每一步的中间上下文和答案都封装进一个测试用例，然后编写自定义的Metric来评估整个推理链的连贯性和最终正确性。其内置的实验对比功能，在这里尤其有用，可以对比不同Agent策略的整体表现。

经验之谈：在评估一个多跳推理的RAG（例如，先查产品规格，再根据规格查兼容配件）时，我最终选择结合两者。用Ragas精细评估每一步的“上下文相关性”和“忠实度”，因为它的度量更透明；同时用DeepEval来运行端到端的“最终答案正确性”测试，并利用其报告功能来呈现整体通过率，方便向非技术同事展示进展。

5.2 与MLOps/LLMOps流水线集成

持续的评估需要融入开发流程。

  • Ragas：它更像一个“库”，所以你需要自己搭建集成。常见的做法是：
    • 将评估脚本封装成Pipeline的一个阶段。
    • 使用ragas.callbacks将评估结果实时记录到MLflow或W&B中。这样，每次实验的指标都能被跟踪和可视化。
    • 在CI/CD中，你可以编写一个脚本，在新代码合并前，用Ragas在标准测试集上跑一遍，如果关键指标（如faithfulness）下降超过阈值，则阻止合并。
  • DeepEval：在这方面提供了更“原生”的支持。
    • 它的evaluate函数可以直接在CI中运行，并根据测试的总体通过率返回成功或失败状态码。
    • 其内置的实验功能可以自动与每次Git提交关联，形成评估历史。
    • 它甚至提供了与Github Actions等CI工具的初步集成示例。

5.3 自定义评估需求

两个框架都支持高度自定义。

  • 在Ragas中自定义一个Metric：

    from ragas.metrics.base import Metric from ragas.llms import BaseRagasLLM class MyCustomClarityMetric(Metric): name = "clarity" def __init__(self, llm: BaseRagasLLM): self.llm = llm async def _ascore(self, row): # row 包含 question, answer, contexts 等 prompt = f"""请评估以下答案的清晰度（1-10分）： 问题：{row['question']} 答案：{row['answer']} 请只输出一个整数分数。""" score_text = await self.llm.generate_text(prompt) return int(score_text) / 10.0 # 归一化到0-1

    你需要处理LLM调用、解析、错误处理等细节，灵活性极高。

  • 在DeepEval中自定义一个Metric：

    from deepeval.metrics import BaseMetric from deepeval.test_case import LLMTestCase class MyCustomClarityMetric(BaseMetric): def __init__(self, threshold: float = 0.7): self.threshold = threshold def measure(self, test_case: LLMTestCase): # 实现你的评估逻辑，返回一个分数 self.score = calculate_clarity(test_case.input, test_case.actual_output) self.success = self.score >= self.threshold return self.score def is_successful(self): return self.success

    你需要实现measure和is_successful方法，框架会帮你处理测试用例的循环和报告集成。

自定义难度对比：Ragas的自定义更底层，你需要更熟悉其异步框架和内部数据流。DeepEval的自定义接口更规整，与它的测试范式结合得更紧密。

6. 决策指南：我到底该选哪一个？

经过上面的对比，选择变得清晰。这取决于你的团队阶段、技术栈和核心需求。

选择 Ragas，如果你：

  1. 是研究人员或极度重视评估过程透明度的工程师：你需要深入理解每一个分数是如何计算的，可能还要修改其中的算法。Ragas的模块化设计和开源代码提供了这种可能性。
  2. 已经有一套成熟的MLOps流水线（如MLflow、W&B）：你只需要一个强大的“度量计算引擎”，实验跟踪、可视化、版本管理你已经有更好的专业工具负责。Ragas能完美地嵌入这个生态。
  3. 评估场景非常特殊，需要高度定制的度量组合：Ragas的“乐高积木”式设计，让你可以自由地组合、修改甚至从头创建度量，适应学术界或工业界前沿的评估需求。
  4. 希望评估逻辑与框架完全解耦：你的RAG系统可能是用非常冷门的框架或纯自研代码构建的，你只需要输入输出数据。

选择 DeepEval，如果你：

  1. 追求快速上手和开箱即用的体验：你想在几分钟内就开始评估，并立刻获得一份能发给老板或团队看的漂亮报告。DeepEval的“测试”思维和内置报告极大地降低了入门门槛。
  2. 团队具有软件工程背景，熟悉单元测试：“测试驱动开发”的理念可以无缝迁移到RAG评估上。定义测试用例、设置通过阈值、集成到CI/CD，这一套流程非常自然。
  3. 项目处于快速迭代的开发期：你需要频繁地对比不同版本（不同检索模型、不同提示词、不同分块策略）的效果。DeepEval内置的实验对比功能就是为此而生。
  4. 主要使用LangChain或LlamaIndex：DeepEval与这些框架的集成度最高，用最少的代码就能完成评估。

一个更实际的建议：混合使用

在我的多个项目中，我并没有非此即彼。我经常采用一种混合策略：

  • 日常迭代与CI/CD：使用DeepEval。我为核心功能编写一组关键的测试用例（如FaithfulnessTest,AnswerRelevancyTest），并将其集成到Git的pre-commit hook或CI流水线中。任何导致测试大规模失败的代码都无法合并。DeepEval的报告能快速定位问题范围。
  • 定期深度评估与模型选型：使用Ragas。每两周或每个月，我会在一个更大的、更具代表性的测试集上，运行一套完整的Ragas评估（包含更多细粒度指标）。这个过程更耗时，但能提供全方位的洞察，用于指导重要的技术决策，比如是否要升级嵌入模型、调整重排序策略等。Ragas提供的详细分数分布和可解释性，在这里至关重要。

7. 避坑总结与最佳实践

无论选择哪个工具，以下几点经验都能帮你少走弯路：

  1. 评估集的质量决定天花板：你的测试问题集（Evaluation Dataset）必须高质量、有代表性、覆盖核心用户场景。垃圾问题进，垃圾评估出。花时间构建和维护一个好的评估集，是ROI最高的事情。
  2. 警惕评估模型的偏见：你用LLM（如GPT-4）来评估你的RAG系统，这个“裁判”本身也有偏好和局限性。它可能对某种写作风格打分更高。定期用人工抽查来校准自动评估的结果，尤其是对关键业务场景。
  3. 成本控制是关键：自动评估很烧钱。对于大规模评估，考虑：
    • 使用更便宜的模型（如GPT-3.5-Turbo）进行初筛。
    • 对本地模型（如Qwen、Llama）的评估结果进行验证后，将其用于非关键指标。
    • 采用抽样评估，而不是全量评估。
  4. 不要唯分数论：faithfulness0.95一定比0.93好吗？不一定。要看分数的分布和稳定性。结合人工检查那些得分边缘的案例（比如分数在0.5-0.7的答案），往往能发现系统最深层的问题。
  5. 从单一指标开始：不要一开始就试图评估所有维度。先从最核心的忠实度（Faithfulness）开始。确保你的系统不“胡编乱造”，这是所有其他改进的基础。然后再逐步加入相关性、正确性等指标。

最后，我想说的是，Ragas和DeepEval都是优秀的工具，它们代表了RAG评估领域两种不同但都极其重要的思路。Ragas像一把精准的瑞士军刀，为专家提供了无与伦比的灵活性；DeepEval像一套高效的自动化测试流水线，为工程团队带来了可重复、可集成的质量保障。理解它们的差异，根据你团队当前的真实痛点做出选择，或者聪明地将它们结合起来使用，才是让AI应用真正变得可靠、可控的关键一步。评估不是终点，而是持续优化的开始。当你开始认真测量，改进的方向自然会变得清晰。

编程学习 学习日记 实战经验
← 返回列表