ふくふくHukuhuku Inc.
EP.12RAG 11分公開: 2026-05-10

本番運用:RAGの監視と改善ループ

本番投入後の 3 ヶ月。フィードバック収集 → 分析 → 改善のサイクルを定常運用に乗せる仕組み。観測指標・週次レビュー・データドリフト検知まで。

#運用#監視#改善
シェア

本番投入はゴールではなくスタート。3 ヶ月後・半年後・1 年後と継続的に改善する仕組みが必要です。本記事では、ふくふくが受託案件で運用してきた 「動いている」を「成長している」に変える 3 つの仕組みを共有します。本編の到達点として、EP.01〜11 までの内容を本番に着地させる話。

本番運用の落とし穴

  • 精度が徐々に下がる:データドリフト(質問パターン変化、文書追加)で精度低下
  • ユーザー満足度が分からない:「使われてるけど良いのか悪いのか不明」
  • 改善ネタが溜まる一方:日々のフィードバックが TODO リストの底に沈む
  • コスト最適化の機会損失:放置すると月額が膨らむ一方

観測すべき 6 指標

本番 RAG のダッシュボード(最低限)
指標見るべき頻度良い目安悪化の兆候
質問数 / 日日次増加トレンド急減 = 信頼失墜
回答時間 p95日次< 5 秒10 秒超 → UX 損失
ユーザー評価 (👍 / 👎)週次👍 80% 以上👎 比率上昇
評価スコア週次0.85 以上0.7 を割ったら異常
コスト / 質問週次$0.05 以下0.10 超 → 最適化必要
ガードレール発火率日次1〜3%急増 = 攻撃 or 仕様逸脱

改善ループの 3 つの仕組み

① ユーザーフィードバック収集

👍/👎 ボタン + 自由記述を回答下に必ず置く。👎 が押されたら 質問・取得文書・回答 をログに記録、週次でレビュー。改善 PR の起点になる。

👎 押下時のフィードバック収集 UI(例)
TSX
<div className="rag-response">  <div>{response}</div>  <div className="feedback">    <button onClick={() => sendFeedback("up", { messageId, query })}>      👍 役に立った    </button>    <button onClick={() => setShowReport(true)}>      👎 改善要望    </button>    {showReport && (      <textarea        placeholder="どこが間違っていたか / 期待した内容を教えてください"        onBlur={(e) => sendFeedback("down", { messageId, query, comment: e.target.value })}      />    )}  </div></div>

② 週次レビュー会

毎週 30 分、固定アジェンダで回す。 EP.15 の KPI レビュー会と同じ思想。

  1. 1今週の数字:質問数、👍 率、p95 応答時間
  2. 2👎 ピックアップ:最も多く Down 評価された 3 件を全員で読み解く
  3. 3ゴールデンセット の回帰結果:プロンプト変更があれば必ず確認
  4. 4次週のアクション:プロンプト改修 / 文書追加 / 設定変更を 1〜2 件決める

③ データドリフト検知

質問パターンの変化を監視。「先月は機能 A の質問が多かったが、今月は B が増えている」のような変化は、何か業務が変わったことのシグナル。

  • 質問のクラスタリング:週次で質問を し、k-means クラスタの変化を見る
  • 新クラスタ出現:新しいトピックが浮上 → ナレッジベース追加検討
  • 既存クラスタ消失:使われなくなった機能 → 文書整理
  • 精度劣化:特定クラスタだけ 👎 比率が高い → 個別チューニング

改善 PR のフロー

  1. 1👎 集計 → 分類:「文書不足」「プロンプト改善」「Reranker 設定」「Embedding 質」のどれか
  2. 2ゴールデンセットへの追加:問題ケースを再現できるテストケースに
  3. 3改修実装:プロンプト変更 / 文書追加 / モデル変更
  4. 4回帰テスト:ゴールデンセットで全件評価、デグレなしを確認
  5. 5A/B 配信:5〜20% のユーザーで本番試験、👍 率比較
  6. 6全展開:A/B で勝てば全ユーザーへ

3 ヶ月で見える効果(実例)

ふくふくが伴走した RAG プロジェクトの推移
指標Month 1Month 3改善
👍 比率62%88%+26pt
p95 応答時間8 秒3.5 秒-56%
コスト/質問$0.12$0.04-67%
質問数 / 日120850+7 倍
ガードレール発火率8%2%-75%

ふくふくの進め方

RAG を本番投入したが、運用が回らない」というご相談には、観測ダッシュボード構築(2 週間)→ 週次レビュー会の運用設計 → 3 ヶ月伴走でお出ししています。👍/👎 比率を 1.4 倍コスト 60% 減応答時間半減のセットで効くケースが多いです。

ここまでのまとめ

EP.01「精度が出ない 5 つの典型パターン」から始まり、チャンク戦略・Embedding・Reranker・評価・コスト・マルチモーダル・ガードレール・運用まで 12 話で扱いました。RAG は「作って終わり」ではなく「育てるシステム」。本シリーズも同じ姿勢で、現場フィードバックや読者リアクションに応じて続編を随時追加していきます。

シリーズ後半予告(EP.13〜)

次のテーマブロックでは、ハイブリッド検索のチューニング多言語 RAGエンタープライズ統合などをテーマにお届けします。RAG だけで限界が見えた時の次の一手を扱う予定。

シェア

この記事の感想を教えてください

あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。

シリーズの外も探す:

まずは、現状を聞かせてください。

要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。

無料相談フォームへ hello [at] hukuhuku [dot] co [dot] jp