From spot fixes to measured gains: improving document extraction accuracy with ai_extract and MLflow Prompt Registry

从临时修复到可衡量的提升：使用 ai_extract 和 MLflow Prompt Registry 提高文档提取准确性 | Databricks 博客

跳至主要内容

工程

2026年10月27日

从临时修复到可衡量的提升：使用 ai_extract 和 MLflow Prompt Registry 提高文档提取准确性

如何提升 ai_extract 准确性、版本化提示词和模式、评估结果，以及 Genie Code 如何为您自动化这些流程

Kristen Drexinger 和 Seshendranath Balla 撰写

摘要

• 您无需独自完成所有工作：Genie Code 文档处理功能可自动化该工作流程的核心部分，通过与标注数据逐字段比对评分、以可审查的差异形式提出模式和指令修正建议，并重新运行评估以展示修改前后的效果。

• 通过正确杠杆提升 ai_extract 准确性：使用字段级规则的模式描述、文档级逻辑的提示词、结构复杂度的精确模式以及引用信息进行错误诊断。

• 使用 MLflow Prompt Registry 版本化提示词和模式：将提取逻辑作为版本化工件进行跟踪，通过别名而非修改流水线代码来部署或回滚更改。

• 在推广前评估变更：在跟踪准确率、覆盖率和运行间差异的同时，将候选方案与固定的人工审核基准进行对比。

文档提取通常始于一个简单循环：发现错误字段、调整提示词或模式、重新运行文档并检查结果。

当字段和文档格式增多时，这种方法会变得不可靠。一个更改可能修复一个字段却在其他地方引入回归问题，适用于一种布局却在另一种布局上失败，或仅仅因为LLM运行间的正常差异而显得更好。

我们在最近一个项目中观察到这种情况，该项目从合作伙伴提交的订单文档中提取了约40个结构化字段，涉及数十种PDF布局。审核人员在数据流向下游前修正并批准提取值，为我们提供了人工审核的基准数据用于评估。

挑战不在于让 ai_extract 返回字段，而在于在不降低系统整体性能的前提下提升提取效果。

例如，修订字段有时会返回状态术语如 ORIGINAL 而非修订号或留空。一个微小的模式更改将该字段的错误率减少了约一半。但所有字段的总提取错误率却增加了9%。

这个教训非常明确：改进一个字段不一定能提升整个提取系统。

流水线已经具备了系统评估变更所需的大部分组件。文档存入对象存储后，通过 Lakeflow SDP 流水线处理，使用 Auto Loader。Bronze 层使用 ai_parse_document 解析文档，Silver 层使用 ai_extract 提取结构化字段，Gold 层将结果发布为物化视图。预测结果同步到 Lakebase，Databricks 应用允许审核人员修正和批准字段，Lakebase CDC 将这些批准反馈回湖仓。

图1. 带有人工审核的文档提取流水线。提示词和模式在 Silver 层硬编码，审核人员的修正尚未用于评估提取变更。

反馈循环缺少两个关键部分。审核批准虽然可用，但尚未整合为可复用的评估数据集。同时，提示词和模式直接嵌入流水线代码中，因此即使是对提取的微小更改也需要代码部署。

我们通过围绕三个问题构建一个工作流程来解决这两个问题：我们应该改变什么？应该如何进行版本控制？以及需要哪些证据才能推动实施？

本文涵盖该工作流程的三个部分：

• 通过正确的方式改进 ai_extract：使用模式定义字段规则，用全局指令处理文档逻辑，对复杂结构使用精确模式，并通过引用诊断错误。

• 对提示和模式进行版本控制：将两者存储在 MLflow Prompt Registry 中，并使用别名部署或回滚配置，而无需编辑流水线代码。

• 在推广前进行评估：在固定的、经过人工审核的真实数据集上比较候选方案，跟踪准确性、覆盖率和运行间差异。

这些步骤共同创建了一个从提议的提取更改到生产环境的可重复路径，并提供证据证明更改确实提升了整体系统性能。

从 Genie Code 开始

本文其余部分将逐步介绍我们推荐的实践及其重要性。你无需自行实现所有内容。Genie Code 为文档处理构建了 Lakeflow 作业（ai_parse_document、ai_classify 和 ai_extract 带引用及置信度评分），并通过评估和爬山循环自动化该工作流程的核心：

• 测量：将当前提取结果逐字段与你的标注表进行评分，让你清楚哪些字段表现较弱。

• 改进：提出修复方案（通常是更精确的字段描述），以可审核的差异形式呈现，你批准后才会应用。

• 重新评估：在每次接受更改后重新运行评估集，并显示改进前后的结果，使回归问题与改进一样显而易见。

例如，你可以向 Genie Code 提问："将提取结果与我的标注表进行对比，告诉我哪些字段最弱"，随后可以继续："修订字段的准确性还有提升空间。迭代改进模式和指令，重新运行评估，并向我展示改进前后结果。"

理解基础原理仍然至关重要。它能帮助你判断 Genie Code 提出的更改是否合理，决定何时结果已足够好可以推广，以及如何扩展该工作流程用于生产环境（例如通过在 MLflow Prompt Registry 中对提示和模式进行版本控制）。以下每个部分都会解释推荐的实践，并说明 Genie Code 如何帮你处理这些内容。

选择正确的 ai_extract 杠杆

ai_extract 接收三个输入：解析后的文档、JSON 模式和可选的全局指令。

模式和指令有不同的用途：

• 模式：定义输出字段和字段特定的提取规则。

• 全局指令：提供适用于整个文档的指导。

$

/$

结果是一个结构化值，每个模式字段对应一个条目。你可以直接访问单个字段，例如：extracted:response.revision.value 。

将字段特定规则放入模式中

从模式结构开始。当字段具有封闭的有效值集合时，使用 enum 约束而非在描述中列出允许的值。对数字和整数使用数值类型，对重复结构使用嵌套数组或对象。

然后使用模式描述定义类型本身无法表达的规则，例如：

• 在标识符（如 004）中保留前导零

• 排除状态术语（如 ORIGINAL、NEW 或 REVISED）

• 在遇到第一个无效字符时停止标识符

• 当值不存在时返回 null

KEY : 将字段规则保留在模式中，使提取合同更易于检查，并防止全局提示变成无关例外的列表。

使用全局提示进行文档级推理

将全局提示保留用于适用于整个文档的规则，包括：

• 文档或领域上下文
• 源优先级，例如页眉优先于页脚
• 跨字段一致性规则
• 合并行到数组的指令
• 不应作为来源使用的文档区域

例如，如果实体名称被错误地从模板页脚或第三方联系块中提取，FORBIDDEN-SOURCES 指令可以告诉模型忽略这些区域。

一条有用的规则是：如果规则定义了一个字段，将其放入模式；如果规则定义了如何解释文档，将其放入提示。

通过 Genie Code 自动化：爬山循环遵循相同原则。其提出的修复方案通常会优化模式中的字段描述，并以差异形式展示供你批准后应用。

保持下游确定性格式

并非所有转换都需要使用大语言模型。在可能的情况下，使用 SQL 或其他确定性转换来处理大小写转换、分隔符移除、零填充以及 TELEVISION 到 TV 等映射。

KEY : 使用模型解释文档；使用代码规范化输出。

对结构问题使用精度模式

有时指令是明确的，但文档难以遵循。大型模式、重复的行项目、复杂的表格和多页布局会使保持值与正确行对齐变得困难。

针对这些情况，ai_extract 2.1 版本提供精度模式：

精度模式为更苛刻的使用场景带来了前沿提取能力。在保持提示和模式不变的情况下，它在重复结构上效果最佳，并能减少过度提取（模型在应为空的字段返回值）。

在更改配置前诊断失败原因：

• 如果模型误解了字段含义，修改提示或模式。
• 如果模型理解字段但难以处理数据结构，测试精度模式。

这两种方法是互补的。在我们的测试中，模式规则修正了模型误解的字段，而精度模式提升了从复杂表格中提取字段的准确性。

使用引用理解字段错误的原因

当提取值错误时，引用信息能帮助显示模型找到答案的位置：

引用信息提供字段级边界框，可映射回源文档中的元素跨度。这有助于区分两种不同类型的错误：

• 提取错误：模型选择了错误区域、误解了字段，或返回了源文档不支持的值。
• 标注分歧：模型从正确位置提取，但预期答案遵循了不同的审阅者惯例。

这些错误需要不同的修复方案。提取错误可能需要修改模式或提示；标注分歧应通过在审阅者指南中定义预期惯例来解决。

置信度评分也能帮助优先安排人工审核：

将其作为排序信号使用（例如优先审核低置信度字段），而非自动质量门禁。高置信度结果仍可能是错误的。

在 Genie Code 中：Genie Code 构建的提取任务包括引用和置信度评分。你可以要求它“根据评估结果为每个字段设置置信度阈值，并将低置信度行路由到审核”，并使用文档解析 UI 可视化调试解析和提取过程。

一起对提示和模式进行版本控制

通过将提示和模式作为可配置、可重复使用的定义管理在流水线代码之外，减少在笔记本中硬编码提示和模式的摩擦。一个小小的措辞更改需要代码部署，旧版本难以重建，也没有证据表明新版本优于旧版本。

MLflow 提示注册表允许你将这些输入与流水线代码分开进行版本控制。对提示和模式都进行版本控制：字段描述对提取的影响与全局指令一样显著。仅对提示进行版本控制，你提取逻辑的一半仍然会以未跟踪的代码更改形式存在。

超越 Genie Code 的循环：Genie Code 帮助你找到合适的提示和模式。当你将该配置投入生产时，版本控制使你能够在不进行代码部署的情况下推广和回滚更改。

一个简单的别名策略可能如下：

• @prod 表示当前已批准的版本
• @candidate 表示正在评估的版本
• @scr_* 表示正在并行比较的实验版本

然后流水线通过别名加载活动版本：

解析后的提示和模式随后传递给 ai_extract。

当候选版本获得批准时，mlflow.genai.set_prompt_alias 可以将 @prod 移动到新版本。流水线在下一次运行时会自动解析新版本，无需更改流水线代码。要回滚，只需将两个别名恢复到之前记录的版本。底层版本仍保留在注册表中。

这将提取配置与运行它的代码分离。图 2 还补充了另一个缺失的部分：可重复使用的黄金标准。

图 2。Silver 从注册表中读取已批准的提示和模式。审核人员的签核为黄金标准视图提供数据。

黄金标准视图将已批准的标签与源文档和预测结果配对，创建用于衡量变化的参考数据集。

以固定黄金标准评估候选方案

版本历史告诉你发生了什么变化。但它无法告诉你变化是否更好。从审核人员批准的结果中构建一个固定的样本集；我们的样本集包含数百个涵盖多种布局的 PDF。将生产提示和每个候选提示在相同的测试集上进行评分。

对每个版本，跟踪以下指标：

• 总体和字段级准确性
• 黄金标准覆盖率
• 不同文档类型的性能
• 运行间差异

在比较过程中保持文档和指标定义的一致性。否则，评分变化可能反映的是测试集或评分规则的不同，而非提取配置的不同。

在 Genie Code 中：将 Genie Code 指向你的标记表格（例如图 2 中的黄金标准视图），并要求它评估提取结果。它会对每个字段进行评分，并在每次接受更改后重新运行相同的评估集，因此前后对比使用相同的文档。下面的噪声基线、覆盖率和判断检查是将更改投入生产时有用的防护措施。

考虑正常的 LLM 变化

一个候选模型的得分略微提高并不意味着它更好。在冻结的测试集上至少运行生产配置3-5次，计算其平均准确率和标准差（σ）。这个σ值就是你的噪声基线。你的策略可能要求候选模型的改进必须超过2σ才能视为有意义；任何处于该范围内的变化都属于无法确定结果，而非真正的提升。

与准确率一同跟踪覆盖率

如果忽略缺失预测，准确率也可能具有误导性。

假设你只对模型和审阅者都提供了值的字段进行评分。一个候选模型在遇到困难字段时留空，可能会因为这些缺失值从分母中消失而显得更准确。相反的情况也可能发生。当我们仅在审阅者提供了修订值的文档上对修订字段进行评分时，我们的修复措施似乎只提升了不到3个百分点的准确率。但当我们统计所有错误（包括正确答案为空的情况）时，该修复措施将修订错误减少了约一半。大部分改进来自于在本应为空的字段上正确返回无值。

这就是为什么覆盖率应与准确率一同报告。明确其定义，例如定义为模型返回预测值的非空真实字段占比。如果准确率上升但覆盖率显著下降，请在推广候选模型前进行调查。

由此产生的框架遵循可重复的流程：冻结测试集，建立生产基线，在筛选别名上注册候选模型，运行重复评估，并比较准确率、覆盖率和稳定性。

图3：评估流程：冻结测试集，测量生产基线，筛选候选模型，并比较准确率、覆盖率和稳定性。

将每次评估结果总结为判断结论

一旦测量了准确率、覆盖率和运行间差异，你的评估框架可以将这些指标简化为一组结果：

• BETTER：准确率超过预定义阈值，覆盖率保持稳定，结果稳定。
• SUSPECT：准确率提升，但覆盖率显著下降。
• UNSTABLE：不同运行之间的结果差异过大。
• INCONCLUSIVE：差异过小，无法与正常波动区分。
• WORSE：准确率显著下降。

这些判断结论为评估结果提供了统一的总结方式，以便决定是否将候选模型推广到生产环境。

跟踪修订更改的影响

我们对每个候选模型在相同测试集上进行了三次评分，统计所有字段的错误数，相对于原始提示和模式。

| 更改 | 修订 | 错误 | 所有字段的错误 | 判断 | |------|------|------|----------------|------| | 模式修复（仅模式） | -49% | +9% | TARGET_IMPROVED_WITH_REGRESSION | | 重构提示和模式 | -57% | -16% | BETTER | | 仅精度模式（无提示或模式更改） | -10% | -24% | - | | 重构提示和模式 + 精度模式 | -64% | -32% | - |

针对修订字段的局部修复达到了预期效果，但模型开始在无关的明细字段（如日程细节）中编造值。修改一个字段的描述并不是单字段实验：模型会整体阅读模式。

因此我们没有部署该修复。

相反，我们将字段特定规则从全局提示中移出，放入模式描述中，包括相同的修订规则。提示的长度最终缩短到原来的不到一半，总体错误减少了16%，估计错误减少了30%。

两个字段的性能下降，因此被列入下一轮的目标列表。

精度模式呈现出不同的效果。在没有提示或模式变更的情况下，它将错误率降低了24%，主要是不再在重复的明细字段中虚构值。但由于修订错误本质上是定义问题，只有模式规则能解决，因此精度模式对这类错误的改善微乎其微。

两者结合使用效果更显著：在重构后的提示和模式基础上叠加精度模式，又消除了剩余错误的19%。总体而言，错误率下降了约三分之一（32%），修订错误率更是下降了近三分之二（64%）。

这就是Genie Code的回归循环机制旨在揭示的问题。由于每次接受更改后都会重新运行完整的评估集，因此那些虽然改善了修订但损害了明细字段的局部修复，会体现在评估结果的对比中，而不是直接进入生产环境。

图4。在MLflow中，每位候选者的三次运行结果与原始配置并列显示。每次运行都会记录其提示版本、模式版本和引擎信息，因此每个结果都可以追溯到产生它的具体配置。

将评估转化为推广决策

评估结果只是决策的起点，而非最终结论。

早期一位候选者将估算错误降低了约三分之一，但整体评估结果仅为"INCONCLUSIVE"。它还开始在几乎所有文档中填充一个"是/否"标志字段，而审阅者仅在少数文档中标注了该字段。

某个字段出现严重退化时，即使总体指标看似合理，也可能阻止推广。因此推广决策应始终由人工控制。

如果候选者被归类为"BETTER"，所有者可以更新@prod别名并记录候选版本、评估指标、作者和时间戳。

在某些情况下，推广"INCONCLUSIVE"变更也是合理的，例如实施了聚合准确率未能完全体现的重要业务规范。此时记录覆盖原因可以保留决策依据。

通过该评审和别名更新，反馈闭环得以闭合：

图5。完整闭环：审阅者批准成为真实数据，框架评估候选者，所有者推广已批准的提示-模式组合。新的流水线初始化加载新版本。

构建可重复的提取工作流

可靠的文档提取不是寻找一个完美提示，而是选择合适的变更、追踪变更内容，并测试结果是否改进。

使用ai_extract意味着：用模式描述定义字段级行为，用全局指令处理文档级推理，在结构成为瓶颈时启用精度模式，在需要理解提取失败原因时使用引用。

MLflow提示注册表为您提供版本化路径来管理提示和模式，而固定的评估测试集则为您提供决定哪些内容应进入生产的证据。

这些要素共同将提示迭代从零散的单次编辑转变为可重复的工程工作流。

Genie Code文档处理自动化该循环的核心（测量、改进、重新评估），因此大多数团队可以从这里起步，随着流水线进入生产环境，再逐步添加提示注册表版本控制、噪声基线检查和推广门禁等环节。

查阅 Databricks AI Functions 文档以了解 ai_extract 的更多用法，查看 MLflow Prompt Registry 文档以实现提示词版本管理和别名管理。尝试使用 Genie Code 进行文档处理。从 Jobs 和 Pipelines 打开 Genie Code，将其指向您的文档和标注表格，让它为您评估并优化提取效果。

相关标签：

解决方案、客户案例、最佳实践、媒体与娱乐、数据科学与机器学习

订阅以获取最新文章

订阅我们的博客，最新文章将直接发送到您的邮箱。

立即订阅

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"