AutoBe: 弱いローカルLLMがAIバックエンドジェネレータのアーキテクチャをどう修正したか

何が起きたのか

AutoBeは、TypeScript、NestJS、Prismaを使用して完全なバックエンドアプリケーションを生成するオープンソースのAIエージェントです。当初は100%のコンパイル成功を達成しましたが、コードは保守不可能でした。コードの再利用がなく、小さな変更でもすべてを再生成する必要があったのです。チームはモジュールコード生成を中心にシステムを再構築し、すぐに成功率を40%に急落させました。

デバッグの突破口

新しいアーキテクチャがモジュール間の依存関係を導入したとき、チームは意図的に弱いローカルLLMを使用して、存在すら知らなかったバグを見つけました。qwen3-30b-a3b-thinkingモデルは約10%の成功率で、ASTスキーマの曖昧さや不正な構造を明らかにしました。qwen3-next-80b-a3b-instructモデルは約20%の成功率で、ネストされた関係における型の不一致やエッジケースを明らかにしました。

その低い成功率は価値がありました。各修正がシステム全体を強化したのです。スキーマが30Bモデルでも誤解できないほど正確であれば、より強力なモデルも間違えません。このアプローチはまた、ローカルLLMのコスト優位性を強調しています。エッジケースを発見するには何百もの生成-コンパイル-診断サイクルが必要であり、クラウドAPIの価格では法外に高くつくでしょう。

アーキテクチャの転換

チームはプロンプトエンジニアリングから、検証フィードバックを伴うスキーマ設計へと移行しました。システムプロンプトをほとんどなくし、すべての制約を関数呼び出しスキーマに移動させ、検証フィードバックに教育を任せました。AutoBeは、LLMが生成するのが特に難しい3つのASTタイプを使用しています。AutoBeDatabase（Prismaモデル、関係、インデックス）、AutoBeOpenApi（OpenAPIスキーマ、エンドポイント、DTO）、AutoBeTest（30以上の式タイプ）です。

これらの構造は、無制限の共用体型、無制限の深さ、再帰的参照を含むため困難です。例えば、コンパイラASTには、IExpression[]への再帰的参照を含むIArrayLiteralExpressionやIObjectLiteralExpressionのような型があります。

結果

検証フィードバックのみを通じて、チームは6.75%の生の関数呼び出し成功率から100%に改善しました。現在はGLM v5で再び100%の成功率に戻り、他のローカルモデルも性能を向上させています。