Presentation: Building Reusable Evaluation Frameworks for Agentic AI Products

来源：InfoQ

从烟囱式评估到可复用框架：Elastic 的 Agentic AI 产品评估实践

背景与概述

随着大语言模型（LLM）驱动的 Agentic AI（智能体式 AI）产品逐渐从演示走向生产环境，一个日益突出的问题浮出水面：如何科学地评估一个 Agent 的表现？ 传统的软件测试方法——单元测试、集成测试、断言匹配——在 Agent 面前大多失效，因为 Agent 的输出是开放式的、非确定性的，同一条用户指令可能产生多条不同但同样合理的执行路径。

在 InfoQ 的演讲《Building Reusable Evaluation Frameworks for Agentic AI Products》中，Elastic 的 Susan Chang 分享了 Elastic 在这方面的探索：公司从各团队各自为战、烟囱式（siloed）的评估方式，逐步过渡到一套统一、可复用的评估框架（具体演进路径与细节因摘要截断而待核实，建议读者阅读原文或观看演讲视频了解完整脉络）。

这个话题的价值在于，评估体系往往决定了一个 AI 产品能否真正迭代：没有可靠的评估，你既不知道模型升级是进步还是倒退，也无法对 Prompt 工程、RAG 链路或工具调用的改动做出数据驱动的决策。

核心内容

基于演讲主题与行业通行实践，可复用评估框架的核心要点通常包括以下几个方面（其中属于本演讲明确内容的标注为已确认，其余为通用行业实践的合理阐述）：

统一评估抽象，消除烟囱式重复。当每个团队各自搭建评估脚本时，评估标准、数据集格式和评分口径互不兼容，结果无法横向比较。可复用框架的首要目标是将"评估什么"（指标定义）与"怎么评估"（执行引擎）解耦。

评估指标的分层设计。Agentic AI 的评估通常不是单一分数，而是多维度指标的组合，例如：

正确性/任务完成度：Agent 是否达成了用户目标；
忠实性（Faithfulness）：生成内容是否基于检索到的上下文，有无幻觉；
相关性（Relevance/Relevancy）：回答是否切题；
工具调用正确性：Agent 是否选择了正确的工具、传入了正确的参数；
成本与延迟：Token 消耗、端到端响应时间。

支持人类评审与 LLM-as-a-Judge 结合。完全自动化评估虽然成本低，但存在评审模型自身的偏差；完全人工评审又无法规模化。框架需要允许两者混合编排。（该设计在演讲中的具体占比待核实。）

回归测试与持续集成。评估框架应当能嵌入 CI/CD 流水线，在每次 Prompt 变更、模型升级或知识库更新后自动运行基准测试集，防止性能退化。

面向多团队复用的工程化。框架需要支持不同团队注册自己的数据集、指标和 Agent 实现，同时共享核心的执行与报告能力——这也是"Reusable"一词的核心含义。

技术分析

从技术架构角度看，一个可复用的 Agent 评估框架通常由四层组成：

┌─────────────────────────────────┐
│  数据集层：测试用例、黄金答案        │
├─────────────────────────────────┤
│  指标层：正确性/忠实性/相关性等     │
├─────────────────────────────────┤
│  执行引擎：并发运行、采样、判分      │
├─────────────────────────────────┤
│  报告层：分数聚合、趋势追踪、对比    │
└─────────────────────────────────┘

值得深入讨论的是 LLM-as-a-Judge 的实现思路：用一个（通常更强或不同的）模型作为评审员，对 Agent 的输出按评分准则打分。实践中常用 Python 生态中的评估库（如 Ragas、DeepEval 或 LangSmith）快速起步，例如 Ragas 中的忠实性指标：

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy

result = evaluate(
    dataset,               # 包含 question / answer / contexts 的数据集
    metrics=[faithfulness, answer_relevancy],
)
print(result)

使用 LLM 评审时需要警惕几个陷阱：评审模型可能存在位置偏差（倾向给排在前面的答案更高分）和冗长偏差（倾向偏爱更长的回答），因此业界普遍建议采用成对比较、随机化顺序等缓解手段。此外，评估所用的模型版本应当锁定并记录，否则评估结果的漂移将无法归因。

对于 Agent 特有的多步推理与工具调用，评估还需要关注轨迹（trajectory）层面：不仅看最终答案，还要看中间步骤是否合理、有无无效循环、工具参数是否正确。这类轨迹级评估的实现复杂度较高，是框架设计中最具挑战性的部分（Elastic 的具体实现细节待核实）。

实践建议

如果你正准备为自己的 Agentic AI 产品搭建评估体系，可以参考以下路径：

先定义指标，再谈自动化。和团队明确"什么算一次成功的对话"，把模糊的"感觉不错"转化为可度量的指标。
从最小可行评估开始。先建立 50~100 条高质量的测试用例（含黄金答案或评分标准），比拥有一万条粗糙数据更有价值。
用人工标注校准 LLM 评审。抽取一部分样本让 LLM 与人类评审对齐，估算两者的一致性后再扩大自动化比例。
把评估跑进 CI。每次修改 Prompt、切换模型或更新检索索引后自动触发回归评估，让评估成为发布流程的守门员。
构建可对比的基线。每次变更记录模型版本、参数配置与评估分数，形成可追溯的性能曲线。
警惕评估自身的成本。Agent 评估往往比单次推理昂贵得多（多步执行 × 评审模型调用），需要在覆盖度与预算间做权衡。

总结

Susan Chang 在 Elastic 的这次分享，切中了当前 Agentic AI 落地中最被低估的一环：评估不是上线后的锦上添花，而是迭代过程中的基础设施。从烟囱式脚本走向统一的可复用框架，本质上是把"评估"从个别工程师的隐性经验，沉淀为组织级别的工程能力。对于正在或计划构建 AI Agent 的中国开发者而言，这个话题的启发在于——尽早投资评估体系，往往比追逐最新的模型或框架更能带来长期的复利。

参考资料：InfoQ 演讲原文（本文部分实现细节因原文摘要不完整标注为"待核实"，请以演讲原文为准。）

立即实践

体验现有 smallcode: AI coding agent optimized for small LLM，验证上述工作流的输入、结果与下一步操作。此 Demo 是相关实践工具，不代表原项目的完整实现。

Article summary