Jodie Burchell又回来聊AI编程了。这位JetBrains的数据科学家、Python倡导团队负责人，在最新一期播客里扔了个判断：大语言模型的优化战场，已经从"后训练"转向了别处。

这不是术语游戏。如果你还在用2023年的思路调模型，可能正在错过整个2024年的关键转向。

打开网易新闻 查看精彩图片

后训练：曾经的黄金标准

过去两年，"微调"（fine-tuning）几乎是每个LLM项目的标配。拿到基础模型，灌入领域数据，调整参数，期待它在特定任务上表现更好。

这个逻辑很直接：模型已经学了通用知识，你只需要教它你的特殊需求。

但Burchell点出了两个硬约束。第一，微调需要大量标注数据——而高质量标注本身就是瓶颈。第二，计算成本。每次全参数微调都是一场资源消耗战，对小团队尤其不友好。

更隐蔽的问题是：微调后的模型往往过拟合到训练数据的分布上，遇到真实场景的边缘案例反而脆断。

行业开始意识到，与其不断修改模型权重，不如改变模型看到的世界。

上下文工程：给模型戴上有色眼镜

这就是"上下文工程"（context engineering）崛起的背景。

核心洞察很简单：同一个模型，在不同上下文里表现天差地别。与其花两周微调，不如花两小时设计提示词结构、检索策略和工具调用流程。

上下文工程不是写更好的提示词那么简单。它是一套系统设计——包括：

• 检索增强生成（RAG）的文档切分与排序策略

• 多轮对话的状态管理

• 工具调用的时机选择与错误恢复

• 长上下文的窗口利用与信息压缩

JetBrains的观察是，开发者正在从"模型中心"转向"上下文中心"。模型权重越来越像基础设施，真正的差异化发生在数据流设计和交互编排层。

这解释了为什么2024年向量数据库、提示词工程平台和Agent框架的热度持续走高——它们都是上下文工程的基建。

多智能体编排：从独奏到乐队

比上下文工程更进一步的是"多智能体编排"（multi-agent orchestration）。

不再追求一个万能模型，而是把多个专用模型/模块组合起来，各取所长。一个负责代码生成，一个负责安全审查，一个负责测试用例设计，通过编排层协调工作流。

Burchell认为这个趋势将"彻底改变自然语言处理的工作方式"。

技术实现上，这涉及：

• 任务分解与路由决策

• 智能体间的通信协议

• 冲突消解与一致性保证

• 执行轨迹的可观测性

多智能体架构的隐性优势是容错性。单个模型幻觉可以被其他智能体交叉验证，复杂任务可以并行拆解，系统整体鲁棒性高于任何单一组件。

这也降低了厂商锁定风险——你可以混用不同来源的模型，而不必押注某一家。

当前有效的三类技术

播客里Burchell还梳理了当下最实用的LLM优化手段。我们按实施难度排序：

数据增强：低成本扩围

在标注数据稀缺时，通过生成合成数据来扩充训练集。技术包括同义词替换、回译、模板填充，以及用更强模型生成弱模型的微调数据。

关键是如何保证合成数据的质量边界——垃圾进，垃圾出，在LLM时代尤其致命。

迁移学习：知识的跨域搬运

把模型在一个任务上学到的表示，迁移到相似的新任务。这比从头训练省 orders of magnitude 的计算量。

迁移学习的有效性高度依赖源域与目标域的相似度评估。选错源任务，迁移反而带来负迁移（negative transfer）。

元学习：学会学习

最高阶的玩法是让模型习得"快速适应新任务"的能力本身。少量示例就能触发有效推理，这正是当下提示工程与上下文学习（in-context learning）的理论基础。

元学习的工程化仍在早期，但它指向一个诱人前景：未来模型可能不再需要任务特定的微调，而是通过精心设计的上下文就能即时适配。

一张图看懂范式转移

如果我们把LLM优化画成一张架构图，2023年和2024年的版本会是这样：

【2023版】

基础模型 → 后训练微调 → 部署推理

（重心在箭头1：修改模型权重）

【2024版】

基础模型 → 上下文工程层 → 多智能体编排 → 部署推理

（重心在箭头2和3：设计数据流与协调机制）

这个转移的底层驱动力是成本结构变化。GPT-4级别的API调用成本在过去一年下降了约两个数量级，而高质量微调所需的标注人力成本几乎没变。当"用更多token"比"改模型权重"便宜一个量级时，优化策略自然向后者倾斜。

JetBrains作为IDE厂商，对这个趋势感受尤深。他们的AI助手功能（如代码补全、解释、重构）越来越多地依赖上下文检索和工具调用，而非模型微调。用户项目代码、依赖库文档、运行时错误信息——这些实时上下文比任何预训练知识都更值钱。

开发者的行动清单

如果你负责一个LLM应用项目，2024年的优先级可能需要重新排序：

第一，投资RAG基础设施。不是简单接个向量数据库，而是文档切分策略、重排序模型、查询改写、多路召回的完整 pipeline。

第二，建立评估体系。没有自动化的离线评估，上下文工程的迭代就是盲人摸象。需要覆盖相关性、忠实度、答案完整性的多维指标。

第三，探索Agent边界。从单轮问答转向多步任务，识别你场景中适合拆解为子任务的环节。但警惕过度设计——不是所有问题都需要多智能体。

第四，延迟与成本的trade-off监控。更复杂的上下文工程和Agent编排意味着更高的延迟和token消耗，需要在用户体验和运营成本间找到动态平衡点。

第五，保持模型层的中立性。上下文工程和多智能体架构的价值之一，就是降低对单一模型供应商的依赖。设计时预留模型切换的抽象层。

Burchell的播客没有给出确定的未来图景，但指出了一个清晰的方向：LLM技术栈正在分层固化，模型层趋向商品化，真正的竞争壁垒向上移动——谁能更好地理解用户场景、设计数据流、编排多智能体协作，谁就能在应用层建立优势。

这对开发者是好消息。你不需要再追逐每一个新发布的模型权重，而是可以把精力投入到更持久的工程能力建设中：系统设计、评估方法论、产品化思维。

大模型的"后训练时代"或许没有彻底终结，但它确实不再是唯一的主战场了。