RAG 核心组件深度剖析Embedding 模型与向量数据库问题场景刚接触 RAG 很容易搞混——Embedding 模型和大语言模型是同一个东西吗向量数据库为什么非要用 MilvusMySQL 存向量不行吗这两个问题是 RAG 入门的第一道坎。30秒速览① Embedding 模型 ≠ LLM——前者只管文字→数字向量图书管理员贴标签后者只管阅读理解写答案专家教授。本地 BGE1.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 大语言模型角色类比图书管理员只管分类、贴标签、按标签找书专家教授能阅读、理解、推理、写答案能做什么把一段文字变成一串数字向量读上下文、理解意图、生成自然语言回答不能做什么对话、推理、理解语义—输入一段文字完整对话上下文含检索到的文档输出1024 个浮点数向量自然语言文本模型大小~1.3 GBCPU 可跑数百 GB需 GPU 集群运行方式本地下载离线推理远程 API 调用典型代表BGE-large-zh、OpenAI text-embedding-3DeepSeek V4、GPT-4、Claude 4一句话总结Embedding 模型只管把文字变成数字标签LLM 只管阅读上下文写答案。把 Embedding 当成 LLM 用——让它回答问题——它做不到它输出的是数字不是文字。反过来用 LLM 做向量化——理论上可行但每次要调远程 API、按 token 计费——成本和延迟都不划算。1.3 为什么不都用远程 API这是一个自然的追问。当前主流方案存在不对称性维度LLM远程Embedding本地调用频率每次对话 1-N 次每个文档切片 每次检索查询单次调用量1 次请求文档上传时批量 N 条检索时 1 条成本敏感度对话核心体验高频但可离线化举例一个知识库上传 100 个 PDF、切出 2000 个 chunk → 如果用远程 Embedding API 需要 2000 次调用 → 本地 BGE 模型零费用。这是成本驱动的设计决策不是技术限制。# 本地 BGE 模型一次加载无限使用fromsentence_transformersimportSentenceTransformer modelSentenceTransformer(BAAI/bge-large-zh-v1.5,devicecpu)embeddingsmodel.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 性能对比数据库1 万条向量 Top-10 检索100 万条向量 Top-10 检索MySQL全表扫描~500ms~数十秒MilvusIVF_FLAT~10ms~50ms差距原因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 —— 核心原因是 MilvusPrismAI 项目将 Docker 24 列为环境假设。5 个基础设施中Milvus 是唯一必须通过 Docker 运行的基础设施能否不用 Docker原因MySQL 8.0✅ 可本地安装Windows/Mac/Linux 都有原生版本Redis 7.0✅ 可本地安装或测试时用fakeredis替代Nacos 2.3.2⚠️ 需 Java可以java -jar本地启动MinIO✅ 可本地安装且 Beam RAG 当前未用 MinIO文件存本地磁盘Milvus❌必须 DockerC 项目只有 Linux 版本。单机模式内嵌 etcd底层依赖 Linux cgroup/namespace。Windows 上无原生二进制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四、关键决策 FAQ4.1 为什么选择本地 BGE 而不是远程 Embedding API原因三层层面理由成本知识库批量上传时需向量化数千个 chunk远程 API 按 token 计费BGE 本地推理零费用一致性公共知识库需要跨用户检索。如果各用各的 Embedding 模型用户 A 用 GLM、用户 B 用千问向量在不同语义空间中检索结果不可用。平台统一 BGE 模型保证跨用户的向量空间兼容——这是做公共知识库最容易踩的坑一开始觉得让用户各配各的模型更好上线后发现跨用户检索全是噪声可控性本地模型不依赖第三方 API 可用性模型版本和推理行为完全可控4.2 LLM 不能直接做 Embedding 吗技术上 LLM 的最后几层隐藏层输出可以当向量用。但成本每次 Embedding 调用要走完整 forward passGPU 计算成本远高于专用 Embedding 模型延迟LLM 推理延迟秒级vs 专用模型毫秒级语义空间未必适配LLM 的隐藏层向量训练目标是预测下一个 token不是区分语义相似度检索效果未必好于专用 Embedding4.3 MySQL 8.0 已经支持向量索引了吗MySQL 8.0 不支持向量索引。MySQL 9.02024 年发布引入了VECTOR数据类型但向量索引功能仍有限。PostgreSQL 的pgvector扩展支持 IVFFlat 和 HNSW 索引但在大规模100 万条向量场景下专用向量数据库Milvus/Qdrant/Weaviate在性能、索引灵活性、混合检索能力上仍有显著优势。4.4 开发阶段能绕开 Milvus 吗能。PrismAI 项目的单元测试 92/92 全部通过完全不依赖 Milvus# 测试中 Mock VectorStore不走真实 Milvusmock_vector_storeAsyncMock(specVectorStoreRepository)mock_vector_store.search.return_value[]serviceRagApplicationService(vector_storemock_vector_store,...)对于本地开发体验可以考虑的轻量替代方案chromadbPython 原生零配置pip install即可FAISSFacebook 的向量检索库纯 CPU内存模式pgvector如果已有 PostgreSQL 实例但生产环境或需要混合检索向量 BM25 RRF 融合时Milvus 是设计文档选定的方案。核心要点回顾Embedding 模型 ≠ LLM——前者是图书管理员文字→数字标签后者是专家教授阅读理解写答案。把 Embedding 当 LLM 用会得到数字不是文字用 LLM 做 Embedding 成本爆炸向量数据库不可或缺——MySQL 能存向量但只能全表扫描100 万条 ≈ 数十秒。Milvus 的 IVF_FLAT 索引用 K-Means 聚类→只搜最近分区→100 万条 ≈ 50msMySQL Milvus 混合存储——MySQL 管管理信息知识库元数据 精确查询Milvus 管语义指纹相似度搜索 高维索引。各司其职不是二选一本地 BGE 是成本驱动的选择——知识库上传 2000 chunk 如果用远程 API 2000 次调用 不可忽略的成本。BGE 本地推理零费用且 CPU 毫秒级延迟降级比完美更重要——BGE 不可用→ BM25。Milvus 不可用→ BM25。两者都不可用→ 告知用户检索服务暂不可用。优雅降级 完美架构上一篇《RAG从入门到工程落地》 |下一篇《Agent的本质》系列专栏AI专栏