向量数据库不是终点，企业AI真正需要的是融合数据库

前段时间参与一个企业内部知识库项目，目标是给业务人员做一个智能问答助手。

项目初期，我们采用的是比较常见的RAG架构：文档通过Embedding模型转换成向量，存入Milvus；关键词搜索交给ES；用户权限、业务数据继续保存在关系数据库中。

从技术角度看，这套方案没有问题。

在Demo阶段，效果甚至很好。上传几千份文档后，输入问题，几秒钟就能返回相关内容。

但真正进入业务阶段以后，问题慢慢出现了。

企业里的数据从来不只是文档。

一份合同除了正文内容，还有客户信息、所属区域、审批状态、创建时间等业务字段。一份设备故障记录，也不仅包含描述文本，还有设备编号、运行时间、地理位置、历史维修记录。

用户提出的问题，也不会只是简单的语义搜索。

比如：

"帮我找一下最近三个月华东地区关于合同审核异常的问题。"

这个需求同时包含了文本语义匹配、时间范围过滤、区域筛选和业务状态判断。

如果全部依靠向量数据库处理，并不现实。

最后系统只能变成：

先从业务数据库查询符合条件的数据；

再交给搜索系统过滤；

然后调用向量数据库匹配相似内容；

最后在应用层合并结果。

项目刚开始数据量小，这种方式还能接受。但随着数据越来越多，系统之间的数据同步、接口维护、结果一致性逐渐成为新的问题。

这让我重新思考一个问题：

企业AI真正需要的，到底是一套极致的向量搜索系统，还是一套能够同时理解业务数据和AI数据的数据底座？

为什么RAG需要向量数据库

大模型能力很强，但它天然存在几个限制。

首先，大模型不知道企业内部数据。

公司的合同、产品资料、内部制度，这些私有知识通常不会出现在模型训练数据中。

其次，大模型知识存在时间限制。

企业数据每天都在变化，如果每次更新知识都重新训练模型，成本非常高。

另外，企业数据还涉及安全问题，很多内部资料无法直接提交给公网模型。

RAG的核心思路，就是让模型先查询企业自己的知识库，再根据检索结果生成答案。

简单来说：

用户提出问题；

系统将问题转换成向量；

通过向量搜索找到相似内容；

把相关资料提供给大模型；

模型结合上下文生成回答。

其中最关键的就是向量检索。

传统数据库搜索依赖关键词，比如搜索"数据库优化"，只能找到包含这些文字的数据。

而向量搜索关注的是语义关系。

例如：

"系统最近运行越来越慢，有什么优化方法？"

虽然没有出现"数据库优化"几个字，但通过向量计算，系统可以理解两者表达的是类似含义。

这也是向量数据库出现的原因。

企业场景需要的不只是向量

目前市场上有很多专用向量数据库，例如Milvus、Pinecone等。

它们在纯向量检索场景下表现很好，可以快速完成大规模相似度搜索。

但企业应用往往更加复杂。

例如医疗场景：

"查询过去三个月杭州地区类似症状病例。"

这里包含：

症状文本相似度；
时间范围；
地理位置；
病例结构化信息。

工业场景：

"查找最近一个月某区域设备异常，并分析类似故障原因。"

这里包含：

设备信息；
时间序列数据；
空间位置；
故障文档。

这些需求里面，向量只是其中一部分。

真正业务系统需要同时处理关系数据、文档数据、GIS数据、时序数据以及向量数据。

如果这些数据分散在多个系统里，应用层就需要不断做数据拼接。

这也是很多AI项目从演示阶段走向生产阶段后遇到的问题。

融合数据库解决的是数据孤岛问题

后来重新评估技术方案时，我们关注到了金仓KES的向量能力。

它的思路不是单独建设一个向量数据库，而是在数据库内部增加向量处理能力。

业务数据继续保存在关系表中，文档内容、向量信息、空间数据、时间数据可以关联存储。

例如知识库表：

scss 复制代码

CREATE TABLE knowledge_base (
    id BIGINT PRIMARY KEY,
    title VARCHAR(200),
    content TEXT,
    product_type VARCHAR(50),
    region VARCHAR(50),
    create_time DATE,
    embedding VECTOR(768)
);

其中：

content保存文本内容；

product_type保存业务分类；

region保存区域信息；

embedding保存文本向量。

查询时，可以同时完成向量相似度计算和业务条件过滤。

例如：

"查找最近三个月华东区域关于设备故障的相关资料。"

不需要先查业务库，再调用向量库，而是在数据库内部完成统一查询。

这类融合能力对于企业应用最大的价值，不一定是单纯提升某一次搜索速度，而是减少系统之间的数据搬运。

向量检索性能并不是唯一指标

向量数据库常见的索引方式包括IVFFLAT和HNSW。

IVFFLAT通过聚类方式减少搜索范围，资源消耗较低，适合中等规模数据。

HNSW通过构建多层图结构进行快速搜索，在召回率和查询速度之间取得较好平衡。

KES向量组件支持这类主流索引方式，同时支持余弦距离、欧氏距离、内积等多种距离计算。

对于企业场景来说，更重要的是向量数据和业务数据能够在同一个数据库环境中协同工作。

因为实际应用里，很少存在"只搜索向量"的需求。

和Milvus、ES相比，如何选择？

如果业务目标是超大规模纯向量检索，例如几十亿级图片搜索、模型训练数据检索，那么专用向量数据库仍然具有优势。

Milvus在向量搜索领域积累较深，适合纯AI检索场景。

ES则更擅长全文搜索。

但企业生产系统通常还需要考虑事务、高可用、安全、权限管理以及数据一致性。

这也是融合数据库的价值所在。

它牺牲了一部分极致的单项性能，换来了更完整的数据处理能力。

对于金融、政务、制造、企业知识库等场景，数据本身就是复杂混合的，融合架构往往更加符合实际需求。

AI Agent时代，数据库会变成新的能力入口

随着AI Agent的发展，数据库的角色也正在变化。

过去数据库只是负责存储数据。

未来AI可能直接通过数据库完成查询、分析甚至辅助运维。

例如，通过MCP Server让AI连接数据库后，开发人员可以直接询问：

"这个SQL为什么执行慢？"

"当前哪些表缺少索引？"

"帮我分析最近一次故障原因。"

AI调用数据库能力，返回分析结果。

这意味着数据库不只是数据存储中心，也可能成为AI理解业务的重要入口。

总结

向量数据库解决了AI应用中的语义检索问题，但企业真正落地AI时，需要处理的不只是向量。

业务数据、文档数据、空间数据、时间数据往往同时存在。

如果继续依赖多个系统拼接，随着规模增长，复杂度会越来越高。

融合数据库的价值，就是让AI能力和企业数据体系在同一个环境中结合。

所以，向量数据库并不是企业AI的终点。

真正决定AI应用能否落地的，是有没有一套能够理解业务、连接数据、支撑智能应用的数据底座。