LLMOps

LLMOpsとは、LLMを使ったアプリケーションを、作って終わりにせず、本番で安定して動かし、改善し続けるための取り組み全体を指す言葉です。機械学習の運用であるMLOpsや、ソフトウェア開発のDevOpsの考え方を、LLM特有の事情に合わせたものと言えます。

なぜ通常の運用と違うのか

従来のソフトウェアは、同じ入力に対して同じ出力を返すので、テストで合否を決めやすい性質がありました。LLMアプリは次の点が異なります。

• 出力が毎回変わりうる。 同じ質問でも、答えの表現や中身が揺れます。
• 品質が数値で測りにくい。 「良い回答」の基準は、用途や人によって変わります。
• 外部のモデルに依存する。 APIのモデルは、提供元の更新や提供終了（model-deprecation）で挙動が変わることがあります。
• 費用が使い方に比例する。 トークン数に応じた従量課金になるため、設計次第でコストが大きく変わります。
• 新しいリスクがある。 誤情報（ハルシネーション）、プロンプトインジェクション、個人情報の漏えいなどです。

こうした特徴に対応する運用の枠組みが、LLMOpsです。

主な構成要素

• 評価（evals）：代表的な質問と望ましい回答のセットを用意し、変更のたびに品質を測る。人手の確認や、LLM-as-a-judgeも使われます。
• 版管理：プロンプト、モデル名、設定値、検索の設定をコードと同様に記録し、変更の履歴を追えるようにする。
• 監視（オブザーバビリティ）：本番でのリクエスト、応答、遅延、エラー、トークン数、費用を記録し、異常に気付ける状態にする。
• 安全対策：入出力のフィルター、権限の制限、重要な操作での人の確認（ヒューマン・イン・ザ・ループ）。
• コストと性能の最適化：用途ごとのモデル使い分け、キャッシュ、バッチ処理の活用。
• フィードバックの循環：利用者の評価や失敗事例を集め、プロンプトや検索データの改善へつなげる。

具体例

社内QAボットで、新しいモデルが出たので入れ替えたいとします。LLMOpsが整っていれば、まず過去の質問200件の評価セットで新旧モデルを比較し、品質、遅延、費用を確認します。問題なければ、一部の利用者だけに先行公開し、本番のログを監視しながら範囲を広げます。問題が出たら、すぐ元の設定に戻せるよう、版を管理しておきます。

注意点

• 最初から大がかりな基盤は不要です。 小規模なら、評価用の質問リスト、プロンプトのGit管理、基本的なログから始めても十分です。規模や重要度が上がるにつれて、ツールや専任の担当を検討します。
• ツールは数多くあり、変化も速い分野です。 特定の製品に依存しすぎず、記録すべき情報と手順を先に決めると、後から乗り換えやすくなります。
• 「運用」は人と責任の話でもあります。 誰が品質を判断し、障害時に誰が対応するのかを決めておくことが、技術以上に重要になる場面もあります。

関連する考え方

品質を測る仕組みはevals、記録と可視化はobservabilityの項目で詳しく扱っています。モデルの提供終了への備えや、用途に応じたモデルの振り分け（model-routing）も、運用の重要な論点です。