https://yennj12.js.org/yennj12_blog_V4/tags/semantic-router/Recent content in Semantic Router on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 04 Jun 2026 17:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part24-hybrid-model-routing-zh/Thu, 04 Jun 2026 17:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part24-hybrid-model-routing-zh/為什麼用 Gemini Pro 回答「你好！」？ 用 Gemma-2b 回答「你好！」，品質幾乎一樣，成本低 20 倍。 問題不是「要不要用小模型」，而是「如何設計一個系統，讓正確的問題找到正確的模型」。 面試情境 面試官： 「客戶希望設計一個 Hybrid Model Routing 系統：70% 的簡單日常問候和格式轉換自動路由到 GKE 部署的 Gemma-7b；複雜推理和多步驟 Tool-calling 才路由到 Gemini 1.5 Pro。你如何設計這個路由器？如何用統計評估確保路由器不會因為誤判讓整體品質下滑？」 一、核心問題：路由器要解決什麼問題 不路由的世界（所有請求 → Gemini Pro）： 成本：$1.25/1M input tokens（Gemini 1.5 Pro） 延遲：平均 2~5 秒 路由後的世界： 70% 簡單請求 → Gemma-7b（自托管 GKE） 成本：近乎零（只有 GKE 運算成本，約 $0.05/1M tokens 等效） 延遲：0.2~0.5 秒（本地推理） 30% 複雜請求 → Gemini Pro 成本：$1.25/1M tokens 延遲：2~5 秒 整體節省：70% × 95% cost reduction = ~66% 成本降低 代價（路由器的風險）： 如果路由器誤判，把複雜問題送給 Gemma-7b → Gemma-7b 無法回答 → 錯誤答案 → 業務影響 → 品質下滑的代價 > 成本節省的收益 結論：路由器的設計核心是「確保誤判率在可接受範圍內」 二、路由器設計的三種方案 方案比較： Embedding-based LLM-based Router Rule-based Semantic Router (Gemini Flash) ────────────────────────────────────────────────────────────────────────── 決策速度 ~50ms ~300ms < 1ms 準確性 中等（依賴相似度） 高（LLM 理解語意） 低（規則有限） 維護成本 中（需要更新範例向量） 低（Few-shot 更新） 高（規則越來越多） 對新場景適應 差（未見過的範例命中率低） 好（LLM 泛化能力強） 差 成本 Embedding 費用（低） Gemini Flash 費用（低） 零 可解釋性 中（相似度分數） 高（可要求 LLM 解釋） 高（規則清楚） 適用場景 路由決策需要極快速度 品質優先 非常簡單的場景 推薦：雙層架構 Layer 1: Rule-based（極快速，處理明顯的情況） Layer 2: Semantic Router（處理 Layer 1 通過的請求） 三、完整路由架構設計 ┌──────────────────────────────────────────────────────────────┐ │ 用戶請求 │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Layer 1：Rule-based 快速路由（< 1ms） │ │ │ │ 明確路由到小模型（Gemma）： │ │ ├── 請求長度 < 50 tokens AND 無 Tool-calling 歷史 │ │ ├── 純問候語（pattern match） │ │ └── 格式轉換任務（JSON → CSV 等） │ │ │ │ 明確路由到大模型（Gemini Pro）： │ │ ├── 請求含 tool_calls 欄位（需要工具能力） │ │ ├── 請求長度 > 5,000 tokens（複雜上下文） │ │ └── 用戶明確標記為「高精度模式」 │ │ │ │ 不確定 → 進入 Layer 2 │ └──────────────────────────┬───────────────────────────────────┘ │ 不確定的請求 ▼ ┌──────────────────────────────────────────────────────────────┐ │ Layer 2：Semantic Router（~50ms） │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Embedding Model（text-embedding-004，輕量） │ │ │ │ → 將當前 Query 轉為向量 │ │ │ └─────────────────────────┬────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ In-memory Vector Index（FAISS 或小型向量快取） │ │ │ │ │ │ │ │ 「簡單任務」黃金範例： │ │ │ │ ├── "今天天氣怎樣？" │ │ │ │ ├── "幫我把這段文字翻譯成英文" │ │ │ │ └── "這個 JSON 格式對嗎？" │ │ │ │ │ │ │ │ 「複雜任務」黃金範例： │ │ │ │ ├── "分析這份合約的法律風險並給出建議" │ │ │ │ ├── "根據這些數據建立一個財務預測模型" │ │ │ │ └── "找出這段程式碼的 bug 並修復" │ │ │ └─────────────────────────┬────────────────────────────┘ │ │ │ │ │ ▼ │ │ 相似度分數： │ │ ├── 與「簡單任務」相似度 > 0.