Test-time Compute Evaluation
Test-time compute evaluation 是把模型表現視為「推論時算力」函數的評測方式，而不是只報告單一 benchmark 分數。test-time compute 可以用 token 數、成本或實際耗時表示；核心問題是，同一個模型在不同推論預算下可能呈現完全不同的能力曲線。
為什麼重要
aihao-blog 文章整理 Noam Brown 對大規模 test-time compute 的主張：隨著推理模型與 agent 架構變強，benchmark 分數越來越依賴推論預算。若只看單一分數，可能把「用了更多 token / 成本 / 時間」誤判成模型或方法本身更強。
這會直接影響三件事：
- 模型選型：應比較「在同一預算下誰最強」，而不是只看最高分。
- agent / prompt A/B test：沒有控制推論預算的比較，可能只是比較誰花更多錢。
- 安全評估：前沿模型能力若會隨推論預算持續上升，安全報告需要說明在多大預算下評估。
評估方式
最小可用做法：
- 固定一個任務集或 benchmark。
- 對每個模型記錄 token 數、成本或時間。
- 畫出「表現 vs 推論預算」曲線。
- 若只能報單點，至少同時揭露該點使用的推論預算。
這與 replit-agent-eval-scale、vibench 的精神一致：eval 不只是分數表，而是能支撐產品決策與迭代的觀測系統。它也補強 build-for-next-model 中「evals 是不變量」的觀點：eval 必須把模型、鷹架與推論預算一起納入。
Google Research 的 reasoning-for-factual-recall 研究補上一個 factual QA 例子：reasoning tokens 即使沒有語意內容，也可能透過 computational buffer 擴大模型可取回的 parametric knowledge 邊界；但自然 reasoning trace 中的 factual priming 若混入 hallucinated facts，反而會拖累最終答案。這表示 test-time compute 的評估不只要量 token / cost，也要看 reasoning trace 是否可驗證。
Knowledge Profiling / WikiProfile 再把 budget-aware evaluation 接到 fact-level diagnosis：Google Research 報告指出，frontier models 的 encoding 已接近飽和，但 recall failure 仍然存在；thinking 主要恢復已編碼卻難以直接取回的 facts。評估因此應同時記錄 encoding proxy、direct recall、recognition、thinking budget、題目方向與成本，而不是只看最後 accuracy。knowledge-profiling-factuality
bayesian-teaching-llm-reasoning 則補上互動式 probabilistic reasoning 的評估面：如果任務有可計算的 Bayesian assistant，就能比較 LLM 在多輪回饋中是否正確更新偏好假設，而不是只看最後推薦是否命中。
multilingual-model-scaling-laws 把 budget-aware evaluation 延伸到訓練前決策：多語模型比較不只要控制推論預算，也要揭露訓練語言數、語料混合、cross-lingual transfer 假設與 pre-train / fine-tune 的 compute crossover。
Kimi K3：context 策略也是評測變因
BusinessNext 對 Kimi K3 的報導顯示，同一個長程搜尋任務在不同 context 設定下就可能得到不同結果：BrowseComp 在約 30 萬 token 壓縮 context 的設定為 91.2 分，完整 context 則為 90.4 分；文章另列出前端程式碼、AutomationBench-AA 與長程代理知識工作的差異化結果。這些數字是來源轉述的第三方評測，不能直接視為跨模型的普遍結論，但足以提醒評測記錄必須包含 context 壓縮、工具／harness 設定與任務成本。
因此，模型比較至少要把 model-harness-fit 的配對條件與 agentic-ai-cost-management 的 task-level budget 一起固定：同一任務集、同一 context policy、同一工具權限與可比的 token／美元／時間預算。若只留下「某模型排名第一」，就無法判斷優勢來自模型、更多推論資源，還是更貼合的工作流。
ALE：長時程、harness 與成本同時入榜
AIHAO 對 Agents’ Last Exam（ALE）的整理提供一個長時程 agent 的具體評測形狀：任務在真實專業軟體或 CLI 環境執行，結果有可驗證 outcome，榜單同時列 pass rate、partial-credit score、模型／harness 與總成本。這使評估單位從「模型在一題上的分數」變成「模型 + harness + 任務分布 + 推論預算」；Near-term、Full-Spectrum、Last-Exam 等子集也能分開回答短期可用性、跨產業廣度與前沿能力距離。來源所列 leaderboard 與成本數字是文章轉述，需以 ALE 原站及相同設定重現後再採用。
對 AI Ark 的最小規則是：長任務至少同時記錄滿分通過率、partial credit、失敗／恢復 trace、工具環境、token／美元／時間成本；若只增加 reasoning effort 卻沒有改善 Last-Exam 類任務或 Pareto frontier，就不應把額外算力視為有效升級。
Deep research 的 test-time diffusion
Google Research 的 Test-Time Diffusion Deep Researcher（TTD-DR） 把長篇研究報告視為「先產生草稿，再用搜尋逐輪去噪與修訂」的 test-time workflow，而不是把規劃、搜尋、寫作和評估拆成互不相干的工具串接。它以 draft-first 的初稿作為後續研究計畫與查詢生成的 context；每輪取得新資訊後，回寫草稿、驗證既有主張，再生成下一個搜尋問題，直到完成報告。這個模式和 loop-engineering、academic-workflow-agents 的閉環觀點相連，但把迭代 refinement 提升成模型推論時的主要計算單位。
TTD-DR 另加入 component-wise self-evolution：對不同階段產生多個答案變體，以 LLM-as-a-judge 評估 helpfulness / comprehensiveness，根據 feedback revision，最後 crossover 合併高品質 context。Google Research 文章回報，TTD-DR 在 DeepConsult、HLE-Search 與 GAIA 上優於比較系統，長篇報告對 OpenAI Deep Research 的 win rate 為 74.5%；這些數字應視為來源方的報告，仍需和原論文、相同模型與相同 latency / cost 設定交叉核對。
這個案例擴大了 test-time compute 的定義：預算不只是 reasoning tokens，也包含搜尋輪數、retrieval、judge、revision、context 累積與 latency。評估 deep-research agent 時，應同時記錄每輪 query、引用證據、草稿變更與 verifier 結果，才能用 agent-trace-observability 拆出「多花算力」究竟換來更好的證據、較完整的報告，還是只換來較長的文字；比較結果也應畫成 quality / latency / cost 的 Pareto frontier。
Grok 4.6：從靜態分數轉向長時程 task budget
BusinessNext 2026-08-13 對 Grok 4.6 的整理提供一個產品發布型案例：來源轉述 Artificial Analysis 在 GDPval-AA v2、Terminal-Bench v2.1、τ³-Banking 與 AA-Briefcase 的結果，並把「長時間 agent 能否自我測試、驗證並完成工作」和靜態推理題區分開來。這些評測數字、每題 0.84 美元與約 53 輪來回都是 attributed claims，需用相同模型、harness、任務與預算重現。
這個案例把 test-time budget 擴成可觀測的 task trajectory：除了 reasoning tokens，還要記錄 tool-call 回合、搜尋／檢索、self-check、retry、context cache、延遲與人工接手。對 model-harness-fit 而言，評估問題是模型與工具迴圈是否貼合任務；對 agentic-ai-cost-management 而言，問題是額外回合與快取價格是否換來更高的完成率，而不是只看模型排行榜。
Gemini 3.7 Flash：把模型發布轉成任務級曲線
BusinessNext 2026-08-14 對 Gemini 3.7 Flash 的整理同時列出官方編碼／軟體工程評測、Artificial Analysis 綜合智慧指數、每秒 token、單一任務時間與每任務成本，形成一個比單一 benchmark 更接近實務的觀察面。來源稱它在不同 coding 與 agent benchmark 對 GPT-5.6 Terra 互有勝負，並以較低促銷價和較快速度取得部分 Pareto 優勢；這些是來源方／第三方 attributed claims，仍需固定模型版本、model-harness-fit、任務集與預算重現。
可重用的最小評測記錄是：同一任務集下，同時保存完成率、品質門檻、輸入／輸出 token、cached input、tool-call 回合、latency、retry、人工審查與每任務美元成本。只有把這些變數放在同一條曲線上，才知道「更快、更便宜」是否只是少做了驗證，或真的改善 agentic-ai-cost-management 的 quality／cost Pareto。
Gemini 3.7 Flash：從 benchmark 快照到選型曲線
BusinessNext 2026-08-17 的 Gemini 3.7 Flash 修訂版把 FrontierCode、DeepSWE、WebDev Arena、GDP.pdf 與 AutomationBench 等任務結果，和 API 價格、Google AI 訂閱層級、算力額度及 Flash-Lite／Flash／Pro 的任務分工放在同一篇。這些數字與功能是 Google／BusinessNext／第三方 attributed claims；它們適合當候選訊號，不足以直接證明跨帳號、跨地區或跨 harness 的普遍優勢。
可重用的評測設計是把「模型發布」轉成一條 budget-aware 選型曲線：固定任務集、模型版本、入口／harness、帳號地區與工具權限，分別記錄品質門檻、完成率、澄清與人工接手、算力／token 用量、延遲、retry，以及 API 或訂閱的完整任務成本。訂閱的額度與背景 agent 能力是 capacity budget，不應和 API token 單價混成同一個變數；正式決策要比較 model-harness-fit 的配對條件與 agentic-ai-cost-management 的 quality／cost Pareto。
文章也提醒產品頁面的模型標示可能落後實際 App rollout，台灣聊天介面與 Spark agent 可能同時使用不同版本。評測紀錄應保存當時的實際入口、模型、地區與資格狀態，否則日後重跑時無法分辨能力變化來自模型、算力配額、產品 rollout 或 harness 差異。
AI Ark wiki 觀察
對 AI Ark 來說，這個概念可以作為後續模型評測與 agent 成本分析的基準語言：
- daily / weekly synthesis 若比較模型能力，應避免只引用單一榜單分數。
- agent 工作流若聲稱某 scaffold 較強，應同步記錄推論預算。
- 本地 / 雲端模型選型可用 Pareto frontier（能力 vs 成本）來描述，而不是只列模型排名。