評価とヒューマンフィードバック

日本語LLMの評価とヒューマンフィードバック

モデルが日本語で実際に出力するものに対する、構造化された人の判断。日本語ネイティブが明文化したルーブリックで採点し、一致率を計測し、判断の相違は文書で裁定します。

評価の質は、ルーブリックの質を超えません。日本語のできる二人が同じ応答に違う点をつけ、その理由を説明できないなら、出てくる数値は小数点を付けただけのノイズです。

日本語の評価に、日本語の評価者が要る理由

自動指標やLLM-as-judgeは、傾向を追うには有用ですが、日本語で最も問題になる失敗に対しては信用できません。英語中心に学習した判定モデルは、場面に対して丁寧さの水準が誤っている応答も、拒否として読めないほどやわらかい拒否も、3ターン前に成立した関係と矛盾する敬語も、平気で合格にします。いずれも日本語のユーザーがすぐ気づき、指標はまったく気づかない誤りです。

ですから当社は、注意深いレビュアーがするのと同じやり方で評価し、そのレビューを再現可能にします。各スコアに実例を紐づけたアンカー付きルーブリック、採点開始前のキャリブレーション、サンプルに対するブラインドの二重採点、採点者の判断が分かれたときの文書による裁定。出てくるのは、根拠を説明できる数値と、それを生んだ推論です。

独立性も設計上の制約として扱います。あるプロジェクトの評価者は、そのプロジェクトの学習データを書いた人ではありません。自分が関わったガイドラインを自分で採点すると、甘くなりがちだからです。

要点

評価の種類
ペアワイズ選好、ルーブリック採点、事実性とグラウンディング、安全性とレッドチーミング、ベンチマークの構築。
採点者
日本国内の日本語ネイティブ。題材が必要とする場合はドメイン専門家。
報告に含むもの
評価者間一致率、裁定率、基準ごとの内訳、採点メモの全文。
独立性
評価者は、お客様の学習データを書いたアノテーターとは別の人です。
再現性
ルーブリックはバージョン管理するため、後日の実施でも前回と比較できます。

評価の種類

評価する対象

問いが違えば、道具も違います。多くのプログラムでは、同じモデルに対してこのうち2つか3つを実施します。

ペアワイズ選好

同じプロンプトへの2つの応答を、明文化した基準で比較します。モデルのバージョン比較には最も頑健な方法です。相対的な判断は、絶対的なスコアよりはるかに安定するからです。

  • モデルのA/B比較
  • 引き分けを明示的に記録
  • 基準ごとの選好
  • 位置バイアスを抑えた提示順

ルーブリック採点

正確さ、有用性、文体、書式、安全性といった名前のついた基準ごとの絶対評価。各スコアが何を意味するかを、アンカーとなる記述で定義します。

  • アンカー付きの順序尺度
  • 一つに丸めない、基準ごとのスコア
  • 低評価には根拠の記述を必須化
  • 実施ごとにバージョン管理されたルーブリック

事実性とグラウンディング

主張が事実かどうかと、それが与えられた文章に実際に裏づけられているかどうか。この二つは別の失敗であり、別々に採点します。

  • 主張単位の検証
  • 引用箇所の照合
  • 裏づけのない主張の検出
  • 日本語の情報源による確認

安全性とレッドチーミング

日本語話者が日本語で書く敵対的プロンプト。翻訳したプロンプトセットには決して含まれない、間接的で婉曲な言い回しも含みます。

  • カテゴリ別の攻撃セット
  • 過剰拒否の検査
  • 日本固有の社会的・法的リスク
  • 深刻度を付与した検出結果

ベンチマークの構築

お客様のドメイン向けに構築するホールドアウトの評価セット。どのモデルでも正解できる問題ではなく、差がつく問題として設計します。

  • 難易度を均衡させた問題プール
  • 汚染に配慮した出典選定
  • 許容される言い換えを含む参照解答
  • 再利用できる採点ハーネス

日本語固有の論点

日本語話者以外の評価が見落とすもの

いずれも、英語で学習した判定モデルには見えず、日本語の読み手には一目でわかるものです。

敬語の適切さ

文法的に正しく、内容も正確なのに、誤っている応答があります。同僚に対して使う文体で顧客に話しかけている場合です。日本語の丁寧さは文体の問題ではなく、正しさの軸です。

当社の対応 文体はルーブリックの独立した基準として名前を持ち、独自のアンカーを持ちます。正確さとは別に採点するので、内容は良いが文体が誤っている回答が、内容の陰に隠れることはありません。

拒否の強さ

日本語の断りは、そもそも間接的です。禁止された依頼に対して 難しいかもしれません と答えるモデルは、形の上では言葉を濁しただけですが、多くの評価設計はこれを拒否成功と採点してしまいます。

当社の対応 拒否は、日本語話者がそれを拒否として読むかどうかで採点します。実例を添えた尺度を用い、過剰拒否は成功ではなく、それ自体を一つの失敗として採点します。

ターンをまたぐ一貫性

会話の序盤で成立した関係は、以降のすべてのターンを縛ります。モデルは対話の途中でこれをリセットしがちで、日本語のユーザーには、アシスタントが誰と話しているかを忘れたように読めます。

当社の対応 マルチターンの項目は会話として採点し、各応答を単独で見るのではなく、ターンをまたいで見る一貫性の基準を設けます。

固有名詞と読み

日本語の固有名詞には複数の正しい読みがあり、人名や地名の読みを間違えたモデルは、綴りの検査では見つからない事実誤認をしています。

当社の対応 エンティティと読みの誤りは事実性の独立した下位カテゴリとし、評価者の記憶ではなく日本語の情報源に照らして確認します。

プロセス

評価の進め方

実施が終わっても残る納品物が、ルーブリックです。次回の評価を今回と比較できるようにするのは、これです。

  1. 01

    「良い」の定義を決める

    お客様が気にしている品質上の懸念を、名前のついた基準に変えます。そのうえで、お客様自身のモデル出力から取った実例を使い、各スコアのアンカー記述を書きます。

  2. 02

    問題セットをつくる

    重視する振る舞いを網羅するように、プロンプトをサンプリングまたは作成します。無作為抽出では決して現れない、稀なケースや敵対的なケースも含めます。

  3. 03

    採点者のキャリブレーション

    全評価者が同じキャリブレーションバッチを採点します。乖離を議論し、ルーブリックのアンカーを鋭くし、一致が安定してから本採点に入ります。

  4. 04

    採点、二重採点、裁定

    定めた割合の項目を、二人の評価者がブラインドで採点します。判断が分かれた項目はシニアレビュアーに回し、解決の理由を記録します。

  5. 05

    推論とともに報告する

    スコア、一致率の統計、裁定ログ、そして繰り返し現れる失敗パターンの記述をお渡しします。順位表の1行だけではありません。

納品

納品されるもの

すべてのスコアは、項目、評価者の役割、ルーブリックのバージョン、そして記述がある場合は根拠まで辿れます。

標準的な評価の納品物。採点ハーネスの形式は、お客様の環境がある場合はそれに合わせます。
納品物形式内容
項目ごとのスコアJSONLまたはCSV項目ID、基準ごとのスコア、根拠、評価者の役割、ルーブリックのバージョン
一致率レポートPDFまたはMarkdown基準ごとの評価者間一致率、裁定率、実施期間中のドリフト
失敗分析PDFまたはMarkdown繰り返し現れるパターン、その実例、ガイドラインまたはデータの変更提案
レッドチームの検出結果JSONLプロンプト、応答、カテゴリ、深刻度、再現手順のメモ
ベンチマークセットJSONLと採点ハーネス問題、参照解答、許容される言い換え、採点スクリプト

品質

この業務に固有の品質管理

一致率の統計がない評価は、意見です。以下のチェックが、それを測定に変えます。

  • 採点前のキャリブレーション。ルーブリックを変更するたびに実施する。
  • 定めたサンプルに対するブラインドの二重採点。一致率は丸めずに基準ごとに報告する。
  • すべての判断の相違に対する文書での裁定。結果とともにログとしてお渡しする。
  • ペアワイズ比較では応答の提示順をランダム化し、位置バイアスを抑える。
  • 同じプロジェクトの学習データを作成したチームとは、評価者を分ける。
  • ルーブリックのバージョン管理。数か月後に再実施しても、前回と同じものを測る。

よくあるご質問

LLM評価について

初めて日本語の評価を依頼される前に、よくいただくご質問。

LLM判定は安価で速く、リリース間の回帰追跡には有用です。ただし、日本語が難しい箇所そのもの、つまり丁寧さの適切さ、拒否の強さ、敬語の一貫性、名前の読みでは信用できません。これらの判断がネイティブの語用論的な知識に依存するからです。よくある組み合わせは、人手で採点したセットを基準とし、頻繁な実施はLLM判定に任せ、定期的に人手で採点し直して、判定モデルが基準からずれていないかを確認する形です。

どれくらいの差を検出したいか、いくつの基準で採点するかによります。よく選ばれた数百件があれば、明らかに違う2つのモデルはたいてい区別できます。ほぼ同等のチェックポイントを見分けるには、かなり多く必要です。当社は、お客様が下そうとしている判断に照らして件数を設計し、望む結論を支えるには小さすぎるセットであれば、そうお伝えします。

はい。法務、税務、会計、労務、商業登記といった題材については、タスクが必要とする専門性に合わせて評価チームを編成します。当社は有資格の専門家を常時登録した名簿を保有しておらず、対応可否は案件ごとに範囲・分量・スケジュールに照らして判断し、着手前にどこまで実現できるかをお伝えします。

お受けしますが、同じ人は使いません。あるプロジェクトの評価者は、そのプロジェクトの学習データを書いたアノテーターと分けます。自分が作成に関わったガイドラインに照らして採点するのは、独立した測定ではないからです。データを作成したベンダーの外で評価を行いたいというご判断も妥当だと考えており、その場合はそう申し上げます。

結果と、それを説明する失敗分析です。スコアしか載っていないレポートでは手が打てません。必要なのは、その背後で繰り返されているパターン、それぞれの実例、そして打ち手がデータの追加なのか、ガイドラインの変更なのか、プロダクト側の変更なのかについての具体的な見立てです。都合の悪い結果は、やわらげるよりも明確にお伝えします。

LLM評価

モデルが日本語で何を間違えているかを、確かめてください。

モデルの出力一式、または試したいプロンプトをお送りください。ルーブリックの案、それで採点したサンプル、そして本実施の内容をお返しします。

データをご共有いただく前にNDAを締結します。パイロットの要件定義は無料です。