この記事では、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/