AI 模型上線前，我們如何評估？

你將瞭解

• 先明確產品要完成的工作，不要從公開排行榜開始。
• 在查看模型輸出之前，先寫好評分標準。
• 計算完整工作流的成本和可靠性，把重試也算進去。
• 把提示詞、模型 ID 和發佈控制放在業務代碼之外管理。

從任務出發，而不是從模型列表出發

起草回覆的客服助手、直接修改代碼倉庫的編程 Agent，以及從發票中提取字段的文檔流水線，都可以叫作“AI 功能”，但它們顯然不需要同一種模型。開始比較之前，我們會先寫一份簡短的任務約定：輸入是什麼，必須輸出什麼，用戶最多能等多久，以及錯誤答案會造成什麼後果。

這份約定能讓評估保持誠實。沒有它，團隊很容易偏愛演示中“聽起來最好”的答案。到了生產環境，字段正確、表達樸素的結果，往往比文采很好卻讓解析器報錯、甚至捏造規則的答案更有價值。

• 輸入：語言、長度、附件、工具，以及敏感數據限制。
• 輸出：格式、必需事實、拒答行為和允許的波動範圍。
• 運行邊界：延遲目標、請求量和成本上限。
• 失敗成本：錯誤能否在到達用戶前被人工發現。

建立一個規模不大、但足夠難的評估集

相比 4,000 條泛泛的提示詞，我們更願意使用 40 條精心挑選的案例。評估集首先來自產品工作流中真實、且經過授權的樣本。清除個人和機密信息後，再加入過去真正出過問題的邊界情況：含糊指令、上下文缺失、惡意輸入、異常長文檔，以及本應拒絕的請求。

有效的評估集不會刻意追求平均。常見案例用來判斷模型能否承接正常流量，困難案例用來觀察它會怎樣失敗。保留一組凍結的核心案例做迴歸測試，同時持續加入近期真實案例，避免測試集逐漸脫離產品。

先確定評分方法，再去看答案

評分表必須在第一次對比之前寫好。這樣可以避免一種常見錯誤：看到偏愛的模型給出漂亮答案後，再臨時修改標準。有效 JSON、必需字段、精確引用和工具參數等項目可以自動檢查；需要主觀判斷的任務，則應使用簡短清晰的評分規則，並讓評審者不知道答案來自哪個模型。

單一總分會掩蓋太多問題。我們會保留不同評分維度，讓團隊清楚自己在做什麼取捨。一個模型即使很會遵循指令，也可能因為捏造引用，或反覆在同一類安全案例上失敗而無法使用。

衡量完整工作流，而不是單次請求

Token 單價只是成本計算的輸入，不是最終答案。單價更低的模型可能需要更長提示詞、生成更多內容、進行多餘的工具調用，或者反覆重試。我們會計算工作流得到合格結果時的總成本。超時請求和需要人工重寫的結果同樣佔用時間，而且通常也已經產生模型費用。

延遲也應該用同樣的方法評估。對於流式場景，要記錄首 Token 時間、完整響應時間和慢請求尾部，而不是隻看平均值。測試次數要足以暴露波動，並且應從應用真正運行的地區發起請求。

把真實接入方式完整測試一遍

兼容 OpenAI 接口，並不代表所有模型的行為完全一致。首先確認實際要使用的端點和模型 ID，然後逐項測試應用依賴的能力：流式輸出、結構化輸出、工具調用、圖片輸入、停止序列和上下文長度。不支持的參數應該在評估階段明確暴露，而不是上線後才出問題。

我們也會認真檢查錯誤響應。應用應該保留 HTTP 狀態碼和請求 ID，能夠區分限流與參數錯誤，並且不應重試永久性錯誤。這些工作不如並排展示幾個答案吸引眼球，卻往往決定了接入能否穩定進入生產。

• 在配置中固定模型 ID，並記錄評估日期。
• 對提示詞模板和生成參數進行版本管理。
• 設置明確的超時時間和帶隨機抖動的有限重試策略。
• 記錄請求 ID 和用量，但不要記錄密鑰。

使用影子流量，並提前演練失敗場景

離線測試無法復現生產環境中的所有輸入。全面切換之前，我們會把一小部分經過安全處理的現有流量發送給候選模型，但不會把它的答案返回給用戶。這樣可以發現格式漂移、真實併發下的延遲，以及評估集遺漏的案例。涉及敏感數據的工作負載，必須先確認合規的數據路徑，才能進行影子測試。

接下來要測試那些不太“好看”卻很重要的場景：限流、超時、流式響應損壞、模型不可用，以及結果未通過校驗。團隊必須明確哪些錯誤可以重試、什麼時候可以安全切換備選模型，以及什麼時候應該停止並請用戶稍後再試。

記錄決策，並確保它可以回退

最終的決策記錄應該足夠簡短，確保以後真的有人願意更新。至少記錄任務、候選模型、測試集版本、評分、實測成本、延遲、已知失敗模式和選擇理由，並寫明負責人和下一次複核日期。

模型選擇不是永久架構。把模型和任務參數保存在配置中，持續維護評估集，並通過可控制的流量比例或功能開關發佈。當價格、模型行為、流量或可用模型發生變化時，重新運行同一套流程，而不是依靠記憶從頭爭論。