向量数据库从相似度检索走向融合数据底座
@toc
我头一回把向量检索接进咱们业务系统的时候啊，其实原以为难点仅仅是选个索引就完事了。后来才发现，根本不是这么回事。向量数据库真正难的地方，是把"相似"给变成"有用"。两段文本在语义上看着挺近，这并不等于它们就适合拿来回答当前的问题。两张图片的特征很接近，也不等于它们就是同一个业务对象。你要是想让 AI 在企业层级里的场景中给出靠谱的结果。那么向量这个东西啊，还得跟关系属性、文档内容、空间位置、时间的变化，还有权限的边界，这些东西都得放在一起去理解才行。
这也是我后来开始去关注金仓向量数据库的一个原因。向量数据库啊，它不应该变成关系数据库之外的又一座孤岛。金仓 KES 搞的那个 AI 时代的融合数据库架构，它强调的是什么呢？是在同一个数据底座里面，去处理关系数据、文档数据、向量数据，还有 GIS 和时序这些模型。它真正的价值，并不是说把所有数据都硬生生地变成向量。而是说，让向量检索能够在真实业务数据的旁边去干活。这样的话，就能减少好几套数据库之间那种反反复复的同步和拼接的情况。
在这条链路里面啊，向量检索往往仅仅只是负责去找相似的内容。那么过滤呢，还有版本的校验和权限的判断，这些才决定了哪些内容是允许被塞进上下文里面的。我为什么要把这几步给画出来呢？其实就是为了提醒一下自己，千万别把 RAG 给简化成一个 top k 的查询了。
一、为什么只搭向量库还不够
传统 AI 架构里面，咱们常见的一种做法是这样的。就是说，关系数据库去存业务数据。文档库呢，去存那些知识文档。向量数据库里面存 embedding。缓存数据库负责处理那些热点的结果。接着呢，应用层再用 ETL 或者接口，把这些数据给拼到一块儿。你单看每一个组件的话，好像都挺合理的。但是呢，系统一旦变得复杂了，问题马上就显现出来了。 
首先是同步延迟的问题。文档刚刚更新了，但是向量还没有重新生成出来。业务记录已经变了，向量库里面的元数据却还是老值。模型检索出来的内容啊，可能"看着挺相关的"，但它并不是当前有效的状态。其次呢，是一致性的问题。应用在好几个系统里面分别去写数据。任何一个环节要是挂了，都可能留下一个半成功的那种状态。再次，就是权限的问题了。用户在关系库里面明明没权去看某条记录。但是向量库呢，却把跟它相关的片段给返回来了。这时候应用就必须得额外去做一层过滤。稍微一疏忽，就可能造成越权的情况。
还有就是运维的复杂度。多套数据库啊，这就意味着你得去搞好多套的备份、监控、扩容、升级，还有出了故障怎么去恢复的流程。AI 应用越是往生产环境里面走，你就越不能光盯着检索的速度看。你还得关心什么呢？关心数据到底从哪儿来的，什么时候更新的，谁可以去读，怎么去审计，还有出了问题怎么回退。
所以说啊，我理解的融合数据库，它不是那种"一个数据库包打天下"的口号。它其实是让不同的模型，在一个统一的治理边界里面去协同干活。关系模型嘛，去负责那些结构化的业务事实。文档模型呢，去保留那些非结构化的内容。向量模型去负责相似性的检索。GIS 和时序模型，分别去表达位置和变化。模型虽然不一样，但是呢，数据的生命周期、权限，还有关联关系，这些是可以被统一管理起来的。
二、向量数据到底解决什么问题
文本啊、图片啊、音频还有视频这些东西，本身是不太容易直接拿去比较的。嵌入模型可以把它们给转换成高维的向量。这个向量的每一个维度啊，其实就代表了原始内容里面的某些特征。语义上比较相近的内容，在向量空间里面的距离呢，通常来说也会更近一点。那么向量数据库要做的最核心的工作是什么呢？就是把这些向量给高效地存起来。然后在给定一个查询向量的时候，能从中找出最相近的那几条记录。
这类查询啊，通常来说有两种方式。精确最近邻检索呢，它会挨个去计算距离。结果是很准的，但是数据量一大，计算的成本就很高了。近似最近邻检索呢，它是借助索引把搜索的范围给缩小。牺牲了一部分计算路径，换来的是更快的速度。金仓向量组件的资料里面提到，它支持精确检索，还有像 IVFFlat、HNSW 这种近似检索的索引。同时还支持好几种向量类型和距离度量的方式。不同的索引啊，在内存占用、速度还有召回率上面，都是有取舍的。你不能简单地觉得，某一种索引在所有业务里面就一定是最好的。
向量检索要是真想给业务服好务啊，还得把向量对应的原始对象标识给存下来。还有它的来源、版本、权限、时间，还有业务的标签，这些都得有。向量呢，它仅仅只是一种表示而已，它是不能替代原始事实的。一个靠谱的检索结果啊，它至少得能够顺着找回到业务记录那边去。去核对一下最新的状态。然后再根据用户的权限，来决定到底能不能把这个结果展示出来。 
三、一个可落地的 RAG 数据结构
咱们拿企业层级里的知识问答来举个例。我会把文档切分、向量化，还有业务的元数据，都放在同一个治理的边界里面。下面这个啊，是一个简化了的结构示例。里面的字段和类型呢，仅仅只是用来解释一下设计的思路。实际上的语法啊，你还是得去看目标版本文档里面怎么写的。
sql
CREATE TABLE knowledge_chunks (
chunk_id BIGINT PRIMARY KEY,
document_id BIGINT NOT NULL,
content TEXT NOT NULL,
embedding VECTOR(768),
department_id INTEGER,
document_time TIMESTAMPTZ,
access_level INTEGER,
version_no INTEGER NOT NULL,
updated_at TIMESTAMPTZ NOT NULL
);
CREATE INDEX knowledge_chunks_embedding_idx
ON knowledge_chunks USING hnsw (embedding);
SELECT chunk_id, document_id, content, version_no
FROM knowledge_chunks
WHERE department_id = 10
AND access_level <= 2
ORDER BY embedding <=> :query_embedding
LIMIT 8;在这个例子里面啊，你可以看到，向量相似度它仅仅只是排序条件里面的一个。部门和访问级别呢，它们是属于结构化的过滤条件。版本和更新的时间，是用来确认这个内容到底新不新鲜的。在真实的应用里面啊，你还得在召回之后去做重排、去重、引用的拼接，还有敏感信息的过滤。只有把向量检索给塞进这条完整的链路里面，RAG 才不容易变成那种情况，就是说"找着了相似的句子，但是给出的回答还是不靠谱"。
KES 向量组件是基于 KES 的能力和生态的。它用扩展的方式，给你提供了向量的存储、计算还有查询。而且呢，它还能跟你已有的数据类型混在一起去查。对于写代码的人来说呢，用自己熟悉的 SQL 去管理向量和关系数据，这就能帮你少搞一些新的访问层，还有数据同步的服务。对于运维的兄弟们来说呢，实例、集群、权限、备份还有审计这些都统一了。也能把因为系统数量太多而带来的那种管理压力给降下来。
一次增量更新应该怎样走
这里面的顺序啊，其实是非常关键的。你得先把新版本给写完整了，接着再去把旧版本给标记成失效。为什么要这么做呢？因为这样的话，就算向量生成的时候挂了，或者索引维护的时候出了错。在线的检索呢，依然有机会去继续用那个旧版本。就不会出现那种情况，就是文档都已经发布了，但是知识库里面却找不到能用内容的这种空窗期。
四、向量索引不能脱离业务指标选择
IVFFlat 和 HNSW 啊，它们俩都属于近似检索的方法。但是呢，它们适用的侧重点是不一样的。IVFFlat 通常来说更关注分区还有搜索的范围，内存的占用相对来说比较好控。HNSW 它是基于图结构的，常常能给你提供比较好的检索速度和召回率。但是呢，它构建索引的时候还有内存的开销，你得认真去评估一下才行。资料里面还提到了不同的向量类型、精确检索，还有好几种距离度量的能力。这就意味着什么呢？意味着你选索引的时候，得跟你用的 embedding 模型、向量的维度、数据量有多大、更新得有多频繁，还有业务能容忍到什么程度，这些东西都得放在一起来决定。 
我一般会先去定四个指标。就是召回率、P95 延迟、更新可见的时间，还有资源的成本。如果是做问答的场景啊，可能你得更看重召回率还有引用到底可不可信。如果是做推荐的场景呢，可能就更看重延迟了。要是知识库更新得特别频繁，那你还得盯着看，新增的向量到底什么时候能被稳定地检索到。测试的时候啊，你千万别光拿几十条样例数据去跑。应该用那种接近生产环境分布的数据。而且还得把短文本、长文本、相似的问题、权限的过滤，还有高并发这些情况都给覆盖到。
索引建好之后啊，你也不能就不管它了。文档一直在更新，这就会带来新增还有删除的操作。旧版本要是没有去清理掉的话，检索出来的结果就会重复，还会出现过期的东西。知识库里面呢，还得有版本的状态。比如说什么是草稿，什么是已发布，什么是已废弃。然后在查询条件里面，得明确写上只去召回那些有效的版本。向量数据库它能给你提供底层的能力。但是呢，内容怎么治理、切分的策略是什么、更新的流程怎么走，这些依然得靠业务团队自己来负责。
五、把向量与关系、文档、GIS、时序放在一起
在企业里面啊，真正的问题很少是只问一句"哪段文本最相似"的。搞设备运维的人可能就会这么问："最近一个星期里面，出现过类似振动曲线的设备都有哪些？它们是不是在同一个园区里面？最近三个月有没有修过？"你看，这个问题里面，其实同时包含了时序的条件、向量的条件、关系的条件，还有空间的条件。
如果这些数据散落在好几个系统里面。那应用就得先去查设备档案，接着去查时序库，然后再去做向量检索。最后呢，还得在代码里面把这些结果给拼起来。这里面每一步啊，都存在着权限的问题、延迟的问题，还有失败的风险。融合数据库的思路是什么呢？就是尽量让这些模型，在统一的底座里面去把过滤和关联给做完。让一次分析啊，更接近业务问题最自然的那个表达方式。 
当然了，这并不代表说所有的计算都得硬塞到数据库里面去完成。也不代表说，模型的服务就能被数据库给替代掉了。像 Embedding 的生成、模型的推理，还有复杂的重排，这些往往还是需要专门的 AI 服务去干的。数据库呢，它其实更适合去承担数据的存储、索引、过滤、关联，还有事务、安全和可以审计的这些职责。分工要是搞清楚了，系统反而会跑得更稳当。
六、MCP 让 AI 操作数据库，但安全边界必须先建立
向量数据库还有融合数据库啊，还有另外一个趋势。就是让开发工具或者智能体，直接去调用数据库的能力。 KES MCP Server提供了一些标准的工具。比如探索数据库的结构、查 SQL、看执行计划，还有检查状态什么的。它可以在 TRAE、Cursor 这些有 MCP 能力的开发工具里面去用。它把以前那种需要人工去查、去复制、去解释的操作，给连成了一种更自然的交互流程。
这种方式啊，确实能把开发和运维的效率给提上去。打个比方，开发者可以让工具去看某张表的结构和索引。然后让它生成一条分析的 SQL。接着再根据执行计划，去判断一下还有没有优化的空间。资料里面还特别强调了权限的控制、参数的检查，还有 Restricted 这种模式。这些设计其实是非常重要的。AI 能够生成 SQL，这并不代表它就应该拥有那种没有限制的写权限啊。AI 能看到某张表，也不代表它就能看到这张表里面所有的敏感字段。
我一般会把这个 MCP 的接入给分成三层。第一层呢，是只读的探索。就是允许它去看看结构、索引还有统计信息。第二层，是受控的分析。就是允许它去执行查询，但是得有超时的限制，有返回行数的限制，还有资源的限制。第三层，才是真正的变更操作。而且这一层啊，必须得经过显式的审批，得有审计，还得能回退。在生产环境里面啊，我建议你优先去用那种受限的访问模式。连数据库的账号呢，一定要遵循最小权限的原则。所有的 SQL、是谁调用的，还有返回了多大的范围，这些都得留底。
| MCP 操作层 | 默认权限 | 适合做什么 | 必须限制什么 |
|---|---|---|---|
| 结构探索 | 只读 | 看表、列、索引、约束 | 隐藏敏感字段和凭据 |
| 受控分析 | 只读查询 | 执行计划、慢查询、数据质量检查 | 超时、返回行数、资源消耗 |
| 变更操作 | 显式审批 | 建索引、调整参数、执行变更 | 审批、审计、回退和窗口 |
七、从"有向量"到"能落地"的检查清单
第一点啊，你得搞清楚向量到底是哪个模型生成的，是哪个版本。模型要是变了，你怎么去重建。
第二点，原始数据得留着，对象标识得留着，业务的元数据也得留着。你不能就光存一串向量在那儿。
第三点，权限啊、版本啊、更新的时间啊，这些结构化的条件，你得把它们给塞进检索的流程里面去。
第四点，针对数据量有多大、更新得有多频繁、召回率要多少，去选你的索引。而且得用生产级别的样本去压测。
第五点，过期的数据怎么清理，失败了怎么重试，重复的文档怎么去重，还有索引怎么维护，这些机制你得建起来。
第六点，AI 服务、数据库还有 MCP 工具，它们的权限边界你得分开去设计。千万别为了"调起来方便"，就把数据库的权限给扩大了。
咱们回到最开始的那个问题。向量数据库的价值啊，其实不仅仅只是算一个相似度。它是 AI 应用去连企业数据的一个通道。但是呢，这个通道必须得建在准确的数据、清晰的权限、可以验证的检索，还有稳定的运维这些基础上面。金仓数据库搞的融合架构啊，给关系数据、文档数据、向量数据，还有 GIS 和时序数据，提供了一个统一管理还有混合检索的方向。它能帮你减少数据在不一样系统之间搬来搬去的情况。也让企业更容易把 AI，从那种演示的环境里面，给推进到真实的业务当中去。
一个真正成熟的向量数据库方案啊，它不是让你再去加一套孤零零的组件。而是说，让向量变成企业数据体系里面的一种能力。只有当检索出来的结果，能够关联到业务的事实上面去，能够符合权限的要求，能够跟上数据的变化，而且还能被审计、被维护的时候。向量数据库啊，这才算是真正地从"搜索工具"，走向了"融合数据底座"。