"检索增强生成"六个字人人会念，但一份 PDF 从进知识库到变成答案要经过几个环节、每个环节坏了会什么表现，能说清的人不多。这篇把 RAG 拆成七步链路，重点讲三个高频坑的定位方法——检索层的故障和生成层的故障要分开看，混在一起调会白费功夫。
七步链路：离线四步、在线三步
建库是离线活，答题是在线活，两段各自独立：
| 阶段 | 步骤 | 做什么 | 易错点 |
|---|---|---|---|
| 离线 | 1 解析 | PDF/Word/网页转纯文本 | 表格、扫描件、多栏排版 |
| 离线 | 2 切分 | 长文切成几百字一块 | 把语义劈开 |
| 离线 | 3 向量化 | 每块变成语义向量 | 模型与语言不匹配 |
| 离线 | 4 入库 | 存入向量库 | 维度不一致 |
| 在线 | 5 召回 | 问题向量化取 Top-K | 用词不重合搜不到 |
| 在线 | 6 重排 | 精排留最相关几条 | 最常被省略的一步 |
| 在线 | 7 生成 | 资料拼 Prompt 交给模型 | 脱离资料自由发挥 |
第 6 步值得单独说：向量检索快而粗，适合从十万条里筛出五十条；重排模型慢而准，适合从五十条里挑五条。先用便宜的筛再用贵的精排，是标准工程折中。省掉重排的 RAG 系统，答案质量上限直接降一档。
三个坑的定位方法
坑一：切分断语义。 一句话被劈成两块，两半都不完整，召回和生成都受影响。解法按标题层级切分、块间留 10% 重叠；进阶方案是父子文档——小块负责被搜到，命中后把父级大块交给模型，检索精度和上下文完整度同时保住。
坑二：召回不准。 用户问"报销怎么走"，文档写"费用核销流程"，语义接近但字面零重合，纯向量检索经常败给关键词。混合检索（向量+BM25）不是锦上添花，是必需品；查询改写（把口语转成检索词）和 HyDE 也在同一武器库里。
坑三：不按资料答。 检索明明是对的，答案还是编的——问题出在生成段。解法是在 Prompt 里强制"只依据材料回答"、要求带引用出处、温度调低。这个坑最容易被误诊：检索指标看着都好，于是反复调向量库，实际该调的是生成 Prompt。
定位口诀：先分开看检索命中和生成忠实度。检索层用"该找到的段落排进 Top-K 了吗"衡量；生成层用"答案里的每个断言都能在检索结果里找到出处吗"衡量。两段各自归因，才不会一直在错误的方向上使劲。
进阶四件套的适用边界
GraphRAG 解决"跨文档归纳"类问题（"这批合同的风险集中在哪"），普通段落检索对这类整体性问题是失效的；Agentic RAG 把检索变成 Agent 的工具，让模型自己决定查不查、查几轮；多模态 RAG 处理截图和扫描件。长上下文时代的常见疑问"还要 RAG 吗"——要。窗口大也贵也慢，且长上下文的中间内容容易被忽略，业界的分工是长上下文负责精读几篇，RAG 负责从十万篇里定位。
企业知识库的验收基线
落一套企业知识库，验收别只看"答得像不像"：按部门、时间、权限过滤是否生效（元数据入库时就该一起存）；无据可答时是否明确拒答而非硬编；权限越界的文档是否零泄露。这三条比准确率更能区分玩具和能上生产的系统。
评论0