公開日: 2024 年 10 月 30 日
大規模言語モデル(LLM)を使用して特徴を構築することは、従来のソフトウェア エンジニアリングとは大きく異なります。デベロッパーは、非確定的な結果、入力の前処理、結果の後処理を処理するために、プロンプト エンジニアリングを学習する必要があります。
お客様から寄せられた課題の 1 つは、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 2B と Gemma 2 2B によって作成された要約を評価しました。Google の具体的なアプローチは、DeepEval の要約指標の一部であるアライメントに基づいています。
アライメントは、要約に含まれるステートメントが、要約の基になる元のコンテンツでサポートされている頻度を測定する指標です。
評価プロセスは 2 つのステップに分かれています。まず、各要約を個別のステートメントに分割するようにモデルに指示しました。次に、各記述が元の記事のテキストによって裏付けられているかどうかを判断するようにモデルに指示しました。
要約からステートメントを抽出する
Gemini 1.5 Flash に、長いテキストを個別のステートメントに分割するよう指示しました。次に例を示します。
エヴァートンのディフェンダー、デビッド ウィアーは、リバプールを破ってプレミアリーグで 2 位に浮上したにもかかわらず、ヨーロッパのサッカーへの進出について語ることを控えた。
Gemini 1.5 Flash では、この文は次のステートメントに分割されます。
- 「デイビッド ウィアーはエヴァートンのディフェンダーです。」
- 「現在、エヴァートンはプレミアリーグで 2 位です。」
- 「エヴァートンが最近の試合でリバプールを破った。」
- 「デイビッド ウィアーは、エヴァートンがヨーロッパのサッカーでプレーすることについて、話し合いを最小限に抑えています。」
ステートメントを検証する
次に、分割されたステートメントと比較して、元の文を分析するよう Gemini 1.5 Flash に指示しました。モデルは、各ステートメントの有効性を次のように分類しました。
- はい: 元のテキストによってその記述が裏付けられています。
- いいえ。この記述は元のテキストと矛盾しています。
- Idk. 記述が裏付けられているか、元のテキストと矛盾しているかどうかを確認できません。
結果の分析
このプロセスの結果、モデルの比較に使用できる 2 つの指標が得られました。
- アライメント: モデルが、元のテキストでサポートされているステートメントを含む要約を生成した頻度。
- Richness: モデルによって生成された要約に含まれるステートメントの平均数。
配置
アライメントは、少なくとも 1 つのステートメントが「No」とマークされている要約の数を数え、その数を要約の合計数で割って算出しました。
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 で共有してください。