作者：来自 Elastic Bahubali Shetti

作为 SRE，分析应用程序比以往更加复杂。 你不仅必须确保应用程序以最佳状态运行以确保良好的客户体验，而且还必须了解某些情况下的内部工作原理以帮助排除故障。 分析基于生产的服务中的问题是一项团队运动。 它需要 SRE、DevOps、开发和支持才能找到根本原因并进行潜在的补救。 如果它有影响，那就更糟了，因为这是一场与时间的赛跑。 无论情况如何，都有大量信息需要消耗和处理。 这不仅包括客户正在经历的情况，还包括有助于提供最合适解决方案的内部数据。

Elastic 的 AI Assistant 有助于改进 SRE、DevOps、Dev 等的分析。 在使用自然语言问题的单个窗口中，你不仅可以使用一般信息进行分析，还可以将其与以下内容结合起来：

• 来自内部 GitHub 存储库、Jira 等的问题。
• 来自 Confluence 等内部 wiki 站点的文档。
• 你的支持服务引起的客户问题
• 和更多

在本博客中，我们将引导你了解如何：

1. 将包含代码和问题的外部 GitHub 存储库（OpenTelemetry 演示存储库）提取到 Elastic 中。 应用 Elastic Learned Sparse EncodeR (ELSER) 并将其存储在 AI 助手的特定索引中。
2. 将包含 Runbook 信息的内部 GitHub 存储库提取到 Elastic 中。 应用 ELSER 并将处理后的数据存储在AI助手的特定索引中。
3. 使用 AI 助手分析 Elastic 中的 OpenTelemetry 演示的问题时，请使用这两个索引。

使用 GitHub 数据和 AI Assistant 解决 3 个简单问题

在我们完成从 GitHub 设置数据的步骤之前，让我们回顾一下 SRE 可以使用 AI 助手和 GitHub 存储库做什么。

我们最初使用 Elastic GitHub 连接器连接到 GitHub，并提取和处理两个存储库：OpenTelemetry 演示存储库（公共）和内部 Runbook 存储库（Elastic 内部）。

通过 ELSER 加载并解析这两个之后，我们向 AI 助手询问一些分析过程中通常会问到的简单问题。

OpenTelemetry 演示有多少问题尚未解决？

由于我们提取了整个存储库（截至 2024 年 4 月 26 日），文档数量为 1,529，因此我们向它询问一个关于未解决问题总数的简单问题。 我们特别告诉 AI 助手搜索我们的内部索引，以确保 LLM 知道要求 Elasti c搜索其内部索引以获取问题总数。

基于 Rust 的 shippingservice有任何问题吗？

Elastic 的 AI Assistant 使用 ELSER 遍历加载的 GitHub 存储库，并找到针对 shippingservice 的未解决问题（这是撰写本文时的以下问题）。

有 Cartservice 的操作手册吗？

由于我们加载了带有一些示例 Runbook 的内部 GitHub 存储库，因此 Elastic AI Assistant 可以正确找到该 Runbook。

在浏览本博客时，我们将讨论 AI 助手如何使用 ELSER 发现这些问题，以及如何将其配置为使用你自己的 GitHub 存储库。

使用 Elastic AI Assistant 进行检索增强生成 (RAG)

Elastic 拥有最先进的基于 RAG 的 AI 助手，可实现可观察性和安全性。 它可以帮助你使用以下方式分析数据：

你最喜欢的 LLM（OpenAI、Azure OpenAI、AWS Bedrock 等）
你可以连接到或引入 Elastic 索引的任何内部信息（GitHub、Confluence、客户问题等）

Elastic 的 AI Assistant 之所以能够做到这一点，是因为它支持 RAG，这有助于检索内部信息以及基于 LLM 的知识。

将 SRE 的相关内部信息添加到 Elastic 中：

• 当数据进入时（例如在 GitHub 存储库中），ELSER 会应用于数据，并添加嵌入（稀疏向量场中的权重和标记）以捕获数据的语义和上下文。
• 这些数据（GitHub、Confluence 等）经过嵌入处理并存储在 AI 助手可以搜索的索引中。

当你查询 AI 助手信息时：

• 该查询与使用 ELSER 提取的数据经历相同的推理过程。 输入查询生成一个“稀疏向量”，用于在摄取的数据（GitHub、Confluence 等）中查找最相关的高排名信息。
• 然后，检索到的数据与查询相结合，并发送到 LLM，然后 LLM 将添加自己的知识库信息（如果需要添加任何内容），或者可能要求 Elastic（通过函数调用）进行分析、绘制图表、甚至进一步搜索。 如果对 Elastic 进行函数调用并提供响应，LLM 会将其添加到其响应中。
• 结果将是结合 LLM 和内部数据中任何相关内容的最基于上下文的答案。

应用程序、先决条件和配置

如果你想尝试本博客中的步骤，请满足以下一些先决条件：

• Elastic Cloud 帐户 — 立即注册
• OpenTelemetry 演示正在运行并连接到 Elastic（APM 文档）
• 无论你想要使用什么内部 GitHub 存储库，以及一些对分析有用的信息（在我们的演练中，我们将使用一个 GitHub 存储库，其中包含 Elastic 进行演示时不同场景的 runbooks）。
• 拥有你最喜爱或批准的 LLM 的帐户（OpenAI、Azure OpenAI、AWS Bedrock）

将 GitHub 存储库添加到 Elastic

第一步是设置 GitHub 连接器并连接到你的 GitHub 存储库。 Elastic 拥有来自 GitHub、Confluence、Google Drive、Jira、AWS S3、Microsoft Teams、Slack 等的多个连接器。 因此，虽然我们将在本博客中介绍 GitHub 连接器，但不要忘记其他连接器。

选择 GitHub 连接器并为其命名后，你需要添加两项：

• GitHub token
• URL open-telemetry/opentelemetry-demo

接下来，将其添加到向导中的索引中。

创建管道并使用 ELSER 处理数据

为了添加我们在上一节中讨论的嵌入，我们需要将以下内容添加到连接器：

• 在配置向导中创建管道。
• 创建自定义管道。
• 添加 ML 推理管道。
• 选择 ELSERv2 ML 模型以添加嵌入。
• 选择需要作为推理管道一部分进行评估的字段。
• 测试并保存推理管道和整体管道。

同步数据

现在管道已创建，你需要开始同步 github 存储库。 当来自 github 存储库的文档进入时，它们将通过管道并添加嵌入。

嵌入

设置管道后，同步连接器中的数据。 当 GitHub 存储库进入时，推理管道将按如下方式处理数据：

• 当数据从 GitHub 存储库传入时，ELSER 会应用于数据，并添加嵌入（稀疏向量场中的权重和 tokens）以捕获数据的语义和上下文。
• 该数据经过嵌入处理并存储在可由 AI 助手搜索的索引中。

当你查看提取的 OpenTelemetry GitHub 文档时，你将看到如何将权重和 tokens 添加到索引中的 Predicted_value 字段。

当用户向人工智能助手提出查询时，这些嵌入现在将用于查找上下文最相关的文档，人工智能助手可能会使用它。

检查 AI 助手是否可以使用索引

Elastic 的 AI 助手使用 ELSER 遍历加载的 Github 存储库，并找到针对 shippingservice 的未解决问题。 （这是撰写本文时的以下问题）。

根据响应，我们可以看到 AI 助手现在可以使用索引来查找问题并用于进一步分析。

结论

你现在已经看到了 Elastic 基于 RAG 的 AI 助手的设置是多么容易。 你可以从多个位置（GitHub、Confluence、Slack 等）引入文档。 我们展示了 GitHub 和 OpenTelemetry 的设置。 这些内部信息可用于管理问题、加速解决和改善客户体验。 查看我们的其他博客，了解 AI 助手如何帮助 SRE 更好地分析、降低 MTTR 并改善整体运营：

• 使用 Elastic AI Assistant 和 APM 分析 OpenTelemetry 应用程序
• 用于可观察性的 Elastic AI 助手摆脱了 Kibana！
• Elastic AI Assistant for Observability 和 Microsoft Azure OpenAI 入门
• Elastic 8.13：Elastic AI Assistant for Observability 中 Amazon Bedrock 的 GA
• 使用 AI Assistant for Observability 和组织的运行手册增强 SRE 故障排除
• 使用 Elastic AI Assistant for Observability 获得情境感知洞察
• Elastic AI Assistant for Observability 和 Amazon Bedrock 入门

试试看

现有 Elastic Cloud 客户可以直接从 Elastic Cloud 控制台访问其中许多功能。 没有利用云上的 Elastic？ 开始免费试用。

所有这一切在你的环境中也是可能的。 今天就了解如何开始。

本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。

在这篇博文中，我们可能使用或引用了第三方生成人工智能工具，这些工具由其各自所有者拥有和运营。 Elastic 对第三方工具没有任何控制权，我们对其内容、操作或使用不承担任何责任，也不对你使用此类工具可能产生的任何损失或损害负责。 使用人工智能工具处理个人、敏感或机密信息时请务必谨慎。 你提交的任何数据都可能用于人工智能培训或其他目的。 无法保证你提供的信息将得到安全或保密。 在使用之前，你应该熟悉任何生成式人工智能工具的隐私惯例和使用条款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标志是 Elasticsearch N.V. 的商标、徽标或注册商标。 在美国和其他国家。 所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

原文：Elastic's RAG-based AI Assistant: Analyze application issues with LLMs and private GitHub issues | Elastic Blog