【要約】LLMルーターの自動プロファイル選択をrule-basedでどこまでやるか—CodeRouter v1.6 auto_router [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMを用いた自動分類には、以下の技術的課題がある。
- ・常駐プロセス増加による運用監視コストの増大。
- ・初回リクエストへの200〜500msのレイテンシ追加。
- ・誤判定時にストリームを巻き戻せない問題。
- ・分類理由が不明透明なブラックボックス化。
- ・「ログ＝観測の単一ソース」という設計哲学との乖離。
// Approach
解釈可能性と低レイテンシを優先し、以下の設計を導入した。
1.**Precedence設計**: 既存の明示的な指定を優先し、
default_profile: auto の場合のみ auto_router を発火。2.**Matcherの限定**:
has_image, code_fence_ratio, content_contains, content_regex の4種に絞り、DSL化を回避。3.**Bundled Rules**: 画像検知（
multi）とコード密度（code_fence_ratio >= 0.3）の2本を実装。4.**Fallback**: 未一致時は
writing プロファイルへ。5.**Error Handling**: 設定不備を起動時に検知する
fast-fail 方式を採用。// Result
複雑な条件を排除し、現実のリクエストの9割をカバー。ログに rule_id や signals を含めることで、ダッシュボードでの事後分析を可能にした。また、全ルール不一致時は auto-router-fallthrough イベントを吐き、改善の指標とする。
Senior Engineer Insight
>
極めて実践的な設計である。LLMによる分類という「精度」の誘惑を、レイテンシと観測性の観点から切り捨てた判断を高く評価する。決定論的なルールベースは、大規模運用における「なぜこの挙動になったか」という問いへの回答を保証する。閾値0.3を実測値から導出するプロセスも、エンジニアリングの正当性を示している。運用フェーズを見据えたfast-failやメトリクス設計も、プロダクション品質である。