LLMと生きていくための アーキテクチャ 2024/10/5 YAPC函館 U25 LT かっか

自己紹介: かっか(@kakka_q) 修士 -> 某AI企業(小田原リモート男) 社会人2年目 ソフトウェアエンジニア 技術スタック：Python・Go・TS・Azure(Terraform)・ML 趣味：Open the futureなスマホを使うこと(GMSのないスマホや折りたたみスマホ も...) 推しツール：Arc, Kagi Search, ast-grep, ghq

YAPC函館の参加理由 ● YAPC広島をSNSで見て参加したいと思った ● はこだて未来大学を志望校にしようとした時期もあり、来てみたかった ● U25支援があった！！！ ● U25支援があった！！！ ● U25支援があった！！！

LLMの進歩を無視して未来は語れない ● Transformerのスケール則が見つかってから異常な速度で進歩 ● 未来のソフトウェア開発を語る上で外せないトピック ○ Github Copilotが出る前とは段階的な変化がある 今回は ● アーキテクチャ内の LLMの立ち位置 ● LLMからアーキテクチャへの影響 について考えてみる

アーキテクチャ内のLLM ● アルゴリズムモジュールとしてのLLM（AI） ○ 検索・推薦 ○ 翻訳・要約 ● オーケストレーターとしてのLLM（AI） ○ ソフトウェアのI/Fが自然言語に ○ いわゆるAI Agent

アーキテクチャ内のLLM ● アルゴリズムモジュールとしてのLLM（AI） ○ 検索・推薦 ○ 翻訳・要約 ● オーケストレーターとしてのLLM（AI） ○ ソフトウェアのI/Fが自然言語に ○ いわゆるAI Agent 今回はこっち！！

AI Agent ● 与えられたタスクに対して自立的にプラ ンニングと実行を行う ● Agent自身がコードを実装するケースも あれば、他の処理を呼び出すケースもあ る ● LangChainはチェーンでLLM自身が考え て別サービスを呼び出すなどタスクを自 動的に解決

ぐっと睨みつけると...

AI Agentここでは？？ LLM Agent

似た感じで書けそう？？ Controller ● 事前にエンドポイントを公開し、 UseCaseと紐 づける ● リクエストをハンドリングし、 UseCaseに処理 を委譲 AI Agent ● 自然言語のインターフェースを持ち、事前に 連携ツールと紐づける ● 自然言語を解析し、最適なツールに適切な パラメータで処理を委譲

これはAI is eating software の香り... 1. 普通にアプリケーションをDomainとUseCaseまで作る 2. ToolがUseCaseをDIしAgentから呼び出すことで、ソフトウェアをアーキテクチャ 的にAIが食う 3. アプリケーション側でvalidationできるので、LLMが間違えてバルスしても破綻し ないのでは？？

じゃあ、やってみよう

taMeLL - 家計簿アプリ - 命名はLLM eatのアナグラム - コンビニ飯すぎて食費がやばかったので、家計簿を作ろう！ - あるサイトによると一週間でこれぐらいの予算だと食費2万ぐらいらしい - 肉・魚・タンパク質: 1500円 - 野菜: 1500円 - 調味料: 500円

アーキテクチャ WebSocket チャット対話 豚肉を399円で今日買 いました！ chat taMeLL LLMAgent domain usecase HTTP ツール化

NotionをDBに持つという暴挙

購入品をDBに登録するTool toolは UseCaseを 呼び出して いるだけ

demo

LLMからアーキテクチャへの影響 ● エンジニアはLLMの恩恵を受けて開発生産性を高めている ○ Github Copilot, Cursor ● バズワード化したLLM機能に対する市場の強い関心 より少ない開発人数 で素早く、柔軟で、ロバストに 機能をデリバリーする必要

クリーンアーキテクチャを採用すると？

直面する課題 ● LLMの得意な書き方と相反する ○ ペライチは簡単だが、複雑な依存関係がファイルを横断すると途端に精度が落ちる ● 開発人数が減る中、分かりきっている冗長な詰め替え処理を粛々と行う ● 市場からの要望と速度の圧 ○ LLMでブーストした世の開発スピードについていく必要 ○ AIで何かする系の機能は技術が枯れてないので、時にはダイナミックな修正が必要 ■ 抽象化の難易度とコードが生きてる期間の ROIが合わない 総じて重厚・冗長過ぎて速度が出ない

ソフトウェア品質とアーキテクチャ ● 「依存性逆転の法則」はめっちゃ偉いが、、、 ● 大事な特性とそれに合うソフトウェア品質を比較すると、テスト容易性にしか効 いてない？？ ● オーバーエンジニアリングな可能性 使いたい時に使える 高可用性・高信頼性 コア機能のクオリティが高い 高機能適合性・高使用性 デリバリーが速い(イテレート しやすい) 高敏捷性・テスト容易性・デ プロイ容易性

プロダクトを未来に連れていくためには？ ● LLMで好き勝手できる部分とコアドメインを分離する ● トランザクションスクリプト ○ 依存関係が少なく、Readのみの箇所をモジュールとして独立させ LLMの幅を効かせる ○ データ構造も半構造化データを使うなど上手にサボる ● Always-Valid Domain Model ○ Validationされたデータのみが扱われる Commandなどが呼ばれる箇所 ○ 不正な状態が存在し得ないようにドメインモデルを定義することで、ビジネスロジックの厳密性 を確保する ○ モデルが半構造化データを受け取る場合でも、 I/Fは厳密に取る

おわりに ● LLMむず過ぎる... ● 今回はLLMの性能を楽観視した話 ● 悲観視した話や他にあり得る未来の話 もしたいので、声をかけてもらえると嬉し いです！