为什么生成式 AI 需要向量数据库？

大语言模型本身并不知道企业最新、私有或内部的数据和知识。

例如，企业内部可能存在：

• 指标定义文档；

• 产品手册；

• 数据治理规范；

• 业务制度；

• 客户案例；

• SQL 说明；

• Wiki；

• FAQ；

• 内部报告。

这些内容通常不会直接存在于通用大模型的训练数据中。

企业如果希望 AI 能够回答：

“公司内部对于有效客户是怎么定义的？”

一种常见方案就是建立 RAG 系统。

基本流程是：

企业文档
   ↓
文本切分
   ↓
Embedding
   ↓
向量数据库
   ↓
用户提问
   ↓
向量相似度检索
   ↓
找出相关文本
   ↓
发送给大语言模型
   ↓
生成回答

其中，向量数据库承担的是：从大量企业知识中快速找到与当前问题最相关的上下文。

因此，在生成式 AI 架构中，向量数据库经常承担“长期外部知识存储与检索层”的角色。

向量数据库有哪些核心能力？

1. 向量存储

能够高效保存数百维甚至数千维的 Embedding 向量，并管理大规模向量集合。

2. 相似度搜索

根据查询向量快速查找语义上相似的记录。这是语义搜索、RAG 和推荐系统最基础的能力。

3. 元数据过滤

企业场景中，仅靠语义相似并不够。

例如用户检索“销售收入定义”时，可能需要限定：

部门 = 财务

数据版本 = 当前版本

权限 = 当前用户可访问

文档状态 = 已发布

因此成熟向量数据库通常支持：向量搜索 + 结构化元数据过滤。

4. 混合检索

纯向量搜索有时会漏掉精确关键词。

例如：

“BCBS 239”

这类缩写本身具有很强的关键词特征。

因此实际 RAG 系统经常结合：

• 向量检索；

• BM25；

• 关键词搜索；

• 元数据过滤。

形成 Hybrid Search，也就是混合检索。

5. 向量更新与生命周期管理

企业知识会不断变化。

例如：

指标口径更新；

制度文档换版本；

产品资料被修改。

因此向量数据库还需要支持新增、删除、更新和重新 Embedding，而不能只完成一次性向量化。

向量数据库在 AI 架构中的位置

典型企业生成式 AI 架构可以表示为：

企业文档 / Wiki / PDF / FAQ
           ↓
      文档解析与切分
           ↓
      Embedding Model
           ↓
       向量数据库
           ↓
        Retriever
           ↓
       Prompt Context
           ↓
           LLM
           ↓
         AI 回答

在这个架构中，向量数据库主要处理的是：非结构化知识的语义检索。

但如果用户的问题是：

“华东地区今年销售收入是多少？”

事情就不同了。因为用户要的不是一段相关文档，而是一个需要基于真实数据和确定业务规则计算出来的数值。这种场景通常还需要：

自然语言
   ↓
业务语义解析
   ↓
指标 / 维度 / 条件
   ↓
语义层 / 指标平台
   ↓
结构化数据查询
   ↓
结果

这正是理解向量数据库边界的关键。

向量数据库和传统数据库有什么区别？

向量数据库和 RAG 是一回事吗？

不是。RAG 是一种生成式 AI 架构模式，向量数据库只是其中常用的检索基础设施。

RAG 通常包括：

数据准备
+
文档切分
+
Embedding
+
检索
+
重排序
+
上下文组装
+
LLM 生成

向量数据库主要负责其中的：向量存储和检索。此外，RAG 也并不一定必须依赖向量数据库。

一些系统可能使用：

• 搜索引擎；

• 知识图谱；

• SQL；

• API；

• 混合检索。

因此不能将：

“用了向量数据库”

直接等同于：

“已经完成高质量 RAG”。

向量数据库和知识图谱有什么区别？

向量数据库擅长表示：

“两个对象在语义上有多接近。”

知识图谱更加擅长表达：

“两个对象之间到底是什么关系。”

例如：

销售毛利
依赖
销售收入

这是一个明确的结构化关系。

知识图谱可以清楚表示：

销售毛利 —— depends_on —— 销售收入

而向量数据库通常只能判断：

“销售毛利”和“销售收入”在语义上比较相关。

因此，如果企业需要明确管理：

• 上下游关系；

• 血缘；

• 组织关系；

• 实体关系；

• 依赖关系；

结构化图关系通常比单纯向量相似度更合适。

向量数据库和语义层有什么区别？

这是企业 Data Agent 场景中非常重要的区别。向量数据库解决的是“找到相关知识”，语义层解决的是“按照统一业务规则计算数据”。

例如，用户询问：

“销售收入的定义是什么？”

向量数据库可以从企业文档中找到：

销售收入统计口径说明。

这属于知识检索。

但用户如果询问：

“今年华东区销售收入是多少？”

系统需要明确：

• 销售收入对应哪个指标；

• 是否含税；

• 使用支付时间还是下单时间；

• 华东包括哪些组织；

• 底层使用哪些数据；

• 按什么规则进行聚合。

这些问题不能仅靠文本相似度解决。因此企业级 Data Agent 通常需要同时具备：

向量数据库 / RAG
        ↓
解释文档、制度、知识
语义层 / 指标平台
        ↓
执行指标、维度和业务规则
大语言模型 / Agent
        ↓
理解问题并协调调用

三者职责不同。

典型应用场景

场景一：企业知识库问答

企业将：

• 制度；

• 产品资料；

• 技术手册；

• FAQ；

• 项目文档；

转成向量。

用户提出自然语言问题后，通过向量检索找到相关内容，再由大语言模型回答。这是当前最典型的 RAG 应用。

场景二：语义搜索

传统关键词搜索可能要求用户知道准确术语。

向量数据库可以支持：

“怎么判断会员是不是快流失了？”

检索出标题为：

《会员流失预测与留存管理规范》

即使关键词不完全一致，也能通过语义相似完成召回。

场景三：推荐系统

商品、文章、视频甚至用户都可以表示成向量。系统根据向量之间的相似度推荐：相似商品、相似文章、相关内容。

场景四：多模态检索

图片和文本可以通过多模态 Embedding 映射到统一向量空间。这样用户甚至可以输入：“找到类似这张工业设备图片的产品。”再通过向量搜索找到相关图片或商品。

场景五：Data Agent 业务知识检索

企业 Data Agent 在分析过程中可能需要查阅：

• 指标说明；

• 业务制度；

• 行业知识；

• 历史分析报告；

• 用户上传文档。

向量数据库可以作为 Agent 的知识检索工具之一，为分析提供外部上下文。

Aloudata 如何使用向量数据库能力？

在 Aloudata 的产品体系中，向量数据库更适合作为 Aloudata Agent 可信数据分析智能体的知识检索能力之一，而不是承担企业结构化指标计算的核心职责。

Aloudata Agent 在复杂分析场景中，不仅需要访问结构化数据，还可能需要理解：

• 指标说明；

• 分析方法；

• 业务制度；

• 上传文件；

• 企业知识；

• 分析经验。

这类非结构化内容可以通过 RAG、Embedding 和向量检索等方式，为 Agent 提供相关上下文。

例如用户询问：

“为什么本季度会员留存下降？结合会员运营制度分析一下。”

这里可能同时需要：

结构化数据
↓
留存率、渠道、会员等级等指标
非结构化知识
↓
会员运营策略、制度、历史分析资料

向量数据库更适合处理后者。

向量数据库、语义层与 Data Agent 如何协同？

企业级 Data Agent 往往同时面对三类问题。

第一类：“销售收入是什么意思？”这是知识问题，可以通过 RAG 和向量数据库检索相关文档。

第二类：“8 月销售收入是多少？”这是数据计算问题。应该调用 Aloudata CAN 等语义层或指标服务，按照统一口径执行查询。

第三类：“为什么 8 月销售收入下降？”这是分析问题。Agent 需要综合：指标查询、维度下钻、历史趋势、企业知识、分析 Skill，进行多步骤分析。

因此，一个更加完整的企业数据分析架构是：

                   ┌──────────────┐
                   │ Aloudata Agent│
                   └───────┬──────┘
                           │
           ┌───────────────┼───────────────┐
           ↓               ↓               ↓
      向量数据库       Aloudata CAN      分析 Skill
           ↓               ↓               ↓
      企业知识检索      指标语义查询       分析流程
           └───────────────┼───────────────┘
                           ↓
                       可信回答

核心不是让一种技术承担所有任务，而是让不同组件处理自己最擅长的问题。

常见误区

误区一：有了向量数据库，就有了企业知识库

事实：向量数据库只是存储和检索层。企业知识库还需要文档治理、切分、Embedding、权限、版本、重排序以及知识更新机制。

误区二：向量检索出来的内容一定正确

事实：向量检索衡量的是语义相似度，不代表事实真实性、时效性或业务权威性。企业需要通过元数据和治理机制限制检索范围。

误区三：RAG 可以替代企业语义层

事实：RAG 适合检索非结构化知识，但无法天然保证结构化指标计算中的业务口径、维度、权限和聚合规则一致。企业问数仍需要确定性的指标语义层。

误区四：向量数据库可以直接替代关系型数据库

事实：两者解决的是不同问题。交易、订单、客户和指标等精确结构化查询仍然更加适合关系型、分析型数据库或数据仓库；向量数据库主要处理相似度检索。

常见问题（FAQ）

Q1：什么是向量数据库？

向量数据库是一类专门用于存储、索引和检索高维向量数据的数据库。它通常将文本、图片等内容通过 Embedding 模型转换为向量，再通过向量距离找到语义上最相似的数据，广泛应用于 RAG、语义搜索和推荐系统。

Q2：向量数据库和普通数据库有什么区别？

普通数据库主要通过字段值和明确条件进行精确查询，而向量数据库主要通过向量距离执行相似度查询。前者更适合订单、客户和交易等结构化数据，后者更适合文本、图片和知识内容的语义检索。

Q3：RAG 一定需要向量数据库吗？

不一定。向量数据库是 RAG 中常见的检索基础设施，但 RAG 还可以结合关键词搜索、搜索引擎、知识图谱、SQL 和 API 等方式进行检索。高质量 RAG 通常还需要重排序、权限、版本和上下文管理。

Q4：向量数据库能直接用于企业 AI 问数吗？

可以辅助理解业务知识，但不能单独保证问数结果正确。企业 AI 问数还需要明确指标、维度、业务规则、数据模型和权限。向量数据库更适合检索相关文档，而指标平台或语义层负责确定性的数据计算。

Q5：向量数据库和语义层是什么关系？

两者负责不同类型的语义。向量数据库主要通过 Embedding 表达文本或内容之间的相似语义；语义层则显式定义企业指标、维度、业务规则和数据模型。前者解决“找到相关知识”，后者解决“按照统一业务逻辑查询和计算数据”。