Jevを6回調整もClaudeのgrepに2倍差で敗北

著者の出発点は、Obsidianノートの抜粋を毎回のClaude Codeリクエストに注入するフックだった。直近14日間で2,333回発火し、1回あたり平均4,840文字を挿入したが、Claudeが自ら読んだのはVaultの0.9%だけで、読んだ154件のノートのうちフックの候補に含まれていたのはわずか3件だった。これによりコンテキスト選択が解決すべき課題となり、テキストではなく型付きの判断と確率を返すモデルであるJevが、その用途に安くて速い分類器として有望に見えた。

調整の経緯は、最終比較がなぜ重要だったかを示している。初期の試みは数百の候補に対してyes/noを問い、46%の確率で見逃した。リクエストテキストのみを分類する版は速かったが、正しいドメインを捉えたのは55%にとどまった。第3ラウンドでは全候補と直近の会話を対象に選択を行い、20件のリクエストで誤提案率0%を達成した。著者は後にこれを「出来すぎ」と呼んでいる。しきい値が同じ20件で選ばれていたからだ。テストが100件のリクエストと1,331の候補に拡大すると、この手法の誤り率は40%に上昇した。

その中で、Opusとgrepのベースラインは著者が求めるまで測定されていなかった。同じ100件のリクエストで、grepと会話コンテキストを使うOpusは52件の正しいノートを見つけたのに対し、Jevは24件だった。両者を組み合わせても件数は52件から54件に増えただけだった。Jevは誤提案率が低く（20%対Opusのトップピックの25%）、ノート不要のリクエストでの誤提案も少なかった。著者の結論は、Jevは狭く大量の分類やゲーティングのタスクに向く一方、ノート選定では会話中にすでに存在するコンテキスト対応モデルに勝つのは難しいというものだ。