支援機器人模型路由：低成本 FAQ 處理

Cheap-first 模型路由將日常支援問題送往小型、低成本模型，並將挑選出的困難或不確定請求升級至更強大的模型。只要較便宜的路徑符合您的支援需求，即可降低為每則訊息使用高效能模型的成本。應用層面上的三種模式為靜態規則、分類器分類以及帶信心閾值的答案檢查。

本指南比較三種模式，說明 OpenRouter 處理流程的哪些部分，並以可複製的請求示範支援流程，最後列出在加入升級前需要衡量的指標。

Tl;dr

• 對於狹窄且易辨識的 FAQ，使用靜態規則；對於以多樣措辭表達的穩定類別，使用分類器分類；對於應先由低成本模型嘗試回覆的情境，使用答案檢查。
• 將支援政策的接受檢查保留在您的應用程式中。模型回退僅處理請求錯誤。若答案雖成功卻不正確，需在程式碼中做獨立的升級決策。
• 將 cheap-first 與僅使用 cheap 及僅使用更強模型進行比較，評估答案接受率、包含棄用嘗試的總成本、升級率與完整回合延遲。
• 僅在評估顯示能修復失敗時加入升級。若升級取代已可接受的低成本答案，將增加成本與延遲，卻不提升回覆品質。

當較便宜的模型適用於日常 FAQ 時

使用一個能夠處理的模型可保持最初整合的簡單性。若日常 FAQ 在較低成本模型上能滿足您的品質需求，該流量即可成為降低模型支出的候選。請使用我們的model catalog與目前pricing，對同一批核準檔案測試兩個模型。

分類器呼叫與第二次嘗試亦會消耗時間與預算。請根據您能在生成前識別的資訊以及生成後可檢查的內容，選擇相應模式。

三種路由模式

Anthropic 的guidance on building effective agents將路由描述為將輸入分類並指派至專門的後續任務，將簡易問題送往較小模型，將困難問題送往更強模型。以下的建置與維護估算為我們對小型支援應用的規劃判斷。

這些模式可共存。規則或分類決定請求的起點；答案檢查決定其輸出是否可接受。模型自報的信心並非正確性的機率，除非您已對自己的問題驗證其正確性，否則請將其視為排序訊號，直至取得相應資料。

您應用程式負責的與 OpenRouter 處理的部分

擁有以品質為基礎的路由意味著維護規則或分類器、接受檢查、升級決策與監控。這些可放在您的支援應用程式內部，而不需要單獨的路由服務。

若您希望我們選擇初始模型，我們的 Auto Router，以 "model": "openrouter/auto" 選取，會依任務型別分類每個提示，並從 OpenRouter 使用者在該任務型別上使用的模型中挑選一個。按順序的 model fallback 清單，以 models 陣列傳送，會在發生速率限制、供應商停機或內容審核拒絕等錯誤後，重試下一個模型。支援政策接受檢查仍由您負責。

若您希望我們選擇初始模型，請選擇 Auto Router。若您已知首選模型且需要錯誤恢復，請選擇有順序的 fallback 清單。對於先使用低成本模型再升級品質的流程，您的應用程式會檢查候選答案，若檢查失敗則請求另一個答案。

以下流程展示了責任劃分。

OpenRouter 上的完整支援流程

步驟 1：在選擇模型前定義預期結果

HarborDesk 是一個虛構的 SaaS 產品，擁有固定的 FAQ。其機器人能解釋政策並推薦支援，但無法檢查帳戶或進行更改。可接受的回覆會回答問題、要求澄清或推薦人工支援。

對於您能可靠辨識且具有固定答案的意圖，請使用已核准的範本。請單獨測試意圖選擇，確保正確措辭對應正確問題。需要解釋的請求將進入下方的產生式答案流程。

步驟 2：在升級前檢查產生式答案

對於需要生成的請求，低成本模型提供第一個候選答案以及分診訊號。您的應用程式負責接受決策。

假設有客戶詢問如何取消訂閱並請求退款。在 HarborDesk 的政策中，擁有者可於 Settings > Billing 取消訂閱，並由帳務人員審核退款請求。

• 接受低成本答案，說明兩個步驟但不保證退款。
• 拒絕將所有事項轉交帳務且遺漏擁有者取消的答案。若有範本覆蓋此請求，請使用已核准範本；或在評估顯示更強模型能修正此遺漏時，請求更強模型嘗試。
• 若客戶要求機器人批准退款，請推薦帳務支援。更強模型無法提供此許可權。

檢查政策內容與預期行動。僅有有效 JSON 並不能證明正確性。保留對話上下文，在更強答案上執行相同檢查，並在一次升級後停止。

步驟 3：配置錯誤 fallback 並記錄請求成本

此程式碼片段以有順序的 fallback 清單送出單一請求。請先安裝 requests 並設定 OPENROUTER_API_KEY，再執行。簡短的虛構 FAQ 為範例提供背景。

import os
import requests

messages = [
    {
        "role": "system",
        "content": (
            "Answer only from this fictional HarborDesk FAQ. "
            "Owners can cancel under Settings > Billing. "
            "Billing support reviews refund requests. "
            "You cannot inspect accounts, cancel plans, or approve refunds. "
            "Ask for clarification when necessary."
        ),
    },
    {"role": "user", "content": "How do I cancel my subscription and request a refund?"},
]

response = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["OPENROUTER_API_KEY"]},
    json={
        "models": ["openai/gpt-4.1-mini", "openai/gpt-4.1"],
        "messages": messages,
        "max_tokens": 512,
        "stream": False,
    },
    timeout=60,
)
response.raise_for_status()
data = response.json()
if "error" in data:
    raise RuntimeError(f"Completion failed: {data['error']}")
choices = data.get("choices", [])
if not choices:
    raise RuntimeError("Completion returned no choices")
choice = choices[0]
if choice.get("error") is not None or choice.get("finish_reason") == "error":
    raise RuntimeError(f"Completion failed: {choice.get('error', 'unknown error')}")
print({
    "id": data["id"],
    "model": data["model"],
    "answer": choice["message"]["content"],
    "cost": data.get("usage", {}).get("cost"),
})

models 陣列會在發生符合條件的錯誤（如速率限制或供應商停機）後嘗試下一個模型。成功但不正確的答案不會觸發此行為。品質升級需要應用程式檢查與單獨的更強模型請求。

存在兩種錯誤檢查是因為模型可能在開始處理請求並在輸出時失敗，但仍回傳 HTTP 200。error 物件會出現在主體的頂層，或在 choices[0] 內，並將 finish_reason 設為 error 時表示部分內容存在。errors and debugging 參考說明兩種結構。將兩者視為失敗，而非將部分輸出作為答案。

此程式碼片段列印一個未經驗證的候選項以供檢查。usage.cost 欄位是我們為此請求收取的信用點數，model 是產生回應的模型，當回退觸發時這很重要。對每一次請求都要記錄這兩個值。當您的應用程式升級時，將兩次呼叫的費用相加，包括已丟棄的廉價草稿。若回應沒有 cost 值，請將成本記為未知而非零，直到您將其與您的 activity 頁面對帳。usage accounting cookbook 描述了 usage 物件。

測量升級率和每張已解決票的成本

對於總是先嘗試便宜模型的管線，使用此公式計算每次請求的預期模型成本。

expected_cost = cost_cheap + cost_check_1
              + escalation_fraction * (cost_strong + cost_check_2)

將任何評估器或分類器呼叫的成本包含在檢查條件中，並在升級請求時使用更強模型的成本。將結果與僅使用便宜模型和僅使用更強模型（包括它們的檢查）在相同質量目標和延遲限制下進行比較。

為每個路由策略跟蹤這些指標。

• 升級率。 進行更強模型嘗試的請求比例。
• 接受錯誤答案。 便宜模型的答案通過檢查但未通過人工審核。
• 正確答案升級。 已符合條件的便宜答案仍被升級。每個升級都會增加更強模型費用和第二次呼叫的延遲，卻不提升回應品質。
• 轉接適切性。 機器人是否在請求需要其無法擁有的授權時建議人工支援。
• 全回合延遲。 從客戶訊息到回傳答案的時間，包括升級請求的兩個模型階段。

高升級率需要檢查路由問題。它本身並不證明閾值錯誤。

每張已解決票的成本，將該票組的所有模型支出（包括未解決票）除以在指定重新開啟視窗內符合解決定義的票數。測試集上的答案接受度衡量回應品質，而非客戶解決度，請保持兩項指標分開。

在將升級功能投入正式環境前，先在保留的支援問題上執行此比較。包含簡單 FAQ、模糊請求、故障排除以及需要人工轉接的請求，並根據預先定義的內容標準與預期行動為每個答案打分。升級僅在能以可接受的成本與延遲將失敗答案轉為通過答案時才有價值。

結論

先以已批准的範本和針對狹窄 FAQ 的便宜模型基線開始。根據工作負載選擇規則、分類或答案檢查，然後僅在相同質量目標與延遲限制下與更強模型進行比較。僅在升級能修復足夠失敗以抵消成本與延遲時才加入升級。當支援政策改變時，重新檢視檢查。

常見問題

我可以避免建立自訂路由服務嗎？

您可以將路由保留在支援應用程式內。若想讓我們選擇初始模型，請使用 Auto Router，並使用 models 回退陣列以便在請求錯誤後重新嘗試其他模型。支援專屬的接受檢查，例如答案是否符合您的取消政策，仍應留在您的應用程式中。將模型 ID 保留在設定檔，並保持提示與評估資料可攜帶，以便日後更換模型。

便宜模型能在生成過程中諮詢更強模型嗎？

不在本指南的流程中。廉價模型先完成候選答案，然後您的應用程式決定是否請求更強大模型的答案。在同一回合內諮詢另一個模型需要在您的程式碼中明確的工具或協調步驟，呼叫更強模型並將其輸出返回到正在進行的工作流程。models fallback 陣列不會建立該機制。它只會在出錯後重試另一個模型的請求。

我應該選擇哪個 FAQ 分流模型？

先從符合您質量目標且成本最低的候選模型開始，測試留存的支援問題，包括含糊請求和政策例外。測量整個回合的延遲，而非單次呼叫延遲，因為最快的模型呼叫仍可能產生較慢的支援回應，如果它經常需要第二次嘗試。先從少量重複問題開始，隨著評估顯示哪些路徑有效，再逐步擴大。

參考資料

• Auto Router
• Model Fallbacks
• Usage Accounting
• Errors and Debugging
• Building effective agents, Anthropic