编者按： 随着大语言模型应用从简单的文本生成，发展到复杂的多轮对话机器人、检索增强生成（RAG）系统乃至智能体（Agent），我们应如何科学、有效地评估它们的性能，确保其稳定可靠？

我们今天为大家带来的文章，作者的观点是，对现代 LLM 应用的评估，必须超越传统的 NLP 评估指标，转向一个分场景、系统化的评估体系，综合运用新兴的评价指标与自动化框架，从而全面地衡量系统的综合表现。

作者系统梳理了从传统 NLP 评估指标（如 BLEU、ROUGE）到现代 LLM 基准测试（如 MMLU）的演进，并重点阐释了"LLM-as-a-judge"这一新兴评估范式。文章进一步深入探讨了多轮对话系统、RAG 系统及智能体的关键评估维度，并对比了主流评估框架（如 RAGAS、DeepEval、OpenAI Evals）的功能差异与适用场景，为开发者构建可靠、可追踪的 LLM 应用提供了清晰指引。

作者 | Ida Silfverskiold

编译 | 岳扬

Agentic AI 评估主要在于测试 LLM 应用，以确保其表现稳定。

这或许不是很吸引人的话题，但正受到越来越多企业的重视。因此，有必要深入探讨应追踪哪些指标来有效衡量性能。

此外，在每次推送代码变更时实施恰当的评估，也有助于避免系统出现混乱。

为此，本文研究了多轮对话机器人、RAG 及 Agentic 应用的常用评估指标。

我还简要梳理了 DeepEval、RAGAS 和 OpenAI 评估库等框架，助您根据使用场景选择合适的工具。

本文分为两部分。新手可从第一部分读起，其中介绍了 BLEU、ROUGE 等传统评估指标，提及了一些 LLM 的基准测试，并讲解在评估中使用另一个大语言模型来充当"裁判"或"评判者"的理念。

若您已熟悉上述内容，可直接跳到第二部分阅读。该部分将深入解析不同类型 LLM 应用的评估方法。

01 先前的评估方法

如果你已熟知 NLP（自然语言处理）任务的评估方式以及公共基准测试的运作机制，那么可以跳过这一部分。

如若不然，了解早期评估指标（如准确率、BLEU）的最初用途与工作原理，并理解 MMLU 等公共基准测试的运作方式，将是很有益处的。

02 评估 NLP 任务

在评估分类、翻译、摘要等传统 NLP 任务时，我们通常会借助准确率（accuracy）、精确率（precision）、F1 值、BLEU 和 ROUGE 这类传统指标。

这些指标至今仍在沿用，但主要适用于模型输出单一、易于比对"标准答案"的场景。

以文本分类任务为例，其目标是为每个文本分配一个唯一的标签。测试时，我们可以使用准确率指标，通过比较模型分配的标签与评估数据集中的参考标签，来判断其是否正确。

判断标准非常明确：如果分配了错误的标签，则得分为 0；如果分配了正确的标签，则得分为 1。

这意味着，如果我们为一个包含 1000 封邮件的垃圾邮件数据集构建分类器，并且模型正确标记了其中的 910 封，那么准确率就是 0.91。

针对文本分类场景，我们还经常使用 F1 值、精确率和召回率。

在文本摘要和机器翻译等 NLP 任务中，人们通常使用 ROUGE 和 BLEU 来衡量模型生成的译文或摘要与参考文本的匹配程度。

这两种分数都基于 n-gram 的重叠程度进行计算。尽管比较的侧重点不同（例如，BLEU 更侧重精确率，ROUGE 更侧重召回率），但其核心思想都是：共享的词语片段越多，得分就越高。

这种方式相对简单，因为如果输出文本使用了不同的措辞，得分就会较低。

所有传统指标最适用于存在标准答案的应答场景，但对于如今我们构建的 LLM 应用而言，它们往往并非最合适的选择。

03 大语言模型基准测试

如果您关注相关新闻，可能会注意到：每次新版本的大语言模型发布时，总会提及 MMLU Pro、GPQA 或 Big-Bench 等基准测试结果。

它们属于通用性评估，其正确术语应是"基准测试"而非"评估"（后者我们将在后续讨论）。

尽管针对每个模型还会进行多种评估（测试毒性、幻觉和偏见等内容），但最受关注的往往是这些更类似标准化考试或排行榜的基准测试。

像 MMLU 这样的数据集采用多选题的形式，并且已存在相当长的时间。我曾粗略地浏览过其中的内容，发现其内容质量参差不齐。

部分问题和答案相当模糊，这让我认为 LLM 提供商很可能通过针对性训练来确保模型在这些数据集上取得佳绩。

这种现象引发了公众的担忧：多数 LLM 在基准测试中的优异表现可能只是过拟合的结果，这也解释了为何我们需要更高质量的新数据集与独立的第三方评估。

04 将 LLM 用作评估器

对这些数据集进行评估时，通常仍可使用准确率和单元测试。但如今的不同之处在于，新增了所谓的"LLM-as-a-judge"方法。

为了对模型进行基准测试，团队大多仍会采用传统方法。

因此，只要是多选题或仅存在一个正确答案的情况，除了将答案与参考答案进行精确匹配外，无需其他操作。

像 MMLU 和 GPQA 这类包含多项选择题答案的数据集便属此类。

对于编程类测试（如 HumanEval、SWE-Bench），评估器可直接运行模型生成的补丁或函数。若所有测试用例通过则判定问题已成功解决，反之则失败。

然而，不难想象，当问题存在歧义或属于开放式问题时，答案可能会出现波动。这一差距催生了"LLM-as-a-judge"的兴起，即使用像 GPT-4 这样的大语言模型来为答案打分。

MT-Bench 就是采用 LLM 评分的基准测试之一，它将两个相互竞争的多轮对话答案提供给 GPT-4，并要求其判断哪个更好。

原采用人工评分的 Chatbot Arena 平台，据我了解现也已扩展融合了"LLM-as-a-judge"模式。

为了透明起见，也可使用 BERTScore 等语义评分工具进行语义相似度比对。为保持内容精炼，此处未详述现有方案。

因此，团队虽仍会使用 BLEU 或 ROUGE 这类重叠度指标进行快速校验，或在可能时采用精确匹配解析（exact-match parsing），但新的趋势是让另一个大语言模型来评判输出结果。

05 当前对 LLM 应用的评估方式

现在主要的变化是，我们不再仅仅测试 LLM 本身，而是评估整个系统。

在条件允许时，我们仍会像以前一样使用程序化的方法进行评估。

若需更精细的评估结果，可先采用成本低廉且确定性的指标（如 BLEU 或 ROUGE）来分析 n-gram 的重叠程度，不过，当前主流框架普遍采用大语言模型作为评分器进行评估。

有三个领域的评估方法和评估指标值得探讨：多轮对话系统、RAG（检索增强生成）以及智能体。

如下所示，在这三个领域已经定义了大量的评估指标。

接下来我们将简要讨论这些指标，然后再介绍那些能为我们提供帮助的不同评估框架。

06 评估多轮对话系统

首先需要构建针对多轮对话的评估体系，这类对话场景常见于聊天机器人。

与聊天机器人交互时，我们期望对话过程自然流畅、体现专业性，且能准确记住关键信息。我们希望它在整个对话过程中不离题，并切实解答用户提出的问题。

目前业界已形成一系列标准的评估指标。首要关注的是相关性（连贯性）与完整性。

相关性指标用于追踪 LLM 是否恰当地处理了用户的查询并保证不偏离主题；而若最终结果真正达成了用户目标，则完整性得分就高。

也就是说，若能追踪整个对话过程中用户的满意度，我们也能验证该系统是否真正"降低了支持成本"、增加了用户信任度，同时保持较高的"自助解决率"。

该评估体系的第二个核心维度，是知识留存能力（Knowledge Retention）与应答可靠性（Reliability）。

即：它是否记住了对话中的关键细节？能否确保不会"迷失方向"？仅记住细节还不够，它还需要能够自我纠正。

这类问题常见于智能编程工具：它们会忘记自己犯过的错误，然后一犯再犯。我们应将其记录为低可靠性或低稳定性表现。

第三部分可追踪的是角色一致性与提示词遵循度，用于检验 LLM 是否始终遵循预设角色设定，是否严格执行系统提示词中的指令。

接下来是涉及安全性的指标，例如幻觉和偏见/毒性。

追踪幻觉虽重要但也相当困难。常见做法包括设置网络搜索验证输出内容，或将输出拆分为多个可独立验证的论点后交由更大模型评判（采用 LLM-as-a-judge 模式）。

此外还有像 SelfCheckGPT 的这类方法：它通过多次调用模型处理同一提示词，检查其是否坚持原始答案以及出现分歧的次数，以此检验模型的一致性。

对于偏见/毒性检测，可采用微调分类器等 NLP 技术。

根据具体应用场景，可能还需其他定制化指标，例如代码正确性、安全漏洞数、JSON 格式合规性等。

至于如何进行评估，虽然在这些情况下标准解决方案确实常用 LLM，但并非总是必须使用它。

在可以提取正确答案的场景（例如解析 JSON），我们自然不需要使用 LLM。如我之前所说，许多 LLM 提供商也会使用单元测试对代码相关指标进行基准测试。

需要说明的是，用于评判的 LLM 并非总是超级可靠，就像它们所测量的应用一样，但此处无法提供具体数据佐证，建议您自行查阅相关研究。

07 评估检索增强生成（RAG）系统

承接多轮对话系统的评估思路，我们再来探讨 RAG 系统需要衡量的指标。

针对 RAG 系统，我们需要将评估流程拆分为两部分：分别衡量检索环节与生成环节的质量。

首先要评估的是检索环节，检验系统为特定查询抓取的文档是否精准。

若检索环节得分偏低，可通过以下方式进行优化：制定更合理的文本分块策略、更换嵌入模型、引入混合搜索与重排序技术、使用元数据进行过滤等方法。

评估检索效果时，我们既可采用依赖标注数据集的传统指标，也可以使用无需参考答案、以 LLM 作为评判者的方法。

我必须先介绍这些经典的信息检索指标，因为它们是该领域的奠基者。使用这些指标的关键在于，我们需要一套"标准答案" ------ 即针对每一个预设的查询，我们都已事先为每个文档标注好了它与该查询的相关性等级。

虽然可以使用 LLM 来构建评估所需的数据集，但评估过程无需 LLM 参与，因为数据集中已经包含了用于比对的基准分数。

最著名的 IR 指标包括 Precision@k、Recall@k 和 Hit@k。

这三个指标分别从不同角度衡量检索系统的表现：实际检索到的前 k 个文档中，有多少个是真正相关的、所有应该被检索到的相关文档（在标准答案里的）中，有多少个出现在了你检索到的前 k 个结果里、在前 k 个结果里有没有"命中"至少一个相关文档。

而 RAGAS、DeepEval 等新兴框架，则引入了一种无需参考答案且使用 LLM 对检索结果进行评判的评估指标，如上下文召回率与上下文精确度。

这些指标通过使用 LLM 作为评估者，来统计：针对给定查询，系统返回的前 k 个结果中，究竟包含了多少真正相关的文本块。

也就是说，针对给定查询，系统是否真正返回了相关文档？是否混入了过多不相关的内容以致于无法正确回答问题？

构建检索评估数据集时，可从真实日志中挖掘问题并由人工标注。

也可以利用 LLM 辅助的数据集生成器，这类工具存在于多数评估框架中，或者有独立的工具提供此功能，如 YourBench。

如果要用 LLM 搭建自己的数据集生成器，可参考以下实现方案：

# Prompt to generate questions
qa_generate_prompt_tmpl = """\
Context information is below.
 
---------------------
{context_str}
---------------------
 
Given the context information and no prior knowledge
generate only {num} questions and {num} answers based on the above context.
 
...

接下来看 RAG 系统的生成部分，这部分评估的是系统利用所提供文档回答问题的质量。

若此环节表现不佳，可采取以下措施：调整提示词模板、优化模型参数（如温度值）、更换基础模型或针对特定领域进行微调。还可引入思维链推理循环、验证答案自洽性等方法。

这方面，RAGAS 框架提供的 Answer Relevancy、Faithfulness 和 Noise Sensitivity 等指标非常实用。

这些指标分别验证：答案是否切中用户问题核心、答案中每个论断是否都有检索文档支撑、以及少量无关上下文是否会误导模型输出。

以 RAGAS 为例，它在衡量第一个指标（Answer Relevancy）时，很可能通过以下方式计算：向 LLM 提供问题、答案及检索到的上下文，要求其"评判该答案在 0-1 分范围内对问题的直接回应程度"，这个过程会返回一个原始的 0-1 分值，该分值可被用于计算整体平均值。

综上所述，我们将 RAG 系统拆分为检索和生成两个独立环节进行评估。虽然可以沿用依赖标准答案的传统信息检索指标，但也可以选择依赖大语言模型进行评分的无参考答案方法。

最后，我们需要探讨的是，智能体（Agent）技术如何扩展了我们所需追踪的指标范围，这超出了我们之前已讨论的所有内容。

08 评估智能体

对于智能体，我们的评估范畴不再局限于输出结果、对话内容或上下文质量。

如今还需评估其"行为能力"：能否完成特定任务或工作流、执行效率如何，以及是否能在适当时机调用正确的工具。

尽管各评估框架对这些指标的命名可能不同，但最核心的两项追踪指标是任务完成度 与工具调用准确率。

对于工具使用的追踪，我们需要验证智能体是否根据用户查询准确选择了对应的工具。

这需要预先编写包含真实场景的基准测试脚本，该脚本可一次性创建，并在每次系统变更时重复用于验证。

对于任务完成度，评估方法是读取完整的执行轨迹和任务目标，然后返回一个 0 到 1 之间的分数，并附上评估理由。该指标应有效衡量智能体达成任务的执行效果好坏程度。

对于智能体，你仍然需要根据您的具体应用，测试我们前面已经讨论过的其他评估维度。

需要特别说明：尽管现有框架已有不少定义好的评估指标，但你的实际使用场景可能会有所不同。了解通用评估指标是有价值的，但切勿直接假定它们完全适用于你的应用场景。

接下来，我们将概览当前主流的辅助评估框架。

09 主流评估框架概览

目前已有不少框架能协助进行评估工作，本文将重点介绍几个热门选择：RAGAS、DeepEval、OpenAI 的 Evals 库以及 MLFlow 的 Evals，并分析它们各自的优势及适用场景。

完整的评估框架清单可在此仓库（https://github.com/ilsilfverskiold/Awesome-LLM-Resources-List/blob/main/README.md[#evaluation]()-frameworks-and-add-ons ）中查看。

你也可以使用许多框架内置的评估系统（如 LlamaIndex 提供的工具），特别适合快速原型验证。

OpenAI 的 Evals 和 MLFlow 的 Evals 更像是附加组件而非独立框架，而 RAGAS 最初是专为 RAG 应用设计的指标库（尽管后续也扩展了其他指标）。

DeepEval 可能是现有框架中功能最全面的评估库。

但需要指出的是，所有框架都支持对自有数据集进行评估，以不同方式兼容多轮对话、RAG 和智能体场景，都支持 LLM-as-a-judge 模式，都允许配置自定义指标，并且都能无缝接入持续集成流程。

正如前文所述，它们的差异主要体现在功能完备度上。

MLFlow 最初为传统机器学习 pipelines 设计，因此针对 LLM 应用的预置指标较少。OpenAI 提供非常轻量的解决方案，需要用户自行设定评估指标（尽管它提供了一个示例库帮助入门）。

RAGAS 提供了丰富的评估指标，并且与 LangChain 集成，便于快速部署。

DeepEval 则提供了大量开箱即用的功能，其功能集完全覆盖 RAGAS 指标。

上述对比表格的详细内容可在此 Github 仓库（https://github.com/ilsilfverskiold/Awesome-LLM-Resources-List/blob/main/README.md[#evaluation]()-frameworks-and-add-ons ）中查看。

通过分析各框架提供的评估指标，我们可以大致了解这些解决方案的覆盖范围。

值得注意的是，这些框架的指标命名尚未形成统一标准。相同含义的指标可能具有不同名称。

例如，某个框架中的"忠实度（faithfulness）"可能等同于另一框架的"事实性（groundedness）"。"答案相关性（Answer relevancy）"与"响应相关性（response relevance）"可能指向同一概念，等等。

这使得从业者需要花费额外的心力去理解和管理这些术语差异，而不是专注于更重要的评估设计和结果分析工作。

尽管如此，DeepEval 仍以超过 40 项预置指标脱颖而出，同时提供名为 G-Eval 的框架，能快速创建自定义指标，成为从指标构思到可运行指标的最快捷路径。

OpenAI 的 Evals 框架则更适合需要高度定制化逻辑的场景，而不仅仅是需要一个快速评判器。

根据 DeepEval 团队反馈，开发者最常使用的是自定义指标功能。因此不必纠结于框架预置了哪些指标，您的应用场景独一无二，评估方式也应如此。

那么，在什么情况下应该选择哪种框架呢？

当我们需要专为 RAG pipeline 设计、开箱即用的专项指标时，请选用 RAGAS；若追求功能完整的全场景评估套件，DeepEval 是最佳选择。

若您已深度集成 MLFlow 生态或偏好内置追踪与可视化界面，MLFlow 值得考虑；OpenAI 的 Evals 框架最为轻量，最适合深度依赖 OpenAI 基础设施且追求灵活定制的用户。

最后，DeepEval 还通过其 DeepTeam 框架提供红队测试功能，可自动化对 LLM 系统进行对抗性测试。虽存在其他具备类似功能的框架，但实现深度通常不及此方案。

未来我将专门探讨 LLM 系统对抗测试与提示词注入防护这一有趣领域。

10 几点补充说明

数据集业务利润丰厚，这也反衬出当前我们能利用其他 LLM 进行数据标注或测试评分的可贵之处。

但需要注意的是，LLM 评估器并非万能 ------ 正如我们开发的任何 LLM 应用一样，我们搭建的评估系统也可能出现不稳定的状况。根据业界普遍做法，大多数团队和公司会每隔几周进行人工抽样审核，以确保评估结果真实可靠。

我们为 LLM 应用定制的评估指标很可能需要进行个性化设置。因此，尽管本文介绍了大量现有指标，但最终你大概率需要构建自己的评估体系。

不过了解行业内的标准评估指标仍然很有价值。

希望本文能对你有所启发。

END

本期互动内容 🍻

❓你有没有遇到过"评估性能很好，但用户体验很差"的情况？你是怎么解决的？

本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。

原文链接：

https://www.ilsilfverskiold.com/articles/agentic-ai-on-evaluations