PolarDB IMCI将向量/Embedding能力深度集成到数据库内核，以SQL一体化管理向量全生命周期，大大简化AI应用开发，性能显著提升。
原文标题：一条SQL管理向量全生命周期，让AI应用开发更简单
原文作者：阿里云开发者
冷月清谈：
针对这些挑战，阿里云PolarDB IMCI（In-Memory Column Index）提出了一种创新的多模态混合检索架构，通过将向量索引和Embedding能力深度集成到数据库内核，实现了向量全生命周期的一体化管理。
其核心优势在于：
1. **开发一体化与标准化**：开发者只需通过简单的SQL（如EMBEDDING表达式和DISTANCE函数），即可完成向量生成、索引构建、检索和Prompt拼接等操作，无需编写大量“胶水代码”，极大降低了学习和开发门槛。
2. **自动化运维**：向量生成和索引构建由数据库后台自动完成，彻底解决了业务数据与向量数据的手动同步难题，保证了数据的实时性。
3. **技术深度融合**：HNSW向量索引被实现为列式存储的二级索引，复用了数据库成熟的事务、备份恢复等企业级能力。同时，能高效融合标量数据管理与高性能标量过滤。
4. **智能优化与实时检索**：通过异步构建机制（参考LSM-Tree思想的增量数据同步与基线索引合并），兼顾效率与时效性。优化器能智能决策混合检索路径（Pre-filter/Post-filter），执行器采用“两阶段召回”策略保证事务级实时检索。
5. **开放的Embedding生态**：数据库不绑定具体模型，而是将外部Embedding服务API封装为SQL表达式，让用户能灵活使用前沿模型，实现AI生态与数据库生态的完美结合。
经过公开数据集的性能测试，PolarDB IMCI在向量检索性能上展现出显著优势，QPS是同类产品的2-3倍。这种“一体化”设计有望成为AI与数据库融合的新范式，为智能应用提供坚实高效的数据底座。
怜星夜思：
2、文章提到PolarDB IMCI将外部Embedding服务（如阿里云百炼）的API调用封装为内置SQL表达式。这对于企业在模型安全、数据隐私和成本管理方面会有哪些潜在影响或考量？
3、如果一个团队已经运行着一套基于传统关系型数据库（如PostgreSQL）+独立向量数据库（如Faiss、Qdrant或Pinecone）构建的RAG系统，他们考虑迁移到PolarDB IMCI这种"一体化"方案，除了文章提到的开发和运维简化，还需要重点考量哪些"隐性"因素？比如数据迁移成本、现有技术栈人员的学习曲线等。
原文内容
一、引言：AI应用开发的隐形挑战
在当前大模型驱动的AI浪潮中，无论是构建RAG知识库，还是实现Agent的长期记忆，向量都扮演着至关重要的角色。一个典型的向量数据流包含两个核心环节：
1. 写入：将文本等非结构化数据，通过Embedding模型转化为向量，并存入向量索引。
2. 检索：将用户问题同样转化为向量，在索引中进行检索，召回相关的信息。
然而，在实际的AI应用开发中，开发者常常面临一个分裂的技术栈。向量索引、Embedding模型和业务数据库往往是三个独立的系统，这种分离带来了诸多“隐形成本”：
1. 开发之痛：需要在不同的软件/云服务之间进行技术选型和集成，编写大量胶水代码，增加了开发复杂性。
2. 运维之痛：业务数据与向量数据需要手动或通过ETL工具同步，不仅增加了运维负担，还导致数据延迟，影响AI应用获取信息的实时性。
3. 使用之痛：各种向量数据库/服务接口各异，缺乏统一标准。当需要进行向量与标量（如商品价格、租户ID等）的混合查询时，能力往往受限，学习和使用成本高昂。
PolarDB多模态混合检索架构
为了解决这些难题，PolarDB IMCI（In-Memory Column Index，简称IMCI）提出了一套全新的解决方案——在数据库内核中集成向量索引与Embedding能力，构建了一个多模态混合检索架构，致力于为开发者提供一体化的向量全生命周期管理服务。
向量全生命周期管理流程
二、百闻不如一见：一条SQL搞定RAG知识库
在深入技术细节之前，我们通过一个简单的例子，直观地感受一下PolarDB带来的改变。
假设我们要为PolarDB IMCI搭建一个技术问答机器人，知识库中有以下三条文档：
-
"PolarDB IMCI支持通过Hybrid Plan在一条SQL中同时访问行存和列存"
-
"HashMatch是PolarDB IMCI中的一种Join算子"
-
"PolarDB IMCI提供内置的向量索引和embedding服务"
过去，这需要多个系统协作。现在，你只需要几行SQL。
第一步：创建并填充知识库
-- 创建一张表，其中vec列由doc列通过EMBEDDING表达式自动生成 -- 同时，通过COMMENT语法声明一个HNSW向量索引 CREATE TABLE t1( doc TEXT, vec VECTOR(1024) AS (EMBEDDING(doc, "text-embedding-v4", 1024)) STORED COMMENT 'imci_vector_index=HNSW(metric=cosine,max_degree=16,ef_construction=300)' ) COMMENT 'COLUMNAR=1';– 插入原始文本数据，向量生成和索引构建由数据库自动完成
INSERT INTO t1(doc)VALUES(“PolarDB IMCI支持通过Hybrid Plan在一条SQL中同时访问行存和列存”),(“HashMatch是PolarDB IMCI中的一种Join算子”),(“PolarDB IMCI提供内置的向量索引和embedding服务”);
第二步：用一条SQL完成“提问-向量化-检索-拼接Prompt”
当用户提问“HashMatch是什么”时，你可以这样从知识库中召回信息并生成Prompt：
SELECT CONCAT("请参考以下内容: ", GROUP_CONCAT(doc), ", 以合适的语气回答用户的问题: HashMatch是什么")FROM(SELECT doc FROM t1 ORDER BY DISTANCE(vec, EMBEDDING("HashMatch是什么", "text-embedding-v4", 1024), 'COSINE') LIMIT 1) AS t;
在这个例子中，PolarDB的优势体现得淋漓尽致：
1. 一体化：EMBEDDING表达式与向量索引无缝集成。通过物化虚拟列，文本向量化的过程无需应用层干预。
2. 自动化：只需在表定义中声明索引，数据库后台任务便会自动构建和维护向量索引，彻底告别了数据同步的烦恼。
3. 标准化：所有操作都在开发者最熟悉的SQL生态下完成。EMBEDDING和DISTANCE表达式就像普通的SQL表达式一样易于使用，学习成本极低。
接下来，我们将深入剖析其背后的技术设计。
三、详细设计：原生于HTAP数据库的向量能力
我们将向量能力深度融合到PolarDB IMCI中，这一架构决策带来了独特的技术优势。我们没有“重复造轮子”，而是让向量索引“站在巨人的肩膀上”。
3.1 架构核心：基于列存的二级索引
我们将HNSW向量索引实现为列式存储的一种二级索引。它存储的是从向量到数据行ID（RowID）的映射。这种设计的好处是：
-
复用成熟能力：向量索引本身通常不具备成熟的事务、备份恢复（Checkpoint/Recover）等企业级能力。通过与列存结合，这些能力被完美复用。例如，数据的可见性判断可以直接利用列存的
delete bitmap，天然支持事务。 -
融合数据管理：向量索引只负责向量检索，而标量数据（如租户ID、时间戳、类别等）存储在列存中。查询时，通过RowID可以快速关联两者。
-
高性能标量过滤：在进行“向量+标量”的混合检索时，可以充分利用列存引擎强大的IO裁剪（只读需要的列）和向量化执行器，实现高效的标量过滤。
3.2 向量索引构建：
兼顾效率与时效的异步机制
向量索引的构建开销较大，为了不影响列式存储的物理复制，我们采用异步构建。但这带来了新的挑战：
1. 前台写入流量较大时，增量数据可能无法及时被写入向量索引，产生堆积。堆积的数据无法借助向量索引加速，只能通过暴力扫描进行检索，影响性能。
2. 列式存储采用标记删除，基线向量索引中将产生空洞，带来空间开销的同时还会影响性能。
3. 使用quantization时，预训练的codebook质量将随写入下降，影响recall。
为此，我们参考LSM-Tree的设计思想，将异步构建后台任务分解为两个子任务：
-
增量数据同步（类似Flush）：该任务会动态监测索引构建的延迟。
-
延迟低时：将增量数据逐行写入到基线索引中，保证数据尽快可查，同时避免产生过多的小索引。
-
延迟高时：通过Bulk Load的方式，将堆积的增量数据快速构建成一个小索引，防止堆积影响查询。
-
基线索引合并（类似Compaction）：该任务负责合并小索引，并清理已删除数据留下的空洞。
-
数据量较大，删除比例较低，召回率较高时：采用逐行合并，开销较小。
-
大量更新或删除时：触发全量重建，重新构建一个紧凑、高效的基线索引，保证查询性能和召回率。
3.3 向量检索：优化器与执行器的协同作战
PolarDB IMCI支持精确检索和近似检索。精确检索通过暴力扫描实现，较为简单，重点在于高性能的近似检索。
-
优化器：智能决策混合检索路径
在混合检索场景中，过滤标量和检索向量的先后顺序，对性能影响巨大。
-
Pre-filter（先标量）：当标量条件（如
price < 100）能过滤掉大量数据时，先执行标量过滤，在小结果集上进行向量暴力计算会非常快。 -
Post-filter（先向量）：当标量条件选择性差时，先通过向量索引召回K个近邻，再用标量条件进行过滤更为高效。
PolarDB优化器会基于统计信息，动态选择Pre-filter或Post-filter的执行计划。未来我们还将引入执行反馈和自适应执行，让决策更加智能。
-
执行器：实现事务级的实时检索
为同时保证数据可见性（事务）和数据新鲜度（实时），执行器采用“两阶段召回”策略：
-
基线索引召回：从向量索引中检索数据。利用列存的
delete bitmap进行可见性判断，天然支持事务隔离。 -
增量数据召回：扫描尚未写入索引的最新数据，进行暴力计算。
-
结果合并：最后，由上层算子将两路召回的结果进行归并排序，得到最终的Top-K结果。
此外，通过Sideway Information Passing，如果上层Filter算子过滤掉了部分向量召回结果，执行器可以动态地从向量索引中召回更多候选集，以保证最终结果的数量和质量。
3.4 EMBEDDING：拥抱开放生态
Embedding模型技术日新月异。我们认为，数据库的核心是数据管理与计算，而非模型本身。因此，PolarDB IMCI选择了一种更开放、灵活的方式：
-
将外部Embedding服务（如阿里云百炼等）的API调用封装为内置SQL表达式。
-
用户可以在SQL中直接调用
EMBEDDING表达式，就像调用SUM、AVG一样简单。
这种设计既让用户能随时用上最前沿（SOTA）的模型，又兼容了简洁的SQL生态，实现了AI生态与数据库生态的完美结合。
四、性能测试：数据见证实力
我们在公开的GIST-960数据集上，将PolarDB IMCI与开源PGVector及MariaDB进行了性能对比。在同等硬件规格下（见附录），测试结果显示：在不同的召回率下，PolarDB IMCI的向量检索性能（QPS）是其他两款产品的2-3倍。
五、总结
PolarDB IMCI通过将向量检索与Embedding能力集成到数据库内核中，从根本上解决了传统AI应用开发中技术栈分裂、数据孤岛和运维复杂等痛点。它不仅提供了一个高性能、支持事务、实时可见的向量数据库，更重要的是，它将这一切都统一在开发者最熟悉的SQL语言之下，极大地降低了AI应用的开发和维护门槛。
我们相信，这种“一体化”的设计将成为AI与数据库融合的新范式，为广大开发者构建下一代智能应用提供坚实、高效的数据底座。
附录
测试使用的CPU规格为Intel(R) Xeon(R) Platinum 8357C CPU @ 2.70GHz，PolarDB为128G规格，开源PGVector和MariaDB的相关参数如下：
1. MariaDB：
innodb_buffer_pool_size = 256G
mhnsw_max_cache_size = 128G
2. 开源PGVector：
shared_buffers = 128GB
work_mem = 1GB
maintenance_work_mem = 128GB
effective_cache_size = 128GB
PolarDB 列存索引加速复杂查询
本方案为您介绍如何通过云原生数据库 PolarDB MySQL 版列存索引（In-Memory Column Index，简称 IMCI）实现大数据量场景下的高性能复杂查询。
点击阅读原文查看详情。