Coding Agentを「仕事になるか」で測る

Local LLMの比較では、モデルを読み込めたか、何tokens/sで生成できたかがよく測られます。これらは重要な基礎値です。しかしCoding Agentとして使うなら、速く文章を生成することと、正しい変更を最後まで完了することは同じではありません。

へつほつでは「このモデルは速いか」だけでなく、「この環境で、この仕事を、どこまで任せられるか」を測ります。

完了を分解する

一つのタスクを、少なくとも次の段階に分けて記録します。

• 指示とリポジトリ構造を理解したか
• 関係するファイルと既存の制約を見つけたか
• 変更が要求を満たしているか
• テスト、lint、typecheckを実行し、結果を扱えたか
• 不要な変更や危険な操作を避けたか
• 人が何回、どの程度介入したか

最後の回答が自然でも、テストが失敗したままなら完了とは扱いません。逆に時間がかかっても、正確に完了し、人の修正が少ないなら実用上の価値があります。

失敗にも種類がある

「失敗」を一つの数にまとめると、買う側が原因を判断できません。メモリ不足でモデルが動かなかったのか、contextが足りず要件を落としたのか、ツール操作を誤ったのか、単純に時間切れだったのかを分けます。

同じモデルでもruntimeや量子化、context長で挙動は変わります。そのためモデル名だけで結論を出さず、実行条件を結果と一緒に残します。

比較の単位を固定する

最初の検証では、公開可能な小さなリポジトリと文書セットを用意し、バグ修正、機能追加、テスト追加、説明の作成など、性質の異なるタスクを複数回実行します。

タスク、入力、合格条件、実行回数を先に固定し、成功例だけを選びません。平均値だけでなく、ばらつきと失敗内容を見せることで、日常の仕事へ持ち込んだときの期待値を判断しやすくします。