抽欄位不必動用大模型：Cloudflare Clairic 把文件抽取做成另一門生意

帳單、收據、客服信件進到系統之後，如果流程真正需要的只是日期、金額和單號三個欄位，先請大型語言模型寫一段說明、再從文字裡拆回欄位，這條路繞得有點遠。Cloudflare 於 2026 年 10 月推出的 Clairic，瞄準的正是這段流程。它以 Workers AI preview 形式提供，訴求是低延遲、低成本，從文字或圖片中抽取預先定義型別的欄位值。

值得先講清楚的是：Cloudflare 宣稱部分任務比 LLM 更快更省，這些數字是廠商公布的測試結果，能不能套用到自家流程，仍要自己量一遍。

它解決的是「輸入亂、輸出固定」那一段

傳統表單欄位位置固定，程式靠座標或欄位名稱就能讀。麻煩的是電子郵件、收據、報價單這類文件，句子和版面每次都不一樣。工程團隊過去得補規則、寫解析器、做格式檢查與例外處理；改用大型語言模型讀上下文，拿到的卻是一段自由文字，呼叫端還得確認格式，再回頭核對答案是否真的對得上原文。

Clairic 的用法是：先提供 state（待讀取的文字或圖片），再用 fields 描述要什麼欄位，例如 invoice_number 是文字、due_date 是日期、total 是兩位小數的金額。模型依型別定義回傳欄位值與信心資訊。掃描 PDF 或其他檔案格式，仍須先確認能否轉成受支援的文字或影像輸入，必要時加上轉檔或 OCR 步驟。

用日常比喻：這比較像請一位只負責 key-in 的專員，你給他一張表格規格，他照格填數字並附上「這個值出自原文哪個位置」，而不是請一位會寫長篇報告的顧問再從報告裡撈數字。

抽取、檢索、生成，三種任務常被混在一起

文件抽取回答的是「這張收據的日期和總額是什麼」。RAG 解決的是「去哪裡找資訊」，先從資料庫檢索相關段落，再交給模型組織回答，它不會自動替每個欄位建立可信值。生成模型負責說明、摘要、對話與開放式問題。三者各司其職，RAG 不等於抽取模型，生成模型也不必因此退場。

Cloudflare 在產品公告中展示的分工是：文件送進來，Clairic 抽取欄位與來源位置，程式檢查格式、範圍與必填值，不確定或矛盾的項目交給人工，通過檢查的資料再進資料庫、RAG 索引或後續生成服務。公告中一個客服損壞申訴流程的比較案例，就是 Clairic 抽取、Clef 判斷，再由 GLM-5.3 撰寫回覆，對照組則全程交給大型模型。

這種分工與我們先前分析的把生成模型換成判斷模型是同一個方向：流程中間的判斷與抽取環節，未必要用最通用的生成模型扛。而抽取結果要餵給自動化流程時，替 AI 代理準備獨立沙箱那類執行環境的隔離設計，也會一併進入採購清單。

欄位對了，不代表資料對了

幾個限制必須先放在評估表上。模型可能把格式合理的數字配到錯誤欄位；文字品質差、表格跨頁、日期缺年份時也可能誤判。Cloudflare 文件示範的 span 與字元位置能讓系統回到原文核對，信心分數可以排定人工覆核的優先順序，但它不是正確率保證。

schema 的管理也是隱性成本。日期採哪種格式、幣別怎麼標示、遇到空白或多筆金額怎麼處理，這些規格若各部門定義不一致，即使共用同一個模型，業務解讀也會分歧。高風險金額、合約條款或涉及個人資料的欄位，是否人工確認，取決於錯誤的代價，這是模型供應商無法替你決定的。

快與省的主張，量端到端才有意義

Cloudflare 公布的結果顯示，在其測試流程中，Clairic 與其他模型串接的方案較快且較省。但文件種類、流量規模、前置轉檔步驟、系統架構都會改變結論。合理的評估方式是量測「文件進站到欄位可用」的端到端時間與總成本，包含轉檔、OCR、覆核人力與重跑失敗案例的支出，而非只比單次 API 呼叫的價格。

小規模驗證的做法不複雜：拿一批真實歷史文件，定義好欄位規格，先讓現有流程跑一遍留下基準，再讓抽取模型跑同一批，比對欄位正確率、需要人工介入的比例與總處理時間。這個原則與讀模型評測榜單時的態度一致，分數與規格表之外，自己的資料才是最終裁判。

對正在規劃文件自動化的團隊，判斷順序可以先問三個問題：輸出欄位是否已經明確定義、欄位值能否用規則核對或人工覆核、錯誤的代價有多大。三個答案都清楚，抽取模型值得進入比較名單；若需求是綜合多份資料、解釋原因或撰寫回覆，檢索與生成模型仍有各自的位置。