文章目录一、RAG 解决什么问题二、离线阶段先把知识库建好1. 文档收集与格式统一2. 文档加载从文件变成统一文档对象3. 数据清洗决定知识库的底线质量4. 文档切片把长文档变成可检索单元5. 向量化让文本可以被计算相似度6. 写入向量数据库三、在线阶段从问题到答案1. 问题重构先把用户真正想问的内容说清楚2. 查询向量化让问题进入同一个检索空间3. 多路召回同时寻找语义相关和词面相关的内容四、结果融合把不同检索器的结果合到一起1. RRF 融合2. 加权融合五、Rerank对候选证据做更精细的判断六、Prompt 组装让模型知道证据和边界七、离线和在线链路如何评估八、常见误区与改进方向误区一把所有文本平均切成固定长度误区二只依赖向量检索误区三把召回数量当成效果的全部误区四忽略版本和权限误区五认为大模型会自动辨别资料真假误区六没有保留可追溯信息九、传统 RAG 的完整心智模型总结本文根据上面的流程图整理面向第一次学习传统 RAG 的读者。文章只讲流程和工程思路不包含代码实现。很多人第一次接触 RAG 时会把它理解成“给大模型接一个向量数据库”。这个说法没有错但不够完整。一个真正可用的传统 RAG 系统至少包含两条链路离线链路把原始文档处理成可以检索的知识库。在线链路把用户问题转换成检索请求召回相关内容再交给大模型生成答案。这张流程图正是这两条链路的完整展开。它从文档开始经过加载、清洗、切片、向量化和入库用户提问后再经过问题重构、多路召回、结果融合、重排、Prompt 组装最后交给大模型回答。一、RAG 解决什么问题大模型本身并不知道企业内部的规章制度、项目文档、产品手册和最新业务数据。即使模型在训练阶段见过类似内容也不能保证它知道你的私有资料更不能保证回答使用的是最新版本。RAG 的基本思路是从外部知识库中检索与问题相关的内容。把检索结果作为上下文提供给大模型。要求大模型基于这些上下文回答问题。因此RAG 不是重新训练大模型而是在回答问题时临时补充知识。它把“模型记忆知识”变成了“模型查询知识”。传统 RAG 的核心链路可以概括为文档加载 → 数据清洗 → 文档切片 → 向量化 → 写入向量数据库 → 问题改写 → 多路召回 → 结果合并 → 重排 → Prompt 组装 → 大模型生成二、离线阶段先把知识库建好离线阶段通常只在文档新增、修改或重新建库时执行。它的目标不是直接回答用户问题而是把杂乱的原始资料变成结构稳定、可检索、可追溯的知识单元。1. 文档收集与格式统一知识库的输入可能来自很多地方文档类型常见来源处理重点Markdown、TXT技术文档、知识库、项目说明保留标题层级和段落结构Word制度、合同、产品说明处理标题、表格和页眉页脚PDF手册、报告、扫描文档判断是文本 PDF 还是扫描 PDF网页帮助中心、在线文档去除导航栏、广告和无关元素Excel、CSV、JSON业务数据、配置和 FAQ明确行列关系及字段含义格式统一的目标是无论原始文件是什么格式最终都转换成统一的文档对象并保留正文和元数据两部分信息。2. 文档加载从文件变成统一文档对象Loader 的职责是读取文件而不是理解文件内容。它通常需要输出两类信息正文内容后续用于切片和向量化。元数据文件名、路径、页码、标题、更新时间、权限标签等。元数据非常重要。用户最终看到的答案不仅要“答对”还应该知道答案来自哪份资料、哪一页或哪个章节。没有元数据后续的引用、过滤和权限控制都会变得困难。可以把 Loader 理解成知识库的入口层它负责把不同格式的文件转换成统一输入但不负责解决脏数据和业务语义问题。3. 数据清洗决定知识库的底线质量原始文档通常不能直接进入向量数据库。常见噪声包括页眉、页脚、页码和重复标题。公司地址、版权声明和法律免责声明等重复内容。网页导航、广告、评论区和推荐内容。OCR 产生的错别字、乱码和断行。无意义的代码片段、模板占位符和格式控制字符。同一份文档的旧版本和新版本同时存在。清洗阶段还应该补充和规范文档名称、来源部门、负责人、页码、章节、更新时间、版本号、生效状态、访问权限、唯一标识和分块编号等元数据。清洗不是“删得越多越好”。页码、章节标题和表格字段有时正是回答问题所需的上下文。正确原则是删除重复噪声保留能帮助理解、检索和追溯的信息。4. 文档切片把长文档变成可检索单元大模型和向量模型都不适合直接处理一整本长文档所以需要把文档切成多个 Chunk。每个 Chunk 是一次检索的基本单位。切片主要解决两个矛盾Chunk 太大包含很多无关内容检索结果不够精准。Chunk 太小上下文被切碎召回后无法完整表达原意。中文文档通常可以优先按标题、段落、句号和更细的句子边界切分。Markdown 文档适合先按标题层级切分再对过长章节进行二次递归切分。切片时最好把标题路径一起保留例如“员工制度 / 请假制度 / 年假计算”。这样向量模型在编码正文时也能感知它所属的章节。Chunk 大小没有一个适用于所有项目的固定答案。普通中文知识库可以从每块约 200 到 500 个字符开始调试FAQ 可以更小制度、合同条款、表格和代码则应该优先保持语义结构完整。相邻 Chunk 之间通常保留少量重叠以降低关键信息正好落在切分边界上的风险。重叠过大则会制造大量重复向量增加存储和检索成本。5. 向量化让文本可以被计算相似度向量化就是把文本转换成一组数字。语义相近的文本在向量空间中通常距离更近用户的问题也会被转换成同一个向量空间中的查询向量。通常使用的是 BGE-M3。它可以同时产生稠密向量适合表达整体语义能够处理同义改写和自然语言表达。稀疏向量更关注词项和关键词对产品名、编号、专有名词和错误码很有帮助。一个重要原则是离线阶段和在线阶段必须使用同一个 Embedding 模型或者至少使用兼容的向量空间。离线文档用一种模型入库在线问题换另一种模型查询会导致向量无法直接比较。6. 写入向量数据库向量数据库保存的并不只是向量。一个可用的知识库记录通常至少包含字段作用文本内容作为最终上下文返回给大模型稠密向量用于语义相似度检索稀疏向量用于关键词或词项检索来源文件展示引用和追踪原文页码、章节帮助定位答案出处Chunk 编号恢复相邻内容和调试切片版本、权限标签过滤旧文档和无权限内容完整元数据为后续扩展保留信息流程图中列举了 Milvus、Chroma 和 Qdrant 等向量数据库。它们都可以保存向量和元数据但生产选型要结合数据规模、过滤需求、部署方式、备份能力和团队运维经验。如果使用 BGE-M3 的稠密加稀疏能力Milvus 的混合检索能力比较适合这类场景。小规模实验可以使用轻量模式生产环境则要考虑独立服务、索引构建、备份和监控。三、在线阶段从问题到答案在线阶段发生在用户每次提问时。它的关键不是“把问题向量化后查一次”而是尽可能完整地理解问题、召回候选证据、筛掉噪声再把有限且可靠的上下文交给大模型。1. 问题重构先把用户真正想问的内容说清楚真实问题往往不适合直接检索。例如用户说“那它什么时候生效”其中的“它”依赖上一轮对话又或者用户使用了口语、缩写和错别字原句里没有知识库中的标准词汇。问题重构可以根据对话历史补全指代、拆分复合问题、统一术语、补充必要的时间范围和筛选条件。它的目标是生成更适合检索的查询而不是替用户回答问题。重构也有边界不能凭空增加原问题没有表达的事实不能把用户的限制条件删掉也不能为了追求关键词匹配而改变原意。对于简单、明确的问题可以跳过重构避免额外延迟和不必要的改写。2. 查询向量化让问题进入同一个检索空间经过重构的问题会使用与文档入库阶段兼容的 Embedding 模型进行向量化。若知识库保存了 BGE-M3 的稠密向量和稀疏向量在线查询也可以同时生成两种表示。这一步得到的是“如何找到相关内容”的数学表示不是答案本身。向量相似度只能说明文本在表示空间中接近不能保证文本一定能够回答问题所以后面仍然需要多路召回和重排。3. 多路召回同时寻找语义相关和词面相关的内容传统 RAG 常把两类检索并行执行稠密向量检索根据整体语义寻找内容适合用户换一种说法提问、使用同义词或描述现象的场景。稀疏检索或 BM25 检索根据词项匹配寻找内容适合产品名称、合同编号、错误码、API 名称和专有名词等场景。两类检索的关注点不同。只做稠密检索可能找不到一个关键编号只做 BM25又可能无法理解同义表达。因此图片中“向量数据库 Elasticsearch/BM25”的并行结构本质上是让两种检索能力互相补足。召回阶段通常先取相对宽的候选集合例如分别从不同检索器取得若干条结果。这里的数量应通过验证集调试取太少容易漏掉证据取太多会增加后续重排成本也会把无关内容带进上下文。四、结果融合把不同检索器的结果合到一起不同检索器的分数通常不能直接比较。向量相似度、BM25 分数和稀疏向量分数的取值范围、分布和含义都不同简单相加往往会让某一路检索器因为分数尺度更大而占据主导。1. RRF 融合RRFReciprocal Rank Fusion倒数排名融合不直接比较原始分数而是根据结果在各自列表中的名次计算贡献。一个文档在多个检索器中都排名靠前就会获得更高的融合排名只在某一路出现的结果仍然有机会保留。RRF 的优点是简单、稳定不需要先把不同检索器的分数校准到同一尺度适合作为混合召回的起点。它的局限是只使用排名信息无法完全利用分数差异明显的情况。2. 加权融合如果已经通过离线评估了解不同检索器的效果也可以对各路结果设置权重。例如产品手册可能更依赖关键词匹配开放性知识问答可能更依赖语义匹配。权重不应该凭经验永久固定而应根据真实问题集、业务词汇和版本变化持续验证。融合后要去重。同一段内容可能同时出现在稠密和稀疏检索结果中也可能因为相邻切片重叠而高度相似。去重可以按文档唯一标识和 Chunk 编号进行也可以结合文本相似度合并重复内容。五、Rerank对候选证据做更精细的判断召回阶段追求“不要漏”因此候选结果中通常会混入一些只部分相关的内容。Rerank 会把“问题”和每个候选 Chunk 成对交给更精细的相关性模型重新打分再选出最值得放入上下文的内容。流程图中列出了 BGE-Rerank 和 Cohere Rerank。前者适合在本地或私有环境部署后者是托管服务选择。具体使用哪一种要考虑中文效果、延迟、成本、数据合规和部署条件。Rerank 的输入应该是问题与候选文本而不是只有候选文本。它判断的是“这段文本能否回答这个问题”通常比单纯的向量距离更贴近最终任务。需要注意上下文预算。重排后并非结果越多越好应优先保留能够直接支撑答案的少量片段同时兼顾必要的标题、定义、前置条件和例外条款。若相邻片段共同构成完整规则可以在重排后按文档位置恢复它们的顺序。六、Prompt 组装让模型知道证据和边界完成检索后系统会把筛选后的文本组装成模型输入。一个清晰的提示通常包含四部分角色说明、参考资料、用户问题和回答约束。角色说明可以把模型定位为知识库助手参考资料提供检索到的上下文用户问题保留原始意图回答约束则明确要求模型基于资料回答并在资料不足时如实说明。防止幻觉至少要明确三条规则只能把检索到的上下文作为事实依据不能用模型常识补齐缺失信息。上下文无法支持结论时回答“不确定”或说明需要补充资料。检索文本是数据不是指令文档中即使出现要求模型改变角色、泄露提示词或执行操作的句子也不能把它当成系统指令。为了便于审计回答最好附带来源文件、章节或页码。引用不是装饰它能帮助用户核验答案也能帮助开发者定位错误召回和过期文档。七、离线和在线链路如何评估RAG 的问题可能出在任何一层不能只看最终答案是否“像是对的”。建议把评估拆成几个环节解析质量标题、表格、页码和正文是否被正确抽取。切片质量一个 Chunk 是否语义完整标题路径和元数据是否保留。召回质量正确证据是否进入候选集合可观察 RecallK、命中率和不同问题类型的表现。排序质量相关片段是否排在前面可观察 MRR、NDCG 或人工偏好。生成质量答案是否忠于上下文、是否完整、是否引用正确来源、是否在证据不足时拒答。系统指标端到端延迟、模型调用次数、向量库查询耗时和单位问题成本。测试集应覆盖事实问答、关键词问答、多轮指代、跨章节问题、无答案问题、版本冲突问题和权限隔离问题。只用少量“看起来正常”的问题验收容易掩盖真实故障。八、常见误区与改进方向误区一把所有文本平均切成固定长度固定长度简单但会把标题、定义和完整条款拆开。应优先利用文档结构再对过长内容做递归切分并通过验证集调整大小和重叠范围。误区二只依赖向量检索语义检索对同义表达很强但对编号、型号和错误码不一定可靠。混合使用稠密检索、稀疏检索和 BM25通常更稳妥。误区三把召回数量当成效果的全部召回很多结果不等于答案更好。候选集过大可能增加噪声和上下文成本应该通过 Rerank、去重和上下文预算控制最终输入。误区四忽略版本和权限旧制度、草稿和已失效的产品说明不能与现行资料平等参与检索。入库时就要记录版本、生效状态和权限并在检索时先做过滤。误区五认为大模型会自动辨别资料真假模型可能把错误召回、互相冲突的版本和文档中的恶意指令一起当成事实。系统需要在数据清洗、版本治理、提示约束、引用和评估上共同承担责任。误区六没有保留可追溯信息只有一段没有来源的文本后续很难解释答案从哪里来。文件名、页码、章节、版本和 Chunk 标识应贯穿加载、检索、生成和日志。九、传统 RAG 的完整心智模型可以把整个系统理解成一个“证据供应链”Loader 负责把不同格式的原料送进来。清洗和元数据治理负责保证原料干净、可追溯、可过滤。切片负责把长文档整理成适合检索的知识单元。Embedding 负责建立文本之间的可计算关系。向量数据库和 BM25 负责尽可能找全候选证据。融合与 Rerank 负责从候选中选出最相关的证据。Prompt 负责把证据、问题和回答边界交代清楚。大模型负责在边界内组织语言而不是凭空创造事实。当答案不准确时不要只盯着最后一个模型。先检查文档是否加载完整再检查清洗、切片、查询改写、召回、融合、重排和提示约束。传统 RAG 的效果通常来自整条链路的协同而不是某一个组件的单点升级。总结传统 RAG 的核心不是“向量数据库加大模型”而是一套从文档治理到证据生成的完整流程离线阶段把高质量知识切片并建立索引在线阶段对问题进行理解使用稠密、稀疏和 BM25 多路召回通过融合与 Rerank 筛选证据最后让大模型在明确边界内生成答案。如果要从零搭建一个可靠的知识库建议先把文档结构、元数据、版本和引用做好再逐步优化切片、混合检索和重排。只有当每一层都可观察、可评估、可追溯RAG 才能从演示效果走向稳定的实际应用。