Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
LLMチャットボットの評価モデル
Search
Shinsuke Matsuki(snsk)
January 20, 2025
Technology
37
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
LLMチャットボットの評価モデル
Shinsuke Matsuki(snsk)
January 20, 2025
More Decks by Shinsuke Matsuki(snsk)
See All by Shinsuke Matsuki(snsk)
品質定義の組織レベル
snsk
0
67
メタモルフィックテスティングでMBT気分
snsk
0
27
ゲームのテスト設計のチャレンジ
snsk
0
63
JSTQB Conference2023 基調講演2
snsk
0
27
Other Decks in Technology
See All in Technology
FPGAが実現する遠方宇宙の高空間分解能天体撮影 -大型地上望遠鏡の視力を補正する「補償光学」とは?-
komei_mt
0
300
ハーレムエンジニアリング
kazuma777777
0
180
【GCC2026】大規模言語モデルを活用した内製検索サービスの社内展開や業務活用
bandainamcostudios
PRO
0
180
会社紹介資料 / Sansan Company Profile
sansan33
PRO
24
430k
エンドユーザー視点で見る SansanのMeraki活用と内製自動化
sansantech
PRO
0
100
社内の7割が使うデータ基盤を、 データチーム2人で回すためにやったこと
koh_yoshi
4
1.4k
FORENSIA: ローカルLLMフォレンジックハーネス
sumeshi
2
410
Apache Icebergインフラストラクチャ:ストレージ・カタログ・エンジンの選択肢とClouderaプラットフォームでの実装
tsugiyama
0
110
ソフトウェアサプライチェーンの構造的リスクとコンテナ環境の保護
kyohmizu
4
370
ブラウザ研修 2026
recruitengineers
PRO
6
1.1k
なぜ Temporal の大小比較には compare しかないのか / Why Does Temporal Only Have compare() for Comparisons
kazukihayase
1
150
Service Connect 上のサービスに ECS Service の外側から到達できなかった話
ota1022
1
270
Featured
See All Featured
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.8k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
440
Paper Plane (Part 1)
katiecoart
PRO
1
10k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
210
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
870
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
62k
Rails Girls Zürich Keynote
gr2m
96
14k
Bash Introduction
62gerente
615
220k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
My Coaching Mixtape
mlcsv
0
240
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
770
Transcript
LLMチャットボットの評価モデル https://www.confident-ai.com/blog/llm-chatbot-evaluation-explained-top-chatbot-evaluation-metrics-and-testing-techniques 出典: 役割の遵守 会話の関連性 知識の保持 会話の完全性 会話全体を通じて LLM チャットボットが指示どおりに行動できるかどうかを評価します。これは、ロール
プレイングのユースケースに特に役立ちます。最終的なロール遵守メトリックスコアは、指定されたチャット ボットがロールに従ったターン数を、会話テストケースの合計ターン数で割った値です LLM チャットボットが会話全体を通じて関連性のある応答を生成できるかどうかを評価します。これは、 各ターンを個別にループして計算され、スライディングウィンドウ アプローチを採用し、最後の min(0, current turn number — window size)ターンを考慮して関連性があるかどうかを判断します。最終 的な会話の関連性メトリックスコアは、関連するターン応答の数を会話テストケースの合計ターン数で割っ た値です LLMチャットボットが会話全体を通じて提示された情報を保持できるかどうかを評価します。これは、ま ず会話の特定のターンまでに提示された知識のリストを抽出し、LLM がターン応答にすでに存在する情 報を求めているかどうかを判断することによって計算されます。知識保持スコアは、知識の喪失がない ターンの数をターンの合計数で割ったものです。 会話全体を通じて LLM チャットボットがユーザーの要求を満たすことができるかどうかを評価します。 会話の完全性は、ユーザー満足度とチャットボットの有効性を測定するための代替評価として使用できま す。会話の完全性は、最初に LLM を使用して会話ターンで見つかった高レベルのユーザー意図のリスト を抽出し、次に同じ LLM を使用して会話全体で各意図が満たされたかどうかを判断して計算されます。 Slide: Shinsuke.Matsuki.2024
LLMチャットボットの評価モデル:アプローチ https://www.confident-ai.com/blog/llm-chatbot-evaluation-explained-top-chatbot-evaluation-metrics-and-testing-techniques 出典: Slide: Shinsuke.Matsuki.2024 スライディングウインドウ(Sliding Window) アプローチ 小さなブロック(ウインドウ)で順次評価する 「スライディングウインドウ」とは、チャットの内容やテキストを一定サイズの小さなブロッ
クに区切り、順番に(あるいは少しずつ重なりを持たせながら)評価を行うという方法を 指します。以下のようなイメージです。 1. 大きなテキストや長い対話ログを、ウインドウサイズ(例: 100トークン、200単 語など)で分割 2. 先頭からウインドウを当てて評価(例: ウインドウ内のチャットボット応答を評価) 3. 少しずらして次のウインドウを当てて評価 4. 全体をカバーするように繰り返す 「スライディングウインドウ」の狙いは、「全体の会話」や「長いテキスト」をそのまま一括で 評価するのではなく、ウインドウごとに局所的な要素(文脈の一部、回答の一部)をきめ 細かくチェックする点にあります
LLMチャットボットの評価モデル:アプローチ https://www.confident-ai.com/blog/llm-chatbot-evaluation-explained-top-chatbot-evaluation-metrics-and-testing-techniques 出典: Slide: Shinsuke.Matsuki.2024 局所評価を積み重ねるメリット • 詳細な不具合やエラー箇所を発見しやすい ウインドウを使うことで、対話ログ中のどのセクションで問題が起きやすいかを見極められます。 •
チャットボットの長い対話でも評価しやすい 一度に大量の文字数を扱う場合、評価基準がぼやけたり評価コストが膨大になったりすることがあります。スライディングウイ ンドウで段階的に評価することでその問題を軽減できます。 • メトリクスが安定しやすい 1箇所だけ極端に良い /悪い応答があっても全体平均に埋もれることがあるため、ウインドウ単位での評価を集計することでト レンドを捉えやすくなります。 スライディングウインドウの注意点 • ウインドウサイズ・ステップサイズの選定 ◦ 大きすぎるウインドウでは「細部を見逃しがち」、小さすぎると「文脈が途切れて正しい評価ができない」など、バランスが重 要 • 評価コスト ◦ ウインドウ単位で繰り返し評価するため、評価ツールや人手アノテーションのコストが増大する場合がある • 重複カウント・重複評価の扱い ◦ ウインドウ同士が重複する場合、その部分の応答をどう扱うかを明確に決めておかないと、一部の箇所だけ過剰に評価さ れる可能性がある