ペアワイズ選好
同じプロンプトへの2つの応答を、明文化した基準で比較します。モデルのバージョン比較には最も頑健な方法です。相対的な判断は、絶対的なスコアよりはるかに安定するからです。
- モデルのA/B比較
- 引き分けを明示的に記録
- 基準ごとの選好
- 位置バイアスを抑えた提示順
評価とヒューマンフィードバック
モデルが日本語で実際に出力するものに対する、構造化された人の判断。日本語ネイティブが明文化したルーブリックで採点し、一致率を計測し、判断の相違は文書で裁定します。
評価の質は、ルーブリックの質を超えません。日本語のできる二人が同じ応答に違う点をつけ、その理由を説明できないなら、出てくる数値は小数点を付けただけのノイズです。
自動指標やLLM-as-judgeは、傾向を追うには有用ですが、日本語で最も問題になる失敗に対しては信用できません。英語中心に学習した判定モデルは、場面に対して丁寧さの水準が誤っている応答も、拒否として読めないほどやわらかい拒否も、3ターン前に成立した関係と矛盾する敬語も、平気で合格にします。いずれも日本語のユーザーがすぐ気づき、指標はまったく気づかない誤りです。
ですから当社は、注意深いレビュアーがするのと同じやり方で評価し、そのレビューを再現可能にします。各スコアに実例を紐づけたアンカー付きルーブリック、採点開始前のキャリブレーション、サンプルに対するブラインドの二重採点、採点者の判断が分かれたときの文書による裁定。出てくるのは、根拠を説明できる数値と、それを生んだ推論です。
独立性も設計上の制約として扱います。あるプロジェクトの評価者は、そのプロジェクトの学習データを書いた人ではありません。自分が関わったガイドラインを自分で採点すると、甘くなりがちだからです。
要点
評価の種類
問いが違えば、道具も違います。多くのプログラムでは、同じモデルに対してこのうち2つか3つを実施します。
同じプロンプトへの2つの応答を、明文化した基準で比較します。モデルのバージョン比較には最も頑健な方法です。相対的な判断は、絶対的なスコアよりはるかに安定するからです。
正確さ、有用性、文体、書式、安全性といった名前のついた基準ごとの絶対評価。各スコアが何を意味するかを、アンカーとなる記述で定義します。
主張が事実かどうかと、それが与えられた文章に実際に裏づけられているかどうか。この二つは別の失敗であり、別々に採点します。
日本語話者が日本語で書く敵対的プロンプト。翻訳したプロンプトセットには決して含まれない、間接的で婉曲な言い回しも含みます。
お客様のドメイン向けに構築するホールドアウトの評価セット。どのモデルでも正解できる問題ではなく、差がつく問題として設計します。
日本語固有の論点
いずれも、英語で学習した判定モデルには見えず、日本語の読み手には一目でわかるものです。
文法的に正しく、内容も正確なのに、誤っている応答があります。同僚に対して使う文体で顧客に話しかけている場合です。日本語の丁寧さは文体の問題ではなく、正しさの軸です。
当社の対応 文体はルーブリックの独立した基準として名前を持ち、独自のアンカーを持ちます。正確さとは別に採点するので、内容は良いが文体が誤っている回答が、内容の陰に隠れることはありません。
日本語の断りは、そもそも間接的です。禁止された依頼に対して 難しいかもしれません と答えるモデルは、形の上では言葉を濁しただけですが、多くの評価設計はこれを拒否成功と採点してしまいます。
当社の対応 拒否は、日本語話者がそれを拒否として読むかどうかで採点します。実例を添えた尺度を用い、過剰拒否は成功ではなく、それ自体を一つの失敗として採点します。
会話の序盤で成立した関係は、以降のすべてのターンを縛ります。モデルは対話の途中でこれをリセットしがちで、日本語のユーザーには、アシスタントが誰と話しているかを忘れたように読めます。
当社の対応 マルチターンの項目は会話として採点し、各応答を単独で見るのではなく、ターンをまたいで見る一貫性の基準を設けます。
日本語の固有名詞には複数の正しい読みがあり、人名や地名の読みを間違えたモデルは、綴りの検査では見つからない事実誤認をしています。
当社の対応 エンティティと読みの誤りは事実性の独立した下位カテゴリとし、評価者の記憶ではなく日本語の情報源に照らして確認します。
プロセス
実施が終わっても残る納品物が、ルーブリックです。次回の評価を今回と比較できるようにするのは、これです。
お客様が気にしている品質上の懸念を、名前のついた基準に変えます。そのうえで、お客様自身のモデル出力から取った実例を使い、各スコアのアンカー記述を書きます。
重視する振る舞いを網羅するように、プロンプトをサンプリングまたは作成します。無作為抽出では決して現れない、稀なケースや敵対的なケースも含めます。
全評価者が同じキャリブレーションバッチを採点します。乖離を議論し、ルーブリックのアンカーを鋭くし、一致が安定してから本採点に入ります。
定めた割合の項目を、二人の評価者がブラインドで採点します。判断が分かれた項目はシニアレビュアーに回し、解決の理由を記録します。
スコア、一致率の統計、裁定ログ、そして繰り返し現れる失敗パターンの記述をお渡しします。順位表の1行だけではありません。
納品
すべてのスコアは、項目、評価者の役割、ルーブリックのバージョン、そして記述がある場合は根拠まで辿れます。
| 納品物 | 形式 | 内容 |
|---|---|---|
| 項目ごとのスコア | JSONLまたはCSV | 項目ID、基準ごとのスコア、根拠、評価者の役割、ルーブリックのバージョン |
| 一致率レポート | PDFまたはMarkdown | 基準ごとの評価者間一致率、裁定率、実施期間中のドリフト |
| 失敗分析 | PDFまたはMarkdown | 繰り返し現れるパターン、その実例、ガイドラインまたはデータの変更提案 |
| レッドチームの検出結果 | JSONL | プロンプト、応答、カテゴリ、深刻度、再現手順のメモ |
| ベンチマークセット | JSONLと採点ハーネス | 問題、参照解答、許容される言い換え、採点スクリプト |
品質
一致率の統計がない評価は、意見です。以下のチェックが、それを測定に変えます。
よくあるご質問
初めて日本語の評価を依頼される前に、よくいただくご質問。
LLM判定は安価で速く、リリース間の回帰追跡には有用です。ただし、日本語が難しい箇所そのもの、つまり丁寧さの適切さ、拒否の強さ、敬語の一貫性、名前の読みでは信用できません。これらの判断がネイティブの語用論的な知識に依存するからです。よくある組み合わせは、人手で採点したセットを基準とし、頻繁な実施はLLM判定に任せ、定期的に人手で採点し直して、判定モデルが基準からずれていないかを確認する形です。
どれくらいの差を検出したいか、いくつの基準で採点するかによります。よく選ばれた数百件があれば、明らかに違う2つのモデルはたいてい区別できます。ほぼ同等のチェックポイントを見分けるには、かなり多く必要です。当社は、お客様が下そうとしている判断に照らして件数を設計し、望む結論を支えるには小さすぎるセットであれば、そうお伝えします。
はい。法務、税務、会計、労務、商業登記といった題材については、タスクが必要とする専門性に合わせて評価チームを編成します。当社は有資格の専門家を常時登録した名簿を保有しておらず、対応可否は案件ごとに範囲・分量・スケジュールに照らして判断し、着手前にどこまで実現できるかをお伝えします。
お受けしますが、同じ人は使いません。あるプロジェクトの評価者は、そのプロジェクトの学習データを書いたアノテーターと分けます。自分が作成に関わったガイドラインに照らして採点するのは、独立した測定ではないからです。データを作成したベンダーの外で評価を行いたいというご判断も妥当だと考えており、その場合はそう申し上げます。
結果と、それを説明する失敗分析です。スコアしか載っていないレポートでは手が打てません。必要なのは、その背後で繰り返されているパターン、それぞれの実例、そして打ち手がデータの追加なのか、ガイドラインの変更なのか、プロダクト側の変更なのかについての具体的な見立てです。都合の悪い結果は、やわらげるよりも明確にお伝えします。
LLM評価
モデルの出力一式、または試したいプロンプトをお送りください。ルーブリックの案、それで採点したサンプル、そして本実施の内容をお返しします。
データをご共有いただく前にNDAを締結します。パイロットの要件定義は無料です。