LLMOpsとは何か: 大規模言語モデルを業務で安定して使うための運用の仕組み完全ガイド

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

LLMOpsが必要な理由

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

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

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

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

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

LLMOpsの正確な定義: MLOpsとどう違うのか

MLOpsとLLMOps、3つの軸での違い

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

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

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

両者は代替関係ではありません。LLMOpsは、バージョン管理、導入前の検証、運用中の監視というMLOpsの原則を、大規模言語モデルの特性に合わせて適用したものです。

LLMOpsが管理する4つの対象

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

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

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

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

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

この4つの対象のうち1つでも記録が抜けていると、結果が変わったときに原因を絞り込めません。4つの要素のバージョンの組み合わせを、1回のデプロイ単位としてまとめておくとよいでしょう。

LLMOpsの実際の適用方法

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

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

採点の基準も同時に決めます。根拠文書と一致しているか、必要な項目を漏らしていないか、定められた形式を守っているかを、設問ごとに判定できる必要があります。

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

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

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

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

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

韓国環境でのLLMOps

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

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