builder.ioでのLLMを使ったサービス開発の実際

builder.ioのSteve Sewell(CEO)が書いた「まだChat Completions APIで消耗してるの?」というトーンの記事を読んだ

builder.ioはQwikの開発元で知られるCMS SaaS(Qwikの話は出てこない)

www.builder.io

www.builder.io

記事はVisual CopilotというFigmaのデザインをReactコンポーネント等のコードに変換する機能の裏側について解説している

「FigmaをReactコンポーネントに変換!」だけだとプロ驚き屋アカウントに消費されて右から左に流れていきそうなニュースバリューだけど、昨今のLLMs App開発についての実践的なアーキテクチャの話とopinionatedなことが書かれているのが面白かったので紹介します

この2つの記事で言いたいことは「ChatGPTというハンマーが万能過ぎてすべてが釘に見えるけど、それぞれのタスクを分解して個別に解決した方が効率的」ということだと思う

ディープラーニング全盛(バズワードとして)の時にコンサルが「ディープラーニング以外で解決しましょう」と提案してもエグゼクティブにはあんまりウケないという状況のように、この記事も思ったほど話題になっていなかった(Hacker Newsには一応コメントが多数ある)

複数のLLMを連携させてAgentを作るという話題は活発だけど、実際にLLMを活用して現実のプロダクトにどうやって適用しているのかという部分に注目した

アーキテクチャ

Visual CopilotはFigmaからJSXなコンポーネントに変換するのに以下のパイプラインを辿る

https://www.builder.io/blog/train-ai

Identify imagesはデザイン上の画像を認識し、Build layout hierarchyはHTMLの構造解析、Apply stylesはCSSのスタイル情報、Turn to (basic) codeは内部コード表現(Mitosis?)の生成、Customize codeはそれをReactやSvelte形式に変換することだと思う

このうちIdentify imagesとBuild layout hierarchyをGoogle CloudのVertex AIで実装して、Apply stylesとTurn to (basic) codeはコードでロジック書いて、Customize codeは既存のLLMをファインチューニングして使っているらしい(時期的にgpt-3.5-turbo?)

またデータセットの運用が重要という話が出てくる。Visual Copilotでは人間が変換結果を確認してフィードバックして精度を高めていったらしい

記事の結論としては

  1. 最初に既存のLLM(例えばGPT-3やGPT-4)を使用してみる
  2. コストやカスタマイズ性の問題がある場合は、独自のモデルをトレーニングする
  3. データセットの運用で品質を上げる
  4. コードで実装できる個所は書く

という方法が推奨されている

Visual Copilotでは最後の工程のみをLLMで行い、その事前処理は従来の機械学習モデルと変換コードで実装された

感想パート

「Apply stylesとTurn to (basic) code」の変換処理実装するのEasyじゃねぇ・・ と思いつつも、それぞれを比較してこの人たちの能力から見ればそうなのでしょう

一見ChatGPT以前もそう作っていたのでは? と思うかもしれないけどGPTが汎用的に賢いので肝であるデータセットの自動生成のタスクにも役立つという環境の違いはあると思う

冷静に考えるとVertex AI便利話に読めるけど、この頃はGPTのVision APIも公開されていなかったので現在なら物体検知のプロトタイプを作るのは更に捗るのかもしれない

コストについては自前した方がOpenAIより優位だとは思うけどVertex AIを使っているのでそことの比較になってくるのでは…… と思った

コードで実装したぶんがLLM使わなかったので削減されたと解釈するべきか

Vertex AIは個人的に趣味でデプロイして使っていたことあるんですけど一晩のトレーニングで諭吉sが吹っ飛んだ経験があるので、あまりインディーデベロッパーの用途に優しい印象はない

安く使う方法があるのか代替手段があるのか是非読者にご教示いただきたい

今はGPUを買って自宅サーバーでやろうとしている