Upgrade to Pro — share decks privately, control downloads, hide ads and more …

効果的なLLM評価法 LangSmithの技術と実践

効果的なLLM評価法 LangSmithの技術と実践

機械学習の社会実装勉強会第36回 (https://machine-learning-workshop.connpass.com/event/322856/) の発表資料です。
デモ用のスクリプトはこちら: https://github.com/knishioka/machine-learning-workshop/blob/main/langchain/langsmith_evaluation.ipynb

More Decks by 西岡 賢一郎 (Kenichiro Nishioka)

Other Decks in Technology

Transcript

  1. 自己紹介 • 名前: 西岡 賢一郎 ◦ 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) ◦ 自社 よび他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験
  2. LLMの主な評価方法 LLM(大規模言語モデル)アプリケーションを開発すると に 評価 必要となる背景 • 品質保証 ◦ 誤情報 (ハルシネーション)

    を防 、正確な応答を提供するため の評価 必要 ◦ 特に重要な分野では信頼性の確保 不可欠 • ユーザーエクスペリエンス ◦ ユーザーの満足度を向上させるために応答の質を評価 ◦ 対話の質 ユーザー体験に直結する • モデル改善 ◦ モデルの強みと弱みを把握し、次のアプリの改善に役立てる ◦ 評価を通じて性能を向上させ、より良い結果を目指す LLMの現場で見られる3つの評価 1. ユーザのフィードバック 2. プロダクトチームのフィードバック 3. 期待する出力を使った評価
  3. ユーザのフィードバック • フィードバック収集 ◦ 親指マークやコメントでの評価 ◦ 簡便で直感的なインターフェース • 応答の質の分析 ◦

    高評価と低評価の応答を比較 ◦ 改善点の特定 • ユーザー満足度の向上 ◦ フィードバックを基にアプリを改善 ◦ 継続的なユーザーエクスペリエンスの 向上をめざす
  4. プロダクトチームのフィードバック • 手動のチェック ◦ 開発中の応答を人力で確認 ◦ モデルの精度と一貫性の評価 • プロダクトログデータの活用 ◦

    実際の使用データを分析 ◦ ユーザーの行動パターンや傾向を把握 • パフォーマンス指標のモニタリン グ ◦ 応答速度やエラーレートの監視 ◦ システムの信頼性と効率性の向上 • ダッシュボードの作成 ◦ リアルタイムのデータを可視化 ◦ 評価結果の一元管理と迅速な対応。
  5. 期待する出力を使った評価 • 特定のInputに対するOutputを準備 ◦ 具体的なInputと期待されるOutputを設定 ◦ 実際のLLMのOutputと比較して評価 • 曖昧性の考慮 ◦

    LLMの生成するテキスト 必ず同じになる わけではない ◦ 完全一致ではな 、意味的な一致も考慮す る • InputとOutputの管理は課題となる ◦ InputとOutputは追加・更新される可能性 ある • 評価基準の設定 ◦ 実際のOutputを評価するための基準の設 定 必要 ◦ 一貫性、正確性、関連性の評価
  6. LangSmithの評価機能 LLMアプリケーション開発でよ 使われるLangChainのサー ビスである「LangSmith」は、LLMを楽に評価で る機能を 提供している。 • Evaluatorの設定 ◦ コードを書

    ずにEvaluatorを設定し、データ セットに紐づけられる • PlayGround ◦ プログラムを書 ずにプロンプトやモデルの設 定をテスト • 中間ステップの評価 ◦ RAGパイプラインなどの中間ステップを詳細に 評価 • 標準Evaluatorの利用: ◦ カスタムコードを書 ことな 、標準の Evaluatorを使用 • Annotationの利用 ◦ 実行結果に注釈を追加し、詳細なフィードバッ クを提供
  7. 評価に使える2つの機能「Feedback」と「Evaluation」 • 評価文脈で使える機能は、FeedbackとEvaluationの 2種類 ◦ Feedback: ユーザやプロダクトチーム LLM の実行結果に対してAnnotate (注釈付け)

    ◦ Evaluation: 期待する出力を使ってLLMの出 力を特定の基準をもとに評価 • FeedbackはRun (LLMの実行等) を絞り込むのに使 い、実行のInputとOutputをDatasetに保存するこ とでEvaluationに利用すること で るようになる (Annotateした内容はDatasetには保存されない)
  8. 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してい
  9. Evaluation • Datasetにあら じめInputとOutputの組み合わせ らなるExampleを保存 • ExampleのInputを使ってLLMを実行し、出て た Outputを保存されているOutputを使って評価 •

    評価にはLangSmith あら じめ用意している評価 や、カスタム評価を利用すること で る • 評価結果は、key (評価指標の名前), score (評価結 果), commentとして残すこと 可能
  10. LangSmith導入の課題 • データの送信: ◦ LangSmithにInput、Output、Prompt などを送ることとなる ◦ 意図せずセキュアな情報を送らないよ うに実装時に注意 必要

    • コスト: ◦ チームで使うと1ユーザあたり $39 (6000円強)/月で少し高め • アプリとLangSmithの密結合: ◦ ユーザ らのフィードバックを保存す る仕組みなどで、アプリとLangSmith 密結合してしまうこと ある
  11. 自動Evaluatorの設定 • 手順: ◦ データセットで「Add Evaluator」ボタンを クリック ◦ Evaluatorに名前を付け、使用するプロンプト を設定

    ◦ 評価基準をスキーマフィールドに指定 ◦ Evaluatorを保存し、設定後の実験実行 自動 的に評価される • 利点: 評価プロセス 簡素化され、一貫した評価基準 適用される
  12. 標準Evaluatorの利用 • 種類: ◦ QA Evaluator(qa、context_qa、cot_qa) ◦ 基準Evaluator(criteria) ◦ ラベル付

    基準Evaluator(labeled_criteria) ◦ 文字列距離メトリックEvaluator(string_distance) ◦ 埋め込み距離メトリックEvaluator(embedding_distance) • 利点: 多様な評価基準をカバーし、迅速に評価で る
  13. Annotationの利用 • 手順: ◦ 実行結果ページで「Add Annotation」ボタンをクリック。 ◦ 注釈内容を入力して保存 ◦ 注釈は実行結果ページで確認・編集可能

    • 利点: ◦ 詳細なフィードバック: 各実行結果に具体的なフィードバックを追加。 ◦ エラーの特定: 特定のエラーや問題点を明確化。 ◦ チーム間の共有: チームメンバー間での情報共有 容易。