生產環境中的模型路由：何時使用微調 vs API vs RAG

大多數生產 AI 系統不應該對每個請求使用單一方法。微調、RAG 和雲端 API 各有不同的成本結構、品質特性和理想用例。構建有利可圖 AI 功能的團隊使用這三種方法——將每個請求路由到最能處理它的方法。

這不是關於選擇一個贏家。而是關於建立一個路由系統，將每個請求與那個特定工作的正確工具匹配。

三種方法，簡單說明

微調模型： 在你的特定任務資料上訓練的小型語言模型（7B-14B 參數）。模型已經內化了你的用例的模式、格式和品質標準。它在本地或你的基礎設施上運行。費用：固定基礎設施，每次請求接近零費用。最適合：高流量、定義明確、重複性的任務。

RAG（檢索增強生成）： 一個通過檢索系統增強的模型，在生成回應之前提取相關文件或資料。模型不需要記憶一切——它查找需要的內容。費用：中等（嵌入費用 + 推理費用）。最適合：需要存取大型、不斷變化的知識庫的任務。

雲端 API（前沿模型）： GPT-4o、Claude Opus、Gemini Pro。可用的最大、最有能力的模型，通過 API 存取。費用：按 token 定價，每次請求費用最高。最適合：複雜推理、創意任務，以及任何原始模型能力最重要的事情。

每種都有明確的優勢和明確的限制。讓我們映射它們。

決策矩陣

以下是路由決策的框架：

這個矩陣給你起始點。但生產系統需要比靜態表格更精細的路由。

微調、RAG 和 API 如何相互補充

這三種方法不是競爭對手。它們解決同一問題的不同部分。

例子：一個客戶支援 SaaS 產品

這個產品有一個 AI 助手，幫助支援代理回覆票。不同類型的請求需要不同的方法：

第 1 層——微調模型（60% 的請求）：

• 分類票的優先級和類別
• 生成模板化確認回應
• 從票文本中提取客戶詳細資訊
• 根據情感建議回應語調
• 格式化回應以匹配品牌聲音

這些是高流量、定義明確的任務。微調的 7B 模型以 95% 以上的準確率處理它們，因為模式是一致的。費用：每次請求實際上為零。

第 2 層——RAG（25% 的請求）：

• 使用知識庫回答關於產品功能的問題
• 尋找在回應中連結的相關幫助文章
• 查找客戶特定的配置或帳戶詳細資訊
• 引用最近的政策更改或產品更新

這些任務需要存取會變化的信息——你的知識庫每週更新，客戶帳戶每天變化。微調無法跟上這種變化速度。RAG 檢索當前信息並生成基於其的回應。

第 3 層——雲端 API（15% 的請求）：

• 處理需要細緻推理的升級、複雜客戶投訴
• 為模型未見過的異常邊緣案例起草回應
• 分析長對話線程（10 條以上訊息）以摘要背景
• 為非標準問題生成創意解決方案

這些請求不頻繁，但需要前沿模型提供的推理深度。它們也是品質最重要的請求——升級的客戶投訴不是節省每次推理幾分錢的地方。

實施路由器

路由層不需要複雜。以下是三種實施模式，從簡單到複雜：

模式 1：基於端點的路由

將你的 API 端點直接映射到方法：

/api/classify     → 微調模型
/api/search-kb    → RAG 管道
/api/draft-reply  → 微調模型（標準）或雲端 API（升級）
/api/analyze      → 雲端 API

當你的任務類型通過端點清楚分離時，這很有效。大多數 SaaS 產品可以這樣清晰地分類其 AI 功能。

模式 2：基於屬性的路由

根據請求屬性路由：

if request.token_count < 500 and request.task_type in SIMPLE_TASKS:
    route_to_fine_tuned()
elif request.requires_knowledge_lookup:
    route_to_rag()
elif request.token_count > 2000 or request.task_type in COMPLEX_TASKS:
    route_to_cloud_api()
else:
    route_to_fine_tuned()  # 默認為最便宜的選項

默認始終是微調模型——最便宜且最快。只有在滿足特定條件時，請求才會升級到更昂貴的方法。

模式 3：級聯路由

首先嘗試最便宜的方法。如果品質檢查失敗，則升級：

1. 通過微調模型運行請求
2. 檢查輸出置信度/品質分數
3. 如果置信度高於閾值：返回回應
4. 如果需要知識查詢：通過 RAG 管道運行，返回回應
5. 如果置信度仍然低：通過雲端 API 運行，返回回應

這通過確保每個請求首先嘗試最便宜的路徑來最大化成本節省。權衡是延遲——通過所有三個層級的請求比在第 1 層解決的請求花費 3-5 倍的時間。對非同步工作負載使用此方法，其中延遲不那麼重要。

費用分析：路由 vs 單一方法

讓我們建模一個每月處理 30 萬次 AI 請求的 SaaS 產品：

單一方法：所有請求使用雲端 API

單一方法：所有請求使用 RAG

RAG 通過提供相關背景（需要更短的提示）略微降低成本，但你仍然按 token 支付生成步驟的費用。

路由：60% 微調，25% RAG，15% 雲端 API

路由方法比僅雲端 API 節省每月 AU$4,750（53%）。12 個月內節省 AU$57,000。

但真正的好處是擴展曲線。在每月 60 萬次請求時：

• 僅雲端 API：AU$18,000/月
• 路由：AU$5,800/月（微調基礎設施保持不變，只有 API 和 RAG 部分擴展）

RAG 何時優於微調

RAG 是正確選擇的時機：

你的知識庫變化比你能重新訓練的速度更快。 微調捕獲靜態知識。如果你的產品文件、定價、政策或客戶資料每週更改，微調模型立即落後。RAG 始終檢索當前信息。

你的語料庫太大，無法訓練進模型。 微調的 7B 模型可以有效地吸收大約 5,000-10,000 個文件模式。如果你需要引用 10 萬篇支援文章、產品規格或法律文件，帶向量資料庫的 RAG 是唯一可行的方法。

用戶詢問特定文件。 「我們合約的第 3.2 節說什麼？」是一個檢索問題，而不是生成問題。微調無法可靠地記憶特定文件。RAG 檢索確切的章節並生成基於它的回應。

你需要引用和可追溯性。 RAG 自然地為其答案提供源文件。微調模型從學習的模式生成——它們無法指向告知其回應的特定文件。

微調何時優於 RAG

微調勝出的時機：

任務是關於如何回應，而不是回應什麼。 分類、格式化、語調匹配、實體提取——這些是行為任務。模型需要學習一個模式，而不是查找信息。RAG 為這些任務添加不必要的檢索開銷。

延遲很重要。 本地硬體上的微調模型在 50-200ms 內回應。RAG 管道在生成開始之前為檢索添加 100-500ms。對於實時功能——自動完成、內聯建議、即時分類——檢索步驟太慢。

流量高且任務重複。 如果你每月處理 50 萬次分類請求，每次都有相同的模式，微調模型以固定費用處理它們。RAG 將添加 50 萬次嵌入查詢和 50 萬次向量搜索——對於不需要動態知識的任務，這是不必要的開銷。

你希望零每次請求費用。 在自有硬體上的微調模型，每次請求的邊際費用為零。即使使用本地模型進行生成，RAG 仍然有每次請求的嵌入和檢索費用（儘管這些很小）。

何時你真的需要雲端 API

誠實地評估何時需要前沿能力：

長背景推理。 處理 50 頁文件以回答第 12 節和第 47 節之間關係的特定問題，是一個 200B 以上參數模型帶 128K 背景視窗真正優於 7B 模型的任務。

零樣本新穎任務。 當你的 AI 遇到它未被訓練的請求類型時，前沿模型的廣泛能力比從未見過這個模式的微調專家更好地處理它。

帶工具使用的代理工作流程。 複雜的多步驟工作流程——跨多個來源研究答案、推理發現、制定計劃、執行它——仍然受益於前沿模型的深度。隨著較小模型在工具呼叫方面的改善，這將會改變，但今天差距是真實的。

品質關鍵、低流量的請求。 如果請求類型罕見（每月不足 100 次）且高風險（面向客戶、法律、金融），前沿模型每次請求 AU$0.05-0.10 的費用值得品質保證。

建立統一的路由層

你的路由層應該向你的應用程式呈現單一介面：

應用程式 → 路由層 → [微調 | RAG | 雲端 API] → 回應

應用程式不知道也不關心哪個後端處理了請求。它發送一個帶元資料（任務類型、優先級、用戶層）的請求，並以一致的格式接收回應。

實施要求：

• 跨所有三個後端的一致回應格式（在路由時規範化）
• 每次請求記錄使用哪個後端、延遲、token 數量和費用
• 備用邏輯——如果主要後端失敗或超時，路由到下一層
• A/B 測試支援——能夠將一定比例的流量路由到不同後端進行比較
• 費用儀表板——每個後端、每種任務類型、每個用戶層的聚合費用

這個記錄資料是驅動你路由優化的因素。30 天的生產資料後，你將確切看到哪些任務類型被過度服務（昂貴的後端，不需要高品質）和哪些被服務不足（便宜的後端，品質問題）。

迭代循環

路由不是設置後就不管的配置。它隨時間改進：

1. 第 1 個月： 保守地路由——比必要的流量更多到雲端 API。收集品質資料。
2. 第 2 個月： 分析品質資料。將微調模型處理得很好的任務類型從雲端 API 移到本地。
3. 第 3 個月： 將新的任務類型添加到微調訓練資料中。重新訓練。擴展本地路由。
4. 第 6 個月： 大多數穩定、高流量的任務在微調模型上。RAG 用於知識依賴的任務。雲端 API 用於邊緣案例和新功能。
5. 持續進行： 每個重新訓練週期將更多流量移到最便宜的層。

成熟 SaaS 產品的最終狀態通常是 60-80% 微調，15-25% RAG，5-15% 雲端 API。達到這個狀態需要 3-6 個月的迭代，但每個月都降低費用並改善路由準確性。

---

延伸閱讀

• 微調 vs RAG — 兩種方法的詳細比較
• 為客戶專案選擇微調 vs RAG — 在兩者之間選擇的實用指南
• SLM 微調用於文件處理 — 微調何時適用於文件密集型工作負載