LLM評価プレイブックはどのように機能しますか? 私はリアルなリンクを貼って明確に説明しました

本物の審査プロセス

先週、カスタマーサービスのQ&A担当者向けに回帰分析テストを企画していました。最も厄介だったのは、各モデルの微調整後に、どの部分が改善し、どの部分が実際に悪化しているかをどうやって素早く見分けられるのか、ということでした。

従来のユニットテストは適していません。LLMの出力は自然言語であり、固定されたアサーティブ値を持ちません。いろいろなツールを調べた結果、最終的にLLM Evals Playbookというアイデアを選びました。これは単一のPDFではなく、実行可能な評価フレームワークです。コアプロセスは、評価基準の定義→テストデータセットの作成→評価を実行し、結果の分析と反復→することです。

以下は私が実行した最初の完全なリンクで、各ステップに対応するコードと設定ファイルが添えられています。

ステップ1:評価基準を定義する

評価はビジネスの観点から始めなければなりません。私のシナリオはカスタマーサービスのQ&Aなので、3つの次元を定義しました。

回答の正確性:答えが提供された知識ベースに基づいているのか、答えに基づいているのかは不確かです。
完全性:ユーザーの問題のすべてのサブイシューがカバーされているかどうか。
トーンコンプライアンス:友好的で責任を回避しないかどうか。

各次元は1から5のスケールで評価され、評価基準の説明が付けられています。プレイブックではこれらの基準が実行可能なものであることが求められます。例えば、「正確性」は単に「正確」ではなく、「回答のすべての情報はナレッジベースの原文で追跡可能でなければならない」と書かれるべきです。

ここで最も一般的な間違いは曖昧すぎる基準です。私の最初のバージョンは「答えは正確であるべき」と書かれていましたが、評価者によって与えられたスコアは大きく異なっていました。後に「回答にナレッジベースに記載されていないエンティティやデータが含まれている場合、2ポイント減点」に変更され、一貫性が向上しました。

ステップ2:テストデータセットの生成

Playbookはデータセットに3種類のサンプルを含めることを推奨しています:正規問題、エッジ問題(例:文脈欠如)、および対抗的問題(例:不適切な内容を生成する誘導モデル)。

自分のビジネスの実際のユーザーログを使って50問の普通質問を作成し、20問のエッジ質問と10問の対立質問を手動で作成しました。対立的な質問を作成する際は注意してください。インターネットから直接プロンプトインジェクションテンプレートをコピーしないでください。これらは実際のビジネスシナリオから逸脱してしまうことが多いです。

重要な失敗点:データセットは評価基準と整合していなければなりません。もしあなたの基準が「幻覚を持たない」と要求しているのに、データセット内のほとんどの質問が単純なクエリであり、モデルが根拠のない主張を作らないなら、評価結果は独自性に欠けます。正しい方法は、まず小規模なサンプルランを実行し、モデルが誤りにかかりやすい場所を確認し、それに応じてデータセットを補足することです。

ステップ3:運用評価

LangChainのEvaluatorフレームワークを使ってPlaybookに接続しました。各テストサンプルの評価プロセスは、まず評価対象エージェントが質問に答え、その後評価者LLM(GPT-4oなど)があらかじめ設定された基準に従って採点します。

得点には理由が伴わなければなりません。単なる得点だけではなりません。例えば、「精度4点:回答では価格が199元と書かれていましたが、知識ベースでは1999元、1点差し引いたものです。」完全性 5ポイント:価格、納期、アフターサービスの3つのサブ課題をカバーしています。これにより、後続解析時に正確な欠陥位置を特定することができます。

ステップ4:結果を分析し、反復する

評価が完了すると、私の出力はCSVテーブルとなり、各行には各次元のサンプル+スコア+推論が示されています。分析時に注目すべき重要なポイント:

一般的に低い評価を受ける次元:整合性平均が2.5程度の場合、モデルが頻繁に情報を見落としていることを示します。
どのサンプルスコアが大きく変動するか:評価者やサンプル間の違いがあり、しばしば不明確な基準を示しています。

最初のランの結果は、精度4.2、完全性3.0、トーン4.8でした。整合性が低い理由は、モデルがユーザーの明示的な質問にのみ答え、関連する情報を積極的に提供しないためです(例えば、「出荷はいつですか?」と尋ねた際、モデルは出荷時間だけは答えますが物流問い合わせ方法を明示しません)。そこで「ユーザーの問題が注文に関する場合は、物流を確認するために注文番号を積極的に追加してください」というプロンプトを追加しました。第2ラウンドのレビューでは完全性が4.5に向上しました。

失敗や誤解が起こりやすい分野

Playbookの最大の落とし穴は、データセットと標準の断絶です。多くの人はテンプレートに基づいていくつかの基準を作成し、HuggingFaceからランダムにデータセットを抽出してレビューを行います。結果は見た目は素晴らしいですが、実際にはビジネス上の問題を反映していません。正しいアプローチは、標準とデータセットは同じビジネスシナリオから作成されなければならず、まずは小規模な検証を行うべきだということです。

もう一つのよくある間違いは、レビューを一度きりの受け入れと扱うことです。 Playbookの価値は継続的な回帰にあります。モデルの更新や調整のたびに再実行され、「レビュー・>分析・>修正>・再評価」のサイクルが形成されます。一度だけ走ってそのままにしておくと、実質的にレビューはありません。

ノートパソコンの画面には、LLM Evals Playbookの移行チェックリスト(標準定義、データセット生成、評価実行、結果分析)が表示されます

今すぐ着陸したいなら、まず何をすべき?

特定のビジネスシナリオを選びます(カスタマーサービスのQ&A、コード生成、要約など)。すべての能力を網羅しようとしないでください。
**2〜3の実行可能な評価次元を定義し、それぞれの次元の推論基準を明確に示す。
10個の実サンプルを収集し手動で実行する:自分で基準を使ってスコアをつけ、基準が明確か、データセットが差別化されているかを確認します。この工程は1時間未満で終わります。
**手動実行の結果に基づいて基準を調整し、50〜100サンプルに拡大する。
**自動化フレームワーク(LangChain、DeepEvalなど)にアクセスしてループを開始する。

デスクノートに手書きの比較ノート:左欄に評価基準、右欄にモデルのパフォーマンス差が記録されています

次に体系的な学習を始める場所

より完全な評価システムを構築したい、または評価をエージェント工学に体系的に統合する方法を学びたい場合は、より体系的なオリジナル記事やAI上級プログラミングコースを読むことができます。