在文檔抽取項目中，團隊經常從一個看似簡單的循環開始：發現某個字段抽取錯誤，調整提示詞或 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。