知识库里的一条报销规定改了,客服机器人还在按旧的答。查下去,关系表里的正文确实已经更新,向量那边还排在 embedding 队列里,没轮到。

这类问题不报错,也不触发告警,它只是答得不对。等业务方反馈回来,链路早跑过好几轮了。

根子不在 embedding 快慢,在库的数量上。一个中等规模的 RAG 项目,库通常是这么长起来的:先有业务库,存工单和用户;上 RAG,加一个向量库;原文和元数据塞不进向量库,再加文档库;后来业务要按门店位置筛,加空间库;设备数据进来,加时序库。库与库之间用 ETL、CDC,或者干脆一句"定时脚本"连着。

上面那条答错的规定,就是从其中一根连线上漏下去的。

一、烟囱各自冒烟,代价藏在缝隙里

这种各建一套、互不相通的架构,行业里习惯叫"烟囱式"。它的问题不在任何一根烟囱本身,而在烟囱之间。

同步延迟是第一笔账。 一条知识库记录改了正文,关系表里的 updated_at 立刻变了,但向量要等下一轮 embedding 任务跑完才更新。中间这段窗口——快的十几分钟,慢的几个小时——用户问出来的答案是旧的。更麻烦的是这种错误不报警,它只是"答得不太对",等业务方反馈回来,链路早就跑过好几轮了。

一致性是第二笔账。 市面上大多数专用向量数据库出身于 NoSQL,没有事务能力。写关系表成功、写向量失败,这个组合没有回滚可言。于是团队开始写补偿逻辑、写对账脚本、写"每天凌晨三点全量校验"的定时任务。这些代码不产出任何业务价值,但一旦漏掉一个分支,数据就悄悄歪了。

混合过滤是第三笔账,也是最容易被低估的一笔。 业务上真正的问题从来不是"找相似的向量",而是"在华东区、近 30 天、状态为已结案的记录里,找语义相似的"。向量在一套系统,标量条件在另一套系统,只剩两种做法:先在向量库里粗召回一万条再回关系库过滤,或者先在关系库里筛出候选 ID 再拿去向量库比对。前者召回率虚高、延迟难看,后者候选集一大就退化成暴力扫描。工程上怎么调都是在两头亏。

剩下的是运维那笔账。 三套备份策略、三套高可用方案、三套权限模型、三套审计日志。出故障时第一件事不是修,是判断故障在哪一层。安全评审要过三遍,合规资质要备三份。DBA 看不懂 HNSW 的 ef_construction 该调多少,算法工程师不关心 WAL 和 RPO,中间那段没人负责的地带,通常就是事故的发源地。

这些成本单看每一项都不大,加在一起就是架构复杂度。而架构复杂度的特点是,它不会随业务增长线性上升,是按连接数平方上升的。

二、换个思路:向量本来就该是一种数据类型

电科金仓在 KingbaseES 上的做法,是不给向量单独立门户,而是把它放回数据模型层,和关系模型、文档模型、GIS 模型、KV 模型、图模型并排。

这个排布不是 PPT 上的美化。往上,应用场景层的 OLTP、OLAP、HTAP、时序和 RAG 共用同一套入口;中间,语言层统一走 SQL 标准,并兼容 Oracle、MySQL、SQL Server、DB2 等多种语法体系;往下,实例与集群架构层是同一套主备、读写分离、共享存储多写、无共享分布式和跨多云多地部署能力。也就是说,向量数据从写入的那一刻起,走的就是和订单表一样的事务、一样的日志、一样的备份链路、一样的权限和审计。

金仓官方把这套结构称作"AI 时代的融合数据库架构",列了五个一体化层次:多语法体系一体化兼容、集中分布一体化架构、多应用场景一体化处理、多模数据一体化存储、开发运维一体化管理。其中和本文关系最直接的是第三、第四条,原文写得很直白——结构化数据的存算问题在关系库框架内解决,库内计算,减少数据传递;收敛技术栈,降低应用复杂度和成本,减少库间数据同步,降低同步开销。

向量能力本身以组件形式(KES_Vector)接入内核,复用 KES 已有的能力和生态,应用侧仍然用熟悉的 SQL 写查询。

三、一条 SQL 能干多少事

抽象讲"一体化"没什么说服力,金仓自己给的一个交通场景的例子倒是相当具体。

需求是:查询某市过去 30 天内,与"雨天 + 分支道路 + 追尾"形式相似的交通事故频发(至少 3 次)的 5 个热点区域,返回事故数量、事故详情、最早和最晚发生时间,以及与预期特征的平均相似度。

这个需求拆开来是四种数据模型的活:

• 某市热点区域的地理范围和网格划分——GIS 数据模型;
• "雨天 + 分支道路 + 追尾"这组特征的相似度检索——向量数据模型(事故特征编码成 3 维向量,天气、道路类型、事故类型各占一维);
• 区域内各事故详情的聚合——文档数据模型;
• 频次统计与排序——关系模型的常规操作。

在烟囱式架构里,这是一条跨三个系统、至少两轮数据搬运的流水线。在 KES 里,它是一条 SQL:用 ST_Contains 和 ST_Within 圈定行政区范围,用 <=> 算事故特征向量与 '[1,2,3]' 的距离并加上 < 0.5 的阈值,用 json_agg 把详情聚成文档,最后 GROUP BY 区域、HAVING COUNT(*) > 3、按事故数倒序取 5 条。

GIS 计算、向量计算、文档处理、分组排序,全部发生在库内。中间没有一个字节被搬出去过。

这就是"少搬一次数据"最朴素的形态——不是省了多少带宽,是省掉了一整条需要有人维护、有人值班、有人对账的链路。

四、向量本身的功课

融合架构成立的前提,是向量能力本身别拖后腿。KES 向量组件的清单大致是这样:

数据类型上,稠密向量支持单精度(float32)和半精度(float16),同时支持稀疏向量和二进制位向量。稠密向量最大存储维度 16,000;稀疏向量支持 16,000 个非零元素;二进制向量的存储上限是 83,886,080。索引维度受 8K 页面限制:FP32 到 2,000 维,FP16 到 4,000 维,二进制向量到 64,000 维,稀疏向量 1,000 个非零元素——注意这个限制只作用于索引,表里存储没有这道坎。

度量方式上,L2 欧氏距离、内积、余弦距离、L1 曼哈顿距离、汉明距离和杰卡德距离,六种全支持,并且每一种都配了对应的操作符。作为对照,关系型数据库里支持向量的标杆产品 Oracle 23ai 提供五种距离运算、三种操作符。

索引上,IVF_Flat 和 HNSW 都是金仓自主实现的,加入了 x64 SIMD 加速。这里有个容易被忽略但工程上很要命的差异:KES 在建立向量索引后,依然支持新向量的插入与删除,而 Oracle 23ai 建好 HNSW 索引后不支持增删。对于知识库天天更新的场景,后者意味着要么定期重建索引,要么忍受索引与数据脱节。

两种索引怎么选,官方给的判断依据也不绕弯:内存紧张选 IVFFLAT,它只存聚类质心和聚类内的向量列表,代价是搜索速度和准确性;追求高维空间下的检索速度和召回率选 HNSW,代价是更高的内存占用和更慢的索引构建——尤其在 ef_construction 设得比较高的时候。

此外还有一些不那么显眼但用起来很省事的能力:向量支持 +、-、* 和拼接运算,支持正则化、切片、取模、取维度数等函数,支持 AVG、SUM 等聚合函数,可以用表达式索引来索引子向量,可以和浮点数组、整型数组互转,还能作为等值和大小比较的 key(这一条 Oracle 23ai 不支持)。性能口径上,官方给的数字是亿级向量毫秒级召回、索引性能领先友商 20%。

也有短板,值得直说:目前 KES_Vector 不支持 GPU 加速。金仓把它放进了后续规划,同期规划里还有自主实现新的索引方法、优化已有索引性能、新增向量类型和计算函数。对于大部分企业级 RAG 和检索场景,CPU + SIMD 够用;但如果你的场景是超大规模离线向量训练,这一点需要提前算进去。

五、什么时候不该选融合路线

把话说全:融合不是万灵药。

如果场景是纯向量、规模在百亿以上、几乎没有标量过滤需求、也不需要事务保证,那么专用向量数据库在纯检索性能上仍然领先,这一点金仓自己的对比材料里也承认了——只是补了一句,通过内核优化,KES 在中等向量规模场景可以接近甚至超越专用库。

融合路线的价值集中在"混合"两个字上。你的查询条件里标量、地理、时间、文档占的比重越大,数据一致性要求越严,合规审计要求越高,这条路的收益就越明显;反过来,如果整个系统就只有向量这一件事,分开部署也没什么不好。

所以真正该先问的不是"融合好还是专用好",是"我的查询条件里,有多少条不是向量"。

六、顺带说一句标准

这个领域目前没有国际标准,而且短期内也不太会有。原因不复杂:向量数据库压根没有统一的产品形态——NoSQL 的、SQL 的、OLTP 的、OLAP 的、搜索引擎出身的都在往里加向量能力,其中有些(比如 ElasticSearch)严格说都不算数据库。没有国际标准,反而如实反映了市场的实际状况。

国内是电子四院牵头组织制定了一份向量数据库标准,参与方包括百度、腾讯、阿里、爱可生和金仓等,内容已经讨论确定,也有厂商参与了测试。金仓自己对这份标准的评价挺克制:得到了四院背书,但缺少该领域标杆厂商参与,改变不了产品形态多样、难以统一的现实;标准内容偏宽泛,除多向量查询外基本覆盖了通用向量数据库应具备的能力,可以作为设计参考;由于只能作概念性定义,各厂商实现自由度很大,市场碎片化短期内解决不了。

对采购方的含义很实在:别看标签,看能力清单。同样自称"支持向量检索",有的是完整的事务、混合查询和高可用体系,有的只是加了个相似度函数。

七、这笔账自己算

判断这条路适不适合,不用看厂商的架构图,看你自己那张。把库数一遍,再把库之间的连线数一遍。每条连线背后都对应一个同步任务、一套告警规则,和一个"数据对不上时找谁"的答案。第三项要是答不上来,那根线就是隐患。

KES 做的事情说穿了不复杂:把向量、文档、GIS、时序收回同一个内核,共享同一套事务、集群和安全体系,让跨模型的关联发生在库内,而不是链路上。它不承诺每个单项指标都最快,换来的是连线变少。

至于连线少几根值多少钱,每家的数不一样,得自己算。