LLMOpsとは？
近年、GPT-4のような大規模言語モデル（large language model、以下LLM）の使用が普及し、それを活用したアプリケーションの開発が活発に行われています。たとえば、24時間英語学習をサポートするアプリケーションや、お客様からのお問い合わせに自然に応答するアプリケーションなど、LLMは私たちの生活の中に溶け込んでいます。
しかし、このようなLLMベースのアプリケーションを直接開発し、商用サービス化するのはまだ難しい状況です。万能のように見えるLLMでも、現在の文脈を把握して確率に基づいて回答を生成することに特化しているため、もっともらしい応答を提供することがあります。そのため、予期しない回答などでサービス品質が低下するのを防ぐには、さまざまな技術を適用する複雑なプロセスが必要になります。
LLMが有意義な回答を提供できるように開発するためには、データセットの準備、モデル学習、デプロイメントなどの手順が必要です。つまり、希望するドメインに適したデータセットを収集し、それをLLMが学習できる形に加工する必要があります。また、モデルを学習・評価できる環境を構築し、完成したモデルをユーザーが問題なく活用できるように安定的にデプロイ・モニタリングする必要があります。
このようなプロセスを効率的に管理できるようにサポートするのが、この記事で紹介するLLMOpsです。LLMOpsは、LLMの全体的なライフサイクルを管理しながら、データサイエンティストとソフトウェアエンジニアが円滑に協力できるようサポートする役割も果たします。
最近では、LLMOpsはLLMの学習とデプロイメントだけでなく、プロンプトエンジニアリングやエージェント作成、総合的なテスト環境までの広い範囲のサポートを開始しました。これは、管理が必要なドメインが、LLM自体だけでなくLLMアプリケーションの作成に不可欠なコンポーネントまで拡張されたためです。したがって、LLMOpsの定義は、モデルの管理を超えて、LLMアプリケーションのワークフロー全体をサポートする方向へと変化しています。
LLMOpsとMLOpsとの違い
では、LLMOpsは機械学習（ML）開発のワークフローをサポートするMLOpsとはどのような違いがあるのでしょうか？
以下は一般的なLLMアプリケーションの基本的な推論（inference）プロセスです。
LLMアプリケーションは、MLの推論プロセスと同様に、入力→前処理→モデル（モデルに質問する段階）→後処理の順に推論しますが、さらにRAG（Retrieval-Augmented Generation、検索拡張生成）やプロンプトエンジニアリングなど、LLMならではの複雑なプロセスが追加されます。この点がMLOpsとの違いと言えます。
また、モデルを評価する方法にも違いがあります。MLでは0か1で評価する方法や、一定の基準によるスコアで表現される指標を使用して評価する方法を使います。一方、LLMは回答が数字の形ではなく自然言語の形で出てくるため、回答の流暢さや関連性、一貫性のような人間の介入が必要な評価項目が存在します。そのため、LLMOpsでは、人間が結果を簡単に評価できる環境を一緒に提供する必要があります。
このような違いから、LLMOpsはMLOpsとは少し異なる形で進化しています。
LINE GAME PLATFORMでLLMOpsを開発した理由
私たちが開発したLLMOps環境を本格的にご紹介する前に、LLMOpsを開発した理由を説明します。LINE GAME PLATFORMの業務の特性を紹介すると、その理由の説明に役立つと思います。
LINE GAME PLATFORMは現在30以上のゲームと、各ゲームで使用されるさまざまなプラットフォーム機能をサポートしています。各ゲームは、すべてのプラットフォーム機能を導入するのではなく、必要なものだけを選択して導入しています。そのため、プラットフォームを使用する際、一律の手順を適用できません。各ゲームの状況に合わせてカスタマイズされた手順でリリースされ運営されます。その過程で必然的に多くの人員が必要になります。必要な人員の規模を減らすために、さまざまなAPIを開発して提供していますが、十分ではありませんでした。
しかし、GPT-3.5がリリースされ、LLMが利用しやすくなったことから、既存のゲームプラットフォームのナレッジベースを活用したRAGと、エージェントを使用した自然言語ベースの結果生成をサポートする社内ツールを開発し、ユーザーからのお問い合わせ対応やプロセス改善に活用しました。その過程で複数のPoC（proof of concept、概念実証）を実施しました。今回紹介する例は、LINE GAME PLATFORMの開発者向けガイドであるLINE GAME Developersを、ベクトルデータベースに埋め込みRAGを使用して開発者からの問い合わせに対応するチャットボットです。以下は、そのチャットボットが動作している様子です。
このチャットボットは、一般的なデータセットに含まれている内容への質問には、よく答えていました。しかし、データセットの内容と少し違う質問をすると、間違った回答をするハルシネーションの問題が発生しました。この問題を防ぐためにさまざまな処理を行う中、回答精度の向上という課題だけでなく、作業プロセス自体にも関連する課題も発生しました。
- LLM開発者は、専門知識が含まれる回答のクオリティを判断するのが難しい
- 専門知識を持った人は、開発プロセスに参加するのが難しい
- 小さな修正でも回答の変動幅が大きく、検証が難しい
また、プロジェクトの構造的な問題も作業進行の妨げとなりました。
- プロンプトチェイン（prompt chaining）など、プロンプトエンジニアリングプロセスがプロジェクトを複雑にする
- 既存の開発者にとって馴染みのない領域であるLLMに関する作業ノウハウが簡単に共有できない
PoCプロジェクトが増加し、上記のような問題が繰り返し発生しました。そこで、全体的なワークフローを定義するためにLLMOpsの開発をスタートしました。
LLMOps環境を開発で重視したこと
LLMOps環境を開発する際に最も重要視した点は、ドメイン専門家も簡単に参加できるようプロジェクト作業プロセスの可視性を確保することでした。ドメイン専門家が開発に慣れていなくても、積極的にプロジェクトに参加できるように作業 プロセスを視覚化することが必須だと考えたからです。
ただ、すべてのプロセスを可視化することは非効率的です。そのため、ドメイン専門家の介入が必要な部分だけを可視化し、他はプラットフォームの形で隠すか、コンポーネントとして使用できるようにすることを目標としました。可視化によってドメイン専門家が作業に積極的に参加し、共通化されたコンポーネントによって開発者のノウハウがプロジェクト全体に共有できるようにしました。このため、LLMアプリケーションをサービス化するために必要なプロセスを概念的に定義することにしました。
LLMアプリケーションのためのワークフロー定義
私たちは、LLMアプリケーションをドメイン専門家がリードして開発できるように、LLMアプリケーションの開発プロセスを以下の大きく5つの段階に分けました。そして、ドメイン専門家がLLMアプリケーションに使用するデータの準備から、プロンプトの作成、アプリケーションの作成とデプロイ、テスト後の結果確認まで、エンドツーエンドで作業できる環境を構成しました。また、そのための管理者用コンソールも併せて構築しました。
では、各段階でどのような点を重視して開発したのかを紹介します。
入力段階で考慮した点
データはAI/ML分野で最も重要な要素の一つです。なぜなら、モデルの学習やテスト の際に収集されたデータを活用するためです。情報通信分野でよく言われる「Garbage In, Garbage Out」という表現のように、モデル学習に使用するデータが不十分であれば、性能は保証できません。LLMは自然言語に基づいて学習しテストするため、ドメインにそぐわないデータを使って作業を進める場合、正しい回答を提供できない可能性があります。
そのため、データ検証は必須です。しかし、静的な方法で良質のデータを収集して判断するのは難しいです。特に、ドメイン集約的なデータの場合はなおさらですので、ドメイン専門家による検証が必要です。ただし、一般的なAI/ML作業環境では大規模なデータを扱うため、ドメイン専門家がこのような作業環境を構築して確認するのは、容易ではありません。
これを解決するために、私たちはStreamlitを利用して、ウェブ環境でデータを簡単に収集・検討できるシステムを優先して開発しました。以下は私たちが開発したシステムの画面です。
私たちが開発したウェブシステムで提供されるデータセットは、シームレス（seamless）な開発プロセスを支援するため、学習とテストに簡単にマウントできるように設計しました。これにより、データの整合性についてドメイン専門家とデータエンジニアが別々にコミュニケーションを行う負担を軽減しました。
また、データは学習とテストだけでなく、RAGを使用して文書検索（document retrieval）などの作業もサポートできるようコンポーネントに連携しました。これにより、ドメイン専門家が検証されたデータを基準に、さまざまな作業を進められるようにサポートしています。
プロンプトとアプリケーション、デプロイ段階で考慮した点
LLMアプリケーションには、自然言語で命令を出す「プロンプト」という要素があります。しかし、自然言語で作成するといって、適当に書いていいわけではありません。LLMがよく理解できるように構造化された形で作成する必要があり、そのノウハウが必要です。
そのため、プロンプトはユーザー間でノウハウをやりとりできるように、プロジェクトの区別なく共有可能で、プロジェクトに簡単に適用できる必要があります。また、モデルごとに適切に処理できるプロンプトが異なるため、自分のプロジェクトに適したモデルを素早く確認できる環境が必要です。
そのため、私たちはプロンプトを共有してすぐに実行できる環境を提供することが重要だと考えました。そこで、以下のようにユーザー間でノウハウを共有できるプロンプトストア（prompt store）を構築し、すぐにプロンプトを実行できる環境を構成しました。
また、プロンプトエンジニアリングで複数のプロンプトを使用すると、プロジェクトの複雑さも増えてしまいます。これについては、複雑なロジックを簡単に把握してコードを再利用できるよう、以下のようにLanFlowを利用してロジックをグラフで視覚的に表現しました。これにより、ドメイン専門家はロジックの流れを直観的に理解して再利用でき、開発プロセスに直接参加できるようになります。
最後に、Kubernetesを使用してLLMアプリケーションを簡単にデプロイできるようにしました。これにより、ドメイン専門家は複雑なインフラを構築することなく、アプリケーションを迅速かつ安定的にデプロイでき、本番環境でLLMアプリケーションがどのような回答を出すかをすぐに確認できます。
このような統合環境は、LLMアプリケーションの開発とデプロイメントプロセスを大幅に簡素化し、ドメイン専門家が中核機能の開発に集中できるようにサポートします（実装についての詳細は、先日公開したみんなのためのLLMアプリケーション開発環境の構築事例をご参照ください）。
テスト段階で考慮した点
LLMアプリケーションは、前述のようにプ ロンプトが少し変わっただけでも結果が大きく変わることがあります。さらに、複数のプロンプトを使用する環境では、その変化の幅はより大きくなる可能性があります。そのため、LLMアプリケーションの作業を行う際には、反復的なテストによるプロンプトの検証が欠かせません。しかし、大規模なデータ環境でそれを一つ一つ要求して、検証することは容易ではありません。プロンプトの数が増え、アプリケーションの数が増えれば、テストのためのコストは倍増します。
そのため、LLMOps環境では、これを効果的に実行できるようにサポートする必要がありました。LINE GAME PLATFORMでは、Harnessを利用してLLMアプリケーションの結果を以下のように指標で定量化し、ドメイン専門家が簡単に把握できるようにしました（実装についての詳細は、先日公開したHarnessを利用してLLMアプリケーション評価を自動化するを参照してください）。
プロジェクト規模に対して考慮した点
このようなワークフローを作成していく中で、コンポーネントが一つ、二つと増え、自然とLLMOpsプロジェクトの規模が大きくなっていきました。LINE GAME PLATFORMのLLMOps環境は多数のPython AI/MLライブラリを使用するため、Pythonを主な言語として開発しています。本来のPython開発環境では、このような大規模なプロジェクトを支えるには限界があります。そこで、 効率かつ安定的な開発環境を整えるために、Poetryと依存性注入器（dependency injector）を導入し、プロジェクトの管理と依存関係の管理を開始しました（詳しくは、先日公開したPoetryを利用したマルチプロジェクトPythonアプリケーションの開発方法を参照してください）。
LLMOps開発後、改善された点
LLMOpsの開発を通じてさまざまなことを改善できました。
まず、ドメイン専門家がLLMアプリケーションにより簡単にアクセスできるようになりました。これにより、各専門家が自分の分野に合ったアプリケーションを直接活用し、改善する機会が設けられ、結果としてLLMの活用度を高めることに貢献しました。また、職種に関係なく、自分のアイデアを直接社内ツールで実装できるようになりました。これは組織の効率を高め、さまざまな観点から問題を見て解決できる道を開くことができました。私たちの組織のメンバーは、自分のアイデアを実験して実装するために必要なツールと環境を手に入れ、より創造的で効率的な業務遂行が可能となりました。これらによって、冗長な開発は減少し、開発者は新規機能の開発に集中できるようになりました。
このような改善は、LLMOpsを構想した当初に達成しようとした目標であり、より高度なLLMOps環境を開発するための重要な土台となっています。
おわりに
LLMOps環境はまだ正解のない分野です。それでも、LINE GAME PLATFORMで試した方法が私たちの組織にポジティブな効果をもたらしたため、その内容を紹介することにしました。私たちの経験が、みなさんのLLMOps環境構築に役立つことを願って終わりにしたいと思います。最後までお読みくださり、ありがとうございました。