各位，我是老张。今天从一次实战出发，往下拆一层。
去年帮一家制造企业做设备知识库。业务数据在KES里，向量库单独部署。上线三个月，同步链路晚高峰延迟40分钟。运维要维护两套备份，两套权限。真正难受的是审计。同一份工艺文档，业务库有行级权限。向量库里却是一条裸记录。问题就出在数据出了库。
上周五电科金仓刚开完发布会。官方资料里有一组数。1亿条768维向量，98%召回率。峰值内存较业界降低95.4%，查询延迟降低80%。比数字更抓我的，是会上那句"数据不出库，AI也能用"。我第一反应不是惊叹。我想知道这句话落到架构上，到底改了哪几层。今天就从内存、延迟、安全、一致性四本账往下拆。
先说结论。库内向量检索，不是把向量塞进普通表。它让向量索引、过滤、权限、事务在同一个引擎里跑。省下的除了内存，还有跨系统同步和权限复刻的隐性成本。这也是"AI数据库"和"数据库外挂一个向量插件"的区别。
一、先算内存账，95.4%差在哪
做容量规划，我习惯先算原始数据。1亿条向量，每条768维。按float32存，每维4字节。一条就是3072字节。乘1亿，约307GB。这还只是原始向量，索引结构另算。HNSW每个节点要存邻居指针。M取16，底层最多32个邻居。光指针就接近128字节。1亿条再加约12.8GB。算到这儿，已经超过300GB。
独立向量库还有一笔账。业务数据要复制一份过去。原文、元数据、权限字段，都得再存。两份加起来，内存更吓人。很多项目不是算法跑不动。是容量评审这一关过不去。采购单上多出来的，都是真金白银。
python
# 粗算：1亿条768维向量的原始内存
n = 100_000_000
dim = 768
float32_bytes = 4
raw = n * dim * float32_bytes / 1000**3
print(f"原始向量: {raw:.1f} GB") # 约 307.2 GB
# HNSW 邻居指针粗算，M=16，底层最多 2M 个邻居
m = 16
graph = n * (2 * m) * 4 / 1000**3
print(f"图结构: {graph:.1f} GB") # 约 12.8 GB那95.4%怎么来的？按300多GB的盘子算，降95.4%只剩十几GB。光靠调ef_search，不可能。得动架构。先是不复制数据，向量和原文同库，省掉一份副本。再是压缩索引，float32换成分组量化，每维从4字节压到1字节甚至更少。最后是分层驻留，热数据放内存，冷数据放磁盘。这几件事叠在一起，方向上是数量级的变化。
| 方案 | 每向量占用 | 1亿条索引内存 | 数据副本 | 说明 |
|---|---|---|---|---|
| float32 + HNSW | 约3200字节 | 约320GB | 另存一份 | 传统独立向量库常见配置 |
| SQ8 + HNSW | 约896字节 | 约90GB | 另存一份 | 每维1字节，召回略降 |
| PQ96 + HNSW | 约224字节 | 约22GB | 同库不复制 | 分组量化，需重排补偿精度 |
| 库内 + 分层驻留 | 按热数据计 | 按热数据规模规划 | 同库不复制 | 冷数据落盘，按需加载 |
表里的数是我按通用架构做的估算，不代表产品规格。具体实现以官方文档为准，我这里只算架构账。但这四笔账，做容量规划时必须自己算一遍。95.4%不是调参调出来的。它是架构变化的结果。我吃过内存的亏。有次按均值做预算，采购单批下来，实际峰值翻了一倍。后来每次评审，我都要求看峰值，不看均值。
还有一个容易漏的点，索引构建峰值。HNSW建图时要维护临时候选集。内存可能是常驻的一点五倍甚至更高。容量规划只算常驻，构建峰值没算够，内存就会吃紧。这个坑我在两个项目里见过。所以看内存指标，一定要问清楚含不含构建。
二、再算延迟账，80%不是换硬件换来的
独立向量库的查询链路很长。应用先序列化查询向量。走网络到向量库。向量库返回topK。应用再拿ID回业务库过滤。最后拼prompt。四次跨进程，两次网络往返。每次RTT按1毫秒算，P99就多出好几毫秒。768个浮点数序列化，也不是零成本。
库内检索把链路压短了。过滤、向量、排序在同一个执行计划里。优化器能看统计信息，决定先过滤还是先向量。租户、时间、业务线这些条件，可以下推。分区裁剪也能用上。少一次网络，少一次序列化，少一次回表。延迟就是这么一点点省出来的。
text
独立向量库：
应用 → 网络 → 向量库(topK) → 应用过滤 → 业务库回表
库内检索：
应用 → SQL → 优化器(过滤+向量) → 存储引擎 → 结果
sql
-- 伪SQL，只表达执行顺序，具体语法以产品文档为准
SELECT id, title, chunk
FROM kb_document
WHERE tenant_id = :tenant
AND created_at >= :since
ORDER BY vector_distance(embedding, :query_vec)
LIMIT 10;这段SQL的关键不在写法。在WHERE和ORDER BY能不能进同一个计划。独立向量库通常先向量后过滤。topK里没几条符合条件，召回就崩。库内引擎可以先按条件裁剪，再在候选集里算距离。两条路谁快，要看选择率。过滤能筛掉九成，先过滤更稳。过滤很稀疏，先向量更稳。这个判断，应该交给优化器，不该写死在应用里。
| 环节 | 独立向量库 | 库内检索 | 差异来源 |
|---|---|---|---|
| 查询下发 | 网络往返 | 本地调用 | RTT与连接池 |
| 条件过滤 | 应用层二次过滤 | 计划内下推 | 选择率判断 |
| 结果回表 | 再查业务库 | 同事务内完成 | 一次跨系统调用 |
| 数据一致性 | 依赖同步链路 | 同库同事务 | 同步窗口 |
80%要看场景。数据量越大、跨系统环节越多，架构差异越容易显现。数据量小、同机部署，差距不会这么夸张。看性能数据，要连场景一起看。脱离召回率谈延迟，没有意义。
召回和延迟是一对跷跷板。ef_search每加一档，候选集就大一截。延迟涨得慢，召回涨得快。过了拐点，再涨延迟也换不回多少召回。参数得按场景定。线上先划一条召回底线，再压延迟。
三、安全账，数据出库那一刻权限就失效了
业务库里的权限，是一层层叠出来的。行级权限、列加密、脱敏视图、审计日志。数据一旦导出到向量库，这套东西要重建。重建还不一定建得全。向量库认识的是collection和API Key。它不认识你的组织架构。同一份工艺文档，在业务库只给工艺部看。到了向量库，可能变成一个谁都能查的接口。
更麻烦的是向量本身。Embedding不是匿名数据。它保留了原文的语义特征。攻击者拿到向量，可以做成员推断，也能做相似度反查。所以"把文本转成向量再出库"不等于脱敏。这句话我在评审会上说过很多次。真正安全的做法，是让原文、向量、权限待在同一个安全域里。
电科金仓这次发布会的口径，是"数据不出库，AI也能用"。三个能力里，有一个是库内原生数据安全管控。翻成工程语言，就是权限、审计、加密仍然作用在库内数据上。向量检索不绕过原有安全策略。金融、医疗、政务这类场景，过不了这一关，项目根本进不去。信创项目讲数据主权，最后也要落到这句话上。数据在哪，谁能看，出了事怎么查。
四、一致性账，向量和业务数据怎么一起更新
独立向量库最怕两件事。一是双写。业务库提交成功，向量库写失败。二是同步延迟。业务库已经改了，向量库还是旧值。用户问"最新版工艺参数"，系统答的是上一版。这类问题，靠重试补不回来。得靠对账和补偿。
库内方案把这件事收进事务里。业务行和向量列一起提交。WAL先落盘，索引再更新。MVCC保证读到的是一致版本。代价也有。向量索引维护比普通B树重。HNSW插入要算邻居，删除多是标记。更新频繁的表，索引膨胀会更快。这是ANN索引的共性，独立向量库也一样。这些成本要提前算，不能只看查询快。
删除比插入更麻烦。HNSW的删除多是标记，空间不会立刻释放。更新频繁的表，要定期重建或合并。这类维护成本，独立向量库也一样有。选型时要把重建窗口算进去。
如果确实要跨库，也有折中。金仓异构数据同步软件（Kingbase FlySync）负责增量同步，把变更送到目标库。跨库链路要把监控和对账做足。能在库内闭环，运维会更简单。这是我做架构评审时的默认顺序。先问能不能不拆，再问拆了怎么保证一致。
五、发布会数据怎么读，别只盯两个百分比
发布会给了一组数。1亿条768维向量。98%召回率。峰值内存较业界降低95.4%。查询延迟降低80%。这组数来自发布会公开口径，不是我个人实测。这几个条件要连起来读。98%召回是前提。离开召回谈内存和延迟，数字没有可比性。把ef_search调低，延迟马上降，召回也跟着掉。同召回、同硬件、同过滤条件下比，才有意义。
我读性能数据，固定看五个口径。召回率是 recall@10 还是 recall@100？延迟是单条还是并发下的P99？内存报的是峰值还是常驻？含不含索引构建？有没有过滤条件？五个问题问完，数据能不能信，基本就有数了。
| 读取项 | 要确认的口径 | 为什么重要 |
|---|---|---|
| 召回率 | recall@K，K取多少 | 不同K不可直接比 |
| 延迟 | P50/P99，并发数 | 平均值掩盖长尾 |
| 内存 | 峰值/常驻，含不含构建 | 峰值决定采购 |
| 数据规模 | 向量条数、维度、过滤比例 | 规模变了结论会变 |
| 对比基线 | 同硬件、同召回、同过滤 | 不同口径不可比 |
发布会还提到这次发布的重点，是金仓AI数据库。三大核心能力：库内语义构建、库内计算推理。再加上库内原生数据安全管控。这三句话对应的，正是前面四本账。语义构建解决"模型看不懂业务"。计算推理解决"数据搬来搬去"。安全管控解决"出库即失控"。三件事落在同一个引擎里，才叫AI数据库。只加一个向量字段，再外挂一个模型接口，不叫。
六、选型框架，什么场景该走库内
库内更适合核心业务数据。我一般按三个问题判断。数据在哪，权限多严，规模多大。数据已经在关系库，权限复杂，要求强一致，库内更合适。十亿级以上、多模态场景，先把容量和召回验证清楚。运维边界摸清了，再决定拆不拆。中间地带，可以做混合。热数据放库内，冷数据放外部。但混合架构的运维成本，要提前算进去。
多租户SaaS还要多看一眼。租户隔离、配额、统计信息，库内能复用现成机制。独立向量库要另做一套。租户上千以后，过滤条件会更绕。这部分要提前压测，别等上线再调。
| 维度 | 库内向量检索 | 独立向量库 |
|---|---|---|
| 数据位置 | 与业务数据同库 | 单独复制一份 |
| 权限模型 | 复用库内权限与审计 | 需重建 |
| 一致性 | 同事务，强一致 | 依赖同步链路 |
| 混合过滤 | 优化器统一决策 | 应用层拼接 |
| 运维成本 | 一套系统 | 两套系统加一条链路 |
| 适合场景 | 核心业务数据、强合规、强一致 | 多模态、独立团队、跨源聚合 |
我的判断顺序是这样。先看数据能不能不出库。能，就优先库内。不能，再评估同步链路能不能扛住延迟和故障。最后才比QPS和单价。顺序反了，容易先买一堆机器，再回头补权限和一致性。
七、几条实操提醒
第一条，容量按峰值算，别按均值。峰值一上来，机器就得加。索引构建那一刻，内存还要再高出一截。这块漏算，规划就白做。
第二条，权限和一致性，出库前就要想清楚。向量库不认识你的组织架构，权限得重建。同步链路不做对账，延迟和丢数早晚会来。这两件事留到上线后补，代价要翻倍。
第三条，召回先达标，再谈延迟。有次为了压延迟，我把ef_search从100调到40。QPS翻了一倍，召回掉到78%。业务方拿着badcase找了我两周。后来我定了规矩，顺序不能反。
八、写在最后
"AI数据库用金仓"这句话，技术含义可以拆成一句。AI能力进库，数据不出库。库内语义构建，让模型读懂业务。库内计算推理，让数据少搬家。库内原生安全管控，让权限不失效。三件事合在一起，才是这次发布会真正想讲的东西。不是给数据库加个向量字段，再外挂一个模型接口。
金仓这些年在KES上积累了事务、权限、审计能力。这些正好是AI应用缺的底座。发电、医疗这些关键行业，金仓已经长期落地。这也说明底座扛得住生产。信创场景要自主可控，也要数据主权。最后都要落到一句：数据在哪、谁能看、出了事怎么查。选型别追概念，先回答三个问题。数据在哪，权限多严，规模多大。答完再决定向量索引放哪。多数团队的核心数据已经在关系库里。选库内，能少一整条同步链路。
各位，你们现在的RAG，向量库是独立部署还是库内？踩过哪些同步和权限的坑？评论区聊聊。
我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。