摘要： Cloudflare 在 2026 年 10 月 19 日預覽了新類別的 System One 抽取模型，首款產品 Clairic 已在 Workers AI 上以 @cf/cloudflare/clairic 提供，並計畫近期開放權重。它不生成文字，而是在單次前向傳遞中從非結構化輸入直接抽出、計算、估計或預測數值——對長期把「回傳 JSON」交給 LLM 的開發者來說，這是新的成本與可靠度選項。
為什麼抽取不需要 LLM
用 LLM 做「回傳發票編號、廠商與到期日」這類任務，最麻煩的不是能力，而是失敗模式難以察覺：輸出可能不是合法 JSON、數字在逐 token 生成時被讀錯、回傳的文字片段也無法追溯回原文位置。所以大多數團隊最後都建了多層解析、schema 驗證、重試與抽查的管線，還要為每份文件的每個欄位付推理與輸出 token 的錢。
Clairic 的設計正是針對這些痛點。依照 Cloudflare 的說法，它只處理輸入 token、單次前向傳遞完成，不收輸出 token 費用，通常一秒內回應；因為不生成 token，也不會像 LLM 那樣產生格式錯誤或幻覺式的答案。找不到值時就回傳 null，並附上 null 機率與模型本來會選的猜測值。
一個請求長什麼樣
請求由兩部分組成：一段 state（要讀的文字，最多附四張圖片），加上一組帶型別的欄位地圖。每個欄位命名、指定型別，可加上自然語言說明。支援的型別包括：
text：回傳輸入中的片段，附字元偏移與信心分數number/date/time/datetime/duration：依型別規則回傳（例如金額兩位小數、日期為 ISO 格式）list：依輸入順序回傳符合的文字、數字或日期estimate：在你宣告的[min, max]範圍與步進網格內回傳一個分布，附中位數與 80% 區間forecast：對序列的每個未來步驟各回傳一個帶 80% 區間的估計
Cloudflare 的範例是一封客訴 email：要求同時抽出訂單編號、送達日期、計算含稅總額與「距送達已幾天」。結果裡，amount_paid 和天數都不是原文寫明的，而是模型在同一次傳遞中算出來；損壞項目以精確的 span 回傳，可直接在原文標示；不存在的追蹤號碼則誠實回 null。欄位數量沒有上限——三十個欄位的成本大約等於三個。
在模型版圖中的位置
這個概念源自 TypeSafe 一個月前發表的 System One 模型 Jev：借用 Daniel Kahneman「快思慢想」的框架，指快速、精確、針對特定用途的模型，對比擅長深思推理的 System Two（也就是 LLM）。此前的 System One 模型都是決策模型——給選項、回機率；Clairic 則是第一個抽取模型，回傳的是「值」。
三者其實可以組成一條流水線：抽取模型把原始輸入變成帶型別的值，決策模型把值變成決策，LLM 把決策變成文字。對產品團隊來說，這代表你可以把高流量、形狀固定的結構化呼叫（金額是多少？什麼時候送達？逾期幾天？）從 LLM 上卸載下來，只把真正需要生成與推理的部分留給大模型。這和我先前拆解過的 Cloudflare 把 AI 程式碼審查成本砍 68% 的做法 是同一個思路：按任務特性選對模型，省下來的成本往往比任何 prompt 優化都多。
值得留意的限制
Clairic 目前是預覽狀態，開放權重的確切時程 Cloudflare 尚未公布。它回答的是「值」，不是「為什麼」——凡是需要解釋、撰寫或開放式推理的工作，仍然屬於 System Two 的範疇。實際動手前，最務實的下一步是拿自己的一批真實文件，把幾個高流量欄位同時丟給 Clairic 和你現有的 LLM 管線，比較準確率、延遲與單位成本，再決定哪些環節值得遷移。
參考來源
在 X 上查看原貼文