你听过的 RAG / 长上下文 / 微调,其实都在治 AI 的同一个"健忘症"

你大概听过 RAG、长上下文、微调这几个词——它们听起来是三件互不相干的事,其实在治 AI 的同一个老毛病:健忘。LLM 训练完那天知识就冻结了,你公司新出的产品、你这周新写的代码,问它一律"我不知道"。所以圈内人想出三条路给它"补脑"——本文用找东西这件事把它们说清楚。

三个名词背后是同一个问题:怎么让 AI 用上你手里的知识。答案不只一个,也不挑最好——抽屉翻找 / 全倒床上 / 重训收纳习惯,各有最适合的场景,谁也不是谁的替代品。

一、三路线核心定位

1. RAG——抽屉翻找

每个抽屉贴好标签(向量库 + BM25 索引),你问一句"那个红色文件夹在哪",助手按标签打开对应抽屉把东西递给你。什么时候用它:知识高频更新、要可追溯、答案需要引用原文的场景——企业知识库、客服问答、产品手册。

思路最近乎人查资料:问题来了先去检索,拿相关片段拼进 prompt 再让 LLM 生成。代价是抽屉要维护——标签贴错、东西塞错抽屉、你说"那个红的"助手却找不到,效果就崩。DeepSeek-R1 等推理模型登场后,RAG 又被反复拿出来作为"可解释性更好的方案"(检索结果可看,模型权重是黑盒)。

2. Long Context——全倒床上

把所有抽屉里的东西一次性倒在床上摊开,让助手看着答——什么时候用它:文档量 < 1M token(Claude 4 已开到 1M beta,Gemini 1.5 同等量级;主流窗口从 8K / 32K 推到 200K 到现在 1M),单次任务要把全部内容塞给模型——读完全书做摘要、整份代码库改 bug、合同审完提风险点。

思路反着 RAG 来:不检索、不切片,把整本书 / 整份代码一次性扔过去让它"看着回答"。成本随倒出来的东西多少涨($0.075–0.60/query,按"摊开"面积),但没有抽屉维护这一层。问题是床上中间那堆最容易漏掉——你找东西也是先翻顶层、最后才动中间那一堆。这就是 Lost in the Middle。

3. Fine-tuning——重训收纳习惯

不是补东西,而是教他怎么按你的习惯来——什么时候用它:不是补知识,而是改行为。专属客服话术、固定体例文书、SQL 生成器、合规审核标准——输出格式严格、风格统一、月查询量足够大。

用标注过的语料训练,把他训练成"只按你这一套路子办事的搭档"。看似便宜($3/百万 token 推理),但前期培训投入 + 习惯改了又得重训是隐性大坑。习惯一旦养成,想完全抹掉某条接近不可能——所以涉及隐私 / 法规可删除性的,这条路慎走。

二、五维度细评

把这三招找东西的方式摆在一起比,看哪种最合你的场景:

维度 1:机制——三种找法怎么不一样

用最直白的话说:RAG 是按线索找,Long Context 是全摊开找,Fine-tuning 是先学一套找法再上场。新人最常踩的坑是把 Fine-tuning 当"补东西"的工具——它不是;补东西用前两种。

维度 2:延迟

三种方法实测差距不超过 1.5 秒,都能做到用户无感。RAG 多了检索这一步,但要找的范围小;Long Context 全摊开,首字慢一点但后续连贯;Fine-tuning 是已经"学会"的推理过程反而最快。延迟单独看意义不大,主要看你请哪个搭档。

维度 3:成本

不是比单价,是比"达成同一效果的总账"。RAG 主要成本是基建(年费 $0.05/篇/月级)+ 每次检索的开销;Long Context 每条 query 贵但没有检索层;Fine-tuning 推理便宜,但训练和重训才是大头。如果做不到预算增容、就必须算清楚真实成本——尤其把"更新知识需要重新训练"的运维算进去。

维度 4:数据敏感度

关键看可删除性:RAG 的原文全留在向量库,删就是一个动作;Long Context 你扔给他啥他忘了啥;Fine-tuning 一旦写入权重,想完全抹掉某条得重新训练或 unlearning。涉及监管 / 客户隐私,首选 RAG,因为可删除性最强。

维度 5:典型适用

经验值:文档 < 1000 篇,Long Context 最省;1 万到 100 万篇,RAG 主力;行为要统一调整,才轮到 Fine-tuning。这一原则胜过所有"哪个模型最强"的讨论——规模不到什么都是过度工程,规模到了什么都能跑通。

三、按角色选

同一件事,不同角色关心的是不同维度:

• 个人开发者 / 小项目:Long Context 优先(成本可控,运维零负担)。文档量过千再考虑 RAG;绝大多数 side project 永远不需要 RAG。
• 中型业务团队:RAG 是主力,但chunk 切分 + 检索质量评估是必投人力。一个常见误区:花半年搭 RAG 基建,实际上 Long Context + 人工整理常能撑到很后期。
• 大型企业 / 高合规场景:RAG + 私有化部署 + 数据治理流程。Fine-tuning 慎用——如果一定要训,先确认业务量能不能到月 100 万级查询,撑不回训练投入别碰。

四、实战建议

选型决策树(秒判版本)

1. 数据 < 1000 篇? → Long Context。
2. 数据 1 万–100 万? → RAG。
3. 是改行为,而不是补知识? → Fine-tuning + 小数据。

这棵树选不到,90% 是规模不到位或需求没想清楚——回去和业务方再对齐,不要硬上技术。

三个最常见踩坑

• RAG 最常翻车在 chunk 切分:按段落 vs 按 token vs 按问答切,决定召回率 30%+ 的差异。先人工抽样再上自动化。
• Long Context 不是"塞得下就行":Lost in the Middle 实测显示中段召回率从首尾 95%+ 跌到 60–70%。重要信息放首尾,中段放次要信息。
• Fine-tuning 不是"样本越多越好":< 1000 条就开始训,大概率过拟合。判断标准:这条样本代表真实分布、还是临时编出来的。

成本测算(基于真实月度账单)

假设月 100 万次查询、平均 4K token 输出(GPT-4o / Claude 4 价位):

• 纯 Long Context:每条 query 推送 8K 资料 → 月账单 $70 量级,无 RAG 层。
• 纯 RAG:向量库年费 $0.05/篇/月 + 生成按 8K 平均 → 接近纯 Long Context 的 60–80%。
• RAG + Fine-tuning 混合:只在"风格 / 套路"训练,一次性几十到几百 USD,后续推理 $3/百万 token(反而比 Long Context 便宜)。

数字都是估算,真实账单取决于你的 query 长度、检索量、token 单价——别拿这个表签合同。

五、总结

• RAG / Long Context / Fine-tuning 互补,不看场景就选一个 = 大概率过度工程或不够用。
• 规模决定上限:< 1000 篇别想 RAG 基建,> 100 万篇别想纯 Long Context 兜底。
• 可逆性决定兜底:涉及隐私 / 监管 / 内容审核,首选 RAG(数据随时可删)。

一句话选型:数据 < 1000 篇用 Long Context,1 万到百万用 RAG,行为要统一才上 Fine-tuning——三者按规模组合,不互相替代。