RAG、微调、长上下文，到底什么时候用哪个？

每次有人来问 AI 项目落地的事绕不过去的几乎都是这三个词RAG、微调、长上下文。让我有点不安的是问的人其实并不缺资料。讲 RAG 的文章一抓一大把讲微调的教程一打开就停不下来讲上下文窗口涨到几百万 token 的新闻每隔几个月就会来一波。可一旦回到自己手里这个具体场景他们还是会卡住到底走哪条三条都试一遍还是哪个新就用哪个一开始我以为这是因为这三种方案本身复杂。后来反复看了几次我越来越觉得问题不在这一层。他们不是被三种技术的复杂度难住的是从一开始就把这三件事摆在了同一根轴上比较。可这三件事根本不在一根轴上。它们看起来都在给模型补点东西于是被自然地放在一起对比。可只要往下问一句——补的是什么——这种并排就立刻不成立了。一个是这件事它本来就不知道知识不在它脑子里得有人在它开口之前递一份过去一个是知识它早就看过了但它做这类事的方式不对输出格式飘、判断不稳、风格乱得想办法把它自己做事的习惯改一改还有一个其实更朴素知识它也知道做法它也会只是这次的活儿要求它把整份材料从头看到尾再回答你别替它切也别替它检索让它一口气读完。这三件事彼此之间没有谁替代谁的关系。把它们摆在一起选就像在工具箱里把扳手、螺丝刀和卷尺摆在一起问今天该用哪个——问题不在哪个工具更好在你今天要拧螺丝、上钉子还是量长度。所以这篇我想换一个角度讲。不是去比这三项技术哪个更先进而是顺着模型到底差什么这条线把它们各自适合处理的那一类问题摊开来。这样一旦你看清自己手里这个项目缺的是哪一种往哪边走几乎是自然的。一、RAG 真正难的从来不是生成人们最容易把 RAG 理解成给模型加知识。这句话不能算错但它把 RAG 难的地方说得太轻了。RAG 之所以适合那种知识在模型外面、还会不停变化的场景——比如内部知识库、产品文档、政策法规、客服 FAQ——核心其实不在于它能让模型说出新东西而在于它把该说哪一段的责任从模型身上挪到了一个外部系统身上。模型每次开口前面都有一只手在替它选材料。这只手做得好不好比模型本身聪明几分往往更决定最后的输出。这点一想明白你会发现 RAG 真正难的从来不是生成是生成前那一道检索。生成那一段是模型的事模型今年比去年强明年比今年更强这一层的进步几乎不需要你操心。可在对的时刻把对的几段拿出来这件事再强的模型也救不了。它没拿到关键那段就只能在边角料里认真发挥它拿到一堆似是而非的片段就会很努力地把它们综合成一个错的答案。让人痛苦的点是这种错误经常长得很体面。你看模型最后那段输出措辞顺、逻辑也通、语气还挺笃定乍一看不像出错。回过头才发现它根本没看到那条最关键的规定只是顺着检索出来的几段噪音把话说圆了。RAG 系统坏掉的样子往往不是答不出来而是答得很流畅但答的不是这件事。所以判断一个场景该不该上 RAG光看有没有外部知识库是不够的还得继续往下问几件事。知识量到底大不大如果总量并不夸张能整批塞进上下文那有时候长上下文反而更省事少一层检索就少一类失灵。这堆知识有没有在反复被访问只用一两次的材料搭一套检索系统是过度工程要被长期、反复地拿来回答各种问题才值得做成一个被检索化的对象。还有一个特别现实的问题你这个场景里有没有人会在乎出处只要会有人追问你凭什么这么说RAG 的位置就立刻稳了因为它天然适合把来路一起带出来。把这几条叠在一起RAG 就不再是一个要不要给模型加点料的简单决定而是一道更朴素的工程题你愿不愿意为这堆外部知识专门维护一套调度它的系统。二、微调最容易被误用的地方微调被误用的次数可能比正确用的次数还多。最常见的一种误用是把它当成给模型灌知识的工具。模型答不上某个专业问题第一反应是调一下吧。可你真正面对的往往是 RAG 该处理的问题知识不在它脑子里临时递一份过去就够了。把会变的事实塞进权重今天文档改一版明天规则换一条难道每次都要重训一次这条路从经济性上就走不通。微调真正擅长的事情不在知道什么在怎么做。举个最常见的画面同一份资料给模型它该回答得专业、稳定、按你要的格式输出。但它做不到。它知道答案可写出来的东西总是飘格式不一致、字段缺一块、分类边界一直跨、工具调用的参数结构经常不合规。这时候问题就不是它没看到资料而是它看了资料以后做事的方式还是不像你要的。能从根上改这件事的才是微调。所以微调更像是在改一个人的习惯不是给他塞一本新书。可习惯这种东西麻烦也在这里。它对样本有要求但要求不在量大不大在干不干净。一份够干净的几千条样本往往比一份脏的几万条管用得多。因为模型从样本里学到的本质上是这种输入就该长出这种输出的对应关系样本本身要是含糊的、冲突的、边界不清的模型学到的也只能是一种更稳定的含糊。你以为它学不会其实它学得很好只是把你那批数据里的糊涂学进去了。微调还有一个被严重低估的门槛你得能把想让它学什么说清楚。很多人想微调是因为有一种隐约的不满“我想让它更懂我们项目”、“我想让它更像我”。可这种话翻译不成训练目标。你得继续问自己是想让输出格式更稳还是想让某类分类规则更准还是想让它在调用工具时按某个固定结构来组织参数说不到这一层就还没到该微调的时候。先把任务边界问清楚往往比急着开训重要得多。还有最后一层很多人事前没想到的代价微调不是一次性的工程。基座模型会升级业务场景会漂移那批样本过几个月也可能不再够用。今天调好了不等于以后不用再管。这一点一旦被忽略半年后你会发现自己卡在一个不上不下的位置重训成本不低不重训效果又在悄悄退化。所以我自己一直把微调当成一种后手。前面那些更轻的办法都试过了问题依然稳定地卡在模型本身做这类事就是不像样再考虑动它的权重多半才划算。三、长上下文是最容易被低估的那条路长上下文听起来什么都没做。RAG 至少像个系统有索引、有检索、有 ranking微调像在升级模型本身的能力。相比之下长上下文好像就是把材料塞进去。也正因为这种朴素过去几年它一直被当成不够工程化的方案。但只要你认真把工程系统看上几年就会知道一件事朴素往往不等于原始反而经常意味着你少做了很多本来不该做的事。很多任务的本质根本不在找到几段相关片段而在把整份东西完整看一遍。读一份合同看一篇论文理解一组互相牵连的代码文件它们的麻烦不在信息找不到而在这些信息彼此之间的关系本身就是要紧的。一旦你先切碎、再检索整体感反而最先丢掉。模型拿到的是几段被拣出来的片段缺的恰恰是那种从头到尾跟着读一遍才能形成的判断。很多本来该一口气读完的任务被硬套上 RAG 之后效果反而变差原因常常就在这里。不是检索不够先进是任务本身要的就不是检索。过去这条路被低估很大一部分是被窗口大小卡住的。窗口只有几千 token 时塞进去几乎不是一个选项所有任务都被迫走检索。这两年窗口一路涨到几十万、几百万很多原本必须切片的问题其实可以重新拿出来掂量一遍它们到底是真的需要检索还是只是过去没得选。不过这里也得说清楚长上下文不是越长越好更不是越长越准。窗口拉得越长注意力就越被摊薄。一份资料越厚模型在上面看清每一页的概率反而下降。中间那一段最容易被淡化相互冲突的信息塞在一起也更容易混。塞得进去不等于看得见看得见不等于看得清。它的另一面代价是钱和延迟。窗口越长每次推理越贵响应也越慢。一批资料如果会被频繁、反复地用每次都整包塞过去就是一种浪费——这时候 RAG 又会重新显得合理。所以长上下文真正适合的其实是这一类任务它不值得为一次检索专门搭一套系统但又值得让模型完整看一遍。这类活儿在真实工作里其实非常多只是过去没有这条路可走所以大家都习惯把它们硬塞进 RAG 的形状里去解决。窗口变大之后路其实悄悄多了一条只是人还没习惯抬头看一下。四、真正的选型从来不是技术之间的比较写到这里我想再回到开头那个问题RAG、微调、长上下文到底什么时候用哪个我现在更愿意这么回答这个问题最有用的问法不是把这三个名词摆在桌上互相打分而是先停一下问自己一句我手里这个场景到底缺的是什么是模型不知道这件事那这是 RAG 的题。是它知道这件事但做事的方式不对那这是微调的题。是它什么都知道、做法也对只是这一次需要它从头到尾完整看一遍那这是长上下文的题。这三句话听起来简单到有点欺负人可它们最值钱的地方恰恰不在像不像口诀而在于它们逼着你先认清问题的类型。工程上很少有人是被某项技术做得不够优雅卡住的。更常见的麻烦是从第一天起就在用解决 A 类问题的工具去处理一个其实属于 B 类的问题。路一旦走偏后面投入越多越像在认真地把误会做大。RAG 系统搭得再精致也救不回一个本来就不该走检索的任务微调样本调得再干净也补不上一个本质是知识缺失的场景。技术选型说到底从来不是先比哪项技术更高级是先看清自己在解决什么。这个问题一旦确定剩下那些原本看起来纠缠在一起的东西会自己分开。最后想多说一句。在 AI 工具一年比一年多、一年比一年炫的时代里这种先把自己缺的是哪一种东西分清楚的能力可能比手上多会几项新框架更重要。框架会不停换名词会不停翻新今天说 RAG明天聊 Agent后天又冒出新的什么。可我现在到底在补什么这件事是新词换不掉的。它不在某项工具里而在每一次具体决定背后那个愿意慢半拍、把问题先看清楚的人那里。我把这两年关于 AI 编程的一些理解整理成了一本开源书《AI 编程的第一性原理》这篇文章里讲到的判断——为什么 RAG 真正难的地方常常落在检索上为什么微调更像是在改习惯而不是灌知识为什么长上下文反而经常是更朴素的那条路——在书里都展开聊过了。如果你也在用 AI 写代码欢迎来读《AI 编程的第一性原理》 GitHub 仓库