企业官网建设流程全解析

RAG 核心组件深度剖析：Embedding 模型与向量数据库

问题场景：刚接触 RAG 很容易搞混——Embedding 模型和大语言模型是同一个东西吗？向量数据库为什么非要用 Milvus，MySQL 存向量不行吗？这两个问题是 RAG 入门的"第一道坎"。

30秒速览：① Embedding 模型 ≠ LLM——前者只管"文字→数字向量"（图书管理员贴标签），后者只管"阅读理解写答案"（专家教授）。本地 BGE（1.3GB CPU 可跑，零 API 费用）vs 远程 LLM（数百 GB GPU 集群，按 token 计费）② 向量数据库不可或缺——MySQL 能存向量但只能全表扫描（100 万条 Top-10 ≈ 数十秒），Milvus 用 IVF_FLAT 近似最近邻索引（K-Means 聚类→只搜最近分区，100 万条 ≈ 50ms）③ RAG 全链路三组件协同——BGE 向量化→Milvus 语义检索→LLM 生成回答，附 PrismAI Beam 实际代码走读 + 降级链路设计。

本文是《AI 应用开发完全指南》系列深度番外篇。

⚠️时效性提示：本文基于 2026 年 7 月的技术状态撰写。模型版本和向量数据库功能迭代迅速（MySQL 9.0 已引入 VECTOR 类型但索引能力仍有限），文中涉及的版本号请以各项目最新发布为准。建议重点关注架构原理与设计决策。

一、两个模型的本质区别

1.1 它们不是同一个东西

RAG（检索增强生成）流程中存在两种完全不同的模型，各司其职：

┌─────────────────────────────────────────────────────────────────┐ │ RAG 流程中的两个模型 │ │ │ │ [用户问: "Java 垃圾回收有哪几种？"] │ │ │ │ │ ▼ │ │ ┌──────────────────────┐ │ │ │ ① Embedding 模型 │ ← 本地 CPU，~1.3GB │ │ │ 只管：文字 → 数字 │ 输入一段文字，输出一串数字（向量） │ │ │ │ 不能对话、不能理解语义 │ │ │ "Java 垃圾回收" │ │ │ │ ↓ │ │ │ │ [0.12, -0.34, ...] │ ← 1024 个浮点数（语义指纹） │ │ └──────────┬───────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────┐ │ │ │ 向量数据库 │ ← 用"语义指纹"去搜索最相似的文档 │ │ │ "这是检索到的3段 │ │ │ │ 相关文档片段..." │ │ │ └──────────┬───────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────┐ │ │ │ ② LLM 大语言模型 │ ← 远程 API，数百 GB │ │ │ 只管：阅读 + 理解 │ 能读文档、能推理、能写答案 │ │ │ 把问题+检索结果 │ │ │ │ 一起发给大模型 │ │ │ │ ↓ │ │ │ │ "根据资料，Java 垃圾│ │ │ │ 回收分为：Serial、 │ │ │ │ Parallel、CMS、G1、 │ │ │ │ ZGC..." │ │ │ └──────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘

1.2 类比理解

一句话总结：Embedding 模型只管"把文字变成数字标签"，LLM 只管"阅读上下文写答案"。把 Embedding 当成 LLM 用——让它回答问题——它做不到，它输出的是数字不是文字。反过来，用 LLM 做向量化——理论上可行但每次要调远程 API、按 token 计费——成本和延迟都不划算。

1.3 为什么不都用远程 API？

这是一个自然的追问。当前主流方案存在不对称性：

举例：一个知识库上传 100 个 PDF、切出 2000 个 chunk → 如果用远程 Embedding API 需要 2000 次调用 → 本地 BGE 模型零费用。这是成本驱动的设计决策，不是技术限制。

# 本地 BGE 模型：一次加载，无限使用fromsentence_transformersimportSentenceTransformer model=SentenceTransformer("BAAI/bge-large-zh-v1.5",device="cpu")embeddings=model.encode(["文本1","文本2",...,"文本2000"])# 批量、免费# 远程 API：按调用次数和 token 数计费# 2000 个 chunk × $0.00002/token × 500 tokens/chunk ≈ 大规模场景不可忽略

补充：BGE 模型不能直接跑在本地吗，之前不是说要下载 1.3G 模型，本地推理？是的。BGE 模型下载后就是本地推理，不走网络。1.3GB 的模型文件一次下载，后续批量向量化全在本地 CPU 完成，不产生 API 费用。这和 LLM 调用 DeepSeek 远程 API 是两条完全不同的路径。

二、为什么需要专门的向量数据库

2.1 MySQL 能存向量吗？

能存，但不能高效搜索。这是本质区别：

-- MySQL：精确/模糊文字匹配SELECT*FROMdocsWHEREcontentLIKE'%Java 垃圾回收%'-- 问题：用户问"JVM GC 机制"，字面不匹配 → 搜不到-- 即便存了向量（BLOB 列），也没有向量索引 → 全表扫描-- Milvus：语义相似度搜索-- 用户问"JVM GC 机制"-- 能返回：-- 1. "Java 垃圾回收器详解" 相似度 94%-- 2. "G1 收集器的调优参数" 相似度 87%-- 3. "内存管理与回收策略" 相似度 81%

2.2 性能对比

差距原因：MySQL 没有向量索引，只能逐条计算距离（sqrt(sum((a[i]-b[i])²))）。Milvus 用近似最近邻（ANN）索引——先将向量空间分区，搜索时只查最近的几个分区——精度略降（99%+ 召回率），速度提升 1000 倍。

2.3 在项目中的位置

以 PrismAI 的 Beam 应用为例，RAG 数据存储分层如下：

MySQL (beam 库) Milvus ├── knowledge_bases ← 知识库元数据 └── doc_chunks ← 文档切片的向量 ├── documents ← 文档元数据 每条 = {chunk_id, kb_id, text, embedding[1024]} │ (名称/大小/状态) │ │ MySQL 管"管理信息" Milvus 管"语义指纹" │ "知识库A叫什么、谁创建的" "这段文字在语义上和哪些片段最接近"

为什么不是二选一，而是两者配合？

• MySQL 存业务元数据（知识库名称、可见性、审核状态）——需要精确查询 + 事务
• Milvus 存语义向量——需要相似度搜索 + 高维索引

两者职责边界清晰：MySQL 回答"这个文档是什么"，Milvus 回答"这段内容和哪些内容最相似"。

2.4 向量搜索的核心原理

一句话版：把文字变成数字 → 数字之间比距离 → 距离近的就是语义近的。 1. 预处理（建立索引时）： 文档 → 切块 → BGE 编码 → [0.12, -0.34, 0.89, ...] → 存入 Milvus → 建立 IVF_FLAT 索引 2. 搜索时： 用户问题 → BGE 编码 → [0.15, -0.31, 0.92, ...] → Milvus 计算与所有向量的 IP（内积） → 返回 Top-K 最相似的文档片段 3. IVF_FLAT 索引用什么原理做到这么快？ - IVF = Inverted File：用 K-Means 将 100 万个向量聚成 128 个簇 - 搜索时只查找最近的 nprobe 个簇（比如 8 个），不是全量 100 万 - FLAT = 被选中的簇内部暴力计算，精度不损失 - 100万 → 8×7812 ≈ 6.25万次计算，而非 100万次

2.5 为什么本地开发依赖 Docker —— 核心原因是 Milvus

PrismAI 项目将 Docker 24+ 列为环境假设。5 个基础设施中，Milvus 是唯一必须通过 Docker 运行的：

Beam 启动时对每个基础设施都有降级处理，Milvus 不可用时不会崩溃——但 RAG 的向量检索会降级为仅 BM25 关键词匹配。

三、三组件协同：RAG 全链路走读

3.1 总体架构

用户 ──提问──→ [BGE 嵌入模型] ──向量──→ [Milvus] ──相关文档──→ [DeepSeek/LLM] ──回答──→ 用户 ↑ ↑ ↑ 本地 CPU 推理 Linux 容器 远程 API 调用 只管文字→数字 只管向量相似搜索 只管理解上下文作答 ~1.3GB 需 Docker 数百 GB 集群 零 API 费用 开源免费 按 token 计费

3.2 以 PrismAI 的实际代码为例

Beam 应用的 RAG 检索请求贯穿四个组件（beam/src/beam/rag/）：

POST /api/beam/search { query: "JVM GC 机制", kb_ids: ["kb_xxx"], top_k: 5 } │ ├── interfaces/rag_router.py │ └── POST /search → 解析请求 → 委托 Application 层 │ ├── application/service.py │ └── RagApplicationService.search(cmd) │ └── ① query 为空？→ 抛 ValidationError │ └── ② embedding_service 可用？→ 走混合检索，否则 BM25-only │ ├── infrastructure/retriever.py │ └── HybridRetriever.search() │ ├── _vector_search(query) ← ③ BGE 模型: query → 1024维向量 │ │ └── Milvus.search(向量, kb_id) ← ④ Milvus: 向量相似 → Top-K 文档 │ ├── _bm25_search(query) ← ⑤ jieba 分词: 关键词匹配 │ └── _rrf_fusion(v_results, b_results) ← ⑥ RRF 融合: 向量+关键词重排 │ → 返回 SearchResult[] {chunk_id, doc_name, chunk_text, score, search_type} │ ├── application/dto.py │ └── SearchResultDto.from_results(query, results) │ → { query, results: [{score, doc_name, chunk, search_type}] } │ └── 返回 {"code": 0, "data": {"query": "JVM GC 机制", "results": [...]}}

3.3 降级链路

PrismAI 设计文档规定了多层降级：

第一优先：向量检索（BGE + Milvus） │ ├── BGE 模型加载失败? → WARN 降级 → 仅 BM25 关键词检索 ├── Milvus 连接失败? → WARN 降级 → 仅 BM25 关键词检索 ├── 两者都不可用? → 返回空结果（Chat 中触发搜索时告知用户"检索服务暂不可用"） │ └── Chat 模块 rag_search 工具: ├── HybridRetriever 可用 → 调用 retriever.search() └── HybridRetriever 不可用 → 返回 mock 结果（fallback）

四、关键决策 FAQ

4.1 为什么选择本地 BGE 而不是远程 Embedding API？

原因三层：

4.2 LLM 不能直接做 Embedding 吗？

技术上 LLM 的最后几层隐藏层输出可以当向量用。但：

• 成本：每次 Embedding 调用要走完整 forward pass，GPU 计算成本远高于专用 Embedding 模型
• 延迟：LLM 推理延迟（秒级）vs 专用模型（毫秒级）
• 语义空间未必适配：LLM 的隐藏层向量训练目标是"预测下一个 token"，不是"区分语义相似度"，检索效果未必好于专用 Embedding

4.3 MySQL 8.0 已经支持向量索引了吗？

MySQL 8.0 不支持向量索引。MySQL 9.0（2024 年发布）引入了VECTOR数据类型，但向量索引功能仍有限。PostgreSQL 的pgvector扩展支持 IVFFlat 和 HNSW 索引，但在大规模（>100 万条向量）场景下，专用向量数据库（Milvus/Qdrant/Weaviate）在性能、索引灵活性、混合检索能力上仍有显著优势。

4.4 开发阶段能绕开 Milvus 吗？

能。PrismAI 项目的单元测试 92/92 全部通过，完全不依赖 Milvus：

# 测试中 Mock VectorStore，不走真实 Milvusmock_vector_store=AsyncMock(spec=VectorStoreRepository)mock_vector_store.search.return_value=[]service=RagApplicationService(vector_store=mock_vector_store,...)

对于本地开发体验，可以考虑的轻量替代方案：

• chromadb：Python 原生，零配置，pip install即可
• FAISS：Facebook 的向量检索库，纯 CPU，内存模式
• pgvector：如果已有 PostgreSQL 实例

但生产环境或需要混合检索（向量 + BM25 + RRF 融合）时，Milvus 是设计文档选定的方案。

核心要点回顾

1. Embedding 模型 ≠ LLM——前者是"图书管理员"（文字→数字标签），后者是"专家教授"（阅读理解写答案）。把 Embedding 当 LLM 用会得到数字不是文字；用 LLM 做 Embedding 成本爆炸
2. 向量数据库不可或缺——MySQL 能存向量但只能全表扫描（100 万条 ≈ 数十秒）。Milvus 的 IVF_FLAT 索引用 K-Means 聚类→只搜最近分区→100 万条 ≈ 50ms
3. MySQL + Milvus 混合存储——MySQL 管"管理信息"（知识库元数据 + 精确查询），Milvus 管"语义指纹"（相似度搜索 + 高维索引）。各司其职，不是二选一
4. 本地 BGE 是成本驱动的选择——知识库上传 2000 chunk 如果用远程 API = 2000 次调用 = 不可忽略的成本。BGE 本地推理零费用，且 CPU 毫秒级延迟
5. 降级比完美更重要——BGE 不可用？→ BM25。Milvus 不可用？→ BM25。两者都不可用？→ 告知用户"检索服务暂不可用"。优雅降级 > 完美架构

上一篇：《RAG从入门到工程落地》 |下一篇：《Agent的本质》
系列专栏：AI专栏