混合检索实践：向量与标量同库查询的原理与落地

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

上个月我接了个活，给一家公司搭内部知识问答。数据都在业务库里躺着，我没多想，另起了一套向量库。上线那天检索就是不准。有人问"报销流程怎么走"，系统返回的是三年前的旧制度。我查了两天，模型换了，切分策略改了，召回还是飘。

最后打开日志我才看明白，问题出在数据被切成了两半。向量在向量库里，业务状态在业务库里。检索和过滤分属两个系统，筛掉的正好是要找的那条。那两天我一直在想，AI数据库到底是什么。为什么我这套拼装方案就是不灵。

AI数据库是什么？先别被"AI原生"唬住

AI数据库，是指从架构层面就把 AI 负载当作第一等公民的数据库。 它原生统一存储向量、关系、图、文档等多种数据。它还把 AI 推理能力融进内核，直接服务智能体（Agent）。

它不等于"传统数据库再加一个向量插件"。那两天我翻了十几篇资料，发现讲定义的文章一抓一大把。可大多停在概念，落不到选型。真正决定它能不能用的，是下面五个特征。

第一，多模态数据统一存储。 结构化数据、文档、向量、时序、空间，不再散落五六套系统。以前要跨三四个库拼数据。现在一条 SQL 就能同时碰到它们。

第二，混合检索能力。 向量相似度、全文关键词、标量条件，能在同一次查询里组合。不用在应用层手动拼。这一点是我踩坑之后才真正重视的。

第三，事务级一致性。 向量写入和业务写入在同一事务里完成。要么都成功，要么都回滚。纯向量库这块基本是空白。

第四，内核内置智能。 优化器能自己感知负载变化。运维能提前预警，而不是等你半夜被叫起来。半夜被告警吵醒的滋味，我懂。

第五，对 Agent 友好。 它要能当智能体的记忆底座。也要能当上下文底座。它不只是个存储。

这五条里，第二条最容易被忽略。它也最容易在项目里翻车。我就栽在这上面。因为我把检索和过滤拆到了两个系统。当初另起向量库的时候，我压根没觉得这是个问题。

AI数据库和传统数据库，到底差在哪？加个向量检索就算吗

先给一张对比表，我按自己最关心的五个维度列。

看完这张表，一个问题就浮出来了：向量库能不能算 AI数据库？很多人把这两个当成一回事，我也被问过很多次。我的答案很直接，不算。向量数据库解决的是"相似度检索"这一件事，它做得很好。但它通常没有事务能力，业务字段过滤也不高效。高可用方案还得你自己拼。它更像AI数据库的一个能力切片，不是整体。

真正的分水岭在架构。 向量能力做在库外面，还是做进内核，走的是两条路。做进内核的，才是融合型数据库。电科金仓的 KES 就把向量类型原生融入内核层，支持 IVFFlat、HNSW 等主流索引。更关键的是，向量与标量数据可以原生混合查询。我踩的那个跨库顺序问题，在这里就不存在了。

ai数据库怎么建立？我在一个 RAG 场景踩的坑

回到那个知识问答项目。我的第一反应是维度不对。模型输出的是 768 维，而我在建表时按 512 维定义过一版。我重灌了一遍数据，召回没变。我又怀疑是切分粒度问题，把 chunk 从 500 字调到 200 字。召回还是飘。

我不确定当时该往哪查，就把一次请求拆成了两段看。第一段是向量库的语义检索，返回 20 条候选。第二段是业务库按状态字段过滤，筛掉已下架的内容。问题就出在顺序上：过滤发生在语义检索之后。原本该被排除的内容先挤进了 top 20。真正该返回的那条，被挤了出去。

跨库这一步，才是噪声的来源。改法其实很简单。让向量和业务字段回到同一张表。检索和过滤，都在同一条 SQL 里完成。这样就不会再有跨库的先后问题。

-- 商品表：业务字段与特征向量放在同一行
CREATE TABLE products (
  id           BIGINT PRIMARY KEY,
  name         VARCHAR(255),
  category     VARCHAR(50),
  status       SMALLINT,        -- 业务过滤字段
  image_vector VECTOR(512)      -- 模型提取的特征向量
);

-- 建 HNSW 索引，加速向量检索
CREATE INDEX idx_product_img
  ON products USING hnsw (image_vector vector_cosine_ops);

改造之后，查询收敛成一条语句。

-- 语义相似 + 标量过滤，同一条 SQL、同一个事务
SELECT id, name
FROM products
WHERE status = 1
ORDER BY image_vector <-> '[0.12, 0.49, 0.31, ...]'::vector
LIMIT 10;

这里有个细节我得提醒大家。建索引时用的距离算子，必须和查询时用的算子一致。我第一版索引用了默认算子，查询用了余弦距离。结果索引根本没走，直接全表扫描。数据量小的时候完全看不出来，涨到十万级才暴露。

改完之后我在测试环境记录过一次对比。这不是基准测试。下面几行只是我那个场景下的数。换个场景，结果可能不一样。

改造前：向量库查询 + 业务库查询 + 应用层 join
改造后：单库、单条 SQL
差异主要来自省掉了一次跨库往返和应用层拼装

在真实业务侧也有对应的落点。新疆移动的业务编排系统，用了金仓 AI 融合数据库。架构叫"双引擎驱动"，把 OLTP 和 AI 推理放到一起。公开报道显示，5G 网络切片配置的响应延迟，从秒级降到毫秒级。单节点支持 8000+TPS。主备切换时间小于 30 秒。这类数字比任何概念都更有说服力。

AI数据库怎么选？三个维度就够了

聊到这，选型的问题就浮出来了。网上的盘点文章很多，但大多只列名字。它们很少告诉你，什么场景该选哪条路。我按自己的判断，收敛成三个维度。

第一个维度是数据形态。 你的数据是纯向量，还是向量和业务混在一起。如果是前者，专库专办就行。如果是后者，多库拼装的性价比很低。一致性和运维都会拖后腿。

第二个维度是事务要求。 AI 产出的结果要不要和业务写入保持一致。如果是订单、库存、账务这类场景，答案通常是必须。这时候没有事务能力的纯向量库可以直接排除。

第三个维度是运维成本。 每多一套库，就多一套备份、权限、监控和升级。这些活都要人干。这笔账要算进总拥有成本，不能只看单库的性能数字。

有没有场景其实不该上 AI 数据库

有，而且不少。如果你的数据就是纯向量，一份文档切完就存。查询只做相似度，不掺业务字段。那再加一套关系库，反而是添乱。这种场景，专用向量库更轻。

如果你的业务还没到语义检索的阶段。LIKE和全文索引就够用。先别为了"AI"两个字上系统。加一套库的成本，比它带来的收益高。这笔账，得你自己算。还有一种容易忽略的情况。你的AI负载是离线批处理，夜里跑一次就行。跑完再把结果导回业务库。这种异步链路不要求跨库事务，硬拉进一个库，收益有限。

我自己的教训是，判断标准不在"先进不先进"。标准只有一个。向量和业务数据，是不是要在同一次查询里碰面。 要碰面，融合路线才划算。不碰面，分开跑也没什么不好。按上面三个维度往下走，候选就那么几类。只做纯向量检索，且能接受最终一致，专用向量库够用。向量要和业务一起查，还要事务和高可用，那就得看融合型。或者 AI 原生的数据库。

国内这块有个路线值得留意。电科金仓讲的是"双轮驱动"。一轮让数据库自己会调优、会预警。一轮给 AI 应用提供原生数据支持。落到具体能力上，KES V9 把关系、文档、图、时序、向量五类数据放在一库。向量和标量，同一条 SQL 就能一起查。

避坑清单：上 AI 数据库前先想清楚三件事

别把向量库当成 AI数据库。 它只是能力切片，不是整体。上手之前先问自己一句：需不需要事务，需不需要混合查询？想清楚这一点，选型方向就不会跑偏。

混合查询这条，我是踩了坑才当回事的。 语义检索和业务条件一起筛，才是真实场景。只在纯向量上做 POC，结论很容易是错的。我在自己电脑上跑 demo 时，数据量小、条件也简单。它压根没暴露问题。

索引算子这个坑，容易漏。 建索引和查询用的距离算子不一致，索引会静默失效。严重一点，直接退化成全表扫描。小数据量根本测不出来，得拿接近生产的规模压一轮才现形。

写在最后

复盘这次踩坑，我最大的收获很实在。我把"AI数据库"这四个字，从概念落到了实处。以前它是个词。现在它是一串具体的取舍。

它不是给数据库加一个 AI 的壳。多模态存储、混合检索、事务一致性，都放进同一套系统。内核智能也在其中。落到金仓身上，KES 把五类数据在一库统管。向量和标量都能原生混合查询。回到最开始那句判断标准：向量和业务数据要不要碰面？答案已经写在这套能力里。2026 年上半年，KES 通过了两项测试。一项是数据库管理系统智能化基础能力。另一项是融合型数据库基础能力。在行业内，通过这类权威测试的厂商并不多。所以再有人问我要碰面的场景选什么，我的答案很简单。我会先看金仓这类融合型。

如果你也在做 RAG 或者 AI 应用，欢迎在评论区聊聊。说说你踩过的坑。是切分的问题，还是检索链路的问题。也可能是我这种跨库的问题。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋