RAG 到底值不值得上？先搞清检索和生成的分工

经常有人问我们，RAG 是不是把公司的文件夹丢给大模型，让它自己学一遍。不是这样。RAG（Retrieval-Augmented Generation，检索增强生成）的逻辑很朴素：用户提问后，系统先去文档库里翻出和这个问题最相关的那几段原文，再把这几段话连同问题一起交给模型，让模型照着材料回答。

分工也就清楚了。检索负责找对那一页，生成负责把找到的内容说成人话。打个不太严谨但好用的比方——这是一场开卷考试，模型是考生，文档库是那本书。考生再会写，书里没有的东西也写不出来；书里页码贴错、同一道题有三个版本互相打架，他抄出来的答案照样是错的。所以我们后面会反复讲一句话：RAG 的效果上限由文档质量决定，跟用哪个模型关系没那么大。

检索和生成，各自会怎么失败

上系统之后出的问题，八成能归到下面四个环节里的一个。分清楚是谁的责任，才不会一出问题就去换模型。

环节	它在干什么	出问题时你看到的现象	常见原因
解析入库	把 PDF、Word、网页、系统记录切成片段，附上来源和权限	答案里出现半句话、表格串行、页眉页脚混进正文	扫描件没做 OCR、按固定字数硬切、跨页表格没合并
检索召回	用向量加关键词，把最相关的几段捞出来	明明文档里有，它说不知道	切片太碎丢了上下文、同义说法没覆盖、只用了向量没上关键词
生成	把片段读成答案，标出处	答案大方向对，但张冠李戴、引用页码错	片段没带来源元数据、提示词里没写死「只根据给定材料回答」
兜底	检索不到时如实说没有	模型开始编	没有拒答规则，模型被要求「尽量给出答案」

什么场景适合上 RAG

共同特征只有一条：答案本来就躺在文档里，用户的问题是「在哪一页」，不是「怎么推」。这类需求落地周期短，通常两到四周能跑出可用版本，具体看你文档有多乱、整理意愿有多强。

• 制度与流程查询。报销标准、请假规则、设备报修走哪条线。这类问题要求一字不差，模型自由发挥反而是风险。
• 产品与技术资料问答。参数、兼容型号、常见故障码。销售和售后在一线翻 PDF 太慢，让他们打字问更快。
• 合同、招投标、资质库。「哪份协议约定了 60 天账期」「哪个资质明年到期」，属于典型的定位型问题。
• 客服与工单辅助。把历史工单和高频处理方案一起入库，坐席边聊边查，新人上手速度差别很明显。
• 需要给出出处的场合。RAG 能返回原文片段，人能复核。这点在有合规要求的行业里，比答案漂不漂亮重要得多。

哪些事别指望 RAG

这块我们踩过坑，说具体些。

强推理和计算。「算一下这三条产品线的毛利率变化并解释原因」——这要读全量数据做聚合，检索只能捞回几段，算不出来。正确做法是让它调用数据库或走 SQL 工具，检索在这里帮不上忙。

跨多份文档的逐条比对。「把 12 家供应商的框架协议逐条对比，列出对我方不利的条款」。文档一多，检索一次只能带回有限片段，必然漏。这类要做的是先抽成结构化字段再比对，是工程活，不是检索活。

需要全局视野的汇总。「总结今年客户投诉的主要类型」，本质是聚类和统计，跟检索是两条路。

文档本身就没写清的事。口径没统一、口头约定没落纸，模型不会比你更懂你们公司。这时候上系统，只是把混乱放大一遍。

效果上限由文档质量决定，不是模型决定

这句话听起来像口号，拆开看全是具体的活。

• 扫描件和图片型 PDF。不做 OCR 等于没这份文档。很多企业的历史制度、验收单、图纸都是扫描件，占比往往不低，入库前先盘一遍量。
• 一稿多版，互相打架。三个版本的报销制度同时在库里，检索会把三份都捞回来，模型只能挑一份或者揉在一起。建议入库前做版本收敛，旧版标失效而不是直接删，留痕比干净更重要。
• 表格跨页、合并单元格。解析重灾区。切完片表头和数据分了家，答案就串行。表格类文档建议单独走一条解析链路，别和正文用同一套规则。
• 页眉页脚、水印、目录页。噪声进了片段，既挤占上下文，也容易让模型抓错重点，还会白白多烧 token。做模型 API 与成本管理的时候，这部分浪费经常是最容易砍掉的。
• 权限。谁能看什么，必须在检索层就过滤掉，不能靠提示词写一句「不要回答涉密内容」。人事、薪酬、合同这类文档要按组织架构分组，在私有化部署的项目里我们一般会把它放到最前面设计。
• 时效。制度改了但知识库没同步，比没有知识库更危险——它会一本正经地给你旧答案，而且说得很有底气。

给个粗糙的判断线：如果抽检你们文档时，「同一件事存在多种说法」的比例超过一成，先做治理，别急着选模型。治理花的时间往往比搭系统长，但这步省不掉。

一张自查表，判断该不该现在上

问题	回答「是」	回答「否」
答案主要存在于文档原文里吗？	RAG 是对的路子	先看是不是该做数据分析或工具调用
每类文档有单一有效版本和责任人吗？	可以直接进解析	先做版本收敛
扫描件占比低于两成吗？	解析链路可以简单些	先补 OCR 和清洗
能接受「检索不到就说不知道」吗？	可以开始搭	先想清楚，硬要求必答的系统一定会编

起步怎么走

选一个文档量在几百到两千份之间、提问高频、答案明确的场景先跑，比如内部行政与 IT 问答，或者售后参数查询。拿真实提问攒 50 到 100 条测试集，人工标一遍「文档里到底有没有答案」，先量检索命中率，再谈生成质量。

命中率不到七成，就回去改解析和切片，别在那调提示词——那是拿生成端的功夫补检索端的窟窿，补不上。等命中率稳住了，再接AI 智能体去做多步任务，比如查完制度自动发起审批；到那一步，知识库才真正变成流程的一部分，而不只是个能对话的搜索框。

如果你们正卡在「不知道该不该上、上了又不知道哪里不对」这个阶段，可以先对照企业知识库的方案说明梳理一遍现状，或者直接打 400-873-2750 跟我们聊十分钟，把文档量和场景说清楚，能上不能上当场就有个大概判断。