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

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

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

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

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

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

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

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

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

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

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

シゴラクAIとLLMの半年間

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

takuya kikuchi

More Decks by takuya kikuchi

Other Decks in Technology

Featured

Transcript