はじめに
こんにちは！
DMMでカスタマーサポート基盤の開発・運用を担当している、PF開発本部 第一開発部 CSプラットフォームグループ AIチームの23新卒、渡部です。
現在は主にAI領域（LLMやSpeech-to-Textなど）に注力して業務を行っています。
今回は、GPT-3.5系からGPT-4o系への移行についてお話しします。
弊チームでは2023年10月よりAzureを利用してAI基盤の開発・運用を実施しています。
当初はGPT-3.5-Turbo-16Kを使用していましたが、LLM分野の急速な進化に伴い、GPT-4o系への移行を決定しました。
この記事では、チームで行った進化の早いLLMに対応可能なシステム構成や、 この移行を機に実施したC#からPythonへのコードリライトについてもご紹介します。
カスタマーサポート基盤について
CSプラットフォームグループ（以下：CSP）は、カスタマーサポート部と連携し、
カスタマーサポート業務に必要なツールやシステムの開発・運用をする部署にあたります。
具体的には、電話システムや事業部向けのシステムなどを担当しています。
近年ではAIの積極的活用を進めており、業務負担軽減を重視した施策を展開しています。
AI活用について
2023年10月より、Azureを利用したAI基盤の構築・運用を開始しました。
主に以下のサービスを活用しています：
- Azure OpenAI
- GPT-3.5-Turbo-16K（以降：GPT3.5）
- GPT-4-32K（以降：GPT4）
- GPT-4o系（GPT-4o、GPT-4o-mini）
- Azure Speech to Text
- Azure API Management
- CosmosDB
- Azure Functions
GPT3.5やGPT4の活用により、カスタマーサポートでの業務効率化を進めてきました。
具体的なシステム構成としては下記のようになっております
今回は画像の中のAI基盤と書いている部分について、 特にGPTモデルのGPT-4o系への切り替えと、それに伴う周辺システムの最適化に重点を置きお話しさせていただきます。
GPT-3.5からGPT-4o系への移行
移行の理由
GPT3.5からGPT-4o系への移行を決定した理由は以下の2点です：
モデルの非推奨アナウンス
Azure OpenAIでは、モデルの非推奨や提供終了についてのアナウンスが行われます。
2023年8月にGPT3.5の一部モデルで非推奨になることを確認し、今後のモデルサポートを考慮し、 早期移行が必要と判断しました。
ソース：2024年8月時点のアナウンスページ
情報（※現在、情報は更新されております）GPT-4o-miniの登場
GPT-4o-miniは、精度向上、処理速度の向上、コスト削減といった利点があります。 さらに、トークン数の上限が16Kから128Kに大幅拡大されました。 これにより、従来は16K超の場合にGPT4へ切り替える必要があった運用を一本化でき、 運用コストやモデル管理の手間を大幅に削減できました。
初期ではプレーンテキストから文字をパースする処理を行ったり、 OpenAIにてJson出力の方法に対応 したことによりパース処理を不要とし、効率的に結果から情報を取得することが可能になりました。
C#からPythonへの移行
GPT-4o系への移行に合わせて、C#で構築していたシステムをPythonへ全面にリライトしました。
主な理由は以下の通りです：
技術スタックの統一
PythonはLLM分野で主流のプログラミング言語であり、最新技術の活用やライブラリの充実の度合いが高いです。
これにより、開発効率や新規PoCの迅速な展開が可能になります。属人化の排除
チーム全体でPythonを標準技術として採用しているため、C#による開発は属人化を招いていました。
今回の移行により、全員が対応できる統一的な環境を整備しました。
なお、C#採用の背景にはCosmosDBの特定機能が当時Pythonで対応できなかった事情がありましたが、 現在ではPythonでも同様の対応が可能になったため、統一を実現しました。
実施プロセス
移行作業は以下の手順で進めました：
- プロンプトの挙動確認
- Python環境のリソース作成
- 検証環境での並行稼働
- 本番環境へのリリース
- API Managementの採用
- C#側リソースの削除
アーキテクチャ図としては以下の通りです。
以下では、重要なポイントを詳しく解説します。
プロンプトの挙動確認
CSPでは基本的にはベースモデルからプロンプトチューニングを行い目的の出力を行っております。 モデル変更による最大の懸念は、プロンプトの応答内容に影響が出ることでした。 特に、モデルの特性が変わることで出力の品質や意図にずれが生じる可能性があるため、慎重な検証を実施しました。
カスタマーサポート部に協力を依頼し、想定される利用シナリオを基にテストを行いました。 複数の架空の問い合わせを作成し、期待通りの応答が得られるかを確認した結果、大部分で問題のない結果が得られました。 一部の短文問い合わせでは応答が意図しないケースが確認されましたが、プロンプトの微調整を行うことで改善しました。
並行稼働での動作検証
移行期間中のシステム安定性を確保するため、C#版とPython版を並行稼働させました。
両システムは同一のCosmosDBを共有し、リクエストデータを一時的にCosmosDBに保持することで、
柔軟なデータ処理を可能にしました。
リクエストデータは以下のフローで処理されます：
リクエストのキューイング
外部システムから受信したリクエストはまずCosmosDBに保存されます。
これにより、全てのデータを一度キューイングすることにより急なリクエストの増加にも対応できます。推論の実行
保存されたデータがあるとCosmosDB triggerを元にAzure FunctionsがAzure OpenAIを呼び出し、GPTによる推論を実行します。結果の記録
推論結果もCosmosDBに保存し、結果返却時に利用されます。
この設計により、新旧システム間でのデータ整合性を維持しながらC#からPythonへの移行の実現のほか、Azure OpenAIを介したGPTによる推論を行う仕組みを構築しています。
API Managementの採用
API Managementを採用したことで、運用の効率化と問題発生時の調査にて柔軟が担保することが可能になりました。
特に以下の点で有効に機能しています：
管理容易性の向上
APIのエンドポイントを一元管理することで、リクエストのルーティングやポリシー設定を容易に行えました。
これにより、C#版からPython版への切り替え作業を迅速化できました。リクエストトレースの強化
API Managementのログ機能を活用し、すべてのリクエストとレスポンス包括的に記録することで、 エラーの発生箇所や処理性能の変化を詳細に追跡が可能となりました。変更容易性の担保
今後新規エンドポイントやシステム変更時に大きな更新を行うことなくスムーズに変換ができるようになりました。
持続可能なAI基盤として
AI基盤、とりわけLLM環境の進化は目まぐるしく、各社約半年ごとに大きなアップデートがあります。
こちらの流れに対して適切に検証や実施するための環境などを同時進行にて整備を行っていました。
現在はStreamlitを用いたUI基盤も別に運用を行っており、エンジニアサイドでの検証とカスタマーサポート側での検証・利用を行っています。
2023年10月からAzureを導入して約1年が経過しました。 この間、AI基盤の安定稼働と新機能の追加を並行して進めてきましたが、開発スピードを優先するあまり、新しい機能を積み上げる形での対応が続いていました。 その結果、変更対応時に無理が生じる場面も増えていました。
今回のGPT3.5系への移行に伴い、C#からPythonへのリライトを含む基盤整備を実施し持続可能なシステム運用を目指す取り組みを進めました。 工数はかかりましたが、Factory MethodやAdapterといったデザインパターンを活用することで、柔軟性と高品質を両立させた開発を実現しています。 また、Azureの新機能を積極的に活用しながら新規開発とリファクタリングを並行して進めた結果、開発生産性とシステムの柔軟性を向上させることができました。
おわりに
GPT-4o系への移行とPython環境へのリライトを通じ、柔軟で効率的なAI基盤を構築できました。
これにより、運用負担を軽減しつつ新機能に取り組む際に容易に取り組める環境になりました。
今後もより良いシステム提供を目指していきます。
関連事例：
