生成AIのアプリは、本番に出してからが長い。プロンプトを直すたびに、前は答えられた質問に答えられなくなる。使っていたモデルに廃止の日が来る。利用者が増えて、費用と応答の時間が読めなくなる。こうしたことを、出たとこ勝負でなく決まった手順で回すための考え方がLLMOpsだ。
ここでは、LLMOpsとは何かを定義から整理し、MLOpsとの違い、本番で回すものを表にまとめる。試作を本番に持っていくまでの壁はAIのPoC止まりを抜け出すに書いた。この記事は、本番に出したあとの話だ。
LLMOpsとは
LLMOps（Large Language Model Operations）とは、本番で動く大規模言語モデル（LLM）とそのアプリを運用・管理するための実務、技法、道具の総称だ。
主なクラウド事業者の定義は、ほぼ同じことを言っている。
| 出典 | 定義の要点 |
|---|---|
| Google Cloud | LLMの管理と運用に関わる実務とプロセス |
| Databricks | 本番環境のLLMを運用管理するための実務・技法・道具。データの流れ、評価、プロンプトと設定の管理、コストの管理、監視などを扱う |
| AWS | 本番環境のLLMの運用を管理する道具と実務。ファインチューニングから保守までのライフサイクルを管理し、自動化する |
| IBM | AIモデルの開発、デプロイ、管理をライフサイクル全体で速めるための専門的な実務とワークフロー |
Microsoftは同じものをGenAIOps（Generative AI Operations）と呼び、LLMOpsと呼ばれることもあると書いている。名前は違っても、指しているものは同じだ。
私の見方では、LLMOpsは特定の製品の名前ではなく、本番で品質を保ち続けるための約束事の集まりだ。道具を入れることより、何を記録し、何を測り、誰が直すかを決めることが先にある。
MLOpsとの違い
LLMOpsは、機械学習のモデルを運用するMLOpsの延長にある。Google Cloudは、LLMOpsをMLOpsの一部分で、LLMに固有の課題を扱うものと説明している。AWSも、従来のMLOpsのままでは生成AIの用途の複雑な運用の要件に足りず、拡張が要ると書いている。
機械学習を本番で運用する難しさを論じた論文に、2015年のNIPSで発表されたD. Sculleyらの「Hidden Technical Debt in Machine Learning Systems」がある。機械学習は成果を早く出せるが、それはタダではなく、実運用のシステムには保守の費用がかさみ続ける負債がたまりやすい、と論じている。原因として挙げられた中には、外の世界の変化や、設定の問題が入っている。生成AIのアプリでも、同じ種類の負債がたまる。
違いを、私の整理で表にした。
| 観点 | MLOps | LLMOps |
|---|---|---|
| モデル | 自社のデータで学習して作る | 提供元のモデルを借りる。必要ならファインチューニングする |
| 変える場所 | 学習データと学習の設定 | プロンプト、渡す文書（RAG）、モデルの選択 |
| 正解の測り方 | 正解率など、決まった指標で測りやすい | 答えが文章なので、決まった指標だけでは測りにくい。人の評価やAIによる採点を組み合わせる |
| 費用 | 学習の計算資源が中心 | 使うたびにかかる推論の費用が中心 |
| 外から来る変化 | データの分布の変化 | データの変化に加え、提供元のモデルの更新と廃止 |
| 守るもの | 学習データの取り扱い | 入力される情報、プロンプトインジェクション、出力の誤り |
Databricksも、LLMの課題は答えが開かれていることが多く、利用者からのフィードバックが評価に欠かせないと書いている。プロンプトの作り込みが、もっともらしい誤りやプロンプトインジェクションのリスクを下げるとも書いている。外部の文書に紛れた指示で操られる攻撃についてはプロンプトインジェクションとはに書いた。
本番で回す5つのもの
LLMOpsで回すものを、私は5つに分けて考えている。
1. プロンプトと設定の版管理
プロンプト、使うモデルの名前、温度などの設定、渡す文書の範囲は、どれを変えても答えが変わる。コードと同じように版を付け、どの版がいつ本番に出たかを残す。AWSも、モデルの設定、プロンプトのデータ、学習データの版管理が要ると書いている。
2. 評価
変更を出す前に、決まった質問の組で答えを確かめる。OpenAIの文書は、評価（evals）をモデルの出力が指定した基準を満たすかを確かめるテストと説明し、モデルを上げ替えるときや新しいモデルを試すときに欠かせないと書いている。Anthropicの文書も、成功の基準をはっきり決め、それを測る評価を設計するところから始めるよう書いている。同じ文書は、少数の人手の採点より、自動で採点できる多くの質問のほうがよいとしている。
どの質問を評価に入れるかは、業務を知る人にしか決められない。誤りの重さで確認の仕方を変える考え方はハルシネーション対策にまとめた。
3. 記録と監視
本番の入力と出力、検索した文書、かかった時間とトークン数を記録する。AWSは、プロンプトのトークン数、応答の時間、文脈への忠実さなどを追える指標として挙げている。米国立標準技術研究所（NIST）が2024年7月に出した生成AIのリスク管理の文書（NIST AI 600-1）も、本番に出したあとの監視の計画に、利用者からの声を拾って評価する仕組みを含めるよう求めている。
記録の道具は、オープンソースのLangfuseやMLflowのように、LLMの呼び出しと検索の処理をまとめて追えるものがある。OpenTelemetryにも生成AI向けの記録の規約があるが、仕様は開発段階だ。
4. モデルの更新と廃止への備え
借りているモデルは、いつか使えなくなる。OpenAIもAnthropicも、新しいモデルを出すたびに古いモデルを定期的に廃止すると公式の文書に書いている。Anthropicの文書は、廃止日を過ぎたモデルへのリクエストは失敗すると書き、公開モデルの廃止は少なくとも60日前に知らせるとしている。Microsoft Foundryの文書では、一般提供のモデルの標準のライフサイクルは18か月だ。
同じ名前のまま中身が変わることへの備えもある。Anthropicは、モデルのIDごとに版が固定され、同じIDの中身は変えないと書いている。OpenAIも、特定の版に固定できるスナップショットを用意している。本番では版を固定したIDを使い、移行は評価を通してから行う。
道具のほうも変わる。OpenAIは評価の機能（Evals platform）を2026年11月30日に停止する予定だと書いている。特定の道具に評価の資産を閉じ込めず、質問と正解の組は自社の手元に持っておく。
5. 費用と応答の時間
LLMの費用は、使われた分だけ増える。利用者や機能ごとにトークン数を集計し、上限と警告を決めておく。応答の時間も同じ記録から追える。
LLMOpsを始める順番
最初から全部をそろえる必要はない。私の見方では、次の順番で足していくのが現実的だ。
| 段階 | やること | これがないと起きること |
|---|---|---|
| 本番に出す前 | プロンプトと設定に版を付ける。評価用の質問と正解の組を作る | 直したら別の質問で壊れたことに気づけない |
| 出した直後 | 入力と出力、かかった時間とトークン数を記録する。利用者が「役に立たなかった」と押せるようにする | 何が起きているかを、苦情でしか知れない |
| 利用が増えたら | 費用の上限と警告。記録から評価の質問を足す | 費用が読めない。評価の質問が古いまま |
| モデルを変えるとき | 版を固定したIDで、新旧のモデルを同じ評価で比べる | 廃止の日に、確かめないまま切り替えることになる |
社内文書に答えるAIでは、評価と記録の対象に検索の結果も入る。検索の仕組みはRAGとはに書いた。
LLMOpsを誰が回すか
LLMOpsの仕組みはエンジニアが作れる。ただ、何を正解とするか、どの誤りが許されないかを決めるのは業務の側だ。私の見方では、評価の質問の組を業務の担当者と一緒に作り、毎月見直す場がないと、記録と監視の道具を入れても数字を見る人がいなくなる。
業務の現場に入り、作ったAIを本番で使われ続ける形にするまでを担う職種についてはFDEとは？Forward Deployed Engineerの意味と仕事内容に書いた。生成AIのアプリを本番に出し、回し続けるところまでの支援は、私たちのサービスで紹介している。