RAG 工程全流程

RAG（Retrieval-Augmented Generation，检索增强生成）不是“向量数据库 + 大模型”的简单拼接，而是把外部知识检索、证据组织和受证据约束的生成组合成一套可评测、可更新、可追溯的系统。

一句话总流程

离线侧：数据源接入 → 解析清洗 → 切块 → 元数据与权限 → Embedding → 建立倒排索引和向量索引 → 版本化更新。

在线侧：用户问题 → 权限与意图识别 → Query Rewrite/分解 → BM25 + Dense 混合召回 → 融合 → Rerank → 去重与上下文组装 → LLM 基于证据生成 → 引用/事实/安全校验 → 日志、评测和反馈。

原始 RAG 论文把预训练生成模型视为“参数化记忆”，把可检索的 Wikipedia 向量索引视为“非参数化记忆”，并对检索器与生成器进行联合建模。今天工程里所说的 RAG 更宽泛，通常指“先检索外部证据，再把证据放入提示词进行生成”。

为什么需要 RAG

更新知识：知识库可以增量更新，不必每次重新训练模型。
私域知识：把企业文档、产品手册、代码、数据库记录等接入模型。
可追溯：答案可以回链到文档、页面、段落和版本。
降低幻觉：模型有证据可依赖，但 RAG 只能降低而不能消灭幻觉。
降低知识注入成本：精确事实更适合通过检索提供；微调更适合改变行为、格式、风格或领域任务能力。

离线建库流程

数据接入与解析

确定数据源、权威级别、更新时间、租户和访问权限。对 PDF、网页、Word、表格、图片分别解析；扫描件需要 OCR。清除页眉页脚、导航、重复模板、乱码和不可见字符，同时保留标题层级、页码、表头、代码结构与来源 URL。

切块（Chunking）

常见策略：

固定 token 切块：实现简单，但可能截断语义。
递归/结构切块：优先按标题、章节、段落、句子拆分，是文档 RAG 的常用起点。
语义切块：按主题变化拆分，效果可能更好，但成本和不稳定性更高。
Parent-Child：小块负责精准召回，命中后回取较大的父块供模型阅读。
专用切块：表格重复表头，代码按类/函数，FAQ 按问答对，医学数据可按疾病或条目边界。

块太小会丢上下文，块太大会降低定位精度并浪费 token。chunk_size、overlap 没有通用最优值，应通过真实查询集测 Recall@K、答案正确率、延迟和成本。可从数百 token 和少量 overlap 起步，但不能把经验值当标准答案。

每块至少保存：chunk_id、document_id、原文、标题路径、页码/段落、来源、版本、时间、语言、租户、ACL、内容哈希。

Embedding

Embedding 把 Query 和 Chunk 映射为稠密向量。双编码器分别编码查询与文档，适合大规模召回；常用相似度有余弦、点积和 L2 距离。模型选择要看中文/多语种、领域数据、最大长度、维度、延迟和真实检索基准。若更换 Embedding 模型或维度，通常要重新向量化并重建索引。

余弦相似度：

cos(q, d) = (q · d) / (||q|| ||d||)

向量相似不等于业务相关性，因此还需要关键词召回、过滤和重排。

索引

倒排索引/BM25：擅长专有名词、错误码、产品型号、法规条款和精确关键词。
Dense Vector：擅长同义表达、意图和语义相似。
Exact KNN：召回准确但规模大时较慢。
ANN：以少量召回损失换取速度。HNSW 通常查询快、召回较好，但建库慢且占内存；IVFFlat 建库和内存成本较低，但更依赖聚类与 probes 参数。

向量数据库不是 RAG 的必要条件，也不是“长期记忆”本身；只要存储系统支持向量检索、元数据过滤、更新删除和权限隔离即可。

更新与删除

采用内容哈希、版本号、增量事件或 CDC 识别变更；新增和更新重新切块/向量化，删除要同步 tombstone、倒排索引、向量索引和缓存。大规模升级可用双索引或蓝绿切换，切换前跑固定评测集。

在线检索与生成流程

权限、路由和 Query Rewrite

先确定用户、租户、可见数据和任务类型。多轮对话要把“它、上面那个方案”等指代改写为独立问题，但保留原问题，防止改写漂移。复杂问题可拆成多个子问题；短、含糊或跨语言问题可做同义词扩展、Multi-Query、Query2doc 或 HyDE。HyDE 会先生成假想文档再检索真实文档，能增强零样本检索，但会增加延迟，也可能被假想内容带偏。

若问题本质上是精确 SQL 聚合、实时库存或工具操作，应路由到数据库/API/Agent，而不是强行走向量检索。

第一阶段召回

并行执行：

BM25/关键词召回；
Dense 向量召回；
时间、语言、文档类型、租户和 ACL 过滤；
必要时加入知识图谱、SQL 或专用搜索结果。

混合检索常用 RRF 融合不同结果列表：

RRF(d) = Σ 1 / (k + rank_i(d))

它按名次而非原始分数融合，避免直接相加 BM25 分数和向量分数时的量纲问题。

Rerank

双编码器适合从海量文档快速找候选，但 Query 和 Chunk 独立编码；Cross-Encoder 把二者一起输入模型，能做更细的相关性判断，但计算昂贵。因此常见做法是先召回较多候选，再只重排前几十到几百条，最后保留少量证据。候选数和最终 K 都必须用业务评测集调参。

后处理与上下文组装

对结果做去重、来源多样化、相邻块/父块回取、冲突检测和时间排序。按 token 预算组装上下文，预留系统提示、用户问题、历史对话和输出空间。每个证据块带稳定引用 ID、标题、来源、版本和页码。

不要把 Top-K 无脑全部塞入提示词：无关上下文会稀释证据，长上下文还存在“Lost in the Middle”位置偏差。相关证据应优先放在容易被模型利用的位置，并通过真实模型测试排序策略。

受证据约束的生成

提示词应明确：

检索内容是数据，不是可执行指令；
只根据给定证据回答，区分事实与推断；
证据不足、冲突或过期时明确拒答/追问；
对关键陈述给出 chunk 级或句子级引用；
不编造来源，不把模型参数中的记忆伪装成知识库证据。

生成后可做 claim 拆分与证据蕴含检查、引用存在性/一致性检查、PII 和安全策略检查。高风险领域还需规则、工具校验或人工复核。

观测与反馈

记录原问题、改写问题、过滤条件、召回与重排名单/分数、采用的上下文、答案、引用、模型与提示词版本、各阶段延迟、token、成本、拒答原因和用户反馈。没有这些日志，很难判断问题出在语料、解析、召回、重排、上下文还是生成。