引言

在当今快节奏的技术环境中,维持稳健的值班运营对确保服务顺畅运行至关重要。现代平台工程团队面临着高效管理值班排班、事件响应、关键时刻沟通以及在 Slack® 渠道上提供强有力客户支持的挑战。

本文介绍了我们构建的名为 Genie 的值班副驾驶,它使用生成式 AI 来优化与值班工程师之间的沟通和问答。

深入了解:问题和动机

在 Uber,像 Michelangelo 团队这样的不同团队都有 Slack 支持渠道,内部用户可以在那里寻求帮助。如图 1 所示,每月在这些渠道上提出约 45,000 个问题。高问题量和长响应等待时间降低了用户和值班工程师的工作效率。

图 1: Uber 各 Slack 渠道 5 个月内提出的大量问题。

繁琐的流程

图 2: 等待值班工程师回答问题的缓慢过程。

通常,当用户在 Slack 渠道提出问题时,他们必须等待值班工程师回应。值班工程师要么回答用户的初始问题,要么要求提供更多细节。然后用户可能会提出后续问题、寻求更多澄清或提供额外信息。这导致需要再次等待值班工程师的回应。经过几轮来回沟通后,用户的问题最终得到解决。

难以找到信息

许多问题本可以通过查阅现有文档得到解答,但信息分散在 Uber 的内部 wiki(称为 Engwiki)、内部 Stack Overflow 和其他位置,这使得找到具体答案变得困难。因此,用户经常重复提出相同的问题,导致数百个 Slack 渠道对值班支持的需求很高。

架构挑战

为了构建值班副驾驶,我们在微调 LLM 模型和利用 检索增强生成(RAG)^[1] 之间做出选择。微调需要经过策划的高质量、多样化示例数据供 LLM 学习。它还需要计算资源来用新示例更新模型。

相比之下,RAG 一开始不需要任何多样化的示例。这减少了副驾驶发布的上市时间,所以我们为副驾驶选择了这种方法。

构建值班副驾驶面临几个挑战,包括解决幻觉、保护数据源和改善用户体验。以下是我们如何解决每个挑战的概述。

对于幻觉,我们专注于:

• 响应的准确性: 我们确保副驾驶为问题检索相关知识,这可以防止 LLM 引擎生成不正确或误导性信息

• 验证机制: 我们实施方法来根据权威来源验证副驾驶的响应,以减少幻觉的可能性

• 持续学习: 我们确保副驾驶能访问最新数据以提高其准确性

对于数据安全,我们谨慎选择要摄取的数据源,因为许多数据源不能在 Slack 渠道中暴露。

为了改善用户体验,我们设计了:

• 直观的界面: 我们设计了一个易于使用的界面,让用户能够高效地与副驾驶互动

• 反馈循环: 我们创建了一个系统,让用户能够对响应提供反馈,以不断改进副驾驶的性能

在开发值班副驾驶时,我们解决了这些挑战,以确保它可靠、用户友好且安全。

深入探讨:架构

让我们探索我们的值班副驾驶 Genie 的架构。

图 3: 值班副驾驶的架构。

从高层次来看,我们抓取内部数据源(如 Uber 的内部 wiki、Uber 的内部 Stack Overflow、工程需求文档),并使用 Open AI 嵌入模型从这些数据源创建向量。这些嵌入存储在向量数据库中。然后,当用户在 Slack 渠道发布问题时,该问题会被转换为嵌入。服务在向量数据库中搜索与问题相关的嵌入。由嵌入索引的结果被用作 LLM 的提示以获得响应。

以下使用 Apache Spark™ 进行数据准备、嵌入和推送工件以供服务的步骤可以概括为 RAG 应用程序。这些一般步骤构成了 RAG 应用程序的基础。

ETL

图 4: 用于数据摄取的 Spark 应用程序。

图 4 显示了一个包含将数据摄取到向量数据库步骤的自定义 Spark 应用程序。Spark 应用程序使用 Spark 执行器运行这些步骤。

数据准备

Spark 应用程序使用 Uber 的内部 wiki(称为 Engwiki)或 Uber Stack Overflow API 从相应的数据源获取内容。从这个数据准备阶段输出 Spark 数据框。模式在一列中包含 Engwiki 链接,在另一列中包含 Engwiki 的内容,两者都是字符串格式。

图 5: 来自 Engwiki 数据源的 Spark 数据框的列。

图 5 显示了以 Uber 的内部 wiki 为原始数据源的 Spark 数据框的列。它具有源 URL、内容和存储元数据的其他列。

嵌入生成

一旦抓取了数据,就使用 OpenAI 嵌入模型创建嵌入并推送到 Terrablob(Uber 的 blob 存储)。创建的嵌入只能通过与 Engwiki 空间相关的特定 Slack 渠道访问。输出格式是具有分块内容映射到该块对应向量的模式的数据框。Uber 的内部 wiki 内容使用 langchain 进行分块,并通过带有 PySpark UDF 的 OpenAI 生成嵌入。

图 6: 带有向量嵌入的 Spark 数据框的列。

图 6 显示了以 Uber 的内部 wiki 为原始数据源的 Spark 数据框的列。它具有源 URL、内容、分块内容以及该特定块的嵌入。

推送器

图 7: 向量推送到 Terrablob 的流程。

图 7 显示了向量如何推送到 Terrablob。触发引导作业将数据从数据源摄取到 Sia(Uber 的内部向量数据库解决方案)。然后触发两个 Spark 作业用于索引构建和合并并将数据摄取到 Terrablob。每个叶子同步并下载存储在 Terrablob 中的基本索引和快照。在检索期间,查询直接发送到每个叶子。

知识服务

图 8: 后端知识服务的流程。

Genie 有一个名为知识服务的后端服务,它通过首先将传入查询转换为嵌入,然后从向量数据库获取最相关的块来服务所有传入查询的传入请求。

成本跟踪

图 9: Genie 成本跟踪流程。

对于成本跟踪,当 Slack 客户端或其他平台调用知识服务时,UUID 会传递给知识服务,后者通过上下文标头将 UUID 传递给 Michelangelo 网关。Michelangelo 网关是 LLM 的传递服务,因此可以将其添加到用于按该 UUID 跟踪成本的审计日志中。

Genie 性能评估

指标框架

用户可以通过点击 Genie 回复中的相关按钮在 Slack 中立即提供反馈。我们让用户可以选择:

• 已解决: 答案完全解决了问题

• 有帮助: 答案部分有帮助,但用户需要更多帮助

• 没有帮助: 回答错误或不相关

• 不相关: 用户需要值班人员的帮助,Genie 无法协助(如代码审查)

图 10: Genie 的用户反馈流程。

当用户留下反馈时,Slack 插件会拾取它并使用特定的 Kafka 主题将指标流式传输到包含反馈和所有相关元数据的 Hive 表中。我们稍后在仪表板中可视化这些指标。

性能评估

我们为 Genie 用户提供运行自定义评估的选项。他们可以评估幻觉、答案相关性或他们认为对其用例重要的任何其他指标。这种评估可用于更好地调整所有相关的 RAG 组件—检索和生成。

图 11: 性能评估过程。

图 11 显示了评估过程,这是一个使用已构建的 Michelangelo 组件的单独 ETL 管道。从 Hive 检索 Genie 的上下文和响应,并与任何其他相关数据(如 Slack 元数据和用户反馈)连接。它被处理并传递给评估器。评估器获取指定的提示并运行 LLM 作为评判。指定的指标被提取并包含在评估报告中,用户可以在 UI 中查看该报告。

文档评估

准确的信息检索取决于源文档的清晰度和准确性。如果文档质量本身就很差,无论 LLM 表现如何好,都无法获得良好的性能。因此,评估文档并提出可行的建议以改进文档质量的能力对于高效和有效的 RAG 系统至关重要。

图 12: 文档评估应用程序的工作流程。

图 12 显示了文档评估应用程序的工作流程。在抓取数据后,知识库中的文档被转换为 Spark 数据框。数据框中的每一行代表知识库中的一个文档。然后通过调用 LLM 作为评判来处理评估。在这里,我们用自定义评估提示来提供 LLM。LLM 返回评估分数,以及分数的解释和关于如何改进每个文档质量的可行建议。所有这些指标都作为评估报告发布,用户可以在 Michelangelo UI 中访问。

挑战的解决方案

为了减少幻觉,我们改变了向 LLM 发送从向量数据库获得的提示的方式。对于从向量数据库获得的所有结果,我们明确添加了一个称为子上下文的部分以及该子上下文的源 URL。我们要求 LLM 只从提供的各种子上下文中给出答案,并返回源 URL 来引用答案。这旨在为它返回的每个答案提供源 URL。

为了确保我们不会将用于创建嵌入的数据源泄露给 Open AI 或在 Slack 上泄露给可能无法访问敏感数据源的人,我们预先策划了大多数 Uber 工程师都可以广泛使用的数据源,并且只允许使用这些数据源来生成嵌入。

为了最大限度地发挥 Genie 回答问题的潜力,我们开发了一种新的交互模式。这种模式允许用户更方便地提出后续问题,并鼓励他们更仔细地阅读 Genie 的答案。如果 Genie 无法回答他们的问题,用户可以轻松地将问题升级到值班支持。

图 13: Genie 如何回应用户问题的流程。

在新的交互模式中,当用户提出问题时,Genie 将提供下一步操作按钮回答。使用这些按钮,用户可以轻松地提出后续问题、将问题标记为已解决或联系人工支持。

结果

自 2023 年 9 月推出以来,Genie 已扩展到 154 个 Slack 渠道,并回答了超过 70,000 个问题。Genie 拥有 48.9% 的帮助率,展示了其不断提高的效率。我们估计自推出以来已为我们节省了 13,000 小时的工程时间。

未来

Genie 是一个尖端的 Slack 机器人,旨在简化值班管理、优化事件响应和改善团队协作。Genie 以简单性和有效性为重点开发,作为一个全面的助手,使工程团队能够无缝处理值班职责。

这个值班助手副驾驶有望改变用户和任何平台的值班工程师在各自平台的 Slack 渠道中互动和参与的整个体验。它还可以改变每个产品内的体验,如 Michelangelo 或 IDE,用户可以在产品内或产品特定的 Slack 渠道中找到产品特定的帮助,而无需等待值班协助。

结论

Genie 这个值班助手副驾驶彻底改变了工程团队管理值班职责的方式。通过促进自动解决和提供有见地的分析,Genie 使团队能够高效和有效地处理值班职责。

致谢

如果没有许多团队成员的贡献,这个值班副驾驶的推出是不可能的。非常感谢 Uber Michelangelo 团队的成员。我们还要感谢其他 Uber 团队的合作伙伴,使这个想法成为现实。

Slack® 是 Slack Technologies, Inc. 的注册商标和服务标志。Apache®、Apache Spark™ 和 Spark™ 是 Apache 软件基金会在美国和/或其他国家的注册商标或商标。使用这些标志并不意味着得到 Apache 软件基金会的认可。

页眉图片说明：该图片由人工智能生成工具创建。