我们如何构建安全且私密的 Slack AI

编辑注：本文最初发布在 Slack 的工程博客中。

在 Slack，我们始终秉承严谨的技术精神，换句话说，每当我们决定采用全新类别的基础设施时，我们总是以严格审慎的态度进行。自 2016 年推出机器学习驱动的功能以来，我们一直遵循这样的原则，并在此过程中培养了一支经验丰富的团队，建立了完善的流程。

尽管如此，在过去的一年里，商用大型语言模型 (LLM) 的能力提升着实让我们震惊，更重要的是，它们可以解决我们用户面临的最大痛点。要阅读的内容太多？很难找到想要的信息？这些都不再是问题：与未使用 AI 的用户相比，90% 使用了 AI 的用户都表示他们的工作效率得到了极大提升。

但与任何新技术一样，我们能否推出 AI 产品，取决于我们能否找到实施方案并使之符合 Slack 在客户数据管理方面的严格标准。因此，我们不仅着眼于打造出色的 AI 功能，更要打造可信赖的 AI。

生成式模型行业还很年轻，而且主要集中于科研领域，而不是以企业客户为中心。在构建全新的 Slack AI 架构时，我们很少能利用现成的企业级安全和隐私模式。

相反，为了确定如何构建 Slack AI，我们从基础原则出发。我们首先明确了我们的要求：维护我们现有的安全和合规产品，坚守我们的隐私保护原则，比如“客户数据是神圣不可侵犯的”。然后，我们的团队从生成式 AI 领域的具体实践出发，创建了一套新的 Slack AI 原则作为指导。

• 客户数据会始终保留在 Slack 中。
• 我们不会使用客户数据训练大型语言模型 (LLM)。
• Slack AI 仅针对用户已经可以看到的数据执行操作。
• Slack AI 符合 Slack 的所有企业级安全和合规要求。

虽然这些原则有时会带来更大挑战，但它们为设计我们的架构提供了更清晰的指导。接下来，我将详细解释每一条原则是如何影响 Slack AI 当前架构的。

客户数据会始终保留在 Slack 中

我们面临的第一个，也可能是最重要的决定，是如何在使用顶级基础模型的同时，确保客户数据不离开 Slack 控制的 VPC。在生成式模型行业，大多数基础模型的客户会直接调用托管服务，而替代选项很少。

我们知道这种方法对我们来说行不通。Slack 和我们的客户对数据所有权有很高的期望。尤其是 Slack 已获得 FedRAMP Moderate 授权，这要求我们遵守特定的合规要求，包括不得将客户数据发送到我们的信任边界之外。我们要确保我们的数据不会离开 AWS 虚拟私有云 (VPC)，从而防止第三方保留或训练它们。

因此，我们开始寻找创新的解决方案，以便在自己的基础设施上托管基础模型。但是，大多数基础模型都是闭源的：它们是提供商的制胜武器，提供商不愿意把模型交给客户，让客户自行部署到自己的硬件上。

幸运的是，AWS 提供了一种产品，可以作为基础模型提供商和客户之间的可信中介：AWS SageMaker。通过使用 SageMaker，我们得以在托管 VPC 中部署闭源的大型语言模型 (LLM)，这使我们能够控制客户数据的生命周期，并确保模型提供商无法访问 Slack 客户的数据。有关 Slack 如何使用 SageMaker 的更多信息，请查看 AWS 博客上的这篇文章。

就这样，我们拥有了使用顶级基础模型的能力，而模型托管在我们自己的 AWS VPC 中，保证了客户数据的安全。

我们不会使用客户数据训练大型语言模型 (LLM)

下一个决定也很关键：我们选择使用现成的模型，而不是训练或微调模型。自从我们开始在 Slack 中使用更传统的机器学习 (ML) 模型（例如给搜索结果排名的模型）以来，我们一直坚持隐私原则，其中包括数据不会在不同工作区之间泄露，并且我们允许客户选择是否参与。我们认为，鉴于目前这个行业和技术尚处于早期阶段，如果我们使用 Slack 客户的数据来训练生成式 AI 模型，我们无法做出足够强有力的保证。

因此，我们决定采用检索增强生成 (RAG) 的方法，以无状态的方式使用现成的模型。所谓 RAG 是指在每个请求中包含执行任务所需的所有上下文，这样模型就不会保留任何数据。例如，在为频道生成摘要时，我们向 LLM 发送的提示中会包含要总结的消息和操作说明。RAG 的无状态性是一个巨大的隐私优势，也是一个产品优势。Slack AI 的所有结果都基于贵公司的知识库，而不是公共互联网，这使得结果更加相关和准确。你可以享受到整合专有和个性化数据集的好处，同时不必担心因模型保留这些数据而导致的风险。

使用 RAG 会限制可用模型的范围：可用模型需要具备足够大的“上下文窗口”，以便你可以传入要在任务中使用的所有数据。此外，你发送给 LLM 的上下文越多，请求的处理速度就越慢，因为模型需要处理更多数据。可以想见，“总结频道中的所有消息”这项任务可能涉及大量数据。

这给我们带来了挑战：找到一个拥有大型上下文窗口且延迟较低的顶级模型。我们评估了许多模型，发现有一个很适合我们的首批用例，也就是摘要和搜索。不过，还有改进的空间，我们开始了一段漫长的过程，通过调整提示以及将传统 ML 模型与生成式模型相结合，来改善结果。

随着模型的每一次迭代，RAG 正变得更简单、更快捷：上下文窗口在增大，模型在大范围上下文窗口内综合数据的能力也在增强。我们相信，这种方法既能达到我们追求的质量，同时也有助于确保我们客户的数据得到保护。

Slack AI 仅针对用户已经可以看到的数据执行操作

我们的核心原则之一是：Slack AI 只能看到提出请求的用户能看到的数据。例如，Slack AI 的搜索功能永远不会向用户显示标准搜索功能无法检索到的结果；摘要功能永远不会总结用户在查看频道时无法看到的内容。

为确保这一点，我们在获取用于摘要或搜索的数据时，会使用提出请求的用户的访问控制列表 (ACL)，并利用我们现有的库来获取要在频道或搜索结果页面上显示的数据。

从技术角度来说，这并不难实现，但需要我们做出明确的抉择。而保证这一点的最佳方法是在 Slack 的核心功能集之上构建和重用，并在最后添加一些“AI 魔法”。

值得注意的是，只有调用 Slack AI 的用户才能看到 AI 生成的输出。这增强了信任感，让用户觉得 Slack 是值得信赖的 AI 合作伙伴：只有你能看到的数据才能作为输入，也只有你能看到输出。

Slack AI 符合 Slack 的所有企业级安全和合规要求

没有 Slack 就没有 Slack AI，因此我们把所有的企业级合规性和安全功能都整合进来了。我们遵循最少数据原则：只存储完成任务所需的数据，并且仅保留必要的时间。

有时最少的数据就是：无。在可能的情况下，Slack AI 的输出是短暂的：对话摘要和搜索答案都会生成即时响应，这些响应不会存储在磁盘上。

当不可能做到这一点时，我们尽可能重用 Slack 现有的合规性基础设施，并在需要时构建新的支持。我们的许多合规功能已经内置在我们现有的基础设施中，例如加密密钥管理和国际数据驻留权。对于其他情况，我们构建了特殊支持，以确保派生的内容（如摘要）能够知道生成它们时所用的消息，例如，如果一条消息因数据丢失保护 (DLP) 机制而被埋藏，那么从该消息派生出的任何摘要都将失效。这使得 DLP 和其他管理控制措施与 Slack AI 的强大相结合：这些控制措施已经应用于 Slack 的消息内容，现在也应用于 Slack AI 的输出。

呼——这真是一段漫长的旅程！我甚至还没来得及介绍我们如何构建提示、评估模型或处理需求高峰，我们下次再谈。但我很高兴我们从安全性和隐私这个话题开始：我们希望客户知道，我们是如何严肃认真地保护他们的数据，以及我们是如何在每一步保护数据的。