要的是欄位，來的卻是一段作文：Cloudflare Clairic 走的專用抽取路線

文件處理要的常常只是幾個欄位值。Cloudflare 新推出的抽取模型 Clairic 縮短了取值的時間，但欄位怎麼定義、結果怎麼覆核，仍要由使用端自己完成。

一張發票送進報帳系統，財務真正需要的值通常只有四個：發票號碼、開立日、含稅金額、付款期限。發票版面可能有十幾種，供應商每隔幾年換一套開立工具，欄位清單卻三年沒變過。這種場景裡的常見做法，是把整份文件丟給大型語言模型（LLM），請它讀一讀、整理一下。模型讀得懂，也答得出來，只是回覆多半是一段文字，程式還得再解析一次，而且每次推論都要付費，還要等它逐字把答案生出來。

Cloudflare 近日發布的抽取模型 Clairic，鎖定的就是這類工作。依 Cloudflare 的公告，它從非結構化的文字或影像裡擷取指定欄位，主打比傳統 LLM 更快、推論成本更低。定位用一句話講完：輸入是文件加上一份欄位規格，輸出是照規格填好的值。

先分清楚：要的是欄位，還是答案

「讀文件」三個字，經常把幾種不同的工作混在一起。第一種是擷取，在原文裡找到既有的值，例如姓名、金額、編號。第二種是計算，依發票日期和付款條件推算到期日。第三種是估計，從文件線索推測沒有明說的數值。第四種才是生成，整理一段說明，或回答「這份合約有哪些風險」這類開放問題。

前三種都可以事先定義欄位與型別；第四種需要上下文與自由文字，是 LLM 擅長的位置。把 LLM 拿來做擷取，能用，但每一步都在為理解與生成付費。發票、合約、表單這類大量文件的共同點，是版面千變萬化、需要的欄位卻相對固定：輸入是未整理的文字或影像，輸出是欄位名稱、型別和值。這種工作有個正式名字，叫結構化資料抽取，也正是專用抽取模型設定的位置。

在 LLM 之前，這類工作多半靠光學字元辨識加版面規則撐著，版面一換就得重寫規則；LLM 補上了彈性，代價是速度與成本。Cloudflare 想同時拿走彈性與速度，取捨則是模型只做抽取，其餘的事一概不接。

填空題的作法：不生成文字，直接回值

Clairic 的介面可以想成一份填空題。開發者先交出欄位規格，Cloudflare 的示範以發票為輸入，指定發票號碼、到期日、金額、聯絡人等欄位。欄位型別涵蓋文字、數字、日期、清單，也可以是帶上下限的估計值。模型收到文字或圖片後，把規格與輸入一起跑一次運算，直接回傳每個欄位的值，過程不逐字生成輸出詞元。Cloudflare 以「單次前向處理」描述這種設計，並稱通常能在一秒內回應。

回傳結果自帶型別。日期就是日期格式，數字就是數字，後續程式不必再寫解析規則，去猜「2026/10/20」和「十月二十日」算不算同一天。部分文字欄位會附上來源位置，標出值落在輸入的哪個字元範圍，抽查時可以直接跳回原文對照。文件裡找不到足夠依據時，模型也可能回傳空值，把模糊的案例交回使用端，排進覆核佇列。

這套設計有個前提：「要什麼值」得先說清楚。欄位定義含糊時，模型無從替組織決定業務規則。「總額」要不要包含運費、稅金或折扣，是資料使用者的決定，先定義，再交給模型。另外，官方文件標示支援影像輸入，實際可用格式與請求限制依 API 文件確認；原始資料若是掃描件，影像整理、頁面拆分、轉檔這些前處理可能省不掉。丟一個 PDF 網址就想完成整套辨識，是危險的假設。

型別對了，答案還是可能錯

Cloudflare 自己的抽取模型指南裡，有一句提醒值得先抄下來：型別正確，不代表答案正確。結果符合欄位型別與限制，值仍然可能填錯。信心資訊能幫忙安排覆核順序，但分數要拿實際資料集校準過才有意義，單看數字稱不上保證。

涉及付款、核準這類會產生實際影響的動作，第二道驗證或人工確認要設計進流程。來源位置與信心分數是給覆核用的工具，讓人可以把力氣花在最少數、最可疑的案例上。模型交出候選答案，放行的責任在使用端，這條線在導入前就要畫好。

速度與成本：把整段流程放上同一把尺

「更快、更省」是 Cloudflare 在自家比較情境裡的主張，屬於廠商數據。同樣任務拿傳統 LLM 對照，比較是否公平，取決於 LLM 的型號、提示詞寫法、輸出詞元數、重試次數，以及兩邊有沒有達到同一個欄位正確率。這些條件不透明時，數字只能當參考。

真正該測的是自己那條流程。固定輸入、欄位與品質門檻，從讀檔、轉圖、網路傳輸、佇列等待，一路量到欄位回傳為止。只計模型收文到回文的時間，會漏掉大半條管線，人工放行更常常是整段流程最慢的一關。

成本的帳也一樣。文件抽取管線的前後掛著掃描、影像壓縮、光學字元辨識、格式轉換，低信心或錯誤的案例要送人核對。欄位定義需要反覆調整、系統需要重試時，省下的模型費用可能被整合與覆核的工作喫掉。Workers AI 的定價與計費方式會調整，估算時以官方定價頁當下條件為準，計入自己實際使用的模型與流量。模型單價下降之後，費用記在誰的預算、流程裡哪一段最花錢，反而更值得先回答，這一題可以對照我們先前整理的管 AI 用量之前先回答費用歸誰的討論。

導入前可以照著走的順序

第一件事，確認輸出形態。要的是欄位值，還是一段有脈絡的回答？前者才考慮專用抽取模型，後者留給 LLM。

第二件事，把欄位定義寫成文件。每個欄位的型別、業務規則、邊界案例先寫下來，含糊之處在上線前解決。

第三件事，用自家文件實測整段流程。固定的欄位與品質門檻，記下正確率、延遲與失敗案例的分布。這個原則與我們先前整理的llama.cpp 推測解碼的驗收順序一致：宣稱的數字先放一邊，固定條件下的對照才算數。

第四件事，校準信心分數再定覆核門檻。高影響動作保留人工關卡，讓模型處理量，人處理風險。

第五件事，核對定價與限制。以官方定價頁與模型文件當下的條件估算，影像格式與請求限制一併確認。

專用抽取模型換掉的是讀文件的算式：固定欄位、大量文件、要求快速回應的部分交給它，理解與寫作留給 LLM。Clairic 的功能細節與服務條件，以 Cloudflare 的模型文件為準。而成敗的關鍵多數落在模型之外，欄位怎麼定義、信心怎麼校準、錯誤由誰覆核，這三題先有答案，工具的選擇就簡單了。

資料來源：本站編輯參考 APPI News〈Cloudflare Clairic 與大型語言模型完整指南：文件抽取、速度與成本〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。