打造以人工智能为本的公司

1967 年，马歇尔·麦克卢汉的朋友约翰·M·库尔金说 ：“我们塑造了工具，随后工具塑造了我们。”构建技术亦是如此。我们用来构建软件的基础设施不断演进以满足构建需求，而我们的构建也会被我们所建立的基础设施所影响。

2020 年代初，生成式人工智能备受关注。关注点尤其在于产出：被生成的文本或代码 、被渲染的图像 、被制作的深度伪造 ，或被合成的音乐 。更广泛的讨论围绕这些工具将如何塑造我们，以及它们会如何影响我们的写作、编码、动画制作或信息消费。人们讨论开源与专有大型语言模型的比较表现 、幻觉风险、或平台与功能之争，同时也有现有企业与初创公司之间的类似辩论。

但关于我们工具的形态却鲜少被讨论。从根本上讲，我们构建技术的方式受制于为构建而铺设的基础设施。SaaS 的普及由互联网加速，智能手机的普及推动了移动开发，一代应用的可扩展性则由云计算推动。

AI 在我们应用中普及程度取决于算力、模型能力以及这些模型在具体业务场景中的编排。在本文中，我们将聚焦于那一编排要素。编排任何 AI 用例的关键组成部分之一是公司的数据库。数据被存储、操作并被调用的地点，是这一拼图中至关重要的一环。但正如我们将展示的那样，数据库的历史在很大程度上是作为一个“愚蠢”的基础设施存在。若要最大化 AI 的实用价值，数据库愈发需要被设计为生成性计算方程的一部分。

1959 年 5 月，数据系统语言会议（CODASYL）首次召开 ，其目的是构建“一种用于开发业务应用的通用语言。”到 20 世纪 60 年代后期，信息系统被大量数据淹没，检索相关信息的过程变得越来越昂贵。

使用大型机通常会导致每百万条指令每秒（MIPS）成本增加，因为为了维持性能，需要进行应用维护、补丁和升级，从而提高了对大型机的利用率。由于数据库管理的复杂性、僵化的层级结构以及导航结构的错综映射，公司常常需要技术专长才能访问特定信息，甚至迫使一些开发者编写完整程序来获取相关信息。

1970 年，E.F. Codd 发表了《大型共享数据库的关系模型》，提出了一种模型 ，其中表格可以通过共享特征相互关联（即用主键识别唯一记录，并用外键在表之间建立关系）。这使得通过单个查询从不同表中检索数据成为可能。Codd 的关系数据库不再依赖事先单独指定的链接来关联数据项，而是以数据项之间的关系为基础，从而实现了数据操作和使用的灵活性。

1973 年，IBM 圣何塞研究所的一组程序员开始开展 System R 项目，展示了关系数据库系统可以包含生产使用所需的完整功能，同时仍保持高性能。该团队负责开发用于提高数据库效率的基于成本的优化器 ，而由 System R 衍生出的发展最终促成了 IBM 首个关系数据库产品 SQL/DS 的发布。

在 IBM 研究院，System R 团队率先提出了一种考虑处理时间来优化数据库查询的新方法，基于 Codd 提出的模型开发了一个关系数据库原型。System R 将促成了 SQL（结构化查询语言）的发明，SQL 随后成为关系数据库的行业标准语言，并与 IBM 的 DB2 数据库管理系统一同发展。DB2 于 1983 年首次在 MVS 大型机平台上发布，随后迅速成为广泛公认的顶级数据库管理系统。

到了 20 世纪 80 至 90 年代，关系型数据库已成为主流数据库解决方案，提供直观的索引并保障查询效率。关系型数据库使得数据可以表示为具有结构化关系的表集合，从而通过像 SQL 这样的查询语言加快数据检索。

关系型数据库的设计假定它们将在单机上运行，但 1990 年代和 2000 年代互联网的大规模普及带来了海量数据，产生了单台计算机难以承载的工作负载。传统的 SQL 数据库被构建为在单一服务器上运行，用户需要通过增加物理硬件来扩展存储容量，而对于处理更大工作负载的公司来说，这种做法代价高昂且不可行。

2010 年代，随着 OLTP（联机事务处理）中的数据和用户呈指数级增长，分布式数据库、数据仓库和 OLAP（联机分析处理）随之兴起。关系型数据库和 SQL 已无法满足所需的应用规模和复杂性，NoSQL 数据库应运而生 ，以提升性能（以牺牲 ACID 特性——原子性、一致性、隔离性和持久性为代价）。

虽然关系型数据库能够存储和操作结构化数据，但在考虑创建、读取、更新和删除（CRUD）操作成本的情况下，处理连接开销和维护数据之间的关系被证明是困难的。关系型数据库非常适合处理具有逻辑或离散需求的关系数据，但通常面向为关系结构专门构建的遗留系统。

NoSQL 的出现是为了解决非结构化大数据的处理问题，通过非关系型方法为开发者提供数据持久化。NoSQL 并不以 SQL 作为主要查询语言，而是通过应用程序接口（API）提供访问，保证了更高的可扩展性、分布式计算、成本降低和模式灵活性。NoSQL 数据库运行高效架构，能够横向扩展，因此增加存储或计算能力只需更多服务器或云实例。对于需要更快处理或分析非结构化数据的数据工作负载的企业来说，NoSQL 数据库成为了首选。

在数据库架构演进的背景下，特定公司在每个新兴市场中确立了自己的地位。就在 IBM 交付 System R 不久后，时年 33 岁的 Larry Ellison 阅读了同一篇由 Codd 撰写的关系数据库论文。Ellison 与他的两位联合创始人建立了一家旨在与 System R 兼容的公司，但 IBM 使这一点变得异常困难 。因此，这三人围绕一款新的旗舰数据库产品建立起了他们的业务；Oracle Databases。自那时起，Oracle 的数据库一直是领先产品，截至 2024 年 5 月的市场份额约为 28.7%。

就在甲骨文（Oracle）于 1986 年上市前几年，另一家公司进入了数据库领域。Sun Microsystems 最初于 1982 年通过销售各种计算机组件起家，但因 Java 编程语言、网络文件系统（NFS）等贡献而闻名。值得一提的是，2008 年，Sun Microsystems 收购了一个名为 MySQL 的开源数据库管理系统。仅两年后，甲骨文又收购了包括 MySQL 在内的 Sun Microsystems。近十五年后的 2024 年 5 月，市场上两大领先数据库为甲骨文（Oracle，市场份额 28.7%）和 MySQL（~17.3%）。

来源：TOPDB 顶级数据库索引 ；Contrary Research

尽管 Oracle 在关系型数据库领域处于领先地位，人们存储和访问信息的方式并未停滞不前。每当出现新的任务，人们就会想出新的架构来应对。从像 MongoDB（2007）和 Databricks（2013）这样的文档存储，到像 InfluxDB（2013）和 Prometheus（2012）这样的时序数据库，再到像 Neo4j（2007）和 Cosmos（2017）这样的图数据库——专用数据库的名单还在不断延续。随着关系型数据库受欢迎程度的逐渐下降，这些新的边缘需求已由不同的解决方案来满足。

来源： 事务性数据库管理系统

数据库的最新演进源于处理非结构化数据的需求。过去50多年间的模式主要围绕结构化数据关系构建。但人们越来越需要一个能应对大量数据不确定性的工具。向量数据库应运而生。

随着大语言模型（LLMs）和生成式人工智能的广泛普及，向量数据库已成为能够处理非结构化、多模态数据的工具。传统的关系型数据库（Postgres、MySQL）在结构化模式下表现最好，而向量数据库则能够存储和查询向量嵌入——即相对于语言模型权重包含语义含义的数据的数值表示。与关系型数据库通常采用的行与列不同，向量数据库将数据表示为多维空间中的点，基于相似度而非精确值来匹配数据。

来源：DeepAI

根据所使用的嵌入模型，数据可以在不同的向量空间和不同维度中表示。向量嵌入捕捉数据点的语义含义，通过在向量数据库中查找彼此最接近的对象，便于检索相似对象。

例如，Word2Vec 有助于将词映射到向量，捕捉意义、语义相似性以及与其他文本的上下文关系。该算法使用一个浅层神经网络从更大语料库中推导特定词的含义，并通过逻辑回归识别任何同义词。获取嵌入的其他方法包括奇异值分解和主成分分析 ，这些方法在不依赖深层神经网络的情况下也能提取嵌入。

距离度量有助于确定向量空间中点之间的相对“距离”，常见方法包括欧氏距离 、 曼哈顿距离 、 余弦距离和 Jaccard 相似度 。K 近邻以及近似最近邻有助于通过简化图像、视频或其他多模态输入的相似性搜索来提高执行速度。

像 Weaviate、Chroma、Qdrant 和 Pinecone 这样的纯向量数据库帮助开发者处理大规模数据，特别是在对非结构化输入进行搜索方面。与以固定行列存储表格数据的传统关系型数据库（例如 PostgreSQL）或以 JSON 文档存储数据的 NoSQL 数据库（例如 MongoDB）不同，向量数据库专门配备来处理向量嵌入。传统数据库将数据存储为标量，而向量数据库只存储向量，并通过量化和聚类等索引技术来优化搜索操作。

基于 Transformer 的 LLMs（如 GPT）能够捕捉文本中的长程依赖关系。然而，保持对长文本的理解在计算上可能代价高昂。虽然当代 LLMs 能够捕捉输入中词元对的全局依赖，但时间和空间复杂度带来了计算资源挑战，限制了训练时的输入文本长度和推理时的有效上下文窗口。

对于多维情况，相对位置编码难以实现，而且大多数用于编码相对位置的办法需要一个稳健的位置嵌入机制，这会在推理时导致性能下降。处理更长序列时，向量数据库可以作为模型的长期记忆发挥关键作用，即使文本长度增加亦然。使用向量数据库可以简化诸如文本补全或摘要等任务，在这些任务中，可能需要完整的篇章上下文来生成准确的结果。

向量数据库可以为检索增强生成 （RAG）提供支持，其中向量数据库通过在原始查询旁加入额外上下文来增强传递给 LLM 的提示。由于 LLMs 通常依赖自监督训练模型，它们在需要特定知识或更高准确率阈值的领域特定任务上常常表现不佳。RAG 可以帮助验证、追溯甚至解释响应的生成过程，同时减轻因查询缺乏上下文而可能产生的幻觉问题。

开发者还可以将知识图谱与向量检索结合起来，扩展 LLMs 在训练数据之外的能力，借助微软研究院的 GraphRAG 等工具，在对私有数据集进行检索时辅助提示增强。基础的 RAG 通常难以在大规模数据集合上全面理解被总结的语义概念，因此像 LlamaIndex 和 GraphRAG 这样的工具会基于私有数据集构建知识图谱。

开发者可能会根据具体需求或用例选择使用知识图而不是基于 RAG 的方法。与此同时，向量数据库擅长相似性检索，在文档或图像搜索以及推荐生成方面表现最佳，而知识图适合用于推理与推断（在摄取数据、提取实体并获取相互关联的关系然后遍历这些关系时尤其有用）。

对于需要实时或近实时数据处理的应用，向量数据库可能比其他方案更为可取 ，因为其查询延迟更低。通过摄取并存储向量嵌入，向量数据库促成更快速的相似性检索，将输入的提示与相似的嵌入进行匹配。相似度排序有助于支持广泛的机器学习任务，涵盖推荐系统、语义搜索、图像识别及其他自然语言处理应用。

向量数据库在通过实现向量嵌入的高效存储与检索来提升 LLMs 性能方面至关重要，这使得可规模化的自然语言自动理解成为可能。但向量嵌入代表的是一次 N+1 的创新；它们仍然是一种数据形式，类似于之前的关系型或时间序列数据。传统数据库厂商已开始推出向量功能，例如 MongoDB 的 Atlas Vector Search、SingleStore 的 vector database 或 Neo4J 的 vector search indexes。尽管向量数据库在 AI 用例中可能非常强大，但它们本质上仍是“无脑”的基础设施，只由输入和输出驱动。它们缺乏理解或解释所管理数据的能力，仅仅作为在指令下存储和检索数据的仓库存在，不具备任何内在的智能或情境感知。

对于最新一代以 AI 为核心的应用来说，这还不足够。越来越多的公司以 AI 模型为其业务的核心。因此，如果这些应用要展示越来越智能的能力，它们的基础设施也需要具备同样的智能能力。

首批原生人工智能公司

自从学者们在 1956 年达特茅斯首次开始研究人工智能以来，实际应用场景一直推动着这一领域向前发展。例如，在 1960 年代末，约瑟夫·韦岑鲍姆（Joseph Weizenbaum）构建了一个名为 ELIZA 的计算机程序。它通过模式匹配来模拟对话的简单方法被用于类似治疗的初级对话；这是第一个聊天机器人。

在将人工智能用于商业场景的历史大部分时间里，AI 的改进是渐进式的。在“人工智能”一词流行之前，“机器学习”一词更常被用来指代相同的技术，即“能够从数据中学习并对未见数据进行泛化，从而在没有明确指令的情况下执行任务的统计算法”。在公众认知方面，2022 年 11 月 30 日当 OpenAI 发布 ChatGPT 时，人工智能达到了一个拐点。但从技术角度来看，转折点早在此之前就已发生。

2017 年 11 月， 金融稳定委员会 ——一个旨在监测全球金融体系的国际监管机构，撰写了一份关于机器学习将如何影响金融服务的概述 。越来越多的金融服务公司开始使用机器学习来“评估信用质量”，这可能“有助于建立更高效的金融体系”——换言之，这可能提高效率，但并不构成一项生死攸关的必然要求。

与此同时，机器学习持续不断地进步。然后，在 2018 年 5 月，OpenAI 发表了一项关于训练大型模型所需计算量历史的研究，显示自 2012 年以来计算量增加了 30 万倍，约每 3.4 个月翻一番。接着在 2018 年 6 月，OpenAI 发布了首个关于 GPT 模型的介绍。

来源：OpenAI

一场争论在两个阵营之间酝酿。一方面，许多人认为模型越做越大，其收益会递减。另一阵营——其中包括 OpenAI——则认为性能会随着规模扩大而持续提升。2020 年 1 月，OpenAI 研究员、约翰斯·霍普金斯大学教授 Jared Kaplan 与其他人发表了 《神经语言模型的扩展定律》，其中指出：

“随着我们按适当比例扩大模型规模、数据和计算，语言建模性能会平稳且可预测地提升。我们预期更大的语言模型将比现有模型表现更好且样本效率更高。”

来源：OpenAI

2020 年 5 月，OpenAI 发表了一篇关于 GPT-3 的论文《语言模型是少样本学习者》，该论文展示了随着计算资源增加性能平稳提升。

来源：OpenAI

此外，OpenAI 发现，扩大规模也能提高泛化能力，他们指出：“扩大大型语言模型的规模大幅提升了任务无关的少样本性能，有时甚至能与先前最先进的微调方法竞争。”自由研究员 Gwern Branwen 在一篇博客文章中提出了扩展假说 ，并表示：

“GPT-3，由 OpenAI 于 2020 年 5 月公布，是迄今为止训练过的最大神经网络，规模超过此前任何网络一个数量级以上……令大多数人（包括我自己）感到惊讶的是，这一大幅扩展并没有像许多人预期的那样出现边际收益递减或收益为负的情况，规模带来的好处如 OpenAI 预测的那样持续显现。”

布兰文感到的那种惊讶，是对格局的一次转变。人工智能越来越可能成为公司产品的核心，而不仅仅是附属品。Transformer 架构、更多的数据量以及性能的提升，都为以人工智能为本的产品铺平了道路。

当模型能够足够出色地作为产品核心时，AI 原生公司的时代便开始了。紧随 2020 年 5 月 GPT-3 发布之后，像 Writer 和 Jasper 这样的公司以 AI 模型为业务核心构建了文案写作产品。像 Harvey 和 EvenUp 这样的公司以 AI 为核心构建了法律科技。像 DeepScribe 和 Freed 这样的公司以 AI 为核心构建了医疗转录。但正如以往新用例促使数据库演进一样，AI 原生产品的诞生意味着每家公司技术栈背后的基础设施需要改变和适应。

一个以 AI 为核心的数据库

随着 AI 原生公司数量和规模的增长，支持 AI 原生用例的工具需求也在增加。第一波以 AI 为核心构建的公司主要关注从现有模型进行推理。他们有应用程序，可能还有一些为特定流程打造的工具，无论是用于文案写作、医疗转录等。产品的核心是模型的输出：生成的文本或创建的图像。

在 OpenAI 2023 年 11 月的 DevDay 之后，开始流传这样一个梗 ：“OpenAI 杀死了我的初创公司。”某些专用的 GPT 或 AI 代理似乎在扮演这些早期 AI 原生初创公司的一些角色，因为它们同样侧重于从现有模型进行推理。碰巧的是，OpenAI 同时成为了模型和应用的提供方。

模型能力的创新速度如此之快，以至于开始让创业公司感到威胁。但情况也有相反的一面；随着模型性能日益提升（尤其是那些易于获取的开源模型），公司能够更深入地将自身建设为以 AI 为核心的企业。

构建一个以人工智能为本的技术栈，不只是围绕模型添加一些组件。例如，为人工智能专门构建的数据库会是什么样子？以推理作为关键输出的以 AI 为本的数据库不仅会存储和检索数据；它还能够接受关于如何处理所存数据的上下文指令。

其中一个例子可能是为电商个性化商品描述。向量数据库不仅可以存储围绕商品 SKU 和描述的向量嵌入，还可以存储围绕用户画像的嵌入。利用来自数据库的所有这些上下文数据，基础设施可以利用生成式反馈循环：对商品描述的查询同时触发对相关用户画像的查询，然后基于该相关用户画像来生成商品描述。

同样， 语言也可被用作生成式反馈循环。例如，用户可能希望以多种语言生成产品描述。产品描述不仅可以针对用户个性化，还可以翻译成用户选择的语言。这类指令可以直接内置到数据库中，因为像生成式 AI 这样的用例将越来越成为应用功能的核心。

来源：Weaviate

为了适应特定用例而演进的基础设施并非新鲜事。最初，开发者在浏览器中使用 JavaScript 构建应用，使网站具有交互性和动态性。但当开发者意识到可以将这种能力带到后端时，node.js 应运而生。随后，随着开发者开始制作更多移动应用，你会看到 JavaScript 对象表示法 （JSON）的出现，它让应用更具动态性、响应性和数据驱动特性。MongoDB 完美契合了那一波浪潮，作为一家旨在应对不断演变的基础设施需求的公司而兴起。

历史正在随着 AI 再次重演。随着需求的改变，基础设施将不得不演进以满足这些需求。最大的问题将是：人们想构建哪种类型的公司，哪种基础设施最适合这些公司？正如 Bob 在接受 Matthew Lynley 采访时所阐述的：

“我坚信未来每个应用都会包含人工智能。有些应用只是点缀性地加入 AI，有些则把 AI 置于应用的核心——把 AI 拿走，应用就不复存在。如果你要构建一个网页应用并想在上面加点 AI，挺好，继续用 MongoDB，尤其是你已经在用它……但如果你想构建一个以 AI 为核心的原生 AI 应用，那就应该考虑 Weaviate。”

展望未来，公司将决定是把人工智能作为附属品——正如鲍勃所说的“点缀”——来构建产品，还是让它成为其产品的核心。

AI 原生技术栈

Source: Contrary Research

对于希望以人工智能作为产品核心组件的公司来说，现有基础设施很可能不够用。传统工具将数据存储、清洗与执行构建在一个孤岛中，而自动化则构建在另一个孤岛。这种做法的缺点是会丧失诸如生成式反馈循环等能够更好地告知并改进产品的上下文信息。

对于来自“AI 临近”技术栈的公司来说，某一特定模型的推理通常会被限制在上下文窗口内。有些人认为，随着上下文窗口容量的增加，它可以取代向量数据库。然而，情况更可能相反：向量数据库可能会发展到取代上下文窗口。向量嵌入对生成式模型至关重要，生成式结果的基础设施应将向量嵌入视为一等公民。

与其单纯扩大上下文窗口，不如将向量数据库嵌入模型中，以既提供上下文窗口的理解能力，又具备数据库的可靠性和可扩展性。尤其是，模型越是通用性越强，其为特定任务量身定制的能力就越弱。一个以 AI 为本的向量数据库将赋能更具体的能力。

通用模型（如 GPT-4）在知识上被刻意设定为通用性强。如果一个产品仅仅依赖简单的微调，那么底层模型永远不会成为该业务独一无二的价值部分。构建一个以 AI 为本的产品，除了利用模型之外，还需要围绕更紧密交织的技术栈来构建。该技术栈既提供类似数据库的规模，又具备模型的能力，从而造就更有竞争力的产品。