作者：来自 Elastic Susan Chang 及 Abhimanyu Anand

了解我们如何在向 Elastic 用户发布之前评估和测试代理系统的更改，以确保结果准确且可验证。

通过我们的点播网络研讨会提升你的技能：使用 Elasticsearch 的 Agentic RAG，以及使用 Elasticsearch MCP Server 的 MCP 入门。

你现在还可以通过启动免费的云试用或在本地运行 Elasticsearch 来利用 Elastic 的生成式 AI 功能。

---

介绍

在 Elastic Stack 中，有许多由 LLM 驱动的代理应用，例如即将推出的 Agent Builder 中的 Elastic AI Agent（目前为技术预览）和 Attack Discovery（在 8.18 和 9.0+ 中正式发布），还有更多正在开发中。在开发期间，甚至在部署之后，回答以下问题都很重要：

• 这些 AI 应用的响应质量该如何评估？
• 如果我们进行了更改，如何确保这些更改确实是改进，而不会导致用户体验下降？
• 我们如何以可重复的方式轻松测试这些结果？

与传统软件测试不同，生成式 AI 应用的评估涉及统计方法、细致的定性审查以及对用户目标的深刻理解。

本文详细介绍了 Elastic 开发团队在执行评估、确保更改质量以及监控系统性能时所采用的流程。我们的目标是确保每一次更改都有证据支持，从而带来可信且可验证的结果。这个流程的一部分直接集成在 Kibana 中，体现了我们作为开源文化一部分的透明承诺。通过公开共享部分评估数据和指标，我们希望促进社区信任，并为开发 AI 代理或使用我们产品的任何人提供一个清晰的框架。

产品示例

本文所使用的方法是我们改进和迭代 Attack Discovery 和 Elastic AI Agent 等解决方案的基础。以下是这两者的简要介绍：

Elastic Security 的 Attack Discovery

Attack Discovery 使用 LLM 来识别并总结 Elastic 中的攻击序列。根据给定时间范围内（默认 24 小时）的 Elastic Security 警报，Attack Discovery 的代理工作流会自动检测是否发生攻击，以及诸如哪些主机或用户被攻陷、哪些警报促成了这一结论等重要信息。

目标是让基于 LLM 的解决方案输出的结果至少与人类一样好。

Elastic AI Agent

Elastic Agent Builder 是我们用于构建具备上下文感知能力的 AI Agent 的新平台，它充分利用了我们的搜索功能。该平台内置了 Elastic AI Agent，这是一个预构建的通用代理，旨在通过对话式交互帮助用户理解并从他们的数据中获取答案。

该代理通过自动识别 Elasticsearch 或连接的知识库中的相关信息，并利用一组预构建的工具与之交互来实现这一点。这使得 Elastic AI Agent 能够应对各种用户查询，从单个文档的简单问答，到需要在多个索引中进行聚合或单步、多步搜索的复杂请求。

通过实验衡量改进

在 AI 代理的上下文中，实验是一种有结构、可测试的系统更改，旨在在明确定义的维度（例如：有用性、正确性、延迟）上提升性能。目标是明确回答：“如果我们合并此更改，能否确保它是真正的改进，而不会降低用户体验？”

我们进行的大多数实验通常包括：

• 假设：一个具体且可证伪的主张。示例：“增加对攻击检测工具的访问可提升与安全相关查询的正确性。”

• 成功标准：定义 “成功” 含义的清晰阈值。示例：“在安全数据集上的正确性得分提高 5%，其他部分无性能下降。”

• 评估计划：我们如何衡量成功（指标、数据集、比较方法）

一个成功的实验是一个系统化的探索过程。每一个更改 —— 从轻微的提示调整到重大的架构变更 —— 都遵循以下七个步骤，以确保结果具有意义且可执行：

步骤 1：确定问题
步骤 2：定义指标
步骤 3：制定清晰的假设
步骤 4：准备评估数据集
步骤 5：运行实验
步骤 6：分析结果并迭代
步骤 7：做出决策并记录

这些步骤的示例如图 1 所示。以下小节将解释每个步骤，我们将在后续文档中进一步展开每个步骤的技术细节。

逐步演练，使用真实的 Elastic 示例
 

步骤 1：确定问题

这个更改旨在解决的具体问题是什么？

• Attack Discovery 示例：摘要有时不完整，或者将良性活动错误标记为攻击（误报）。

• Elastic AI Agent 示例：代理在工具选择上（尤其是用于分析查询时）表现次优且不一致，经常选择错误的工具，进而增加了 token 成本 和 延迟。

步骤 2：定义指标

使问题可量化，以便我们可以将更改与当前状态进行比较。

常见指标包括精确率与召回率、语义相似度、事实性等。根据用例，我们使用代码检查来计算指标，例如匹配警报 ID 或正确检索的 URL，或使用诸如 LLM-as-judge 之类的技术来评估更自由形式的回答。

下面是实验中使用的一些示例指标（并非详尽）：

Attack discovery

指标	描述
精确率与召回率	比较实际输出与预期输出之间的警报 ID 匹配情况，以衡量检测准确度。
相似度	使用 BERTScore 比较响应文本的语义相似性。
事实性	关键的 IOCs（入侵指标）是否存在？MITRE 攻击战术（行业攻击分类）是否被正确反映？
攻击链一致性	比较发现数量，以检查攻击是否被过度或不足报告。

Elastic AI Agent

指标	描述
精确率与召回率	比较代理检索的文档/信息与回答用户查询所需的实际信息或文档，以衡量信息检索的准确性。
事实性	回答用户查询所需的关键事实是否存在？对于流程性查询，事实的顺序是否正确？
响应相关性	响应中是否包含与用户查询无关或次要的信息？
响应完整性	响应是否回答了用户查询的所有部分？响应是否包含地面实况中所有信息？
ES|QL 验证	生成的 ES|QL 语法是否正确？其功能是否与地面实况 ES|QL 相同？

步骤 3：制定清晰的假设

使用上述问题和指标建立明确的成功标准。

Elastic AI Agent 示例：

• 对 relevance_search 和 nl_search 工具的描述进行更改，以清晰定义其具体功能和使用场景。

• 我们预测工具调用准确率将提高 25%。

• 我们将通过确保对其他指标（如事实性和完整性）没有负面影响来验证这是净正效应。

• 我们认为这将有效，因为精确的工具描述将帮助代理更准确地为不同类型的查询选择和应用最合适的搜索工具，减少误用并提高整体搜索效果。

步骤 4：准备评估数据集

为了衡量系统性能，我们使用能够反映真实场景的数据集。

根据评估类型，我们可能需要不同类型的数据格式，例如输入 LLM 的原始数据（如 Attack Discovery 的攻击场景）和预期输出。如果应用是聊天机器人，则输入可能是用户查询，输出可能是正确的聊天机器人响应、应检索的正确链接等。

Attack Discovery 示例：

10 个新颖攻击场景
8 集 Oh My Malware 剧集（ohmymalware.com）
4 个多攻击场景（通过组合前两类攻击创建）
3 个良性场景

Elastic AI Agent 评估数据集示例（Kibana 数据集链接）：

使用开源数据集的 14 个索引，用于模拟知识库中的多个来源。
5 种查询类型（分析型、文本检索型、混合型…）
7 种查询意图类型（流程型、事实型 - 分类型、调查型…）

步骤 5：运行实验

通过对评估数据集分别生成现有代理和修改后版本的响应来执行实验。计算诸如事实性等指标（见步骤 2）。

我们根据步骤 2 所需的指标混合使用各种评估方法：

• 基于规则的评估（例如使用 Python/TypeScript 检查 .json 是否有效）

• LLM-as-judge（询问另一个 LLM 响应是否与源文档在事实上一致）

• 人工参与的审查，以进行细微质量检查

第 6 步：分析结果 + 迭代

现在我们有了指标，就可以分析结果。即使结果满足第 3 步中定义的成功标准，也仍然需要人工复核后再合并到生产环境；如果结果不符合标准，需要进行迭代并修复问题，然后在新的修改上重新运行评估。

我们预计需要几轮迭代才能找到最佳修改。类似于在推送提交前运行本地软件测试，离线评估可以针对本地更改或多个提议的更改进行。自动保存实验结果、综合得分和可视化内容有助于简化分析过程。

第 7 步：做出决策并记录

根据决策框架和接受标准，决定是否合并更改，并记录实验过程。决策是多方面的，可以考虑评估数据集之外的因素，例如检查其他数据集上的回归情况或权衡拟议更改的成本–收益。

示例：在测试和比较几轮迭代后，选择得分最高的更改，并发送给产品经理和其他相关利益方审批。附上前几步的结果，以帮助指导决策。有关更多示例，请参见 Elastic Security 的生成式 AI 功能幕后介绍。

结论

在本篇博客中，我们介绍了实验工作流的端到端流程，展示了在向 Elastic 用户发布前，如何评估和测试对智能代理系统的更改。我们还提供了一些在 Elastic 中改进基于代理的工作流的示例。在后续博客中，我们将详细扩展各个步骤的内容，例如如何创建良好的数据集、如何设计可靠的指标，以及在涉及多个指标时如何做出决策。

原文：https://www.elastic.co/search-labs/blog/ai-agent-evaluation-elastic