做大模型应用开发时很快会遇到一个核心瓶颈模型只会回答训练数据里出现过的内容公司内部文档、最新政策、实时业务数据它一概不知道。RAGRetrieval-Augmented Generation检索增强生成是当前解决这个瓶颈最常用的技术路线先让系统从知识库中检索与问题最相关的片段再把片段交给大模型生成答案。这套逻辑听起来简单真正落地时却涉及 Embedding 嵌入模型怎么选、向量检索为什么能工作、文档切块怎么切、检索结果如何重排等一系列问题。这篇文章从 RAG 的完整业务流程出发重点讲解 Embedding 的运行机制、向量检索的工作原理并给出一个可运行的最小项目和排查链路适合准备入门大模型 RAG 开发或者已经在做 RAG 但想系统理清原理的读者。1. 先理解 RAG 的运行位置为什么大模型需要外挂知识库1.1 大模型的“知识截止”与幻觉问题语言模型在训练阶段学习到的知识有一个固定的截止时间。模型无法天然知道训练之后发生的事情也无法读取你本地服务器上的私有文档。如果直接拿一个通用模型回答企业内部问题它只能基于训练时的记忆生成内容一旦遇到没见过的问题会选择“编造一个看起来合理的答案”这就是所谓的大模型幻觉。幻觉不是模型“坏掉了”而是生成机制决定的。模型在预测下一个 token 时只会根据上下文寻找概率最高的表达它并不区分这个表达来自真实资料还是自己的记忆。因此在企业知识问答、客服、文档助手等场景中直接让模型回答是不可控的。RAG 的思路是改变信息流向不让模型凭记忆回答而是先从外部知识库检索出候选材料再把材料作为上下文交给模型让模型基于给定材料生成答案。这样既保留了模型的生成能力又把答案限定在可追溯的知识范围内。1.2 RAG 与微调不是二选一很多刚接触大模型开发的人会把 RAG 和微调放在一起比较但两者解决的问题是不同的。对比维度RAG微调核心目的给模型补充“外部知识”改变模型的“行为方式或输出风格”知识更新更新知识库即可无需重新训练需要重新训练或增量训练成本相对低主要消耗存储和检索资源较高需要 GPU 训练资源可追溯性答案可以引用来源文档难以追溯知识来自哪条训练数据典型场景企业内部问答、文档检索、客服特定格式输出、领域术语适应、风格对齐实际项目里RAG 和微调也经常组合使用。先用微调让模型适应业务术语和输出格式再用 RAG 提供最新的业务数据。两者不是互斥方案。1.3 RAG 的核心链路一句话总结可以把 RAG 理解成两条流水线的组合一条是离线的索引构建流程原始文档 - 清洗 - 切块 - Embedding 向量化 - 写入向量数据库。另一条是在线的问答流程用户提问 - 问题向量化 - 向量数据库检索 - 候选片段合并重排 - 拼接 Prompt - 大模型生成答案。后面所有章节都会围绕这两条流水线展开。理解这两条线RAG 的整体结构就清楚了。2. Embedding 运行机制文本如何变成向量2.1 什么是文本向量文本向量是把一段文字转换成一串固定长度的浮点数数组。例如“RAG 是什么”经过 Embedding 模型处理后可能得到一个 1024 维的向量像这样[0.0123, -0.0456, 0.0789, ... , 0.0034]这串数字不是随机的它在高维空间里编码了文本的语义。两个语义相近的句子它们对应向量的空间距离也会更近。例如“如何退款”和“怎么申请退款”的向量会靠在一起而“如何退款”和“今天天气怎么样”的向量会离得比较远。这就是 Embedding 模型的核心价值把人类语言中的相似性转换成数学空间中的距离。2.2 Embedding 模型的基本工作流程Embedding 模型本质上是一个深度神经网络通常基于 Transformer 结构。输入是一段带 token 的文本输出是一个向量表示。常见流程是文本分 token例如“RAG 是什么”会拆成若干 token。token 经过多层 Transformer 编码每一层都会融合上下文信息。取最后一层某个位置的输出或者对所有 token 输出做池化得到一个定长向量。对向量做归一化得到可以直接计算相似度的结果。以 bge-m3 这类常见中文模型为例它在推理时会同时把词、短语、句子级别的信息编码进向量因此对中文长文本的语义表达效果较好。使用前要查看模型的 max_seq_length也就是最大输入长度超过这个长度的文本需要截断或重新切块。2.3 相似度计算余弦相似度为什么常用向量检索时最常用的相似度指标是余弦相似度。它计算两个向量夹角的余弦值公式逻辑是import numpy as np def cosine_similarity(vec_a, vec_b): dot np.dot(vec_a, vec_b) norm_a np.linalg.norm(vec_a) norm_b np.linalg.norm(vec_b) return dot / (norm_a * norm_b)余弦相似度的值范围是 -1 到 1。值越接近 1表示方向越一致语义越相近。它只关心方向不关心向量的长度因此在文本语义相似度场景中比欧式距离更稳定。很多向量数据库在计算时会先对向量做归一化这样余弦相似度可以直接转化为内积计算性能更高。2.4 Embedding 模型选型对比Embedding 模型的选择会直接影响检索效果。常用的几类模型如下模型常见维度特点使用场景bge-m31024支持中英文支持长文本可做多语言检索中文知识库、通用 RAGtext-embedding-ada-0021536OpenAI 出品英文效果稳定英文场景、调用第三方 APItext-embedding-3-small1536可指定维度价格较低英文场景、成本敏感m3e-base768中文效果不错模型体积小本地部署、中文场景jina-embeddings-v32048支持多语言和长文本多语言混合检索选择模型时要注意三点第一Embedding 模型必须与检索链路保持一致索引时用模型 A查询时换成模型 B会造成向量空间不一致检索结果完全不可用第二要关注模型的最大输入长度长文本切块后单块长度不能超过该限制第三中文场景优先选择中文语料训练充分的模型直接拿英文模型处理中文语义表达会打折扣。2.5 常见坑维度、语义漂移与文本长度第一个坑是维度不匹配。向量数据库建集合时会固定维度例如 1024 维。如果写入时换了一个模型输出的向量变成 1536 维写入就会报错。解决方案是建集合前固定模型版本并在集合元数据里记录模型名称。第二个坑是语义漂移。同一套知识库今天用 bge-m3下周换成另一个新模型新模型没有重新生成全部向量只对新文档做向量化。结果就是新旧文档处于不同向量空间检索质量混乱。正确做法是换模型后全量重建索引。第三个坑是文本超长。有些 Embedding 模型会直接截断超长输入但截断位置如果落在语义中间向量表达会偏离原意。所以文档切块时单块长度要小于模型的最大输入长度留出安全余量。3. 向量检索工作原理从暴力搜索到 ANN3.1 为什么传统数据库的 LIKE 不够用传统关系数据库的 LIKE %退款% 只能做字符匹配。用户问“钱没到账怎么办”文档里写的是“退款将在 3 个工作日内原路返回”两者没有共同的字符LIKE 无法召回这条内容但 Embedding 向量可以做到因为两个句子的语义是相近的。向量检索解决的是“按语义找内容”的问题。它可以处理同义词、口语表达、语序变化这是 RAG 知识库的核心能力。3.2 近似最近邻HNSW 和 IVF 的原理如果知识库只有几百条文档直接计算每条向量与查询向量的距离也就是暴力搜索完全可行。但生产环境的知识库动辄几十万、上百万条数据暴力搜索的耗时无法接受所以需要近似最近邻算法简称 ANN。ANN 的核心思想是用空间索引结构减少需要计算距离的向量数量用少量精度损失换取大幅性能提升。HNSWHierarchical Navigable Small World是目前最常用的算法之一。它把向量构建成多层图结构上层图连接稀疏适合快速定位大范围区域下层图连接密集适合精确比较。查询时从顶层进入逐层向下类似在大地图上先定位城市再找具体街道。IVFInverted File Index的思路是先把向量空间划分成多个聚类区域查询时只搜索与查询向量最近的几个聚类区域而不是全量搜索。它需要先训练聚类中心适合数据量更大的场景。实际选型时可以参考这个表格算法优点缺点适合场景Flat 暴力检索结果最准数据量大时慢数据集小于 1 万HNSW查询快、精度高内存占用较大万级到千万级通用首选IVF内存占用相对低需要训练聚类模型千万级以上、内存受限DiskANN支持超大规模部署复杂度高亿级向量3.3 混合检索向量召回 BM25 多路召回向量检索擅长语义匹配但也有短板。遇到精确名词、编号、人名、专业术语时向量模型可能把不同编号的语义混淆而传统的关键词检索能精确命中。例如用户查“订单号 20260815001”关键词检索能直接找到包含这个订单号的文档向量检索反而可能召回语义相近但不正确的文档。混合检索的思路是同时跑两条召回通道一条是向量召回基于 Embedding 相似度找语义相近内容。另一条是关键词召回基于 BM25 算法计算文档与查询词的相关性找字符级精确匹配的内容。两条通道的召回结果合并后再经过重排序模块把最终结果拼接给大模型。BM25 的核心公式可以简单理解为一个词在一篇文档中出现的频率越高且这个词在整个知识库中越稀有那么这篇文档的相关性越高。它适合处理精确匹配场景。3.4 重排序 rerank 的作用召回阶段的目标是“尽量不全漏”所以返回的候选数量通常比较大例如召回 50 条。但大模型的上下文窗口有限不能把 50 条全部塞进 Prompt而且召回的列表未必按真实相关性排序。这时需要 rerank 模型。Rerank 模型与 Embedding 模型不同。Embedding 是预先给每条文本算好向量查询时只比较向量距离Rerank 是在查询发生时把“查询文本 候选文档”拼接起来输入模型让模型直接判断候选文档与查询的相关性输出相关度分数。这种方式的精度更高但性能开销也更大因为每条候选都要单独过一遍模型。生产环境常见的做法是召回 50 条 - rerank 取前 5 条 - 拼入 Prompt。3.5 向量数据库选型对比向量数据库是 RAG 项目中负责存储和检索向量的组件。主流选择如下方案部署方式优点注意事项Milvus独立服务功能全、支持混合检索、规模大组件多运维成本较高Qdrant独立服务部署简单、API 友好自研功能需看版本文档Weaviate独立服务支持模块化集成中文生态资料相对少pgvectorPostgreSQL 插件复用现有数据库数据量大时性能受限FAISS嵌入式库轻量、适合学习和原型不提供服务端管理能力学习阶段可以先从 FAISS 或 pgvector 开始跑通业务逻辑后再切换到 Milvus 等生产级方案。切换时要注意向量索引类型、检索参数和元数据过滤方式的差异。4. 一条完整的 RAG 业务流程从文档到答案4.1 整体流程两个阶段一条主线RAG 业务可以拆成两个阶段。理解这两个阶段就能理解 RAG 项目所有模块的职责。离线索引构建阶段的任务是“准备好知识库”。输入是 PDF、Word、Markdown、HTML 等原始文档输出是向量数据库中的一条条向量记录。在线问答阶段的任务是“根据问题找答案”。输入是用户问题输出是模型生成的回答同时最好附带引用的来源文档。两个阶段共享同一个 Embedding 模型这一点非常关键。4.2 阶段一离线索引构建离线索引构建的五个步骤分别是文档加载读取原始文件。PDF 要处理扫描件还是文本版Word 要处理表格和页眉页脚Markdown 相对干净。文档清洗去掉无意义的换行、水印、页眉页脚、特殊符号。清洗不干净切出来的块会大量包含噪声文本。文档切块把长文档切成固定大小的片段这是影响检索效果最直接的一步。向量化每个片段调用 Embedding 模型生成向量。写入向量数据库保存文本片段、向量、元数据例如来源文件名、页码、章节标题。4.3 阶段二在线问答在线问答的五个步骤分别是查询向量化用同一个 Embedding 模型把用户问题转成向量。向量检索从向量数据库召回 TopN 候选文本。可选的混合检索同时用 BM25 召回关键词命中结果。重排序用 Rerank 模型重新排序合并多路结果。Prompt 拼接与生成把用户问题和检索到的候选片段拼进系统提示词交给大模型生成答案。这个流程中任何一个环节质量差最终答案都会受影响。很多人调了很久 Prompt 但效果仍然不好问题很可能出在检索环节而不是生成环节。4.4 切块策略什么影响检索效果切块是 RAG 项目里最值得花时间调优的环节。切块过小单个片段语义不完整检索不到核心信息切块过大片段里混入太多无关内容向量表达被稀释同时占用的 Prompt token 也更多。常见的切块策略有三种策略做法适用场景固定长度切块按字符数或 token 数切分相邻块加重叠通用场景、结构化不强的文档段落切块按 Markdown 标题、换行符切分技术文档、公众号文章语义切块根据句子向量相似度判断语义边界内容主题差异大的长文档推荐的做法是固定长度切块 重叠窗口。例如每块 500 个 token重叠 50 个 token。重叠的作用是避免关键句子刚好落在切块边界上导致语义断裂。切块后每块文本长度要小于 Embedding 模型的最大输入长度。4.5 一个最小 Python 示例bge-m3 FAISS 大模型 API下面给出一段最小可运行示例用来说明离线索引和在线检索的完整闭环。import os from FlagEmbedding import FlagModel from sentence_transformers import SentenceTransformer # 1. 加载模型实际项目中要统一模型版本 model SentenceTransformer(BAAI/bge-m3)这段代码仅为示例加载说明不同版本的依赖库接口差异较大。使用前先确认 FlagEmbedding、sentence-transformers 等包的版本并查阅对应版本的 API 文档。更稳妥的最小链路可以拆成两个脚本。索引脚本负责把文档切块后写入 FAISSimport numpy as np import faiss # 假设 docs 是已经切块并清洗好的文本列表 docs [ RAG 是把检索结果作为上下文交给大模型生成答案的技术。, Embedding 把文本转换为向量用来计算语义相似度。, 向量数据库用来存储和检索大规模向量数据。, ] # 生成向量 vectors model.encode(docs, normalize_embeddingsTrue) # 写入 FAISS 索引 dimension vectors.shape[1] index faiss.IndexFlatIP(dimension) index.add(vectors) # 保存索引和文档映射供查询阶段使用 faiss.write_index(index, knowledge.index) with open(docs.txt, w, encodingutf-8) as f: f.write(\n.join(docs))查询脚本负责把问题向量化、检索并输出结果index faiss.read_index(knowledge.index) with open(docs.txt, r, encodingutf-8) as f: docs [line.strip() for line in f.readlines()] question RAG 是什么技术 question_vector model.encode([question], normalize_embeddingsTrue) # 检索 top3 scores, indices index.search(question_vector, k3) for score, idx in zip(scores[0], indices[0]): print(fscore: {score:.4f}, text: {docs[idx]})之后再把检索到的片段拼入 Prompt调用大模型 API 生成答案from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) context \n.join([docs[idx] for idx in indices[0]]) prompt f请基于以下资料回答问题。 资料 {context} 问题{question} 回答时只使用资料中的信息不要编造。 response client.chat.completions.create( modelqwen-plus, messages[{role: user, content: prompt}], ) print(response.choices[0].message.content)这个最小示例中切块、索引、检索、生成四个环节都完整存在只是全部简化了。实际项目里需要把 FAISS 换成向量数据库把内存中的 docs 列表换成持久化存储并加入元数据过滤。4.6 Java 侧集成提醒热搜词里出现“java rag 实战”说明很多 Java 技术栈的团队也在接入 RAG。Java 生态中可以做类似的事情但侧重点不同。Java 侧通常负责的是 RAG 后端的工程化部分接收用户请求、调用检索服务、管理 Prompt 模板、调用大模型 API、保存会话历史。而 Embedding 和向量检索更多是交给 Python 侧的服务或独立部署的向量数据库完成。如果坚持在 Java 里生成向量可以使用 ONNX Runtime 加载量化后的 Embedding 模型也可以调用远程 Embedding API。要特别注意Java 侧通过 HTTP 调用 Python 侧服务时建议在中间层做好超时控制、熔断和日志记录避免大模型接口抖动影响主流程。5. 从零跑通 RAG 项目环境准备与验证5.1 环境版本建议学习阶段不需要一上来就搭建完整的 Milvus 集群建议从轻量方案开始。组件学习环境建议生产环境建议Embedding 模型bge-m3本地运行或调用 API根据预算和效果评估后固定版本向量存储FAISS 本地索引Milvus、Qdrant、pgvector 等大模型大模型 API例如 DashScope 兼容接口私有化部署或安全合规的 API语言Python 3.10按团队技术栈定框架LangChain 或 LlamaIndex或手写业务耦合度高时建议抽象服务层先跑通最小闭环再逐步替换组件是成本最低的学习路径。5.2 一个 RAG 项目的目录结构rag-project/ ├── data/ # 原始文档 ├── index/ # 本地向量索引 ├── src/ │ ├── loader.py # 文档加载与清洗 │ ├── chunker.py # 切块策略 │ ├── embedder.py # Embedding 封装 │ ├── retriever.py # 检索封装 │ ├── generator.py # 大模型生成封装 │ └── pipeline.py # 编排完整流程 ├── tests/ │ └── test_retriever.py # 检索测试 ├── requirements.txt └── README.md这种目录结构把每个环节拆成独立模块。等需要替换组件时例如从 FAISS 换成 Milvus只需要修改 retriever.py其他模块不需要动。5.3 运行验证查询答案并检查引用项目跑通后不能只看模型是否输出了文字。建议输出以下信息用来验证用户问题。检索到的每个候选片段和相似度分数。被拼接进 Prompt 的最终片段。模型生成的答案。同时检查三个问题答案是否来自检索到的片段片段是否真的与问题相关相似度分数是否达到合理阈值。如果检索到的片段与问题不相关说明问题出在检索环节调 Prompt 没有意义。这个判断顺序很重要。5.4 评估不能只看回答漂不漂亮RAG 项目的效果评估需要拆成两个维度检索质量评估和生成质量评估。检索质量评估看两类指标指标含义RecallK正确答案是否出现在前 K 条结果中MRR第一条正确答案在结果列表中的位置生成质量评估可以建立测试集每个问题带标准答案或评分标注然后用大模型自动打分或人工抽样评估。至少要准备 50 到 100 条覆盖不同场景的测试问题否则后续优化没有依据。5.5 学习环境和生产环境的差异学习环境一切从简生产环境必须补齐以下能力配置外置化模型名称、API Key、数据库地址不能写死在代码里要用环境变量或配置中心管理。日志记录每轮问答的检索候选、分数、最终 Prompt、生成结果方便定位问题。监控大模型接口延迟、Token 消耗、向量数据库查询耗时都要有指标。权限知识库内容可能涉及部门权限检索侧要做元数据过滤。回滚模型升级、切块策略调整后必须保留旧索引支持快速回滚。6. 常见问题排查链路6.1 检索不到相关内容现象用户提出的问题明显在知识库里有答案但检索结果完全不相关。排查顺序如下确认查询文本已经正确向量化打印问题向量维度是否与索引维度一致。确认 Emebdding 模型是否与索引构建时一致。检查原始文档是否真的被写入索引查询索引条数。检查切块逻辑是否因为清洗或切块把关键内容截掉了。检查检索返回的 TopN 数量是否因为 k 设置太小漏掉了正确内容。尝试降低相似度阈值观察结果是否有改善。如果问题可以直接用 BM25 命中而向量检索不命中说明当前 Embedding 模型对这类问题的语义表达能力有限可以加入混合检索。6.2 检索到了但答案不对现象检索结果看起来相关但模型回答仍然错误或编造信息。排查重点转向生成环节查看最终输入大模型的 Prompt确认检索片段是否真的被完整拼接。检查提示词是否明确要求“只使用资料中的信息回答”。检查检索片段数量是否过多上下文被大量无关信息干扰。确认大模型版本和参数配置过高的 temperature 会增强随机性降低答案稳定性。注意RAG 调优的顺序永远是先查检索再查生成。检索结果不对时调整 Prompt 只是在放大错误信息。6.3 向量维度或模型不一致现象写入向量数据库时报错或者检索结果质量极差。常见原因索引时用模型 A查询时换成模型 B。向量数据库集合创建时指定了固定维度后来换模型后维度不同。多个团队各自生成向量没有统一模型版本。解决方案在向量数据库的集合元数据里记录模型名称和维度检索代码启动时校验模型是否匹配。换模型一律全量重建索引。6.4 响应太慢现象问答接口整体耗时过长用户等待超过可接受范围。耗时通常分布在四个环节环节耗时原因优化方向查询向量化Embedding 模型推理慢使用 GPU 推理、批量处理向量检索索引类型不合适使用 HNSW 等 ANN 索引Rerank逐条过模型开销大缩小候选集、使用更轻量模型大模型生成生成长文本耗时减少输出 token、优化 Prompt 长度6.5 一个可复用的 RAG 排错清单[ ] 确认 Embedding 模型版本一致。[ ] 确认向量维度一致。[ ] 确认文档已清洗、已切块、已写入索引。[ ] 打印问题向量和检索分数确认检索结果合理。[ ] 检查最终 Prompt 内容确认上下文包含检索片段。[ ] 确认大模型配置参数输出稳定。[ ] 检查日志定位耗时集中在哪个环节。7. 生产落地建议与扩展方向7.1 上线前检查清单RAG 系统上线前这组清单可以帮助减少线上问题知识库是否需要权限隔离检索时是否按用户身份过滤元数据文档更新频率是多少是否需要定时重建索引或增量更新是否保留历史索引版本切换失败能否快速回滚大模型 API 是否有超时、重试、熔断机制是否记录每轮问答的检索候选和最终 Prompt是否对敏感内容做数据脱敏和访问审计是否准备了一组评估问题集用来监控线上效果漂移7.2 扩展方向Agentic RAG、GraphRAG 与多路召回RAG 不是一个终点而是一个可以持续扩展的基础架构。Agentic RAG 是目前很受关注的方向。普通 RAG 做一次检索、生成一次答案Agentic RAG 则让大模型自己决定是否检索、检索几次、是否需要查询改写、是否结合工具。例如用户先问“帮我查一下上个月销售数据”Agent 发现知识库检索不到最新数据转而调用数据库查询工具。这种模式更适合复杂的多轮对话场景。GraphRAG 是把知识图谱和 RAG 结合。先抽取文档中的实体和关系构建成图结构再基于图进行检索。它适合回答“实体之间有什么关系”这类多跳问题例如“A 产品的供应商与 B 项目的负责人是否有合作”。普通向量检索很难处理这种关联关系因为关联信息分散在不同文档片段里。多路召回是生产环境更务实的优化方向。向量召回负责语义匹配BM25 负责精确匹配知识图谱检索负责实体关联不同路的结果合并后经过 Rerank 统一排序。每一路召回对应一类信息需求不追求单条路完美而是组合取胜。7.3 对入门者的学习路径建议如果刚接触 RAG建议按这个顺序学习先用手写代码完成最小闭环切块、Embedding、FAISS 检索、调用大模型。再引入切块优化对比不同切块策略在测试集上的召回效果。然后接入向量数据库把本地文件索引迁移到服务化存储。后续加入 BM25 混合检索和 Rerank观察最终答案质量变化。最后再研究 LangChain、LlamaIndex 等框架此时你已经能判断框架的封装是否合理而不是被框架牵着走。RAG 的学习难点从来不是某个单一组件而是如何把组件组合成一条可靠的链路。只要把“文档怎么进、向量怎么存、问题怎么找、上下文怎么拼、答案怎么生成”这条主线理清楚剩下的就是针对业务场景逐步优化。先把最小闭环跑起来再按指标迭代才是做 RAG 项目最有效的方式。