GitHub Radar

Hamel Husain 與 Antaripa Saha（2026 年 10 月 20 日）試用一批被稱為 decision model 的新工具——Jev、Perplexity 的 Decider、Liquid 的 d1、Cloudflare 的 Clef、OpenAI 的 Decisions API——當自動評測的廉價評審。文中沒給正式定義，只描述它們承諾快速且便宜的分類，每個都回傳 0 到 1 的分數，估計一條 trace 含有失敗的機率。作者指出是否適用要看成本、效能與延遲需求，並觀察到很多人直接用預設的 0.50 門檻而不曾檢查，白白浪費效能。

測試設定：用 100 條公寓租賃 agent 的 trace（對話與動作的紀錄），任務是找出含錯誤的 trace（例如預約失敗、沒有轉交給人類）。排除兩條內部 QA 範例後共評分 98 條，參考集有 61 條已知失敗與 37 條通過。比較的維度是效能（與人類 pass／fail 標籤的一致度）與成本（由 token 用量與供應商定價推算的 API 成本）；延遲被排除在外，因為它取決於實驗控制之外的因素。測試的模型有 Jev 1.13、Perplexity Decider 1.1 27B、Liquid d1 與 d1-ultra、Cloudflare Clef Flash、OpenAI Decisions（GPT-6 Luna），全部給同一組準則。

門檻觀念：trace 只標 pass 或 fail，作者建議做二元 eval；分數達到或超過門檻就被標為失敗，預設是 0.50。他們用一個假設例說明風險：若一個模型把所有失敗都評 0.40、所有通過都評 0.10，在 0.30 門檻下分類是完美的，但預設的 0.50 一條都抓不到。精確率（被標起來的裡有多少是真失敗）與召回率（真失敗被抓到多少）會互相權衡，平衡點要看錯誤的後果，作者用刑事審判（重精確率）與癖症篩檢（重召回率）作對比；為了比較方便，他們用 F1（精確率與召回率的調和平均）等權處理。

調門檻的做法：作者對自動警示用例的最低要求是精確率與召回率都要 80%；Perplexity、Liquid d1-ultra 與 OpenAI Decisions 在 precision-recall 分析上過關，OpenAI 對兩類的分隢最清楚、F1 最高。方法是：用分層五摺交叉驗証，在訓練 trace 上選門檻、在保留 trace 上量測；只採用在訓練資料上同時滿足兩個 80% 門檻的設定，若沒有符合就如實報告而不降標準；並與預設 0.50 對比。F1 調優後候選者的改善是温和的，Liquid d1 與 Clef Flash 掉到最低要求以下；作者也提醒 F-beta 可以對精確率或召回率給不同權重，改變選出的門檻。

效能對成本：作者把調優後的 F1 對成本畫成圖並識別 Pareto 前沿。剩下的候選者中，Perplexity 最便宜，每 100 次 eval 要 0.82 美分，F1 0.79；OpenAI Decisions 的 F1 是 0.87，但每 100 次 eval 要 3.72 美分，貴約 4.5 倍。作者自嵹這張圖很簡單，因為只剩三個選項。

機率能不能信：分數要能當作信心估計，前提是它有校準——分數接近 0.80 時，類似的 trace 應該約 80% 是失敗。他們用 reliability 圖把 trace 按分數分組、比對預測機率與實際失敗率，並測試了 Platt scaling（用一條曲線修正機率）。Perplexity、Liquid d1 與 Clef Flash 校準後更靠近對角線；其中 Clef Flash 有一組平均預測失敗機率約 8%，實際失敗率卻是 60%。Jev 與 Liquid d1-ultra 本來就校準得很好；OpenAI 的機率用這版 Platt scaling 後稍微變差。註腦的 Brier 分數（越低越好）：Jev 校準前 0.187、後 0.188；d1-ultra 0.173 與 0.172；OpenAI 0.159 與 0.164。作者強調校準必須量測、不能假設。

Prompt 調優與評審範圍：作者刻意把任務設得寬，讓模型差異顯現；他們建議實務上每一種失敗模式用一個專屬評審，預期那樣模型間的差距會縮小。他們的做法是先用一個表現可接受的大模型，再試小模型省成本；prompt 調優在標籤品質好時有用。註腦提到一個小實驗：給 Jev 加上失敗類型檢核表後，預設門檻下的 F1 從 0.78 升到 0.80；也建議留一組獨立測試集做最後檢查。

実務步驟總結：一、先定稿評審 prompt，再設定最低精確率與召回率，刷掉做不到的模型。二、每個模型先調門檻再比較，選的是符合商業目標的權衡，而不是預設用 F1。三、若要把分數當信心使用，就要檢校準並量測修正有沒有用。四、最後權衡效能、成本與延遲。他們強調這是迴圈式的過程，效能會隨任務與資料集變動，所以在自己的資料上量測很重要；並引述 Randy Olson 更广的比較：decision model 在分類與路由上可以跟 LLM 打平而成本更低，LLM 則在知識與推理密集的任務上較佳。文末附上完整的評測 prompt，要求判断 trace 是否含有至少一項實質的助理端失敗、風險或品質問題並回傳機率，並明訂要評的是助理而非客戶、排除小節風格問題與客戶自己造成的失敗。