公開日: 2024 年 10 月 30 日
大規模言語モデル（LLM）を使用して特徴を構築することは、従来のソフトウェア エンジニアリングとは大きく異なります。デベロッパーは、非決定的な結果、入力の前処理、後処理の結果を処理するプロンプト エンジニアリングを学習する必要があります。
お客様から Google に共有された課題の一つは、LLM からの出力のテスト、有効性と品質の決定に時間がかかることです。デベロッパーは、多くの場合、さまざまな入力を使用して出力をバッチ生成し、人間の判断で手動で検証しています。
さまざまなモデルとプロンプトの結果を評価するためのよりスケーラブルなアプローチとして、LLM の手法があります。この手法では、人間の判断に依存するのではなく、モデルの検証を別の LLM に委任します。2 つ目の LLM は、より大きなクラウドベースの LLM である必要があります。この LLM は、推論能力が優れている可能性があります。
このドキュメントでは、要約を使用して、さまざまなモデルを比較する方法について説明します。また、参考として、Gemma から Gemma 2 にまで品質が向上したことも示します。
比較するモデルを選択し、データを準備する
要約に関する 3 つのモデルの能力を評価しました。クライアントサイドで実行できる Google の 2 つのオープンモデル（Gemma と Gemma 2）の結果を比較しました。どちらも 20 億個のパラメータサイズです。対照的に、より大規模で高性能なクラウドベースのモデルである Gemini 1.5 Flash も評価しました。
ビジネス、エンターテインメント、政治、スポーツ、テクノロジーなどの分野を網羅する 2,225 件の BBC 記事のデータセットを使用し、選択した各モデルを使用して各記事の要約を生成しました。すべてのモデルで同じプロンプトを使用しました。
記事を 1 つの段落に要約します。
元の記事と生成された要約をデータベースに保存し、各ステップで簡単にアクセスできるようにしました。
要約を分析して採点する審査員を指名する
要約の品質を分析するために、Gemini 1.5 Flash を使用して、Gemma 2 と Gemma 2 2B によって生成された要約を評価しました。Google の具体的なアプローチは、DeepEval の要約指標の一部であるアライメントに基づいています。
アライメントは、要約に含まれるステートメントが、要約の基になる元のコンテンツでサポートされている頻度を測定する指標です。
評価プロセスは 2 つのステップに分かれています。まず、各要約を個別のステートメントに分割するようにモデルに指示しました。次に、各記述が元の記事のテキストによって裏付けられているかどうかを判断するようにモデルに指示しました。
要約からステートメントを抽出する
Gemini 1.5 Flash に、長いテキストを個別のステートメントに分割するよう指示しました。例:
エヴァートンのディフェンダー、デビッド ウィアーは、リバプールを破ってプレミアリーグで 2 位に浮上したにもかかわらず、ヨーロッパのサッカーへの進出について語ることを控えた。
Gemini 1.5 Flash では、この文は次のステートメントに分割されます。
- 「デイビッド ウィアーはエヴァートンのディフェンダーです。」
- 「現在、エヴァートンはプレミアリーグで 2 位です。」
- 「エヴァートンが最近の試合でリバプールを破った。」
- 「デイビッド ウィアーは、エヴァートンがヨーロッパのサッカーでプレーすることについて、話し合いを最小限に抑えています。」
ステートメントを検証する
次に、分割した記述と比較して、Gemini 1.5 Flash に元の文を分析するよう依頼しました。モデルは、各ステートメントの有効性を次のように分類しました。
- はい: 元のテキストによってその記述が裏付けられています。
- いいえ。この記述は元のテキストと矛盾しています。
- Idk. 記述が裏付けられているかどうか、または元のテキストと矛盾しているかどうかを確認することはできません。
結果の分析
このプロセスの結果、モデルの比較に使用できる 2 つの指標がもたらされました。
- アライメント: モデルが、元のテキストでサポートされているステートメントを含む要約を生成した頻度。
- リッチネス: モデルによって生成された要約に含まれるステートメントの平均数。
配置
1 つ以上のステートメントが「いいえ」とマークされた要約の数をカウントし、要約の総数で割ることでアライメントを計算しました。
Gemini 1.5 Flash モデルのアライメント スコアは 92% を超えており、最も高いスコアです。つまり、事実に忠実であり、事実を捏造することを回避できます。
Gemma 2 2B は 78.64% という高いスコアで、優れた精度を示しています。一方、以前のバージョンの Gemma 2B はアライメント スコアが低く、元のテキストでサポートされていない情報が含まれる傾向があります。
豊かさ
各サマリーでモデルが生成したステートメントの数を平均して、モデルのリッチネスを算出しました。
Gemma 2 2B のリッチネス スコアは 9.1 と最も高く、要約にはより多くの詳細情報と要点が含まれていることがわかります。Gemini 1.5 Flash モデルの豊富さスコアも高く、8.4 を超えています。Gemma 2B はリッチネス スコアが低く、元のテキストから重要な情報を多く取得していない可能性があることを示しています。
まとめ
Gemma 2 2B など、クライアント側で実行できる小規模なモデルの方が高品質の出力を生成できることがわかりました。Gemini 1.5 Flash などのクラウドベースのモデルは、元の記事に沿った要約を生成して大量の情報を圧縮することに優れていますが、クライアントサイド AI を構築するかどうかを判断する際には、アプリケーションのパフォーマンス、プライバシーとセキュリティのニーズ、その他の質問とともに、その違いを検討する必要があります。
Gemma 2 2B は Gemma 2B よりも豊富で整合性の高い要約を生成できるため、Gemma モデル ファミリーの機能は明らかに進化しています。
ユースケースを評価する
このドキュメントでは、LLM を判定手法として使用できることのほんの一部について説明しました。要約しても、他の指標を調べると結果が異なる場合があります。たとえば、プロンプトを使用して記事の要点を特定し、別のプロンプトを使用して、それらの要点が各要約に含まれているかどうかを検証することで、カバレッジを評価できます。
テキストの作成、テキストの書き換え、検索拡張生成（RAG）などの他のユースケースでは、同じ指標で異なる結果が得られる場合があります。また、評価に他の指標を使用する必要があります。
このアプローチを実装する際は、人間が出力を評価してユースケースに最適な指標を判断する方法について考えてみましょう。DeepEval などの既存のフレームワークも検討してください。ユースケースに適した指標がすでに用意されている場合があります。
モデルを評価する判定者として LLM を実装していますか？検出結果を @ChromiumDev でツイートするか、LinkedIn のデベロッパー向け Chrome で共有してください。