企业AI应用的数据策略

【引】人工智能的狂乱无处不在，有人已经开始担心人工智能支配我们生活的方方面面。每天都有新的人工智能应用程序出现，将可能性的边界推得更远。

尽管人工智能正在获得所有的关注，一些引人注目的问题再次提醒我们 "garbage in, garbage out"。如果我们忽略底层的数据管理原则，那么输出就不可信。一旦我们能够保证基础训练数据的准确性，人工智能的采用率将会大大提高。

然而，未来必须与现实相抗衡！如今，大多数业务数据都位于企业数据源内部，而不在公共领域的互联网上。如果我们在这个企业级的数据系统上利用大语言模型，就会出现新的不确定性。

但是，如何利用LLM对企业私有数据的实现强大功能呢？

这里试图探讨技术人员应该如何发展他们的数据策略，并选择一个数据基础设施来利用LLM和企业数据。

1. 重启数据策略

组织必须做出一个基本决定ーー是否创建自己的 LLM、用私有数据调优LLM 或利用通用 LLM 的 API。

1.1 训练自定义的 LLM

为特定的任务启用特定的模型构建，例如分类 Slack 消息以识别 PII。这种方法需要在组织中具备深厚的 AI 技能，并且更适合具有大型且复杂IT 团队的组织，另外训练像 gpt-4 这样的 LLM 还需要大量的基础设施。

目前，生成式人工智能领域对于支持这个选项来说还为时过早。然而，随着许多服务提供商将来开发特定于领域的 llm，这个领域可能是最令人兴奋的领域。

1.2 调优通用 LLM的权重

此选项使用模型权重对特定训练集上的现有模型进行微调。它还需要对人工智能有深入的了解，并且需要对基础设施资源进行投资，这取决于数据的大小。此外，它还创建了一个新的职责岗位，称为 LLMOps。

和前一个选项一样，这个方式在在成熟度曲线上也较早。LoRA可以帮助微调，期望看到在这个领域的快速发展。

1.3 通用LLM的提示工程

此选项使用模型输入，将上下文插入到通过 api 发送给 LLM 的输入消息中。对于具有一般 IT 技能和资源的组织来说，这个选项通常是利用生成性 AI 空间的初步尝试。

这种方式称为提示工程，已经出现为人工智能模型开发准确和相关的文本提示词工具。利用外部内容来增强 LLM 的过程称为检索增强生成 (RAG)。

下表显示了权衡情况：

提示工程	数据及时性好，能低成本上线	精度降级，向量化延迟较高，大模型的token有一定成本

因为大多数组织不具备训练或调优 LLM 所需的技能。这种方法涉及向量化数据和创建嵌入，需要编程能力。虽然提示工程也消耗资源，但是比前两个选项消耗的资源少得多。它最大的好处是允许将上下文数据实时提供给 LLM。

2. LLM 的数据持久化策略

在构建大语言模型应用时，数据策略的第二步是确定如何高效支撑AI工作负载的技术架构。这一阶段的核心挑战在于权衡技术选型：是否需要引入全新的技术体系，还是能够基于现有基础设施进行适配性改造？这不仅关系到系统开发成本，更直接影响到模型性能的可持续性。

在实际部署中，数据持久化与管理能力构成了LLM应用的基石。这包括对模型输入数据的全生命周期管理、向量嵌入的高效存储与检索机制，以及对查询模式的深度优化。特别是在提示工程（Prompt Engineering）领域，开发者面临两种关键策略选择：

第一种策略是将API服务作为LLM的"短期记忆"模块，通过临时缓存和即时调用的方式处理模型输入数据。这种方案的优势在于实现成本低、响应速度快，特别适合对实时性要求较高但数据量相对有限的场景。

第二种策略则是构建"长期记忆"体系，通过持久化存储技术对模型输入数据进行结构化保存。这种方案能够建立完整的数据资产库，支持复杂的数据检索、历史回溯和知识演化，尤其适用于需要深度语义理解和跨会话上下文关联的场景。在具体实施时，开发者需要根据业务需求在存储效率、查询性能和数据一致性之间找到最佳平衡点。

这两种策略并非完全对立，而是可以结合使用。例如，在实时交互场景中采用API缓存处理即时请求，同时将关键数据同步至持久化存储系统，从而构建兼具时效性与完整性的数据管理体系。这种混合架构能够最大化发挥LLM的能力，同时确保系统的可扩展性和稳定性。

下图显示了两个备选方案的例子：

| 模型输入 | 工具 |
| 短历史 | * FAISS * Annoy * ScaNN/Match Engine |

长历史	* 原生向量数据库 * 关系型数据库 NoSQL数据库文件系统

短期记忆是短暂的，而长期记忆是持久化的。

2.1 短期记忆：集成内置嵌入和向量化的库

提到的诸如FAISS等库均为开源项目，并已被众多产品广泛应用。这些工具为开发者提供了强大的功能，但同时也要求开发团队自行负责构建数据处理流水线以实现最终的交付目标。这意味着从数据预处理、向量化到相似性搜索的每一个环节都需要精心设计与实现。

相比之下，Google的Matching Engine（匹配引擎）提供了一个完全托管的解决方案，专为优化模型输入而设计，并且支持数据的持久化存储。使用Matching Engine，开发者可以无需关注底层基础设施的搭建和维护，直接通过API调用即可快速部署高效率的向量搜索服务。这种全托管的方式不仅简化了开发流程，还确保了系统的可扩展性和稳定性，特别适合希望减少运维负担并加速产品上市的企业或团队。

因此，在选择技术方案时，如果需要灵活性和对技术栈的深度控制，可以选择如FAISS这样的开源库；若追求高效部署、易于管理及自动扩展能力，则Google Matching Engine将是更为理想的选择。两者各有优势，具体选用哪一种取决于项目的具体需求、团队的技术能力和资源情况。

2.2 长期记忆

随着人工智能和机器学习应用的不断深入，向量数据的高效处理变得日益重要。为此，原生向量数据库应运而生------这些是专门为高效存储、索引和检索高维向量而设计的专用系统，例如 FAISS、Pinecone 和 Milvus 等。

与此同时，传统的关系型与非关系型数据库管理系统（DBMS） 也在迅速跟进，逐步集成对向量数据的支持。像 Elasticsearch 这类以搜索为核心的数据平台，原本就具备强大的倒排索引能力，用于关键词搜索和日志分析，如今也开始引入高效的向量相似性搜索功能，标志着其在语义搜索领域的进一步拓展。

此外，一些现代数据库如 SingleStoreDB 及其他主流系统，也已经具备了内建的向量嵌入支持，能够实现本地化的语义搜索功能。尽管在过去，这类功能并未被广泛宣传或重点使用，但随着大模型和AI驱动的应用兴起，它们正重新受到关注并被深度整合到新一代智能系统中。

当然，向量数据并非必须依赖数据库来存储。事实上，文件系统也是一种可行的选项 ，特别是那些支持列式存储格式的文件格式，如 Apache Parquet 或 Apache Arrow。这些格式非常适合批量处理和大规模数据分析，同时也能够有效地存储向量数据。

然而，一个不可忽视的问题是：如果缺乏合适的索引机制，在文件中进行向量查询可能会非常缓慢。因为顺序扫描无法高效地处理高维空间中的相似性匹配，这使得构建高效的索引结构成为向量数据管理中不可或缺的一环。

下面的图显示了长期记忆的例子，虽然这个列表只是代表性的，因为大多数数据库供应商正在增加对向量的支持：

文件系统	Apache Parquet CSV JSON

现代数据堆栈已经爆满要求简化的呼声已经高涨。因此，重新启动数据策略必须支持降低复杂性。这意味着探讨目前部署的数据和分析技术是否以及如何能够用于对私有数据进行向量搜索。

3.在私有数据上使用LLM 的价值链

通过部署聊天机器人来实现企业数据的自然语言搜索，可以大幅扩展数据访问的用户群体和应用场景。除了基础的搜索功能外，大型语言模型（LLMs）利用深度神经网络算法还能执行复杂的任务，如文档摘要、内容排名及个性化推荐等。

举例来说，当您在某零售商网站上查找特定商品却无果时，借助LLM的附加API调用，即便初次查询未返回结果，系统也能基于相似性或语义搜索技术提供一系列相关产品推荐。这种向量搜索方法能够识别出与您的查询意图最接近的商品集合，从而提升用户体验。

目前，诸如ChatGPT这样的应用依赖于GPT-3乃至更新的GPT-4模型，它们基于2021年9月前的公开数据进行训练。这意味着对于像2022年底结束的世界杯足球赛这类较新的事件，LLM可能无法提供准确信息。此外，训练这些先进的LLM需要庞大的计算资源，例如ChatGPT就需要大约10,000个GPU的工作量，这使得训练过程既昂贵又耗时。

为了克服这一限制并利用最新数据，可以在对GPT-3或GPT-4的API请求中加入额外的信息，比如关于世界杯足球赛的维基百科页面作为"提示"或"模型输入"。然而，需注意的是，GPT-3的最大输入长度为4000个token（约等于5页文本），而GPT-4则支持高达32000个token（大约40页）。这里的token可以是单词、短语、代码片段或是任何其他形式的模型输入。

转向商业需求，特别是那些涉及探索企业数据以发现新洞察的情况，我们可以通过市场营销实例来说明如何提高客户转化率。理想的应用程序应能实时分析所有流入的数据，运用模型生成个性化的优惠，并在用户使用应用程序的同时即时实施这些优惠。这通常涉及到从交易数据库提取数据，通过批处理操作完成数据抽取、加载与转换，接着在OLAP引擎中运行分析，最后创建细分市场并制定报价策略。

而在新一代AI驱动的模型中，您可以直接实时摄取数据，经由一个或多个GPT服务应用模型，并立即根据用户在线行为做出响应。这些GPT模型特别适用于实时数据处理场景，如推荐系统、分类和个人化定制服务。近年来的技术进步，包括LangChain和AutoGPT的发展，正在革新现代应用程序的开发与交付方式。

要达成上述目标，以下是三个关键步骤。

3.1 为向量搜索准备数据

在深入探讨向量搜索的机制之前，我们先来理解"向量"究竟是什么。传统数据库中的关键词搜索依赖于精确匹配，但在自然语言查询场景中，这种匹配方式往往无法捕捉语义层面的相似性。当用户输入一个自然语言问题时，系统需要将该句子转换为一种结构化表示形式，以便与其他文本进行比较------这一过程的核心就是"嵌入（Embedding）"。

什么是嵌入？

嵌入是一种将文本、图像或其他非结构化数据映射为数值向量的技术。这些向量以高维空间中的坐标点形式存在，就像数组一样，每个维度代表某种语义特征。例如，"king" 和 "man" 在语义上比 "woman" 更接近，因此它们在向量空间中的距离也会更近。

如果没有这些嵌入向量，大型语言模型（LLM）就无法准确提取提示（prompt）的上下文信息，也就无法生成语义连贯的响应。

语义距离与相似性计算

当对新文本执行搜索时，模型会计算词汇之间的"语义距离"。这个距离是通过一些数学函数来衡量的，常见的包括：

余弦相似度（Cosine Similarity）
点积（Dot Product）
欧几里得距离（Euclidean Distance）

这些方法帮助模型识别出与输入最相关的候选结果，即所谓的"最近邻（Nearest Neighbor）"。

然而，在面对数百万甚至数十亿个向量时，逐个计算距离显然效率极低。为此，我们需要使用近似最近邻（Approximate Nearest Neighbor, ANN）算法来大幅缩小搜索空间并提升性能。

高效向量搜索的关键：ANN 与 HNSW

目前最流行的向量索引技术之一是 HNSW（Hierarchical Navigable Small World）图算法。它通过构建多层导航结构，使得在大规模向量集合中可以快速定位最近邻。许多主流的向量数据库（如 FAISS、Milvus）都集成了 HNSW 来加速搜索过程。

为了支持生成式 AI 工作负载，现代数据库必须具备以下能力：

将原始数据转换为嵌入向量；
持久化存储这些向量；
构建高效的索引结构以实现快速检索。

以下是准备和处理用于向量搜索的数据的标准步骤：

1. 数据摄入（Ingestion）

使用标准的数据导入工具将数据加载到数据库中。
对于关系型数据库（RDBMS），通常意味着将数据写入表中。
支持批量导入或实时流式处理，确保能够处理最新数据。
目标字段可以是数组、JSON 或其他适合存储向量的格式。

2. 数据协调（Curation）

执行轻量级的数据清洗和标准化操作。
统一文本格式、处理缺失值或异常内容。
可在此阶段对数据进行丰富（Enrichment），例如添加标签或分类信息。
输出通常是一个结构化的列表或文档。

3. 数据编码（Encoding）

将结构化数据转化为嵌入向量。
可使用外部服务 API，如 OpenAI 的 text-embedding-ada-002 模型，或开源的 Sentence Transformers 等预训练模型。
图像、音频等非结构化数据也可通过相应模型转换为向量。

4. 加载嵌入向量（Vector Ingestion）

将生成的向量存储到数据库中。
通常做法是在原表基础上扩展一个新的列，类型为 vector、JSON 或 BLOB，用于保存向量数据。
这些向量应与原始记录保持一一对应。

5. 性能调优（Performance Optimization）

为了加快搜索速度，可以采用多种优化策略：
- 压缩向量数据
  
  ：例如使用 PQ（Product Quantization）减少内存占用。
- 利用 SIMD 指令
  
  ：实现并行化向量扫描，提升计算效率。
- 构建 HNSW 索引
  
  ：加速大规模向量的近似最近邻搜索。
- 使用专用函数
  
  ：如 SingleStoreDB 提供的 JSON_ARRAY_PACK 函数可将 JSON 数组高效转为向量。

完成上述流程后，您的系统就具备了支持语义搜索的能力。从自然语言查询到语义嵌入，再到高效检索，整个过程依赖于向量的生成、存储与索引机制。借助现代向量数据库和嵌入模型的强大功能，企业可以以前所未有的方式探索其内部数据的价值，推动智能应用的快速发展。

3.2 执行向量搜索

当系统完成数据的嵌入与索引构建后，操作便转移到前端------即用户通过如 ChatGPT 这样的聊天机器人进行交互的环节。此时，用户以自然语言形式提出问题或输入提示（prompt），而第一步就是将这些文本内容转换为向量表示。

这一转换通常通过调用大型语言模型（LLM）来实现，例如 OpenAI 的 GPT-3 或其他预训练嵌入模型。该过程将用户的自然语言查询映射到高维语义空间中的一个向量点，从而可以与其他已索引的向量进行相似性比较。

接下来，系统会首先在企业内部的数据中执行向量搜索，寻找最相关的匹配结果。随后，系统可以将这些匹配项作为附加上下文信息，再次输入到 LLM 中，以生成更准确、更具上下文相关性的回答。

正如前文所述，LLM 的输入长度是有限制的。例如，GPT-4 虽然支持最多约 32,000 个 token（相当于 40 页左右的文本），但其访问权限尚未完全开放。因此，如何高效利用这有限的"上下文窗口"，成为提升模型输出质量的关键因素之一。

在这种情况下，使用企业数据库进行向量搜索就显得尤为重要：它能够在将请求发送给 LLM 之前，快速筛选出最相关的信息，从而大幅减少需要传递给模型的数据量，同时确保上下文的质量和相关性。

此外，如果使用的数据库既支持传统关键字搜索，又具备向量搜索能力，还可以实现两者的融合查询。也就是说，在执行 SQL 查询时，既可以基于结构化字段进行 JOIN 和过滤，也可以结合向量相似性搜索来增强语义理解能力。这种混合搜索方式不仅提升了查询的灵活性，也为构建智能化应用提供了更强的数据支撑。

简而言之，向量搜索不仅是连接用户自然语言输入与企业数据之间的桥梁，更是优化 LLM 使用效率、降低成本并提升响应质量的关键一环。借助现代数据库的多模态查询能力，开发者可以在传统结构化查询的基础上，无缝集成语义搜索功能，从而打造更加智能、高效的 AI 应用体验。

3.3 利用 LLM 生成智能响应

在完成数据库、数据仓库或湖仓（Lakehouse）中的向量搜索并获取相关匹配结果后，下一步是将这些信息输入到大型语言模型（LLM）中，以执行更高级的语义任务，例如个性化推荐、内容摘要或上下文增强。

具体来说，系统会将从数据库中检索出的相关数据（即"匹配结果"）连同用户查询一起，发送至 LLM 的 API 接口。LLM 将基于这些信息进行理解和推理，最终生成自然语言形式的响应，提供更具洞察力和个性化的输出。

然而，在早期阶段，随着 ChatGPT 等工具的兴起，许多企业和机构出于对数据隐私的担忧，限制了其使用。这是因为 OpenAI 在最初的数据政策中明确表示，可能会利用用户的输入内容来训练和优化其模型。

值得指出的是，OpenAI 在 2023 年 3 月更新了其数据使用政策。根据最新规定，用户输入不再被用于模型训练。尽管系统仍会在服务器上保留提示信息最多 30 天，但这主要是为了满足合规与法律审查需求。30 天后，相关数据将被自动删除，从而显著提升了用户数据的隐私保护水平。

因此，如今越来越多的企业开始放心地将 LLM 集成到其业务流程中，借助其强大的语义理解与生成能力提升应用智能化水平。

一旦处理完成，LLM 将返回结构化或自然语言形式的响应，供前端应用展示给用户或触发后续的自动化流程。这一过程不仅实现了从原始数据到智能输出的闭环，也为构建下一代 AI 驱动型应用提供了坚实基础。

4.小结

生成式人工智能仍处于快速发展阶段，展现出巨大潜力。本文聚焦于实现语义搜索，特别是支撑这一生态系统、尤其是组织在利用大型语言模型处理专有数据时所需的数据库能力。尽管技术不断演进，企业在推进AI成熟过程中不应忽视数据管理的最佳实践。

在企业AI应用集成的过程中， MCP 的作用显著，如果希望快速入门MCP，可以阅读笔者的《MCP极简入门》一书：

【关联阅读】