vectara/hallucination-leaderboard を要約タスクの採用判断に使う
Leaderboard Comparing LLM Performance at Producing Hallucinations when Summarizing Short Documents
ひと目でわかる
- これは何？
- LLM が短い文書を要約するときに事実と異なる内容をどれだけ混ぜるかを、Vectara の HHEM で採点して一覧にしたリポジトリ。モデル選定の一次資料として使える範囲と、そのまま信じてはいけない範囲を整理する。
- 誰に向いている？
- 要約パイプラインを組む前にモデルの候補を絞りたいチーム、とくに hallucination rate と answer rate の両方を見て「短くまとめるが嘘をつくモデル」を避けたい用途には向いている。逆に、長文の RAG、多言語、表や数値を含む文書、抽出型の質問応答を評価したい場合にはこのリーダーボードは直接の答えを与えない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 127 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このリポジトリが測っているのは要約時の事実逸脱だけである
対象は「短い文書を要約させる」という一つのタスクに絞られている。README には Public LLM leaderboard computed using Vectara's Hallucination Evaluation Model, also known as HHEM とあり、評価対象は LLM が要約を生成するときにどれだけ hallucination を混ぜるかである。質問応答やコード生成、長文の推論は測っていない。したがって、要約以外の用途でモデルを選ぶ根拠にはならない。
想定読者は、要約を製品や社内ツールに組み込もうとしている開発者と、その判断をレビューする立場の人間である。モデルの性能を網羅的に比べたい人ではなく、要約という一点に絞って候補を絞り込みたい人が対象になる。リーダーボードの表には Hallucination Rate だけでなく Factual Consistency Rate、Answer Rate、Average Summary Length (Words) が並ぶ。この四列が揃っていることが、単一スコアのランキングとの違いである。
HHEM が要約と原文の整合を採点し、リポジトリはその結果を表に固定する
仕組みは README の記述以上には公開されていない。分かるのは、Vectara の Hallucination Evaluation Model が要約の事実整合性を判定し、その結果をリポジトリが表として保持しているという構造である。データの流れとしては、評価用の短い文書と各 LLM が生成した要約の組が HHEM に入り、モデルごとに hallucination と判定された割合が集計される、という形になる。
表の列の関係は明示されている。Hallucination Rate が 1.8 % の行では Factual Consistency Rate が 98.2 %、10.9 % の行では 89.1 % で、両者は補数の関係にある。つまり実質的には同じ情報である。Answer Rate は別軸で、要約を返さなかった、あるいは判定不能だった割合を示すと読める。microsoft/Phi-4 は Hallucination Rate が 3.7 % と低い一方で Answer Rate が 80.7 %、snowflake/snowflake-arctic-instruct は 4.3 % で 62.7 % である。この二つは、要約を出さないことで hallucination を避けている可能性を否定できない。単独の数値ではなく Answer Rate と並べて読む必要がある。
リポジトリに実行コードはなく、更新は手作業の表編集である
Python が primary language として登録されているが、README から確認できる成果物は Markdown の表と画像である。<!-- LEADERBOARD_START --> というコメントで囲まれた区間に表が置かれ、Last updated on May 11, 2026 という日付が添えられている。つまりこのリポジトリは、評価パイプラインそのものではなく、評価結果の公開先として使われている。
自分で同じ評価を回したい場合、HHEM のモデルカードと評価スクリプトは別に入手する必要がある。このリポジトリを clone しても採点はできない。過去の版はブランチで残されており、README は hhem-1.0-final と hhem-2.3-old-dataset の二つを案内している。評価モデルやデータセットが変われば数値の意味も変わるため、古い記事や社内メモの数値を現在の表と直接比較すると誤読する。バージョンを揃えて参照する必要がある。
数値の読み方: 上位と下位の差はモデル規模と一致しない
表の先頭は antgroup/finix_s1_32b の 1.8 %、次いで openai/gpt-5.4-nano-2026-03-17 の 3.1 %、google/gemini-2.5-flash-lite の 3.3 % と続く。末尾側には xai-org/grok-4-1-fast-reasoning の 19.2 %、mistralai/ministral-3-14b-2512 の 19.4 % が並ぶ。同じ提供元でも上位と下位が混在しており、モデル名から hallucination の傾向を推測することはできない。
注意したいのは Average Summary Length (Words) の散らばりである。上位の meta-llama/Llama-3.3-70B-Instruct-Turbo は 64.6 語、下位側の openai/gpt-5.1-high-2025-11-13 は 254.4 語である。長く書くモデルは原文に触れる機会が増え、結果として判定に引っかかる箇所も増える。短くまとめるモデルは hallucination が少なく出やすい。この列を見ずに順位だけを比べると、要約の粒度が違うモデルを同条件で並べていると誤解する。要約の長さに要件があるなら、その語数帯の行だけを抜き出して比較したほうがよい。
このリーダーボードが答えを出さない領域
第一に、評価対象は短い文書の要約である。数十ページの契約書や長い議事録を扱うパイプラインの判断材料にはならない。第二に、言語は明示されていない。日本語文書の要約で同じ傾向が出るかは、この表からは分からない。第三に、分野も不明である。医療、法務、金融のように数値や固有名詞の正確さが重要な文書で、表と同じ順位になる保証はない。
もう一つの限界は、採点者が Vectara 自身のモデルである点だ。HHEM は Vectara が提供する評価モデルであり、その判定基準が公開されている範囲でしか解釈できない。判定の境界事例、たとえば原文にない言い換えを許容するのか、数値の丸めを誤りとするのかは README からは読み取れない。リーダーボードを社内の受け入れ基準としてそのまま使うと、HHEM の癖を自分の製品の品質基準として固定してしまう。自社の評価セットを別に持つべき理由はここにある。
代替手段との違い: 汎用ベンチマークと人手評価
一般的な LLM ベンチマークは、推論、数学、コード、指示追従などをまとめて点数化する。要約の事実整合性はその一部にすぎず、しかも自動採点が難しいため、多くのベンチマークでは周辺的な扱いになる。hallucination-leaderboard は対象を要約一本に絞り、Factual Consistency Rate と Answer Rate を分けて出す。汎用ベンチマークで上位のモデルがここでは下位に沈むことがあり、その差がこのリポジトリの存在理由である。
人手による評価と比べた場合、コストと再現性で勝るが、判定の根拠は見えない。人手なら「どの文が原文のどこに対応しないか」を記録できるが、この表は集計値しか出さない。自社の文書で失敗事例を集めたいなら、HHEM を回して個別の判定を保存するか、人手のサンプル調査を併用する必要がある。表は候補を絞るために使い、最終判断は自社データで行う、という役割分担が現実的である。
導入と更新のコスト、ライセンスの扱い
このリポジトリ自体を導入するコストは低い。Markdown と画像が中心で、依存関係を抱えたアプリケーションではない。Apache-2.0 で公開されているため、表や図を社内資料に引用する際の条件は比較的緩い。ただし Apache-2.0 が及ぶのはこのリポジトリの内容であり、HHEM のモデルや各 LLM の利用条件はそれぞれ別に確認する必要がある。ライセンスの解釈についてはここでは判断しない。
更新コストは読み手側に発生する。表は Last updated on May 11, 2026 のように日付付きで差し替えられ、過去版はブランチに退避される。社内の選定資料に数値を引用した場合、次回更新で順位が動くことを前提にしておく必要がある。引用時には日付と、どのブランチの表かを併記しておくと、後から差分を追える。リリースタグは取得できていないため、バージョン固定の手段はブランチ名に頼ることになる。
導入を判断するための確認順序
最初に確認するのは、自分の要約タスクの入力長が評価データセットの「短い文書」に収まるかである。収まらないなら、この表は参考程度にしかならない。次に Answer Rate を見る。Hallucination Rate が低くても Answer Rate が 60 % 台のモデルは、要約を返さない場面が多い。プロダクトで空応答を許容できるかで評価が変わる。
そのうえで Average Summary Length (Words) が自分の要件と近い行だけを抜き出し、候補を二、三個に絞る。絞ったモデルで自社の文書を数十件要約し、原文と突き合わせる。表の数値は候補選びの入口であり、採否の根拠ではない。日本語の文書を扱うなら、なおさら自前の確認が要る。このリポジトリは、その最初の絞り込みにかかる時間を短くするために使うものである。
編集部の結論
要約パイプラインを組む前にモデルの候補を絞りたいチーム、とくに hallucination rate と answer rate の両方を見て「短くまとめるが嘘をつくモデル」を避けたい用途には向いている。逆に、長文の RAG、多言語、表や数値を含む文書、抽出型の質問応答を評価したい場合にはこのリーダーボードは直接の答えを与えない。採用前に確認すべきは、自分の入力文書の長さと分野が評価データセットのそれに近いか、そして answer rate が低いモデルを候補から外したときに残る選択肢が自分のレイテンシ要件を満たすか、の二点である。
コミュニティノート