向量数据库：错误的抽象——以向量器重新定义嵌入管理

引言：AI应用开发中的隐形痛点

“你的嵌入又不同步了。”这句话成了众多构建AI应用的工程团队的噩梦。从简单的向量搜索实现到复杂的监控、同步和应急处理，AI系统在投入生产后，向量数据库的抽象缺陷逐渐暴露。

许多团队都有过类似经历：构建RAG系统时使用Pinecone作为向量数据库存储和搜索嵌入，但文本数据难以适配其元数据结构，不得不搭配DynamoDB处理大文件和应用数据，还需OpenSearch实现词法搜索。结果是同时处理三个系统，同步工作堪称噩梦——删除一个源文档，需要分别操作三个系统，任何一步遗漏都可能导致资源浪费或数据错误。

向量数据库的核心问题：割裂的嵌入与源数据

向量数据库（包括支持向量搜索的通用数据库）的致命缺陷在于：嵌入被插入数据库后，生成它们的非结构化数据与向量嵌入之间的连接就断裂了。

向量嵌入本质上是源数据的高维表示，二者存在根本联系，但当前的抽象却将嵌入视为独立数据原子，这导致一系列问题：

复杂的ETL管道用于处理数据分片、格式化和嵌入生成

同时维护向量数据库、元数据数据库和词法搜索索引

需构建数据同步服务避免数据源冲突

依赖队列系统处理更新和同步

需监控工具应对数据漂移和嵌入服务错误

升级嵌入模型或调整分片方式时，需跨多个系统协调变更

这些工作让开发团队耗费大量时间在同步逻辑、基础设施搭建和故障排除上，偏离了核心业务目标。

更好的方案：让数据库接管复杂性

当我们将嵌入重新定义为派生数据，生成和更新嵌入的责任就可以交给数据库管理系统，从而解放开发者。

这一点在数据频繁变化的场景中尤为关键：电商平台的产品目录语义搜索需要随新品上架和描述更新而调整；产品助手RAG应用必须同步最新产品信息才能提供准确回答。手动跟踪这些变化并重新生成嵌入不仅费力易错，更会分散开发精力。

向量器：作为索引的向量嵌入

更有效的抽象是将向量嵌入视为对嵌入数据的专用索引（而非字面意义上的传统索引）。我们称之为“向量器”，它从底层源数据生成向量，具有三大优势：

自动同步

如同数据库索引会随底层数据变化自动更新，向量器能确保向量嵌入始终与最新数据同步，消除手动更新需求并降低错误风险。

强化的数据-嵌入关系

独立存储的向量容易让人混淆其是否来自最新数据或旧模型，而向量器将嵌入与数据直接绑定，自动维护这种关系。

简化的数据管理

手动管理数据同步时，容易出现删除源数据后忘记清理旧嵌入等不一致问题。向量器让系统负责管理这些关系，减轻开发者认知负担。

PostgreSQL中的向量器实现：Pgai Vectorizer

Timescale团队已在PostgreSQL中实现了这一抽象——pgai Vectorizer（目前处于早期访问阶段），作为PGAI项目的一部分，旨在提升PostgreSQL对AI系统的支持。

工作原理

开发者通过SQL定义和创建向量器，指定作用的表、需向量化的列、嵌入模型和格式化规则。例如：

sql


-- 创建向量器自动处理blogs表的嵌入
SELECT ai.create_vectorizer(
   'public.blogs'::regclass,
   embedding=>ai.embedding_openai('text-embedding-3-small', 1536, api_key_name=>'OPENAI_API_KEY'),
   indexing => ai.indexing_diskann(min_rows => 100000, storage_layout => 'memory_optimized'),
   chunking=>ai.chunking_recursive_character_text_splitter('content'),
   formatting=>ai.formatting_python_template('Blog title: $title url: $url blog chunk: $chunk')
);