スクリーンショットからコードを生成するプロセスは、新たなレベルに到達しました。

最新のフロントエンド コード向けの初の自己生成マルチモーダル ビッグ モデル ソリューションが登場しました。

そしてオープンソースです。

(注: 現代のフロントエンドコード開発は、コンポーネント化、状態管理、データ駆動型レンダリング、厳格な開発標準、強力な動的インタラクションを特徴としています。これらの特徴は相互に関連しており、現代のフロントエンド開発の複雑なシステムを構成し、React や Vue などのフレームワークに基づく開発など、コード生成に対する要求が高まっています。)

このモデルはFlameと呼ばれています。早速、結果を見てみましょう。

たとえば、スクリーンショットを撮り、AI に次のインターフェースを生成させます。

画像を「表示」した後、Flame モデルは次のコードを出力します。

Flame によって生成されたコードは、比較的明確な外部スタイルやモジュール式のコンポーネント構造など、最新のフロントエンド開発標準に明確に準拠していることが簡単にわかります。

一方、コンポーネントのさまざまな状態、イベント応答、データ駆動型の動的レンダリングは、コンポーネントの実装で正しく定義されていました。

ただし、 GPT-4oのような最先端 (SOTA) モデルであっても、設計図のエンドツーエンドの複製中に静的コンポーネントのみを生成することに制限されているため、最新のフロントエンド開発の中核要件に反する可能性があります。

たとえば、同じインターフェースの場合、GPT-4o のソリューションは次のようになります。

問題の根本は、このタイプの静的コードではモジュールアーキテクチャをサポートできず、動的な相互作用もサポートできないことです。

各コンポーネントは「一度限りの製品」です。小さな要件の開発と反復作業でも、開発者は大量のカスタマイズされたコードを作成したり、ゼロから作成したりする必要がある場合があります。

では、Flame モデルはこの問題をどのように解決するのでしょうか?

核心的な問題: データ不足

大規模なビジュアル言語モデル (LVLM) がプロフェッショナルなフロントエンド コードの生成でパフォーマンスが低い根本的な理由は、データの不足です。

現代のフロントエンド開発プロセスは非常に複雑です。例えば、Reactのようなフロントエンドフレームワークは、コンポーネント化、状態管理、データ駆動型レンダリングを重視しています。

これには、生成されたコードが使用可能であるだけでなく、開発標準に準拠し、動的かつ応答性を備えていることも必要です。

しかし、オープンソース コミュニティでは、フロントエンド開発をサポートする高品質の画像テキスト (コード) データセットが非常に不足しています。

WebSight のようなデータセットには静的 HTML のみが含まれるため、最新のフロントエンド開発には適していません。

高品質のトレーニング データを収集して構築するには、多くの課題があります。

• パブリックコードリポジトリから便利なコードスニペットを抽出するにはどうすればよいでしょうか?
• 元の外観を維持しながらコードをレンダリングするにはどうすればよいでしょうか?
• エンジニアの習慣に合った、多種多様なデータを大量に生成するにはどうすればよいでしょうか?

これらの問題に対処するために、Flame モデル チームはデータ合成という解決策を提案しました。

LVLM のフロントエンド コード生成機能を強化するために、フロントエンド開発シナリオで高品質のデータを生成するための完全な自己反映型インテリジェント ワークフローを設計しました。

このワークフローは、公開コード リポジトリから実際のデータを自動的に抽出できるだけでなく、データを自動的に合成してプロフェッショナルで多様なフロントエンド コードを生成することもできます。

チームは3つの合成方法を設計し、実装しました。

進化に基づく合成

WizardLMのEvol-Instructメソッドに着想を得て、ランダム進化を通じて多様なコードを生成します。幅広い進化と深い進化という2つの戦略を採用しています。

二重進化は、コードの機能と視覚的なスタイルを変更することで新しいバリアントを作成します。一方、深い進化は、技術的な複雑さを増大させ、コンポーネント処理、状態管理、およびパフォーマンスを最適化することで、コードの信頼性と保守性を向上させます。

継続的な進化を通じて、さまざまなニーズをカバーする大量のフロントエンドコードを取得できます。

ウォーターフォールモデルベースの合成

従来のソフトウェア開発におけるウォーターフォールモデルをシミュレートすることで、生成されるコード構造が明確で論理的に一貫性があることを保証します。要件分析から始まり、システムの機能要件を導出し、UIレイアウトとアーキテクチャを設計し、コードが現代のフロントエンド開発のモジュール性とスケーラビリティの要件を満たしていることを保証します。

次に、複数のイテレーションを経て、要件は具体的で再利用可能なフロントエンドコンポーネントとインターフェースへと変換されます。この手法によって生成されるコードロジックは明確で、複雑な機能の開発に適しています。

添加剤開発合成

既存のコードをベースに、機能と複雑さを段階的に追加していきます。状態管理、インタラクションロジック、APIなどの機能モジュールを段階的に統合することで、生成されたコードは実際の開発ニーズにより適したものになります。

このアプローチでは、コードの機能と複雑さを段階的に増やすことを重視し、各拡張が可能な限りベスト プラクティスに準拠するようにします。

上記の 3 つの方法は、データセットの規模と多様性を豊かにするだけでなく、データの品質と実用的なアプリケーションの価値も保証します。

これらの手法により、特定のフロントエンドフレームワーク向けに低コストで大規模なグラフデータの合成が可能になります。Flameチームはこれらの手法を用いて、Reactフレームワーク向けに40万件を超えるマルチモーダルデータセットを構築しました。

一方、ウォーターフォールモデルと増分開発方式は、マルチグラフシナリオでのデータ合成や視覚的な思考チェーンの合成もサポートし、より複雑なシナリオでのフロントエンドコード生成の可能性を広げます。

Flame: フロントエンド開発シナリオ向けの VLM

Flame チームは、80 個のテスト問題を含む高品質のテスト スイートを構築し、改良された Pass@k を使用して、マルチモーダル モデルのフロントエンド コード生成機能を評価しました。

生成されたコードがコンパイルおよび検証可能であり、コーディング標準に準拠しており、レンダリングされたページが入力設計図と十分に類似している場合、コードは要件を満たしていると見なされます。

評価結果によると、GPT-4oやGemini 1.5 Flashといった現在のトップモデルは、生成されるコードが主に静的コードであり、コーディング標準から大きく逸脱しているため、合格率が最大でもわずか11%にとどまっています。一方、Flameは同じ条件下で52%以上の合格率を達成し、大きな可能性を示しています。

一方、Flame はわずか約 20 万個のデータ ポイントで上記の結果を達成し、上記のデータ統合方法の価値と、マルチモーダル モデルの機能向上における高品質データセットの重要な役割をさらに検証しました。

△左：テスト画像、右：炎のレンダリング

トレーニングデータ、データ合成プロセス、モデル、テストセットはすべてオープンソース化されている点も特筆すべき点です。ご興味のある方はぜひご確認ください！

GitHub アドレス: https://github.com/Flame-Code...