RAG到底怎么做:从一堆文档到一个能回答问题的AI助手-夜雨聆风

RAG到底怎么做:从一堆文档到一个能回答问题的AI助手

你可以把 RAG 想成一件很朴素的事：先把资料整理好，再让 AI 学会去里面翻。

上一篇我们讲了 RAG 是什么。

说人话，它就是让大模型在回答前，先去指定资料里查一遍，再根据查到的内容组织答案。

这篇接着往下讲：

RAG 到底是怎么做出来的？

先说结论。

做 RAG，不是把一堆文档丢给大模型，然后等它自己变聪明。

它更像是搭一条工作流程：

先把资料整理成 AI 能检索的样子；

用户提问时，系统先去找相关资料；

最后再把问题和资料一起交给大模型，让它按资料回答。

听起来有点技术，但你不用一上来就记那些词。

先把这件事拆成几个动作，就很清楚了。

先别急着接模型

很多人一听要做 RAG，第一反应是：

我是不是要先选一个大模型？

用 GPT？用 Claude？用通义？用 DeepSeek？

模型当然重要。

但在 RAG 里，模型不是第一个问题。

你真正要先问的是：

我要让 AI 根据哪批资料回答问题？

比如你想做一个公司内部 AI 助手。

那它要看的资料可能包括：

员工手册
报销制度
产品说明书
客服 FAQ
销售话术
项目复盘文档
历史方案和合同模板

这些东西平时可能散在飞书、语雀、Notion、企业网盘、PDF、Word、网页后台里。

人找起来都费劲。

你直接指望 AI 找得又快又准，基本不现实。

所以 RAG 的第一步，不是让模型回答。

而是先把资料收回来。

第一步，把资料收回来

你可以把这一步理解成“建资料池”。

公司里哪些资料允许 AI 看，哪些资料不该看，哪些资料已经过期，哪些资料才是最新版，都要先理一遍。

这一步很琐碎，但非常关键。

因为 RAG 有个很残酷的地方：

资料本身乱，后面的回答一定很难干净。

比如一个报销制度，有 2023 版、2024 版、2025 版。

旧版没有删，新版没有标清楚。

员工问“差旅住宿标准是多少”，系统可能把旧制度翻出来。

模型再会说，也只能把错资料说得更像真的。

所以做 RAG 前，最好先问几个很土但很有用的问题：

哪些文档是有效的？
哪些文档已经过期？
哪些文档只能部分人看？
哪些文档是重复的？
哪些文档里写得含糊，连人都看不懂？

很多团队做到这里才发现，自己不是缺 AI。

是缺一套像样的资料管理习惯。

第二步，把大文档切小

资料收回来之后，还不能直接丢给模型。

因为很多文档太长了。

一本产品手册几十页，一个投标文件几百页，一堆制度加起来可能几十万字。

用户只问一句话：

“这个设备保修几年？”

你不可能每次都把整本手册塞给大模型。

成本高，速度慢，还容易把模型看晕。

所以 RAG 通常会先把文档切成一小块一小块。

这一步叫切分。

你不用记英文，也不用把它想复杂。

它本质上就是把一本厚资料，拆成很多张小卡片。

用户问问题时，系统不是去翻整本书，而是先找最可能有答案的那几张卡片。

但这里有个难点。

切太大，不好找。

切太小，又没上下文。

比如一句“适用上述标准”，如果单独切出来，AI 根本不知道“上述标准”是什么。

但如果把整章都切成一块，里面又塞了太多无关内容。

所以好的切分，不是按字数机械切。

更好的思路是：

尽量切成一个人读完后能独立理解的小段资料。

一个条款、一个问答、一个产品参数表、一个操作步骤，通常就比随便每 500 字切一刀要靠谱。

第三步，把文字变得好找

文档切成小块之后，下一步是让系统能“找”到它们。

最容易理解的是关键词搜索。

用户问“退款规则”，系统就去找包含“退款”的段落。

但只靠关键词不够。

因为人问问题时，不一定用资料里的原词。

比如资料里写的是“售后退换政策”。

用户可能问：

“买错了能不能退？”

“拆封以后还能换吗？”

“七天内不想要了怎么办？”

这些话里不一定有“售后退换政策”这几个字。

但意思明显相关。

这时候就要用到 embedding，也就是常说的“向量”。

你不用被这个词吓住。

可以把它理解成：系统会给每段文字做一个语义坐标。

意思相近的内容，坐标就更靠近。

这样一来，哪怕用户没有说出原文里的关键词，系统也有机会把相关资料找出来。

比如用户问“新人入职第一天要准备什么”，系统不只找“新人”和“第一天”，还可能找到“入职材料清单”“工牌领取”“账号开通流程”。

这就是 RAG 里常说的语义检索。

听起来很高级，目的其实很简单：

让系统不只是按字面找，而是按意思找。

第四步，用户一问，先去翻资料

前面几步，都是提前准备。

真正使用时，是从用户提问开始的。

比如员工问：

“出差住酒店，超过标准能不能报销？”

系统不会马上让大模型自由发挥。

它会先把这个问题也变成一个可检索的形式，然后去资料池里找最相关的内容。

可能找出来几段：

差旅住宿标准
超标住宿审批规则
特殊城市住宿补贴说明
报销单据要求

这几段就是给大模型看的“参考资料”。

你可以把这一步想成考试时先翻书。

题目来了，系统先找到可能用得上的几页。

然后才轮到大模型上场。

这里的关键是：

资料要找准。

找错了，后面就会歪。

找少了，答案可能不完整。

找太多了，又会把无关内容塞进去，让模型抓不住重点。

所以很多 RAG 项目真正难的地方，不是“能不能回答”。

而是“能不能先把该看的资料找出来”。

第五步，再让模型组织答案

当相关资料找出来之后，系统会把三样东西一起交给大模型。

第一，用户的问题。

第二，刚检索到的资料。

第三，回答规则。

比如：

只能根据资料回答
资料里没有就说不知道
回答要简单清楚
重要结论要标出来源
不要自己编政策和数字

这时候，大模型做的事情就不再是“凭记忆猜”。

它更像是在读一小摞资料，然后帮你整理成一段人能看懂的话。

比如它可能回答：

“一般情况下，超过住宿标准的部分不能直接报销。如果因会议地点、旺季房价或特殊城市原因导致超标，需要提前提交审批。审批通过后，可以按实际情况报销。具体依据是《差旅管理制度》里的住宿标准和超标审批条款。”

你看，这里面真正有价值的，不是模型突然懂了你们公司的制度。

而是系统把正确制度放到了它眼前。

RAG 的核心，不是让模型记住更多，而是让模型每次回答前看到对的资料。

第六步，最好能给出处

如果 RAG 只给一个答案，但不告诉你依据在哪里，很多场景里还是不够用。

尤其是企业知识库、客服、法务、医疗、财务这些场景。

用户不只是想听一个结论。

他还想知道：

你这个结论从哪来的？

所以比较靠谱的 RAG，通常会把出处带出来。

比如：

来自哪篇文档
来自哪一章
来自哪个条款
文档更新时间是什么时候

这件事看似只是多给一个链接。

但它会明显改变用户对 AI 的信任感。

没有出处的回答，像是在“告诉你”。

带出处的回答，更像是在“带你查”。

前者容易让人怀疑。

后者更适合真的拿去工作。

第七步，资料要能更新

很多人以为 RAG 做完就结束了。

其实不是。

RAG 最重要的价值之一，就是资料可以更新。

产品价格变了，上传新价格表。

制度调整了，替换旧制度。

客服话术改了，更新 FAQ。

下次用户再问，系统检索到的就应该是新内容。

但这里也有坑。

如果旧资料没有下架，新资料只是又传了一份，系统可能新旧一起搜出来。

如果文档更新时间没有记录，用户也不知道答案依据是不是最新。

如果不同部门有不同权限，系统还得知道谁能看什么。

所以一个能长期用的 RAG，不只是“能上传文档”。

它还要处理版本、权限、更新、删除这些很普通但很实际的问题。

这些事听起来不炫。

但它们决定了 RAG 是演示一下好看，还是放到业务里也能用。

最容易坏在哪

你现在大概能看出来了。

RAG 不是一个按钮。

它是一套从资料到答案的工作流程。

这套流程里，每一步都可能出问题。

最常见的是这几类。

第一，资料本身质量差。

文档过期、重复、含糊、互相打架。

AI 最后只能把混乱重新讲一遍。

第二，切分方式不合适。

该放在一起的内容被拆散了，不该放一起的内容又挤在一块。

结果检索出来的资料看似相关，其实没法支撑答案。

第三，检索不准。

用户问的是 A，系统找出来的是 B。

模型再努力，也是在错误材料上写作文。

第四，没有权限控制。

员工问普通制度，结果搜出了管理层文件。

客服问产品参数，结果看到了内部成本表。

这种问题在企业里非常敏感。

第五，没有测试。

很多团队做 RAG，只测几个演示问题。

演示时效果不错，一上线就露馅。

因为真实用户问法太多了。

有人问得很短，有人问得很绕，有人问错词，有人把两个问题混在一起。

如果没有一批常见问题去反复测试，很难知道系统到底靠不靠谱。

普通团队怎么先做起来

如果你不是大公司，也没有专门的 AI 团队，别一上来就想做一个“全公司万能知识库”。

这东西听起来很厉害，实际很容易做成一个什么都懂一点、什么都答不准的系统。

更好的办法是从一个小场景开始。

比如只做一个客服 FAQ 助手。

或者只做一个内部报销制度助手。

或者只做一个产品参数问答助手。

范围越小，资料越容易整理，问题也越容易测试。

你可以按这个顺序来：

先选一个具体场景
收集这个场景里最常用的资料
整理出 30 个真实高频问题
看每个问题能不能在资料里找到依据
再接入检索和大模型
用这 30 个问题反复测答案
答得不准，就回头改资料和检索方式

注意，这里最重要的不是第 5 步。

很多人最想做的是“接入大模型”。

但真正决定效果的，往往是前面那几步。

资料有没有整理好。

问题有没有选真实。

答案有没有依据。

错了之后能不能知道错在哪。

这些才是 RAG 能不能落地的关键。

你可以这么理解整件事

如果把 RAG 做成一张流程图，它大概长这样：

资料收集。

文档清洗。

内容切分。

生成向量。

存进数据库。

用户提问。

检索相关资料。

把资料交给大模型。

生成答案。

返回出处。

这就是一个最基础的 RAG。

但别被这些步骤吓住。

换成人话，它其实就三件事：

把资料整理好。

把相关内容找出来。

让 AI 按找到的资料回答。

只要你抓住这三件事，就不会被那些技术词带跑。

向量数据库也好，embedding 也好，rerank 也好，本质上都在服务同一个目标：

让 AI 更容易找到对的资料。

最后

RAG 之所以重要，不是因为它听起来技术感很强。

而是因为它把大模型从“凭印象回答”，往“按资料回答”推了一步。

但你也要记住：

RAG 做得好不好，很多时候不取决于你用了多贵的模型。

它取决于你有没有把资料整理清楚，有没有让系统找得准，有没有让答案能追得回出处。

所以如果你真想判断一个 RAG 项目靠不靠谱，别先问它接了哪个模型。

先问一个更朴素的问题：

它到底能不能把该看的资料，准确地翻到 AI 面前？

这个问题答清楚了，RAG 才算真正开始有用了。