要做一个知识库问答（RAG），离线建库 + 在线检索各环节怎么落地、有哪些坑？本指南把 RAG 全系列概念页（RAG、RAG运转流程 及 6+4 各环节）整合成一份端到端 checklist：离线 6 环节 + 在线 4 环节，每环节给"PM 要确认什么 + 常见坑 + 验收点"，不新增方法。

一句话心法：离线决定上限（一次性投入，质量越高线上 badcase 越少），在线决定单次延迟与成本；二者靠同一个 Embedding 模型对齐。

适用场景

核心原则：RAG 是"垃圾进、垃圾出"——检索质量直接决定回答质量，90% 取决于知识库质量。

步骤总览

前置准备

• 业务场景已明确（这个问答助手服务谁、回答什么类型的问题）
• 业务方愿意提供核心数据源，并能配合专家抽样校验
• 法务可对接（公开/付费数据的版权与合规）
• 已选定一个 Embedding 模型，并约定离线与在线用同一个

离线建库（6 环节，一次性 + 增量更新）

环节 1：数据采集

PM 要确认：

• 知识边界——只采与业务场景强相关的数据（无关数据进库只会拉低召回质量）
• 数据来源三分法：企业内部（历史文档/业务系统/在线知识库/FAQ/邮件）、外网公开（爬虫/API/公开数据集）、付费外采（行业报告/专业数据库）
• 接入方式：文件类 / 数据库（增量拉取靠时间戳或 CDC）/ API（认证、限流、重试、幂等去重）
• 元数据强制：每条记录来源 ID、采集时间、所有权类型，为检索过滤、答案引用、合规审计兜底

常见坑：

• 贪多采无关数据 → 噪声拉低召回
• 不记元数据 → 后续没法做权限过滤、答案没法溯源
• 公开网页数据没过法务 → 版权风险

验收点：

• 知识边界与业务场景对齐，无明显噪声源
• 每条数据带来源 ID / 采集时间 / 所有权类型
• 公开 / 付费数据版权已过法务

环节 2：文档解析

PM 要确认：

• 目标：完整提取内容并保留基础结构（表格行列关系、章节层级）
• 按文档类型定提取重点：PDF（多栏排版、阅读顺序，扫描版需 OCR）、Word（标题层级/表格）、PPT（多文本框）、HTML（去标签去广告）、扫描件（OCR）
• 复杂排版阅读顺序方案选型：版面分析+规则排序（快、但难处理混排）vs 按顺序生成文本（处理纯文字好、但慢）
• 定保真度优先级：哪些结构必须保留（表格行列、章节层级），哪些可丢（页眉页脚）
• 与算法侧定义"解析失败"判定标准 + 人工处理流程

常见坑：

• 多栏 PDF 按行读取 → 阅读顺序错乱
• 扫描件没上 OCR → 内容丢失
• 表格被拍扁成乱序文本 → 行列关系丢失

验收点：

• 表格行列、章节层级等关键结构已保留
• 扫描件 / 图片走了 OCR
• "解析失败"判定标准 + 人工兜底流程已定

环节 3：数据清洗

PM 要确认（核心原则：保留语义核心，剔除无关信息）：

• 清洗 4 项：删冗余（页眉页码/重复段落）、内容改写（错别字/语法/补全缩略语）、格式标准化（UTF-8、日期、表格转"表头:内容"、公式转 LaTeX）、敏感信息过滤（身份证/手机号/密码脱敏）
• 质量校验三件套：自动校验（解析后文本长度 ≥ 原文 90%、表格列数一致）、人工抽样（专业术语/公式/特殊符号，比例 ≥ 3%、专业文档 ≥ 10%，业务专家参与）、异常处理（模糊图片/加密文档触发人工干预）

常见坑：

• 不脱敏 PII → 合规风险，敏感信息进库被检索出来
• 不做专家抽样 → 专业术语解析错没人发现
• 清洗过度把语义核心也删了

验收点：

• PII 已脱敏
• 自动校验通过（文本长度 ≥ 90%、表格列数一致）
• 专家抽样比例达标（≥3%，专业文档 ≥10%）

环节 4：文本分割（Chunking）

PM 要确认（核心：语义边界优先，长度适配模型）：

• 三要点：语义完整性（按段落/章节/句子等自然边界，别把"结论"和"论证"拆开）、长度适配（中文一般 300-800 字，按业务调整；客服 FAQ 配 Sentence-BERT 约 150-250 字）、重叠窗口（相邻 chunk 设 10%-20% 重叠，优先保留上下文衔接句）
• 选分块策略：固定长度 / 语义感知 / 文档结构 / 关键词主题 / 多粒度 / 混合分块
• 复杂文档优先多级切分：先按章节/标题切大块，再按语义切子块（章/节/句三级），缓解"一套规则只适配一种格式、参数敏感、易截断"的问题
• 定 chunk 元数据核心字段；推动建立"分割规则按检索反馈迭代"的机制

常见坑：

• 纯按字数硬切 → 语义被截断、信息不完整
• 一套规则套所有文档 → 格式一变就崩
• 没设重叠窗口 → 跨 chunk 的上下文丢失

验收点：

• chunk 长度匹配所选 embedding 模型输入限制
• 设了 10%-20% 重叠窗口
• 复杂文档用了多级 / 混合分块，抽查无语义截断

环节 5：文本向量化

PM 要确认：

• 选 embedding 模型（常用 BGE / M3E / OpenAI text-embedding-3 / Sentence-BERT），评估效果与成本，输出选型建议
• 相似度度量：RAG 主流用余弦相似度（只看方向不看长度）
• 关键铁律：在线 Query 端必须用与离线分块完全一致的 embedding 模型，否则距离不可比
• 制定向量质量监控指标（相似度、稳定性）

常见坑：

• 离线和在线用了不同 embedding 模型 → 检索距离不可比，召回全乱（最隐蔽的坑）
• 只看效果不算成本 → 大库向量化成本失控

验收点：

• embedding 模型已选型，效果 / 成本有依据
• 离线在线锁定同一模型
• 向量质量监控指标已定

环节 6：向量索引构建

PM 要确认：

• 按业务需求（检索速度 / 精度 / 数据量 / 部署成本）选索引：树状（低维、精度高）、哈希 LSH（快、省、精度低有漏检）、图索引 HNSW（速度精度兼顾，RAG 主流，Milvus/Pinecone 默认）、聚类 K-Means（千万级超大规模）、关键词倒排（字面匹配）
• 存储常混合：向量库（Milvus/Pinecone/Weaviate/FAISS）做语义模糊匹配 + 关系库（MySQL/PG）存元数据做精确过滤（时间/权限）
• 定索引参数调优评估标准；协调索引构建期的业务中断风险

常见坑：

• 超大规模还用树状索引 → 高维检索效率塌方
• 只建向量库不留元数据库 → 没法按权限/时间过滤
• 索引参数没评估标准 → 调优凭感觉

验收点：

• 索引类型与数据规模 / 速度精度需求匹配（默认优先 HNSW）
• 向量库 + 元数据库混合方案已定（支持过滤）
• 索引参数调优有评估标准

在线检索生成（4 环节，每次用户提问触发）

环节 7：Query 改写

PM 要确认（是决定召回上限的第一道关口）：

• Query 向量化 6 动作：接收原始 Query → 清洗（去符号/emoji）→ 多轮上下文融合 → Query 增强 → 调 embedding（同离线模型）→ 缓存命中
• Query 增强 6 方法按需选：语义强化、歧义消解、上下文补全、意图拆解、领域术语适配、约束条件强化
• 改写路线选型：seq2seq（快、效果一般，适合高 QPS/延迟敏感）vs Few-Shot+CoT（准、慢且贵，适合高客单价/准确率优先）；多数工业场景混合：seq2seq 兜底 + 关键 Query 用 LLM 改写

常见坑：

• 多轮对话不做上下文补全 → "明天呢？"这类省略 Query 检索失败
• 一词多义不消歧 → "Java 怎么泡"检索方向跑偏
• 不做缓存 → 高频 Query 重复跑全链路，浪费延迟和成本

验收点：

• 多轮场景做了上下文补全
• 改写路线与 QPS / 客单价匹配
• 高频 Query 走了缓存

环节 8：召回检索

PM 要确认：

• 检索策略：纯向量 / 关键词 BM25 / 混合（向量召回 + 关键词召回并行，结果融合）
• 复杂 Query 用多重查询（派生近邻子查询）或查询分解（拆独立子问题分别检索再融合）
• 多路召回结果用哈希表合并去重：键=文档唯一标识，值=整合信息（得分/内容/召回路径/是否多路命中）
• 明确检索目标（搜什么、怎么算成功），制定质量标准（如召回率 ≥ 90%、准确率 ≥ 85%）

常见坑：

• 只用纯向量、漏掉关键词路 → 精确名词/编号类查询召回差
• 多路召回不去重 → 同一文档重复占满上下文预算
• 没定召回率/准确率验收线 → 检索好坏说不清

验收点：

• 检索策略明确（推荐混合检索）
• 多路结果用哈希表合并去重
• 召回率 / 准确率有量化验收线

环节 9：重排

PM 要确认（重排序漏斗是工程降本核心）：

• 漏斗分层：ALL Item（百万/千万级）→ 快速筛选→ 召回（万级）→ 轻量模型→ 粗排（千级）→ 复杂模型→ 精排（八十级）→ 后处理→ TOP 5-10
• 每层用复杂度递增的模型，越往后越精越贵，靠前置层先砍候选量
• 降本可用二级片段法：chunk 切三级，先检索二级片段，若 Top-K 中超 n 个属同一一级片段则用一级片段替换（拿主题完整语义），独立二级片段不输出

常见坑：

• 不做重排，直接拿向量 Top-K 当最终结果 → 相关性不够、精排缺失
• 漏斗层级设计不合理，前置层没砍量 → 精排模型在海量候选上跑，成本爆炸

验收点：

• 召回→粗排→精排漏斗已分层，模型复杂度递增
• 最终输出收窄到 TOP 5-10
• 评估过是否需要二级片段法降本

环节 10：组装生成

PM 要确认——分组装、生成、后处理三段：

① 上下文组装（3 动作）：

• 整理 chunks：去重、阈值过滤（如相似度 <0.78 丢弃）、截断（按预算保前 N）、多样性控制（同文档最多保 N 个，避免单一来源）、重新分配 ID（chunk_142 → [doc-1]）
• 加载 Prompt 模板 5 段：System Prompt（角色+规则+风格）、Reference Context（[doc-N] 含来源）、Conversation History（最近 N 轮 / N 轮+更早摘要）、User Query（用分隔符+角色锁定，防 prompt 注入）、Output Format（自然语言 或 JSON：answer/citations/confidence/need_human_followup）
• 注入兜底策略：资料不足时明确回复"无法判断、建议联系 XX"，禁止用预训练知识猜测

② 生成：

• 模型路由（route_model）：空召回用小模型、要计算用大模型+Tool、多轮 follow-up 用中等模型、召回多+问题复杂用大模型
• 参数：temperature=0.1（保事实稳定）、max_tokens=800、stream=True、top_p=0.9
• 流式 4 要点：首字延迟 <1s（核心指标）、中断处理（用户关页面要优雅取消停止烧 token）、错误处理（流到一半挂了提示重试）、完整性校验（JSON 能否 parse）

③ 后处理 4 步：引用关联（[doc-N] → 可点击链接 + hover 预览原文）、Markdown 渲染、敏感词/PII 过滤（扫手机号/身份证/薪资）、格式校验（JSON 不能 parse 走兜底重试/降级）

常见坑：

• 没写兜底策略 → 资料不足时模型用预训练知识硬编，幻觉
• 所有 Query 一律用大模型 → 成本高、延迟大（该用路由）
• temperature 设高 → 事实性回答不稳定
• 不做引用关联 → 答案没法溯源，用户不信
• 不过 PII 过滤 → 答案里意外暴露隐私

验收点：

• chunks 经去重 / 阈值过滤 / 多样性控制 / 重分配 ID
• Prompt 含 5 段结构 + 兜底策略
• 模型走路由，temperature 低、流式开
• 首字延迟 <1s
• 后处理做了引用关联 + PII 过滤 + 格式校验

RAG 落地检查表（可复制总表）

# RAG 落地检查表：[项目名称]

## 离线建库
[环节1 采集]   □ 知识边界对齐  □ 元数据(来源ID/时间/所有权)  □ 版权过法务
[环节2 解析]   □ 关键结构保留  □ 扫描件OCR  □ 解析失败兜底流程
[环节3 清洗]   □ PII脱敏  □ 文本长度≥90%校验  □ 专家抽样≥3%(专业≥10%)
[环节4 分割]   □ 长度适配模型  □ 10-20%重叠窗口  □ 复杂文档多级切分
[环节5 向量化] □ embedding选型(效果/成本)  □ 离线在线同一模型  □ 向量质量监控
[环节6 索引]   □ 索引类型匹配规模(默认HNSW)  □ 向量库+元数据库混合  □ 调优评估标准

## 在线检索生成
[环节7 Query] □ 多轮上下文补全  □ 改写路线匹配QPS/客单价  □ 高频缓存
[环节8 召回]  □ 混合检索策略  □ 哈希表合并去重  □ 召回率/准确率验收线
[环节9 重排]  □ 召回-粗排-精排漏斗  □ 收窄TOP5-10  □ 评估二级片段法降本
[环节10 生成] □ chunks整理(去重/过滤/多样性/重ID)  □ Prompt5段+兜底
              □ 模型路由  □ temperature低+流式  □ 首字延迟<1s
              □ 后处理(引用关联+PII过滤+格式校验)

## 全局对齐
□ 离线在线锁定同一 embedding 模型（最易忽略的致命坑）
□ 数据全程带元数据，答案可溯源
□ 资料不足有兜底，不用预训练知识硬编

常见坑（全局汇总）

完成检查清单

建库前：

• 业务场景与知识边界已明确
• embedding 模型已选定，离线在线统一
• 法务、业务专家已对接

上线前：

• 离线 6 环节验收点全过
• 在线 4 环节验收点全过
• 召回率 / 准确率达到验收线
• 首字延迟 <1s，兜底策略 + 引用溯源到位
• 全局对齐三项（同模型 / 带元数据 / 有兜底）确认

相关页面

→ RAG（RAG 是什么、解决截断/未知/幻觉三类问题） → RAG运转流程（四阶段 + 10 Pipeline 全景） → RAG数据采集（环节 1） → RAG文档解析（环节 2） → RAG数据清洗与文本分割（环节 3+4） → RAG向量化与索引（环节 5+6） → Query增强与改写（环节 7） → RAG检索-组装-生成（环节 8+9+10）