【DeNA × AI Day】 LLMの事業適用を加速させるLLMOps

LLMの事業適⽤を加速させるLLMOps データ統括部データ基盤部 外⼭ 寛 1 © DeNA Co., Ltd.

⾃⼰紹介 外⼭ 寛 ● データ基盤部 プラットフォームグループ所属 ● 2018年⼊社 ● MLOps=>データエンジニア=>LLMOpsと 職種を転々としている 2 © DeNA Co., Ltd.

DeNAのLLMプロジェクトの特徴 DeNAでは多種多様な領域で事業を展開 LLMプロジェクトも様々な領域にわたり数多く存在 ※ スライドに記載している全てのサービスにおいてLLMの活⽤が⾏われているわけではありません 3 © DeNA Co., Ltd.

LLMOpsとは(⼀般論) ● 特に⼤規模⾔語モデルを使ったアプリケーションのオペレーションや 管理など⼀連のプロセス ● 主要な要素には、モデルのデプロイメント、スケーラビリティの確 保、パフォーマンスモニタリング、ログ管理、セキュリティ対策、プ ライバシー保護が含まれる 4 © DeNA Co., Ltd.

LLMOpsのスコープ(⼀般論) ● ● ● ● ● ● 5 デプロイメント(モデルの更新と管理) スケーラビリティ モニタリングとロギング セキュリティとプライバシー 効率化とコスト管理 fine-tuningに伴う学習パイプラインの構築 © DeNA Co., Ltd.

DeNAの現状のLLMOpsのスコープ ● ● ● ● ● ● 6 デプロイメント(モデルの更新と管理) スケーラビリティ モニタリングとロギング セキュリティとプライバシー 効率化とコスト管理 fine-tuningに伴う学習パイプラインの構築 © DeNA Co., Ltd.

スモールスタート ● 基本的にLLMプロジェクトの9割はスモールスタート ○ よってPoCから始まるので開発を少⼈数でいかに効率良く回せる かが重要となる ● 実装コスト上LLMで課題解決は以下のような優先順位で⾏う 1. プロンプトエンジニアリング 2. RAG 3. fine-tuning 7 © DeNA Co., Ltd.

DeNAのLLMOps ● ⼀般的に話されるLLMOpsは⼤規模なプロジェクトでのfine-tuningを 前提とした話が多い ● モデルをfine-tuningする話になるとMLOpsとあまり変わらない ● DeNAのLLMOpsは「PoCを⾼速に回す」ことがどちらかというと求め られている ● プロジェクトにおいてLLM本当に価値が出せるかを⾒極めることが⼤ 事な場⾯が多いため 8 © DeNA Co., Ltd.

(DeNAの)LLMOpsとMLOpsの違い ● 学習パイプラインの構築が必須ではない ○ OpenAIやGeminiなどのモデルを使う場合は⾃社モデルのdeploy や管理の必要が基本ない ○ PoCはプロンプトエンジニアリングでなんとかなる ○ MLOpsの場合学習パイプラインの開発にかなり時間を取られるが この点がない場合は運⽤的にも楽でスモールスタートしやすい ● 推論処理から先の開発フローは基本MLOpsと同じ ● 扱うライブラリの⼤半がLangChainやStreamlit関係 9 © DeNA Co., Ltd.

LLMプロジェクトの進め⽅と役割(現状) データサイエンティスト プロンプトエンジニアリ ング、各種モデル評価 データサイエンティスト プロジェクトにアサインされ、LLMモデルの 評価やPOC実装、プロンプトエンジニアリン グを⾏う LLMOpsエンジニア 推論API開発(アプリ開発) プロジェクトにアサインされ、LLM システムの設計、実装、運⽤を担当 LLMOpsエンジニア インフラ構築 token消費量のモニタリング、インフラ構築 などSREのような業務も担当 運⽤ プロジェクトによって担当領域は流動的 10 © DeNA Co., Ltd.

LLM開発のフェーズ 本開発 確度が⾼いPoC フルスクラッチ開発 Streamlitなどのchat-UI Difyベースの社内基盤LLMアプリ (SAI) アイデア段階 11 © DeNA Co., Ltd.

SAI ● 新卒研修から⽣まれた社内基盤LLMアプリ ● RAGを含む基本的なチャットアプリの作成‧利⽤をサポート ● LLMアプリ開発基盤OSS Difyをバックエンドに組み込み、⼊出⼒処理 やRAG機能の開発を⾼速化 ● 全社運⽤にあたり、Google Cloud上に安定したDifyのインフラを構築 ○ TerraformコードをDeNAのOSSとしてGitHubで公開中 12 © DeNA Co., Ltd.

LLMOpsのはじまり 13 © DeNA Co., Ltd.

Azure OpenAI ● Azure OpenAI Serviceを社内で使いたい、がLLMOpsの始まりだった ● セキュリティ要件を満たしやすく、IaCなどインフラ管理との相性が 良いAzure OpenAIに乗り換えたいという話が出た ● 最初はOpenAIのAPIを各⾃が⾃由に使っていた ○ ただwebブラウザでの利⽤は不可とするルールだった ● Azure OpenAIを使いたい⼈が部署内に多く出てきた ○ アカウントの運⽤が煩雑になり始めた ○ token消費量の最適な分散が必要になってきた 14 © DeNA Co., Ltd.

Azure OpenAIのToken消費量の分散(例) region A(1000k tpm のcapacity) Endpoint(250k) Endpoint(250k) region B(500k tpm のcapacity) Endpoint(250k) Endpoint(250k) Endpoint(250k) Endpoint(250k) region C(300k tpm のcapacity) Endpoint(150k) Endpoint(150k) user単位で個別endpointを作成してcapacityを最適化 15 © DeNA Co., Ltd.

各種LLM案件紹介 16 © DeNA Co., Ltd.

⽬標設定サポートチャットAI ● ● ● 17 期初に⾏う⽬標設定をサポートしてくれ るチャットAI 定性的な⽬標を定量化するように⾊々サ ジェストしてくれる 社内900名以上が利⽤ © DeNA Co., Ltd.

⽬標設定サポートチャットAI GCP VPC load balancing ● ● ● ● 18 Azure Cloud Run (streamlit) gpt-4o RAGなどは利⽤せずprompt engineeringで完結 モデルはgpt-4oを使⽤ ○ gpt-4oは複雑なプロンプトエンジニアリングをしてもハルシネーションが発⽣ しなかった フロントエンド、バックエンドはStreamlitで開発 GCPで動かすためCloud Runで稼働 © DeNA Co., Ltd.

DeNAベイスターズ何でも相談チャットAI ● DeNAベイスターズの過去のニュースをRAGとして利⽤ ○ https://sp.baystars.co.jp/news/2024/12.php ● RAGのエンジンはpgvectorを使⽤(後述) ● モデルはgemini-1.5-proを使⽤ ○ これまではazureのgpt-4oが多かった ○ シンプルなpromptになった ● フロントエンド、バックエンドはStreamlitで開発 ● GCPで動かすためCloud Runで稼働 19 © DeNA Co., Ltd.

• https://sp.baystars.co.jp/news/2024/12.php

DeNAベイスターズ何でも相談チャットAI RAGとして使われた metadata 20 © DeNA Co., Ltd.

DeNAベイスターズ何でも相談チャットAI GCP VPC cloud sql(pgvector) gemini 1.5 pro load balancing vector検索 private service connect cloud run 21 © DeNA Co., Ltd.

対話AI‧データ基盤の開発 ● 内閣府の『戦略的イノベーション創造プログラム（SIP）』 ● ⼈とテクノロジーが共⽣‧協調して相互に⽀えあう社会を実現するこ とを⽬指した対話AI‧データ基盤の開発 ● 現在開発中 ● 詳細はこちらに ○ https://www.nedo.go.jp/content/100979570.pdf 22 © DeNA Co., Ltd.

• https://www.nedo.go.jp/content/100979570.pdf

対話AI‧データ基盤の開発 AWS VPC Amazon Bedrock (claude 3.5 sonnet) Aurora(DB) Backend Server AI Server ● ● ● 23 VPC Endpoint アプリは全てaws上で構築 VPC Endpointを使ってセキュアにBedrockへ閉域接続 modelはbedrockでclaude 3.5 sonnetを使⽤ © DeNA Co., Ltd.

技術的取り組み 24 © DeNA Co., Ltd.

RAGとLangChain ● LangChainはLLMアプリ開発のライブラリ ○ 最早フレームワークと⾔えるレベルで機能が超⼤ ○ 主要なモデルはほぼ全てサポートしている ● 社内ではLLMアプリを開発する際にLangChainを使うことが多い ● RAGを使うにもLangChainから使えるRAGにする必要あり ● LangChainはRAGのサポートも⼿厚い 25 © DeNA Co., Ltd.

pgvector ● ● ● ● 26 PostgreSQL の拡張機能（Extension） ベクトル型データを扱うことができる つまりRAG⽤途に使える ベクトル同⼠の距離⽐較（最近傍探索）の関数は以下 ○ L2 距離（ユークリッド距離） ○ 内積 ○ コサイン類似度（またはコサイン距離） © DeNA Co., Ltd.

pgvectorのメリット ● PostgreSQL なのでCloudSQLやRDSなどで動かせる ○ AWSで動かそうがGCPで動かそうが差分がない ● LangChainから使いやすい ○ LangChainのサポートがしっかりしている ● pgvectorのdocker imageを使えばlocal開発もやりやすい ○ クラウド上と同じ構成の開発環境が実現できる ● RAGを要する場合⼤抵DBも必要になるので⼀⽯⼆⿃ ○ PoC向きでコストも抑えられる 27 © DeNA Co., Ltd.

LLMプロジェクトにおけるのナレッジの集約 ● ● ● ● ● ● 28 メガプロンプトによる対話制御 マルチエージェントシミュレーション LLM-as-a-Judgeによるマルチターン対話の評価 LangGraphによるワークフロー制御 Chain-of-Thought (CoT) による推論精度の改善 etc… © DeNA Co., Ltd.

LLMOpsの課題とか 29 © DeNA Co., Ltd.

課題. マルチクラウドのジレンマ ● なにかサービスを⽴ち上げる度にAzureとGCP、AzureとAWSを⽤意 するのが結構な⼿間ではある ● 可能な限りGCPならGemini、AWSならBedrockと同じクラウド内で 完結するようなサービス構成が運⽤しやすく、セキュリティ的にも堅 牢である ● ただ、まだgpt-4oが使いやすいユースケースもある ● Azureで完結するような構成は今はない ○ 社内のケイパビリティの問題 30 © DeNA Co., Ltd.

まとめ 31 © DeNA Co., Ltd.

まとめ ● LLMプロジェクトはまだまだこれからということもあり、スモールス タートさせたいというPoC案件が多い ● PoCをどうやって早く回すかというのもまたLLMOps ● PoCとはいえシステム的なベースは必要 ○ セキュリティとかも含む ○ システム構築部分をいかに⾼速に回すかが重要！ ○ LLMで本当に事業価値が出せるかを⾒極めることが重要 32 © DeNA Co., Ltd.