向 GPT-4o 和 Claude 提供了完全相同的双摆提示。它们在几秒钟内选择了相反的角约定。
摘要
一项实验向 GPT-4o、Claude 3.5 Sonnet 等其他模型提供相同的双摆提示,结果显示它们选择了相反的角约定,导致在共享渲染器中立即出现可见的不匹配。这种约定分裂在不同模型家族间并非随机,表明在经典力学问题的训练数据分布中存在偏差。
我让 GPT-4o 和 Claude 3.5 Sonnet 各自根据同一份约定编写一个 JavaScript 双摆模拟器。相同的初始条件、相同的步长、相同的宿主渲染器同时绘制两个面板。这些摆立即以明显不同的方向摆动。原来一个模型从向上垂直方向测量 θ,而另一个模型从向下垂直方向测量 θ。两种约定在数学上都有效,但当宿主渲染器在 `public/workers/simulator-host.js` 中读取 `info.theta1` 和 `info.theta2` 并以相同的方式绘制两个面板时,这种不匹配就无法忽视。一个摆自然下垂摆动,另一个看起来就像在天花板上做体操。令我惊讶的是,这个问题暴露得如此之快。你不需要等待数千个时间步长后的混沌发散。约定分裂在第一个帧上就能看到。检查数学的单元测试对两者都会通过,因为两组运动方程内部是一致的。只有当它们被强制放入同一个渲染管线时,你才会发现它们对于“向下”的含义有分歧。该设置是一个并排的基准测试,名为 Physics Bench,每个模型都从 `lib/prompt.ts` 中定义的严格约定实现 `step`、`getInfo` 和 `reset`。模型从不编写自己的 `draw` 函数。宿主负责渲染,因此面板之间的任何视觉差异都是物理上的真实差异,而不是外观上的。我还注意到,当我测试更多模型(Gemini 1.5 Pro、Llama 3.1 70B 等)时,约定分裂并非随机。某些模型系列一致地选择一种约定而非另一种,这让我认为这已嵌入到它们关于经典力学问题的训练数据分布中。约定是有意严格的:恰好一个围栏代码块,第一行必须以 `function createSimulator(` 开头,没有导入、没有导出、没有 DOM 访问、没有绘图。模型返回的一切都是纯粹的模拟逻辑。这个约束使得约定不匹配如此清晰地被观察到,因为模型无处隐藏变通方法。好奇是否有人在使用 GPT-4o 解决其他涉及符号约定的物理或工程问题时看到过类似的约定分歧。
相似文章
面对“全知”GPT还是“多疑”Claude?Repair机制揭示大模型多轮对话中的不可靠行为
研究发现,GPT与Claude在多轮数学对话的纠错过程中表现出截然不同且不可靠的修复行为:有的模型抗拒修正,有的则过度修正。
发现一个工具,同时向GPT、Claude、Gemini和Grok提问,并给出一个共识答案
文章介绍了AllChat这个工具,它能同时查询GPT、Claude、Gemini和Grok,并返回一个共识答案,同时列出每个模型的回答概要。
'一刀切'式AI时代已终结。我实测了GPT-5.5、Claude 4.7、Gemini 3.1 Pro和DeepSeek V4 Pro——以下是最新前沿格局。
对GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro和DeepSeek V4 Pro的基准测试分析表明,没有单一模型在所有任务上占据优势;要实现最佳性能,需要采用多模型路由器,根据各模型的优势与弱点进行专门化使用。
@kapicode: 我一直在使用 Claude 作为“人类”来提示 @opencode 以重建参考项目,在同一测试平台上评估了四款 LLM…
一项针对四款大语言模型(Qwen、MiniMax、GLM)的评估显示,当使用 Claude 作为 Opencode 智能体工具的提示器时,一个较小的本地模型(运行在 3090 显卡上的 Qwen 27B)在代码质量与可靠性方面表现优于更大的剪枝模型。
同一个Agent,同一个提示,不同运行结果。你选择哪个输出上线?
作者注意到,在不同会话中用同一个Claude Code运行相同任务,会产生不同的决策模式,导致难以选择可以安全上线的输出,并指出目前缺乏评估Agent决策档案的工具。