Embedding模型与LLM不是同一个东西！RAG核心组件深度剖析

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

一、两个模型的本质区别

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 模型：一次加载，无限使用from sentence_transformers import SentenceTransformermodel = 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 ≈ 大规模场景不可忽略

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

2.1 MySQL 能存向量吗？

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

-- MySQL：精确/模糊文字匹配SELECT * FROM docs WHERE content LIKE '%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 是设计文档选定的方案。

核心要点回顾

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