KES AI資料庫：1億條向量的峯值記憶體開銷降低95.4%，庫內AI與庫外拼裝有何不同

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

前几天看到电科金仓发布会的直播。今年的主题叫“Hello，AI数据库”。北京现场坐了几百人，线上还有很多人在看。弹幕刷得最多的一句，是“数据不出库，AI也能用”。我看完的第一反应不是激动，是想弄明白。这句话要成立，技术上到底补了什么？

我帮人搭过知识问答，也做过向量检索的活。数据出库这件事，我吃过亏。所以这篇不写通稿，只写我关心的三个问题。痛点是不是真的，能力到底怎么落进库里。企业真要上，得先想清楚什么。

先把话说清楚：什么叫“数据不出库”

AI数据库，是把语义、推理、安全三类能力放进内核。数据不必搬出库，就能支撑AI应用。 关键词是“库内”。库内做语义，库内做推理，库内做管控。我按这个标准去看发布会，才没被概念带跑。

它和“数据库外挂一个向量库”是两回事。后者我也搭过。业务数据在一边，向量在另一边，中间靠ETL和接口连着。能跑，但账要另算。

发布会上，杜胜总裁把企业落地AI的痛点归了三类。业务语义缺失、数据流转成本高、出库后安全失控。这三个词写得克制。我一条条对，都对得上自己的经历。

痛点一：模型不懂你的业务

大模型看表，只看到字段名。它不知道“有效订单”要排除测试单。也不知道“复购率”按什么口径算。这些知识在人脑里，在文档里，就是不在SQL里。我以前的做法，是把口径写成提示词。写得再长，模型还是会猜。

语义这东西，散落在表注释、指标文档、老员工记忆里。谁维护、放哪儿、怎么和大模型对齐？这是库外方案解决不了的。发布会说金仓在库内做语义构建。我特意记了一下。这是我认为最见功夫的一块。

痛点二：数据搬来搬去，账单跟着搬

做过RAG的都知道，一条数据要出库、切分、向量化。然后写进另一个系统。业务表更新了，向量还得跟着更新。增量同步漏一条，问答就答旧数据。我见过一个项目，光同步链路就维护了三套。

搬运的代价不只是工程。多一份存储，多一层延迟，多一个故障点。夜里告警一响，你分不清是谁的锅。是业务库的问题，还是同步链路的问题。补数据更麻烦。业务库补一遍，向量库还得补一遍。两边对不上，只能重灌。

痛点三：出了库，权限就管不住了

这个最扎心。数据在库里，行级权限、列级脱敏、审计日志都是现成的。一旦导出去做向量化，这些控制基本失效。向量库里躺着原文切片。谁能查、查过什么，未必说得清。

金融、医疗这类行业，数据出库要走审批。审批一次两次还行。天天走，业务就停了。所以“不出库”不是宣传点。它是很多企业敢不敢用AI的前提。

库外拼装和库内AI，差在哪张表上

我把两种做法按自己最关心的五个维度列了张表。这不是选型结论，是判断“库内”含金量的尺子。横着看是方案差异，竖着看是你要承担的活。先看结构，再看数字。

表格右边那一列，是发布会公布的产品设计。我没在生产环境验证过，这点得说在前面。左边那一列，是我真金白银踩出来的。两边对照着看，能看出这套设计想解决什么。

三个能力，我逐条掂量了一下

发布会把KES AI数据库的能力拆成三块。库内语义构建、库内计算推理、库内生安全管控。名字有点技术味，我翻译成自己的话。翻完你会发现，三块其实是一件事的三个面。

库内语义构建，是让数据库说清字段的业务含义。表结构、指标口径、实体关系，都在库里定义。模型来查数，先读语义，再生成SQL。这一步做扎实，答非所问能少一大半。

库内计算推理，是把向量化和相似度计算放在库内做。数据不用导出。索引和业务表在同一个实例里。写一条数据，向量和业务字段同时落库。不存在“同步漏了”这种事。对实时问答的场景，这点很实际。链路短了，出错的地方也少了。

库内生安全管控，是权限跟着数据走。行级权限、列级脱敏照旧生效。审计日志记的是库内操作，不是某个中间件的行为。合规的同学听到这里，一般会松口气。

发布会上给了一组实测数据。我整理成一张小表。数字比形容词有说服力，条件也写得明白。看完表，再看它和你的场景差多远。

这是发布会公布的实测条件，我没复测。我的建议是，把这组数字当成一个公开基准。上线前用自己的数据分布和查询场景再压一遍。条件对得越齐，参考价值越大。

一段伪代码，看看“库内”省了什么

发布会没给具体语法。我按库内检索的思路写个示意，不代表真实接口。语法以官方文档为准，这里只看结构。重点看WHERE和ORDER BY放在一起。

-- 示意：库内混合检索，向量与业务条件一次查询
SELECT doc_id, title, score
FROM   knowledge_docs
WHERE  tenant_id = :tenant          -- 行级权限在库内生效
  AND  status = 'published'
ORDER BY embedding <-> :query_vec   -- 向量计算在库内完成
LIMIT  10;

注意WHERE里那行tenant_id。库外方案里，这行过滤往往发生在应用层。过滤和检索一分开，召回就可能跑偏。库内方案把两件事放进同一条SQL。少一层拼接，少一类bug。

发布会另一半：口号、生态和人

产品之外的信息，我更看重它透露的方向。新Slogan换了。从“数据库平替用金仓”，到“AI数据库用金仓”。平替讲的是替代，AI讲的是定义。金仓同时启动了全球化战略。国产数据库出海，前几年多是项目制。现在把“定义下一代数据库”写进发布会。这份底气，是明摆着的。

金兰组织这次发布了联合解决方案。成员超过700家，覆盖金融、能源、医疗、政务、交通。生态单看数字没感觉。落到具体场景，才有分量。

现场三位合作伙伴的分享，我记了三个细节。德索信息讲期货核心系统迁移。关键词是“性能不降级、业务零中断”。核心系统敢说零中断，背后得有真实的切换记录。东华医为讲医疗全链路适配。ICO Limited讲香港落地，这是出海的第一手样本。

三大赛事的颁奖也在同一天。大学生计算机设计大赛来了412所院校、2100多名师生。智能运维工具开发大赛设了八大赛道。KES诊断、巡检、SQL优化都在里面。征文大赛收的是一线经验。一个厂商肯在人才和社区上长期投入。这通常说明，它打算长期干这件事。

市场数据也报了。发电行业销量第一。医疗行业连续三年第一。关键领域六年销售套数第一。这些是发布会公布的市场成绩。我更看重另一件事：它把客户请到台上讲细节。

真要上AI数据库，先问自己三个问题

发布会看完，我把判断收敛成三个问题。准备上AI应用的企业，可以拿去问供应商，也可以问自己。问题不复杂，答案不一定好答。我把它们写在下面，顺序就是优先级。

第一，数据能不能出库？监管不允许，库外方案第一天就走不通。这不是技术选型，是合规的前置条件。过不了这一关，后面都是空谈。

第二，语义层谁来维护，放在哪？口径会变，业务会调。语义散在提示词里，每次变更都是一次事故。放库内，至少有个统一的落点。

第三，权限是不是原生的？让安全团队评审时问一句。向量数据的行级权限怎么控制？答不上来的方案，先放一放。三个问题没有标准答案。问完，方案合不合适，基本就清楚了。

上线前值得注意的三个要点

先说第一个。向量检索是AI数据库的入口，不是全部。语义、权限、事务，才决定它能不能进核心业务。选型时别只看“能不能搜”，要看“搜完能不能管”。

第二个，性能数字要放回自己的场景里看。95.4%和80%是发布会的实测结果，条件写得明白。你的数据分布、查询模式未必一样。上线前拿真实SQL压一遍，比什么都实在。

还有一个，是我自己踩过的。当年我把召回做到98%，用户还是说“答非所问”。后来才想明白，问题在语义定义没跟上业务口径。检索找对了文档，模型读错了意思。所以我现在看AI数据库，先看语义怎么定义。再看检索怎么跑。

写在最后

发布会我看了两个小时，记了十几条。最后留下来的，就一句话。AI数据库的竞争，不在谁家向量索引快。在谁家敢把语义和安全一起接进内核。金仓这次把能力落进了内核。接下来，看它在更多行业场景里跑出结果。你们公司准备上AI应用吗？数据是留在库里，还是搬出去另建一套？评论区聊聊。

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