微软的 Build 开发者大会揭开了它希望开发者如何向其 Copilot 应用程序添加自定义内容和应用程序集成的帷幕。 这种方法应该使他们更加相关，并且不太可能偏离轨道，将他们的输出集中在特定任务上。
重要的是要明白，一旦经过训练，像 GPT-4 这样的大型语言模型就需要额外的数据来保持专注。 这就是为什么 Microsoft 的各种 Copilot 都构建在自己的数据源之上：GitHub、Power Platform、Microsoft Graph，以及最明显的 Bing。 这是一种非常成功的方法，可以降低幻觉和提示超限的风险，但它仍然对其人工智能平台施加了微软定义的限制。
目前，Bing 的 Copilot 只能回答有关 Bing 搜索数据库的问题。 虽然数据量很大，但它无法回答有关用户防火墙内的数据或来自他们想要使用的应用程序的数据的问题。 该服务无法获取这些响应并使用其他结果将其输入其他应用程序以格式化其输出或代表用户运行交互。 用户可以要求必应聊天列出新奥尔良最好的餐厅，或者为他们提供三天旅行的行程，但它不会为他们预订餐桌。
添加AI辅助插件
这就是插件可以提供帮助的地方，提供额外的数据源和新的交互。 用户已经可以使用为 ChatGPT 构建的插件，微软正在为其新的 Bing 插件构建相同的插件架构。 最初，它提供 OpenTable 和 Wolfram Alpha 支持，以及来自 Expedia、Instacart、Zillow、TripAdvisor 等服务的插件。 因此，举例来说，如果有人使用 Instacart 插件，他们可以快速将 Bing 的菜单转换为购物清单，然后转换为不在其橱柜中的食材的送货订单。 有趣的是，这些插件将包括一个用于 ChatGPT 本身的插件。
微软走得更远：这种通用插件模型也被用于 Microsoft 365 的 Copilot 和 Microsoft Edge 浏览器中的 AI 工具。 拥有 LLM 插件的通用模型非常有意义。 它允许代码编写一次并在所有用户的不同应用程序中重复使用。
使用标准插件架构允许用户向其他用户和组织提供他们的代码，因此，如果他们构建了一个可以将 Salesforce 应用程序与 Bing Chat 集成的工具，他们可以将其作为产品出售或开源并共享 它。
快速构建插件
那么用户如何构建ChatGPT插件呢？ 插件是现有应用程序 API 和 ChatGPT 之间的接口，具有它们所使用的 API 的清单和 OpenAPI 规范。 Bing Chat 服务充当编排工具，根据需要调用 API 并使用其自然语言工具格式化响应。
借助这些工具，用户可以问：“你能告诉我第一季度完成的所有交易吗？” 让 Bing Chat 连接到他们的客户关系管理系统，并从销售数据中提取所需信息，将其显示为聊天响应。 然后，他们可以跟进，询问是否需要订购更多原材料，使用另一个链接到企业资源规划平台的插件，检查库存水平，然后询问他们是否批准订购任何所需的材料和组件。
这里的结果是支持用户使用他们通常使用的应用程序，编排交互，并将复杂的任务转变为微工作，使他们能够深入处理其他任务。
在现有 API 定义和标准定义格式上构建扩展应该可以简化开发。 如果用户尚未构建 REST API 的 OpenAPI 定义，他们可以使用 Postman 等工具自动生成一个。 OpenAPI 定义的描述字段可以帮助 Bing 或 ChatGPT 围绕其查询生成文本，并帮助他们选择要使用的 API。 生成的插件定义将添加到 LLM 的提示中（在聊天 UI 中隐藏），但仍会根据其上下文进行计数并耗尽令牌。 重要的是要记住，插件需要由用户直接调用； 它们并不适用于所有查询。
要做的第一件事是用 YAML 或 JSON 为其插件构建清单。 用户将自己将其托管在其域顶部的特定文件夹中，并使用预定义的名称，因此 GPT 主机很容易找到它。 有用的是，OpenAI 插件规范包括处理身份验证的方法，这样他们就可以确保只有经过身份验证的用户才能访问内部 API。 使用 OpenAPI 描述允许用户限制 GPT 访问其 API 的各个方面，因为他们可以编辑 API 定义以隐藏他们不希望其进行的调用。 例如，某人只能允许读取具有更新和删除功能的 API。
让插件变得更好
插件不会将数据添加到 Bing 或 ChatGPT； 它们为其输出添加方向和焦点，仅在用户请求时运行，并且仅返回作为原始查询响应的一部分的数据。 用户需要避免返回自然语言响应——GPT 模型将围绕来自 API 的数据生成自己的响应。
插件清单的一项有用功能是“模型描述”属性，该属性允许用户细化从 API 描述生成的提示，从而提供添加更多指令的位置。 当用户测试他们的插件时，他们可以通过这种方式添加额外的控制来控制插件的使用方式。 ChatGPT 提供了一种通过显示请求和响应（通常采用 JSON 格式）来调试插件的方法。 这有助于他们了解人工智能使用了应用程序中的哪些数据，即使不能确切地了解数据的使用方式或原始请求是如何生成的。
更复杂的插件可以与矢量数据库配合使用来提取和使用文档。 这种方法可能最适合需要使用用户文档存储的应用程序，可以使用嵌入进行预处理并使用矢量搜索进行索引，以加快访问复杂的业务信息，这些信息可以根据其他应用程序的响应生成文档， 使用最相关的内容来构建任何生成的文本。
将现有的 Microsoft Teams 应用程序转换为插件
另一个有趣的选项是将现有的 Teams 消息扩展与 Microsoft 365 Copilot 结合使用。 这种方法可以简化将 AI 快速添加到现有 Teams 机器人的过程，通过机器人框架将用户的 Web 服务链接到 Copilot。 这里最重要的是确保应用程序描述和技能参数用于构建 Copilot LLM 提示以及扩展中的任何内容请求。 输出以嵌入聊天会话中的自适应卡的形式提供。 甚至可以选择修改扩展，使其成为一个完全对话的系统，通过大多数 Microsoft Copilot 基础的 GPT-4 模型进行工作。
微软扩展 Bing 及其其他 Copilots 的方法目前来看是一个不错的方法。 现在仍处于生成式 AI 的早期阶段，因此拥有一种标准插件格式非常有意义，它允许 API 支持多个 AI 平台，并减少多次构建相同插件的需要。 适用于 ChatGPT 的代码将适用于 Bing Chat 和 Microsoft 365 以及 Microsoft 未来添加 Copilot 功能的任何其他地方。
