企业官网建设流程全解析

每次有人来问 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 仓库