RAGは一度作って終わりのシステムではありません。利用者の質問が増えるほど、改善すべき文書、検索条件、回答方針が見えてきます。
残すべきログ
本番運用では、次のログを検討します。
-
質問内容
-
回答内容
-
参照文書
-
利用者属性
-
回答時間
-
評価ボタン
-
回答不能
-
誤回答報告
-
権限エラー
ただし、個人情報や機密情報を扱う場合は、ログの保存範囲や閲覧権限も設計します。ログを残すこと自体がリスクになる場合もあります。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。費用対効果 試算シート・失敗要因チェックリストをその場で共有します。
改善サイクルを決める
ログを残しても、誰も見なければ意味がありません。週次や月次で、よくある質問、回答不能、低評価、誤回答を確認し、文書追加やチャンク修正に反映する流れを作ります。
RAGの改善は、AI担当者だけでは完結しません。文書の管理部署、業務担当者、情シス、開発会社が役割を分担する必要があります。
KPIを置く
RAGの効果測定では、次の指標が使えます。
-
月間利用者数
-
質問数
-
回答評価
-
回答不能率
-
問い合わせ削減数
-
検索時間削減
-
有人確認への引き継ぎ数
導入目的によって見る指標は変わります。問い合わせ削減が目的なら回答解決率、営業支援なら資料探索時間、情シス支援なら問い合わせ件数が重要です。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
発注前チェック
-
どのログを残すか決めているか
-
ログ閲覧権限を決めているか
-
低評価や誤回答を誰が確認するか
-
文書追加・修正の運用があるか
-
効果測定KPIが決まっているか
運用改善まで見積もりに含めると、RAGを一過性のPoCで終わらせにくくなります。
RAGの運用改善まで設計します
質問ログ、回答評価、誤回答報告、文書更新フローを設計し、導入後も改善できる体制を作ります。
