在 Elastic Stack 中，有许多由 LLM 驱动的代理应用程序，例如 Agent Builder 中即将推出的 Elastic AI Agent（目前处于技术预览阶段）和 Attack Discovery （ 8.18 和 9.0+ 中的 GA ），还有更多正在开发中。在开发过程中，甚至在部署之后，回答这些问题都非常重要：

• 我们如何估算这些人工智能应用的响应质量？

• 如果我们做出改变，如何保证这种改变是真正的改进，而不会导致用户体验下降？

• 如何以可重复的方式轻松测试这些结果？

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

本文详细介绍了 Elastic 开发人员团队进行评估、确保部署前变更的质量以及监控系统性能的流程。我们的目标是确保每一项变革都有据可依，从而取得可信和可验证的成果。这一过程的一部分直接集成到了 Kibana 中，体现了我们对透明度的承诺，这也是我们开源精神的一部分。通过公开分享我们的部分评估数据和指标，我们力求促进社区信任，并为开发人工智能代理或使用我们产品的任何人提供一个清晰的框架。

产品示例

本文档中使用的方法是我们迭代和改进 "攻击发现 "和 "弹性人工智能代理 "等解决方案的基础。分别对两者进行简要介绍：

弹性安全的攻击发现

攻击发现使用 LLM 来识别和总结 Elastic 中的攻击序列。在给定的时间范围（默认 24 小时）内收到 Elastic Security 警报后，Attack Discovery 的代理工作流程会自动查找是否发生了攻击，以及重要信息，如哪台主机或用户受到了攻击，哪些警报促成了这一结论。

我们的目标是，基于 LLM 的解决方案所产生的输出结果至少与人类的输出结果一样好。

弹性人工智能代理

Elastic Agent Builder是我们的新平台，用于构建可利用我们所有搜索功能的上下文感知人工智能代理。它配备了Elastic AI Agent，这是一个预构建的通用代理，旨在通过对话式交互帮助用户理解数据并从中获得答案。

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

通过实验衡量改进

就人工智能代理而言，实验是对系统进行的结构化、可测试的更改，旨在提高系统在明确定义的维度（如有用性、正确性、延迟）上的性能。我们的目标是明确回答"如果我们合并这一改动，能否保证它是真正的改进，不会降低用户体验？

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

• 假设：一个具体的、可证伪的主张。例如"增加对攻击发现工具的访问权限，可提高安全相关查询的正确性"。

• 成功标准：明确界定 "成功 "含义的阈值。例如"在安全数据集上，正确性得分提高了 +5% ，其他方面没有降低"。

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

成功的实验是一个系统的探究过程。从细微的提示调整到重大的架构转变，每一项改变都要遵循这七个步骤，以确保结果是有意义和可操作的：

• 第 1 步：确定问题

• 第 2 步：确定衡量标准

• 步骤 3：提出明确的假设

• 步骤 4：准备评估数据集

• 步骤 5：运行实验

• 第 6 步：分析结果 + 反复试验

• 第 7 步：做出决定并记录在案

图 1 举例说明了这些步骤。下面的小节将对每个步骤进行说明，我们将在接下来的文件中详细介绍每个步骤的技术细节。

使用真实的 Elastic 示例逐步讲解

第 1 步：确定问题

这一变化究竟要解决什么问题？

攻击发现示例：摘要有时不完整，或者良性活动被错误地标记为攻击（误报）。

弹性人工智能代理示例：代理的工具选择，尤其是分析查询工具的选择，不够理想且不一致，经常导致选择错误的工具。这反过来又增加了令牌成本和延迟。

第 2 步：确定衡量标准

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

常用指标包括精确度和召回率、语义相似性、事实性等。根据不同的使用情况，我们使用代码检查来计算指标，例如匹配警报 ID 或正确检索的 URL，或者使用 LLM-as-judge 等技术来计算更自由的答案。

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

Attack Discovery

公制

描述

精确度& 召回率

在实际输出和预期输出之间匹配警报 ID，以衡量检测准确性。

相似性

使用 BERTScore 比较回复文本的语义相似性。

事实性

是否存在关键的 IOC（妥协指标）？是否正确反映了 MITRE 战术（行业攻击分类）？

攻击链一致性

比较发现的次数，检查是否存在多报或少报攻击事件的情况。

弹性人工智能代理

公制

描述

精确度& 召回率

将代理为回答用户查询而检索的文档/信息与回答查询所需的实际信息或文档进行匹配，以衡量信息检索的准确性。

事实性

是否存在回答用户查询所需的关键事实？程序性查询的事实顺序是否正确？

回应相关性

回复是否包含与用户查询无关的信息？

答复完整性

回复是否回答了用户查询的所有部分？回复是否包含地面实况中的所有信息？

ES|QL 验证

生成的 ES|QL 语法正确吗？它在功能上是否与地面实况 ES|QL 相同？

步骤 3：提出明确的假设

利用问题和上文定义的衡量标准，制定明确的成功标准。

弹性人工智能代理示例：

1. 对 relevance_search 和 nl_search 工具的说明进行修改，以明确定义其具体功能和用例。

2. 我们预测，我们的 工具调用准确率 将 提高 25% 。

3. 我们将通过确保不对其他指标产生负面影响来验证这是否是一个净积极因素，例如事实性和完整性。

4. 我们相信这将行之有效，因为精确的工具描述将帮助代理针对不同查询类型更准确地选择和应用最合适的搜索工具，从而减少错误应用，提高整体搜索效率。

步骤 4：准备评估数据集

为了衡量系统的性能，我们使用了能捕捉真实世界场景的数据集。

根据我们所进行的评估类型，我们可能需要不同类型的数据格式，例如反馈给 LLM 的原始数据（例如："......"）。攻击发现的攻击场景）和预期产出。如果应用程序是聊天机器人，那么输入可能是用户查询，输出可能是聊天机器人的正确回复、本应检索到的正确链接等。

攻击发现示例

10 种新颖的攻击情景

8 集 Oh My Malware (ohmymalware.com)

4 种多重攻击情景（通过组合前两类攻击而创建）

3 种良性情景

弹性人工智能代理评估数据集示例（Kibana 数据集链接）：

14 使用开放源码数据集模拟 KB 中多个来源的指数。

5 种查询类型（分析型、文本检索型、混合型...）

7 查询意图类型（程序、事实--分类、调查......）

步骤 5：运行实验

执行实验，根据评估数据集生成现有代理和修改版代理的响应。计算事实性等指标（见第 2 步）。

我们根据步骤 2 中要求的指标，将各种评估混合在一起：

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

• 法学硕士即法官（询问另一位法学硕士某项答复是否与源文件的事实相符）

• 人在回路中审查，进行细微差别质量检查

第 6 步：分析结果 + 反复试验

现在我们有了衡量标准，可以对结果进行分析。即使结果符合步骤 3 中定义的成功标准，在将变更合并到生产之前，我们仍要进行人工审核；如果结果不符合标准，则要进行迭代并修复问题，然后在新变更上运行评估。

我们预计，在合并之前，需要反复几次才能找到最佳修改。与在推送提交之前运行本地软件测试类似，离线评估也可与本地变更或多个建议变更一起运行。自动保存实验结果、综合分数和可视化效果，简化分析过程，非常有用。

第 7 步：做出决定并记录在案

根据决策框架和验收标准，决定是否合并变更，并将实验记录在案。决策是多方面的，可以考虑评估数据集以外的因素，如检查其他数据集的回归情况，或权衡拟议变更的成本效益。

举例说明：在测试和比较几次迭代后，选择得分最高的变更，发送给产品经理和其他相关利益者审批。附上前几个步骤的结果，以帮助指导决策。有关攻击发现方面的更多示例，请参阅《Elastic Security 的生成式人工智能功能幕后》。

结论

在这篇博客中，我们介绍了实验工作流程的端到端过程，说明了我们如何在向 Elastic 用户发布代理系统变更之前对其进行评估和测试。我们还提供了一些在 Elastic 中改进基于代理的工作流的示例。在随后的博文中，我们将详细介绍不同步骤的细节，例如如何创建一个好的数据集、如何设计可靠的度量标准，以及在涉及多个度量标准时如何做出决策。