阿Q技术站

深浅色

第 23 章 Agent 评估方法论 ​

23.1 评估特殊性与维度体系 ​

传统软件的评估基于确定输入→确定输出，Agent 系统存在三类本质差异：其一，非确定性（Non-determinism），同一输入因 temperature、采样、工具返回抖动可产生不同答案，且多个答案都可能正确；其二，多步过程（Multi-step reasoning），最终答案正确但过程可能冗余、绕路或调用了不必要的高成本工具；其三，外部依赖，工具与检索结果的变化会影响答案，需单独隔离评估。

评估维度分为五层：结果质量 关注答案正确性、完整性、与问题相关性；过程质量 关注工具选择是否正确、参数是否正确、调用路径是否合理、冗余调用率（Redundant Tool Call Rate）；效率 关注总轮次、token 消耗、端到端延迟、单次成本；鲁棒性（Robustness）关注异常输入、工具失败恢复、网络抖动与对抗性输入表现；安全性 关注提示注入防护、权限越权、敏感信息泄露。

离线评估（Offline Evaluation）流程为：构建数据集 → 在数据集上批量运行 Agent → 评分器（Evaluator）打分 → 失败案例聚类分析 → prompt/工具/图结构迭代 → 重新评估。在线评估（Online Evaluation）通过 A/B 测试、灰度发布、用户反馈（thumbs up/down）、业务漏斗指标（完成率、转化率）持续监控。

23.2 LangSmith 评估框架 ​

LangSmith 评估框架由四个要素组成：Dataset（数据集）、Target（被评估对象，Runnable 或 Graph）、Evaluators（评分器集合）、evaluate()（批量运行与聚合 API）。

Dataset 创建方式包括：在 UI 手动录入；从历史 Threads/Trace 转化（把真实线上对话转化为测试用例）；合成（用强模型按 schema 批量生成，需人工抽检）；对抗样本（提示注入、越狱、模糊指令、多轮上下文陷阱）。

评分器分为五类：

  • 规则评分器：精确匹配、子串包含、正则、JSON Schema 校验，适合结构化字段（如 SQL、函数参数）。
  • LLM-as-judge：用强模型（如 gpt-4o、claude-opus）按 rubric（评分细则）对答案打分，需给出评分等级、加分项、扣分项、示例，减少偏好偏差。
  • 自定义 Python 函数：接收 run、example、output 三参，返回布尔或分数，用于业务逻辑校验。
  • 嵌入相似度：计算输出与参考答案的 embedding 余弦相似度，适合开放式问答，但阈值需人工校准。
  • 轨迹评分器（Trajectory Evaluator）：检查 Run Tree 中工具调用顺序、数量、参数，用于过程评估。

evaluate() 在 Dataset 上批量调用 target，对每个样例跑所有 evaluator，聚合成准确率、平均分、P95 延迟、平均成本等指标并写入 LangSmith。

python
# pip install langsmith langchain-openai
from langsmith import Client
from langsmith.evaluation import evaluate, LangChainStringEvaluator

client = Client()
# dataset 需在 LangSmith UI 或 API 中预先创建
correctness = LangChainStringEvaluator(
    "score_string", config={"criteria": {"correctness": "回答是否准确解决用户问题，0-5分"}}
)

def target(inputs: dict) -> dict:
    return {"output": "假设的Agent输出"}  # 实际为 agent.invoke(inputs)

results = evaluate(
    target,
    data="rag-agent-dev-v1",
    evaluators=[correctness],
    experiment_prefix="rag-agent-exp",
)

数据集构建策略上，生产日志按业务场景分层抽样，确保覆盖高频与长尾；手工标注聚焦高价值/高风险场景（支付、合规）；合成数据用于扩充冷门 case；对抗样本单独成集用于安全回归。公开基准方面，GAIA 测试通用 Assistant 能力、AgentBench 测试多环境 Agent、SWE-bench 测试软件工程 Agent、ToolBench 测试工具调用能力，可作为能力基线参考。

典型客服 Agent 指标体系包括：问题解决率、一次解决率（FCR）、平均转人工率、工具调用准确率、平均对话轮次、平均 token 成本、P95 响应时间、用户满意度（CSAT）。

23.3 反模式、示例与治理 ​

评估反模式包括：其一，单点 LLM-as-judge：单一模型单轮打分存在立场与风格偏好偏差，需多模型交叉或加规则校验；其二，数据泄漏：评估集样本进入训练/开发 few-shot 中，导致虚高；其三，不可复现：批量评估时未固定 temperature=0、未设 seed，每次分数波动不可比；其四，只看答案不看过程：高准确率掩盖冗余调用与高成本问题；其五，评估集过小：少于 50 条的测试集置信区间过宽，结论不可靠。

本章小结：Agent 评估必须同时覆盖结果、过程、效率、鲁棒性、安全五个维度；离线评估基于 Dataset+Evaluator 的批量框架，在线评估依赖灰度与业务指标；LLM-as-judge 是核心手段但需配合规则与轨迹评分共同校准。

常见错误：评估集样本量不足（<50）导致分数波动大；rubric 描述模糊（如"回答要好"）致使 LLM 评分一致性低；只评最终答案、忽略工具调用顺序与参数正确性；未记录成本与延迟，导致上线后超预算；直接全量发布新 Agent 版本而不做灰度，线上指标劣化无法快速回滚。

生产建议：建立黄金测试集（Golden Dataset），覆盖核心场景+边界+对抗样本，随版本演进持续补充；temperature=0、固定 seed、固定工具 mock 响应，让离线评估可复现；LLM-as-judge 的 rubric 需经过标注员一致性校验（Kappa > 0.6）；把评估分数与成本、延迟同时作为发布门槛；在线灰度按流量比例逐步放大，监控业务指标与反馈率双阈值触发回滚。