uqlm: LLM の不確実性をスコア化する Python ライブラリの実装と限界
[JMLR 2026] "UQLM: A Python Package for Uncertainty Quantification in Large Language Models"
ひと目でわかる
- これは何？
- CVS Health が公開している uqlm は、LLM の出力に対する信頼度スコアを 0〜1 で返すスコアラ群を提供する。ブラックボックス系は追加の生成と比較を必要とし、ホワイトボックス系はトークン確率へのアクセスを要求する。導入前に確認すべきは、どのスコアラが自分のモデルと予算に収まるかである。
- 誰に向いている？
- 複数の生成を許容できる予算とレイテンシがあり、かつ任意の LLM を差し替えながら信頼度スコアを比較したいチームには、BlackBoxUQ から試す価値がある。逆に、1 回の推論で完結させたい用途や、トークン確率を返さない API しか使えない構成では、ホワイトボックス系は選択肢に入らない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
uqlm が埋めようとしている穴は何か
LLM を使ったアプリケーションでは、出力が正しいかどうかをモデル自身が教えてくれない。uqlm はこの穴に対して、応答レベルの信頼度スコアを 0〜1 の実数で返すという答えを出している。README の表現を借りれば、スコアが高いほど誤りやハルシネーションの可能性が低いことを意味する。対象読者は、RAG や要約、コード生成などのパイプラインに LLM を組み込み、出力をそのままユーザーに渡す前に何らかの選別を挟みたい開発者である。モデルの内部に手を入れずに使える手法と、トークン確率を要求する手法の両方を 1 つのパッケージにまとめている点が、単発の研究スクリプトとの違いになる。
5 種類のスコアラは何を犠牲にして何を得るか
README の表は、スコアラをブラックボックス、ホワイトボックス、LLM-as-a-Judge、アンサンブル、長文という 5 分類で並べ、それぞれに追加レイテンシ、追加コスト、互換性、導入の手間を示している。ブラックボックス系は同じプロンプトから複数の応答を生成し、その一貫性を測る。任意の LLM で動く代わりに、生成回数分のレイテンシとコストを払う。ホワイトボックス系はトークン確率を使うため追加の LLM 呼び出しは不要だが、確率を返さないモデルでは成立しない。LLM-as-a-Judge 系は判定役のモデルを呼ぶ。アンサンブル系はこれらを組み合わせるため、レイテンシもコストも構成次第で伸縮する。長文スコアラは主張レベルの比較を行うため、表の中では最も重い区分になっている。どの行も、精度を上げる方向に動かせば呼び出し回数が増えるという同じ構造をしている。
BlackBoxUQ のデータフロー
README のコード例では、langchain_openai の ChatOpenAI をモデルとして渡し、BlackBoxUQ に scorers=["semantic_negentropy"] と use_best=True を指定している。generate_and_score に prompts と num_responses=5 を渡すと、5 本の応答が生成され、意味的な一貫性に基づくスコアが付き、use_best=True によって不確実性が最小の応答が選ばれる。ここでの流れは、生成、比較、スコア算出、選択という 4 段階である。比較の段階で意味的なまとまりを判定するため、文字列一致では捉えられない言い換えを同一視できる。semantic_negentropy は Farquhar ら 2024 と Bouchard & Chauhan 2025 を出典として挙げられており、意味的エントロピーの変種として位置づけられている。返り値は to_df() で表形式に落とせるので、しきい値を決めてフィルタする処理を後段に置ける。
インストールと最小構成
導入は pip install uqlm の 1 行で、Python 3.10 以上が要求される。README の例に沿うなら、まず ChatOpenAI(model="gpt-4o-mini") のような LangChain のチャットモデルを用意し、それを BlackBoxUQ に渡す。scorers 引数には使いたいスコアラ名をリストで指定し、num_responses で生成本数を決める。use_best=True は緩和策であり、スコアを付けるだけでなく最も確からしい応答を選ぶ動作に切り替わる。ここで注意したいのは、モデル側の API キーやレート制限がそのままスコアラの実行回数に効いてくる点である。num_responses=5 は 1 プロンプトあたり 5 回の生成を意味するので、既存の呼び出し回数の見積もりをそのまま使うと足りない。
ホワイトボックス系が使えない場面
ホワイトボックス系スコアラはトークン確率を入力に取る。README の表でも互換性の欄が「limited」とされており、確率へのアクセスが前提であることが明示されている。したがって、確率を返さない API 経由でしかモデルを呼べない構成では、この分類は実質的に選択肢から外れる。表の脚注には、複数生成を行うホワイトボックス系はコストとレイテンシが高くなると書かれており、追加コストがゼロという説明がすべてのホワイトボックス系に当てはまるわけでもない。もう 1 つの制約は、スコアが校正されている保証は README からは読み取れないことである。0〜1 の値は相対的な比較には使えるが、0.8 なら 80% 正しいといった解釈をそのまま当てにするのは危うい。しきい値を業務に組み込むなら、自社データで分布を確認する作業が別途必要になる。
代替手段との分かれ目
同じ目的の道具として、モデルのトークン対数確率をそのまま読み、系列全体の確率を計算する素朴な実装がある。こちらは追加の生成も判定モデルも不要で、1 回の推論の副産物として確率が手に入るなら最も安い。違いは、uqlm が意味的な一貫性や判定モデルを介在させる点にある。言い換えを同一視できるかどうか、そして複数サンプルを平均できるかどうかが分岐点になる。逆に、応答が 1 本しかなく、確率も取れず、判定モデルを呼ぶ予算もないという条件では、uqlm のどの分類も成立しない。この場合はスコアリングを諦め、検索結果の引用をそのまま提示するといった別の設計に寄せるほうが現実的である。
保守とライセンスの確認点
ライセンスは Apache-2.0 で、リポジトリはアーカイブされておらず、直近のリリースは v0.6.6 である。0.x 系が続いているため、マイナー更新でスコアラの引数や既定値が変わる可能性は残る。依存の中心は LangChain のチャットモデル抽象であり、上流の破壊的変更がそのまま影響しうる。固定して使うなら、requirements などで uqlm のバージョンを明示し、更新時はスコア分布が変わっていないかを確認する運用になる。Apache-2.0 は特許条項を含む寛容なライセンスだが、これは法務判断ではなく事実の記載にとどめる。商用利用の可否や表記義務の解釈は、自組織の法務に確認する項目である。
編集部の結論
複数の生成を許容できる予算とレイテンシがあり、かつ任意の LLM を差し替えながら信頼度スコアを比較したいチームには、BlackBoxUQ から試す価値がある。逆に、1 回の推論で完結させたい用途や、トークン確率を返さない API しか使えない構成では、ホワイトボックス系は選択肢に入らない。導入前に確認すべきは、利用中の LangChain Chat Model がスコアラの前提を満たすか、そして num_responses を増やしたときの呼び出し回数が自社のコスト上限に収まるかである。
コミュニティノート