人工智能代理开发团队需要进行不止最终答案检查，才能了解系统是否按预期运行。在结合检索、生成和工具调用的应用中，错误结果可能源于选择了错误的数据库或检索到不相关的文档，即使表面上问题只出现在最终文本中。在一次通过 InfoQ 进行的演讲中，Elastic 首席数据科学家 Susan Chang 介绍了该公司如何开发一个通用框架，用于评估其应用于网络安全和企业聊天机器人的代理。
从孤立评估到共享工具
Elastic 的团队最初为每个代理分别创建数据集、评估器和追踪流程。以攻击检测代理为例，测试包括由分析师和安全研究人员编写的攻击场景与正常场景，并使用准确率、召回率、事实正确性、相似度以及 MITRE 战术分类等指标。对于依赖企业数据的聊天机器人，测试内容则包括问题和文档检索，重点关注答案的相关性与完整性、产品标识符的正确性，以及 ES|QL 查询的编写。
这些场景之间的差异导致了大量重复工作。因此，Elastic 创建了一个通用框架，能够按照统一模式导入不同类型的数据集，运行基于执行轨迹的评估，为 RAG 应用使用共享评估器，同时保留各产品专用的组件。该流程可以在本地运行，加载数据、运行代理、收集结果，然后向开发人员展示分数。
追踪是理解失败原因的必要条件
实践表明，代理追踪不应局限于其最终输出。必须记录代理调用的工具、向量和关键词搜索、检索到的数据、令牌消耗、响应时间以及决策顺序。这种详细程度可以评估特定工具的调用情况，或发现代理在问题出现在最终答案之前使用了错误的来源。
此外，还可以将用户报告的失败案例，例如负面评价，转化为测试集中的新示例。这样，生产环境中的反馈就会成为后续版本的回归测试的一部分，而不再是与开发周期分离的手工记录。
为什么 LLM-as-a-judge 不够？
Elastic 使用语言模型评估其他模型的输出，适用于风格、一致性和答案与上下文的相关性等开放式或模糊任务。当难以编写精确规则来判断长文本时，这种方法能够扩展评估范围。但它可能在不同运行之间产生不一致的结果，也可能无法发现具体错误，例如不存在的产品标识符或无效的查询表述。
因此，Elastic 将 LLM-as-a-judge 与基于规则和编程的确定性评估结合起来。这些评估会检查 JSON 或 YAML 的结构、表述的正确性、所需实体是否存在、代码或查询是否可执行，以及准确率、召回率和事实正确性等指标。这种结合可以在答案明确的情况下降低评估成本并提高速度，同时将语义判断留给难以简化为规则的任务。
哪些内容无法泛化？
Elastic 并不认为创建专门的测试数据是一个可以完全自动化的环节。在网络安全领域，团队需要分析师和研究人员确定什么构成真正的攻击，以及什么是最终用户可接受的行为。此外，不同代理对回归的定义也不同；例如，某次更新后，安全代理可能会变得更倾向于在输入正常数据时也宣称存在攻击。
评估器的校准仍然是每个团队的责任。如果语言评估器对同一案例给出不同分数，或与目标人工判断不一致，那么无论软件架构质量多高，通用框架都会产生误导性数字。Chang 还指出了评估器偏差的风险：当使用同一家族的模型进行生成和评判时，评估器可能会高估这些模型的表现。
团队在实践中会发生什么变化？
Elastic 的实践建议从一小组测试示例开始，可以包含 20 到 50 个案例，而不是等待一个完美的数据集。在早期阶段，为了加快学习，零散的工作方式可能是可以接受的，尤其是在用例和指标仍处于探索阶段时。但随着多个代理进入生产环境，基础追踪和评估对于回答性能问题以及诊断用户问题会变得必不可少。
Elastic 还将部分评估工具从 Python 转移到了 TypeScript，以匹配使用 TypeScript 编写的生产代码，并使用 Playwright 和一个名为 Scout 的定制内部工具。这一步并不意味着所有数据科学评估都必须迁移，而是反映了缩小团队测试内容与系统实际执行内容之间差距的特定需求。实际结论是，通用框架可以统一模式、运行方式和通用指标，但无法取代领域专业知识，也无法取代对什么应被视为成功或失败的判断。