ストーリー
ミッション概要
| 項目 | 内容 |
|---|---|
| 目標 | AIシステムの継続的改善プランを設計する |
| 所要時間 | 60分 |
| ミッション数 | 2つ |
| 使用知識 | A/Bテスト / フィードバックループ / Fine-tuning判断 |
| 評価観点 | 改善サイクルの実用性、A/Bテスト設計の妥当性 |
Mission 1: 継続的改善サイクルの設計(30分)
シナリオ
【チャットボットの現状データ】
- 月間10,000対応、CSAT: 72%(目標: 85%)
- ネガティブフィードバックの内訳:
不正確な回答: 35%
的外れな回答: 25%
回答が冗長: 20%
対応できないトピック: 15%
その他: 5%
- エスカレーション率: 25%(目標: 15%以下)
タスク
【継続的改善プラン】
1. フィードバック収集設計:
明示的フィードバック: ___
暗黙的フィードバック: ___
専門家レビュー: ___
2. 改善アクション計画:
| 問題カテゴリ | 改善手段 | 優先度 | 期待効果 |
|------------|---------|--------|---------|
| ___ | ___ | ___ | ___ |
3. 改善サイクルの運用設計:
日次: ___
週次: ___
月次: ___
四半期: ___
4. KPIと目標:
| KPI | 現状 | 1ヶ月後 | 3ヶ月後 |
|-----|------|---------|---------|
| ___ | ___ | ___ | ___ |
解答例を見る
1. フィードバック収集:
明示的: チャット終了時のGood/Badボタン + 任意コメント欄
月次アンケート(CSAT 5段階 + 自由記述)
暗黙的: 同一セッション再質問率、エスカレーション率、
セッション継続率、平均対話ターン数
専門家: QAチームが週100件をサンプリングレビュー、
カテゴリ別の品質スコアリング
2. 改善アクション:
| カテゴリ | 手段 | 優先度 | 効果 |
|---------|------|--------|------|
| 不正確(35%) | RAG知識ベース更新+ファクトチェック追加 | 1(最優先) | CSAT+5% |
| 的外れ(25%) | 質問分類の改善+プロンプト調整 | 2 | CSAT+3% |
| 冗長(20%) | 出力長制限+簡潔回答プロンプト | 3 | レイテンシ改善 |
| 対応不可(15%) | 知識ベース拡充+スコープの見直し | 4 | エスカレ率-5% |
3. 運用設計:
日次: ネガティブFB確認、エラー率チェック、緊急対応
週次: FB分析レポート、改善タスク起票、QAレビュー結果共有
月次: KPIレビュー、改善効果測定、次月計画策定
四半期: モデル評価、Fine-tuning検討、アーキテクチャ見直し
4. KPI:
| KPI | 現状 | 1ヶ月後 | 3ヶ月後 |
|-----|------|---------|---------|
| CSAT | 72% | 78% | 85% |
| エスカレーション率 | 25% | 20% | 15% |
| Good率 | 60% | 70% | 80% |
| 再質問率 | 30% | 22% | 15% |
Mission 2: A/Bテスト計画の策定(30分)
タスク
Mission 1の改善施策をA/Bテストで検証する計画を策定してください。
【A/Bテスト計画書】
1. テスト一覧:
| テスト名 | 仮説 | 変数 | 主要メトリクス |
|---------|------|------|-------------|
| ___ | ___ | ___ | ___ |
2. 最優先テストの詳細設計:
Control: ___
Treatment: ___
トラフィック分割: ___
期間: ___
サンプルサイズ: ___
成功基準: ___
ガードレール: ___
3. テスト実施スケジュール:
| 週 | テスト | フェーズ | 判断基準 |
|----|-------|---------|---------|
| ___ | ___ | ___ | ___ |
4. テスト結果に基づく意思決定フレームワーク:
___
解答例を見る
1. テスト一覧:
| テスト名 | 仮説 | 変数 | メトリクス |
|---------|------|------|---------|
| RAG改善テスト | 知識ベース更新で不正確回答30%減 | RAGソース | 正確性スコア |
| 簡潔回答テスト | 出力長制限で冗長回答50%減 | max_tokens+プロンプト | 満足度 |
| 質問分類テスト | 分類改善で的外れ回答20%減 | 分類プロンプト | 的確性スコア |
2. 最優先テスト(RAG改善):
Control: 現行RAG(知識ベースv1、Top-5チャンク)
Treatment: 更新RAG(知識ベースv2+FAQ追加、Top-3チャンク+リランキング)
トラフィック: カナリア5%→2日→本テスト50%→2週間
期間: 最大3週間
サンプルサイズ: 各群2,000件以上
成功基準: 正確性スコアが統計的有意に5%以上改善(p<0.05)
ガードレール: エラー率+5%で自動停止、CSAT-10%で自動停止
3. スケジュール:
| 週 | テスト | フェーズ | 判断 |
|----|-------|---------|------|
| W1 | RAG改善 | カナリア5% | エラー率チェック |
| W2-3 | RAG改善 | 本テスト50% | 統計的有意差 |
| W4 | RAG結果反映 | 100%展開or棄却 | p値+効果量 |
| W5-6 | 簡潔回答 | カナリア→本テスト | 同上 |
| W7-8 | 質問分類 | カナリア→本テスト | 同上 |
4. 意思決定フレームワーク:
有意に改善(p<0.05, lift>5%): Treatment採用→全量展開
有意だが効果小(p<0.05, lift<5%): コスト/複雑さとの兼ね合いで判断
有意差なし(p>=0.05): テスト延長(サンプル不足)or棄却(十分なサンプル)
有意に悪化: 即座に棄却、原因分析→次の仮説策定
達成度チェック
| 評価項目 | A(優秀) | B(合格) | C(要改善) |
|---|---|---|---|
| フィードバック設計 | 3種類を統合した包括的設計 | 基本的な収集設計 | 収集方法が限定的 |
| 改善サイクル | 多層的な運用設計 | 基本的なサイクル | サイクルが不明確 |
| A/Bテスト | 統計的に厳密な設計 | 基本的なテスト設計 | テスト設計が不十分 |
| 意思決定 | データ駆動の判断基準 | 基本的な判断基準 | 判断基準が曖昧 |
推定所要時間: 60分