最も目を引くのはGPT-o3が0点を取ったことではなく、基礎的なDebug問題で満点から直接ゼロに転落した一方で、メイン榜が2.1ポイント上昇したことだ。
今回の事故の中心問題は「Debug：行列回転」だ。前回GPT-o3はこの問題で100点を獲得したが、今回は0点となった。問題自体は奇問ではない：N×N行列を時計回りに90度その場で回転させるもので、標準的な解法は主対角線で転置した後、各行を反転させることだ。GPT-o3もこのルートを書き出したが、最後のステップが実際には実行されていなかった。
for i in range(n): matrix[i].reverse
問題はここだ：reverseに括弧が欠けている。リストメソッドオブジェクトを取得しただけで、呼び出されていない。結果として関数は転置だけを完了し、行列の時計回り回転は完了しなかった。厳格な問題に対しては、これは「惜しい」ではなく機能的な誤りであり、100から0への判定は妥当だ。
知識がないのではなく、実行チェーンが切れている
さらに注目すべきは、GPT-o3の全体データが連動して崩壊していないことだ。v6メイン榜は73.62から75.69に上昇、2.1ポイント上がった；素材制約は66.80から73.10に上昇、6.3ポイント上がった；コード実行は79.20から77.80への低下にとどまり、1.4ポイント下がっただけだ。つまり、今回の事故はモデルの全面的な退化ではなく、典型的な「局所的な致命的失敗」だ：全体は良く見えるが、単一点で開発者が落とし穴にはまるには十分だ。
この種の失敗は「全くわからない」よりも危険だ。なぜならモデルは正しい思考過程を説明し、コメントも模範解答のように書かれており、読者は一見してタスクが完了したと思うからだ。本当の誤りは1つの括弧の中に隠れている。テストケースがなければ、人による審査では見落としやすい。
メイン榜の上昇が厳格な問題のリスクを覆い隠す
YZ Index v6によると、メイン榜はコード実行と素材制約という2つの監査可能な次元のみを見る。今回のメイン榜の上昇は、主に素材制約の改善によるものだ：66.80から73.10へ、上昇幅は6.3。これはGPT-o3が今回より問題文に沿い、素材を活用できることを示しているが、すべてのコードパスが正しく実行されることを保証するものではない。
コード実行は79.20から77.80へ、わずか1.4ポイントの低下で軽微に見える；しかし「行列回転」が100から0になったことは、平均点が事故の深刻度を希釈することを示している。エンジニアリングチームにとって、平均点は本番投入の保険ではない。1つの初歩的なAPI呼び出しのエラーが、一見正しいアルゴリズムを本番で誤った結果を返させる可能性がある。
サイド榜のシグナルに分裂が現れる
エンジニアリング判断（サイド榜、AI支援評価）は43.50から51.30に上昇、7.8ポイント上昇；しかしタスク表現（サイド榜、AI支援評価）は40.00から30.00に低下、10ポイント下がった。このデータの組み合わせは興味深い：方向性の判断はより上手くなったかもしれないが、タスクを完全かつ検証可能な形で提出する能力はむしろ弱くなっている。
この問題に当てはめると、GPT-o3の判断方向は誤っていない：転置プラス行の反転。しかし提出レベルで失敗している：reverse()を呼び出さず、最小限のテスト検証も提供していない。これはまさに「分かっているように見えて、実行するとエラー」という典型的な事故パターンだ。
安定性が低いことは、正答率が低いことと等しくない
今回の安定性は37.4から35.9に低下し、引き続き低めだ。しかし強調すべきは、安定性は回答の一貫性を測るもので、スコアの標準偏差に基づき、計算式はmax(0, 100-stddev×2)であり、正答率ではない。35.9の意味は：同種の問題で複数回回答した際にスコアの変動が大きく、出力が十分に一貫していないということ；「正答率35.9%」と解釈してはならない。
これはGPT-o3のリスク像にとって重要だ：使えないわけではない。可用性は依然として100.0で、正常に応答できることを示している；コストパフォーマンスは8.5から8.4へ、基本的に安定している。しかし厳格なコード問題では「高い自信を持った初歩的な誤り」が現れる。この種のエラーはより長い説明では解決できず、実行、テスト、判定によるバックアップに頼るしかない。
結論：GPT-o3は候補プログラマーとして扱うべきで、最終判定コンパイラーではない
今回の事故が示す結論は明確だ：GPT-o3の素材適合能力は向上しており、メイン榜も上昇しているが、コード提出には依然として針の先ほどの断裂が存在する。特に基礎的なAPI呼び出しのようなエラーは、モデルが実際にコードを実行していないという短所を最もよく露呈する。
私の使用上の助言は直接的だ：GPT-o3に初稿を書かせるのは良い、思考を説明させるのも良い、しかし厳格なロジック、配列変換、境界条件の密集したコードシナリオに入る場合は、必ずテストを付ける必要がある。テストのないモデルコードは、本質的に「文法的に答えのように見える」テキストにすぎない。
この一言を覚えておこう：メイン榜の上昇は事故の消失と等しくない；本当のエンジニアリングリスクは、しばしば欠落した一対の括弧の中に隠れている。
データソース：YZ Index | Run #112 | 元データを見る
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接