7月31日、Quesmaが「A lesson about retries, hidden in the DeepSeek-V4 paper」と題した記事を公開した。LLMのリトライ処理が統計的バイアスを引き起こし、ベンチマーク結果を歪める可能性があることを、10万件の実験で実証した内容だ。
DeepSeek-V4論文に埋め込まれた警告
注釈として補足しておくと、ここで言及するDeepSeek-V4は、arxiv:2606.19348で公開された論文に基づくモデルであり、広く知られるDeepSeek-V3やDeepSeek-R1とは異なるモデルを指す。読者は混同しないよう注意されたい。
その論文の一節が、LLM運用の実務に関わる重要な指摘を含んでいる。
数学的に正しくないのは、未完了のリクエストを最初からやり直すことだ。これは長さバイアス（length bias）を生む。短い応答ほど中断を生き延びやすいため、中断が発生するたびにモデルは短い出力を返しやすくなる。
リトライはシステム信頼性の定番手法だ。しかし、LLM推論においては「長い応答ほど中断されやすい」という非対称性が存在する。失敗した長いリクエストをリトライすると、今度は短い応答が返ってくる確率が上がる。これが問題の核心だ。
10万件の詩で検証した
実験の設計
Quesmaはこの仮説を実証するため、DeepSeek-V4-Flashに10万件の文学作品を生成させた。費用は6.06ドル。プロンプトは以下の通り：
一行詩、俳句、小説の章、リメリックのいずれかをランダムに選び、完成した作品を一つ書け。
結果の内訳は以下の通りだった：
- 73.2%が俳句：平均15語と非常に短い
- 11.5%が小説の章：平均503語と、俳句の34倍の長さ
全体の平均は74語だが、応答長のばらつきは非常に大きい。
障害のシミュレーション
次に、リクエストの10%がランダムに中断される障害を統計モデル（ポアソン過程）でシミュレートした。平均中断間隔を31秒に設定すると、この10%という失敗率が再現できる。
ポアソン過程を使った失敗確率の計算式は以下の通りだ：
$$P(\text{failure during request}) = 1 - e^{-\text{request time} / \text{mean time between interruptions}}$$
俳句は平均2.38秒で生成されるため、失敗率は約**7.4%。一方、小説の章は平均11.52秒かかるため、失敗率は約31.0%**に跳ね上がる。応答が長くなるほど失敗率が上昇する構造だ。
リトライを加えると何が起きるか
失敗したリクエストに対してリトライを繰り返すシミュレーションを実行した結果、最終的なデータセットは以下のように変化した：
| 指標 | 障害なし | 障害あり＋リトライ | 変化 |
|---|---|---|---|
| 平均語数 | 73.51語 | 59.40語 | −19.2% |
| 600語以上の応答数 | 2,904件 | 1,961件 | −32.5% |
| 小説の章の数 | 11,499件 | 8,919件 | −22.4% |
平均応答長が約20%短縮され、長文応答は3割以上減少した。リトライによって「本来長い応答になるはずだったリクエスト」が「短い応答」に置き換えられているからだ。
この現象は統計的には選択バイアス（selection bias）および生存者バイアス（survivorship bias）として説明できる。リトライされたサンプルは長い応答が過剰に含まれており、最終データセットには「中断という篩を通り抜けた応答」だけが残る。短い応答ほど生き残りやすい。
ベンチマークへの影響が本質的な問題
詩の長さが変わる程度ならば実害は小さい。しかし、同じ問題がベンチマーク環境で起きると話が変わる。
長いリクエストが失敗する原因として考えられるのは、推論ループへの迷い込みや誤った方向への進行だ。そういったリクエストをリトライすると、モデルに「やり直しの機会」が与えられ、スコアが不当に向上する可能性がある。
ベンチマーク研究者にとってこの問題が特に深刻なのは、バイアスが「見えにくい」からだ。リトライは正常系の挙動として実装されるため、ログを見ても異常は現れない。測定環境のインフラ構成——負荷分散の設計、タイムアウト設定、リトライポリシー——が静かにスコアを動かしている可能性があり、再現性の担保が難しくなる。評価基盤の信頼性を議論する際に、この「インフラ起因のバイアス」を明示的に制御・報告する慣行が今後求められるだろう。
3つの対処法
Quesmaは記事の末尾で、この問題への対応策を3点まとめている：
- DeepSeek自身のアプローチ：中断されたリクエストを最初からやり直すのではなく、途中から再開できるようシステムを設計する
- リトライが安全なケース：失敗が応答長と無関係に純粋にランダムで発生するなら、リトライはバイアスを生まない
- 影響範囲の整理：ベンチマークや研究用途では重大な問題になり得るが、一般的なコンシューマー向けアプリケーションでは実質的な差は生じにくい
DeepSeek-V4論文のわずかな記述が、実験を通じてシステム設計の判断に直結する統計的教訓として可視化された事例だ。リトライを「とりあえず入れておく」設計判断が測定結果を歪めるリスクを持つことは、LLMを用いた評価基盤を構築するエンジニアにとって覚えておく価値がある。
詳細はA lesson about retries, hidden in the DeepSeek-V4 paperを参照していただきたい。
