简单是美

**简介
在我的上一篇文章中，我将生命演化的历程与人类创新的进步做了类比，描述了一个循环模式，在这个模式里，简单孕育出复杂，而复杂的系统又寻求简化。一个细胞分裂和分化，最终形成一个能够执行多种功能的复杂生物体。

从简单到复杂的演变过程中，真正突出的是那些兼具多重功能的事物，在大规模的应用中带来简化。比如鸟类的羽毛——它们不仅对飞行至关重要，能够提供升力并帮助控制，还具有保温作用，使鸟类在寒冷的天气里保持温暖。在某些种类中，羽毛的颜色和图案在伪装、求偶展示和社会信号传递中都起着重要作用，这些都是生存所必需的。

这种模式不仅限于生物学。在我们的创造物中也能看到这一点。拿 iPhone 来说，它是一个多用途的典范，诞生于追求简洁。它一诞生，iPhone 将多个专业化设备的功能整合进了一个简单易用的界面（同样，CRM 和操作系统也是如此）。

那么为什么我要在谈到生成式人工智能和数据库时提到这点呢？

我来解释一下。

在生成式人工智能应用领域中，有一种普遍的看法是，你必须使用只包含矢量的数据库来为大型语言模型（LLM）提供上下文。冒着被大量愤怒评论淹没的风险，我要说的是，其实你不必这样做。

事实上，将仅向量数据库添加到应用或服务中会增加复杂性，因为它违背了简洁性的原则。仅向量数据库只能用于存储和搜索向量数据，而不能做其他事情。

让我们来拆解一下。在构建应用程序的世界中，大致可以分为两大类，包括生成AI应用程序——低代码或无代码的构建方式和企业级的应用场景，后者则需要复杂的集成，以及较为复杂的需求。

谈到生成式AI时，无论是哪一类，构建一个自定义应用程序时，你需要三个基本组成部分——应用程序需要能够访问自定义知识（你提供给大语言模型的数据），自定义指令（这些使你的大语言模型应用程序具有独特的特性），最后是访问工具（能够调用其他API和应用来执行特定任务）。

在撰写本文时，帮助构建生成式AI应用或定制聊天机器人的低代码/无代码工具数不胜数。直到一周前，使用这些工具都需要先下载或注册一个仅限向量的数据库。现在，不需要了。让我们来看看几个例子：

1. Flowise — 一个基于LangChain的开源无代码工具，允许你构建“流程”，即一系列连续的步骤来完成任务。一旦你构建了流程，你可以手动运行它，或者通过其他无代码工具（如Zapier或Make（以前称为Integromat））调用其API端点。在Flowise中，如果你打算根据自己的数据构建某个东西，你确实需要选择一个向量存储，但我并不意外他们可能会增加对OpenAI助手API的支持，这些API不需要任何仅用于存储数据的向量存储数据库。
2. RelevanceAI — 一个付费工具，与OpenAI自定义GPT非常相似。你不需要专门的向量数据库来构建自己的自定义AI。你可以在Relevance上上传数据，就像在OpenAI GPT上一样，也不需要注册或购买另一个仅用于存储向量的数据库。
3. Voiceflow — 一个付费工具，允许你构建自己的定制机器人或基于LLM的应用程序，并将其连接到其他应用程序。构建此应用程序不需要专门的向量数据库。
4. Botpress — 与其他提到的工具非常相似。你不需要专门的向量数据库来向构建在Botpress上的应用程序提供知识。

值得注意的是，上述提到的工具只是以低代码/无代码方式构建AI应用程序的众多选项中的一小部分。目前存在的一些低代码工具，如Bubble、Zapier、Make、n8n和Tooljet，现在也具备生成AI的功能，可以用来构建基于生成AI的应用程序。

企业级生成AI工具

当我们谈论为企业构建生成式AI应用时，我们讨论的不仅仅是另一个用例，而是一个充满复杂性和大规模数据的世界。我们谈论的是软件架构和技术栈，可能包含数百乃至数千个现有的API端点、数据管道和不同的团队，所有这些都用不同的编程语言构建，并不仅有大量CI/CD管道，更重要的是，还有海量的数据。这些数据具有以下特性：1）数据类型多样，包括SQL、NoSQL、CSV、Parquet、基于HDFS的文件、二进制数据、时序数据等；2）数据量通常为太字节或拍字节级别；最后，可能还需要处理事务型和分析型数据库、数据湖和数据仓库中的所有这些数据。

如果我要用一个简单的图像来展示这种数据复杂性的样子，大概就是这样的。

企业数据架构的复杂性问题可视化

当然，我是在开玩笑啦。实际上大概会像这样子。

企业简化数据架构图

现在想象一下，你正在构建一个基于LLM的应用程序，它显然对所有这些数据一无所知，因为它是在不同的数据集上训练出来的，因此对你们公司的数据集一无所知。

你现在有三个选择，可以让你的大型语言模型了解这些数据。

1) 重新训练你的大模型

2)，调整大模型

3) 使用检索增强生成模型（RAG）开发您的应用。

假设你没有数百万美元、大量GPU和干净的数据集，所以你可以选择微调一个大型语言模型或者使用RAG。大多数公司最终会采用微调和RAG相结合的方法。不过值得注意的是，微调只是针对特定的模型和特定的行为。因此，如果这两个中的任何一个发生变化，这种情况在当今非常普遍，你就需要对新的模型进行微调，并继续用新数据进行训练。

现在，我们来看看构建企业级生成式AI应用程序时典型的RAG架构。下面的图是一个简化后的参考架构。

企业级LLM应用（大型语言模型应用）参考架构示例

在这样的架构里，如果你想要用RAG从最底层数据中搜索和整理，我们现在有两个选择：要么添加一个专门做向量的数据库，即一个只做向量的数据库，要么想办法简化这个架构同时满足企业所有需求。

根据我们到目前为止的讨论，我会将这家企业分为三个主要类别，如下图所示——多种类型的数据、交易和分析、以及在大量数据中进行的混合搜索。

企业数据架构的三大需求,

但首先，让我们来探讨一下为什么最近向量和向量数据库如此受到关注。简单来说，RAG就是用来搜索大量数据并返回最相关结果的技术。在这种情况下，传统的精确关键词匹配，即词汇搜索，就不起作用了。因为如果用户提问如——“我们公司在2020年的CEO是谁？”，而文档中仅含有——“2020年，公司由John Doe领导”这样的描述，那么这种匹配方式就很难成功。

这里就是语义搜索派上用场的地方。语义搜索是一种根据意义相近而非完全字符或单词匹配的方式来查找数据的方法。它通过首先将要搜索的数据转换成一组由逗号分隔的向量或数字来实现。

用通俗的话来说，想象一下你把一间房里的所有物品都赋予一个位置编号，就像经纬坐标一样（不过这里的向量有数千个维度），每个物品都会有一组数字来表示它的位置。在这个空间里，相似的物品会更接近；比如，国王、男孩、王子这些词和女孩、女王、公主这些词的数字/向量会更接近。这是一个将数据转换为嵌入或向量的简单例子。

数据的向量化可视化

在将数据转换为向量并进行语义搜索的过程中，主要分为三个步骤：1）使用模型生成向量或嵌入、2）存储并索引这些向量、3）执行对数据的语义搜索。

对于第3点，通常你可以使用余弦相似度算法，或者使用欧几里得距离算法等来测量对象之间的确切距离。然而，语义搜索通常对非结构化数据（比如PDF和文档）效果很好。如果你的数据是以结构化SQL表格形式存储的，你不需要在这种情况下用到向量，因为你可以通过连接表格来整合和匹配数据。

那么如果您的数据类型各异——包括SQL、JSON、二进制等，并且数据量是海量且不断有新的数据以极快的速度流入，我们现在会怎么办？

下面是一个图表，展示了再加入一个数据库会是什么样子。

在现有复杂数据架构中增加复杂度

除了增加了更多的数据传输和成本以外，这种架构选择还存在一个更大的问题。由于只支持向量的数据库只能存储向量和少量的元数据（例如，Pinecone 对元数据的限制仅为 40KB），你现在必须进行两次请求：1）搜索向量，2）通过查询元数据来获取实际的数据，而这些元数据可能存储在完全不同的数据库中。

总的来说，只用矢量的数据库有三个大问题。

1. 它只能管理向量，所以你还需要在其他地方获取、混合和匹配你的SQL、JSON、二进制以及其他类型的数据。
2. 这个过程可能会因为频繁创建向量而变得昂贵。
3. 这种架构不是实时的，因为你可能有一堆新数据没有立即转换成向量，因为一些数据库（如Pinecone）在插入向量和能够搜索之间存在时间延迟。

Pinecone 文档的截图

最后，由于在过去几年内建立了许多仅支持向量的数据库，其中一些仍然没有ACID特性、冗余和灾难恢复等基本数据库功能。

对于数据库的选择来说，有超过300种选择，这取决于你怎么看，可能是幸运的也可能是不幸的。

让我们一起浏览一下数据库领域，更好地了解我们的选项。

• 仅支持向量的数据库： 工具如 Pinecone、Weaviate、Qdrant（顺便提一下，Grok LLM 使用 Qdrant，所以如果它对一个 LLM 来说足够好，那么如果你有类似的使用场景，它可能也是一个不错的选择），以及 Milvius 专门用于向量存储和搜索。然而，它们通常无法满足企业的各种需求，如处理不同类型的数据和实时分析。正如我们之前提到的，它们只能进行单一功能的操作，因此会增加复杂性、成本和延迟。
• Postgres 配合 PG Vector： 这个选项在事务处理和语义搜索方面表现出色，但缺乏分析能力。如果你的场景需要同时处理 SQL 和 JSON 数据，则你可能需要考虑其他选择。
• MongoDB 配合向量： MongoDB 适应事务处理，并且最近还增加了对向量的支持。如果你的使用场景仅限于对 JSON 进行语义搜索，则这是一个不错的选择。然而，如果你需要支持多种数据类型、运行分析和 SQL 支持，则需要寻找其他选项。
• Elasticsearch： 以在词法和语义搜索方面的卓越表现而闻名，但 Elasticsearch 并不适用于分析和事务处理场景。特别是最近的向量搜索功能，其语义搜索方法仍然不够透明。尽管它在搜索方面表现出色，但作为单一数据库来处理事务和分析场景时，可能不是最佳选择。
• SingleStore： 在这一群工具中，SingleStore 独树一帜。它适用于事务处理和分析，可以实时处理事务和分析工作负载，快速处理数据引入，并提供向量支持（尽管在 KNN（最近邻）查询方面存在一些限制）。它支持 SQL 和 JSON，适用于事务处理和分析，并支持词法和语义搜索。

当然，还有许多其他的选择。图数据库 Neo4J 也支持向量功能，同样，Redis 这样的键值型内存数据库也支持向量功能。这些选择还包括能够做不止一件事的数据库，这对于任何企业级应用来说都是关键所在。

总之，简洁是最复杂且最难实现的目标之一。作为构建者，我们每天都会做各种选择（其中最难的一个就是给变量命名）。在我看来，选择那些能够做好几件事的东西来简化事情至关重要，而不是选择那些只能做一件事的东西，这样只会增加复杂性。这对我们来说非常重要，可以让我们通过这种方式进化现有技术，以可扩展的方式集体增强我们的能力。

简洁能扩展。