谷歌数据库副总裁的一篇文章，未来的AI数据库是什么样！

liuaustin32026年01月08日约 20 分钟

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7 8群已经爆满 9群 300+，开10群PolarDB专业学习群110+)

虽然我的另一个号，在抨击AI，甚至转发了党中央的官方媒体文章中中写出AI发展对普罗大众未来的生存的担心，但这个号，我们只说技术，不说哲学，人文。

今天我们从技术的角度来说说，什么是AI数据库，因为大量的文字，国内的数据库产品让我们对于什么是AI数据库有一些误解，所以，本篇将从一篇国外的文字说起。

AI 数据库就是向量数据库，AI数据库就是矢量数据库，AI数据库就是图数据库，时序数据库？ NO NO NO

在这篇文字中，谷歌的Google Cloud 数据库工程副总裁Sailesh Krishnamurthy，对于AI数据库的认知可以总结如下：

混合搜索能力：结合向量搜索、全文搜索与结构化搜索。

多模态支持：如图数据库接口、地理空间数据等。

内置 AI 函数：在 SQL 中直接调用 AI 功能处理文本、品牌识别等任务。

自然语言查询：用户可用自然语言提问，数据库返回相关结果。

这篇访谈展示了数据库从传统的“存储与精确查询”工具，正在演变为支持 AI 应用的智能平台。如果你想深入探讨某个技术点，比如向量索引、参数化安全视图或自然语言转 SQL，我可以继续展开。

译文

数据库如何适应生成式 AI？又该如何与大语言模型（LLM）集成？这是 Sailesh Krishnamurthy 多年来一直在思考的问题。作为 Google Cloud 数据库工程副总裁，Krishnamurthy 领导着 Google Cloud 的数据库团队，涵盖 Google 搜索、YouTube 等所有服务。他还负责一个项目，旨在将生成式 AI 和 Google 的 Gemini 模型应用于数据库管理。

我最近与 Krishnamurthy 讨论了将数据库与 LLM 结合的挑战、从自然语言生成 SQL 的难点、Google Cloud 数据库团队如何应对这些问题，以及数据库如何演进以满足生成式 AI 应用及其用户的需求。以下是经过简化和整理的访谈内容。

Martin Heller：我们来谈谈 LLM 与操作型数据之间的脱节吧。我们该如何弥合这个鸿沟？

Sailesh Krishnamurthy：我认为 LLM 拥有大量的世界知识，而企业最合理的做法就是将其与企业内部的数据结合起来。最容易处理的是信息检索问题，比如你有一批文档。但难点在于，当你需要超越文档，从数据库中提取数据，再将其嵌入某个文档中提交给搜索引擎时，问题就变复杂了。

这些数据权限管控严格，必须确保安全。我们担心数据外泄和访问控制。数据是业务应用的核心，而且它不断变化。如果你持续地将数据提取到其他语料库中，它很快就会过时。你可以将此问题看作两种方式：复制（replication）或联邦（federation）。我是要把数据从数据库复制到其他地方，还是让其他系统联邦式地访问数据库？

Heller：我们该如何理解这两种方式——联邦与复制？

Krishnamurthy：在某种程度上，联邦和复制是彼此的对偶。你可以选择其中一种，关键是看在哪种场景下更合适。我们看到的趋势是，大家使用上下文、schema（模式）以及数据存在位置的表示方式，让 LLM 和其他编排机制实时地查询这些数据源并提供答案。我认为这是一种元趋势，不仅针对数据库，也适用于许多其他专有系统。

Slack 就是一个很好的例子，或者其他提供 API 的系统，用来弥合这种差距。但这其中有很多挑战，尤其是数据库方面。我们这个行业过去倾向于构建微服务，这些微服务对数据库的访问窗口非常狭窄。如果你只是让 LLM 访问这些微服务，那么它能看到的只是那一小部分数据。

安全性也是一个问题，因为应用通常通过服务主体连接数据库。而企业中的终端用户是登录了 Gemini for Enterprise 之类系统的用户。如果他们想连接数据库，那么这个终端用户与代理连接数据库的服务主体是不同的，因此要正确设置安全机制非常棘手。这些就是我经常看到的问题。那么我们该如何弥合这个差距？这对我们来说是个大问题，我们也有一系列解决方案。

Heller：说说这些解决方案吧。Google 提出了哪些方法？

Krishnamurthy：你希望点亮操作型数据库，让它们能被智能代理应用访问。我们有一系列选项。最简单的方式是启用一些工具，让数据库中的数据可以被 LLM 使用。

我们构建了一个叫做 MCP Toolbox for Databases 的工具，它是开源的。我从没想过自己会负责一个“病毒式传播”的项目，但它对我们来说确实非常火爆。（编辑注：MCP Toolbox 在 GitHub 上有 11.9K 星标。）不仅是我们在用，它支持我们的第一方数据库，但也是开放的。很多竞争对手也加入使用 MCP Toolbox。这是一个非常简单的方式，可以让任何使用 LLM 的编排系统连接到这些数据库。它解决了很多连接性、安全性等问题。除了开箱即用的标准工具，它还允许用户添加自定义工具。

这些自定义工具其实就是预定义的查询。你可以把它们看作是带参数的模板查询。要用英文准确地描述这些查询，其实是个不简单的问题。

我认为工程师知道如何写出优秀的 SQL 查询，但他们是否能写出优秀的英文描述，那是完全不同的事情。但我们假设可以做到，或者可以让 AI 来做这件事。那么 AI 就可以根据用户请求选择合适的工具，并生成参数。这里也有一些安全方面的问题需要考虑，比如如何设置安全参数？哪些参数是 LLM 可以设置的，哪些是不可以的？但这是解决问题最简单的方式——让 LLM 能够轻松连接操作型数据库。这是最基础版本的问题解决方案。

第二种方式是从自然语言自动生成 SQL 查询。写这些自定义工具可能很痛苦，但它们是有意义的，因为它们填补了 API 的空白。API 太窄了，但你又不想构建新的 API 层。我可以用这些自定义工具访问数据库，但如果我想做一些更开放性的操作，而 AI 的诱人承诺正是做这些开放性的事情，那么我就需要能够运行更自由的查询，并且要确保安全。

我们要解决的问题首先是准确性：如何确保生成的查询非常准确。我们的团队就在上周在全球领先的自然语言转 SQL 基准测试中拿下了榜首。科学在这方面持续进步，准确性越来越高。

Heller：有哪些因素可以提升自然语言生成 SQL 的效果？

Krishnamurthy：其中一个关键因素是上下文。你提供给模型的 schema 和元数据越多，它的表现就越好。有些信息比其他信息更明显。例如，我喜欢举的一个例子是，在一个电商场景中，你可能有一个表，其中有“账单地址”和“收货地址”两个字段。设计 schema 的人可能隐含了一个逻辑：如果其中一个字段是 null，那么两个地址应该是相同的。如果你知道这个假设，那么对系统的 SQL 查询就会更准确。

所以我们正在做的一件事是自动提取 schema，构建更好的上下文信息，让自然语言转 SQL 的效果更好。

我们也在模型内部进行创新。这是 Google 的优势：我们在整个技术栈的每一层都有布局，从芯片到基础设施，再到模型和数据库。我们与 Google DeepMind 的同事密切合作，让模型本身变得更强。这种“模型优化 + 上下文增强”的组合，能带来更准确的查询。

下一步是安全性。如果 LLM 可以对数据库运行任何查询，那么我们如何确保不会发生数据泄露？我们构建了一项技术，叫做“参数化安全视图”，它在数据库内部定义了安全边界，并编码了所需的安全策略。这样一来，LLM 可以生成任何查询，但我们会根据登录用户的权限，确保他们看不到任何不该看的信息。从信息理论的角度来说，我们也不会泄露他们不该访问的数据。

Heller：你花了很多时间思考数据库与生成式 AI 的未来。你认为我们将走向何方？

Krishnamurthy：我过去几年对这个问题的看法发生了变化。过去 50 年，数据库世界（至少是 SQL 数据库）一直专注于生成“精确结果”。我常说数据库只有一个任务：存储数据，不丢数据，然后在你提问时给出精确答案。好吧，也许是两个任务。因为我们处理的是结构化数据，所以一直强调精确性。

但现在最大的变化是，我们不再只处理结构化数据。我们也在处理非结构化数据。当你将结构化与非结构化数据结合起来，下一步就不再是“精确结果”，而是“最相关结果”。在这个意义上，数据库开始具备搜索引擎的某些能力，比如相关性和排序。这时候，信息检索系统中的“精度 vs 召回率”就变得重要了。

那么如何实现这一切？一个关键技术是向量索引。也就是说，你有结构化数据在数据库中，但还有其他类型的信息，比如非结构化数据、半结构化数据。

有些非结构化数据可能存储在数据库的列和行中，但很多会存在对象存储中，比如图像、视频、地理空间数据、PDF 文件等。这些数据需要保留在对象存储中。但我们可以做的是，从对象存储中提取向量嵌入，并将其与数据库共置。这样你就可以提出同时涉及结构化和非结构化数据的问题。

一个很好的例子是 Target.com。Target 的所有在线商品目录以及其向量搜索系统都已经迁移到 AlloyDB。他们的一个关键需求是：除了按图像搜索或按描述搜索之外，顾客可能还会关心价格，而价格信息是在数据库里的，不在对象存储中。顾客还可能关心离其登录位置最近的实体店中该商品的库存情况。

Heller：或者是距离 10 英里以内的库存。

Krishnamurthy：是的，那就变成了一个额外的参数，它会成为一个地理空间参数谓词，对吧？但关键在于，如果你试图在应用层把这些拼接起来，会非常困难，因为每个请求中这些不同谓词的选择性都不同，你无法预先知道哪种方式是正确的。

如果我使用一个独立的向量索引，我可以查询它并获得前 10 个结果，然后再去访问常规数据库，但当我应用所有其他谓词时，可能一个结果都没有。这对业务毫无帮助，因为 Target 希望提供用户会点击并最终购买的结果。如果你先访问数据库，你可能会得到太多结果，无法与最近邻向量搜索结合。

因此，我们的解决方案是把这些不同的索引放在同一个系统中。我们构建了一个叫做自适应过滤向量搜索（adaptive filter vector search）的技术，它可以将这些索引探测结合起来，从而始终以最短时间、最高质量返回最佳结果。实际效果非常惊人：在 Target.com 上，他们将“无结果页面”的数量减少了 50%，并将业务结果提升了大约 20%。

对我来说，这是一个非常有趣的启发，因为它意味着世界已经改变了。我过去在这个行业中只关注“精确结果”，但现在的新世界更像是回到了 Google 当年构建搜索拼写检查的方式——我们现在都习以为常，但在 20 或 25 年前，它是一个不断迭代、不断变得更好的系统。我认为正在构建这些新型应用的人们会从根本上意识到：“我必须持续迭代，我必须持续改进。”

Heller：我认为这引出了你之前提到的“AI 原生数据库”概念。从 Google 的角度来看，什么是 AI 原生数据库？

Krishnamurthy：我们认为的 AI 原生数据库，是一种具备向量索引混合搜索能力的数据库，它将向量搜索、全文搜索以及其他结构化搜索结合在一个系统中。我们也看到多模态数据库正在出现。例如，在 Google，我们有 Spanner，并且在数据中提供图接口。用户的期望已经发生了根本变化：他们希望我们让所有数据协同工作，因为他们不再只是提出精确查询，而是提出非常通用的问题，并希望我们找到连接数据并返回结果的方法。

AI 搜索是 AI 原生数据库的一个关键特性。另一个关键特性是 AI 函数。我们开始在数据库内部加入使用 LLM 技术提问的能力。例如，我们提供一个名为 AI 的 SQL 函数，它允许你对某个值、字段或数据库列中的文本执行一些有趣的 AI 操作。你可能会问一个关于品牌的问题，比如哪些品牌是纯美国品牌。

如果你想想数据库，它存储的是结构化信息，但其中很多其实是文本信息，是对业务有意义的内容。通过提供丰富的原语（primitives），AI 原生数据库可以让你直接在数据库内部处理这些信息。

如果回到之前的话题，我提到自然语言搜索让应用变得更丰富。这些能力彼此契合，因为用户会用自然语言向数据库提问。如果我能够进入一个 AI 原生数据库，那么返回结果的质量会变得更有趣、更有价值。

如果再往回看，你最开始的问题的答案其实是最简单的方式：自定义工具，它们看起来很像现有世界，但我们把应用拆解成了许多小工具，这些工具会发出查询，然后我们把它们连接到 AI 代理。

这是第一步。下一步是回答我没有预料到的问题，而要做到这一点，我需要准确性和安全性。我们在这两方面都取得了巨大进展。我不会说我们已经完全解决了这些问题，因为它们确实很难，但我们对目前的进展非常兴奋。

第三步是数据库本身变得更加智能，更能够处理不同类型的数据。

读完这篇文章后，给我的结果是，未来的数据库，不是给出一条SQL，给我一堆准确的数据，这不是未来的数据库，因为未来的查询本身就是不确定的，且查询的方式是动态的，现有的数据库查询方式已经无法应对未来AI的查询，数据库本身将变成一个查询路径的融合者，你是使用BTREE，向量，地理位图，时序，还是其他的数据形式，JSON,XML,或者图形，声音，等一次的查询需要的是多个路径的信息聚合和搜索，SQL引擎很可能变成时代的祭品，同时数据库将接受一个结果可能是近似的，但是结果对查询者更有意义和价值的结果，比如从结果是正确的到结果是近似的，结果是完整的，结果是排序且动态的，结果是可重复的，到结果的质量是可重复的，可以动态调整查询的质量。最后AI的功能集成在数据库内，而不是外部还需要AI的应用来处理。

最终未来的数据库，是一个“持续优化结果质量的数据智能系统”，而不是一个执行确定查询的引擎。

置顶

PostgreSQL Bitmap scan 和 Index scan 优化一个SQL ，结果非常不一样！

PostgreSQL 平时没事，怎么就一个SQL下去就不行了？，原来是老毛病了！

在测试浪潮 KaiwuDB-lite 后，留下几个大字 "你别挨骂了"

云数据库备份恢复验证，云数据库高端客户的需求说明

国产数据库大舞台，搞不搞兼容性之互相揭老底！

PostgreSQL 现世报，客户吐槽不如SQL SERVER 与国产数据库搞兼容性

阿里云 PolarDB for MySQL IMCI 绞杀SQL优化专家，My GOD！！

阿里云DTS 我冤枉，其实我很委屈--客户大爷们，咱们换个位置也理解一下吧！

SQLite 开发中的数据库开发规范 --如何提升业务系统性能避免基础BUG

把我的第一次给 “金仓” 数据库社区活动之我要作妖