Doubao Pro、Smokeテスト5次元すべて欠席――API障害によりゼロ記録

Doubao Pro は本日のSmokeテストにおいて、execution・grounding・judgment・integrity・communicationの5次元のスコアがすべて「-」を示し、メインランキングのスコアも同様に「-」となった。同モデルはAPI障害・タイムアウトにより一問も回答を完了できなかったため、今回はランキングに参加しない。

データの事実：ゼロ記録はAPI中断に起因

スコア比較表では昨日・本日ともに全次元が「-」を示しており、いかなる数値も生成されなかった。これは、評価プロセスがAPI呼び出し段階で既に終了しており、モデルが10問に回答した後にスコアが変動したのではないことを示している。Smokeテストは1日あたり各次元2問のみであり、1日単位の変動は通常の範囲内だが、完全に結果が返らないケースはAPIタイムアウトまたはサーバー側の応答拒否の場合にのみ見られる。

原因分析：モデルの劣化ではなく技術的呼び出し失敗

問題の抽選による変動は通常、回答完了後にスコアが隣接する範囲内で小幅に移動する形で現れる。一方、今回は5次元が同時に欠失しており、リクエスト送信後に呼び出しチェーンが中断したことを示している。API障害・タイムアウトの記録はサービス可用性の問題を直接示すものであり、コード実行や資料制約タスクに対するモデルの理解能力の低下を意味しない。エンジニアリング判断とタスク表現の2つのサイドランキング次元も同様に欠失しており、中断がモデルの推論前に発生したことをさらに裏付けている。

API障害によるゼロ記録と、モデルが同種の問題に複数回回答した際のスコア標準偏差の増大によるスコア安定性の低下とは、メカニズムがまったく異なる。

利用者への意味

コード実行を重視するチームが本番環境でDoubao Proを呼び出す場合、APIのレスポンス成功率を追加でモニタリングする必要がある。資料制約に敏感なシナリオも同様にリクエスト拒否のリスクに直面しており、ワークフローの中断を引き起こす可能性がある。開発者が同モデルを用いて連続タスクを実行する場合、1回のタイムアウトがバッチ処理全体の失敗につながり、リトライおよびフォールバックロジックの開発コストを増加させる恐れがある。

• モデル選定を行う企業へ：Doubao Proをメインモデルとして採用する場合、バックアップAPIエンドポイントまたはローカルキャッシュ戦略を準備する必要がある。
• 同モデルに依存する開発者へ：今回のSmokeテストにおける中断シグナルは、日常的な呼び出しにタイムアウトリトライとヘルスチェックを組み込むべきであることを示唆している。

戦略的判断

今回の事象はAPI可用性の問題のみを反映しており、モデル能力の劣化を示す根拠にはならない。メインランキングでスコアが取得できなかったため、コード実行や資料制約における実際のレベルを比較することはできない。次回のSmokeテストで同様の欠失が再び発生した場合はAPI安定性の検証を優先すべきであり、正常な回答が再開された場合は今回の中断を偶発的な技術障害とみなしてよく、Doubao Proのコア能力に関する評価を見直す必要はない。

現在のスコア比較に基づけば、Doubao Proの今回のランキング欠席は呼び出し層の障害に直接起因するものであり、モデル内部のパフォーマンス変化とは無関係である。企業および開発者は、モデル自体のスコア変動よりもAPIの可用性モニタリングに注目すべきである。

データ出典：YZ Index | Run #268 | 元データを見る