Databricks发布文档抽取工作流：用MLflow Prompt Registry版本化提示词与Schema
Databricks博客介绍一套文档抽取改进流程：把字段规则写进JSON schema、把文档级判断放进全局提示词，并将提示词与schema一起存入MLflow Prompt Registry，用固定的人工标注测试集评估后再决定是否上线。文中引用一个约 40 个字段、数十种PDF版式的项目数据。
AI解读：Databricks博客描述了一个从合作方提交的订单文档中抽取约 40 个结构化字段的项目，文档版式有数十种，审阅者会修正并批准抽取结果，形成人工审核过的评测真值。
博客称，针对revision字段的小幅schema修改让该字段错误约减半，但全部字段的总错误增加 9%，因此团队没有上线这次修改。
改用重构后的提示词与schema后，博客称总错误下降 16%、估算类字段错误下降 30%；仅启用precision mode（不加提示词或schema改动）总错误下降 24%；两者叠加后总错误下降约 32%、revision错误下降约 64%。
上述数字是博客给出的单项目评测结果，三次运行于同一测试集，并非跨客户或跨数据集的普遍结论。
方法上，博客建议字段级规则写入schema描述，文档级规则放入全局提示词，结构化对齐困难时试用ai_extract 2.1的precision mode，并用citations区分抽取错误与标注口径分歧。
评估环节要求冻结测试集，先跑生产配置 3 至 5 次得到均值与标准差作为噪声下限，同时报告覆盖率，并把结果归类为BETTER、SUSPECT、UNSTABLE、INCONCLUSIVE、WORSE，最终由人决定是否把 @prod别名指向新版本。
Databricks在博客中介绍了一套改进ai_extract文档抽取准确率的流程：把提示词与JSON schema一起放进MLflow Prompt Registry版本化管理，在固定的人工审核测试集上评估候选改动，再通过别名切换上线或回滚，而不是每次改动都发布管道代码。
文章以一个抽取约 40 个结构化字段、覆盖数十种PDF版式的合作方订单文档项目为例，说明单点修复可能带来其他字段的回退。
单字段修复导致总错误上升
博客描述的最初做法是：发现某个字段抽错，就调整提示词或schema，重跑文档检查结果。当字段和文档格式变多后，这种做法不再可靠：一处改动可能修好一个字段、在别处引入回退，也可能只是LLM多次运行间的正常波动。
示例是revision字段有时返回ORIGINAL等状态词，而不是版本号或空值。博客称，一处小的schema修改让该字段错误减少约一半，但所有字段的总抽取错误上升了 9%，模型开始在schedule details等无关行项目字段中编造值。团队因此没有上线这次修改。
schema、全局提示词与precision mode的分工
ai_extract接收三个输入：解析后的文档、JSON schema和可选的全局指令。博客建议把只定义一个字段的规则放进schema描述，例如保留标识符前导零、排除ORIGINAL等状态词、值不存在时返回null；把跨字段一致性、来源优先级（如页眉优先于页脚）、禁止作为来源的区域等文档级判断放进全局提示词。大小写、分隔符去除、零填充等格式化转换则交给SQL等确定性处理。
对于大schema、重复行项目、复杂表格和多页版式导致的结构对齐问题，博客建议测试ai_extract 2.1的precision mode。文章称，在提示词和schema不变的情况下，precision mode主要改善重复结构的抽取，减少“正确答案为空却返回了值”的过度抽取。
博客还提到citations会给出字段级bounding box，可映射回源文档元素，用来区分两类错误：模型选错区域或误解字段的抽取错误，应改schema或提示词；模型位置正确但审阅者口径不同的标注分歧，应改审阅指南。置信度分数被建议用作人工复核的排序信号，而非自动质量门槛，因为高分结果仍可能错误。
版本化与评估数字
博客指出，提示词和schema原先硬编码在管道的Silver层代码里，小改动也要走代码部署。使用MLflow Prompt Registry后，两者可独立于代码版本化，并用 @prod、@candidate、@scr_* 等别名区分已批准版本、评估中版本和并行实验版本；批准后通过set_prompt_alias移动 @prod，管道下次运行即解析到新版本，回滚则恢复两个别名到此前记录的版本。
评估要求使用固定测试集，博客中的规模是数百份PDF。每次评估需跟踪整体与字段级准确率、真值覆盖率、按文档类型的表现以及运行间波动，并保持文档和指标定义一致。博客建议先跑生产配置至少 3 至 5 次，计算均值与标准差 σ 作为噪声下限；候选改动需超过 2σ 才视为有意义，落在带内的结果记为不确定。
博客给出的对照结果如下，每项候选在同一测试集上评估三次，统计全部字段错误：
- 仅revision schema修复：revision错误 -49%，全部字段错误 +9%，结论为有回退的定向改善。
- 重构提示词与schema：revision错误 -57%，全部字段错误 -16%，判定BETTER；博客称提示词长度降到原来不到一半，estimate错误下降 30%，另有两个字段变差被列入下一轮。
- 仅precision mode、不改提示词和schema：revision错误 -10%，全部字段错误 -24%，判定BETTER。
- 重构提示词与schema再加precision mode：revision错误 -64%，全部字段错误 -32%，判定BETTER。
覆盖率与人工放行
博客提醒，只统计模型和审阅者都给出值的字段，会让“把难字段留空”的候选显得更准确。同一revision修复若只算审阅者给出值的情形，准确率提升不到 3 个百分点；计入正确答案为空的全部错误后，revision错误约减半，改善主要来自正确返回空值。因此覆盖率需与准确率同时报告，例如定义为模型对非空真值字段给出预测的比例。
评估结果被归为BETTER、SUSPECT（准确率升但覆盖率明显降）、UNSTABLE（多次运行波动过大）、INCONCLUSIVE（差异太小）和WORSE五类，但博客强调分类只是决策起点。单个字段的严重回退可阻止上线，即使总体指标尚可；最终是否把 @prod指向候选版本仍由人控制，并记录版本、指标、作者、时间戳，若在INCONCLUSIVE情况下因业务约定上线，也需记录覆盖理由。
博客同时提到Genie Code可自动构建包含ai_parse_document、ai_classify、ai_extract的Lakeflow作业，并执行“测量—提出修复—重跑评估”的循环，但文章未给出该工具本身的独立效果数据。