LLMOpsとは何か：大規模言語モデルを業務で安定して使うための運用体制の完全整理

LLMOpsとは、大規模言語モデルを業務に展開したあと、プロンプトとモデルのバージョン、検索データ、回答品質とコストを合わせて管理し、結果を一定の水準に保つ運用体制です。

LLMOpsが必要な理由

同じ質問に違う答えが返ってきました。

大規模言語モデルはデモの段階で印象的な結果を見せます。ところが業務に展開して数週間経つと、先週はうまくいった質問に的外れな答えが返ってきたり、回答の形式が変わって後続システムが結果を読めなくなったりします。コストが想定より速く増えることもよくあります。

原因はいくつもの場所にあります。誰かがプロンプトの文言を直したのかもしれず、モデルの提供元がバージョンを更新したのかもしれず、検索対象の文書が変わったのかもしれません。何がいつ変わったかの記録がなければ、原因を探すだけで数日かかります。

従来のソフトウェアはコードが同じなら結果も同じです。大規模言語モデルはコードの外にある文章やデータ、外部のモデルによって結果が変わるため、これらの要素を別に管理する体制が必要です。

この要請は、大規模言語モデルが回答の生成にとどまらず業務の判断や処理に使われるほど大きくなります。回答が少し変わることは参考用のチャットボットでは不便で済みますが、審査や登録のような業務では誤った処理につながるためです。

LLMOpsの正確な定義：MLOpsと何が違うのか

MLOpsとLLMOps、三つの軸の違い

第一に、管理対象が違います。MLOpsは組織が自ら学習させたモデルとその学習データを中心に管理します。LLMOpsではモデルを自ら学習させないことが多く、プロンプトと検索データ、モデルの選択と呼び出し設定が主な管理対象になります。

第二に、変化が生じる場所が違います。MLOpsではモデルを変える主体は組織の内部です。LLMOpsでは、外部の提供元がモデルを更新したり旧バージョンの提供を終了したりするなど、組織が制御できない変化が起こります。

第三に、評価の方法が違います。MLOpsの評価は分類の正解率や数値の誤差のように、正解とすぐ比較できる指標が中心です。LLMOpsは文章で書かれた回答を扱うため、根拠文書と一致しているか、形式を守っているか、使ってはならない表現がないかなど、複数の基準を合わせて見る必要があります。

二つの体制は置き換えの関係ではありません。バージョン管理、展開前の検証、運用監視というMLOpsの原則を、大規模言語モデルの特性に合わせて適用したものがLLMOpsです。

LLMOpsが管理する4つの対象

運用中にバージョンとして残すべき4つの対象

第一に、プロンプトです。指示文や例、出力形式の定義はコードと同じようにバージョンを付け、誰がなぜ変えたかを記録します。一文を直しただけでも結果が大きく変わることがあるためです。

第二に、モデルのバージョンと提供元です。どのモデルのどのバージョンをどの設定で呼び出したかを残し、提供元のバージョン終了の予定を追跡します。

第三に、検索データです。回答の根拠となる文書群とチャンクの基準、インデックス作成の時点を管理しておけば、回答が変わったときにデータが原因かを見分けられます。

第四に、評価とコストです。固定した質問セットに対する採点結果と呼び出しあたりのコスト、応答時間を、バージョンごとに比較できるよう蓄積します。

四つの対象のうち一つでも記録が欠ければ、結果が変わったときに原因を絞り込めません。四つの要素のバージョンの組み合わせを一回の展開単位としてまとめておくとよいでしょう。

LLMOpsの実際の適用方法

評価用の質問セットを先に作ります

運用に入る前に、実際の業務で出てくる質問と期待する回答、根拠文書をまとめた評価セットを作ります。税務分野の事例では、対象の文書を定め、実際の問い合わせを集めてRAGの評価セットを構成しました。

採点基準も合わせて決めます。根拠文書と一致しているか、必要な項目が抜けていないか、決められた形式を守っているかを、質問ごとに判定できなければなりません。

このセットがあってはじめて、プロンプトやモデルを変えるたびに同じ基準で前後を比較できます。運用中に新たに見つかった失敗事例は評価セットに加え、同じ問題が再発しないかを確認します。

変更は一度に一つずつ反映します

プロンプトとモデル、検索データを同時に変えると、結果が良くなっても悪くなっても何が原因かわかりません。一度に一つの要素だけを変え、評価セットで検証し、承認を経て運用に反映します。問題が起きたら直前の組み合わせにすぐ戻せるよう、以前のバージョンを残しておきます。

呼び出し記録を残し、コストを分けて見ます

運用中は呼び出しごとに入力と出力、使用したバージョン、応答時間、コストを記録します。業務別、部署別にコストを分けて見れば、どの業務でコストが膨らんでいるかがわかり、軽いモデルで十分な業務を選び出せます。呼び出し記録は、利用者がおかしな回答を報告したときに当時の入力とバージョンを再現する根拠にもなります。

国内環境におけるLLMOps

韓国の金融と公共分野では、ネットワーク分離の規制により外部のモデルAPIを使いにくいことが多く、内部に設置したモデルを併せて運用する構成がよく見られます。この場合、モデルの入れ替えと性能比較を内部環境で行えなければなりません。

外部のモデルを使うときは、プロンプトに個人情報が入らないよう入力段階で隠し、呼び出し記録の保存場所と保管期間を決めておきます。韓国語の業務文書で評価セットを作ってはじめて、実際の性能を判断できます。

よくあるご質問