この記事では、LLM評価パイプラインで temperature=0 を使うときに、推論モデルが反復ループへ入り、最終回答やO/X判定に到達しないケースを扱う。
対象はモデルの順位やRAGスコアの分析ではなく、評価を止める機械的な失敗をどう検知し、どう例外処理として残すかである。

背景には、LLM-as-judgeや回帰テストで再現性を重視すると、低温・greedy decodeを選びたくなるという実務上の事情がある。
「再現性のために temperature=0 で回す」は、LLM 評価ではほぼ定石だ。
同じ入力なら同じ出力に近づけやすく、回帰テストやLLM-as-judgeの条件固定にも向いている。

ただし、確認したローカルの**推論モデル(reasoning model)**と長文評価の条件では、temperature=0 が「安全」とは限らない場面があった。
生成側でも判定側でも、推論が同じ句を反復し続け、最終出力に到達しない反復ループを踏んだ。

この記事の目的は、temperature=0 を主経路に残したまま、失敗を機械的に検知したときだけ例外経路へ1回だけ切り替える運用を示すことである。
評価の再現性を守りながら、壊れた出力だけを手続きとして扱うのが現実的だった。

ここでは、手元の日本語RAG評価で見た失敗を具体例として使う。
ただし主題は、その評価のスコアやRAG構成ではなく、LLM評価パイプラインを運用するときの失敗検知と例外処理である。
この記事単体で「ローカルLLMや推論モデルを評価に使うときのTips」として読めるように、データセットやRAG構成の詳細には踏み込まない。
一方で、判定側の反復サンプルはプロンプト中の語句と対応しているため、Judgeプロンプトの骨格は本文中に置く。

前提環境

具体例として使う評価環境は、次のようなものだ。

日本語PDFを根拠にしたRAG評価で、300問を一括で回答生成し、その後にLLM-as-judgeで O/X 判定する。
生成とJudgeのどちらにも、ローカル実行の推論モデル qwen/qwen3.6-35b-a3b を使った。
実行は LM Studio の OpenAI互換API経由で、通常経路は temperature=0 に固定した。
Judgeは、質問、正解例、生成回答を受け取り、JSONで reason と judge を返す。
judge フィールドは O または X の二択で、評価スクリプトはこれを最終判定として集計する。

以下では、この judge フィールドに入る最終的な O/X 判定を verdict と呼ぶ。
本文では、「判定理由」やreasoning途中の文章と区別するために verdict と書く。
生成とJudgeに同じモデルを使う構成では、自己選好や誤りの相関まで解消できない。
この記事ではその評価限界ではなく、O/Xに到達しない機械的な失敗をどう扱うかに絞る。

先に結論

通常は temperature=0 のままでよい。決定論ベースラインとしての価値は高い。
ただし低温・greedy decode が反復的な出力に落ちること自体は、ニューラルテキスト生成の既知の問題である。
LLM評価では、通常の回答生成だけでなく、LLM-as-judgeでも同じ型の失敗が起きる。
Judge は verdict が出ない ? のときだけ、temperature=0.3 で1回だけ再判定する。
生成側は最終回答が空になるなど明確に壊れたときだけ、同条件で1回だけリトライする。
人手で O/X や回答を書き換えない。救済はあくまで手続き側で行い、ログに残す。

既存知見との差分

低温・greedy decode で反復が出ること自体は、公知の問題として扱ってよい。
たとえば Holtzman らの The Curious Case of Neural Text Degeneration は、尤度最大化系のdecodeが不自然で反復的なテキストを生みやすいことを論じている。
同論文の OpenReviewページでも、最大化ベースのdecodeが repetitive loops に陥る問題として説明されている。
また、NeurIPS 2022の Learning to Break the Loop は、文単位の反復ループを分析し、軽減手法を扱っている。

したがって、この記事の差分は「temperature=0で反復が出る」という発見そのものではない。
ここで扱う差分は、評価パイプラインの生成側と LLM-as-judge の両側で同じ型の障害として出ること、そして評価運用では「壊れた出力をどう無効化・救済するか」を事前に決めておかないと、再現性とフェアネスを同時に壊すことである。
この整理は推論モデル一般の断定ではない。
少なくとも、確認した qwen3.6-35b と長文の RAG 評価条件では、この失敗モードを前提にしたほうが運用しやすかった。

verdict(最終判定)が出ないまま打ち切られる判定側

使っていたJudgeは、質問、正解例、評価対象回答を渡し、主要な事実・数値・結論の一致で O/X を返すものだった。
設問ごとに入力本文は変わるが、プロンプトの骨格は次のような形である。

あなたはRAGシステムの回答品質を評価する厳格な採点者です。

[質問]
{question}

[正解回答]
{target_answer}

[評価対象の回答]
{answer}

評価対象の回答が、正解回答と照らして質問に正しく答えているか判定してください。

判定基準:
- 正解回答に含まれる主要な事実・数値・結論が評価対象の回答にも含まれていれば「O」
- 主要な事実が欠落している、数値が異なる、矛盾する内容がある、
  「分かりません」等の回答放棄をしている場合は「X」
- 表現の違いや追加情報は減点しない。事実の一致のみを評価する

必ず次のJSON形式のみで出力してください:
{"reason": "判定理由を1文で", "judge": "O または X"}

このJudgeを temperature=0 で回したとき、ある設問で判定(O/X)が返ってこなかった。
reasoning を見ると、

…主要な事実・数値・結論が正解回答に含まれる主要な事実・数値・結論が…

と同じ句を反復し、max_tokens を 16384 でも 32768 でも使い切って、verdict に到達しない。
greedy デコード(temperature=0)が、長文対で同じトークン列に吸い込まれた反復ループと見ている。

対処は、Judge 全体の温度を上げるのではなく、失敗した設問だけを次の手順で救済することにした。

通常判定は temperature=0 のまま実行する。
verdict が O / X に到達せず ? になった場合だけ、失敗として扱う。
その設問だけ temperature=0.3 で1回だけ再判定する。
それでも壊れるなら、手で直さず失敗として記録する。

ここでの ? は、モデルに出させる判定値ではない。
出力から O / X を抽出できなかったときに、評価スクリプト側で付ける失敗ラベルである。

temperature=0.3 にすると greedy 固定から外れ、同じ反復トークン列に吸い込まれる状態が解けて verdict が出た。
299/300 は temperature=0 のまま不変だった点が、運用上の判断を支える。
全体の決定論を崩すのではなく、詰まった1問だけを手続きとして救済する。

`</think>` の後が空になる生成側

同じ現象は生成側でも起きた。
ある設問で、生成モデルが推論を 6万トークン超・500秒以上続け、</think> の後の最終回答が空になった。
judge は当然「回答が空」で X を付ける。

このケースでは、入力文脈や正解データが空だったわけではない。
モデルが reasoning 内で迷走し、最終回答に何も出せなかった。

生成側も、Judge と同じく失敗した設問だけを次の手順で救済する。

通常生成は temperature=0 のまま実行する。
最終回答が空、または構造的に壊れている場合だけ失敗として検知する。
温度は上げず、同じ設定で同じ設問を1回だけリトライする。
2回目も壊れるなら、手で補正しない。

1回リトライしたら、正常な回答(数千トークン・1000字程度)が返って O になった。
少なくともこのケースでは**一過性(再現しない)**で、1回で回復するタイプの失敗だった。

実装方針

実装としては、次のようなポリシーにしておくのが扱いやすい。

表1: temperature=0運用時の失敗条件と救済方針

箇所	通常	失敗条件	救済	上限
Judge	`temperature=0`	verdict が `O` / `X` にならない	`temperature=0.3` で再判定	1回
生成側	`temperature=0`	最終回答が空、または明確に壊れる	同条件で再生成	1回

この設計で避けたいのは、次の2つだ。

最初から温度を上げて、全件の評価条件を揺らしてしまうこと。
失敗した設問だけ人間が都合よく補正して、評価を cherrypick 化してしまうこと。

「主経路は決定論、例外だけ機械的に1回切り替える」と決めておけば、評価ログも説明しやすい。
重要なのは、救済条件を実行前に固定し、回数上限を置き、対象 idx と再実行結果を残すことだ。
O/X の手修正や、良い結果だけの採用はしない。

教訓

temperature=0 は、再現性を高めるための有効な設定だ。
ただし、推論モデルの長文評価では「決定論である」ことと「安全である」ことは同じではない。

ローカル LLM を RAG 評価に使うなら、生成側と判定側の両方に反復ループが起きる前提で、失敗検知・1回だけの例外処理・ログ保存までを評価手順に含めておくのがよい。

具体例で使った再現基盤 → RAG Eval JA Repro

業務文書RAGやローカルLLM評価の再現性設計、評価データ整備、運用ログ設計に取り組んでいる。
社内ナレッジ活用やオンプレ生成AIの評価設計にご関心があれば、お気軽にご相談を。
→ サカタコンサル(SAKATA Consulting) https://www.sakata-consul.com/