开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共820人左右 1 + 2 + 3）新人会进入3群。

Microsoft 已经推出了一系列新工具，以简化对基于 GPT 的 AI 模型输出的定制和关注。Cosmos DB 在其中扮演着重要角色。

微软首席执行官萨蒂亚·纳德拉（Satya Nadella）将像 GPT-4 这样的大型语言 AI 模型的出现描述为“马赛克时刻”，可与第一个图形网页浏览器的出现相提并论。与最初的马赛克时刻不同，当时微软在浏览器大战中起步较晚，被迫购买其首个网络开发工具，如今该公司在 AI 领域占据领先地位，迅速推出 AI 技术，覆盖企业和消费级产品。

要了解微软的关键之一就是其将自身视为平台公司的观点。这种内部文化驱使它为开发人员提供工具和技术，并为开发人员构建基础设施。对于 AI 而言，这从 Azure OpenAI API 开始，延伸至 Prompt Engine 和 Semantic Kernel 等工具，这些工具简化了基于 OpenAI 的 Transformer 神经网络的定制体验的开发。

因此，今年的微软 Build 开发者大会的很大一部分关注的是如何使用这些工具构建自己的 AI 驱动应用程序，从 Microsoft 在其 Edge 浏览器和必应搜索引擎、GitHub 以及开发者工具中推出的“副驾驶员”模式的辅助 AI 工具入手，并在 Microsoft 365 和 Power Platform 中为企业提供服务。我们还了解到微软计划在其平台上填补空白并使其工具成为 AI 开发的一站式商店。

在像 OpenAI 的 GPT-4 这样的大型语言模型（LLM）的核心是一个庞大的神经网络，它使用语言的向量表示进行工作，寻找与描述提示的相似向量，并创建和优化一个多维语义空间中的最佳路径，以产生可理解的输出。这与搜索引擎所采用的方法相似，不过搜索是关于找到能回答您查询问题的相似向量，而 LLM 则扩展了组成初始提示的语义标记集合（以及用于设置正在使用的 LLM 上下文的提示）。这就是为什么微软的第一款 LLM 产品 GitHub Copilot 和 Bing Copilot 基于搜索服务构建的原因之一，因为它们已经使用了向量数据库和索引，提供了保持 LLM 回应正常运行的上下文。

不幸的是，对于我们其他人来说，向量数据库相对罕见，它们基于与熟悉的 SQL 和 NoSQL 数据库非常不同的原理构建。或许将它们视为图数据库的多维扩展是最好的，数据以具有方向和大小的向量形式转换和嵌入。向量使得查找相似数据变得快速且准确，但它们需要一种与其他数据格式截然不同的工作方式。

如果我们要构建自己的企业副驾驶员，我们需要拥有自己的向量数据库，因为它们使我们能够使用特定领域的数据来扩展和优化 LLM。也许这些数据是一个常用合同库，或者是几十年的产品文档，甚至是所有的客户支持问题和答案。如果我们可以以恰当的方式存储这些数据，就可以利用它们构建面向业务的 AI 驱动接口。

但是，我们是否有时间和资源将这些数据存储在一种不熟悉的格式、一个未经验证的产品上呢？我们需要的是一种快速向 AI 提供这些数据的方法，基于我们已经在使用的工具。

微软在 BUILD 2023 上宣布了针对其 Cosmos DB 云原生文档数据库的一系列更新。虽然大部分更新都集中在处理大量数据和管理查询方面，但对于 AI 应用程序开发来说，可能最有用的是添加向量搜索功能。这同样适用于现有的 Cosmos DB 实例，使客户无需将数据迁移到新的向量数据库。

Cosmos DB 的新向量搜索功能基于最近推出的 Cosmos DB for MongoDB vCore 服务，该服务允许您将实例限定到特定的虚拟基础设施，并在可用区之间提供高可用性，同时使用更具可预测性的每节点定价模型，而仍然使用熟悉的 MongoDB API。现有的 MongoDB 数据库可以迁移到 Cosmos DB，这样您可以在本地使用 MongoDB 来管理数据，并在 Azure 上使用 Cosmos DB 运行应用程序。Cosmos DB 的新变更源工具应该使得在不同地域之间构建副本变得更容易，在其他集群中复制一个数据库的变更。

向量搜索扩展了这些工具，为您的数据库添加了一种新的查询模式，可用于处理 AI 应用程序。虽然向量搜索不是一个真正的向量数据库，但它提供了许多相同的功能，包括存储嵌入并将其作为数据搜索键的方法，应用与更复杂替代方案相同的相似性规则。微软推出的工具将支持基本的向量索引（使用 IVF Flat）、三种类型的距离度量以及存储和搜索高达 2,000 维大小的向量的能力。距离度量是向量搜索中的关键特征，因为它们有助于定义向量的相似程度。

微软初始解决方案最有趣的地方或许在于它是对一种流行文档数据库的扩展。使用文档数据库为 LLM 创建语义存储非常有意义：这是我们已经知道如何使用来发布和管理内容的熟悉工具。已经有一些库可以帮助我们捕获和转换不同的文档格式，并将它们封装在 JSON 中，因此我们可以在不改变工作流程或不必学习全新类别数据库技能的情况下，从现有存储工具转换为适用于 LLM 的向量嵌入。

这种方法应该简化组装定制数据集以构建自己的语义搜索所需任务。Azure OpenAI 提供用于从文档生成嵌入的 API，这些嵌入随后可以与源文档一起存储在 Cosmos DB 中。应用程序将基于用户输入生成新的嵌入，这些嵌入可以与 Cosmos DB 向量搜索一起使用，以找到相似的文档。

除了基于云的 AI 工具，微软还为 Visual Studio Code 引入了一个交互式 Semantic Kernel 扩展，使开发人员能够使用 C# 或 Python 围绕 Azure OpenAI 和 OpenAI API 构建和测试 AI 技能和插件。像 Cosmos DB 的向量搜索这样的工具应简化为 Semantic Kernel 构建语义记忆的过程，使您能够围绕 API 调用构建更复杂的应用程序。关于如何使用嵌入的示例作为扩展可在示例 Copilot Chat 中找到，这应该能让您在预构建文档分析功能的位置方便地替换为向量搜索。

微软的 AI 平台正是一个供您建设的平台。Azure OpenAI 构成了骨干，托管着 LLM。将向量搜索引入 Cosmos DB 中的数据将使我们更容易将结果植根于我们自己组织的知识和内容中。这应该会影响到其他 AI 平台的声明，如 Azure Cognitive Search 这样的工具，它可以自动将任何数据源连接到 Azure OpenAI 模型，为您的应用程序和工具提供一个简单的端点，以便在不离开 Azure AI Studio 的情况下测试服务。

微软在这里提供的是一系列 AI 开发者工具，从 Azure AI Studio 及其低代码 Copilot Maker 开始，通过定制的 Cognitive Search 端点，直至在您的文档上进行自定义向量搜索。这应该足够帮助您构建满足需求的基于 LLM 的应用程序。