欄位先被宣告，答案才開始找：Cloudflare Clairic 的抽取介面觀察

一份發票丟進系統之前，開發者得先交出一張欄位規格：發票號碼、到期日、含稅金額、聯絡人。Cloudflare 在 2026 年 10 月 20 日由 APPI News 刊出的指南中，把 Clairic 描述成一個做這件事的專用抽取模型：輸入文字或圖片，加上預先定義的欄位，回傳型別正確的答案。這個介面的設計重點，在於把「要什麼」和「怎麼找」分開，前者由人填，後者交給模型。

這和直接拿大型語言模型讀文件、要求它輸出欄位，是兩種不同的產品姿態。LLM 擅長解釋脈絡、推理與生成文字；Clairic 則把範圍收窄到「擷取已知欄位」。指南裡有一個值得留住的分法：擷取、計算、估計、生成是四件不同的事。擷取是找到原文裡的金額，計算是依發票日期和付款條件算出到期日，估計是從線索推測數值，生成才是回答「這份合約有哪些風險」。前幾種可以設計成固定型別，最後一種需要自由文字。介面先劃清這條線，工具的取捨才有了比較基準。

欄位規格本身就是一套排版語言。欄位可以是文字、數字、日期、清單，也可以是帶上下限的估計值。型別一旦宣告，後續程式就不必再猜格式。部分文字欄位會附上來源位置與信心資訊，讓答案能連回文件原文核對；缺乏依據時，結果允許是空值。這三個設計，來源錨點、信心分數、合法的空值，構成一頁可核對的介面，而非一頁只能照單全收的答案。

其中最有節制的是空值。很多抽取工具的失敗模式，在於被逼著對每個欄位給出答案，於是模型開始編。允許說「找不到」，等於把誠實設計進了輸出格式裡。指南同時提醒，信心分數需要用實際資料集校準，不能單獨當成正確保證；Cloudflare 自己的抽取模型指南也寫明，型別正確不代表答案正確，高影響流程應搭配人工覆核。一句產品文件裡的自我設限，往往比行銷頁的速度數字更值得讀。

Cloudflare 對 Clairic 的主張是單次前向處理、不生成輸出文字詞元，通常一秒內回應，成本也低於相同任務下的傳統 LLM。但這是廠商在其比較情境中的說法。同樣的比較課題，我們在Chrome 內建大模型的等待介面裡也看過：延遲數字要不要被相信，取決於起點和終點怎麼畫。若只計模型收到文字到回傳欄位的時間，就沒有涵蓋讀檔、轉圖、OCR、網路傳輸與人工放行。省下的推論費用，也可能被前處理和覆核成本喫掉。

介面設計上最誠實的一段，是指南對欄位定義的態度：模型無法替組織決定業務規則。「總額」要不要包含運費、稅金或折扣，應先由資料使用者定義。這句話把責任畫得很清楚。欄位規格是人的介面，模型只負責填值；規格含糊，輸出再快也只是把含糊格式化。這與上下文長度作為一套被設計出來的介面的觀察相通：標稱的規格之外，真正可用的部分永遠由使用端的定義品質決定。

Clairic 的價值不在於比 LLM 更聰明，而在於把任務收窄到可以用欄位驗收的程度。型別、來源位置、信心、空值，這四樣東西讓抽取結果第一次變得可核對。至於快與省，那是流程量測的結論，要等同一份文件、同一組欄位、同一個品質門檻下的實測數字說了算。