生成AIで構築する自律型企業調査アシスタント

by ShuyaKinjo

Slide 1

Slide 1 text

⽣成AIで構築する⾃律型企業調査アシスタント 2024/7/11 リテールアプリ共創部⾦城秀哉

Slide 2

Slide 2 text

Xへの投稿の際は、ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い

Slide 3

Slide 3 text

⾃⼰紹介 3 ⾦城秀哉(Shuya Kinjo) ● リテールアプリ共創部マッハチーム ● サーバーサイドエンジニア ● 興味‧関⼼ ○ IaC、CI/CD、業務効率化、⾃動化

Slide 4

Slide 4 text

⽣成AIを⽇々の業務でどのように使⽤していますか？ 4

Slide 5

Slide 5 text

業務における⽣成AIの活⽤度合い 5 ● AIをシステムに統合 ● ビジネス固有ニーズへ対応 ● タスクに特化したAIツールを選択 ● 複数のAIを組み合わせる ● 基本的な対話型AI活⽤ ● 幅広い⽤途に対応 ● タスクに応じてAIをカスタマイズ ● GPTs、OpenAI Assistants APIを利⽤して独⾃のアプリ開発タスクに応じた AIのカスタマイズタスク毎にツール/ モデルを使い分け ChatGPTの利⽤

Slide 6

Slide 6 text

業務における⽣成AIの活⽤度合い 6 ● タスクに特化したAIツールを選択 ● 複数のAIを組み合わせる ● 基本的な対話型AI活⽤ ● 幅広い⽤途に対応 ● タスクに応じてAIをカスタマイズ ● GPTs、OpenAI Assistants APIを利⽤して独⾃のアプリ開発タスクに応じた AIのカスタマイズタスク毎にツール/ モデルを使い分け ChatGPTの利⽤ ● AIをシステムに統合 ● ビジネス固有ニーズへ対応

Slide 7

Slide 7 text

● フレームワークは使うべき？ ● インフラは普通のアプリと同じで良い？ ● AIにどこまで任せるべき？ ● AIが中々⾔うことを聞いてくれない ● etc… AI搭載アプリ開発の検討事項 7

Slide 8

Slide 8 text

考えることが沢⼭🤯 8

Slide 9

Slide 9 text

この30分で話すこと 1. 構築したアプリ(企業調査ツール)の説明 2. 技術選定のポイント 3. ⽣成AIアプリ実装時のTips 9

Slide 10

Slide 10 text

さらに⽣成AIを使いこなしたい⽅ ● ⼀歩進んだ活⽤⽅法のヒントを得る ● AI搭載アプリの開発に興味を持ってもらう既に⽣成AIをアプリに組み込んでいる⽅ ● 実装パターンの選択肢を増やす ● SlackBot、クローラー実装のノウハウを知るこのセッションのゴール 10

Slide 11

Slide 11 text

企業調査ツールについて 11

Slide 12

Slide 12 text

リテールアプリ共創部について 12

Slide 13

Slide 13 text

お客様のビジネスを深く理解したい 13

Slide 14

Slide 14 text

企業調査ツールとは ● 顧客理解のため補助ツールとして開発 ○ ⼿作業で⾏っていた調査業務を半⾃動化 ● クローリング、スクレイピング、要約、考察で⽣成AIを使⽤ ● SlackBotのインタフェースで提供 14

Slide 15

Slide 15 text

動作イメージ調査対象の企業名を⼊⼒ 15

Slide 16

Slide 16 text

動作イメージ企業名を元にURLを収集 16

Slide 17

Slide 17 text

動作イメージ Markdown形式で調査結果を出⼒ 17

Slide 18

Slide 18 text

2つの⼊⼒パターンで調査 18 企業名からの調査情報源を与えて調査

Slide 19

Slide 19 text

情報源を与えて調査 19 ⼊⼒されたMarkdownをパース HTML 内部データモデル ‧調査項⽬ ‧URL ‧AIへの指⽰

Slide 20

Slide 20 text

情報源を与えて調査 20 情報収集‧要約 URL 調査結果 AIへの指⽰ HTML 要約‧整形抽出‧考察

Slide 21

Slide 21 text

経営理念情報源を与えて調査 21 企業課題の考察‧レポート出⼒財務状況沿⾰会社概要 etc.. 調査レポート AIへの指⽰企業課題の考察調査結果

Slide 22

Slide 22 text

企業名からの調査 22 企業名から情報源をWeb検索 🔍クラスメソッド会社概要 🔍クラスメソッド財務状況 🔍クラスメソッド沿⾰ 🔍クラスメソッド経営理念、etc.. 企業名からの調査

Slide 23

Slide 23 text

企業名からの調査 23 Web検索結果 🔍クラスメソッド会社概要 🔍クラスメソッド沿⾰内部データモデル ‧調査項⽬ ‧URL ‧AIへの指⽰結果を精査

Slide 24

Slide 24 text

既存のAIツールとの違い ● より詳細な調査結果 ○ 調査項⽬毎に、複数ターンの要約と考察処理を1つのレポートにまとめる ● 既存の運⽤へ取り込みやすい ○ UI/UX設計のため毎回調査業務を⾏うデザイナーにも協⼒依頼 ○ ⾃動調査後⼿作業で⾁付けしやすいフォーマット 24

Slide 25

Slide 25 text

技術選定のポイント 25

Slide 26

Slide 26 text

● ⾔語：Python ● フレームワーク ○ LangChain、SlackBolt ● インフラ(AWS) ○ Lambda、CloudFront、AWS WAF ○ Amazon Bedrock ○ AWS CDK ● ⾔語モデル ○ Claude 3 Haiku, Sonnet 採⽤した技術スタック 26

Slide 27

Slide 27 text

● ⾔語‧フレームワーク ● インフラ構成 ● ⾔語モデルの選定技術選定のポイント 27

Slide 28

Slide 28 text

LangChainについて ● ⽣成AIを活⽤したアプリ開発のためのオープンソースフレームワーク ● LLMの機能を拡張し、外部データソースと統合することが可能 ● Python/JavaScriptで利⽤可能 ○ Python版の⽅が機能‧ドキュメント共に充実している 28

Slide 29

Slide 29 text

1. 統⼀されたインタフェースの提供 2. LLMと外部リソースの統合 3. 出⼒フォーマットの整形 LangChainの良かった点 29

Slide 30

Slide 30 text

統⼀されたインタフェースの提供 ● 外部リソース(Vector DB)の切り替えのPR ○ 変更点はほぼこれだけ 30

Slide 31

Slide 31 text

統⼀されたインタフェースの提供 31 ● ⾔語モデルの切り替えでも同様 ○ Bedrockで未提供のモデルへ変更するPR

Slide 32

Slide 32 text

統⼀されたインタフェースの提供 ● 抽象化により変更に強い設計‧実装が可能 ● トライアル&エラーで進める上で変更容易性は重要 32

Slide 33

Slide 33 text

LLMと外部リソースの統合 ● クローリングに特化したツール ○ Sitemap ■ サイトマップ配下の全てのページをクロール ○ Recursive URL ■ 指定したURL配下のURLを再帰的に読み込む 33

Slide 34

Slide 34 text

LLMと外部リソースの統合 ● Web検索を統合 ○ Google Search API ■ Google検索のAPI版 ○ Tavily Search API ■ LLMとRAGに最適化された検索エンジン ○ SerpAPI ■ Google、Bingなど数⼗種類の検索エンジンからデータ取得 34

Slide 35

Slide 35 text

● 外部のデータストア、API、サービスとの連携が数多く提供されている ● アプリケーションロジックの実装に集中できた LLMと外部リソースの統合 35

Slide 36

Slide 36 text

● LLMの出⼒はJSON形式にしたい ○ LangChainがなければプロンプトで頑張る出⼒フォーマットの調整 36

Slide 37

Slide 37 text

● LLMの出⼒はJSON形式にしたい ○ LangChainがなければプロンプトで頑張る出⼒フォーマットの調整 37 わかりました。以下が処理結果です。 { "result": "success" }

Slide 38

Slide 38 text

● LLMの出⼒はJSON形式にしたい ○ LangChainがなければプロンプトで頑張る出⼒フォーマットの調整 38 わかりました。以下が処理結果です。 { "result": "success" } JSON Decode Error

Slide 39

Slide 39 text

● Structured Output ○ 出⼒形式の構造体をPydanticで定義 ○ 構造体を渡すだけで出⼒形式を指定可能出⼒フォーマットの調整 39

Slide 40

Slide 40 text

出⼒フォーマットの調整 ● 出⼒フォーマットをPythonの構造体で指定可能 ● プロンプトでの直接指定より安定した出⼒を提供 ● モデルがJSONモードを提供している場合は併⽤も可能 40

Slide 41

Slide 41 text

● ⾔語‧フレームワーク ● インフラ構成 ● ⾔語モデルの選定技術選定のポイント 41

Slide 42

Slide 42 text

サーバレスで始める ● 最初は検証から始めたい ● 検証段階ではあまりコストをかけたくない →まずはサーバレス構成で検討する LLMの課⾦以外は、ほぼ無料で運⽤中 42

Slide 43

Slide 43 text

よくあるサーバレス構成 43

Slide 44

Slide 44 text

よくあるサーバレス構成の問題 44 API Gatewayが29秒で強制的にタイムアウトしてしまう使⽤するモデルによっては処理時間を要す

Slide 45

Slide 45 text

Lambda 関数 URLの利⽤ 45

Slide 46

Slide 46 text

Lambda 関数 URLの利⽤ 46 ‧HTTPエンドポイントを直接公開 ‧最⼤15分まで処理可能に

Slide 47

Slide 47 text

よりセキュアに公開する場合 47 CloudFrontを置くことで、WAFの配置やカスタムドメインが設定可能に

Slide 48

Slide 48 text

Lambda 関数URLのOAC対応 48 参考: https://aws.amazon.com/jp/about-aws/whats-new/2024/04/amazon-cloudfront-oac-lambd a-function-url-origins/

Slide 49

Slide 49 text

よりセキュアに公開する場合 49 2024/4にOACがLambda Function URLsに対応アクセスコントロールが簡単に！

Slide 50

Slide 50 text

よりセキュアに公開する場合 50 OACはPOST/PUTに未対応従来通りLambda@Edgeで SigV4の署名が必要

Slide 51

Slide 51 text

参考: https://dev.classmethod.jp/articles/cloudfront-lambda-url-sigv4-signer/ Lambda＠Edgeで署名 51

Slide 52

Slide 52 text

別案：SQSで⾮同期化 52

Slide 53

Slide 53 text

53 キューを⼊れた時点で正常応答を返すワーカーが⾮同期でリクエストを処理する別案：SQSで⾮同期化

Slide 54

Slide 54 text

● ⾔語‧フレームワーク ● インフラ構成 ● ⾔語モデルの選定技術選定のポイント 54

Slide 55

Slide 55 text

Amazon Bedrock ● ⽣成AIアプリ構築のためのフルマネージドサービス ● 複数のAI企業が提供するLLMを単⼀APIで利⽤可能 ● LLMの請求をAWS利⽤費にまとめられる ● 複数のモデルを同時に⽐較‧検証 ● エージェントやRAG構築も統合 55

Slide 56

Slide 56 text

Claude 3 ● 多くのベンチマーク、コスト⾯でOpenAIのGPT-4を上回る性能 ● 3つのモデルを展開 ○ Opus（最⾼性能）、Sonnet（バランス型）、Haiku （⾼速‧低コスト） ○ 現在はClaude 3.5 Sonnetが最新でOpusを上回る ● タスクに応じて使い分け ○ 要約：Haiku、考察：Sonnet 56

Slide 57

Slide 57 text

⽣成AIアプリ実装時のTips 57

Slide 58

Slide 58 text

⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. プロンプトの調整 5. 完璧を⽬指さない 6. クローラー実装時の注意点 58

Slide 59

Slide 59 text

Agent と Chainの⽐較 ● Agent ○ LLMにツールを与え、LLM⾃⾝に動的に⾏動を決定させる ■ 例)思考→⾏動(ツール)決定→実⾏→結果を元に再考→...出⼒ ○ 汎⽤的なタスクを実⾏可能 ■ 処理フローがLLMの出⼒結果に左右される ■ LLMの呼び出し回数が増える(コスト‧レイテンシー増) ● Chain ○ 事前定義した⼀連のアクションを実⾏する ■ 例)プロンプト⽣成→データ収集→推論 ○ 特定のタスクに特化 ■ 従来のプログラミングに⼀部AIを組み込む形 ■ 動作が安定し、コスト‧レイテンシーも実装次第で下げられる 59

Slide 60

Slide 60 text

Slide 61

Slide 61 text

⽣成AIを適⽤した箇所 61 プログラミングでは解決しにくい課題に対してのみ適⽤

Slide 62

Slide 62 text

⽣成AIを適⽤した箇所 62 Web検索結果と調査対象企業の関連度を判断しURL収集企業情報の要約‧抽出‧ 整形‧考察様々な企業HPのDOM構造を解釈するスクレイピング処理

Slide 63

Slide 63 text

全てを⽣成AIで実装も可能 63 ⼊⼒⽂字列からWeb検索キーワード⽣成企業情報の要約‧抽出‧ 整形‧考察検索結果のスクレイピング Markdownから内部データモデルへ変換出⼒結果の整形検索結果の関連度判定パターン判定

Slide 64

Slide 64 text

● ScrapeGraphAI ○ 当初はこちらで実装を検討 ○ LLMにかかるコスト⾯の懸念 ○ ここまでの汎⽤性は要らず不採⽤実際にやっているOSSもあります 64

Slide 65

Slide 65 text

⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. 完璧を⽬指さない 5. クローラー実装時の注意点 65

Slide 66

Slide 66 text

⼩さく始めて価値を検証する 66 クローラーの実装は後回し

Slide 67

Slide 67 text

⼩さく始めて価値を検証する 67 クローラーの実装は後回し情報源を与えるパターンで⼩さく作って検証

Slide 68

Slide 68 text

⼩さく始めて価値を検証する 68 ● Web検索を統合した他のAIツールより、特定タスクに特化した企業調査ツールを作ることの価値を確認情報源を与えるパターンで⼩さく作って検証

Slide 69

Slide 69 text

⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. 完璧を⽬指さない 5. クローラー実装時の注意点 69

Slide 70

Slide 70 text

完璧を⽬指さない ● ハルシネーションは0にはできない ● 全てAIで完結させるのではなく、⼈が⼊る前提で運⽤を組み、補助ツールの⽴て付けとする ○ ⼈がチェックしやすいように情報取得元のURL を添付 ○ AIの調査結果を元に、⾃分の⼿で⾁付けした⽅が企業理解が進むと⾔う事情もあり 70

Slide 71

Slide 71 text

⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. 完璧を⽬指さない 5. クローラー実装時の注意点 71

Slide 72

Slide 72 text

クローラー実装時の注意点 ● 対象サイトのrobots.txtを遵守する ○ クローリング可能な範囲、リクエスト間隔を守る ● サーバーへ負荷を与えない ○ 10秒以上のクールダウンが推奨 ○ Lambdaの同時実⾏数やSQSで多重度を制御可能 ● エラーハンドリングを適切に実装する ○ 無限ループ、意図せぬリクエスト増を防ぐ 72

Slide 73

Slide 73 text

まとめ 73

Slide 74

Slide 74 text

このセッションで話したこと 1. 構築したアプリ(企業調査ツール)の説明 2. 技術選定のポイント 3. ⽣成AIアプリ実装時のTips 74

Slide 75

Slide 75 text

まとめ ● LangChainで開発⼯数を⼤幅に削減できる ● インフラはサーバレスを推奨 ○ Lambda Function URLsだとシンプルな構成に ● AWSで作るならAmazon Bedrockの採⽤を推奨 ● ⽣成AIの組み込みは本当に必要な箇所のみ ● 最初は⼩さく検証を始める ● 全てをAIで完璧にこなそうとしない ● クローラーは節度を持って実装する 75

Slide 76

Slide 76 text

さらに⽣成AIを使いこなしたい⽅ ● ⼀歩進んだ活⽤⽅法のヒントを得る ● AI搭載アプリの開発に興味を持ってもらう既に⽣成AIをアプリに組み込んでいる⽅ ● 実装パターンの選択肢を増やす ● SlackBot、クローラー実装のノウハウを知るこのセッションのゴール 76

Slide 77

Slide 77 text

● ⼀緒に開発を進めていただいた ○ たにもんさん、あんでぃさん、さけさん ● 仕様‧運⽤の相談に乗っていただいた ○ スギヤマさん ● 検証‧フィードバックしていただいた ○ マッハチームのみなさん Special Thanks! 77