LLMのライフサイクル（構築・拡張フェーズ）

はじめに

LLMのライフサイクルについてフェーズごとに投稿しており、今回は第二弾になります。

No	フェーズ	投稿予定日
1	アイデア化・探索フェーズ	投稿済み
2	構築・拡張フェーズ	今回の記事
3	運用フェーズ	3/20（水）

前回の記事でLLMのライフサイクルにおけるアイデア化・探索フェーズにおいて活用できるAzureのソリューションを紹介しました。まだチェックされていない方は以下も合わせてチェックしてみてください。

LLMのライフサイクル（再掲）

前回の記事を読んだ方は同じ内容になっているため2. 構築・拡張フェーズまで読み飛ばしてください。
Microsoft IgniteではLLMのライフサイクルを以下の3つのステージに分類して紹介しています。各ステージで得られたフィードバックは前のフェーズに提供され今後のプロジェクトで改善に利用することができます。本記事ではMicrosoftがフレームワークとして整理した内容に沿って検証した結果を共有します。

アイデア化・探索（Identing/exploring）
1.1 データソースの接続
1.2 AIチャットボットのテスト
1.3 LLMモデルの選択
構築・拡張（Building/augmenting）
2.1 プロンプトフローの構築
2.2 プロンプトフローの評価
2.3 プロンプトフローの修正
運用（Operationalizing）
3.1 プロンプトフローのデプロイ
3.2 監視

2. 構築・拡張フェーズ

本フェーズでは2.1 プロンプトフローの構築、2.2 プロンプトフローの評価、2.3 プロンプトフローの修正を目的の精度に達成するまでループすることでビジネス実現に必要な精度を持ったプロンプトフローを構築します。詳細は2.2 プロンプトフローの評価で説明しますが、”ユーザーの質問”と”ナレッジベースの情報”と”生成AIの回答”の関連性を評価することで、ビジネス実現に必要な精度で生成AIがユーザーの質問に適切に回答できる仕組みを構築します。

本フェーズでは主にAzure Machine Learning Prompt flowを活用します。Prompt flowを活用することでフローの作成・検証・修正をグラフィカルなインターフェース上で実行できる仕組みになっており、素早くプロセスを進めるためのテンプレートもユースケースやタスクに応じて種類が用意されているので効率的にLLMモデルを利用したバックエンドを開発可能です。Azure Machine Learning Prompt flowの詳細はMicrosoftドキュメントもご確認ください。

2.1 プロンプトフローの構築

プロトタイピングの画面でCustmize in prompt flowのボタンを押下することで、プロトタイピングで使用したプロンプトフローをテンプレートとした最初のフローを作成することができます。プレイグラウンドにて動作は確認しているため、LLMモデルやAzure AI Searchのコネクションをセットアップすることですぐに動作します。

2.2 プロンプトフローの評価

プロンプトフローの画面の右上にあるEvaluationのボタンから評価ジョブを作成します。プレビュー中の機能のためかバグで失敗したので、(1)評価ジョブの作成、(2)ログ確認・修正実行の流れでご紹介します。

(1)評価ジョブの作成

評価したい評価項目を選択することができます。ビルトイン評価を選択した場合以下の3つの評価項目が選択されます。

• Select the metrics（評価項目の選択）
  • Groundedness Evaluation
    • 生成AIの回答がどれだけナレッジベースの情報に沿って生成されているかを評価します
  • Relevance Evaluation
    • 生成AIの回答がユーザーの質問に対してどれだけ関連性があるか評価します
  • Retrieval score
    • ユーザーの質問に対する検索した情報の質と関連性を評価します
• Connection（評価に使用するLLM）
  • 評価に使用するLLM（以下の画面ではgpt-35-turbo）を選択します

QAセットの選択とデータセットの紐づけを行い、評価ジョブを実行します。

• QAセットの選択（Choose dataset）
  • 画面から見切れいますが、QAセットをアップロードします。MicrosoftのサンプルQAセットを使用しています。
• データセットの紐づけ（Dataset mapping）
  • プロンプトフロー
    • プロンプトフローのインプット情報"chat_history"、"query"をデータセットの"chat_history"、"question"列に紐づけます
  • 評価
    • 評価に使用する"answer"、"context"、"question"を順に”生成AIの回答”、”生成AIの回答に使用したデータ”、QAセットの"question"に紐づけます

(2)ログ確認・修正実行

実行したジョブのログは以下のように確認することができます。プレビュー中の機能のせいか、FlowConnectionNotFoundで失敗しました。(1)評価ジョブの作成の通り自分で作成したgpt(gpt-35-turbo)のConnectionを使用するように設定しているはずが、既定のDefault_AzureOpenAIのConnectionを使用して構成されてしまうようです。

実行したジョブの画面から評価に使用したフローを確認し、ダウンロードすることもできます。480行目を確認すると、確かにDefault_AzureOpenAIになっていますし、470行目を見るとGPT-4-Prodになっています。筆者の環境ではGPT-4は構築しておらず、同じような環境ではデフォルトのコネクションが見つけられず失敗する可能性があります。この画面では修正できないため、このフローをDownload codeボタンからダウンロードし、修正します。

以下の画面のようにプロンプトフローはローカルファイルからアップロードして編集することができるため、こちらの機能を使います。

プロンプトフローの編集画面から以下の画像のようにConnectionを自身で事前構成したものに変更することで正しく動作するようになります。（評価フローにはGPT-4またはGPT-35-turbo-16kモデルが必要です。）

修正したフローを実行すると以下のような結果を確認することができます。以下は”Groundedness”、”Relevance”、”Retrieval score”がそれぞれ5段階で評価された結果です。各評価手法・評価尺度についての詳細な説明はMicrosoftのドキュメントでも説明されていますのでご確認ください。Groundedness（4.83）はよいが、Relevance（3.00）とRetrieval score（2.50）は課題があることがわかります。言い換えると、生成AIの回答はナレッジベースの情報に沿ったものになっているが、ユーザーの質問に対する回答の関連性とユーザーの質問に対する検索性能に課題があります。実際にアプリを構築する際にはこの値をいくつになるまで改善を目指すかの目標値を予め設定しておくことが重要です。私が調べた限りでは現時点でMicrosoftの推奨値のようなものはなく、ビジネスの要件に応じて設定する必要がありそうです。

以下の画面だと見切れていますが、QAセットの各質問に対する生成AIの回答と評価スコアの詳細も確認することができます。以下にうまくいっていないケースの例を抜粋します。QAセットでは顧客データを基にした回答が期待されていたのですが、今回実装した外部ソースは製品情報しか入力していなかったため、顧客情報の欠如により期待した品質が得られていないことがわかりました。そこで今回は情報ソースを拡張することでプロンプトフローの質の向上を図ります。

• Relevance=1のケースの例
  • 質問：Melissa Davisの電話番号は何か？
    • 生成AIによる回答：質問に対する回答が見つけられませんでした
• Retrieval score₌1のケースの例
  • 質問：Amanda Perezが購入したものは何ですか？
    • 生成AIによる回答：Amanda Perezが購入したものについて回答が見つけられませんでした

2.3 プロンプトフローの修正

顧客情報に関連した質問にも対応するためプロンプトフローの編集画面から修正を行っていきます。顧客データをAzure Blob Storageにアップロードし、Azure AI Searchで検索インデックスを作成します。Azure AI Searchの画面やプレイグラウンドからAdd your data機能を活用することでGUIから実施することができます。

顧客データ追加のためのフローの修正はMicrosoftのドキュメントでも紹介されているので詳細はドキュメントをご確認ください。流れとしては(1)既存の製品情報収集のためのコードのコピーを生成、インプット情報を顧客情報のインデックスに変更する、(2)ナレッジベースから取得した情報をフォーマットするコードのインプットが製品情報と顧客情報の両方に対応するように変更する、になります。

修正したプロンプトフローを用いて再度評価を実施、製品情報のみをナレッジベースとした場合（左）と製品情報と顧客情報をナレッジベースとした場合（右）の比較結果が以下のように得られました。

Relevance（2.50 → 3.42）とRetrieval score（3.00 → 5.00）が向上したことがわかります。顧客情報を追加したことにより、ユーザーの質問に関連のある回答がより生成できるようになり、検索結果の質も向上しました。今回はナレッジベースの拡張という単純な例ですが、”プロンプトを変更する”、”検索手法を変更する”、”検索データを変更する”、”モデルを変更する”など複数の方法でプロンプトフローの品質を向上を目指すことができます。

まとめ

本記事ではLLMのライフサイクルにおける構築・拡張フェーズについて活用できるAzureのソリューションを紹介しました。本フェーズで私の感じたポイントは以下です。

• プロンプトフローの改善には経験が求められる
  • Microsoftが用意するツールによってプロンプトフローの評価を行うことができますが、どのように修正すべきかの推奨事項は提示されないため、改善方法は開発者に委ねられます。改善の指針は”プロンプトを変更する”、”検索手法を変更する”、”検索データを変更する”、”モデルを変更する”など多岐に渡り専門的な知見が必要かと感じました。
• 評価に使用するLLMモデルの性能による違い
  • 本フェーズにおいてLLMモデルは、(1)プロンプトフローの実行と(2)評価フローの実行の2通りの使われ方をしています。今回ご紹介している図ではGPT-3.5モデルを使用して評価を行っており、GPT-4や他のモデルを使用した評価については検証できておりません。ただ評価にもGPT-4モデルで実施することで評価の正確性が向上することは十分考えられるので、評価に関しては最初から性能の良いモデルを使用した方がよいと思われます。途中で評価に使用するLLMモデルを変更すると評価の基準がずれるため推奨されません。