@IntuitMachine: 让小型模型超越其规模的唯一改变 1/ 大家都知道你需要一个 70B 模型才能在...上击败 GPT-4

# 让小型模型超越其规模的唯一改变 1/ 大家都知道，你需要一个 70B 的模型才能在复杂代理任务上击败 GPT-4。 我们用 8B 做到了——通过改变一个与模型无关的东西。 这篇帖子将告诉你，为什么你的代理最大的问题不在于大语言模型。 2/ 标准做法：给大语言模型喂入不断增长的文本历史，让它选择下一个动作，然后重复。 这种方法一开始有效……直到它失效。 错误不断传播。上下文膨胀。幻觉激增。一旦出了问题，你就得重新规划所有内容。 3/ 关键来了： 问题不在于模型的能力。 而在于你让它把计划结构、执行状态和输入/输出依赖全都塞进一个线性文本流里。 这就像在没有进程表的操作系统上运行程序。 4/ 解决方案：原子任务图（ATG） 不再使用文本轨迹，而是构建一个显式的有向无环图（DAG）。 每个节点 = 一次工具调用。 边 = 数据依赖关系。 大语言模型仍然负责思考——但现在由图表来承载结构。 5/ 三个关键操作让这成为可能： - 保持接口的递归：将任务拆分为子任务，同时保持输入/输出协议的清晰 - 依赖感知执行：并行运行独立分支；在执行前捕获错误的计划 - 最小化修复：当某处失败时，只修复损坏的子图——其余部分保持冻结 6/ 结果呢？ Llama-3.1-8B-Instruct 在 ALFWorld（家务任务）和 WebShop（购物任务）上击败了 GPT-4 + ReAct。 没有微调。 没有更多数据。 仅仅是通过将执行载体从文本切换为图。 7/ 为什么这行得通？ - 上下文缩小：每个节点只看到其局部输入——没有膨胀的历史 - 执行前验证：图让你在行动之前进行“思考” - 局部故障：修复 10% 的图，而不是重新规划 100% 8/ 反直觉的洞见： 在 7–70B 范围内，控制框架 > 模型大小。 你不是在从同一个果实中榨取更多汁液。 而是给模型一个更好的容器来倒入。 9/ 实际效果： • 步骤减少 20–40%（并行） • 幻觉下降 70% 以上（更窄的上下文） • 恢复速度提升 3 倍（最小化修复） • 无需训练，直接接入现有工具 API 这不是学术表演。这是可投入生产的架构。 10/ 更大的启示： 如果通过改变执行载体而非模型就能击败 GPT-4，那我们在哪些方面还过度参数化了？ 检索流程？ 代码生成？ 多模态工作流？ 图又一次胜出。 11/ [结尾 + 行动号召] TL;DR： 别再把你的代理计划存在文本里了。 把它存在 DAG 里。 小模型突然看起来聪明多了。