智能体设计模式-CH19:评估与监控(Evaluation and Monitoring)

122 阅读25分钟

英文原地址:Chapter 19: Evaluation and Monitoring

本章探讨使智能体能够系统性评估自身表现、监控目标进展并检测运行异常的方法论。虽然第 11 章概述了目标设定与监控,第 17 章讨论了推理机制,但本章重点关注对智能体有效性、效率以及对需求合规性的持续(且常为外部)测量。这包括定义指标、建立反馈回路,以及实施报告系统,以确保智能体在运营环境中的表现符合预期(见图 1)。

图 1:评估与监控的最佳实践 unknown.png

实际应用与使用场景

  • 在线系统中的性能跟踪(Performance Tracking in Live Systems): 持续监控部署在生产环境中的智能体的准确率、延迟和资源消耗(例如,客服聊天机器人的问题解决率和响应时间)。
  • A/B Testing for Agent Improvements(A/B Testing for Agent Improvements): 并行系统性比较不同版本或策略的智能体表现,以识别最优方法(例如,为物流智能体尝试两种不同的规划算法)。
  • 合规与安全审计(Compliance and Safety Audits): 生成自动化审计报告,跟踪智能体对伦理准则、监管要求和安全协议的长期合规情况。这些报告可由人类参与者或另一个智能体进行验证,并可在发现问题时生成 KPI 或触发警报。
  • 企业系统(Enterprise systems): 要在企业系统中治理具备智能体能力的 AI,需要一种新的控制工具,即 AI“Contract”。这是一份动态协议,用于编纂 AI 被委派任务的目标、规则和控制措施。
  • 漂移检测(Drift Detection): 监测智能体输出随时间的相关性或准确性,当由于输入数据分布变化(概念漂移)或环境变化导致其性能下降时进行检测。
  • 智能体行为的异常检测(Anomaly Detection in Agent Behavior): 识别智能体采取的异常或意外行动,这些行动可能表明错误、恶意攻击,或出现了不期望的涌现行为。
  • 学习进度评估(Learning Progress Assessment): 对于设计为可学习的智能体,跟踪其学习曲线、在特定技能上的提升,或在不同任务或数据集上的泛化能力。

实战代码示例

为智能体开发一个全面的评估框架是一项充满挑战的工作,其复杂程度可与一门学术学科或一篇重量级出版物相媲美。困难源于需要考虑的因素众多,例如模型性能、用户交互、伦理影响以及更广泛的社会影响。然而,在实际落地中,可以将重点收敛到对 AI 智能体高效有效运行至关重要的关键用例上。

智能体响应评估: 这一核心过程用于评估智能体输出的质量与准确性。其涉及确定智能体是否针对给定输入提供了相关、正确、合乎逻辑、公正且准确的信息。评估指标可包括事实正确性、流畅度、语法准确性以及对用户意图的遵从。

def evaluate_response_accuracy(agent_output: str, expected_output: str) -> float:
   """Calculates a simple accuracy score for agent responses."""
   # This is a very basic exact match; real-world would use more sophisticated metrics
   return 1.0 if agent_output.strip().lower() == expected_output.strip().lower() else 0.0

# Example usage
agent_response = "The capital of France is Paris."
ground_truth = "Paris is the capital of France."
score = evaluate_response_accuracy(agent_response, ground_truth)
print(f"Response accuracy: {score}")

Python 函数evaluate_response_accuracy通过在去除首尾空白后,对智能体输出与期望输出进行严格的不区分大小写的精确比较,来计算智能体响应的基础准确度分数。若完全匹配则返回 1.0,否则返回 0.0,表示二元的正确或错误评估。此方法虽适用于简单检查,但无法处理如同义改写或语义等价等变体。

问题出在其比较方法。该函数对两段字符串执行严格的逐字符比较。在所给示例中:

  • agent_response: "The capital of France is Paris."
  • ground_truth: "Paris is the capital of France."

即便去除空白并转换为小写,这两个字符串仍不相同。因此,该函数会错误地返回准确度分数为 0.0 ,尽管两句实际上表达了相同的含义。

简单比较在评估语义相似性方面力有不逮,只有在智能体响应与期望输出完全一致时才会成功。更有效的评估需要先进的自然语言处理(NLP)技术来辨析句子间的意义。在真实世界场景中,对智能体进行全面评估往往离不开更为复杂的度量指标。这些指标可包括字符串相似度度量(如 Levenshtein 距离、Jaccard 相似度)、关键词分析(检测特定关键词的存在与缺失)、利用嵌入模型并结合余弦相似度的语义相似性、LLM-as-a-Judge 评估(稍后讨论,用于评估细微层面的正确性与有用性),以及 RAG 特定指标,如忠实度与相关性。

延迟监控: 在以智能体行为为核心的应用中,延迟监控至关重要,尤其当智能体响应或执行动作的速度是关键因素时。该过程用于衡量智能体处理请求并生成输出所需的时长。过高的延迟会对用户体验和智能体的整体有效性产生负面影响,特别是在实时或交互式环境中。在实际应用中,仅在控制台打印延迟数据是不够的。建议将这些信息记录到持久化存储系统。可选方案包括结构化日志文件(例如 JSON)、时序数据库(例如 InfluxDB、Prometheus)、数据仓库(例如 Snowflake、BigQuery、PostgreSQL)或可观测性平台(例如 Datadog、Splunk、Grafana Cloud)。

跟踪 LLM 交互的 Token 使用: 对于由 LLM 驱动的智能体,跟踪 token 使用对于管理成本和优化资源分配至关重要。LLM 交互的计费通常取决于处理的 token 数量(输入与输出)。因此,高效的 token 使用可以直接降低运营成本。此外,监控 token 计数有助于识别提示工程或响应生成流程中可改进的潜在领域。

# This is conceptual as actual token counting depends on the LLM API
class LLMInteractionMonitor:
   def __init__(self):
       self.total_input_tokens = 0
       self.total_output_tokens = 0

   def record_interaction(self, prompt: str, response: str):
       # In a real scenario, use LLM API's token counter or a tokenizer
       input_tokens = len(prompt.split()) # Placeholder
       output_tokens = len(response.split()) # Placeholder
       self.total_input_tokens += input_tokens
       self.total_output_tokens += output_tokens
       print(f"Recorded interaction: Input tokens={input_tokens}, Output tokens={output_tokens}")

   def get_total_tokens(self):
       return self.total_input_tokens, self.total_output_tokens

# Example usage
monitor = LLMInteractionMonitor()
monitor.record_interaction("What is the capital of France?", "The capital of France is Paris.")
monitor.record_interaction("Tell me a joke.", "Why don't scientists trust atoms? Because they make up everything!")
input_t, output_t = monitor.get_total_tokens()
print(f"Total input tokens: {input_t}, Total output tokens: {output_t}")

本节介绍了一个概念性的 Python 类 LLMInteractionMonitor,用于跟踪大型语言模型交互中的 token 使用。该类包含输入和输出 token 的计数器。其 record_interaction 方法通过拆分提示和响应字符串来模拟 token 计数。在实际实现中,应使用特定的 LLM API 分词器以获得精确的 token 计数。随着交互发生,监控器会累计输入和输出 token 的总数。get_total_tokens 方法提供对这些累计总数的访问,这对于成本管理和 LLM 使用优化至关重要。

使用 LLM-as-a-Judge 的“有用性”自定义指标: 评估诸如智能体“有用性”之类的主观品质,超出了标准客观指标的范畴。一种可行框架是使用 LLM 作为评估者。该 LLM-as-a-Judge 方法根据预定义的“有用性”标准评估另一个智能体的输出。借助 LLM 的高级语言能力,此方法能对主观品质给出细腻、类人的评估,优于简单的关键词匹配或基于规则的评估。尽管仍在发展中,这一技术在自动化和规模化定性评估方面展现出前景。

import google.generativeai as genai
import os
import json
import logging
from typing import Optional

# --- Configuration ---
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')

# Set your API key as an environment variable to run this script
# For example, in your terminal: export GOOGLE_API_KEY='your_key_here'
try:
   genai.configure(api_key=os.environ["GOOGLE_API_KEY"])
except KeyError:
   logging.error("Error: GOOGLE_API_KEY environment variable not set.")
   exit(1)

# --- LLM-as-a-Judge Rubric for Legal Survey Quality ---
LEGAL_SURVEY_RUBRIC = """
You are an expert legal survey methodologist and a critical legal reviewer. Your task is to evaluate the quality of a given legal survey question.

Provide a score from 1 to 5 for overall quality, along with a detailed rationale and specific feedback.
Focus on the following criteria:

1.  **Clarity & Precision (Score 1-5):**
   * 1: Extremely vague, highly ambiguous, or confusing.
   * 3: Moderately clear, but could be more precise.
   * 5: Perfectly clear, unambiguous, and precise in its legal terminology (if applicable) and intent.

2.  **Neutrality & Bias (Score 1-5):**
   * 1: Highly leading or biased, clearly influencing the respondent towards a specific answer.
   * 3: Slightly suggestive or could be interpreted as leading.
   * 5: Completely neutral, objective, and free from any leading language or loaded terms.

3.  **Relevance & Focus (Score 1-5):**
   * 1: Irrelevant to the stated survey topic or out of scope.
   * 3: Loosely related but could be more focused.
   * 5: Directly relevant to the survey's objectives and well-focused on a single concept.

4.  **Completeness (Score 1-5):**
   * 1: Omits critical information needed to answer accurately or provides insufficient context.
   * 3: Mostly complete, but minor details are missing.
   * 5: Provides all necessary context and information for the respondent to answer thoroughly.

5.  **Appropriateness for Audience (Score 1-5):**
   * 1: Uses jargon inaccessible to the target audience or is overly simplistic for experts.
   * 3: Generally appropriate, but some terms might be challenging or oversimplified.
   * 5: Perfectly tailored to the assumed legal knowledge and background of the target survey audience.

**Output Format:**
Your response MUST be a JSON object with the following keys:
* `overall_score`: An integer from 1 to 5 (average of criterion scores, or your holistic judgment).
* `rationale`: A concise summary of why this score was given, highlighting major strengths and weaknesses.
* `detailed_feedback`: A bullet-point list detailing feedback for each criterion (Clarity, Neutrality, Relevance, Completeness, Audience Appropriateness). Suggest specific improvements.
* `concerns`: A list of any specific legal, ethical, or methodological concerns.
* `recommended_action`: A brief recommendation (e.g., "Revise for neutrality", "Approve as is", "Clarify scope").
"""

class LLMJudgeForLegalSurvey:
   """A class to evaluate legal survey questions using a generative AI model."""


   def __init__(self, model_name: str = 'gemini-1.5-flash-latest', temperature: float = 0.2):
       """
       Initializes the LLM Judge.
      
       Args:
           model_name (str): The name of the Gemini model to use.
                             'gemini-1.5-flash-latest' is recommended for speed and cost.
                             'gemini-1.5-pro-latest' offers the highest quality.
           temperature (float): The generation temperature. Lower is better for deterministic evaluation.
       """
       self.model = genai.GenerativeModel(model_name)
       self.temperature = temperature


   def _generate_prompt(self, survey_question: str) -> str:
       """Constructs the full prompt for the LLM judge."""
       return f"{LEGAL_SURVEY_RUBRIC}\n\n---\n**LEGAL SURVEY QUESTION TO EVALUATE:**\n{survey_question}\n---"

   def judge_survey_question(self, survey_question: str) -> Optional[dict]:
       """
       Judges the quality of a single legal survey question using the LLM.

       Args:
           survey_question (str): The legal survey question to be evaluated.

       Returns:
           Optional[dict]: A dictionary containing the LLM's judgment, or None if an error occurs.
       """
       full_prompt = self._generate_prompt(survey_question)
      
       try:
           logging.info(f"Sending request to '{self.model.model_name}' for judgment...")
           response = self.model.generate_content(
               full_prompt,
               generation_config=genai.types.GenerationConfig(
                   temperature=self.temperature,
                   response_mime_type="application/json"
               )
           )

           # Check for content moderation or other reasons for an empty response.
           if not response.parts:
               safety_ratings = response.prompt_feedback.safety_ratings
               logging.error(f"LLM response was empty or blocked. Safety Ratings: {safety_ratings}")
               return None
          
           return json.loads(response.text)

       except json.JSONDecodeError:
           logging.error(f"Failed to decode LLM response as JSON. Raw response: {response.text}")
           return None
       except Exception as e:
           logging.error(f"An unexpected error occurred during LLM judgment: {e}")
           return None

# --- Example Usage ---
if __name__ == "__main__":
   judge = LLMJudgeForLegalSurvey()

   # --- Good Example ---
   good_legal_survey_question = """
   To what extent do you agree or disagree that current intellectual property laws in Switzerland adequately protect emerging AI-generated content, assuming the content meets the originality criteria established by the Federal Supreme Court?
   (Select one: Strongly Disagree, Disagree, Neutral, Agree, Strongly Agree)
   """
   print("\n--- Evaluating Good Legal Survey Question ---")
   judgment_good = judge.judge_survey_question(good_legal_survey_question)
   if judgment_good:
       print(json.dumps(judgment_good, indent=2))

   # --- Biased/Poor Example ---
   biased_legal_survey_question = """
   Don't you agree that overly restrictive data privacy laws like the FADP are hindering essential technological innovation and economic growth in Switzerland?
   (Select one: Yes, No)
   """
   print("\n--- Evaluating Biased Legal Survey Question ---")
   judgment_biased = judge.judge_survey_question(biased_legal_survey_question)
   if judgment_biased:
       print(json.dumps(judgment_biased, indent=2))

   # --- Ambiguous/Vague Example ---
   vague_legal_survey_question = """
   What are your thoughts on legal tech?
   """
   print("\n--- Evaluating Vague Legal Survey Question ---")
   judgment_vague = judge.judge_survey_question(vague_legal_survey_question)
   if judgment_vague:
       print(json.dumps(judgment_vague, indent=2))

这段 Python 代码定义了一个名为 LLMJudgeForLegalSurvey 的类,旨在使用生成式 AI 模型评估法律问卷问题的质量。它使用 google.generativeai 库与 Gemini 模型交互。

核心功能是将待评估的问卷问题与详细的评分量表一同发送给模型。该量表规定了评判问卷问题的五项标准:清晰与精准、中立与偏见、相关性与聚焦、完整性,以及受众适配性。每项标准打分从 1 到 5,并在输出中要求提供详细的理由与反馈。代码会构建一个包含量表与待评估问卷问题的提示词。

judge_survey_question 方法将该提示词发送至配置的 Gemini 模型,请求按定义结构格式化的 JSON 响应。预期的输出 JSON 包含总体评分、概要性理由、各项标准的详细反馈、关注点列表以及推荐的行动。该类还处理 AI 模型交互过程中可能出现的错误,例如 JSON 解码问题或空响应。脚本通过评估法律问卷问题的示例来演示其工作方式,说明 AI 如何基于预定义标准评估质量。

在结束之前,让我们审视各种评估方法,权衡它们的优势与劣势。

评估方法优势劣势
人工评估捕捉细微行为难以扩展、成本高且耗时,因为需要考虑主观的人为因素。
LLM 作为裁判一致、高效且可扩展。可能忽略中间步骤。受限于 LLM 的能力。
自动化指标可扩展、高效且客观在捕捉完整能力方面可能存在局限。

智能体轨迹(Agents trajectories)

评估智能体的轨迹至关重要,因为传统软件测试并不充分。标准代码会产生可预测的通过/失败结果,而智能体是以概率方式运行的,因此需要对最终输出和智能体的轨迹——也就是达成解决方案所采取的一系列步骤——进行定性评估。评估多智能体系统具有挑战性,因为它们不断变化。这需要开发超越个体性能的复杂指标,以衡量沟通与团队协作的有效性。此外,环境本身也不是静态的,这要求包括测试用例在内的评估方法随时间不断适配。

这涉及审查决策质量、推理过程以及整体结果。实施自动化评估很有价值,尤其是在超越原型阶段的开发中。对轨迹和工具使用的分析包括评估智能体为实现目标所采取的步骤,例如工具选择、策略与任务效率。例如,一个处理客户产品咨询的智能体,理想的轨迹可能包括识别意图、使用数据库检索工具、审查结果以及生成报告。将智能体的实际行为与这一预期(或称“真实基准”)轨迹进行比较,以识别错误和低效。比较方法包括:完全匹配(要求与理想序列完全一致)、顺序匹配(在顺序正确的前提下允许额外步骤)、任意顺序匹配(允许正确动作以任意顺序出现并包含额外步骤)、精确率(衡量预测动作的相关性)、召回率(衡量捕获到多少关键动作),以及单工具使用(检查是否执行了某一特定动作)。指标选择取决于具体的智能体需求:高风险场景可能需要完全匹配,而更灵活的情况可以采用顺序或任意顺序匹配。

对智能体的评估主要有两种方法:使用测试文件和使用 evalset 文件。测试文件采用 JSON 格式,表示单个、简单的智能体-模型交互或会话,适合在积极开发期间进行单元测试,侧重快速执行和简单的会话复杂度。每个测试文件包含一个具有多个轮次的单一会话,其中一轮是一次用户-智能体交互,包括用户的查询、预期的工具使用轨迹、中间的智能体回复以及最终回复。例如,一个测试文件可能详述用户请求“Turn off device_2 in the Bedroom”,指定智能体使用 set_device_info 工具及其参数,如 location: Bedroom、device_id: device_2、status: OFF,并期望最终回复为“I have set the device_2 status to off.” 测试文件可以组织到文件夹中,并可包含 test_config.json 文件以定义评估标准。Evalset 文件利用名为“evalset”的数据集来评估交互,包含多个可能较长的会话,适合模拟复杂的多轮对话和集成测试。一个 evalset 文件由多个“evals”组成,每个代表一个独立会话,包含一个或多个“turns”,其中包括用户查询、预期的工具使用、中间回复以及参考的最终回复。一个示例 evalset 可能包含这样一个会话:用户先问“What can you do?”,然后说“Roll a 10 sided dice twice and then check if 9 is a prime or not”,并定义预期的 roll_die 工具调用与 check_prime 工具调用,以及最终回复对掷骰结果和质数检查进行总结。

多智能体: 评估由多个智能体构成的复杂 AI 系统很像评估一个团队项目。由于存在许多步骤与交接,其复杂性反而成为优势,使你能够在每个阶段检查工作质量。你可以审视每个个体“智能体”完成其特定职责的表现,同时也必须评估整个系统整体的运行情况。

为此,你需要就团队动态提出关键问题,并辅以具体示例:

  • 智能体是否有效协作?例如,当“Flight-Booking Agent”预订好航班后,是否能将正确的日期和目的地成功传递给“Hotel-Booking Agent”?协作失败可能导致酒店被预订在错误的周。
  • 他们是否制定了良好的计划并严格执行?设想计划是先订机票,再订酒店。如果“Hotel Agent”在航班尚未确认前就尝试订房,则偏离了计划。你还需要检查某个智能体是否卡住,比如无休止地寻找“完美”的租车而迟迟不进入下一步。
  • 是否为正确的任务选择了正确的智能体?如果用户询问旅行期间的天气,系统应使用提供实时数据的专业“Weather Agent”。如果却用了“General Knowledge Agent”并给出诸如“夏天通常很暖和”这类泛泛的回答,那么就是为任务选择了错误的工具。
  • 最后,增加更多智能体是否能提升性能?如果你向团队新增“Restaurant-Reservation Agent”,它是否会让整体行程规划更好更高效?还是会制造冲突并拖慢系统,暴露出可扩展性问题?

从智能体到高级承包商(From Agents to Advanced Contractors)

最近,有研究(Agent Companion,gulli 等)提出了一种从简单智能体到高级“承包商”的演进路径,即从概率性、常常不稳定的系统,转向为复杂、高风险环境设计的、更具确定性和可问责性的系统(见图 2)。

当今常见的智能体往往基于简短且未充分明确的指令运作,这使其适用于简单演示,但在生产环境中由于歧义而容易失败。“承包商”模型通过在用户与 AI 之间建立严格、形式化的关系来解决这一问题,该关系建立在明确定义并双方同意的条款之上,类似于人类世界中的法律服务协议。这一转变由四个关键支柱支撑,协同确保清晰性、可靠性,以及对以往超出自主系统能力范围任务的稳健执行。

首先是形式化契约这一支柱,它是一份详尽的规范,作为任务的唯一可信来源。它远不止一个简单的提示。例如,一项财务分析任务的契约不会只写“分析上季度的销售”,而是会要求“提供一份 20 页的 PDF 报告,分析 2025 年第一季度欧洲市场的销售情况,包含五个特定数据可视化、与 2024 年第一季度的对比分析,以及基于所含供应链中断数据集的风险评估。”该契约明确规定了所需交付物、其精确规范、可接受的数据来源、工作范围,甚至预期的计算成本和完成时间,使结果可以客观验证。

第二个支柱是动态的协商与反馈生命周期。契约不是静态命令,而是对话的起点。承包智能体可以分析初始条款并进行协商。例如,如果契约要求使用智能体无法访问的特定专有数据源,它可以反馈:“指定的 XYZ 数据库无法访问。请提供凭证,或批准使用替代的公共数据库,这可能会略微改变数据粒度。”这一协商阶段还允许智能体标记歧义或潜在风险,在执行开始前消除误解,避免代价高昂的失败,并确保最终输出与用户的真实意图完全一致。

图 2:智能体之间的契约执行示例 unknown 2.png

第三个支柱是以质量为中心的迭代式执行。不同于为了低延迟响应而设计的智能体,承包者优先考虑正确性和质量。它遵循自我验证与纠错的原则。以代码生成契约为例,智能体不仅会编写代码;还会生成多种算法方案,编译并在契约定义的单元测试套件上运行,对每个方案在性能、安全性、可读性等指标上打分,只有通过全部验证标准的版本才会提交。这种内部循环——生成、审查、改进,直到满足契约规范——对于建立对其输出的信任至关重要。

最后,第四个支柱是通过子契约进行的分层分解。对于复杂度显著的任务,主承包智能体可以充当项目经理,将总体目标分解为更小、更可管理的子任务。它通过生成新的、正式的“子契约”来实现这一点。例如,一个“构建电商移动应用”的主契约,可以被主智能体分解为“设计 UI/UX”、“开发用户认证模块”、“创建产品数据库模式”、“集成支付网关”等子契约。每个子契约都是完整、独立的契约,具有各自的交付物和规范,可分配给其他专业智能体。这样的结构化分解,使系统能够以高度有序、可扩展的方式处理庞大而多面的项目,标志着 AI 从简单工具向真正自主且可靠的解决问题引擎的转变。

归根结底,这一承包者框架通过将形式化规范、协商以及可验证执行的原则直接嵌入智能体的核心逻辑,重新构想了 AI 的交互方式。这种方法论将人工智能从一个充满潜力但常常难以预测的助手,提升为能够以可审计的精度自主管理复杂项目的可靠系统。通过解决歧义与可靠性的关键挑战,该模型为在任务关键型领域部署 AI 铺平了道路,在这些领域中,信任与问责至关重要。

Google's ADK

在结束之前,让我们看一个支持评估的具体框架示例。使用 Google 的 ADK 进行智能体评估(见图 3)可以通过三种方法:基于 Web 的 UI(adk web),用于交互式评估与数据集生成;使用 pytest 进行编程式集成,以纳入测试流水线;以及直接的命令行接口(adk eval),用于自动化评估,适合常规构建的生成与验证流程。

图 3:Google ADK 的评估支持 unknown 3.png

基于 Web 的 UI 支持交互式会话创建,并可保存到现有或新的评估集,同时显示评估状态。通过集成 Pytest,可在集成测试中调用 AgentEvaluator.evaluate 运行测试文件,需指定智能体模块和测试文件路径。

命令行界面便于自动化评估,只需提供智能体模块路径和评估集文件,并可选择指定配置文件或打印详细结果。在较大的评估集中,可通过在评估集文件名后以逗号分隔列出具体评估项来选择性执行。

回顾

是什么(What)

智能体系统和 LLMs 运行于复杂、动态的环境中,其性能可能随时间退化。其概率性与非确定性意味着传统软件测试不足以确保可靠性。评估动态多智能体系统极具挑战,因为它们及其环境的持续变化要求开发自适应测试方法与复杂指标,以衡量超越个体表现的协作成功。部署后可能出现数据漂移、意外交互、工具调用以及偏离既定目标等问题。因此需要持续评估,以衡量智能体的有效性、效率,以及对操作与安全要求的遵循。

为什么(Why)

标准化的评估与监控框架为系统性评估并确保智能体持续性能提供了方法。这包括为准确率、延迟与资源消耗(如 LLMs 的 token 使用量)定义明确指标;也包括高级方法,如分析 agentic 轨迹以理解推理过程,并采用 LLM-as-a-Judge 进行细致的定性评估。通过建立反馈回路与报告系统,该框架支持持续改进、A/B 测试,以及异常或性能漂移的检测,确保智能体与其目标保持一致。

经验法则(Rule of Thumb)

在将智能体部署到实时生产环境且对实时性能与可靠性要求严格时使用该模式。此外,当需要系统性比较智能体不同版本或其底层模型以推动改进时,以及在受监管或高风险领域需要合规、安全与伦理审计时,也应采用该模式。当由于数据或环境变化(漂移)导致智能体性能可能随时间下降,或需要评估复杂的 agentic 行为(包括动作序列[轨迹])与诸如有用性等主观输出质量时,该模式同样适用。

图示摘要

unknown.jpg

关键点

  • 对智能体的评估超越传统测试,需在真实环境中持续衡量其有效性、效率及对需求的遵循。
  • 智能体评估的实践应用包括在线系统的性能追踪、用于改进的 A/B 测试、合规审计,以及检测行为漂移或异常。
  • 基础的智能体评估关注响应准确性,而真实世界场景需要更复杂的指标,如对延迟的监控以及对由 LLM 驱动的智能体的 token 使用追踪。
  • 智能体轨迹,即智能体采取的一系列步骤,是评估的关键,可将实际动作与理想的、真实标准的路径进行对比,以识别错误与低效。
  • ADK 通过用于单元测试的独立测试文件与用于集成测试的综合 evalset 文件提供结构化的评估方法,两者均定义了期望的智能体行为。
  • 智能体评估可以通过基于网页的用户界面进行交互式测试,通过与 pytest 的编程集成用于 CI/CD,或通过命令行界面用于自动化工作流。
  • 为了让人工智能在复杂、高风险任务中可靠运行,我们必须从简单的提示转向正式的“契约”,精确定义可验证的交付物与范围。这种结构化的约定使智能体能够进行协商、澄清歧义,并迭代验证其自身工作,从而将其从不可预测的工具转变为可问责且值得信赖的系统。

总结

总之,有效评估智能体需要超越简单的准确性检查,转向在动态环境中对其性能进行持续的、多维度的评估。这包括对延迟和资源消耗等指标的实际监控,以及通过其轨迹对智能体决策过程进行复杂分析。对于诸如“有用性”这类细微品质,诸如 LLM-as-a-Judge 等创新方法正变得至关重要,而谷歌的 ADK 等框架为单元测试和集成测试提供了结构化工具。多智能体系统使挑战加剧,评估重点转向协作成功与有效合作。

为确保关键应用中的可靠性,范式正从简单、由提示驱动的智能体转向受正式协议约束的先进“承包商”。这些承包智能体基于明确、可验证的条款运作,使其能够协商、分解任务并自我验证工作,以满足严格的质量标准。这种结构化方法将智能体从不可预测的工具转变为能够处理复杂、高风险任务的可问责系统。最终,这一进化对于在任务关键领域部署复杂的智能体式 AI 所需的信任构建至关重要。

参考资料

  1. ADK Web: github.com/google/adk-…
  2. ADK Evaluate: google.github.io/adk-docs/ev…
  3. Survey on Evaluation of LLM-based Agents, arxiv.org/abs/2503.16…
  4. Agent-as-a-Judge: Evaluate Agents with Agents, arxiv.org/abs/2410.10…
  5. Agent Companion, gulli et al.: www.kaggle.com/whitepaper-…