從擷取結果到工單分流，欄位狀態應當對應下一步動作

Red Hat於2026年10月27日介紹了Atos的一項小模型結構化擷取試驗。供應商案例提供了一個觀察入口，但本文不據此判斷模型優劣，而討論擷取結果進入業務紀錄後的一項設計責任。案例原文

一張表格填得整齊，很容易讓接收者以為每一格都經過同樣的判斷。然而，欄位留空可能意味原文沒有提到、系統沒讀到、多個說法無法取捨，也可能意味這個問題根本不適用。這些情況需要不同的後續動作。如果介面只交付一個空白，接收系統就得自行猜測，而猜測往往藏在預設值、重試規則和報表定義裡。

空值怎樣變成業務判斷

下面是一個假設的售後工單流程，並非Atos案例的實施細節。客戶寫道：「上週收到替換件，原來的問題仍在。」擷取程式需要填寫訂單日期、產品型號和故障是否解決。文字沒有給出訂單日期；產品型號可能出現在附件；「仍在」則需要與具體問題關聯。若三個欄位都填成空值，系統既無法知道該索取訂單憑證，還是重新讀取附件，也無法判斷應否繼續處理原故障。

JSON Schema官方文件明確區分了null與屬性不存在。這個技術區別並不會自動替業務狀態命名。團隊仍須約定：缺少屬性表示舊版介面不提供此欄位，還是本次處理沒有執行？明確的空值表示無法確定，還是確認沒有？把這些含義留到串接時再討論，會讓不同使用端各自形成一套答案。

一種可考慮的做法，是為重要欄位同時保存值和處理狀態。狀態可以區分「原文未提供」「存在衝突」「尚未處理」和「有依據的結果」，但不必給所有欄位都配一套龐大列舉。真正需要分開的，是那些會改變下一步動作的情況。低風險標籤或許允許簡單留空；決定退款、資格或帳戶處置的欄位，則值得更細的交接約定。這裡提出的是設計選擇，不是通用產業標準。

保留解釋空白的材料

狀態標籤本身也可能出錯。因此，關鍵欄位最好能回到對應輸入版本和原文位置。保存一段支持材料，並不等於證明判斷正確；它讓覆核人員有機會發現材料是否答非所問、是否漏掉限制條件。對於「未提供」的判斷，還應明確已處理的範圍：正文沒有，不代表未讀取的附件也沒有。

仍以上述工單為例，系統可以把訂單日期標為「正文未提供」，把型號標為「附件待處理」，把故障狀態連到那句客戶描述。這樣，業務佇列能夠分流：第一項可能需要補充材料，第二項需要完成讀取，第三項需要判斷是否足以支持繼續售後。沒有必要要求模型為了完成一張表而替使用者補全日期。保留未知，是把下一項工作交給合適的環節，而不是宣布流程失敗。

這種約定也約束格式清理。把「上週」轉換成日期區間，需要參考日期和時區；把暱稱正規化為客戶姓名，需要身分關聯依據。如果輸出只保留正規化後的值，覆核者很難辨別原文說了什麼、系統補做了什麼。對高後果欄位，保留原始表達、轉換規則版本和結果之間的關係，比單獨保留一個看似標準的字串更有用。

自動化收益要與覆核負擔一起計算

更細的狀態並非免費。它增加儲存、介面和培訓負擔，也可能讓人工佇列膨脹。團隊需要判斷哪些未知值得攔截，哪些可以暫存，哪些不影響目前任務。例如，型號暫缺可能不妨礙登記投訴，卻可能妨礙寄出替換零件。同一個欄位在不同動作前，可以有不同的放行要求；不應把一次擷取的結果當成永久通行證。

衡量改進時，只看欄位填滿率會鼓勵系統把不確定內容寫進去；只看轉人工比例，又可能懲罰合理的謹慎。更有解釋力的做法，是把最終處理結果與當時狀態聯繫起來：哪些「有依據」後來被更正，哪些「未提供」其實源於讀取遺漏，哪些覆核沒有帶來新的可用資訊。這樣的紀錄幫助團隊調整具體環節，而不是把所有失敗都歸到模型能力上。

另一種合理觀點是，早期產品應先用簡單介面驗證需求。對於低後果、可逆且人工逐筆查看的任務，這可以減少過早設計。問題在於，介面常常在沒人宣布的情況下獲得新用途：原本供人參考的欄位被報表引用，再被自動規則使用。若用途變化沒有觸發約定複審，最初可以容忍的含糊就會被放大。

因此，新增狀態或改變空值含義時，需要像修改欄位型別一樣通知下游。可以保留樣例輸入及預期交接結果，檢查升級後使用端是否仍把「未知」解釋為「否」。歷史資料也不應在沒有說明的情況下套用新定義，否則缺失率變化可能只是定義變化，被誤讀為業務改善。

結構化擷取的價值，在於讓文字進入可協作的流程。這個流程需要知道何時能行動，也需要知道何時還缺一份材料。模型可以承擔擷取工作；欄位的含義、允許的預設行為以及未知由誰繼續處理，仍須由使用它的組織明確下來。