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

by takuya kikuchi

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

シゴラクAIとLLMの半年間

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

まとめ

Slide 35

Slide 35 text

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