在当前大模型驱动的AI浪潮中，无论是构建RAG知识库，还是实现Agent的长期记忆，向量都扮演着至关重要的角色。一个典型的向量数据流包含两个核心环节：
1. 写入：将文本等非结构化数据，通过Embedding模型转化为向量，并存入向量索引。
2. 检索：将用户问题同样转化为向量，在索引中进行检索，召回相关的信息。
然而，在实际的AI应用开发中，开发者常常面临一个分裂的技术栈。向量索引、Embedding模型和业务数据库往往是三个独立的系统，这种分离带来了诸多“隐形成本”：
1. 开发之痛：需要在不同的软件/云服务之间进行技术选型和集成，编写大量胶水代码，增加了开发复杂性。
2. 运维之痛：业务数据与向量数据需要手动或通过ETL工具同步，不仅增加了运维负担，还导致数据延迟，影响AI应用获取信息的实时性。
3. 使用之痛：各种向量数据库/服务接口各异，缺乏统一标准。当需要进行向量与标量（如商品价格、租户ID等）的混合查询时，能力往往受限，学习和使用成本高昂。
PolarDB多模态混合检索架构
为了解决这些难题，PolarDB IMCI（In-Memory Column Index，简称IMCI）提出了一套全新的解决方案——在数据库内核中集成向量索引与Embedding能力，构建了一个多模态混合检索架构，致力于为开发者提供一体化的向量全生命周期管理服务。
向量全生命周期管理流程
在深入技术细节之前，我们通过一个简单的例子，直观地感受一下PolarDB带来的改变。
假设我们要为PolarDB IMCI搭建一个技术问答机器人，知识库中有以下三条文档：
"
olarDB IMCI支持通过Hybrid Plan在一条SQL中同时访问行存和列存"
"HashMatch是PolarDB IMCI中的一种Join算子"
"olarDB IMCI提供内置的向量索引和embedding服务"
过去，这需要多个系统协作。现在，你只需要几行SQL。
第一步：创建并填充知识库
-- 创建一张表，其中vec列由doc列通过EMBEDDING表达式自动生成-- 同时，通过COMMENT语法声明一个HNSW向量索引CREATETABLEt1( 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';
-- 插入原始文本数据，向量生成和索引构建由数据库自动完成INSERTINTOt1(doc)VALUES("olarDB IMCI支持通过Hybrid Plan在一条SQL中同时访问行存和列存"),("HashMatch是PolarDB IMCI中的一种Join算子"),("olarDB IMCI提供内置的向量索引和embedding服务");
第二步：用一条SQL完成“提问-向量化-检索-拼接Prompt”
当用户提问“HashMatch是什么”时，你可以这样从知识库中召回信息并生成Prompt：
SELECTCONCAT("请参考以下内容:",GROUP_CONCAT(doc),",以合适的语气回答用户的问题:HashMatch是什么")FROM(SELECTdocFROMt1ORDERBYDISTANCE(vec,EMBEDDING("HashMatch是什么","text-embedding-v4",1024),'COSINE')LIMIT1)ASt;
在这个例子中，PolarDB的优势体现得淋漓尽致：
1. 一体化：EMBEDDING表达式与向量索引无缝集成。通过物化虚拟列，文本向量化的过程无需应用层干预。
2. 自动化：只需在表定义中声明索引，数据库后台任务便会自动构建和维护向量索引，彻底告别了数据同步的烦恼。
3. 标准化：所有操作都在开发者最熟悉的SQL生态下完成。
接下来，我们将深入剖析其背后的技术设计。
我们将向量能力深度融合到PolarDB IMCI中，这一架构决策带来了独特的技术优势。我们没有“重复造轮子”，而是让向量索引“站在巨人的肩膀上”。
我们将HNSW向量索引实现为列式存储的一种二级索引。它存储的是从向量到数据行ID（RowID）的映射。这种设计的好处是：
复用成熟能力：向量索引本身通常不具备成熟的事务、备份恢复（Checkpoint/Recover）等企业级能力。通过与列存结合，这些能力被完美复用。例如，数据的可见性判断可以直接利用列存的delete bitmap，天然支持事务。
融合数据管理：向量索引只负责向量检索，而标量数据（如租户ID、时间戳、类别等）存储在列存中。查询时，通过RowID可以快速关联两者。
高性能标量过滤：在进行“向量+标量”的混合检索时，可以充分利用列存引擎强大的IO裁剪（只读需要的列）和向量化执行器，实现高效的标量过滤。
向量索引的构建开销较大，为了不影响列式存储的物理复制，我们采用异步构建。但这带来了新的挑战：
1. 前台写入流量较大时，增量数据可能无法及时被写入向量索引，产生堆积。堆积的数据无法借助向量索引加速，只能通过暴力扫描进行检索，影响性能。
2. 列式存储采用标记删除，基线向量索引中将产生空洞，带来空间开销的同时还会影响性能。
3. 使用quantization时，预训练的codebook质量将随写入下降，影响recall。
为此，我们参考LSM-Tree的设计思想，将异步构建后台任务分解为两个子任务：
PolarDB IMCI支持精确检索和近似检索。精确检索通过暴力扫描实现，较为简单，重点在于高性能的近似检索。
PolarDB优化器会基于统计信息，动态选择Pre-filter或Post-filter的执行计划。未来我们还将引入执行反馈和自适应执行，让决策更加智能。
基线索引召回：从向量索引中检索数据。利用列存的delete bitmap进行可见性判断，天然支持事务隔离。
增量数据召回：扫描尚未写入索引的最新数据，进行暴力计算。
结果合并：最后，由上层算子将两路召回的结果进行归并排序，得到最终的Top-K结果。
此外，通过Sideway Information Passing，如果上层Filter算子过滤掉了部分向量召回结果，执行器可以动态地从向量索引中召回更多候选集，以保证最终结果的数量和质量。
Embedding模型技术日新月异。我们认为，数据库的核心是数据管理与计算，而非模型本身。因此，PolarDB IMCI选择了一种更开放、灵活的方式：
将外部Embedding服务（如阿里云百炼等）的API调用封装为内置SQL表达式。
用户可以在SQL中直接调用EMBEDDING表达式，就像调用
这种设计既让用户能随时用上最前沿（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=256Gmhnsw_max_cache_size=128G
2. 开源PGVector：
shared_buffers=128GBwork_mem=1GBmaintenance_work_mem=128GBeffective_cache_size=128GB
