級聯與並行提問

這一類用法的動機都很直白：大模型的呼叫是貴的，而其中大部分請求其實很容易。 決策模型每問的價格比一次生成低一到兩個數量級，於是「先問便宜的，不確定再問貴的」 就成了順理成章的結構。

級聯：只在自己有把握的地方定案

一個醫療幻覺檢測的對比實驗給出了很乾淨的量化：

讓決策模型在它 ≥90% 確信的那 37% 上直接定案， 保住各個大模型原有的準確率，同時省掉 37% 的大模型呼叫。

這個結果之所以值得引用，是因為它把級聯的收益說清楚了：省下來的比例 等於小模型在高置信區間上的覆蓋率，而不是某個固定的百分比。 置信區間收得越緊，省的越多 —— 但前提是那個置信度真的可信 （這又回到了校準那一篇）。

級聯有兩個容易被漏掉的細節：

① 升級之後，大模型不該有無限的自由。 一個把不確定的行升級給大模型的實現， 強制大模型只能從同一組標籤裡選。不這麼做的話，小模型的「不確定」 會被大模型的「自由發揮」換成一個你沒法處理的輸出。

② 選擇一旦做出，就要鎖住。 一個模型路由器的做法是：選定之後在整段會話裡 保持這個選擇，為的是 prompt cache 的連續性。每次都重新選，每次都會因為 字首變了而丟掉快取 —— 省下來的錢在快取上又花回去了。

並行提問：省的是輸入

決策模型允許把很多個問題放進同一次請求。官方的示例裡就有一次呼叫問幾十個問題的做法。

一個跑了 2,976 次呼叫的基準測試給出了具體數字：

也就是說，省下來的主要不是「模型算得快」，而是同一份 state 只發一次。 問題越多，這份固定開銷被攤得越薄。當問題少到一兩個時，並行和逐個發的差別 和重複請求的噪聲是同一個量級 —— 不值得為此改架構。

反例：批處理會破壞排序

這是這一篇裡最值得記住的一條，因為它反直覺：

一個 DuckDB 擴充套件預設按 40 行一批處理。基準測試發現， 按批處理過不了它的排序質量門，而一行一個請求能過。

原因不難還原：把 40 行塞進一次請求，模型要在一個請求裡給出 40 個相對排序， 這比每次只比較少量候選要難。省錢和保真在這裡是衝突的， 而「省錢」這一側的收益是可見的（賬單），「保真」這一側的損失是不可見的 （除非你專門設了一個門去測它）。

這條對任何「批次提問」的設計都成立：並行提問適合彼此獨立的問題 （分類、打分、判斷），不適合需要互相比較的排序問題。

級聯還有一個前提：錯誤要是隨機的

級聯在數學上成立，靠的是一個隱含假設：小模型犯的錯是隨機噪聲， 所以大模型接手後能糾正。

但獨立的 OOD 校準測試給出了相反的證據 —— Choice 與 Score 系統性地過度自信、Boolean 系統性地自信不足。系統性的偏差不是噪聲： 它會讓小模型在同一類樣本上一致地給出高置信度，於是那些樣本 永遠不會被升級，而是被一致地答錯。

這意味著級聯的風險不是「準確率低一點」，而是某一整類輸入被穩定地漏掉， 而且在整體指標上看不出來。要發現它，必須按子類去看準確率， 而不是看總體。

一句話

級聯省的錢等於「高置信區間的覆蓋率」；並行省的錢等於「被攤薄的固定開銷」。 兩者都有代價 —— 前者賭小模型的錯是隨機的，後者會傷到需要互相比較的任務。