把 8 本英文小说一次塞进上下文，模型居然学会了翻译一门只有 200 人的语言——Google 长上下文技术报告精读

一句话结论

　　1M token 上下文不只是「能装更多」，它让模型靠纯上下文学习就学会翻译一门只有 200 人使用的语言、效果逼近真人——这是 RAG 之外另一条被低估的路线。

背景与痛点

　　早年的 LLM 一次只能吞 8K token；后来卷到 32K、128K。但面对长文档、几万行代码、几小时音视频，大家还是被迫上 RAG：切块、向量库、重排、摘要。RAG 好用，但有隐形成本——检索准了不代表回答对，链路一长就有损耗，工程也重。

1M token 输入 + 64K token 输出

核心方法（讲人话）

　　many-shot in-context learning（多样本上下文学习）

　　「我们不是检索，而是把全部相关信息 upfront 一次性喂进去。」这就是范式转移。

实验与数字

• 1M token ≈ 5 万行代码 / 8 本平均长度英文小说 / 200+ 期播客转录。
• Kalamang 翻译实验：只给 500 页语法参考书 + 一本字典 + 约 400 句平行语料（全部放在上下文里），Gemini 学会把英语译成这门巴布亚土著语言（使用者不到 200 人），质量接近用同样材料的人类学习者。
• Gemini 3.6 Flash 实测：SWE-Bench Pro 58.7%，输入价 $1.50 / 1M token，输出价 $7.50 / 1M token。
• Many-shot 表现接近 fine-tune，且无需任何训练。

为什么重要

　　反直觉点来了：长上下文不是 RAG 的替代品，而是「直接把全量信息 upfront 喂进去」的另一种范式。对三类场景是质变——

1. 代码重构：把整个 monorepo 塞进提示词做整体架构重构；
2. 长视频/长音频理解：一次吃进 1 小时视频或 8 小时音频；
3. Agent 状态保持：agent 不用靠摘要丢记忆，全程上下文在线。

　　「现有榜单测不出差距」在长上下文上不成立——差距恰恰在真实长任务里。

复现 / 落地思路

• 用 Gemini API 的 context caching（上下文缓存） 把长输入缓存下来，大幅降低 1M token 反复输入的账单；
• many-shot 分类/抽取任务，可以直接把几百条标注样例塞进提示词免微调验证；
• 开源侧暂无同等窗口的平替，可先用 Gemini 免费额度试水。

今日可做的 3 件事

1. 挑一份你最常用的长文档（合同 / 论文 / 代码库），整篇塞进 Gemini 长上下文，对比你平时 RAG 切块的效果差。
2. 找一个分类或抽取任务，用 many-shot 把 200 条标注样例直接放提示词，测免微调效果。
3. 给一次长上下文请求算一笔成本账：开 context caching 前后 1M token 输入差多少。