架构决策：法律合同审查该用 RAG、微调还是 Long Context

一个法律合同审查 Agent 摆在面前：手上有 1000 份历史合同、500 页法律条文，目标是自动审出风险条款、给出修改建议。技术选型的第一个岔路口就很尖锐——把知识塞进 200k 的 Long Context？把条文和审查经验微调进模型？还是走 RAG 检索？这三条路不是“哪个更先进”的问题，而是把知识注入模型的三种根本不同的机制，各自在成本、延迟、准确性、可解释性、更新频率上有截然不同的表现。这篇文章先讲清三者本质，再给一张五维决策矩阵，最后落到合同审查这个具体场景，说明为什么答案是“三者结合”。

三种方案在做什么

看清本质才能谈取舍。RAG 是运行时检索：知识留在外部向量库/全文索引里，每次提问先检索相关片段，把片段拼进 prompt。知识和模型是解耦的，改知识不用碰模型。Fine-tuning 是把知识和行为**“烧”进权重**：用领域数据继续训练，模型学到的是风格、格式、领域语气，以及一部分被“记住”的事实。Long Context 是把材料一次性全塞进上下文窗口，让模型在单次推理里看到全部原文，不做检索也不改权重。

一个关键但常被忽视的事实：微调不擅长注入新的事实知识。“Fine-Tuning or Retrieval?“这篇论文的实验结论很直接——在知识密集型任务上，RAG 持续优于无监督微调，模型很难通过微调稳定学会新的事实内容。这决定了微调的正确用途是”教模型怎么做“，而不是“让模型记住是什么”。

五维决策矩阵

用五个维度给三种方案逐一打分（✅ 强 / ⚠️ 中 / ❌ 弱）：

维度	RAG	Fine-tuning	Long Context
成本	✅ 低。只付检索 + 少量 token，一次建库长期用	⚠️ 前期训练贵，推理便宜；每次更新要重训	❌ 高。200k token 每次全量计费，调用越多越烧钱
延迟	✅ 检索 10~50ms + 短 prompt 推理，整体快	✅ 推理快，prompt 短	❌ 首 token 慢，长上下文 prefill 随长度近线性增长
准确性	✅ 事实召回准，取决于检索质量	⚠️ 格式/风格准，新事实易幻觉	✅ 全局推理强，但长文档中段易“迷失”
可解释性	✅ 每条结论可溯源到具体条文片段	❌ 黑盒，无法指出结论来自哪条训练数据	⚠️ 材料在上下文里可见，但引用需模型自觉标注
更新频率	✅ 改库即生效，秒级更新	❌ 更新=重训，周期以天/周计	✅ 换材料即可，无需任何训练

矩阵读下来，没有一列全绿——这本身就是“单选题无解”的信号。RAG 的短板在准确性上限受检索质量约束、缺乏跨片段的全局视角；微调的短板是更新慢、不可溯源；Long Context 的短板是成本和长文档中段的注意力衰减（“lost in the middle”现象，关键信息落在超长上下文正中央时召回率明显下降）。

每种方案的适用边界

把矩阵翻译成选型直觉：

选 RAG，当：知识频繁更新（法规每年修订）、语料庞大（几千份合同装不进任何窗口）、且必须引用溯源（法律场景里“这条判断依据是第几条”是硬需求）。RAG 是唯一能天然给出出处的方案。

选 Fine-tuning，当：需要固定的输出格式（审查报告的结构化模板）、稳定的领域语气（法务措辞的严谨克制）、或让模型内化一套判断风格（什么样的条款该标红）。微调改的是“怎么表达和判断”，不是“知道什么事实”。

选 Long Context，当：单次任务只涉及少量文档、需要全局一致性推理（一份合同前后条款是否自相矛盾，必须同时看到全文才能判断）、且是一次性任务不值得建库。

边界的分野可以一句话概括：RAG 管“是什么”、Fine-tuning 管“怎么做”、Long Context 管“整体看”。三者回答的是不同问题，本就不该二选一。

合同审查场景：为什么是三者结合

回到 1000 份合同 + 500 页条文的具体场景，把任务拆开看，每一块恰好落在不同方案的强项上：

• 法律条文 → 用 RAG。500 页条文会修订、审查结论必须能指到“依据《合同法》第 X 条”，这两点直接锁死 RAG——把条文切块、做上下文增强后建向量 + BM25 混合索引，审查时检索命中的条款作为判断依据，天然可溯源、可更新。
• 审查风格与输出模板 → 用 Fine-tuning。用历史的 1000 份合同 + 人工审查批注做微调数据，教模型的不是条文本身，而是“看到这类模糊付款条款该如何措辞地标注风险”“审查报告该用什么结构输出”。这是格式和语气问题，正好是微调的主场。
• 单份待审合同全文 → 进 Long Context。审查当下这一份合同，把它整篇塞进上下文，让模型做全局一致性检查——第 3 条的定义和第 12 条的约定有没有冲突、有没有前后矛盾的金额或日期。这种跨条款推理必须看到全文，RAG 的分片检索反而会切断上下文。

三者的协作流水线是这样的：待审合同全文进 Long Context 打底 → 针对合同里的每个风险点用 RAG 检索相关法律条文和历史相似条款 → 微调后的模型按学到的风格和模板，结合全文语境和检索证据，输出带条文引用的结构化审查报告。每一层补上另一层的短板：RAG 补微调的事实缺口和溯源，微调补 RAG 的格式散乱，Long Context 补 RAG 缺失的全局视角。

混合架构什么时候值得

不是所有场景都值得上三层，混合是有成本的——你要同时维护向量库、训练管线和长上下文调用预算。判断标准是两个条件同时成立：一是准确性要求高到单一方案的短板不可接受（法律、医疗、金融这类错一次代价极大的领域）；二是任务既要领域风格又要知识可更新——需要模型有稳定的专业表达（微调），同时依赖的知识还在持续变化（RAG），单靠任何一个都会顾此失彼。合同审查两个条件都满足，所以值得。反过来，如果是内部文档问答这种“知识会变但对输出风格无所谓”的场景，纯 RAG 就够了，加微调是浪费。

成本与延迟的量化直觉

给几个数量级的直觉，帮助落地估算。成本上，RAG 的边际成本是检索 + 拼进去的几千 token，Long Context 把整份合同 + 条文塞进 200k 则是几十倍的 token 计费——高频调用时这个差距会主导账单；微调是一次性训练投入（几百到几千美元量级）摊薄到后续每次便宜推理。延迟上，长上下文的 prefill 时间随输入长度近似线性增长，200k 输入的首 token 延迟通常是几千 token 输入的一个数量级以上，对交互式审查体验影响明显；RAG 把检索控制在几十毫秒、prompt 压到几千 token，端到端快得多。所以哪怕不考虑准确性，纯为了成本和延迟，也不该把能检索的东西无脑塞进长上下文——Long Context 是给“必须全局看”的那一份合同用的，不是给整个知识库用的。

边界与取舍

这套混合架构的复杂度是真实代价：三条链路各有各的失效模式，检索召回不全、微调过拟合、长上下文中段丢信息，排障面比单一方案大得多。微调数据的质量决定成败，1000 份合同的批注若标注不一致，微调只会把噪声学进去。RAG 的效果高度依赖切块和检索策略，条文这种长依赖、多引用的文本切不好就会丢上下文。而且法律是高风险领域，无论架构多精巧，AI 审查结论都应当作为律师的辅助而非替代——系统的价值在于把可溯源的证据和结构化的初审摆到人面前，最终判断仍需专业人员把关。选型的终点不是选出“最优方案”，而是让每种机制只做它最擅长的那部分，并对各自的失效边界心里有数。

参考资料：Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs、Anthropic — Introducing Contextual Retrieval。