ここ数週間、無料枠で、小さなローカルモデルと小さなクラウドモデルの両方で、実際のマルチファイルのコーディングタスクを回してみました。そこで一貫して出てきた失敗ポイントを共有したいと思います。中には私が意外に思ったものもあったので、コミュニティにも共有して、誰かの役に立てばと思っています。
Markdown のフェンスは、私がテストしたあらゆる小規模モデルで最もよく起きる失敗です。
システムプロンプトに「"出力は生のコードのみ、Markdown 形式は使わないで"」と書けます。モデルはそれに同意します。それでも、特にコードを説明するような依頼が含まれる場合、モデルは結局のところ応答を三連バッククォートで囲んでしまいます。Qwen3.5:9b と gemma4:e4b は、この指示に従う点で最も一貫していますが、それでも時々すべります。私のテストにある他のモデルは、このルールを破る頻度が十分に高いので、基本的にフェンスが付いてくると考えざるを得ません。
解決策は、より良いプロンプトではありません。デフォルトでポスト処理としてフェンスを剥がすことです。小さなモデルを使うコード編集ツールなら、どれでもそれをやらないといけません。
私のテストでは、7B 未満のパラメータでは構造化出力は信頼できません。
あなたのエージェントが、タスクリスト（私の caase のように）、アクションタイプ、または何らかの機械可読なもののために、モデルに JSON を返させる必要があるなら、ベンチマークが示す以上に、小規模モデルはここで失敗する頻度が高いです。ベンチマークは、モデルが妥当な JSON を生成できるかどうかを測ります。しかし、エッジケースを含む複雑なマルチステップの指示を与えたときに、妥当な JSON を生成できるかどうかまでは測りません。
私のテストでは、ローカルモデルの中で構造化出力が最も信頼できたのは Gemma4:e4b でした。Qwen3.5:9B はそのすぐ後です。Codellama（古いものですが）は苦戦します。クラウド側では、Groq 上の Llama 3.3 70B が構造化出力に関して非常に堅牢でした（これが最も一貫していました）。たとえば OpenRouter の他のモデルでは、いくつか癖がありました。例：Nemotron 3 super はとても良かったのですが、OpenRouter で 100k トークン使用時に応答が止まりました。
実用的な回避策は、JSON を検証し、さらに明確な指示で 1 回だけリトライし、それでもダメなら、文章でラップされた応答から JSON を抽出できる寛容なパーサにフォールバックすることです。
あなたが許すと、モデルは間違ったファイルを編集します。
関数名に言及し、似た関数名の一覧（プロジェクトマップ）を含め、さらに「validateToken を verifyToken にリネームして」のような依頼をするタスクを小さなモデルに渡してください（これは私のテストからの実例です）。validateToken を正しくリネームするかもしれません。しかし validateUser もリネームするかもしれません。関数に言及しているコメントだけを変更するかもしれませんし、リネームをまったく別のファイルに適用するかもしれません。モデルはプロジェクトマップを提案として扱い、制約としては扱いません。
修正すべき場所はプロンプトではなく、オーケストレーション層です。モデルが挙げたファイルパスが実際に存在することを検証してください。モデルが動作していると主張する関数名が、モデルが「それらが入っている」と言うファイルの中に本当にあることを検証してください。不一致があれば明確なエラーを投げてください。小規模モデルは自信満々に嘘をつくので、それを信じない必要があります。
質問とアクションの分類は、思っているより難しいです。
「utils.js には何行あるか」と聞くのは読み取り専用の操作であるべきです。しかし、実行側が「このファイルを編集する」というモードしか持っていない場合、モデルはあなたの依頼を、知っている唯一のアクション（編集）として解釈するため、質問への答えをファイルに含めるように律儀に編集してしまいます。
解決策は、実行の前にプランナーが依頼をアクションタイプに分類することです。読み取り専用のクエリは、ディスクに一切触れない別のコードパスへルーティングします。これがないと、何気ない質問がファイルを削除し得ます。
予想よりうまくいったこと
呼び出しの前に、コードでトークン予算を強制すること。小規模モデルにはコンテキスト制限の概念がありません。「簡潔にするよう信じて任せれば大丈夫」と思っても、その通りにはなりません。制限の範囲内に実際に収める唯一の方法は、自分のコードでトークン数を数えて、長すぎるリクエストを送らないことです。
ファイル単位の分離。モデルに 1 ファイルずつ送るのは、2 ファイルを同じ呼び出しで送るより圧倒的に信頼性が高いです。同じ呼び出し内で 2 ファイル渡すと、小規模モデルが混乱してしまうことが驚くほどよくあります。どの修正がどこに行くべきかを取り違えます。
シンセシス（合成）型のメモリ。モデルが前回やったことを、全文のタスクリストではなく 1 文の要約として保存すると、次のターンで「undo」や「さらに X を追加して」のような要求を処理するのに十分な文脈が得られます。高度な仕組みは必要ありません。
まだ調べていること
7B 未満のローカルモデルが実際にエージェント役として使えるのか、それとも 7B が現実的な下限なのか、です。構造化出力が「使い物にならないほど」頻繁に失敗しない、もっと小さいモデルは見つけられていません。ツール使用や JSON 出力に特化して調整された小規模ファインチューンでうまくいった人がいるかどうか、気になります。
誰かが見たり貢献したりしたいなら、テスト用のハーネスをオープンソースにしました： github.com/razvanneculai/litecode
どんな助けでもとてもありがたいですし、あらゆる種類のフィードバックもぜひ欲しいです。
免責として、はい、英語が第一言語ではないので、自分のテキストの一部を AI で整形し直しています。そして、その情報はとても面白く、誰かの役に立つかもしれないと思っています。
[link] [comments]
