JaydenAI的博客

由于大多数现代AI应用（如智能客服、Agent、RAG 系统）都是基于聊天对话的，传统的**单轮单答（Single-turn）**测试无法捕获用户修改意图、追问或上下文丢失等复杂情况。OpenEvals允许你用另一个AI扮演**虚拟用户**，与你的AI应用进行多轮交互模拟，并自动评估完整的对话轨迹（Trajectory）。

[基于OpenEvals的自动化评估-14:以静态代码分析方式评估Coding Agent生成的代码]着重介绍了基于MyPy和Pyright这两种广受欢迎的基于Python的静态代码分析引擎器来评估Agent生成的代码，其实提取出来的代码还可以直接交给LLM进行评估。相关的评估器可以利用create_code_llm_as_judge这个工厂函数来创建，本篇文章就来介绍如何利用这种方式实施针对代码的评估。

虽然我个人对Coding Agent一直持保留的态度，但不可否认的是这已经成为Agent应用最大的一个分支，所以如何有效地评估Agent生成的代码就显得尤为重要。针对生成的代码的评估可以验证代码文本的合法性，也可以验证其可执行性；可以利用没有隔离的代码揭示和执行环境，也可以借助Sandbox提供更加安全的隔离保障；评估代码可以在本地执行，也可以上传到云平台执行。本章介绍几种在本地进行的针对Python的代码评估器。

[基于OpenEvals的自动化评估-12:Agent执行轨迹评估]介绍的轨迹评估很简单，让首先确待评估的消息列表与作为基准的列表在消息数量上相等、角色上一一匹配。如果涉及工具调用，在根据指定的工具调用列表匹配模式和参数匹配模式对工具调用进行比较。其实Agent执行轨迹也可以借助LLM的力量，利用创建的基于**LLM-as-a-Judge**的评

如果您正在构建Agent，OpenEvals包含用于评估Agent完整执行轨迹的评估器，即Agent在解决任务过程中发出的消息和工具调用序列。由于用户与Agent之间采用基于消息的通信方式，所以Agent的执行轨迹通过返回的消息列表来体现。执行轨迹在OpenEvals中以OpenAI风格的消息列表格式呈现。此外，也支持LangChain的`BaseMessage`对象。在进行两个消息的比较时，只考虑角色和工具调用，会忽略消息的其他内容。

在[上篇]我们介绍了评估用户与Agent对话的三个指标，包括语气评估（Tone）、知识记忆评估（Knowledge Retention）和 用户感知错误评估（Perceived Error），接下来我们补充余下的三个：任务完成度评估（Task Completion ）、用户满意度评估（User Satisfaction）和用户赞赏评估（Wins）。

在本系列前面的文章中，我介绍如何利用OpenEvals提供的预定义提示词，结合LLM-as-a-Judge评估器进行输出文本质量([上篇]、[下篇])、[安全]以及专门[面向RAG的评估]。这篇和下篇则专门聚焦针对用户和Agent之间对话的评估，具体指标包括Agent的语气、是否记住对话历史的内容，以及通过分析用户的言辞和清晰评估用户是否认为Agent犯了错误、答非所问或走错了方向。

我们知道RAG分两步：一、根据原始输入检索相关的文档；二、将检索结果作为上下文提交给LLM生成输出。两个步骤涉及三类数据：输入、上下文和输出。三类数据两两比较就带来了如下三种针对RAG的评估：- **检索相关性评估**：评估作为上下文的检索结果与输入的相关度；- **事实依据性评估**：评估最终输出与上下文的忠实程度；- **帮助性评估**： 评估最终的输出对于输入提供的问题有多大的帮助。

中文的安全其实对应**Safety**和**Security**两个单词，它们的侧重点和防御的对象截然不同。Safety指的是防止系统出错或失控对人类或环境造成伤害，核心是防范无意的意外、错误或故障。。核心是防范有意的恶意行为。本文将介绍如何利用OpeEvals提供的提示词，结合LLM-as-a-Judge评估器，针对五个安全指标的评估，**分别有害性（Toxicity）**、**公平性（Fairness）**、**个人信息泄露（PII Leakage）**、**代码注入（Code Injection）**

[上篇]介绍了如何利用OpenEvals提供的预定义提示词结合结合**LLM-as-a-Judge**评估器来评估Agent生成文本的质量，我们具体介绍了针对简洁度、正确性、回答相关性和幻觉

对于我们个人来说，Agent编程最大的挑战不是各种所谓的工作，而是写提示词，毕竟我不是专业的文字工作者。OpenEvals针对一系列针对输出文本质量的评估指标定义了对应的提示词，结合基于LLM-as-a-Judge的评估器，我们可以进行针对简洁度、正确性、幻觉度、相关性、计划遵循度、代码正确性等指标的评估。我们会分上下文两篇文章来介绍针对这些预定义提示词的使用。

基于JSON内容的评估可以说是OpenEvals最重要的部分，[基于OpenEvals的自动化评估-04:基于JSON相似度的评估]对用于提供相关评估器的如下两个工厂函数从无LLM参与的角度进行了介绍。我们着重讨论了这两个函数的`aggregator`、`list_aggregator`和`list_match_mode`参数。其余的参数均与**LLM-as-a-Judge**有关。如果有了LLM加持，我们可以进行真正的基于自然语言的语义相似度比较，这样才能真正发挥AI的能力。

由于Agent与LLM交互的数据基本采用基于JSON的序列化方式，针对数据结构的描述也基本采用JSON Schema，所以很多情况下针对Agent输出的评估体现在基于JSON的相似度比较。OpenEvals专门为此定义了如下两个用于创建基于JSON匹配评估器的工厂函数，其中`create_json_match_evaluator`用于同步调用，`create_async_json_match_evaluator`用于异步调用。这是两个非常重要的函数，我们不仅可以用它来评估基于JSON的结构化输出，Agent

本文介绍两种常用的文本相似度验证方式，一种是基于**Levenshtein距离**的相似度评估，它通过计算把一个字符串转成另一个字符串所需的最少编辑操作数拉来衡量两个字符串相似度，完全不需要LLM的加持。另一个是我们常用了基于**嵌入向量**的相似度介绍，通将文本转换成嵌入向量，然后通过计算两个向量之间的夹角余弦值或者点积的方式衡量语义相似度。

在大部分情况下，我们会借助LLM的能力来评估Agent的输出，我们将这种评估模式成为**LLM-as-a-Judge**。这是一种利用大型语言模型对生成式AI输出进行自动化评估的范式，其核心思想是让模型承担**裁判**角色，对候选答案进行打分、排序或选择，能够在开放式任务中判断质量、相关性、逻辑性、事实性与有用性等更细腻的属性。由于LLM是一个概率模型，所以评估的结果本质上是一个概率分布，所以代表评估结果的Score一般是一个[0-1]的分数，返回的二元布尔值也是基于指标的开率计算出来的。

OpenEvals是LangChain官方推出的开源自动化评估框架，专注于Agent及大模型应用的链路质检。它不仅能评估大模型的最终回复，更核心的价值在于多步行为与决策评估。框架支持工具调用准确性和多轮用户模拟仿真。通过将评估指标代码化，OpenEvals将复杂的Agent推理轨迹、思维黑盒转化为可量化的分数，提供了工业级的Agent**操行评定表**。它是破局Agent落地信任危机的核心度量衡。虽然OpenEvals可以帮助我们从很多的维度对Agent进行评估，但是它的评估模型其实很简单。