5个小模型组队,硬刚大模型:Memdoor 多智能体协作方案解析
Memdoor 展示了一个有趣的思路:用 5 个 Qwen3-27B 小模型组成团队协作,在 LiveCodeBench Hard 上击败了更强的单体模型。本文拆解它的工作流设计,以及这种“团队解题”模式对开发者的启发。
一个反直觉的实验结果
大模型圈子最近有个挺有意思的讨论:如果让 5 个能力中等的小模型组队解题,能不能打赢一个更强的单体大模型?
GitHub 上的开源项目 Memdoor 给出了一个肯定答案。它用 5 个 Qwen3-27B 模型组成协作团队,在 LiveCodeBench Hard 这个公认偏难的代码基准上,成绩超过了 Fable 5。消息在 Hacker News 上拿到 173 分、92 条评论,讨论热度不低。
这件事的价值不在于“谁比谁强”,而在于它验证了一条工程路径:模型能力不够,可以用协作结构来补。
Memdoor 的团队解题是怎么跑的
从项目仓库的 team-solve 工作流示例看,它的核心不是简单地把同一个问题丢给 5 个模型投票,而是设计了一套分工机制。
大致可以理解为几个环节:
- 角色拆分:不同模型实例承担不同职责,比如有的负责理解题意、有的负责出方案、有的负责写代码、有的专门做审查。
- 多轮交互:团队成员之间会交换中间结果,而不是各写各的。
- 结果聚合:最后由一个环节汇总、筛选或修正,输出最终答案。
这种结构其实很像人类程序员的真实协作:一个人写初稿,另一个人 review,第三个人补边界条件。单个人可能都会犯错,但流程能把错误率压下来。
为什么“小模型组队”可能更划算
登录解锁全文
以下内容需登录后阅读。注册/登录完全免费,无需付费。
评论(0)
还没有评论
延伸阅读
公众号
百宝软件工作室