【要約】"壊れた tool call はどこまで直せるか — 自作の修復器を定量ベンチにかけたら malformed で 14.3% だった話" [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
CodeRouterの開発者が、自社のコア機能である「Tool Calling修復器」の真の性能を疑い、定量的な評価指標を確立しようとした。従来の「だいたい直る」という体感値に頼った運用では、以下の課題に直面していた。
- ・修復器の有効範囲が不明確であり、定量的な評価ができていなかった。
- ・修復すべきでない正規のコードブロックを誤って削除する回帰バグが発生した。
- ・小型モデルが頻出させる「末尾カンマ」や「シングルクォート」等の構文エラーに対応できていなかった。
- ・「修復できる（Recall）」ことと「誤修復しない（Precision）」ことを同時に評価する仕組みが欠如していた。
// Approach
開発者が、修復器の「回収率」と「偽陽性」を同時に測定するため、二段構えのベンチマークを構築した。オフラインでの決定的な検証と、実モデルを用いたライブ検証を組み合わせる手法を採用している。
- ・L1ベンチマーク: 8カテゴリ55件のJSONLコーパスを用いた、決定的なオフライン検証を実施した。
- ・L2ベンチマーク: 実モデルに対し、CodeRouter経由と直結の比較を行うライブ検証を実施した。
- ・回帰ゲートの導入: negativeカテゴリを設け、誤修復（偽陽性）を監視する仕組みを構築した。
- ・実装の強化: 緩いJSONパースの導入と、キー名の別名マップ（name/tool等）の追加を行った。
// Result
開発者が、修復器の強化により実運用における失敗率を劇的に低減させることに成功した。ベンチマークに基づいた改善により、以下の成果が得られている。
- ・L1回収率の向上: malformedカテゴリの改善により、総合回収率を100%へ引き上げた。
- ・実運用fail率の低減: CodeRouter経由の失敗率を17.0%から1.0%へ削減した。
- ・モデル価値の証明: Qwen2.5-Coder:7Bにおいて、直結0%から経由100%への成功率向上を実現した。
- ・回帰防止の仕組み化: 誤修復を防ぐためのテストスイートをCIに組み込んだ。
Senior Engineer Insight
> 小型モデルをプロダクション環境で運用する場合、この修復層は信頼性を担保する「最後の砦」となる。ただし、修復器は万能ではない。Gemma 4の例に見られる「空応答」は修復不能であり、モデルの切り替え（fallback）戦略と組み合わせる必要がある。また、修復器の改善が「偽陽性」を招かないよう、PrecisionとRecallを同時に監視する体制が、ミドルウェア開発における生命線である。