在文档抽取项目中，团队经常从一个看似简单的循环开始：发现某个字段抽取错误，调整提示词或 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。