Azure OpenAI を活用してエンタープライズ向けのデータ活用基盤を作ってみる

Transcript

1. Azure OpenAI を活用して エンタープライズ向けの データ活用基盤を作ってみる 向山 裕一朗 ２０２３年7月28日 インフラ寄りの話 1
2. 向山 裕一朗 • 2013年 エンタープライズ向け営業職で入社 • 2017年 IBM Watson 周辺ソリューション企画等対応 • 2018年 副業として週末エンジニアを始める • 2021年 個人的に Blockchain 周り Contribute 開始 • 2022年 異動 営業 → ソリューションアーキテクトへ • 2022年～ Cloud Native 製品の推進に従事 • 2023年～ OpenAI 活用含む アプリ開発等従事 2
3. 背景 業務として Cloud, DevOps 周りの企画・推進をしていた アプリ開発業務も始め、掛け合わせた事例を作ろうと思った Generative AI データ活用 3
4. Generative AI の進化 前提となる課題意識 4
5. 短期間で大量の Generative AI 製品が登場 機能追加、アップデートも急速 画像生成（一例） • Stable Diffusion テキスト生成・予測（一例） • OpenAI 音楽生成（一例） • MusicLM コード作成、支援（一例） • GitHub Copilot etc… OpenAI の場合 （順不同） • 入力可能な文字数（token数）の増大 • 生成された文字数辺りの価格低下 • 各ベクトルデータベースとの簡単連携 • ChatGPT Plugin の登場 • GPT-4 の一般公開 • Function Calling の登場 • Code Interpreter の登場 • Azure on your data の登場 • プロンプトエンジニアリングによる回答最適化 • RAG による LLM が知らない情報の学習・予測 … etc 5
6. 機能・性能向上と共に社内・外でのユースケースも増加 ggr を もっと便利に 記事等 文章案自動生成 プレゼン資料の 自動生成 （実はこの資料も一部…） 社内資料の 効率的検索 議事録 自動作成 画像素材 自動生成 6
7. ついてけない 7
8. Generative AI の進歩・新規ユースケースの登場が早すぎて ユースケース毎に開発していると間に合わない アイディアは社内、社外から どんどん飛んでくる どんどん試したい 対応・開発相談が沢山入る どんどん追いつかなくなる 基盤の負荷も上がる サーバー負荷 必要な 開発リソース 8
9. 対策） 急速に拡大するユースケースへ対応しながら 自社で Generative AI をスムーズに活用していく為に User Chat UI 使いたい機能を選ぶと 対象の APIに接続されるもの Custom FAQ Plugin ユースケース A のテンプレートアプリ 画像解析系 Plugin ユースケース B のテンプレートアプリ 素の Azure OpenAI GPT3.5 SaaS 連携 Custom FAQ Plugin Box, Google Drive 9 一般的な Chat UI 上で接続先を変えるだけで社内で開発した特定タスク特化の AI を使えるように Plugin の仕様を揃え一部リソースを共用する事でスムーズに展開していく （ ≠ ChatGPT Plugin ）
10. Generative AI を 活用していく為に 用意してみた仕組み、環境を説明していきます 10
11. 全体 拡張性の高く、流用のしやすい設計の検討 GIP DNS Kubernetes アプリ実行環境 LB USER Chat App (Web SV) Public Cloud Plugin A Plugin B Plugin C FAISS… etc Vector / Semantic STORAGE CREDS LOG IaC Azure OpenAI Github 11
12. Generative AI ⇔ Generative AI 各 Plugin API の構造 は Azure OpenAI と共通になるよう構築 Plugin 単体の利用だけではなく、Plugin ⇔ Plugin も実現する事で少ない開発工数で発展を狙う Plugin A Plugin B Plugin C Plugin n … Azure OpenAI 12 同じようにアクセス可能 Plugin から Plugin を使う事も可能
13. Kubernetes の活用 スケールしやすい基盤の用意 13 チャットリクエストの増加、ベクトル化・推論等でかかるインフラリソース負荷の増加等、 Generative AI 活用アプリを作るだけではなく、インフラ側の設計も考慮が必要 水平スケール Pod CPU or Memory Limit 0.5 vcpu 垂 直 ス ケ ー ル 水平スケール Pod CPU or Memory Limit 0.5 vcpu 垂 直 ス ケ ー ル ノードA 2vCPU 8GB 水平スケール Pod CPU or Memory Limit 0.5 vcpu 垂 直 ス ケ ー ル 水平スケール Pod CPU or Memory Limit 0.5 vcpu 垂 直 ス ケ ー ル ノードグループ ノード水平スケール（各ノードで稼働する pod が使用するリソースの合計がノードの限界に近づくとノード側をスケールさせる ） ノードB 2vCPU 8GB
14. Infrastructure as Code の活用 アイディアを即デプロイできる環境 14 Plugin を作ったら 自動的に即デプロイ 、 更新時も自動差し替え ができるよう Infrastructure as Code な環境を用意 Plugin 設計兼 開発者（私） Fork した人 新たに開発した人 コンフィグ置き場 Github レポジトリ GIP DNS node External DNS Kubernetes アプリ実行環境 LB node node Cert Manager ・・・ RDB Secret Manager Prometheus Push 変更検出 Azure や その他 Public Cloud
15. 利用例 社内で用意した利用方法例を2つご紹介します 15
16. 社内資料 + Azure OpenAI で 社内問合せの負荷軽減 16 質問者 質問 Web/API Server 社内データ設置場所 回答 質問転送 今となっては一般的になった社内データ活用 1つのプラグインとして提供 認証 チャットの受け渡し プラグイン間連携 （Plugin） API Server データベースより 回答に必要なデー タの取得 → AOAI （Plugin） API Server FAISS を用いてベ クトル検索を行い、 関連文書探索 Plugin Chat UI 回答に必要な 追加データ取得 Azure OpenAI 以下の形式で質問を投げる ``` ${Prompt} >>> ${ヒットした社内データ} >>> ${User Question} ```
17. 当社製品について 聞いてみた 17 当社 MSP サービスの資料を探索対象に 「強みを教えて」と聞いてみた -- こんな事に使えるかも？ • FAQ • プレゼン資料案作成 （実はこの資料も…？） • メールの返信文案作成 … etc
18. クラウド間接続で AWS + Azure OpenAI 18 VPC EC2 （既存アプリ） Virtual Private Gateway Public Subnet Route53 Resolver Outbound Endpoint Direct Connect Gateway Express Route VNet Private Endpoint Gateway Subnet Private Endpoint Subnet Private DNS Resolver Subnet DNS Private Resolver Inboud Endpoint Express Route Gateway Azure OpenAI Internet Gateway Internet Azure内のVNetから OpenAIはAzure内部接続 AWSからAzureは 閉域接続 既存アプリケーションが AWS 上にあり、 AWS から OpenAI に接続したいケースもあった （AWS アプリ → Plugin → Azure → Azure OpenAI）
19. まとめ 残り 1 スライド 19
20. 加速するユースケースに置いて行かれない為に 今こそ Generative AI 活用 × PlatformOps 20 出展：2021年11月16日-18日開催 「Gartner IT Symposium/Xpo 2021」から引用（当社にて体裁加工） みんなで DevOps アイディア即デプロイ PlatformOps 開発 チーム Fork 実施者 他部門 等 … Generative AI 活用基盤 クラウドネイティブな アプリケーション プラットフォーム 開発チームや別部門 PlatformOps チーム Gartner さんの文章引用 DevOps のスケーリングと加速には 実装環境を標準化し、その高度化に専念す るPlatformOps の概念を提唱 Platform ops is an approach to scaling DevOps that involves dedicating a team to the delivery of a shared self-service app platform. Technical professionals focused on DevOps should use a product mindset to establish a platform that helps agile development teams deliver higher quality faster. https://www.gartner.com/en/documents/3988253 ※ 勿論無法地帯も防止
21. -- 宣伝 -- Cloud Native Application Platform 勿論自社で Kubernetes を用意することで CNAP 無しでも同様の環境は再現可能です 21 Managed & Help Desk • K8s 運用で必須な機能構築済み • 基盤の運用・監視お任せ • Infrastructure as Code 構築済み な MSP サービス CNAP を提供中 ※ MSP = マネージドサービスプロバイダ
22. EoF 22