効果的なLLM評価法 LangSmithの技術と実践 2024/06/29 第36回勉強会

自己紹介 ● 名前: 西岡 賢一郎 ○ Twitter: @ken_nishi ○ note: https://note.com/kenichiro ○ YouTube: 【経営xデータサイエンスx開発】西岡 賢一郎のチャンネル (https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg) ● 経歴 ○ 東京大学で位置予測アルゴリズムを研究し博士 (学術) を取得 ○ 東京大学の博士課程在学中にデータサイエンスをもとにしたサービスを提供する株式会社ト ライディアを設立 ○ トライディアを別のIT会社に売却し、CTOとして3年半務め、2021年10月末にCTOを退職 ○ CDPのスタートアップ (Sr. CSM)・株式会社データインフォームド (CEO)・株式会社ディース タッツ (CTO) ○ 自社 よび他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験

今日のお話 ● プレゼンの目的: ○ LangSmithの機能とその利点を紹介し、LLMの評価プロセスの改善を図る。 ● トピック ○ LLMの評価 ○ LangSmithを使った評価 + デモ

LLMの評価

LLMの主な評価方法 LLM（大規模言語モデル）アプリケーションを開発すると に 評価 必要となる背景 ● 品質保証 ○ 誤情報 (ハルシネーション) を防 、正確な応答を提供するため の評価 必要 ○ 特に重要な分野では信頼性の確保 不可欠 ● ユーザーエクスペリエンス ○ ユーザーの満足度を向上させるために応答の質を評価 ○ 対話の質 ユーザー体験に直結する ● モデル改善 ○ モデルの強みと弱みを把握し、次のアプリの改善に役立てる ○ 評価を通じて性能を向上させ、より良い結果を目指す LLMの現場で見られる3つの評価 1. ユーザのフィードバック 2. プロダクトチームのフィードバック 3. 期待する出力を使った評価

ユーザのフィードバック ● フィードバック収集 ○ 親指マークやコメントでの評価 ○ 簡便で直感的なインターフェース ● 応答の質の分析 ○ 高評価と低評価の応答を比較 ○ 改善点の特定 ● ユーザー満足度の向上 ○ フィードバックを基にアプリを改善 ○ 継続的なユーザーエクスペリエンスの 向上をめざす

プロダクトチームのフィードバック ● 手動のチェック ○ 開発中の応答を人力で確認 ○ モデルの精度と一貫性の評価 ● プロダクトログデータの活用 ○ 実際の使用データを分析 ○ ユーザーの行動パターンや傾向を把握 ● パフォーマンス指標のモニタリン グ ○ 応答速度やエラーレートの監視 ○ システムの信頼性と効率性の向上 ● ダッシュボードの作成 ○ リアルタイムのデータを可視化 ○ 評価結果の一元管理と迅速な対応。

期待する出力を使った評価 ● 特定のInputに対するOutputを準備 ○ 具体的なInputと期待されるOutputを設定 ○ 実際のLLMのOutputと比較して評価 ● 曖昧性の考慮 ○ LLMの生成するテキスト 必ず同じになる わけではない ○ 完全一致ではな 、意味的な一致も考慮す る ● InputとOutputの管理は課題となる ○ InputとOutputは追加・更新される可能性 ある ● 評価基準の設定 ○ 実際のOutputを評価するための基準の設 定 必要 ○ 一貫性、正確性、関連性の評価

LangSmithを使った評価

LangSmithの評価機能 LLMアプリケーション開発でよ 使われるLangChainのサー ビスである「LangSmith」は、LLMを楽に評価で る機能を 提供している。 ● Evaluatorの設定 ○ コードを書 ずにEvaluatorを設定し、データ セットに紐づけられる ● PlayGround ○ プログラムを書 ずにプロンプトやモデルの設 定をテスト ● 中間ステップの評価 ○ RAGパイプラインなどの中間ステップを詳細に 評価 ● 標準Evaluatorの利用: ○ カスタムコードを書 ことな 、標準の Evaluatorを使用 ● Annotationの利用 ○ 実行結果に注釈を追加し、詳細なフィードバッ クを提供

評価に使える2つの機能「Feedback」と「Evaluation」 ● 評価文脈で使える機能は、FeedbackとEvaluationの 2種類 ○ Feedback: ユーザやプロダクトチーム LLM の実行結果に対してAnnotate (注釈付け) ○ Evaluation: 期待する出力を使ってLLMの出 力を特定の基準をもとに評価 ● FeedbackはRun (LLMの実行等) を絞り込むのに使 い、実行のInputとOutputをDatasetに保存するこ とでEvaluationに利用すること で るようになる (Annotateした内容はDatasetには保存されない)

Feedback ● Traceされた実行の中に含まれるRunに、自分で定義 したTagやKeyをAnnotate ○ trace_id1つに対して複数のrun_id 含まれる 構造 ○ 最初のrun_idはtrace_idと同一 ● API経由のfeedbackではKey, 手動のfeedbackでは TagでAnnotateする仕組みとなっている 、Tagも Keyとして保存されている ● API経由のfeedbackはrecord 追加・上書 で る のに対して、手動のfeedbackは上書 のみという違 い ある ● 数値データで同じキーのものは集計されて表示され る ● LLMアプリを使っているユーザ らのフィードバッ クは、基本的にAPI経由の登録となる Runに対して定義したTagをAnnotateしてい

Evaluation ● Datasetにあら じめInputとOutputの組み合わせ らなるExampleを保存 ● ExampleのInputを使ってLLMを実行し、出て た Outputを保存されているOutputを使って評価 ● 評価にはLangSmith あら じめ用意している評価 や、カスタム評価を利用すること で る ● 評価結果は、key (評価指標の名前), score (評価結 果), commentとして残すこと 可能

LangSmith導入の課題 ● データの送信: ○ LangSmithにInput、Output、Prompt などを送ることとなる ○ 意図せずセキュアな情報を送らないよ うに実装時に注意 必要 ● コスト: ○ チームで使うと1ユーザあたり $39 (6000円強)/月で少し高め ● アプリとLangSmithの密結合: ○ ユーザ らのフィードバックを保存す る仕組みなどで、アプリとLangSmith 密結合してしまうこと ある

Appendix

自動Evaluatorの設定 ● 手順: ○ データセットで「Add Evaluator」ボタンを クリック ○ Evaluatorに名前を付け、使用するプロンプト を設定 ○ 評価基準をスキーマフィールドに指定 ○ Evaluatorを保存し、設定後の実験実行 自動 的に評価される ● 利点: 評価プロセス 簡素化され、一貫した評価基準 適用される

PlayGround ● 手順: ○ プロンプトプレイグラウンドでプロンプトを 選択または作成 ○ データセットに切り替えて実験を開始 ○ 結果を確認し、プロンプトを再調整して実験 を繰り返す ● 利点: 効率的にプロンプトやモデルの設定をテストで る

中間ステップの評価 ● 手順: ○ パイプラインを定義。 ○ データセットと評価例を作成。 ○ カスタム評価者を定義。 ○ パイプラインを評価。 ● 利点: 各ステップのパフォーマンスを最適化で る

標準Evaluatorの利用 ● 種類: ○ QA Evaluator（qa、context_qa、cot_qa） ○ 基準Evaluator（criteria） ○ ラベル付 基準Evaluator（labeled_criteria） ○ 文字列距離メトリックEvaluator（string_distance） ○ 埋め込み距離メトリックEvaluator（embedding_distance） ● 利点: 多様な評価基準をカバーし、迅速に評価で る

Annotationの利用 ● 手順: ○ 実行結果ページで「Add Annotation」ボタンをクリック。 ○ 注釈内容を入力して保存 ○ 注釈は実行結果ページで確認・編集可能 ● 利点: ○ 詳細なフィードバック: 各実行結果に具体的なフィードバックを追加。 ○ エラーの特定: 特定のエラーや問題点を明確化。 ○ チーム間の共有: チームメンバー間での情報共有 容易。

LangSmithの高度な評価機能 ● ペアワイズ評価の実行 ● 評価者スコアの監査 ● 実験のパフォーマンス指標の取得