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

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

Transcript

1. LLMエンジニアリングを加速させる ソフトウェアアーキテクチャ 株式会社Algomatic シゴラクAIカンパニー CTO takuya kikuchi
2. 自己紹介 Algomatic シゴラクAIカンパニー CTO 菊池 琢弥 / Takuya Kikuchi X: @_pochi フィンテックスタートアップにおいて開発リードや VPoEとして開発 組織構築を担当したほか、モバイルオーダープラットフォームを手 がけるShowcase GigではVPoTとして技術領域全般を管掌。 2023年、AlgomaticにカンパニーCTOとして参画。ソフトウェア開 発、設計、ドット絵が好き
3. 本日の内容 • 会社紹介 • シゴラクAIのご紹介 • 「LLMエンジニアリング」と不確実性 • シゴラクAIとLLMの半年間 • シゴラクAIがとるべきアーキテクチャの方向性 • まとめ
8. 社内ナレッジチャット機能 社内に散らばりがちなナレッジを元に、 AIアシスタントが応答してくれるチャット部屋を手軽に作れます
9. LLMエンジニアリングと不確実性
10. LLMエンジニアリングとは エンジニアリング： 何かを「実現」すること。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移して いく過程に行うすべてのこと * LLMエンジニアリング： LLMを活用していくための、あらゆる不確実性を減少させるための取り組み。 （プロンプトエンジニアリングも含まれる） * 広木大地 (2018) 『エンジニアリング組織論への招待』 技術評論社 https://amzn.asia/d/jiCxskG
11. シゴラクAIの開発を通して見えてきた、LLMの抱える「不確実性」 1. 技術的不確実性 2. 規制などの法的不確実性 3. ユースケースの不確実性
12. 1. 技術的不確実性 高い頻度での新モデル、新機能が登場する • GPT-4V, GPT-4 Turbo, DALL-E, Assistants API, etc… • コンテキスト長制限やコストの変化なども目まぐるしく変化している ◦ 現時点での工夫が、もしかすると半年後には不要になっているかも ... 開発プロセスを変化させるような周辺サービスも登場 • PromptFlow ◦ 開発〜評価〜デプロイのプロセスを一手に担う、 Azure上のサービス ◦ PromptFlowを活用する場合、RAGなどのアルゴリズム実装やプロンプトエンジニアリングはアプリ ケーションコードではなく PromptFlow側で行うことも可能となる • LangChain（これは古くからあるが） • etc…
13. 2. 規制など法的不確実性 データプライバシー、著作権 • トレーニングデータの著作権や、生成物に関する法的側面については各所で議論が進行中 • 日本国内でも「生成AIと知財」をめぐるリスク、懸念について目下議論が行われている : https://www.kantei.go.jp/jp/singi/titeki2/index.html • 今後、生成物に関してさらなるガイドラインが策定される可能性も考えられる 顧客の求める要件 • 「日本国外に情報を置きたくない」「外部に機密データを出していいのだろうか」といった懸念 ◦ 技術の黎明期は、こういった判断において個社ごとの振れ幅が大きい
14. 3. ユースケースの不確実性 LLMを活用する体験自体、まだまだ模索中 エンジニアにとっての GitHub Copilotのような、「手放せなくなる」体験とは何だろうか ◦ 社内、あるいは個人のナレッジを活用した「何か」 ◦ チャット欄に替わる「何か」
15. シゴラクAIとLLMの半年間
16. シゴラクAIの初期アーキテクチャ 極めてシンプルな構成で初期実装（ 5月ごろ）
17. シゴラクAIの現在のアーキテクチャ 11月末現在のすがた
18. ずいぶん重厚長大に見える • 開発人員の拡大に備えた？ • プロダクトの方向性が確立したので整備をした？ → より早く仮説検証を進めていくため のアーキテクチャ シゴラクAIの現在のアーキテクチャ
19. シゴラクAIリリース当初 シンプルにOpenAIのAPIを呼び出すだけの形。
20. シゴラクAIにRAG機能を搭載 「ドキュメントQ＆A機能」として、RAGを用いた機能をリリース。 PoCの意味合いが強かったため、 Chat機能の内部で処理分岐させる形で最短での実装
21. シゴラクAIでAzureOpenAIに対応 AzureOpenAIServiceでGPT-4が利用可能になったタイミングで、シゴラク AIでも対応を開始。 インフラ側で仕組みを構築し、 AOAIからOpenAIを呼び分ける処理を実装。
22. …そこから、さらに起きた出来事 プロダクトの機能改善案 • RAG機能の精度改善 • RAGの情報ソースをチャット画面に表示する • アルゴリズム改良に伴う従量課金額の検討 • ユーザープロンプトに含まれるリンク先を読み取って回答する • etc… 外部環境の変化 • Azure PromptFlow登場 • DALL-E 3、GPT-4-V、TTS • GPT-4-Turbo API　→　ほどなくしてAzure版も登場 • etc
23. シゴラクAIがとるべきアーキテクチャの方向性
24. シゴラクAIとして大事にしたいことを考え、アーキテクチャを段階的に改善 高速に価値検証を行っていきたい • UI改善による新たな体験の創出 • 回答エンジン（通常チャット、 RAG、Copilot、etc…）の新規実装、改良による価値創出 • 特定の実装技術に依存しない 特定のLLMに依存するリスクが高い。 モデルを柔軟に変更可能であることの価値も高い
25. シゴラクAIとして大事にしたいことを考え、アーキテクチャを段階的に改善 高速に価値検証を行っていきたい • UI改善による新たな体験の創出 • 回答エンジン（通常チャット、 RAG、Copilot、etc…）の新規実装、改良による価値創出 • 特定の実装技術に依存しない →　(1) コアドメインを互いに分離する アーキテクチャ設計 特定のLLMに依存するリスクが高い。 モデルを柔軟に変更可能であることの価値も高い →　(2) LLMを代替可能とするアーキテクチャ設計
26. (1) コアドメインを互いに分離させる シゴラクAIにおけるコアドメインは、 UIを含む「ユーザーとAIアシスタントとの対話」の体験
27. (1) コアドメインを互いに分離させる シゴラクAIにおけるコアドメインは、 UIを含む「ユーザーとAIアシスタントとの対話」の体験 UIは柔軟に変更したい 裏側の事情に左右されたくない AIの回答エンジンも柔軟に開発したい UIに依存したくない 各回答エンジンは、互いに無関係に開発したい
28. (1) コアドメインを互いに分離させる AIと人間のやりとりを「 ChatEngine」として抽象化 ChatEngine
29. (1) コアドメインを互いに分離させる UIや各回答エンジン（ChatEngine）はその抽象に依存させる
30. (2) LLMを代替可能とする LLM呼び出しをその他のロジックから分離することで、パーツとして手軽に切り替え可能とする 各回答エンジンは特定の LLMに依存せず切り替え可能とする
31. (2) LLMを代替可能とする ただし... 現実としては特定機能で GPT-4 Turboに依存している面はある （JSON Modeが非常に便利...） （一方で、JSON Mode未対応のLLMを使う場合であっても、自前処理でなんとかすることも可能ではある） 各回答エンジンは特定の LLMに依存せず切り替え可能とする
32. シゴラクAIのソフトウェアアーキテクチャ概念図
33. シゴラクAIのソフトウェアアーキテクチャ概念図 (1) コアドメインを互いに分離させる (2) LLMを代替可能とする
34. まとめ
35. まとめ LLMエンジニアリングで取り組む不確実性の話 • 技術的不確実性、規制などの法的不確実性、ユースケースの不確実性 不確実性に直面したシゴラク AIでの取り組み • 「シゴラクAIで大事にしたいこと」を実現するため のアーキテクチャ改善を実施 • コアドメインをそれぞれ分離する ◦ 「まず作ってみる」を加速させる ◦ 日々変わりゆく実装技術、開発手法に追随可能とする ◦ ユーザー体験の正解も模索し続ける • LLMを代替可能にする ◦ 特定のLLMに依存するリスクを低減したい ◦ ただし、現実的にはOpenAIの仕様にはやや依存しつつある ... ▪ JSON Modeは便利...