没必要非得固守纯向量数据库！专访亚马逊云科技数据库负责人

生成式 AI 时代的到来催生了向量数据库日益增长的需求和应用。亚马逊云科技也在多种数据库服务上实现向量搜索功能，并且他们也认为这是任何数据库都应当具备的一项核心功能。那亚马逊云科技在数据库产品上有什么样的规划、他们如何看待纯向量数据库需求？针对上述问题，近期在 re:Invent 现场，InfoQ 采访了亚马逊云科技数据库和迁移副总裁 Jeff Carter。

Jeff Carter 主要负责亚马逊云科技的关系数据库、非关系数据库和迁移方面的十几种服务。在加入亚马逊云科技之前，任职于 Amazon.com 网站，曾将亚马逊的原有 Oracle 分析环境迁移至亚马逊云科技，并将所有事务处理引擎从遗留技术栈中迁移至亚马逊云科技。Jeff 还担任过几年首席信息安全官，在加入亚马逊之前，曾在 Tera Data 工作过 30 年。

以下为访谈实录，经过不改变原意的整理：

Jeff Carter： 先从技术框架说起。在框架的最底层，我们拥有一套全面的数据库集合。在操作型数据库方面，我们之前提供 15 种不同服务，但到本周结束时服务数量会增加到 17 种。很多客户都问我为什么要有这么多服务。答案很简单，就是人确保客户在考虑使用亚马逊云科技时，能在商店中找到符合需求的充足数据库选项。

所以我们一直在努力推出更多方案。除此之外，客户对于未来两到三年的发展肯定也设有愿景。有些愿景可能需要现有技术，也有一些可能依赖于新的技术。因此我们也会尝试提供能支撑未来需求的新技术。总之，必须密切关注客户的期望，而且这种期望是当下与未来的综合体。如我所说，到本周末我们将拥有 17 种不同的数据库服务，有些是关系数据库、也有些是非关系数据库。

以非关系数据库为例，比如我们即将发布的新方案，我称之为操作型数据库。但实际上，它的应用更偏重于分析。还有 Neptune，我们的老牌图数据库。除了 Neptune 之外，我们的图数据库阵容还会进一步扩展。而对于现有数据库，特别是关注操作型用例时，我们也将更多强调分析方面的应用。比方说，图领域中的分析。以社交图谱为例，对社交图谱的操作能显示当前用户有哪些联系人，并列出前十位，如果需要也可以列出几千位。Facebook 就属于操作型案例。但有时候，大家可能希望查询谁在网络上的影响力最大，这往往就需要所谓全表扫描。不过毫无疑问，我们当然不希望把全表扫描当作操作型负载，事务数据库也不擅长执行这类操作。所以分析应该在内存内进行，这样速度会非常快。这是一种持久设计，而且可以基于我们已经在使用的相同技术，比如 DynamoDB 和 MemoryDB，只是分析会在内存内实现。

之后是核心层，本周之后我们将拥有 17 种不同的数据库。接下来最重要的就是如何集成数据，因为并不是每个人都想面对这么多不同的资产。所以我们希望在各种资产中建立起重要的共性，也就是零 ETL。作为一项基本目标，现在我们已经围绕它建立起诸多案例，而我们真正关心的就是如何让数据无缝、顺畅地从事务引擎转移至数据仓库或者数据湖。而零 ETL，就是实现这种无缝移动的关键。

在我们执行插入、更新、删除等标准数据库操作时，数据其实就开始了流通和变化。数据要么进入 RedShift，要么移动到使用端。接下来是把数据湖治理好。因此，我们最近才公布了 Data Zone 数据区。这样大家就能找到环境中的数据，我们也可以为数据创建权限组。用户可以为权限组指定成员，再把权限组分配给权限集。而且无论大家具体使用什么分析引擎，这些权限都能正确起效。

最后是生成式 AI，这里我要讨论两种生成式 AI 的应用形式。第一，我们要采取哪些措施来改善客户体验？第二，我们要如何帮助客户构建他们自己的应用程序？而改善客户体验的案例，就是我们本周发布的公告之一：Q。在本届 re:Invent 大会之前，亚马逊也有名叫 Q 的产品，就是 QuickSight Q，主要通过自然语言处理建立仪表板和报告。这项功能现在仍然存在，但新的 Amazon Q 属于独立品牌，涵盖亚马逊云科技内部利用生成式 AI 增强客户体验的所有成果。我们这次着力宣传的一个例子就是：我们把所有用户文档同大语言模型相结合，这样用户就能随意用自然语言询问相关问题，Amazon Q 则会根据文档信息给出建议和相应的详尽操作步骤。

这样文档的交互性就更好了。不只是在搜索中使用生成式 AI，我们还用 Aurora 在 RDS 领域做过类似的尝试。我们还开发了 DevOps Guru for RDS，借此查看数据库中是否存在性能异常，并提前向客户发出提醒。我们还与负责 GuardDuty 的安全团队合作，随时监控那些指向您数据库的登录行为。

一旦它发现异常，就会主动发出提醒。具体可能是有人在反复尝试密码，也可能是来自安全部门已知暗网或恶意 IP 地址的一次登录操作。哪怕只发生一次，它也能牢记在心。这就是我们利用生成式 AI 服务帮助客户的三个简单案例。我们还投入大量资金，希望帮助客户们取得更大的成功，而这方面成果就是 Bedrock。在 Bedrock 之下，我们还推出了 PartyRock 等服务。如果大家还没试过，我强烈建议您马上体验。它非常简单也非常有趣，总的来说这就是一大堆不同大语言模型的集合。我们坚信至少就目前来看，还没有哪种单一模型能够证实世界，必须要借助多种不同的方法和模型，发挥它们各自擅长的专业知识。

比如说一种模型可能擅长编辑图片，而另一种模型可能擅长编排音乐，第三种模型则擅长修改文本或者文字润色。它们各有自己的关注取向。因此，我们希望保证客户能轻松找到、并选择最适合自身需求的模型。我们当然支持多种模型，但不同用户对模型有不同的要求，毕竟大家的业务也是独一无二的。你可能需要添加本地数据，这个过程被称为检索增强生成，简称 rag。

使用时，大家可以指定共享驱动器，指定要启用的大模型，指定支持 vss 向量相似性搜索的数据库。数据库可以是 Pincone 向量数据库，也可以是 Redis，或者我们支持的七种数据库中的任何一种。我们还在扩展，目前已经有七种不同数据库选项，包括 OpenSearch、RDS Postgres、Aurora Postgres、MemoryDB 等等，未来还会有更多。指定完成之后，点击开始，它就会读取文档，把文档拆分成块，用你选定的大语言模型将其转为向量、创建向量嵌入。之后则把它们放进支持 vss 的数据库，再把大模型和 vss 数据库组合起来，就能回答你提出的问题了。

现在我们的模型已经掌握了这些来自数据存储的特定业务知识。在交互过程中，所有的知识都圆融一体，可供你随时选择并交付给客户。现在我们就能把大语言模型跟向量存储这套组合一并交给客户了。如果愿意，也可以只提供给内部员工。总之，大家可以随意挑选用户，指定他们能跟文档中的哪些部分进行交互。文档可以是任何形式，比如说网页或者 PDF 等等。总之我们提交一个文档，把它转换成向量。之后大模型就能识别这些数据，避免手动对程序进行处理。单靠 Bedrock 就能实现全面自动化。

当然，本届 re:Invent 大会上还有很多其他案例。总之我们团队一直在与 Bedrock 团队密切合作，共同实现向量搜索功能，我们也认为这是任何数据库都应当具备的一项核心功能。

Jeff Carter： 我们可以在模型中设定多种参数，比如说召回率。整个所谓向量相似性搜索的过程，就是先提取数据、再立足多个维度创建数字，也就是说每个文档可能拥有 20、30 或者 40 个不同的维度。然后在这 40 个维度上，vss 的作用就是在不同的维度间寻找最近邻。这就是我们想要向核心数据库中添加的功能，即快速执行 vss 查找的能力。这就是召回率，它是个介于 0 和 1 之间的数字。召回率越高，得出的答案质量越好，但也会消耗更多算力。你可以选择 90% 的召回率，也可以选择 99% 的召回率。根据选择召回率的不同，各种数据库的性价比也有差异。

我觉得对于大多数用例，Aurora Postgres 都表现出色，另外 OpenSearch 也很不错。但如果想要极高的召回率，那么作为最佳配伍，我觉得 MemoryDB 的性能表现最为极致。因为它会把所有数据都存放在内存内，而不必多次访问磁盘。

Jeff Carter： 根据个人经验，我还是更关注消费者的感受这部分。ETL 其实分为两层，其一就是从事务引擎中获取基础数据并放入数据环境，而零 ETL 其实实现的就是对这一层的自动化。而对基础数据进行业务层级转换以建立更高级别的业务组，即 T 的部分，则仍然要用到 Glue 或者第三方工具才能建立起更高级别的业务领域。从 Amazon.com 的角度来看，前一个级别的实例就是配送中心库存。核对我们配送中心里的每种产品还有多少库存，再把这些数据转移到数据湖中，这就是零 ETL 起效的部分。但要想把所有配送中心都整合起来，把全局数据显示在网站上，那就需要更多的 T 层，要用到 Glue 之类的工具。

ETL 通常是向数据仓库和数据湖读取和写入数据，但如果愿意，也可以使用 Glue 访问不同的数据库以获取信息。在亚马逊云科技中，当我们谈到数据仓库时，通常是指 RedShift。而 Glue 能跟 RedShift 无缝对接。至于说数据湖，我们主要是指 Lake Formation，还有 EMR 和 Athena 等其他几种项目。Redshift 是一种作为数据仓库的并行列式数据库。

那么未来，是不是人们会更多把数据传送到数据湖中？而不再大量使用列式数据库那样的数据仓库？我觉得这两种情况都会存在，具体取决于查询的大小、类型还有表的类型，不同的场景对应不同的方法。但我觉得从长远来看，我们目前正在研发、但还没有公布的很多技术应该能发挥创造性的作用，真正把这两种环境联系在一起。

Jeff Carter： 首先，我们希望通过亚马逊云科技为客户提供更多选择。我之前用两家公司举了例子，当然还有很多其他案例。首先就是 Pincone，他们作为纯向量数据库的代表。另外 Redis Labs 也有能支持 vss 的版本。只要客户愿意，我们非常乐意支持这些产品以供免费使用。

他们对这些方案肯定都有自己的判断，而我们很高兴能支持他们的实际选择。但我一直觉得，没必要非得固守纯粹的向量数据库。 正因为如此，我们才取其核心技术并融入其他方案，努力在不同技术之间做出权衡。这样客户就能做出最符合业务需求的明智选择。

现在形势一直在快速变化，当下我们给出的答案未来都可能变成错误答案，比如 6 个月之后情况可能会大为不同。甚至未来 3 个月都可能出现变化。我相信所有企业都希望能用自己的业务信息来扩展基础模型。相信也会有企业愿意花几个月时间自行训练吧，只是成本会高得多。

我觉得微调和检索增强生成（rag）的边界比较模糊，二者的适用范围也有交集。总之虽然大语言模型的表现令人惊叹，但还远称不上完美。

Jeff Carter： 这是个好问题。首先，我们每年都会对所有产品进行创新，并投入大量时间跟客户和社区成员进行交流，了解客户在使用现有产品时遇到过哪些问题，并尝试做出改进。

但也有很多比较长远的问题，例如如何适应未来几年可能出现的趋势、提前做好准备。我们目前开发的项目可能要到一年、两年或者三年之后发布，当然希望它们在亮相时仍然具有变革性。请原谅我无法透露目前的工作内容，但我想强调的是，我们会同时考虑短期和长期问题，考虑怎么把事情做好。就以生成式 AI 为例，我们已经意识到这是一项变革性的技术，而这样的技术可能每十年都会出现一次。我们内部已经在努力转向，讨论之前的哪些成果能与之对接，并且公开表态将积极向着这条路线推进。我们会始终保持旺盛的创新动力，并真正把心力投入到有希望的特定领域当中。

所以像 Bedrock、Titan 还有 PartyRock，这些都是我们能在相对较短的时间里拿出的现实成果。我们是一家专注于机器学习和 AI 的公司，我随随便便就能举出十几个在消费级业务领域应用机器学习的例子，比如利用机器学习改造搜索功能，借此在所有配送中心内建立起智能化的补货系统。这样的案例可以说数不胜数。

而现在，我们又把目光投向了生成式 AI，希望大家都能感受到我们严肃的态度。至于生成式 AI 方面的用例，我觉得不同的人可能会有不同的看法。生成式 AI 最神奇的能力就在于处理自然语言。是的，就像前面提到，它能阅读文档，再根据读取过的内容正确回答问题，相当于将语言承载的完整历史都纳入了模型自身。这真的太酷了。我相信肯定会有很多有趣的应用出现。

Jeff Carter： 第一个词很简单，降本。第二个是生成式 AI。第三个是集成或者说整合。过去 18 个月以来，人们一直在努力寻求能够降本增效的方法，亚马逊云科技只是其中之一。这也代表着这段时间以来的一大趋势。每一次交流，对方都会强调降本和 AI，而且人们迫切需要更简单的实现方式。而要想实现二者，整合就是关键所在。