【Microsoft 365 Copilot】Microsoft 365 Copilot概述及其工作原理

随着Microsoft 365 Copilot越来越接近发布，我决定更深入地了解此功能的工作原理以及如何为每个租户设置它。

这里有两个主要组件将在Copilot中发挥重要作用，一个是Azure OpenAI实例，另一个是基于Microsoft Search的语义索引。让我们来看一个例子：

今天，当某人在Microsoft 365中搜索某些内容时，如SharePoint、OneDrive或其他Microsoft 365应用程序，他们将向Microsoft搜索发送API呼叫。这个搜索引擎有一个基于您作为用户在文档作为文件方面可以访问的内容的构建索引。

使用Copilot，当有人搜索“我可以休多少假”之类的内容时，Copilot功能将向Microsoft搜索发送API调用，但API调用将是一个提示，然后根据最初的问题搜索内容。然后，搜索引擎将向Copilot回复可能相关的内容，并定义此信息存储在哪个来源。最后，Copilot将向最终用户显示回复。在这里，搜索也是在用户的上下文中完成的。

要让Copilot立足于您的组织数据，重要的部分是搜索引擎。由于OpenAI的上下文窗口有限，无法实际学习新事物，因此您需要向其提供信息，但在大多数组织中，您有大量数据，我们无法将所有数据直接放入OpenAI中，因此当用户要求时，我们需要向其提供信息。

Microsoft Search还可以扩展到Microsoft 365之外的其他数据源，使用名为Graph Connectors的东西，该东西直接使用API与3的集成。诸如Service Now之类的参与方服务，或者我们可以使用本地连接器，该连接器可以连接到Windows文件服务器，在本地对文件和内容进行索引，并使其可供Microsoft CoPilot访问。

注意：我们的数据（包括提示、响应和通过Microsoft Graph访问的数据）不用于训练Copilot使用的基础LLM。

每个标准租户都有自己的Copilot编排器实例，该实例依赖于Microsoft Search来收集信息。实现了单独的编排器实例，以在组织的合规边界内维护数据，防止其在外部共享。

虽然提示是模型的主要输入，但它也可以包括用户选择输入到语言模型的输入文件或内容（通过租户的Copilot编排器实例）。

此外，通过Microsoft权限信息保护（MPIP或AIP）标签保护的数据将根据相应的策略继续受到保护。尽管Copilot生成的内容目前不采用来源的MPIP标签，但Copilot承认原始来源，确保标签保持完整。

当Microsoft 365 Copilot调用LLM（语言模型）时，它会将这些调用定向到同一地区内最近的数据中心。然而，在高利用率期间，Copilot也可能利用其他有容量的地区的数据中心。在LLM调用期间，客户数据在内存中处理，响应和其他客户内容工件一起返回到主区域。重要的是，客户内容数据不会写入用户所在地区之外。

为确保符合欧盟数据边界，欧盟用户还采取了额外的保障措施。欧盟流量仍在欧盟数据边界内，而全球流量可以路由到欧盟和其他地理位置进行LLM处理。

Copilot成功的重要部分是确保它能够访问相关信息，这意味着搜索和索引需要有可用的相关数据。