 | Appleのオンデバイス3Bモデル（Tahoe上のFoundationModels経由）をいじっていて、コードに近いタスクでどこまで通用するのか、その上限を探ってみました。具体的なベンチマークとしてシェルコマンド生成をテストしました（100個のプロンプト、約10通りのアプローチ） https://i.redd.it/ferxmyorh7ug1.gif 素のモデル：正解は約40%。主にフラグばかりで、コマンドの幻覚も少しあります。ドキュメントをコンテキストとして与えても効果はありませんでした。manページでも、tldrをドキュメントとしてでもダメで、自己批評のループもダメでした。どれもベースラインのノイズの範囲で、自己批評はむしろ悪化していました（33%）；モデルは「直そうとして」正しいコマンドを間違ったものにしてしまっていました。 うまくいったこと：tldrの21kのコミュニティ例から、FTS5によるダイナミックな少数ショット検索。使ったコーパスは同じで、参照資料としてではなく、コピーするための解けた例として言い換えました。きれいに分離したホールドアウトで、クエリあたり0.5秒のとき約70%。言い換えただけで30ポイントのジャンプです。精度は“銀行”のサイズに応じてスケールするので、より多く、より厳選された例を入れればさらに押し上げられます（カスタムの上書きで78%まで上げられました）。 また、自己整合性（temp 0.3、3サンプル、多数決）と、検索の上に重ねたCoTもテストしました。どちらも約3倍遅くなり、精度はほとんど動きませんでしたが、自己整合性は実行間のばらつきを大幅に潰しました。おそらく、これももう少し掘る価値があります。 まだ微調整（finetuning）は試していません。AppleはFoundationModelsでLoRAアダプタを許可しているので、次の明らかなレバーですが、配布がややややこしくなります。 まとめ：小さなオンデバイスモデルでは、コンテキストの中身より“どう見せるか”のほうが重要です。同じ21kの文字列でも、それがドキュメントとして提示されるのか、例として提示されるのかで30ポイント以上の差が出ます。ほかの方々も、Qwen 3B / Gemma 2B / Phi-3で同じ分岐が見られたでしょうか。 私が試したことを全部まとめた詳細： https://es617.dev/2026/04/08/apple-on-device-llm-shell.html CLIとベンチマークデータを含むリポジトリです。誰か試してみたいならどうぞ。 https://github.com/es617/hunch [link] [comments] |
Appleのオンデバイス3B LLMにおける動的な少数ショット検索：シェルコマンドで40% → 70%+
Reddit r/LocalLLaMA / 2026/4/10
💬 オピニオンSignals & Early TrendsTools & Practical UsageModels & Research
要点
- Appleのオンデバイス約3B LLMをシェルコマンド生成に用いる実験では、ベースラインの正確性は約40%で、ドキュメント風の文脈を追加しても結果は改善せず、自己批評がときには正確性を下げることもあった。
- 最大の改善は動的な少数ショット検索によるものだった。約21kのコミュニティTLDRコーパスからFTS5で関連例を引き当て、「コピーしてよい解決済み例」として提示することで、正確性は約70%+まで向上し、1クエリあたりの所要時間は約0.5秒だった。
- 正確性は取得した「銀行（バンク）」のサイズとキュレーションに応じてスケールし、著者はカスタムの上書き（オーバーライド）でさらに約78%まで改善できたと報告しており、小型オンデバイスモデルにとって検索品質が重要なレバーであることを示唆している。
- 自己一貫性（複数サンプル＋多数決）を追加し、さらに検索の上にCoT（連鎖的推論）を重ねると、レイテンシは約3倍に増えたが、全体としての正確性の向上は限定的だった。自己一貫性は主にばらつきを減らす効果が中心だった。
- 著者は、AppleがFoundationModels向けにLoRAアダプタをサポートしていることを次のステップになり得ると述べつつ、このタスクではベースとなるテキストよりもコンテキストの組み立て（フレーミング）がより重要になり得ることを強調している。
