カスタムAIモデルを使用してください。 私は数週間、Azure A100で8B～30Bのコーディングモデルをテストしてきました。 私たちのアーキテクチャを変革したモデルは？ 137Mパラメータで、M2 Pro Mac mini上で3分35秒で学習済み。 MicrosoftのFastContextがボトルネックを明らかにしました： リポジトリの探索がコーディングエージェントのトークンの46.5％を消費する可能性があるということです。 彼らが公開した実験では、メインエージェントの使用量を最大60.3％削減しました。 私はDeltaCodeでこのアイデアをさらに進化させました： → Goが合法的なリポジトリコンテキストを列挙 → カスタム137Mランカーがルーチン選択を処理 → FastContext 4Bは曖昧なREAD/GLOB/GREP探索のみを処理 → カスタムQwen3 4Bがコーディングの事前チェックを実行 → 高コストモデルには、全体のリポジトリではなく圧縮された証拠のみが提供される → コンパイラとテストが最終的な権限を保持 私のカスタムランカーは以下の成果を達成： • 57.97%のSealed Recall@5 • 標準モデルより+5.80ポイント向上 • Recall@1で+14.49ポイント向上 • ルーティングされた外部ケースでのRecall@5は73.33% • 実行権限は0 効率の差は圧倒的です： • 4Bエクスプローラーより96.6%少ないパラメータ • 27B～30Bモデルより99.5%少ないパラメータ • 使用されたパラメータのうち0.3225%のみが学習済み • したがってベースの99.68%は凍結されたまま • このアダプターにはA100のコストを完全に回避 • キャスケードがルーチンリポジトリ検索をローカルで処理すれば、クラウドコンテキストトークンは推定35～55%削減* 大規模モデルが失敗したのは、知性が不足していたからではありません。 失敗したのは、1つのモデルに探索・推論・フォーマット・コーディング・ツール操作・自己検証というすべてを要求したからです。 小規模モデルが勝ったのは、それぞれが1つの測定可能なタスクしか持たなかったからです。 私は高コストなA100実験を通じて、本番環境で高コストな計算リソースを必要としない方法を学びました。 コーディングエージェントの未来は、巨大な1つのLLMではなく、 1つのタスクに特化した小さなスペシャリストのチームかもしれません。 それぞれが独立して測定され、最終的な権限は一切与えられない。