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