RAG 是让模型先去翻你给它的资料，再照着资料回答，不是把模型变聪明了。

它的做法很朴素：你问一句，系统先从文档库里找出几段相关的文字，连同你的问题一起交给模型，让它照着这几段写答案。模型本身没变，变的是它眼前多了几页参考材料。

容易踩的坑，是以为接上 RAG 就万事大吉。资料如果是三年前的旧版，它照样能把旧内容说得头头是道；切分太碎，一段话被砍成两半，模型读到的就是残句；检索那一步没找对段落，后面写得再顺也是错的。

还有一点常被忽略：RAG 只管答案有没有出处，不管出处本身对不对。你上传的文件写错了，它会很忠实地把错误复述一遍，还带着页码，看着比胡编更可信。

要用上它，不必懂技术。市面上不少文档问答工具，把 PDF、Word 拖进去就能问。真正该花心思的是整理资料：删掉过期文件，把同一份制度的多个版本合成一个，标题写清楚。这一步做扎实，比换模型管用。

判断要不要上 RAG，看一个条件就够：答案是否依赖一批你自己掌握、而模型没见过的资料。是，就值得做；不是，接上它只是多绕一道弯。

值得做的场景有几个特征。资料有明确边界，比如产品手册、内部制度、合同模板、历史工单；答案要能指回原文，用户会追问这条写在哪；资料更新不快，但一改就得同步到回答里。

没必要做的也清楚。问的是通识，模型自己就能答个八九不离十；资料量很小，十来页，直接贴进对话框比搭一套检索链路省事；问题本身模糊，提问的人自己都说不清要什么，检索出来的段落也帮不上忙。

我见过的失败案例，多半不是技术选型错了，而是资料没治理。三个部门各存一份客户名单，字段名还不一样，检索时抓到哪份全看运气。这种状态下先做资料归一，比先挑模型顺序更对。

还有个成本要提前算：RAG 不是一次性工程。文档改了要重新入库，效果差了要回头看是检索错还是切分错，这些都得有人盯。团队里没人愿意长期管这件事，上线三个月就开始积灰。

我头一次用文档问答，是把公司两年的项目周报全传了进去，想着以后问进度不用翻文件夹。结果问下去就翻车了。

我问「去年那个商城项目延期的原因是什么」，它答得特别流畅，说是供应链问题，还引了一段原文。我去核对，那段原文写的是另一个项目，两个项目名字里都有「商城」两个字。

后来才明白，问题出在我传的东西太杂。周报里既有正式汇报，也有随手记的待办，还有几份同名不同版的草稿。检索的时候它分不清哪份算数，抓到一个关键词像的就往上贴。

改法很笨但有效。我把草稿全删了，只留定稿；每份文件开头加一行说明，写清项目名、时间、版本；文件名从「周报0321」改成「商城项目_2025年3月_周报_定稿」。再问同样的问题，它引的就是对的那份。

那次之后我养成一个习惯：它给的答案，我都点开引用看一眼原文。不是不信它，是它的引用经常对，但引的那段话和我理解的不是一回事。这个动作花十秒，能省掉后面一堆解释。

把两种用法摆在一起看，差别主要在答案的来源上。

直接问模型：你输入问题，它从训练时见过的内容里组织一段回答。速度快，不用准备资料，适合问概念、问思路、问这两者有什么区别。风险是它不知道你的具体情况，遇到没见过的东西也会顺着语气往下写，读起来通顺，实际是编的。

先用 RAG 查资料：系统从你指定的文档里挑出相关段落，再让模型照着写。速度慢一点，要先把资料整理入库。好处是答案能落到具体文件上，点开引用就能核对；涉及内部规定、产品参数、合同条款这类不能错的内容，两边差别很明显。

两组对照下来，判断方法可以压成一句：答案对错有人能立刻验证的，直接问就行；答案错了要付代价的，走 RAG。写文案、想标题属于前者，回复客户关于保修期的询问属于后者。

还有一种混合用法常被忽略。先用 RAG 把事实查准，再让模型基于这些事实组织表达，两步分开做。这样既不用把整份文档喂进去，也不会让模型自由发挥到跑偏。

问：RAG 上了，是不是就不会胡编了？答：不会。它减少的是无据可依的编，不是所有的编。这两件事经常被混在一起说。

问：那它还会错在哪？答：错在三处。检索没找对段落，模型拿到的材料本身就偏；找对了但切分把一句话拦腰截断，意思变了；材料和问题都在，模型总结时把两个数字看串了。前两种是工程问题，后一种到现在也没有根除的办法。

问：怎么判断一次回答靠不靠谱？答：看引用。引用的段落能不能撑住这句话，自己读一遍就有数。有些回答挂了三个来源，逐条点开，只有一条沾边，剩下两条是凑数。这种情况比没有引用更需要留心，因为它看着有据。

问：那还值得做吗？答：值得，但预期要放对。它把「十句话里三句是编的」改成「十句话里一句是编的，而且你能查出是哪一句」。剩下那一句，还得靠人。