Skip to content

生成テキストの人手評価

LLM や NLG の出力について擁護可能な人手評価を実施する方法：基準を精密に定義し、絶対評価とペア比較のどちらかを選び、研究に十分な検出力を持たせ、再現できるだけの詳細を報告する。

BLEU や ROUGE のような自動指標は、生成テキストが実際にどれだけ良いかとの相関が弱いため、人手評価は依然として標準であり、そしてその実施はうまくいっている場合よりも不十分な場合のほうが多い。信頼できる人手評価を見せかけだけのものと分けるのは、次の三つだ。各基準を精密に定義すること、絶対スコアより相対的な判断を優先すること、そして他の誰かが再実行できるだけの詳細を報告すること。 本ガイドはプロトコルであって、評価基準の文言そのものではない。

なぜ人手評価か、そしてなぜ信頼しにくいのか

自由生成、要約、対話、翻訳、LLM の応答では、自動指標は参照テキストと比較し、重要なことの大半を見逃す。参照と異なる言い回しで表現された流暢で忠実な回答は低いスコアになり、流暢な嘘は高いスコアになる。だから人間の判断が依然としてグラウンドトゥルースであり続ける。落とし穴は、人手評価そのものが測定器具であり、設計の悪いものは、それが置き換えた指標と同じくらいノイズの多い数値を生み出すことだ。

問題の規模は文書化されている。Howcroft et al. (2020) は NLG 評価の二十年を調査し、この分野が自分たちの基準が何を意味するのかについてすら合意できていないことを見出した。「流暢性」「妥当性」「自然さ」といった用語は論文ごとに異なって定義されている（あるいはまったく定義されていない）ため、結果を比較することが不可能になっていた。彼らの処方箋は、真剣な評価すべての出発点である。判断を一つも集める前に、各基準が何を意味するのかを正確に定めよ。

基準を精密に定義する

曖昧な基準こそ、ほとんどの人手評価が破綻する場所だ。「品質を 1 から 5 で評価してください」は、各アノテーターが各自の品質の定義を勝手に作り出すことを招く。それを、名前を付けて別々に定義した次元へと分割し、それぞれに一文の操作的定義を書け。

  • 流暢性：内容が正しいかどうかは無視して、テキストは文法的で整った形をしているか？
  • 一貫性：文が全体として筋の通った形で続いているか？
  • 忠実性 / 事実的正確さ：すべての主張がソースに裏付けられているか（要約/RAG の場合）、あるいは真実か（自由生成の場合）？ここでハルシネーションが捕捉される。
  • 関連性：実際にプロンプトに応えているか？
  • 有用性：アシスタント型のタスクでは、ユーザーが望んだことを達成しているか？

これらを別々に測定することで、ある系統が別の系統に勝ったという事実だけでなく、なぜ勝ったのかが分かる。

絶対スコアか相対比較か

最大の設計上の選択は、アノテーターが一度に一つの出力を評価するのか、それとも複数を比較するのかだ。

  • **絶対評価（リッカート）**は単純だが、スケールバイアスを抱える。アノテーターごとに基準の置き方が異なり、両端を避け、セッションの途中で基準がずれていくため、ある評価者の「4」は別の評価者の「4」ではない。
  • ペアワイズの選好（A と B のどちらが良いか？）はスケールバイアスを完全に回避し、一般により信頼できる。だからこそ RLHF の選好データやモデル比較を支えている。その代償は、絶対的な水準ではなく順位が得られることだ。
  • **ベスト・ワースト・スケーリング**は小さなセットを提示し、最良と最悪だけを尋ねる。少ない判断から信頼できる順位を得る安価な方法だ。

van der Lee et al. (2021) は、まさにこうした選択を網羅したベストプラクティスのガイドラインを示している。項目数と評価者数、どの尺度、どの統計分析、を扱っており、設計を確定させる前に読む価値がある。

検出力を持たせ、報告する

設計が正しくなってもなお、二つの失敗様式が残る。

第一に、検出力不足の比較だ。二つの良い系統の間の小さな品質差を検出するには、人々が思うより多くの項目が必要だ。まず検出力分析を実施し、適切な有意性検定を用い、どの平均が高かったかだけでなく効果量を報告せよ。

第二に、報告されない詳細だ。Belz et al. (2021) は NLP における再現性を調査し、人手評価がとりわけ再現しにくいことを見出した。たいていは論文が、正確な基準、指示、アノテーターのプール、分析を省いているためだ。それらすべてを、後付けではなく研究の一部として記録せよ。

避けられるバイアスを防ぐいくつかの仕組み。出力の順序をランダム化することで位置が漏れないようにし（人は最初の選択肢を好む）、系統の正体を伏せることでどのモデルが何を生成したのかをアノテーターが分からないようにし、小さなバッチで試行することで一致度を測り、規模を拡大する前に紛らわしい基準を修正せよ。

Potato での実施

Potato には評価スタイルごとにスキームがあるため、上記の設計上の選択がそのまま設定へと対応する。基準ごとの絶対評価には次のようにする。

yaml
annotation_schemes:
  - name: faithfulness
    annotation_type: likert
    description: "Is every claim in the response supported by the source? 1 = many unsupported, 5 = fully supported."
    size: 5
  - name: fluency
    annotation_type: likert
    description: "Is the response grammatical and well-formed?"
    size: 5

ブラインドの A/B 比較には、pairwise スキームを用い、どの系統を A として表示するかをランダム化する。

yaml
annotation_schemes:
  - name: preference
    annotation_type: pairwise
    description: "Which response is more helpful overall?"
    labels: ["A is better", "Tie", "B is better"]

一度のパスで構造化された多基準のスコアリングを行うには、rubric_eval スキームが評価基準の各次元ごとにスコアを収集する。どれを選ぶにせよ、一致度を報告できるように共有サブセットで重複を保ち、有意性検定が必要とする分散を確保できるようエクスポートにアノテーターごとのラベルを残せ。

さらに読む