📢 转载信息
原文作者：Matthew Mayo
在本文中，您将了解到生产 AI 应用为何需要向量数据库进行语义检索，以及需要关系型数据库来处理结构化、事务性工作负载。
我们将涵盖以下主题：
- 向量数据库擅长什么，以及它们在生产 AI 系统中存在的不足。
- 为何关系型数据库对于权限、元数据、计费和应用状态至关重要。
- 混合架构（包括使用
pgvector）如何将这两种方法结合成一个实用的数据层。
请继续阅读以获取全部详细信息。
超越向量存储：为 AI 应用构建完整的数据层
图片作者：Author
引言
如果您查看当今几乎任何一家 AI 初创公司的架构图，您都会看到一个连接到向量存储的大型语言模型 (LLM)。向量数据库已经与现代 AI 紧密联系在一起，以至于很容易将其视为整个数据层，即驱动生成式 AI 产品所需的唯一数据库。
但是，一旦您超越了概念验证聊天机器人，开始构建面向真实用户、真实权限和真实金钱的产品，单独的向量数据库就不足以应对了。生产 AI 应用需要两个互补的数据引擎协同工作：一个用于语义检索的向量数据库，以及用于处理其他所有事务的关系型数据库。
一旦您考察了每种系统的实际功能，这并非一个有争议的说法——尽管它常常被忽视。Pinecone、Milvus 或 Weaviate 等向量数据库擅长根据意义和意图查找数据，使用高维嵌入执行快速语义搜索。PostgreSQL 或 MySQL 等关系型数据库则使用 SQL 管理结构化数据，提供确定性查询、复杂过滤和向量存储本身在设计上缺乏的严格 ACID 保证。它们服务于完全不同的功能，一个健壮的 AI 应用离不开两者。
在本文中，我们将探讨每种数据库类型在 AI 应用中的具体优势和局限性，然后介绍将它们组合成统一的、生产级的组合式数据层的实际混合架构。
向量数据库：它们的优势与局限
向量数据库在检索增强生成 (RAG) 的检索步骤中发挥作用，这种模式可以让您为语言模型提供特定的、专有的上下文，以减少幻觉。当用户查询您的 AI 代理时，应用程序会将该查询嵌入到一个高维向量中，并在您的语料库中搜索最语义相似的内容。
这里的关键优势在于基于含义的检索。考虑一个法律 AI 代理，用户询问“租户关于霉菌和不安全居住条件的权利”。即使这些文档从未包含“不安全居住条件”这个短语，向量搜索也能从数字化租赁协议中找出相关的段落；这些段落可能引用了“适居性标准”或“房东维护义务”。这是可行的，因为嵌入捕获的是概念上的相似性，而不仅仅是字符串匹配。向量数据库能够优雅地处理拼写错误、释义和隐含上下文，这使得它们非常适合搜索现实世界中混乱的、非结构化的数据。
然而，使语义搜索具有灵活性的相同概率机制也使其不精确，从而给操作工作负载带来严重问题。
向量数据库无法保证结构化查找的正确性。 如果您需要检索用户 ID user_4242 在 1 月 1 日至 1 月 31 日之间创建的所有支持工单，向量相似性搜索就不是正确的工具。它将返回与您的查询语义相似的结果，但它不能保证包含每个匹配的记录，也不能保证每个返回的记录都符合您的标准。SQL 的 WHERE 子句可以做到这一点。
聚合不切实际。 计算活动用户会话的数量、为计费汇总 API 令牌使用量、计算按客户等级划分的平均响应时间——这些操作在 SQL 中是小菜一碟，而单独使用向量嵌入则要么不可能，要么效率极低。
状态管理不适合该模型。 有条件地更新用户配置文件字段、切换功能标志、记录对话已被存档——这些都是针对结构化数据的事务性写入。向量数据库针对的是插入和搜索工作负载，而不是应用程序状态所需的读-改-写周期。
如果您的 AI 应用除了回答关于静态文档语料库的问题之外，还需要做任何事情（即，它拥有用户、计费、权限或任何应用程序状态的概念），您就需要一个关系型数据库来处理这些职责。
关系型数据库：运营支柱
关系型数据库管理着您 AI 系统中的每一个“硬事实”。实际上，这意味着它负责几个关键领域。
用户身份和访问控制。 必须绝对精确地强制执行身份验证、基于角色的访问控制 (RBAC) 权限和多租户边界。如果您的 AI 代理决定用户可以阅读和总结哪些内部文档，那么这些权限就需要 100% 准确地检索。您不能依赖近似最近邻搜索来确定初级分析师是否有权查看机密财务报告。这是一个绝对的“是”或“否”问题，关系型数据库可以明确地回答。
嵌入的元数据。 这一点经常被忽视。如果您的向量数据库存储了分块 PDF 文档的语义表示，您仍然需要存储文档的原始 URL、作者 ID、上传时间戳、文件哈希以及管理谁可以检索它的部门访问限制。那些“某些东西”几乎总是关系表。元数据层将您的语义索引与现实世界联系起来。
预过滤上下文以减少幻觉。 防止 LLM 产生幻觉最有效的方法之一是确保它只在精确范围内的、事实性的上下文上进行推理。如果一个 AI 项目管理代理需要生成一个“过去 7 天内已解决的所有高优先级工单，属于前端团队”的摘要，系统必须首先使用精确的 SQL 过滤来隔离这些特定工单，然后才能将它们的非结构化文本内容输入到模型中。关系型查询会剔除非相关数据，以便 LLM 永远不会看到它。这比单独依赖向量搜索来返回一个完美范围的结果集更便宜、更快、更可靠。
计费、审计日志和合规性。 任何企业级部署都需要对发生的事情、时间以及谁授权的进行事务性一致的记录。这些不是语义问题；它们是结构化数据问题，关系型数据库以数十年久经考验的可靠性解决了它们。
没有关系层会怎样
图片作者：Author
关系型数据库在 AI 时代的局限性很简单：它们原生不理解语义含义。使用 SQL 在数百万行的原始文本中搜索概念上相似的段落计算成本很高，并且会产生糟糕的结果。这正是向量数据库填补的空白。
混合架构：整合
最有效的 AI 应用将这两种数据库类型视为单个系统内的互补层。向量数据库处理语义检索。关系型数据库处理其他所有事情。最关键的是，它们彼此通信。
预过滤模式
最常见的混合模式是使用 SQL 来限定搜索空间，然后再执行向量查询。以下是一个关于此过程如何实际工作的具体示例。
设想一个多租户客户支持 AI。来自公司 A 的用户询问：“我们关于企业合同退款的政策是什么？”应用程序需要：
- 查询关系型数据库以检索公司 A 的租户 ID，确认用户的角色有权访问策略文档，并获取属于该租户的所有活动策略文档的文档 ID。
- 使用用户的问题查询向量数据库，但仅限于搜索第一步返回的文档 ID。
- 将检索到的段落连同用户的问题一起传递给 LLM。
没有第一步，向量搜索可能会返回公司 B 策略文档中语义上相关的段落，或者公司 A 中他们无权访问的文档。这两种情况都会导致数据泄露。关系型预过滤器不是可选项；它是安全边界。
检索后丰富模式
反向模式也很常见。在向量搜索检索到语义上相关的块之后，应用程序会查询关系型数据库，以使用结构化元数据丰富这些结果，然后再将它们呈现给用户或输入到 LLM 中。
例如，一个内部知识库代理可能会通过向量搜索检索最相关的三个文档段落，然后连接到一个关系表，附加作者姓名、最后更新时间戳和文档的置信度评分。然后，LLM 可以使用此元数据来限定其响应：“根据第三季度的安全策略（最后更新于 10 月 12 日，由合规团队撰写）……”
使用 pgvector 进行统一存储
对于许多团队来说，运行两个独立的数据库系统会带来难以证明其合理性的运营复杂性，尤其是在中等规模的情况下。这时，pgvector（PostgreSQL 的向量相似性扩展）就成了一个有吸引力的选择。
使用 pgvector，您可以将嵌入直接作为一列存储在结构化关系数据旁边。单个查询可以将精确的 SQL 过滤器、连接和向量相似性搜索在一个原子操作中组合起来。例如：
|
1
2
3
4
5
6
7
8
9
|
SELECT d.title, d.author, d.updated_at, d.content_chunk,
1 - (d.embedding <=> query_embedding) AS similarity
FROM documents d
JOIN user_permissions p ON p.department_id = d.department_id
WHERE p.user_id = 'user_98765'
AND d.status = 'published'
AND d.updated_at > NOW() - INTERVAL '90 days'
ORDER BY d.embedding <=> query_embedding
LIMIT 10;
|
在一次事务中，无需在独立系统之间进行同步，这个单一查询：
- 强制执行用户权限
- 按文档状态和时效性过滤
- 按语义相似性排名
统一模式图：Pgvector 将两类数据整合到一张表中
图片作者：Author
其权衡之处在于大规模下的性能。Pinecone 或 Milvus 等专用向量数据库专门用于处理数十亿向量的近似最近邻 (ANN) 搜索，在那种规模下会优于 pgvector。但对于语料库在数十万到数百万向量的应用来说，pgvector 消除了相当一部分基础设施的复杂性。对于许多团队来说，它是正确的起点，并且如果规模需要，以后可以选择将向量工作负载迁移到专用存储。
选择您的方法
决策框架相对简单：
- 如果您的语料库规模不大到中等，并且您的团队重视操作上的简洁性，请从 PostgreSQL 和
pgvector开始。您将获得一个数据库、一个部署和一个一致性模型。 - 如果您在大规模（数十亿向量）下运行，需要亚毫秒级的 ANN 延迟，或者需要专门的向量索引功能，请在关系系统旁边使用专用向量数据库，并通过上述的预过滤和丰富模式进行连接。
无论哪种情况，关系层都是不可或缺的。它负责管理您的用户、权限、元数据、计费和应用程序状态。唯一的问题是向量层是驻留在其内部，还是与其并存。
结论
向量数据库是任何依赖 RAG 的 AI 系统的关键组成部分。它们使您的应用程序能够按含义而非按关键字进行搜索，这对于使生成式 AI 在实践中具有实用性至关重要。
但它们只占数据层的一半。关系型数据库是使周围的应用程序真正工作的关键；它强制执行权限、管理状态、提供事务一致性，并提供连接您的语义索引与现实世界的结构化元数据。
如果您正在构建生产 AI 应用，将它们视为相互竞争的选择将是一个错误。从坚实的关系型基础开始，以管理您的用户、权限和系统状态。然后，在需要语义检索的技术必需的地方精确地集成向量存储，无论是作为专用的外部服务，还是（对于许多工作负载）作为 pgvector 列，就坐在它所关联的结构化数据旁边。
最具弹性的 AI 架构不是那些将所有赌注押在最新技术上的架构。它们是那些将每种工具用在其最强大之处的架构。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区