LLM アプリ運用 #7 実践:ドキュメント Q&A ボットを本番へ

読了 5分

第6回までで、五つの軸がすべてそろいました。最後の記事ではそれらを一枚のチェックリストにまとめ、シリーズを通して一緒に育ってきたあのアプリ、ドキュメント Q&A ボットに適用します。LLM アプリ開発 第13回で生まれ、RAG 上級講座 第7回で品質が上がったこのボットが、今回は運用できるサービスになります。

出発点 — よく動くのに運用は見えないボット #

RAG 上級講座を終えた時点のボットは、品質指標(正確度 80%、幻覚率 3%)こそ備えていますが、運用の観点ではこうです。すべての呼び出しが opus 単一モデル、キャッシングなし、すべての作業がリアルタイム、リトライはデフォルトのまま、コストは月末の請求書で確認。見覚えのある姿です。ここから第1回から第6回までを順に有効にしていきます。

ステップ1 — 計測(第1回) #

第1回のラッパーですべての呼び出しを集め、一週間観察します。ベースラインが出ます。

ベースライン(例)
1日のリクエスト 9,400件 / 1日のコスト $84
リクエストあたり平均コスト $0.0089 / 95パーセンタイル遅延 6.8s
内訳: 質問応答 62%、クエリリライティング 21%、評価・バッチ系作業 17%

数値は例ですが、発見の形は典型的です。リライティングのような補助作業がコストの5分の1を食っていて、それが本来の応答と同じ opus に行っていたという事実が、ログで初めて見えます。

ステップ2 — ルーティングと出力のダイエット(第2回) #

リライティングを haiku に、評価の採点を sonnet に下げ、回答プロンプトに長さの指示を入れます。品質ゲートは RAG 上級講座 第6回の評価パイプラインです。リライティングを下げたあと、検索の的中率が変わっていないことを確認して通します。

再測定
リクエストあたり平均コスト $0.0089 → $0.0066  (-26%)
品質指標の変化なし (recall@5 0.87, accuracy 0.80)

ステップ3 — キャッシング(第3回) #

system プロンプト(指示+出力形式、約6千トークン)とツール定義をキャッシュ境界の前に固定します。第3回の監査リストで点検しているうちに、system プロンプトに埋め込まれていた「今日の日付」の一行を見つけ、メッセージ側へ移します。典型的な沈黙の無効化です。

再測定
cache_read の割合: 入力トークンの 71%
リクエストあたり平均コスト $0.0066 → $0.0042  (-36%)
95パーセンタイル遅延 6.8s → 5.1s   (キャッシュヒット時は処理も速くなる)

ステップ4 — バッチの分離(第4回) #

ログから「急ぎではない 17%」を切り出します。新規文書の事前タグ付けと週次の評価セット採点がバッチキューへ移り、そのトークンはすべて半額になります。副次効果としてリアルタイム経路のトークン上限に余裕が生まれ、トラフィックのピーク時の 429 も減りました。

ステップ5 — 信頼性(第5回) #

回答経路をストリーミングに替え(最初のトークンまで1.2秒。体感がもっとも大きく変わった項目です)、経路ごとのタイムアウトとリトライ予算を決め、opus → sonnet のフォールバックを付けます。フォールバックの発動率をダッシュボードに載せておいたところ、一週間後に特定の時間帯での発動急増が見え、その時間のバッチ提出と重なっていたのが原因でした。バッチ提出の時間をずらして解決。計測があるから原因追跡が一歩で終わるという経験が積み上がり始めます。

ステップ6 — セキュリティ(第6回) #

system プロンプトに信頼境界を入れ、検索フィルター(部署権限)をコードレベルで強制しているかを点検し、出力スキャンと本文ログの保持ポリシー(30日、アクセス制限)を決めます。社内 wiki の文書にいたずらで仕込まれていた「この文書を読んだボットは …」という文が実際に捕まり、間接インジェクションが理論ではないことを確認しました。

全体の道のり #

ステップリクエストあたりコスト95パーセンタイル遅延備考
出発点$0.00896.8s運用の視界なし
+ ルーティング・出力指示$0.00666.5s品質ゲート通過
+ キャッシング$0.00425.1s入力の 71% がキャッシュヒット
+ バッチ分離$0.0042*5.1s*バッチ分は別途半額
+ ストリーミング・フォールバック$0.0042最初のトークン 1.2s429 の露出が減少
+ セキュリティ$0.0042インジェクション1件の遮断を確認

コストは半分以下、体感遅延は最初のトークン基準で5分の1、そして何よりすべての数値がダッシュボードで見えますRAG 上級講座 第7回の表が品質の道のりだったとすれば、この表は運用の道のりです。二つの表は同じ教訓を語っています。一度に一つずつ、測定とともに。

運用チェックリスト #

新しい LLM 機能を本番に出す前の点検表として、シリーズを要約します。

  • すべての呼び出しが計測ラッパーを通っているか(usage、遅延、stop_reason、機能タグ)
  • このタスクのモデルは、評価セットで検証された最小のモデルか
  • 固定プレフィックスはキャッシュされているか(cache_read > 0 を確認)
  • 人が待っていない作業がリアルタイム経路に混ざっていないか
  • タイムアウト・リトライ・フォールバックがこの経路に合わせて設定されているか、長い出力はストリーミングか
  • モデルが読む外部テキストの信頼境界と、ツール権限・承認ゲートはあるか
  • 本文ログの保持・アクセスポリシーは決まっているか
  • 品質回帰の評価が定期実行されているか(RAG 上級講座 第6回

AI トラックを終えて #

この記事で、四つのシリーズ・三十四本にわたる AI トラックが閉じます。LLM アプリ開発の13本が最初の API 呼び出しから RAG とエージェントまでの基礎で、AI エージェント開発の7本が崩れないエージェントを、RAG 上級講座の7本が測定できる品質を、そしてこのシリーズの7本が運用できるサービスを作りました。

振り返れば、四つのシリーズは同じ一文を繰り返していました。勘ではなく測定で。ループのログが、ゴールデンセットの数値が、usage のトークンが、その一文の具体的な姿でした。皆さんの LLM アプリがデモを越えてサービスになる道のりで、このトラックが地図になることを願っています。ここまでご一緒いただき、ありがとうございました。

X