最近排查 RAG 知识库问题时我遇到一个很典型的现象用户问“发票报销的流程是什么”系统却从一份产品说明里召回了一段和“发票”只是沾边的内容最后大模型一本正经地把报销流程和开票流程混在一起讲。第一反应是模型不行第二反应是向量检索没调好。但真正把链路拆开看问题早在离线索引阶段就埋下了文档切块切得太碎、Embedding 模型对“流程类问题”的语义区分度不够、召回只用了向量检索而没有做关键词兜底也没有重排。这个案例其实代表了很多人对 RAG 的一个误解以为 RAG 就是“给大模型接一个资料库”只要把文档丢进去模型就能自动回答。实际上RAG 是一套完整的检索-组装-生成工作流而 Embedding 嵌入模型和向量检索只是这条流水线上的两个关键环节。真正让 RAG 有价值的不是某个环节多聪明而是整条链路变得可控、可观测、可迭代。1. 先理解 RAG 真正解决的问题不是给模型加资料1.1 一个最常见的“答非所问”场景这种“答非所问”在客服场景、企业内部知识库问答里非常常见。用户的问题往往很具体报销流程是什么、某台设备的告警代码代表什么意思、合同里的付款条款怎么写的。但系统返回的答案经常是“听起来很像但实际上不对”。为什么会出现这种“听起来很像”的错误因为向量检索只负责计算语义距离它不保证事实正确。它可以把“发票”和“收据”这种语义相近的词匹配到一起但无法判断“报销流程”和“开票流程”是不是同一件事。而大模型呢它只负责根据检索到的上下文补全回答本身也没有事实校验能力。于是两端的误差叠加在一起就产生了一个语气自信、逻辑通顺、但内容完全不对的答案。很多人遇到这种情况会立刻怀疑“是不是该换一个大模型”。但真正的排查重点往往在检索链路的前半段。1.2 RAG 不是外挂记忆而是把“知识检索”从模型里拆出来RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它的核心做法是先从外部知识库里检索和用户问题相关的片段再把这些片段作为上下文交给大模型生成回答。你可以把它理解成模型不再是靠“背下来的参数知识”硬答而是先查资料、再回答。这个设计解决的核心问题不是“模型不够聪明”而是参数知识有几个硬伤更新慢。模型训练一次成本很高想让它知道企业内部三天前刚发布的制度根本来不及。不可解释。模型为什么给出这个答案开发者很难追踪到具体依据。无法覆盖私有数据。企业真实的业务文档、聊天记录、运维手册通常不能进入大模型的公开训练集。RAG 的思路是把知识外置文档更新了就更新外部的索引模型参数完全不用动。这样既避开了微调的高成本也让知识来源变得可以追溯。1.3 核心判断可控性大于“聪明”我对 RAG 有一个明确判断它的核心价值不是让模型更聪明而是让回答“有据可依”让系统可干预、可回溯。当你把知识放在外部每个答案都基于检索出来的片段开发者就能检查检索出来的是什么、排序是否合理、引用来源是否正确。如果答错了可以定位是切块问题、Embedding 问题还是 Prompt 问题而不是把模型当成黑盒去猜。所以学习 RAG 时我建议先改变心态不要追求“一步到位效果惊艳”而是先把流程跑通再一个环节一个环节地调。后面所有细节都是在这个框架下展开的。2. 拆开 RAG 完整流程离线索引和在线查询RAG 不是一个单一动作它由离线索引和在线查询两个大阶段组成。很多人只盯着“查询”阶段却忘了离线阶段的质量决定了整个系统的上限。2.1 离线阶段一文档接入与切块这是质量的第一道关文档接入不是“把 PDF 塞进去”这么简单。第一步是文档清洗去掉页眉页脚、导航、页码、多余换行。如果是从扫描件里 OCR 出来的内容还要处理错字率和版面错乱。经常遇到的情况是文档里的表格被切成散落的文本语义关系断裂。清洗之后是切块chunking这是最容易被低估的步骤。切块大小会直接影响后面 Embedding 和向量检索的效果。切得太小单块语义不完整检索时匹配不到关键信息切得太大单块包含太多主题向量被平均成一个模糊的表示查询时召回的精度也会下降。常见切块策略有这么几类固定长度切块实现简单但可能把句子拦腰切断按句子或段落切块保留语义单位但长段落可能超过模型输入限制父子切块父块保留完整上下文子块负责检索检索到子块后返回父块兼顾精准和完整结构感知切块按 Markdown 标题、PDF 章节切适合结构化文档。提醒切块策略没有标准答案。最好的办法是同一批文档用两三种策略分别建索引再用一组测试问题跑一遍对比“正确答案是否被召回”。2.2 离线阶段二Embedding 入库和元数据设计切块完成后每块文本需要调用 Embedding 模型转成向量。这个向量会被写入向量数据库同时存下来的还有原文、来源文件、标题、页码、块序号等元数据。不要小看元数据。后面做权限过滤、时间过滤、按来源追溯都要靠它。向量数据库的选择可以分阶段学习阶段用一个轻量向量库就够生产阶段再用 Milvus 这类专用服务。无论用什么第一次入库时都要确认索引类型和相似度度量否则后面查询时排序逻辑可能不一致。2.3 在线阶段Query 理解、召回、重排、组装和生成用户问了一个问题系统要做五件事Query 理解可选如果用户问题口语化、指代不清可以先改写或扩展成更适合检索的表达把 query 转成向量同时用 BM25 等关键词方式检索拿到多个候选集合并候选集去掉重复和无关内容得到 TopK用 Rerank 模型对候选片段重新打分选出真正相关的片段把片段组装进 Prompt并明确告诉模型“只能根据以下资料回答如果资料里没有就说不知道”然后交给大模型生成。这五个环节里最容易出问题的是第 2、3、4 步。很多人只做了第 2 步“query 向量化 相似度排序”发现效果不好就怀疑大模型。其实在检索质量不过关之前生成环节是无从优化的。2.4 一个最小流程的输入输出视图用一句话描述 RAG 的工作过程一段文档从“清洗-切块-Embedding-入库”变成可检索的数据一个用户问题从“向量化-召回-重排-组装”变成可参考的上下文最后模型基于上下文生成回答。在这个过程中“检索到的片段质量”决定了回答质量的上限。模型只是把上限尽量兑现。如果检索到的片段本身错了再强的模型也救不回来。3. Embedding 嵌入模型它到底做了什么为什么这么关键3.1 从“词向量”到“句向量”Embedding 到底在做什么Embedding 的本质是把文本变成一组固定维度的数字向量。早期大家熟悉的是词向量比如 word2vec 把一个词映射成一个向量现代大模型时代的 Embedding 模型则更进一步把整句话或整段文本编码成一个向量让模型比较的不再是字面词是否相同而是“语义是否相近”。你可以把向量想象成一个坐标点每个文本都在高维空间里有一个位置。语义相近的文本坐标位置更接近语义无关的文本坐标位置更远。RAG 里的向量检索本质就是在高维空间里找“离 query 最近的那批点”。3.2 为什么语义接近的文本会映射到相近位置Embedding 模型通常会通过对比学习训练给模型一个“锚点”再给一个“正样本”语义相近和一个或多个“负样本”语义无关训练目标是把正样本拉近、负样本推远。经过大量数据训练后模型就学会了某种语义空间的排列规则。对于使用者来说不需要去训练模型但要知道两点第一你选用的 Embedding 模型直接决定了这个“语义空间”长什么样。换一个模型所有文本的相对位置可能都不一样。第二Query 和文档应该用同一个 Embedding 模型并使用相同的预处理流程否则两边的向量不在同一个空间里检索结果会失控。很多 RAG 项目出现“检索不到”并不是大模型的问题而是 Embedding 环节就已经把信息编码“偏”了。3.3 使用 Embedding 时的关键参数和常见误解实际使用 Embedding 模型时有几个参数需要留意向量维度常见几百到几千不等。维度越高表达能力越强但存储和计算成本也越高最大输入长度模型通常有一个最大 token 数超过部分会被截断。如果文档块本身很长内容可能损失相似度度量常见有余弦相似度、内积、欧氏距离。向量归一化之后余弦相似度和内积排序结果等价但不要在一个库里混用不同度量是否加 Instruction一些 Embedding 模型要求检索时给 query 加固定前缀文档入库时不加。如果搞反了效果会明显变差。一个常见误解是“Embedding 模型越贵越好”或“越大越好”。实际上对 RAG 项目来说模型是否覆盖你的语种、长度限制是否满足、对领域术语是否敏感往往比单纯看公开评测分数更重要。中文知识库场景优先看中文语料评测好的模型。3.4 模型选型开源模型和 API 型模型怎么选现在可选方案很多有开源模型比如 BGE 系列里的 bge-m3属于多语言、支持长文本的模型也有各种 API 型 Embedding 服务开箱即用国内云平台也提供部署好的模型服务。选型时可以按这个顺序判断你的文档主要是中文、英文还是多语言多语言场景要优先看多语言模型是否需要私有化部署如果数据不能出内网就需要本地部署开源模型检索效果是否足够用你自己的测试集做一次小规模召回实验不要只看公开榜单成本和性能能否接受向量维度和推理速度会影响后续存储和接口响应。注意同一个项目里Embedding 模型一旦确定并完成入库中途更换模型需要重新对所有文档计算向量否则新旧向量空间不一致。4. 向量检索的工作原理从暴力搜索到 ANN再到混合召回4.1 向量检索不是万能的先看距离和维度向量检索要做的事是在一堆向量里找到跟 query 最相似的 TopK。最朴素的方式是暴力逐条计算距离当数据量只有几千条时没问题但到百万级、千万级暴力搜索就慢得不可接受了。于是有了近似最近邻ANN索引。但这里要提醒向量检索擅长的是“语义相似”不是“事实精确”。“苹果”和“水果”语义相近但“型号 ABC-123”和“型号 ABC-124”在向量空间里不一定近。遇到精确编号、代码、品牌型号向量检索不一定比关键词检索更好。4.2 HNSW 等 ANN 索引的核心思想常见 ANN 索引思路有几类基于树的、基于哈希的、基于量化的、基于图的。HNSW分层可导航小世界图是实践中最常听到的一种。它的核心想法是把向量看成图上的节点相邻节点之间连边。检索时从高层稀疏的图开始快速跳到目标区域再逐层下探到更精细的图。这样不需要遍历全部向量就能以较高概率找到最近邻。实际使用向量数据库时你不需要自己实现 HNSW只需要理解几个关键点召回精度和检索速度存在权衡索引参数会同时影响构建时间和查询精度数据量小的时候不同索引的差异不明显数据量上来后才会体现。4.3 为什么需要 BM25 和 Embedding 混合召回向量检索不是银弹。在很多真实文档里问题需要的答案可能依赖“精确词”而不是语义。比如用户输入“退款政策第 2 条”如果文档切块里包含“第 2 条”这个字面标记BM25 这类关键词检索很容易命中向量检索反而可能因为语义平滑而错过。因此工程上常用“多路召回”一路用 Embedding 向量的语义检索一路用 BM25 关键词检索最后把两路结果合并再统一去重和重排。合并时可以按排名倒数加权比如 Reciprocal Rank FusionRRF也可以给两路设置不同权重后线性融合。检索方式擅长场景弱点纯向量检索同义改写、语义相关、跨语言表达精确词、编号、短语容易丢失纯 BM25精确词项、编号、代码片段对同义词和语义改写不敏感向量 BM25 多路召回覆盖大多数文档问答场景需要处理排序融合和去重多路召回 Rerank追求高精度、对结果质量要求严格会增加额外延迟和计算成本搜索热词里提到“向量混合检索加 BM25 多路召回”说明这已经是 RAG 落地时的常见标配而不是什么高级技巧。4.4 Rerank 为什么是质量提升关键向量检索和 BM25 都属于“召回”阶段它们的任务是从海量候选里快速捞出一批“可能相关”的片段。但“可能相关”不等于“一定相关”很多片段可能在向量空间里距离近实际上语义却不对。Rerank 模型通常把“问题”和“候选片段”拼在一起进行更精细的双向交互打分相当于把答案比较的工作重新做一遍。它比向量检索慢但精度高适合只对 Top 20 到 50 的候选做精排。建议的路线是先用向量检索 BM25 召回 Top 50再用 Rerank 重排取 Top 5 放入 Prompt。这个组合在很多 RAG 项目里能明显提升答案准确性。4.5 一个实用的评估方法检验 RAG 质量最直接的方法是准备一组测试问题每个问题标注“正确答案出现在哪篇文档的哪一段”。然后对比召回命中率正确答案是否出现在召回的 Top 5 或 Top 10 里命中位置正确内容是否排在前列最终答案正确率大模型是否基于正确片段生成了正确回答。如果召回命中率低优先查切块和 Embedding如果召回了正确片段但最终回答不对优先查 Prompt 和上下文组装。这个分流思路能让你在排查时少走很多弯路。5. 从零跑通一个 RAG 项目关键技术栈与落地步骤5.1 技术栈选型先跑通再上向量数据库很多人一上来就问我该选 Milvus 还是 LlamaIndex 还是 Dify。我的建议是先区分“学习验证”和“生产落地”。学习验证阶段可以不用任何现成的 RAG 框架自己写三行逻辑文档切块 - 调 Embedding 接口 - 存到一个简单向量库。把最小链路跑通再逐步引入 LlamaIndex、LangChain 这类框架最后才考虑 Milvus 这类专用向量数据库。生产阶段的选择逻辑大概是向量存储数据量小可以用轻量方案数据量大、并发高、需要高可用用 MilvusRAG 框架LlamaIndex 对知识库抽象更好LangChain 链路更灵活低代码平台Dify 这类工具适合快速验证但不等于整个项目一劳永逸Embedding 模型可以本地部署开源模型也可以使用云 API大模型部分本地部署或 API 都行取决于数据隐私和成本。5.2 一个最小可运行的 RAG 流程示意代码下面是一个概念性的 Python 流程用来展示 RAG 主链路不代表某个具体框架的现成代码# 示意结构理解流程为主 # 1. 文档切块 chunks split_document(file, chunk_size400, overlap80) # 2. Embedding 入库 for chunk in chunks: vector embedding_model.encode(chunk) vector_store.add(vectorvector, textchunk, meta{source: file}) # 3. 查询阶段 query_vector embedding_model.encode(user_query) candidates vector_store.search(query_vector, top_k20) # 4. 混合召回可选 bm25_candidates bm25_search(user_query, top_k20) merged merge_by_rrf(candidates, bm25_candidates) # 5. 重排可选 reranked rerank_model.rerank(user_query, merged[:50])[:5] # 6. 组装 Prompt 并生成 prompt build_prompt(user_query, reranked) answer llm.chat(prompt)这段代码不依赖具体库因为不同场景下函数实现差异很大。但它把全流程分成了 6 个动作。你只要保证每一步的输入输出一致就能把不同模块接起来。5.3 关键参数起步值给一组相对保守的起步值实际落地要以你的具体文档和模型为准切块长度300-500 tokenoverlap 50-100召回数量先用 Top 20 召回加 Rerank 后取 Top 5Embedding 批量大小32 或 64避免大批量超时相似度向量归一化后用余弦相似度或内积Rerank 候选数量Top 50 以内避免耗时太高Prompt 上下文长度确保放入的是“检索到的 Top5 片段”而不是整个知识库。这些是起点不是终点。跑完一批测试问题后再根据“召回命中率”和“回答正确率”调整。5.4 常见问题排查链路遇到 RAG 效果不对先别急着换大模型。按这个顺序排查看现象是答案完全无关、部分错误、缺少细节还是回答不稳定看召回结果把 Top 10 候选片段打印出来人工判断是否真的和问题相关。这一步能定位到底是“检索不到”还是“生成错误”。看切块内容候选片段是否被截断、跨主题、丢了上下文如果是调整切块策略。看 EmbeddingQuery 和文档是否用同一个模型是否加了不一致的指令是否存在长文本截断。看检索参数TopK 是否太小、排序指标是否一致、混合召回权重是否合理。看 Prompt是否明确要求“只根据资料回答”是否给出来源格式要求。看大模型上下文拼接后是否超出上下文窗口导致后半段被截断。大部分 RAG 问题都能在这几步里找到答案。真正需要换模型或换数据库的情况比想象中少得多。6. RAG 的适用边界和下一步6.1 适合用 RAG 的场景RAG 最合适的场景是“知识相对稳定、但需要随时更新”的文档问答企业内部知识库、制度文档、产品手册问答客服机器人通过检索历史工单和知识库给出带依据的回答私有数据问答数据不能用于训练大模型时用 RAG 把数据放在外部检索层需要引用来源的场景比如合规审查、法律条款查询RAG 可以把引用段落一并给出。6.2 不适合用 RAG 的场景RAG 不是万能的。这几种情况可能需要换思路需要多步推理、跨多个文档组合证据才能回答的复杂问题基础 RAG 单次检索很难完成需要 Agent 或更复杂的流程数据本身没有做清洗和结构化脏数据进 RAG检索出来的内容质量没有保证高频交易型操作RAG 是检索生成不是事务系统不该用它承载确定性操作现有模型已经能高质量回答的通用问题不一定需要 RAG避免无谓增加延迟和维护成本。6.3 从 RAG 到 Agentic RAG检索流程的自动化传统 RAG 是“一次检索、一次生成”。到了 Agentic RAG流程变成可循环的Agent 先拆解