Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
LLMエンジニアリングを加速させるソフトウェアアーキテクチャ
Search
takuya kikuchi
November 29, 2023
Technology
2
5.3k
LLMエンジニアリングを加速させるソフトウェアアーキテクチャ
2023-11-29 【JDLA後援】実践LLMエンジニアリング でのLT資料です
takuya kikuchi
November 29, 2023
Tweet
Share
More Decks by takuya kikuchi
See All by takuya kikuchi
生成AI時代のソフトウェアエンジニアが持つべきケイパビリティを考える
tkikuchi1002
8
5k
RAGをテーマに考える、LLMの認知アーキテクチャとソフトウェア設計
tkikuchi1002
3
1.2k
生成AIの不確実性と向き合うためのオブジェクト指向設計
tkikuchi1002
3
6.6k
Azure AI SearchとPromptFlowではじめるRAG
tkikuchi1002
2
1.3k
法人向けChatGPTにおける Azure OpenAI Serviceの課題解決の過程と現在
tkikuchi1002
2
2k
WebAPIのバリデーションを、型の力でいい感じにする
tkikuchi1002
0
74
GoとDDDでモバイルオーダープラットフォームを 型安全に作り直した話
tkikuchi1002
0
89
Kotlinのcoroutine、async/awaitと同じでしょ?って思ってたけど意外と洗練されててすごいなぁって思った話をさせてほしい
tkikuchi1002
0
99
使いやすいインターフェースについて考える
tkikuchi1002
0
32
Other Decks in Technology
See All in Technology
コンテナセキュリティのためのLandlock入門
nullpo_head
2
320
C++26 エラー性動作
faithandbrave
2
730
AWS re:Invent 2024で発表された コードを書く開発者向け機能について
maruto
0
190
開発生産性向上! 育成を「改善」と捉えるエンジニア育成戦略
shoota
2
340
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
120
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
220
TSKaigi 2024 の登壇から広がったコミュニティ活動について
tsukuha
0
160
DUSt3R, MASt3R, MASt3R-SfM にみる3D基盤モデル
spatial_ai_network
2
110
マイクロサービスにおける容易なトランザクション管理に向けて
scalar
0
120
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
38k
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
tomoki10
0
450
KubeCon NA 2024 Recap: How to Move from Ingress to Gateway API with Minimal Hassle
ysakotch
0
200
Featured
See All Featured
Site-Speed That Sticks
csswizardry
2
190
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Unsuck your backbone
ammeep
669
57k
It's Worth the Effort
3n
183
28k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Designing for humans not robots
tammielis
250
25k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
440
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Transcript
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がとるべきアーキテクチャの方向性 • まとめ
None
None
None
None
社内ナレッジチャット機能 社内に散らばりがちなナレッジを元に、 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は便利...