Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LLMエンジニアリングを加速させるソフトウェアアーキテクチャ

 LLMエンジニアリングを加速させるソフトウェアアーキテクチャ

2023-11-29 【JDLA後援】実践LLMエンジニアリング でのLT資料です

takuya kikuchi

November 29, 2023
Tweet

More Decks by takuya kikuchi

Other Decks in Technology

Transcript

  1. LLMエンジニアリングを加速させる
    ソフトウェアアーキテクチャ
    株式会社Algomatic
    シゴラクAIカンパニー CTO
    takuya kikuchi

    View full-size slide

  2. 自己紹介
    Algomatic シゴラクAIカンパニー CTO
    菊池 琢弥 / Takuya Kikuchi
    X: @_pochi
    フィンテックスタートアップにおいて開発リードや
    VPoEとして開発
    組織構築を担当したほか、モバイルオーダープラットフォームを手
    がけるShowcase GigではVPoTとして技術領域全般を管掌。
    2023年、AlgomaticにカンパニーCTOとして参画。ソフトウェア開
    発、設計、ドット絵が好き

    View full-size slide

  3. 本日の内容
    ● 会社紹介
    ● シゴラクAIのご紹介
    ● 「LLMエンジニアリング」と不確実性
    ● シゴラクAIとLLMの半年間
    ● シゴラクAIがとるべきアーキテクチャの方向性
    ● まとめ

    View full-size slide

  4. 社内ナレッジチャット機能
    社内に散らばりがちなナレッジを元に、 AIアシスタントが応答してくれるチャット部屋を手軽に作れます

    View full-size slide

  5. LLMエンジニアリングと不確実性

    View full-size slide

  6. LLMエンジニアリングとは
    エンジニアリング:
    何かを「実現」すること。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移して
    いく過程に行うすべてのこと *
    LLMエンジニアリング:
    LLMを活用していくための、あらゆる不確実性を減少させるための取り組み。
    (プロンプトエンジニアリングも含まれる)
    * 広木大地 (2018) 『エンジニアリング組織論への招待』 技術評論社
    https://amzn.asia/d/jiCxskG

    View full-size slide

  7. シゴラクAIの開発を通して見えてきた、LLMの抱える「不確実性」
    1. 技術的不確実性
    2. 規制などの法的不確実性
    3. ユースケースの不確実性

    View full-size slide

  8. 1. 技術的不確実性
    高い頻度での新モデル、新機能が登場する
    ● GPT-4V, GPT-4 Turbo, DALL-E, Assistants API, etc…
    ● コンテキスト長制限やコストの変化なども目まぐるしく変化している
    ○ 現時点での工夫が、もしかすると半年後には不要になっているかも ...
    開発プロセスを変化させるような周辺サービスも登場
    ● PromptFlow
    ○ 開発〜評価〜デプロイのプロセスを一手に担う、 Azure上のサービス
    ○ PromptFlowを活用する場合、RAGなどのアルゴリズム実装やプロンプトエンジニアリングはアプリ
    ケーションコードではなく PromptFlow側で行うことも可能となる
    ● LangChain(これは古くからあるが)
    ● etc…

    View full-size slide

  9. 2. 規制など法的不確実性
    データプライバシー、著作権
    ● トレーニングデータの著作権や、生成物に関する法的側面については各所で議論が進行中
    ● 日本国内でも「生成AIと知財」をめぐるリスク、懸念について目下議論が行われている :
    https://www.kantei.go.jp/jp/singi/titeki2/index.html
    ● 今後、生成物に関してさらなるガイドラインが策定される可能性も考えられる
    顧客の求める要件
    ● 「日本国外に情報を置きたくない」「外部に機密データを出していいのだろうか」といった懸念
    ○ 技術の黎明期は、こういった判断において個社ごとの振れ幅が大きい

    View full-size slide

  10. 3. ユースケースの不確実性
    LLMを活用する体験自体、まだまだ模索中
    エンジニアにとっての GitHub Copilotのような、「手放せなくなる」体験とは何だろうか
    ○ 社内、あるいは個人のナレッジを活用した「何か」
    ○ チャット欄に替わる「何か」

    View full-size slide

  11. シゴラクAIとLLMの半年間

    View full-size slide

  12. シゴラクAIの初期アーキテクチャ
    極めてシンプルな構成で初期実装( 5月ごろ)

    View full-size slide

  13. シゴラクAIの現在のアーキテクチャ
    11月末現在のすがた

    View full-size slide

  14. ずいぶん重厚長大に見える
    ● 開発人員の拡大に備えた?
    ● プロダクトの方向性が確立したので整備をした?
    → より早く仮説検証を進めていくため のアーキテクチャ
    シゴラクAIの現在のアーキテクチャ

    View full-size slide

  15. シゴラクAIリリース当初
    シンプルにOpenAIのAPIを呼び出すだけの形。

    View full-size slide

  16. シゴラクAIにRAG機能を搭載
    「ドキュメントQ&A機能」として、RAGを用いた機能をリリース。
    PoCの意味合いが強かったため、 Chat機能の内部で処理分岐させる形で最短での実装

    View full-size slide

  17. シゴラクAIでAzureOpenAIに対応
    AzureOpenAIServiceでGPT-4が利用可能になったタイミングで、シゴラク AIでも対応を開始。
    インフラ側で仕組みを構築し、 AOAIからOpenAIを呼び分ける処理を実装。

    View full-size slide

  18. …そこから、さらに起きた出来事
    プロダクトの機能改善案
    ● RAG機能の精度改善
    ● RAGの情報ソースをチャット画面に表示する
    ● アルゴリズム改良に伴う従量課金額の検討
    ● ユーザープロンプトに含まれるリンク先を読み取って回答する
    ● etc…
    外部環境の変化
    ● Azure PromptFlow登場
    ● DALL-E 3、GPT-4-V、TTS
    ● GPT-4-Turbo API → ほどなくしてAzure版も登場
    ● etc

    View full-size slide

  19. シゴラクAIがとるべきアーキテクチャの方向性

    View full-size slide

  20. シゴラクAIとして大事にしたいことを考え、アーキテクチャを段階的に改善
    高速に価値検証を行っていきたい
    ● UI改善による新たな体験の創出
    ● 回答エンジン(通常チャット、 RAG、Copilot、etc…)の新規実装、改良による価値創出
    ● 特定の実装技術に依存しない
    特定のLLMに依存するリスクが高い。
    モデルを柔軟に変更可能であることの価値も高い

    View full-size slide

  21. シゴラクAIとして大事にしたいことを考え、アーキテクチャを段階的に改善
    高速に価値検証を行っていきたい
    ● UI改善による新たな体験の創出
    ● 回答エンジン(通常チャット、 RAG、Copilot、etc…)の新規実装、改良による価値創出
    ● 特定の実装技術に依存しない
    → (1) コアドメインを互いに分離する アーキテクチャ設計
    特定のLLMに依存するリスクが高い。
    モデルを柔軟に変更可能であることの価値も高い
    → (2) LLMを代替可能とするアーキテクチャ設計

    View full-size slide

  22. (1) コアドメインを互いに分離させる
    シゴラクAIにおけるコアドメインは、 UIを含む「ユーザーとAIアシスタントとの対話」の体験

    View full-size slide

  23. (1) コアドメインを互いに分離させる
    シゴラクAIにおけるコアドメインは、 UIを含む「ユーザーとAIアシスタントとの対話」の体験
    UIは柔軟に変更したい
    裏側の事情に左右されたくない
    AIの回答エンジンも柔軟に開発したい
    UIに依存したくない
    各回答エンジンは、互いに無関係に開発したい

    View full-size slide

  24. (1) コアドメインを互いに分離させる
    AIと人間のやりとりを「 ChatEngine」として抽象化
    ChatEngine

    View full-size slide

  25. (1) コアドメインを互いに分離させる
    UIや各回答エンジン(ChatEngine)はその抽象に依存させる

    View full-size slide

  26. (2) LLMを代替可能とする
    LLM呼び出しをその他のロジックから分離することで、パーツとして手軽に切り替え可能とする
    各回答エンジンは特定の LLMに依存せず切り替え可能とする

    View full-size slide

  27. (2) LLMを代替可能とする
    ただし... 現実としては特定機能で GPT-4 Turboに依存している面はある (JSON Modeが非常に便利...)
    (一方で、JSON Mode未対応のLLMを使う場合であっても、自前処理でなんとかすることも可能ではある)
    各回答エンジンは特定の LLMに依存せず切り替え可能とする

    View full-size slide

  28. シゴラクAIのソフトウェアアーキテクチャ概念図

    View full-size slide

  29. シゴラクAIのソフトウェアアーキテクチャ概念図
    (1) コアドメインを互いに分離させる
    (2) LLMを代替可能とする

    View full-size slide

  30. まとめ
    LLMエンジニアリングで取り組む不確実性の話
    ● 技術的不確実性、規制などの法的不確実性、ユースケースの不確実性
    不確実性に直面したシゴラク AIでの取り組み
    ● 「シゴラクAIで大事にしたいこと」を実現するため のアーキテクチャ改善を実施
    ● コアドメインをそれぞれ分離する
    ○ 「まず作ってみる」を加速させる
    ○ 日々変わりゆく実装技術、開発手法に追随可能とする
    ○ ユーザー体験の正解も模索し続ける
    ● LLMを代替可能にする
    ○ 特定のLLMに依存するリスクを低減したい
    ○ ただし、現実的にはOpenAIの仕様にはやや依存しつつある ...
    ■ JSON Modeは便利...

    View full-size slide