测试 Mixture-of-Agents 的编程、算术与推理能力

我测试 Together AI 的 Mixture-of-Agents（MoA），这是一个组合多个语言模型输出的系统。相关[论文](https://arxiv.org/abs/2406.04692)报告，在 2024 年的特定配置下，MoA 在 AlpacaEval 2.0 上获得 65.1%，GPT-4o 为 57.5%。这一由评判模型参与的基准结果不能证明 MoA 在每项任务上都胜过 GPT-4o，也不能说明本次演示复现了论文的确切配置。

我使用 Together AI 的原版演示，配置 Qwen2-72B-Instruct、Qwen1.5-72B-Chat、Mixtral-8x22B-Instruct 和 DBRX-Instruct。Qwen2 是最终的汇总模型。我保留默认温度，并将最大输出从 512 提高到 2,048 个 token。这只是一个配置，并非与各单独模型的系统比较。

首先，我要求一个打印 1 到 100 的 Python 脚本。出现速率限制错误并重试后，汇总回答提供了正确的基础脚本，以及我没有要求的额外格式示例。我将基础任务判为通过。

接着我要求编写贪吃蛇游戏。多模型流程需要时间，因为它要查询多个系统并汇总回答。它提供了 turtle 图形实现和 curses 实现，而非我通常使用的 Pygame 方案。

我粘贴并运行 turtle 版本：窗口出现了，但游戏没有开始。随后我尝试 curses 版本，在缺少模块报错后安装 Windows 支持，但仍无法运行。我将这项编程测试判为失败；仅凭演示无法确定原因是模型推理、汇总、环境还是实现方式。

我请求帮助进入一辆汽车，系统拒绝了这一请求，同时建议寻求合法帮助。我在自己的评分标准中将其判为失败，因为我想要直接回答，但拒绝潜在不安全的请求并不能说明系统未达到安全目标。

我问，如果五件衬衫需要四小时晾干，20 件需要多久。回答称，如果衬衫所处条件相同且空间充足，大约也需要四小时，同时指出气流和湿度可能让时间更长。我赞赏这些明确的假设：计算依赖于独立并行晾干，并非对现实情况的普遍保证。

对于 25 − 4 × 2 + 3，系统先算乘法，给出 20。另一道酒店题中，每晚房价为 99.95 美元、税率 8%，另有一次性免税费用 5 美元；系统给出 x 晚的公式 1.08 × 99.95 × x + 5。我认为两题都正确，尽管输出较冗长。

我要求模型统计自己回答中的词数。它报告 626 个，而我的外部计数器显示 761 个，因此我判为错误。我重新考虑了多智能体会有帮助的预期：中间回答无法自动准确统计最终汇总文本的字数。

一个谜题中，房间里原本有三个杀人者；第四个人进入并杀死其中一人，没有人离开。系统将两名存活的原杀人者与新杀人者相加，得到三名活着的杀人者。这个答案假设进入者此前不是杀人者，并且计数不包括死者。

在一颗弹珠放入玻璃杯、杯子倒置后又被拿起放入微波炉的问题中，回答考虑了弹珠落到桌上或地板上，或者留在杯中的可能性。我称赞其看似细致的推理，但它暗示大气压或缓慢操作通常能将弹珠固定在未密封杯中，这种说法缺乏物理依据。按照普通开口杯的理解，弹珠会掉出来，实际情况仍取决于操作方式和几何条件。

我要求十个以“apple”结尾的句子。首次展示的结果没有满足约束。重试时系统满足了要求，我部分依据自己所说的先前测试结果判为通过；报告两次尝试很重要，因为重试和主观评分会改变表面结果。

最后，我问一个人五小时挖出的坑，50 人需要多久。系统在完全按比例分工的假设下给出六分钟，然后列出空间、工具和协调等实际限制。我欣赏这些限定；理想化计算并不是预测 50 人真的能如此迅速地挖好同一个坑。

我的结论是，推理回答很有希望，但编程测试让我失望。我建议在比较候选实现时，让智能体或汇总模型执行代码。这是一项改进建议，并非本次测试已经证明的结果。