LLMに信頼度スコアを求めるのは悪い考え：キャリブレーションにはデータが必要であり、プロンプトではない理由

LLMに信頼度スコアを出力させることは、測定を生み出しません。それは、他のトークンと同じ方法で生成された、もっともらしく見える数字を生み出すだけであり、その数字がモデルの実際の精度を反映することを保証するものは何もありません。rumple.github.ioで広く議論されたブログ記事「Asking LLM for confidence」は、LLMが生成する信頼度スコアは、文書化された記録に基づき、実際の結果と照合されない限り信頼できないと主張しています。また、大規模なHacker Newsの議論では、トレーニング時のキャリブレーションと構造化プロンプトに関するいくつかの重要な反論が追加されました。

この記事はHacker Newsのホームページに掲載され、2026年10月22日に議論スレッドへのリンクを追加するために編集されました。この記事は元の議論を要約し、その後、コメントで提起された最も強い反論と追加点を総合します。

信頼度スコアが実際に意味するもの

信頼度スコアは、予測についての予測です。予報士が「明日雨が降る確信度は70%です」と言うとき、その70%は雨についての意見ではありません。それは、利用可能な情報が雨の方向をどの程度強く示しているかの要約です。

ブログ記事はその情報を2つの部分に分けています：現在の観測（気圧、湿度、風、レーダーの雲）と過去のベースレート（このような日にはどれくらいの頻度で雨が降ったか）。その情報を数字に変換することは、理論的には判断ではなく計算です。2人の予報士が同一の情報を持ち、同じルールを正しく適用すれば、同じ信頼度に到達しなければなりません。予報士が意見を異にする場合、彼らは異なる情報を持っているか、または一方がルールを誤って適用したかのどちらかです。

著者は、情報内容が重要となる2番目のシナリオを使用しています。2週間先の日について尋ねられた場合、予報士はその日の観測値を持たず、季節的なベースレート（例えば30%）のみを報告できます。日が近づき観測が蓄積されるにつれて、信頼度は0%または100%に向かって移動できます。

信頼度スコアが正確であることを検証する方法

単一の予測は信頼度スコアを検証できません。なぜなら、イベントは発生するか発生しないかのどちらかだからです。検証には、同じ表明された信頼度を共有する多くの予測をグループ化し、表明された率を観測された率と比較する必要があります。

予報士が多くの日に「70%の確信度」と言い、そのうち約70%で雨が降った場合、そのスコアはキャリブレーションされています。雨がそれらの日のうち40%しか降らなかった場合、予報士は過信していました。90%で雨が降った場合、予報士は過小信頼でした。ブログ記事は1年間のこの例の記録を示しています：

彼らが言った	日数	雨が降った日	率
10%	120	13	11%
30%	90	26	29%
70%	80	57	71%
90%	75	67	89%

すべてのレベルで、観測された降雨率は表明された信頼度に近く、予報士はキャリブレーションされています。

キャリブレーションだけでは十分ではありません。天気を完全に無視して常に30%（季節的なベースレート）と言う予報士も、キャリブレーションされています。なぜなら、それらの日の約30%で雨が降るからです。その予報士はインスタンスレベルの情報を決して使用しないため、その数字はシグナルを持ちません。表のより良い予報士は、キャリブレーションされており、かつ情報量が多いです。なぜなら、ほとんどの予測が10%または90%の近くに集中しているからです。

ブログ記事は3番目の、見落とされがちな要件を追加しています：誰かがすべての予測と実際に何が起こったかを書き留めなければなりません。その記録がなければ、信頼度スコアが正確かどうかを知る方法はありません。

したがって、2つの条件が信頼できる信頼度スコアを定義します：それは予測が基づいている情報の量を反映し、同じ種類の質問で実際に起こったことと照合されていることです。

LLMが単独でキャリブレーションされた信頼度スコアを生成できない理由

LLMはテキストを一度に1トークンずつ生成し、各トークンはその前のトークンに条件付けられます。これが「自己回帰」の意味です。ユーザーが「どの程度確信していますか？」と尋ねると、モデルは内部のゲージから値を読み取るのではありません。それは「0.85」という文字列をトークンごとに書き出します。なぜなら、その文字列が会話の自然な続きだからです。

上記の用語では、その数字は2つの必要な特性のどちらも持っていません。それは証拠を要約していません。なぜなら、それは測定ではなくテキストの続きだからです。そして、表明された信頼度がモデルの精度と一致するかどうかという質問に対してキャリブレーションされたことはありません。事前学習はモデルを結果に対してスコアリングしますが、その結果はテキストの次のトークンです。したがって、モデルは「次に来るテキストは何か」にある程度キャリブレーションされており、「0.85と言うとき、私はどのくらいの頻度で正しいか」にはキャリブレーションされていません。それは信頼度スコアがテキストでどのように見えるかを学びました。スコアを精度に一致させることを学んだわけではありません。

LLMの信頼度が信頼できないことを示す3つの観察可能な症状

ブログ記事は、自己回帰の説明から直接導かれ、誰でも再現できる3つの行動をリストしています：

再度尋ねると数字が変わります。同じ質問に対して、ある時は0.85、次は0.7という回答が得られることがあります。利用可能な情報は変わっていないので、ルールベースの信頼度も変わらないはずです。
言い回しを変えると数字が変わります。「本当に確信していますか？」と尋ねると、問題について何も変わっていなくても、通常スコアが動きます。異なる表現は新しい情報ではありません。
数字の前のテキストが数字を決定します。モデルがすでに「これは明らかに正しい答えです」と書いている場合、高いスコアが自然な続きです。スコアは証拠ではなく、先行する単語に従います。

モデルは常に数字を返し、その数字は正確に見えます。不正確なスコアは正確なスコアとまったく同じように見え、それらを区別する唯一の方法は、多くのスコアを解答キーと照合して採点することです。これは、LLMに信頼度を求めるほとんどの人が決して行わないステップです。

LLMに尋ねずに信頼度スコアを構築する

投稿が提案する代替案は、予報士が行うことを行うことです：観測可能な情報を信頼度に変換する明示的なルールを構築し、そのルールを結果に対してチェックし続けることです。LLMはタスク（例えば、返信を書くこと）を実行できますが、信頼度スコアはルールから得られます。

実例は、ヘルプセンターを検索して返信の下書きを作成するカスタマーサポートエージェントであり、低信頼度の下書きは人間にルーティングされるべきです。

情報を選択します。モデルにどのように感じるかを尋ねる必要のない観測可能なシグナルをリストします：検索でこのトピックに関する記事が見つかったか、いくつの記事が見つかったか、このタイプの質問が以前に回答されたことがあるか、同じ回答の2つの独立した生成が一致するか。
過去から始めます。他のデータが存在する前に、最良の信頼度はベースレートです。レビュー担当者が過去200件の返信をチェックし、150件が正しかった場合、すべての新しい返信は75%から始まります。
すべての返信と何が起こったかを記録します。各返信について、ステップ1のシグナル、ルールが割り当てた信頼度、返信が正しかったかどうか（レビュー担当者によって承認されたか、顧客が再度尋ねずに受け入れられたか）を保存します。
記録からルールを更新します。過去の返信をシグナルでグループ化し、各グループが正しかった頻度を測定します。一致する記事と2つの一致する生成を持つ返信が95%の確率で正しかった場合、ルールは次のそのような返信に対して95%と言うべきです。一致する記事がない返信が40%の確率でしか正しくなかった場合、ルールは40%と言うべきです。
チェックを続けます。毎週程度、キャリブレーションテーブルを再構築します：各信頼度レベルで、返信が実際に正しかった頻度は？90%の返信が70%の確率でしか正しくなかった場合、ルールは過信であり、新しい記録がそれを修正する方法を示します。

そのようなルールは、LLMの数字に欠けている特性を持っています：同一の情報は常に同一の信頼度を生み出し、スコアは表現ではなく情報に依存し、キャリブレーションは組織自身の記録から構築されたため、組織自身の質問タイプで測定されます。ルールは使用とともに改善されます。なぜなら、すべての返信が記録に追加されるからです。ただし、ルールは記録と同じくらいしか良くありません。返信が正しかったかどうかを誰もチェックしない場合、学ぶべきものはなく、システムは測定されていない数字に戻ります。

主な反論：キャリブレーションはモデルに訓練できる

複数のHacker Newsコメント投稿者は、LLMが「正確さに対してスコアリングされたことがない」という投稿の主張は、もはや正確ではないトレーニングプロセスに関する仮定であると主張しました。コメント投稿者のrahimnathwaniは、Sebastian Raschkaのキャリブレーションに関する執筆と、キャリブレーション報酬を用いた強化学習を指摘しました：

「RLCRは報酬にブライアー・ペナルティを追加するため、モデルのパフォーマンスは%の正確さだけで測定されません。ブライアー・ペナルティ、(q-c)^2は、インスタンスレベルの情報を無視する予報士を罰します。」

コメント投稿者は、60%の確率で正しいモデルのための2つの戦略でメカニズムを説明しています。常に0.6と答えることはキャリブレーションされていますが、シグナルを持ちません。なぜなら、期待されるペナルティは0.6 * (0.6-1)^2 + 0.4 * (0.6-0)^2 = 0.24だからです。簡単なケース（90%の確率で正しい）と難しいケース（30%の確率で正しい）を区別でき、それぞれ0.9と0.3と答えるモデルは、期待されるペナルティが(0.09 + 0.21) / 2 = 0.15です。両方のスコアリング戦略は全体的に同等にキャリブレーションされていますが、2番目の方がスコアが良いため、ブライアー型のペナルティがトレーニングを一定のベースレートではなくインスタンス固有の信頼度に向かわせる理由です。

他のコメント投稿者は関連するポイントを述べました：

コメント投稿者のm101は、単一の次のトークンではなく、次のトークン上の分布を予測するJev型トレーニングが、まさにこれに対処するために設計されているかどうか尋ねました。
コメント投稿者のyaoke259は、正しい信頼度を生成することが実際のまたはシミュレートされた環境（天候の結果、ゲームの結果）でのRLトレーニングターゲットである場合、モデルはJevや決定モデルが訓練されるのと同様に、信頼度に対する強い直感を発達させる可能性が高いと主張しました。
コメント投稿者のOzzie_osmanは、特定のドメインの信頼度スコアを既存のモデルにファインチューニングすることが機能すると報告しました：「基本的に、モデルがどのようなタイプの入力で正解する傾向があり、どのようなタイプで間違える傾向があるかを理解するのを助けます。」
コメント投稿者のqzncは、フレーミング全体に異議を唱え、記事自体がアプローチが悪いことを証明するデータを示しておらず、Metaculusでの予測パフォーマンスをLLMがこれに優れている可能性がある証拠として挙げました。
コメント投稿者のjrfloは同じ証拠の要求をしました：「執筆者がLLMの信頼度スコアの品質という興味深いフレーミングを、それがどれほど良いかについてのデータでフォローアップすることを期待していました...誰かが測定可能な何かでデータを収集したなら、LLMの信頼度の数字がそれほど遠くないと賭けてもいいでしょう。」

実践者が提案する実用的な緩和策

コメント投稿者は、「LLMに数字を求める」と「完全な統計ルールを構築する」の間にあるいくつかの具体的なテクニックに収束しました。

0-100スケールを使用する代わりに評価を分解します。コメント投稿者のorbital-decayは、広い数値スケールはモデルまたは人から判断を引き出す最悪の方法であり、問題を多くの次元に分割し、各次元に小さな意味のある列挙型または粗いスケールを与え、加重スコアリングを適用することを提案しました。YouTubeは同じ理由で1-5評価スケールを廃止したと報告されています。

ルーブリックまたは測定可能な基準を使用します。コメント投稿者のcityofdelusionは、直接測定できる量には採点スクリプトを使用し、あまり明確でない判断には明示的なAからFの基準を持つ採点マトリックスを使用することを説明しました。コメント投稿者の重要なポイントは、信頼度が数学的にまたはルーブリックとして表現できない場合、実装者はターゲットを測定する方法も知らず、人間は「直感と雰囲気で数字を決めている」ことになるということです。コメント投稿者のYmFzZTY0ZGFkZHkは、より粗い記述的信頼度（例えば、メジャー対マイナー）が同じ幻想の異なる味であるかどうか尋ねました。

自己報告の代わりにログ確率または繰り返しサンプリングを使用します。コメント投稿者のdummydummy1234は、許可された出力クラス上のログ確率と組み合わせた構造化出力を提案しました。コメント投稿者のjvanderbotは同じアイデアを提起し、語彙を入力ラベルに制限することで次のトークンの尤度を使用可能な信頼度に変えるかどうか尋ねました。コメント投稿者のbob1029は、多くの同一のリクエストを発行し、ツールの選択または回答の外部分布を測定し、その分布を使用して後続の推論ステップを駆動することを提案しました。

古典的なキャリブレーション済みモデルにフォールバックします。コメント投稿者のPaulHouleは、scikit-learnのキャリブレーションモジュールを指摘し、事前学習済みエンコーダー、プーリング、ドメインデータでトレーニングされた確率キャリブレーション済み分類器のパイプラインを説明しました。同じコメント投稿者は、キャリブレーションはデータ分布に依存することを強調しました：適用される事前分布とは異なる事前分布でトレーニングされたモデルは、キャリブレーションが不十分になります。コメント投稿者のricardobeatは、投稿の5段階手順が本質的に教師あり学習（データ、ラベリング、重み更新、キャリブレーション）であり、決定モデルがまさにこの目的のためにトレーニングされていると述べました。

制限と未解決の質問

コメント投稿者のvisargaは、根本的な制約を最も直接的に述べました：「キャリブレーションセットなしでモデルの信頼度をキャリブレーションすることはできません。信頼度はラベル付きデータセットに対して相対的であり、バケットまたは間隔のセットで確立され、人口ベースであり、単一の予測に対してチェックできるものではありません。」同じコメント投稿者は、モデルプロバイダーがまだ見たことのないタスクに対してモデルを事前キャリブレーションすることはできないと付け加えました。

コメント投稿者のhexapusは、議論を最も広い用語でフレーミングし、LLMを「推論できないが、推論がどのように見えるかを予測できる」次のトークン予測器として説明し、失敗したときはその理由について正直になる価値があると主張しました。

コメント投稿者のzug_zugは、LLMに観測を説明する結果のオッズを評価させる実験で、モデルが人間と同様の方法で体系的に偏っていることを報告し、ベイズ統計の基本は現時点ではLLMでは信頼できないと結論付けました。コメント投稿者のmadroxは、統計学のバックグラウンドから、応用統計学のトレーニングは時間の約10%をモデル構築に、90%を出力の解釈に費やし、機械学習のカリキュラムがそのバランスを維持しているかどうか疑問視しました。

投稿と議論からの実用的な最終結論は一貫しています：信頼度スコアは、スコアリングされている特定のタスクの結果の書面による記録に結び付けられている場合にのみ意味があります。そのスコアが明示的な統計ルール、キャリブレーション済み分類器、ファインチューニングされたモデル、または適切なスコアリングルールでトレーニングされたモデルによって生成されるかはエンジニアリングの選択です。しかし、それらのすべてのケースで、キャリブレーションの証拠はデータから得られ、モデルにどの程度確信しているかを尋ねることからは得られません。