RAG 系统全链路知识地图 关联型知识地图 · 顺链路学 + 反向排障
01 / 10
RAG 主线总览

从大模型局限性
到可落地 RAG 系统

这是一张围绕 落地 与 排障 设计的 RAG 关联型知识地图。你可以按主链路顺着看，也可以从“召回差、幻觉高、Query 不清”这类问题反向定位相关环节。

视觉定调 亮底、蓝光、未来感、玻璃拟态、强层级标题、科技流线背景。
交互方式 横向翻页、滚动吸附、按钮跳转、卡片反馈、局部展开细节。
学习主链

先理解为什么需要 RAG，再看它如何从离线到在线跑通。

为什么需要 RAG → 整体架构 → 离线构建 → 在线检索 → 增强生成 → 评估落地
在线总链路： `用户问题 -> Query 改写/分解 -> 路由 -> 检索 -> 召回 -> 重排 -> 增强 -> 生成 -> 后处理`
离线前提链路： `原始数据采集 -> 文档解析 -> 数据清洗 -> 文本分割 -> 向量化 -> 索引/入库`
召回不准 / 召回太杂

先去看分块策略、搜索策略、最大召回数量、最小匹配度、重排与混合检索。

答案幻觉高 / 依据弱

优先回看证据召回质量、Prompt 组装、引用依据和生成后处理。

用户问题模糊 / 检索方向跑偏

先查 Query 改写、歧义消解、约束条件强化和领域术语适配。

结构化命中差 / 路由错

回到在线链路，看 Text-to-SQL、查询路由、结构化优先和多路查询拆分。

使用方式建议： 第一次按主链顺序通读，第二次从问题卡片反向排查。 页面内提供“上游 / 下游 / 相关点 / 排障入口”导航，方便你从任一知识点继续顺着链路看下去。
01 / Need

为什么需要 RAG

大模型会说，不代表它能稳定回答业务问题。RAG 的出现，本质上是为了弥补纯参数化记忆在时效性、私有知识、专业精度和可追溯性上的天然短板。

核心结论 RAG 不是替代模型，而是给模型增加外部知识访问能力。
01 时效性不足

训练后世界会变化，模型参数不会自动同步最新知识。

02 幻觉

在证据不足时，模型仍可能生成看似合理但事实错误的内容。

03 私有知识缺失

企业制度、工单、说明书、业务表单等不会天然存在于模型参数中。

04 来源不可追溯

纯大模型问答常常无法告诉你答案依据到底来自哪里。

能力演进
  • 1.0：Prompt → Response，只有单轮能力。
  • 2.0：加入上下文窗口，具备短期记忆和多轮对话。
  • 3.0：加入 CoT，更会推理和总结。
  • 4.0：接入外部知识库，也就是 RAG。
两类记忆
  • 参数化记忆：模型参数中学到的知识。
  • 非参数化记忆：外部知识库、向量索引、文档存储中的显式知识。
  • RAG 本质：把模型记忆和外部检索记忆结合起来。
下游去向
相关知识
排障入口
回到主链
02 / Architecture

RAG 的整体架构

RAG 由离线和在线两大阶段组成。离线负责“把知识准备好”，在线负责“把知识正确地找出来并生成答案”。

离线链路

Knowledge Base Build

采集 → 解析 → 清洗 → 分块 → 向量化 → 索引/入库

目标是把原始资料转成可被系统高效检索的知识资产。离线质量越差，在线上限越低。

在线链路

Query to Answer

Query → 改写 → 检索 → 召回 → 重排 → 生成

目标不是“让模型猜”，而是“让模型基于证据作答”。真正成熟的系统还会在最后加上后处理和引用标注。

经典 RAG 范式

RAG-Sequence

整个答案生成过程中，共享同一组检索文档，更适合理解为“先搜一批，再整体作答”。

RAG-Token

逐 token 生成时允许参考不同检索文档，灵活但更复杂。

核心认知

RAG 不只是“先搜后答”的粗流程，它在生成阶段内部也可以有不同耦合方式。

上游知识
下游去向
横向关联
排障入口
03 / Offline

离线知识库构建

离线阶段是整套系统的地基。它不直接回答用户问题，但决定了后面检索与生成的上限。

01 采集
02 解析
03 清洗
04 分块
05 向量化
06 索引入库
01

原始数据采集

先定义知识边界，再收资料。目标是让进入知识库的数据和业务问题强相关，而不是“先全量堆进去”。

  • 先区分核心资料、辅助资料、噪声资料，避免知识源失焦。
  • 优先收集高频问答、制度文档、产品说明、工单记录这类直接影响命中率的材料。
02

文档解析

把 PDF、Word、PPT、图片、扫描件等资料转成机器可读的结构化文本，并尽量保留标题层级与表格关系。

  • 这一步的关键不是“能不能读出字”，而是“结构有没有被读对”。
  • 标题、段落、表格、页眉页脚一旦混乱，后面分块和检索都会一起失真。
03

数据清洗

把“可读文本”进一步变成“可检索文本”，包括去重、去噪、脱敏、纠错和无关信息剔除。

  • 清洗不是装饰动作，它决定检索时会不会把无效页脚、旧版本、错别字一并召回。
  • 对企业场景来说，脱敏和版本管理往往和准确率同样重要。
04

文本分块

把长文档切成适合检索的 Chunk，平衡语义完整性、命中精度、窗口长度和后续 Token 成本。

  • Chunk 太小会丢背景，太大又会稀释主题，所以要跟文档类型和问题类型一起设计。
  • 制度、教程、说明书等结构化文档，通常更适合按标题和章节去切。
05

向量化

使用 Embedding 模型把文本映射到语义空间，让系统可以基于“意思相近”而不是只靠关键词匹配。

  • Embedding 负责“找相似”，不是负责生成答案。
  • 模型是否适配中文、垂直领域术语和长文本，会直接影响召回效果。
06

索引与入库

把向量、原文、元数据和结构标签一起存入可搜索系统，形成后续在线检索依赖的知识资产底座。

  • 真实工程里通常不只有向量索引，还会配合关键词索引、标签过滤和版本字段。
  • 这一步设计得越清楚，后面越容易做 Hybrid Search、召回控制和引用追溯。
企业内部
  • 历史文档
  • 业务系统数据
  • 在线知识库
  • FAQ、工单、客服记录
  • 邮件、会议纪要、IM 记录
外网公开
  • 行业网站、百科、论坛、新闻
  • 政府公开数据
  • 天气、地图、法律、财经 API
  • 公共数据集
付费外采
  • 行业报告
  • 专业数据库
  • 第三方知识服务
  • 用户问题样本

产品经理要定义什么

  • 知识边界
  • 核心数据源优先级
  • 来源标注规范
  • 质量验证标准

为什么这一步值钱

如果离线阶段收错数据、解析失真、清洗不到位、分块不合理，后面再怎么调检索和 Prompt，效果都只能在低质量地基上打补丁。

上游知识
下游去向
横向关联
排障入口
04 / Chunking & Vector

文本分块、向量化与索引

这是实践中最容易“听懂概念、但实际最影响效果”的部分。真正决定线上命中的，往往不是模型名字，而是 Chunk 设计和检索结构是否合理。

关键结论 Chunk 不是越小越好，索引也不是越复杂越好，一切都要围绕业务检索目标。
固定长度简单但容易切断语义；语义感知更自然；文档结构适合制度和说明书；多粒度适合“小搜大”；混合分块最接近真实工程。
短块更精准但容易丢背景；长块背景更完整但噪声更大；重叠窗口能缓解边界损失，但会增加冗余和成本。
Contextual Retrieval 解决的是 Chunk 脱离语境后检索失败的问题；Late Chunking 则尝试先用更长上下文编码，再在后部切分出 Chunk 表示，以保留更多上下文信息。
向量化

Embedding 不是生成

Embedding 模型负责把文本映射到向量空间，用于相似度匹配，不负责自然语言答案生成。

Dense Retrieval

从关键词走向语义

以 DPR 为代表的 Dense Retrieval，让 Query 和 Passage 映射到同一语义空间，是现代语义检索的核心范式之一。

索引

HNSW / kNN / 元数据过滤

真实检索往往不是只有“最近邻”，而是向量相似度、元数据过滤和排序策略的组合。

进阶补充

为什么不能全量召回

原因不是“不能搜到”，而是 上下文放不下、成本太高、噪声太多。所以离线分块的意义，就是把大文档提前拆成可按需调用的片段，问题问到哪一块，就优先召回哪一块。

大小切片

父子 Chunk / 小搜大

说明书、手册这类复杂文档往往不是只切一层，而是 大切片保留背景，小切片负责精准命中。先用小切片找方向，再回捞对应的大切片，是典型的提准思路。

上游知识
下游去向
横向关联
排障入口
05 / Online

在线链路：从 Query 到 Answer

在线阶段是真正被用户感知到的部分。它不是“一问一答”，而是一条由改写、路由、检索、召回、重排、增强和生成组成的复合链路。

主链路
用户 Query → 改写 / 分解 → 查询路由 → 查询构建 → 检索 → 召回 → 重排 → 增强 → 生成
路由

当一个 Query 被改写或拆解后，系统要决定每个子问题走哪条路径：查结构化数据库、查向量数据库，还是走多路查询。

查询构建

典型路径包括 Text-to-SQL 与 Text-to-Embedding。前者面向明确字段和精确条件，后者面向语义相似和模糊表达。

关键原则： 能走结构化检索的，优先走结构化检索。 原因是准确率更高、成本更低、稳定性更强。不是所有问题都应该直接扔给向量检索或大模型。
路由例子

复杂问题先拆，再分路执行

举个例子：“气候变化的影响”这种问题。它不是一个单路查询，而是可以拆成“对天气的影响”“对经济的影响”等多路子问题，再把结果合并后交给模型生成最终答案。

产品重点

规则决定系统如何理解“最近”“更高”“更多”

这类词不是算法自己知道的，而是产品要定义业务规则。比如“最近”到底指 7 天、30 天还是当前季度，这会直接影响改写、路由和最终答案。

上游知识
下游去向
横向关联
排障入口
06 / Query

Query 改写与增强

这是产品最容易介入、也最容易直接提升准确率的地方。用户的表达往往模糊、缺信息、多意图，必须先改写，后检索。

语义强化

通过同义词扩展、语义改写、实体链接等方式，丰富 Query 的表达。

歧义消除

识别多义词、指代不明、语境缺失问题，避免搜错方向。

上下文补全

补回被用户省略、但检索系统必须依赖的关键信息。

意图拆解

把一个复杂问题拆成多个子问题，分别搜，再合并结果。

领域术语适配

把通俗表达转成更适合业务知识库理解的专业术语。

约束条件强化

补全时间、地点、范围、评分、格式等限制条件。

HyDE

让“假想文档”帮你检索

HyDE 的思路不是直接拿 Query 去检索，而是先让大模型生成一段“假想答案文档”，再对这段文档做 embedding，用它去找真实文档。适合 Query 很短、很抽象、缺乏相关标注时的零样本检索。

规则归属

Query 改写不是“算法自己决定”，而是： 产品规则 + 数据标注 + 模型能力 的结合。产品经理负责定义目标、规则与业务边界，技术团队负责把规则真正做进系统。

补充说明： Query 改写不是让模型“随便换个说法”，而是围绕业务规则补信息、去歧义、拆意图。 尤其像“最近”“哪个好”“流程是什么”这类问题，产品要先定义清楚业务边界，系统才能稳定回答。
上游知识
下游去向
横向关联
排障入口
07 / Retrieval

检索、召回、重排

真正成熟的 RAG 检索系统，不是只做一次向量搜索，而是把稀疏检索、稠密检索、召回、精排、结果融合组合起来，服务最终答案质量。

核心公式化理解 Sparse + Dense + Rerank + Fusion
Sparse 用 BM25、倒排索引抓住术语、编号、关键词这类精确命中。
Dense 用 Embedding 抓语义近邻，覆盖自然语言表达和模糊描述。
Fusion 把多路召回结果拼起来，常见做法是 Hybrid Search 和 RRF 融合。
Rerank 在候选集合上重排优先级，把“看起来像”变成“真正最相关”。
Sparse Retrieval

BM25 / 倒排索引

依赖词项匹配，对专有名词、型号、术语编号尤其有效。

Dense Retrieval

Embedding 检索

依赖语义相似，适合自然语言问题、模糊表达和语义近义匹配。

Hybrid Search

混合检索

最常见的真实含义之一，就是 Sparse + Dense 一起用。

召回与 Top-K

  • 召回是先把可能相关的候选片段捞回来。
  • Top-K 不是越大越好，它在平衡召回率、噪声和 Token 成本。
  • Score 阈值 用于过滤低相关结果，但不同平台分值不可直接横比。

Rerank 与 RRF

  • Rerank 在候选集合上重新打分排序。
  • Embedding 负责“找相似”，Rerank 负责“重排优先级”。
  • 混合检索结果合并常用 RRF，它基于排名融合而不是简单平均分。
调用方式

自动召回 vs 按需召回

实践中有“每轮自动召回”与“按需从特定知识库召回”两种方式。前者省操作，后者更可控，适合多知识库和高成本场景。

搜索策略

混合语义 vs 全文关键词

语义适合模糊表达，全文适合术语、编号、关键词精确命中。真实产品里通常不是二选一，而是看场景组合使用。

最大召回数量

Top-K 是召回上限，不是越大越好

通过 3、5 这样的数量演示召回条数变化。数量越大，覆盖面更广，但噪声、成本和后续重排负担也会升高。

最小匹配度

Score 阈值决定放行线

你真正要管的是“门槛设多少”，不是分数如何计算。算法负责打分，产品负责结合场景确定放行阈值。

上游知识
下游去向
横向关联
排障入口
08 / Generation

增强、生成与系统优化

检索完并不代表系统已经成功。真正的关键在于：如何把证据组织进 Prompt，并让模型输出结构清楚、依据明确、尽量不编造的答案。

一句话 检索好只是开始，Prompt 组装和生成控制是最后一公里。
RAG 的生成阶段不是把片段机械拼起来，而是基于任务定义和约束，让模型围绕证据作答。
如果后处理缺失，系统很容易出现“内容对但表达乱”“引用缺失”“格式不统一”等问题，影响实际可用性。
多轮对话不是 RAG 本身，但会显著影响 Query 理解、检索方向和最终答案一致性，因此企业级应用通常会把对话状态跟踪与 RAG 一起设计。
优化策略

小切片 / 大切片

小块负责精准命中，大块负责补充背景，是“小搜大”“父子 Chunk”类策略的核心。

多路查询

复杂问题先拆再搜

适合对比型、多条件、多跳问题，能提升复杂问题的检索质量。

可追溯

引用与依据

成熟的 RAG 系统不只要答对，还要告诉用户：依据来自哪里、是否可回查。

补充

增强不只发生在生成前一刻

强调一点：“增强在各个环节都有”。除了 Prompt 组装，还包括 Query 增强、跨域增强、功能态增强等。它本质上是在不同节点把系统往“更容易答对”方向推。

生成控制

先保证 grounded，再追求文采

对工作场景来说，答案首先要基于证据、结构稳定、能回查来源；表达润色和可读性，是在此基础上的第二层要求。

上游知识
下游去向
横向关联
排障入口
09 / Evaluation

评估、调优与延展阅读

一个 RAG 系统要真正可用，不只是“看起来能答”，而是要能评估、能定位问题、能持续优化。

评估指标
  • 检索侧：Recall@K、Precision@K、MRR、nDCG
  • 生成侧：Groundedness、Relevance、Completeness、幻觉率
  • 工程侧：时延、Token 消耗、成本、稳定性
调优闭环
  • 先选一个明确场景
  • 做代表性问题集
  • 先看检索是否命中正确证据
  • 再看答案是否 grounded
  • 一次只改一个变量再复测
权威延展阅读

从知识地图走向个人知识体系

01
Lewis et al. — Retrieval-Augmented Generation 理解参数化记忆 / 非参数化记忆、RAG-Sequence、RAG-Token。
02
Karpukhin et al. — Dense Passage Retrieval 理解现代 Dense Retrieval 的基本范式。
03
ColBERT / HyDE / Contextual Retrieval / Late Chunking 继续补齐精排、Query 扩展、Chunk 语境保持这几条重要进阶线。

这一页系统梳理了 RAG 从离线构建到在线检索、增强生成与评估落地的完整链路，可作为项目复盘与实战应用时的产品视角参考。

上游知识
问题入口
回到主链
继续延展