Cloudflare Clairic 擷取模型瞄準毋須生成文字的任務

Cloudflare 推出了 Cloudflare Clairic 擷取模型，挑戰了軟件只要向 AI 索取數值，便必須生成文字的假設。這項於 10 月 19 日公布的 Workers AI 預覽版，針對擷取、運算、估算及預測任務。Cloudflare 稱其為 System One 模型，即為快速且有明確範圍的答案而設，而非用於生成冗長回應的模型。

最直接的比較對象是通用語言模型；開發者目前已用它們將文件轉成結構化紀錄。這類模型可在同一次互動中擷取資訊並解釋答案。Clairic 則把產生數值的任務與寫作任務分開，要求開發者判斷每個工作流程實際需要哪一種能力。

這個分野與其說是威脅某個特定聊天機械人，倒不如說更直接地對應用程式設計提出要求。TypeSafe 的 Jev 提供了一個有用參考：它是專為軟件內部決策而設的專門模型。Clairic 將 Cloudflare 版本的這種做法延伸至開發者無法預先列舉的數值。問題在於，當核對、例外情況及人工審核都納入考量後，專門化是否能改善整個工作流程。

Cloudflare Clairic 擷取模型將數值移出文字生成迴圈

Cloudflare 的擷取模型預覽版透過 Workers AI 提供 Clairic，型號為 @cf/cloudflare/clairic。該公司表示，它會回傳具類型的數值，無須生成 token。具類型數值遵循已宣告的格式，例如數字或日期，讓應用程式程式碼取得可預期類型的答案。

這項改變，代表模型與應用程式之間採用了不同的輸出合約。

這份合約之所以重要，是因為軟件通常需要比有幫助的回應更具體的內容。發票處理應用程式需要供應商識別碼、到期日或金額。對話式解釋可以附隨這些欄位，但不能取代它們。在應用程式能夠繼續前，每個欄位都必須進入正確的目的地。

以一個說明性的應付帳款工作流程為例：文件送達後，應用程式識別相關欄位，審核人員在批准前處理差異。若最終目的地是資料庫，中間回應的文字質素貢獻不大。重要的是，正確資訊能否連同足夠可供核查的證據，進入正確欄位。

以數值為核心設計的模型介面，令這項要求變得明確。開發者必須說明所需內容，而非讓應用程式自行從散文中還原。這改變了模糊之處變得可見的位置。定義欠佳的欄位，在成為模型質素問題前，已是應用程式設計問題。

例如，「付款日期」可以指發票到期日、承諾匯款日期，或預計結算日期。三者都可以是有效日期。只有應用程式擁有人能確立紀錄中應採用哪個含義。可預期的格式有助軟件接納答案，而清晰定義則有助它提出正確問題。

這正是 Clairic 結構化擷取值得在其分類名稱以外獲得關注的原因。它提供了一種方式，將所需資訊視為核心介面。模型成為負責填寫已定義欄位的元件，而非預期可解釋一切的助手。

不過，這並不代表 Clairic 是每個文件工作流程的最佳元件。現有系統已可結合文件處理、語言模型及一般程式碼。這次推出帶來另一項架構選擇。其價值取決於該選擇能否在不掩蓋其他地方錯誤的前提下，簡化真實應用程式。

對採購者而言，實際影響是可以提出更具體的採購問題。與其問哪個模型整體最聰明，不如問哪個元件最可靠地處理一項明確任務。只要任務及其失敗條件清晰，這個較窄的問題便較容易評估。

以擷取為主的應用程式面對更具體的採購決定

受影響最直接的團隊，正建立將雜亂資訊反覆轉換為紀錄的應用程式。他們面對的挑戰包括模型選擇，也包括文件準備、驗證、例外處理及整合。專門模型只有在改善這個綜合流程時，才值得佔一席位。

相關的價值單位，是一份獲接納的紀錄，以及建立信任所需的工作。

便宜的模型回應仍可能帶來昂貴的工作流程。審核人員可能要花時間處理不清晰欄位、尋找來源證據，或修正不相符的紀錄。反過來，較耗時的回應若可減少後續介入，也可能值得。只評估模型呼叫本身，會令這些取捨無從看見。

這對將通用生成視為每項任務預設中介層的團隊構成壓力。他們現在有理由區分寫作與資訊傳遞。若應用程式從不顯示生成的回應，團隊便應檢視生成在該步驟實際帶來甚麼貢獻。

答案因情況而異。有些文件包含含義一致、直接明確的欄位；另一些則需要協調互相矛盾的陳述、解讀例外情況，或判斷哪個來源具權威性。擷取介面可表達目標欄位，但不會自動解決來源中的每項分歧。

這項差異影響機構如何分工。專門元件可處理例行紀錄，而較廣泛的模型則檢視不尋常個案。另一種做法是，先由語言模型識別相關文件脈絡，再由另一個元件填寫欄位。合理界線應跟隨任務，而非偏好某個模型類別。

企業採購者亦應將可驗證行為與架構承諾分開看待。整潔的回應格式可在小規模測試中觀察到；要在不斷改變的文件版面中維持可靠表現，則需要更廣泛的證據。關於營運節省的聲稱，亦須有周邊流程的證據支持，包括維護所需的工作量。

對知識工作者而言，也有類似分野。結構化紀錄可令資訊更易篩選、比較及重用，但精簡欄位亦可能刪去重要限定條件。從會議記錄擷取的項目截止日期，或會取決於其他地方提及、尚未解決的決定。

對建立可搜尋知識庫的團隊而言，這帶來一個有用的設計問題：哪些事實應成為欄位，哪些需要保留周邊脈絡？搜尋與結構化擷取服務相關目的，但保留原始材料的不同面向。

因此，短期壓力落在應用程式擁有人及整合商身上。他們必須解釋每個階段為何需要所選模型。即使尚未有足夠獨立證據，為 Clairic 與替代方案在各行業中的表現作排名，這已是一項具體的採購及工程決定。

Clairic 與語言模型之比較，關鍵在於生成應置於何處

Clairic 與語言模型比較中最有力的版本，承認通用系統已具備的能力。Anthropic 的結構化輸出文件描述受 schema 約束的回應，即受已宣告資料結構限制的回應。這類功能已處理許多格式及解析問題。

Clairic 的競爭論點，必須超越回傳可供軟件解析的資料。

定義回應允許結構及類型的 schema，為生成式模型設定了較窄的輸出目標。這使結構化生成成為嚴肅的比較基準。若只將專門擷取器與不受約束的散文請求比較，便會忽略既有替代方案。

架構上的分野仍然相關。Cloudflare 稱 Clairic 會在不生成 token 的情況下回傳數值。通用模型會生成回應，同時提供超越填寫欄位的能力。比較時應檢視，在雙方都接收清晰定義任務時，各自的做法有何貢獻。

文件工作流程說明了這點為何重要。讀取訂單識別碼與草擬客戶回覆是兩項不同工作。前者在來源中有具體目標；後者則需要措辭、語氣，以及判斷客戶需要甚麼資訊。

把兩項工作結合於一次呼叫中可能很方便；把它們拆開，則可令每個階段更易檢查。兩種安排都不會自動勝出，因為交接本身引入責任。應用程式必須保留正確脈絡，並避免將中間數值視為毋庸置疑的事實。

TypeSafe 的System One models發布，為這種分工提供了較早的參考。創辦人 Diogo Almeida 將 Jev 介紹為用於軟件內結構化決策的模型。其角色與擷取開放式數值不同，但兩種方法都強調應用程式邏輯可直接使用的輸出。

有用的產業發展，是可供選擇的元件更為廣泛。應用程式可將欄位擷取、決策及寫作分派給不同系統。這讓開發者更能控制在哪裏運用模型能力，同時也提高了各階段之間清晰介面的重要性。

讓通用模型在較大範圍內發揮作用，也有合理理據。經常出現例外情況的工作流程，或可受惠於同時解讀文件及解釋差異。過度拆分流程，可能迫使應用程式重建原本較廣泛模型已掌握的脈絡。

因此，正確比較亦包括整合複雜度。表現良好的獨立模型，部署時可能需要額外路由、儲存或監控。較廣泛的模型可能較易整合，卻會在例行請求上進行不必要工作。這些都是相互競爭的營運成本。

Clairic 與語言模型最好被視為工作負載問題。任務決定生成是必要、有用，還是附帶的。這種框架避免作出專門模型將淘汰通用系統的錯誤預測，也避免假定熟悉的聊天介面必然屬於每個自動化流程。

Clairic 結構化擷取令來源證據成為介面的一部分

Clairic 模型參考文件記錄了文字及圖片輸入、信心資訊，以及具類型欄位定義。擷取出的文字可包含字元偏移量，用以識別其在輸入內容中的位置。參考文件亦說明，當欄位定義無法與狀態並列時，系統會進行平行處理。

營運上的機會，在於讓回傳值更容易檢視及分流處理。

對審核人員而言，答案與其來源位置各有不同用途。答案說明系統選取了甚麼；位置則協助審核人員檢視該選擇為何可能合適。同時保留兩者，可讓分歧更容易解決。

試想一則支援訊息同時包含原本的送貨地址及替代地址。兩者都是來源中的真實文字。欄位可以準確複製其中一個地址，卻仍可能為當前要求選錯地址。要作出檢視，便需要了解客戶意圖及應用程式規則的脈絡。

這正是 Clairic 的結構化擷取不再只是格式討論之處。有用的記錄應攜帶足夠資訊，以支援下一步行動。視乎應用程式而定，這可能包括原始文件、欄位定義或審核狀態。模型的答案只是該記錄的一部分。

開發人員亦需要區分「衍生」一詞的多種含義。讀取已陳述的數量，與計算總額不同；預測未來結果亦與兩者不同。即使它們的證據基礎有所不同，共用介面仍可能令這些輸出看起來相似。

擷取出的期限可根據合約中的句子核對。計算出的期限則取決於正確的起始日期及規則。預計完成日期則取決於對未來行為的假設。應用程式向使用者呈現結果時，應保留這些分別。

否則，共通資料格式的便利性可能造成不恰當的確定感。無論日期如何得出，顯示出來都看似精確。審核人員需要知道，他們是在核實來源陳述、檢查計算，還是評估預測。

這對產品設計有所啟示。介面可將擷取出的事實與其原始脈絡一併顯示，同時把估算結果呈現為具不確定性的規劃輸入。這些差異有助使用者採取恰當程度的審視，也可防止預測結果悄然進入原本預期接收有文件佐證事實的系統。

同一原則亦適用於資訊在工具之間流動的情況。當不確定的數值進入下游記錄而未附帶其狀態，後來的使用者便可能將其視為已確立的事實。保留欄位的含義，與保留其資料類型同樣重要。

模型介面為這個流程提供了組成元素。應用程式團隊仍須決定保留哪些證據、如何呈現不確定性，以及何時需要審核。這些決定將影響專門化是否能改善使用者體驗。

有效欄位仍未能解決算術、歧義及預測問題

Cloudflare 的 Clairic 推出分析將此端點稱為早期檢查點。該公司指出多步算術及彙總方面的弱點，形容預測功能仍屬基礎，並警告不熟悉資料上的不確定性區間可能過窄。該公司亦表示，開放權重仍在計劃中，尚未推出。

有效結果只證明其形式成立；正確性仍須以獨立證據證明。

Cloudflare 的 擷取模型限制明確作出這項區分。文件指出，類型與限制條件並不能保證答案正確，亦警告當輸入提供的資訊有限時，估算及預測可能回傳推測結果。

這些提醒收窄了對此推出的適當解讀。專門介面不會消除底層工作的不確定性。它只是讓應用程式能以更可預測的方式接收結果，而開發人員仍須決定該結果可支持甚麼判斷。

算術提供了一個尤其清楚的例子。若應用程式具備可信的數量資料及明確公式，一般程式碼便可提供可檢視的計算。當輸入資料雜亂時，要求模型推斷結果可能有用；但一旦識別出輸入資料，精確計算便值得獨立處理。

更困難的問題往往在於是否選取了正確輸入。文件可能同時包含原始金額、修訂金額及抵免額。即使對錯誤組合作出完美算術運算，結果仍然錯誤。評估需要獨立檢視詮釋與計算。

預測又增加一層複雜性。模型可以回傳格式整齊的預測，卻未必有足以支持營運決策的強力證據。買家應詢問哪些資訊會改變預測，以及誤差會如何影響預定用途。

例如，一項示範性的人手預測可以為規劃討論提供參考，而不會直接編排輪班。當同一預測自動更改員工工作時間表時，其後果便更為重大。輸出本身沒有改變，但應用程式所需的保證程度已改變。

信心分數亦需要同樣審慎對待。校準是指，在可比較個案中，報告的不確定性與觀察到的結果大致相符。某一資料集上的可信分數，並不能證明在文件格式、語言或業務條件改變後，仍有同等表現。

本文未找到任何獨立 Clairic 評估，足以驗證其在這些條件下的表現。現有官方材料說明了產品及其預期行為，卻未能確定它在買方完整文件處理流程中的實際表現。

這讓樂觀與懷疑都有空間，而無須虛構爭議。專門擷取處理的是一個明確可辨識的軟件問題。尚未解決的問題是，部署後該問題有多少會消失，又有多少會轉移到欄位設計、評估及審核之中。

因此，考慮 Cloudflare Clairic 擷取模型的團隊，應區分較整潔的介面與已獲證實的可靠性。兩者都重要，但需要不同證據。示範可以即時展示介面；營運可靠性則會透過對具代表性、經獨立核實記錄的重複使用而逐漸呈現。

留意獨立評估、開放權重及生產環境使用情況

最有用的下一批訊號，將涉及獨立測試、承諾中的權重發布，以及已部署應用程式的證據。每項都針對託管預覽版本與成熟基礎設施選擇之間的不同差距。合併來看，它們可顯示這類模型是否帶來實際效益。

下一步證據應把模型行為，連結至應用程式實際需要完成的工作。

首先是獨立評估。有用的測試應比較專門擷取系統與結構化生成系統在同等工作上的表現，並應公開欄位定義、文件條件及評分規則。否則，比較可能只是對同一要求的不同詮釋作出獎勵。

評估亦應區分容易處理的記錄與含糊的記錄。整體準確率可能掩蓋錯誤是否集中在後果重大的欄位上。一個通常能正確讀取文件標題的系統，仍可能難以處理修訂後的期限或互相衝突的金額。買家需要反映其實際風險的結果。

若有證據顯示其在不熟悉文件上表現強勁，將加強更廣泛採用的理據。若證據顯示成效取決於狹窄的版面配置，則支持較有限的角色。無論結果如何，都有助開發人員為模型選擇合適的使用邊界。

承諾中的開放權重發布是下一個訊號。開放權重是可下載的模型參數，在受制於授權及技術要求下，可讓模型部署於原本託管服務以外的環境。其發布將為獨立檢查及實驗帶來更多機會。

重要細節包括授權條款、硬件要求、部署工具，以及與託管版本的一致性。單是可供取得，並不能證明獨立運行模型具實際可行性。這些配套細節決定哪些機構能真正有效使用它。

附有清晰文件的發布，將提升這個類別的可及性。長期延遲則會令評估更依賴託管端點。兩者都不能單獨決定擷取品質，但都會影響誰能研究它。

最後一個訊號是生產環境使用情況。最有力的案例會說明哪些工作流程有所改變、如何處理審核，以及例外情況如何處置。案例亦應包括當傳入文件改變時，維護欄位定義所需的工作量。

若報告處理時間縮短，同時提供獲接受記錄及審核人員工作量的證據，說服力會更強。若其他環節的修正工作增加，更快的中間回應價值便較低。相反，若人工介入持續減少，便支持專門化的實際價值。

對開發人員而言，下一步是找出一個預期答案及失敗後果都清晰、範圍受控的工作流程。將專門擷取與應用程式現有的結構化生成方法比較。把具代表性的困難文件保留在評估中，並保留足夠來源脈絡以調查分歧。對買家而言，應要求供應商把模型聲稱與獲接受記錄、審核工作量及例外處理連結起來。Cloudflare Clairic 擷取模型令輸出介面的選擇更明確，但該選擇仍需要周邊系統的證據支持。檢視你的應用程式在哪些地方需要一個數值、在哪些地方需要解釋，以及這些工作是否應歸於同一系統。哪個階段可受惠於較專門的模型，同時不會令最終結果更難信任？