在文件抽取專案中，團隊經常從一個看似簡單的迴圈開始：發現某個欄位抽取錯誤，調整提示詞或 schema，重新執行該文件，然後檢查結果。但隨著欄位數量和文件格式成倍增加，這種方法很快變得不可靠。一個改動可能修復了某個欄位，卻在其他地方引入迴歸；可能對一種版式有效，卻在另一種版式上失敗；甚至可能僅僅因為 LLM 執行的正常波動而顯得有所改善。
Databricks 部落格分享了一個近期專案的經驗。該專案需要從合作方提交的訂單文件中抽取大約 40 個結構化欄位，這些文件涵蓋數十種 PDF 版式。稽核人員會在抽取結果進入下游之前進行修正和批准，從而為評估提供了人工稽核的基準資料。團隊面臨的核心挑戰並非讓 ai_extract 返回欄位，而是在不降低系統整體效能的前提下持續改進抽取質量。例如，修訂號欄位有時會返回“ORIGINAL”等狀態詞，而不是修訂號或空值。一個小的 schema 改動將該欄位的錯誤減少了大約一半，但所有欄位的總抽取錯誤卻增加了 9%。這個教訓很明確：改善單個欄位並不一定改善整個抽取系統。
為了解決這個問題，團隊圍繞三個問題構建了工作流：應該改什麼？如何版本化？需要多少證據才能推廣？首先，要選對 ai_extract 的調節槓桿。ai_extract 接收三個輸入：解析後的文件、JSON schema 和可選的全域性指令。schema 定義輸出欄位和欄位級抽取規則，全域性指令則提供適用於整個文件的指導。團隊建議：如果規則定義的是單個欄位，就放入 schema；如果規則定義的是如何理解文件，就放入提示詞。例如，保留前導零、排除狀態詞、在第一個無效字元處停止識別符號、值不存在時返回 null，這些欄位級規則應放在 schema 描述中。而文件或領域上下文、來源優先順序（如頁首優先於頁尾）、跨欄位一致性規則、合併行的指令以及禁止使用的文件區域，則適合放在全域性提示詞中。
其次，並非所有轉換都需要 LLM。大小寫轉換、分隔符移除、補零以及類似將“TELEVISION”對映為“TV”的操作，應儘可能用 SQL 或其他確定性轉換處理。原則是：用模型解釋文件，用程式碼規範化輸出。當文件結構複雜時，比如大型 schema、重複行專案、複雜表格或多頁佈局，ai_extract 2.1 版本提供的 precision mode 可以發揮作用。在提示詞和 schema 保持不變的情況下，precision mode 通常對重複結構幫助最大，並能減少過度抽取，即模型在正確答案應為空時卻返回了值。診斷失敗原因很重要：如果模型誤解了欄位含義，應修改提示詞或 schema；如果模型理解欄位但難以處理資料結構，則應測試 precision mode。
第三，利用 citations 理解欄位為何出錯。citations 提供欄位級邊界框，可對映回源文件中的元素跨度，幫助區分兩類錯誤：抽取錯誤（模型選錯了區域、誤解了欄位或返回了源文件不支援的值）和標註分歧（模型從正確位置抽取，但預期答案遵循不同的稽核慣例）。這兩類問題需要不同的修復方式。抽取錯誤可能需要修改 schema 或提示詞，而標註分歧應透過明確定義稽核指南中的預期慣例來解決。置信度分數可以作為排序訊號，例如優先稽核低置信度欄位，但不應作為自動質量門檻，因為高置信度結果仍可能出錯。
接下來是版本化提示詞和 schema。將提示詞和 schema 硬編碼在筆記本中會帶來摩擦：小的措辭改動需要程式碼部署，歷史版本難以重建，也沒有證據表明新版本優於舊版本。MLflow Prompt Registry 允許將提示詞和 schema 作為獨立於流水線程式碼的可配置、可複用定義進行版本管理。重要的是要同時版本化提示詞和 schema，因為欄位描述對抽取的影響不亞於全域性指令。如果只版本化提示詞，那麼一半的抽取邏輯仍以未跟蹤的程式碼變更形式存在。
一個簡單的別名策略可以使用 @prod 表示當前批准的版本，@candidate 表示正在評估的版本，@scr_* 表示並行比較的實驗版本。流水線透過別名載入活動版本，解析後的提示詞和 schema 再傳遞給 ai_extract。當候選版本獲批時，可以透過 mlflow.genai.set_prompt_alias 將 @prod 移動到新版本，流水線在下一次執行時自動解析，無需修改程式碼。要回滾，只需將兩個別名恢復到之前記錄的版本，底層版本仍保留在登錄檔中。這樣就將抽取配置與執行它的程式碼分離開來。
最後，在推廣之前進行評估。團隊將稽核人員的批准結果組裝成可複用的評估資料集，並與源文件和預測結果配對，形成基準檢視。候選版本需要在固定的人工稽核基準上進行對比，同時追蹤準確率、覆蓋率和執行間波動。這確保了改進是系統性的，而不是區域性的。整個工作流形成了一條從抽取改進提案到生產部署的可重複路徑，並有證據表明改動改善了整個系統。
值得注意的是，團隊不必獨自實現所有這些步驟。Genie Code for document processing 可以構建 Lakeflow 作業（包括 ai_parse_document、ai_classify 以及帶 citations 和置信度分數的 ai_extract），並自動化這一工作流的核心：對照標註表逐欄位評分，提出修復建議（通常是更精確的欄位描述）作為可稽核的差異，並在每次接受更改後重新執行評估，展示前後對比結果。例如，可以要求 Genie Code：“對照我的標註表評估抽取結果，告訴我哪些欄位最弱”，然後要求：“修訂號欄位的準確率可以提高。迭代改進 schema 和指令，重新執行評估，並展示前後對比。”理解基本原理仍然很重要，它有助於判斷 Genie Code 提出的更改、決定何時結果足夠好可以推廣，以及將工作流擴充套件到生產環境，例如在 MLflow Prompt Registry 中版本化提示詞和 schema。