文档塞进提示词、压成 KV 还是训进权重？一次公平对撞给出了四种失败模式

你的客服机器人要「记住」一万篇产品文档。你有三条路：每次回答时把相关文档拼进提示词；把每篇文档编码成一个 KV 缓存前缀，推理时拼接；或者用 LoRA 或全量微调，把知识焊进模型权重。

这三条路业界吵了很久，各有各的信徒，但一直缺一次公平的对撞——同一个模型、同一套数据、同一个评测。Amazon AGI 的一组研究者把这个实验做了一遍，结论出乎很多人意料：没有赢家，只有三种不同的失败模式。

一个几乎每个团队都要做的选择题

这个选择的实质是：外部知识以什么形式进入模型？

• 塞进上下文：也就是 RAG。每次回答前检索相关文档，拼到提示词里。优点是灵活，文档随时可换；缺点是上下文长度和推理成本随文档量线性增长。
• 压成表征：把文档预先编码成 KV 缓存前缀，推理时直接拼接。优点是省掉了重复计算，存储远小于原始文本；缺点是需要预处理的工程投入。
• 训进参数：微调。优点是推理时零额外开销；缺点是知识更新要重新训练，而且可能影响模型原有能力。

大多数团队的选型依据其实是习惯和传言：「RAG 更灵活」「微调效果更好」这类说法满天飞，但很少有人在同一套数据上比过。

实验怎么设计的

研究者用 Qwen3-8B 作为基座，在五个数据集上测试：

• LongHealth：临床病人记录，多选题，长文档约 11.7K token
• QASPER：学术论文问答，抽取式，约 4.7K token
• QuALITY：小说与非小说阅读理解，多选题，约 5.7K token
• FinQA：财报数值推理，需要数学计算，约 1K token
• TechQA：IT 支持文档问答，抽取式，约 1.5K token

方法覆盖了三条路的主流实现：上下文拼接（ICL）、KV 前缀（Cartridge）、另一种 KV 压缩（Compaction）、低秩适配（LoRA）、MLP 适配器，以及作为上界的全量微调。

每种方法都在 2 倍、10 倍、20 倍、50 倍、100 倍五档压缩率上扫描，用来画性能与成本的曲线。这个设计很关键——脱离压缩率谈谁更好是没有意义的。

结论一：单文档场景，KV 前缀的性价比最高

在关于单个文档提问的场景里，Cartridge（KV 缓存前缀）在多数数据集上以最小的体积拿到了最好的表现。

以 LongHealth 为例：Cartridge 在 2 倍压缩下拿到 83.2 分，占用 54 MiB；LoRA 要达到相近表现需要约 509 MiB；全量微调表现略高，但要 3072 MiB。

也就是说，Cartridge 用十分之一的体积打平 LoRA，用五十分之一的体积达到全量微调九成的表现。对工业部署来说，这个差距直接决定了单机能服务多少路并发。

结论二：需要算数的任务，KV 前缀会塌

Cartridge 并非无敌。在 FinQA 这个需要数值推理的数据集上，Cartridge 在 2 倍压缩下只有 50.7 分，而全量微调超过 70 分。

这个落差很说明问题：数值推理似乎需要更深层的参数级整合。把财报数字压成 KV 前缀，模型能「读到」这些数字，但没法真正把它们纳入计算过程。

如果你的场景涉及计算、推导、需要多步数值操作，别指望 KV 前缀能顶上。这是三条路里最清晰的一条能力边界。

结论三：多文档组合是三种方法的共同死穴

真正让人意外的是多文档场景。当问题需要同时用到多份文档（k=3）时：

• KV 拼接表现掉到接近随机
• 权重合并同样崩塌
• 只有联合训练能撑住，但代价是牺牲检索灵活性

这是整篇论文里最有实践价值的一条。如果你的应用需要跨文档综合信息，那么无论选哪条路，都不能指望「分别注入再组合」。要么在一次训练里同时喂进所有文档，要么回到最朴素的上下文拼接。

这也解释了很多团队的实际体验：单文档问答效果很好，一加到多文档就莫名其妙地变差——不是你调参有问题，是方法本身有这个上限。

结论四：训进权重会遗忘，LoRA 的低秩反而成了保护

参数级注入会带来灾难性遗忘。全量微调在通用基准上掉了 10 分以上，而 LoRA 因为低秩约束，反而起到了正则化的作用，遗忘更轻。

这条结论对做垂直领域微调的团队是直接的提醒：全量微调的收益上限更高，但对模型通用能力的损伤也更明显。如果你只想在特定知识上加强、又不想把模型搞残，LoRA 的低秩约束其实是个保护机制，不只是省钱手段。

把结论翻译成提示词工程动作

把这四条结论落到日常操作上：

• 单文档、事实型问答：优先 KV 前缀方案，同样的钱能撑起更高的并发。如果暂时没有工程能力做 KV 预编码，RAG 的上下文拼接效果接近，只是成本更高。
• 数值、计算、多步推导类任务：回到参数级注入，或者干脆把计算逻辑外挂成工具调用，不要让模型在上下文里硬算。
• 跨文档综合：不要指望分别注入。要么一次性联合处理，要么用上下文拼接把多份文档放进同一个提示词，并做好长度控制。
• 垂直知识增强：优先 LoRA 而不是全量微调，除非你有完整的通用能力回归测试来兜底。

四步选型流程

第一步，先判断你的任务是不是「单文档 + 事实型」。如果是，KV 前缀方案是首选，性价比远超其他两条路。

第二步，判断有没有数值计算需求。有就把这条任务单独拆出来，别和事实问答混在同一个注入方案里。

第三步，判断要不要跨文档综合。要的话，直接放弃「分别注入再组合」的幻想，改成一次喂全或者上下文拼接。

第四步，做遗忘回归测试。无论选哪条路，都要在注入前跑一遍通用能力基准，注入后再跑一遍，对比差值。全量微调如果掉了 10 分以上，就要认真考虑换 LoRA。

别忘了成本才是真正的驱动项

这篇论文最有价值的地方，是它把「性能—体积」曲线画出来了，而不是只比谁分数高。

54 MiB 对 509 MiB 对 3072 MiB，这三个数字才是工程决策的真正依据。在真实的线上服务里，决定你能服务多少用户的不是准确率，而是每份知识占用多少显存。准确率差 3 个百分点通常可以靠流程和兜底补上，显存差一个数量级补不了。

所以选型的正确顺序是：先确定你的部署约束（显存、并发、延迟），再看在这个约束下哪条路的准确率最高，而不是反过来。没有银弹，只有在准确率、可组合性和持久性之间的取舍，而成本是最终的裁判。