企业文档抽取项目里最容易被高估的是 OCR。OCR 可以把扫描件和图片中的文字转成可读取内容但业务真正需要的通常是字段化结果合同编号、主体名称、金额、日期、条款状态或表格中的指定列。只有文字没有字段语义和质量控制数据仍然很难进入后续流程。从工程视角看文档信息抽取是一条从非结构化输入到业务 Schema 的转换链路。要提高结果可用性需要同时处理文档预处理、字段定义、抽取策略、规则校验、人工复核和结构化交付。先定义输出 Schema再选择抽取方式抽取目标不清是很多项目反复返工的原因。不同团队对“日期”“金额”“主体”的理解未必相同日期可能是签署日、生效日或到期日金额可能包含含税金额、未税金额、币种和大写金额主体也可能包含甲方、乙方、开票方和收款方。因此第一步应当定义业务 Schema而不是直接让系统从文件中“找关键信息”。一个可执行的 Schema 至少要描述字段名、数据类型和是否必填。字段的业务含义与优先级。合法格式、取值范围或枚举关系。多个候选值同时出现时的选择规则。字段来源位置与原文引用要求。例如contract_amount除了数值本身还可能需要输出币种、税务口径和原文位置。把这些内容在 Schema 层说明白后续抽取、校验与系统对接才有共同边界。预处理决定抽取输入的质量进入抽取前文件可能是原生 PDF、扫描 PDF、照片、Word 或混合附件。不同输入需要不同预处理方式。对于扫描件关注点不只是文字识别还包括旋转校正、页面切分、表格结构、印章遮挡和低清区域。对于原生 PDF则要检查阅读顺序、双栏布局、页眉页脚和嵌入表格是否被正确还原。若文本顺序本身混乱后续实体识别或大模型抽取会把错误结构当作事实。预处理阶段可以输出中间表示例如页级文本、段落块、表格单元格和版面坐标。这样抽取结果出现争议时能够回到具体页面和位置排查而不是只能重新阅读整份文件。字段抽取要同时处理定位和归一化抽取并不只是从文本中找到一个字符串。以“合同编号”为例系统需要先定位可能的候选文本再确认它是否属于目标字段最后按规则去除空格、全半角差异或不必要的前缀。日期、金额、主体名称和表格字段也都需要相似的归一化过程。常见的抽取策略可以组合使用版面与标题规则用于定位固定区域或字段标签。正则与字典规则用于处理编号、日期、金额等格式明确的字段。语义抽取用于处理表达多样但含义相近的内容。表格解析用于保留列名、行关系和跨页表结构。字段间约束用于检查候选值是否符合业务逻辑。工程上需要保留“原始值”和“归一化值”。原始值用于回查归一化值用于检索、统计和系统写入。两者混在一起后续很难解释某个字段为什么发生变化。用规则校验和置信度决定复核队列抽取结果不必全部人工重录但也不适合不加区分地直接进入业务系统。更高效的做法是让格式规则、字段关系和置信度共同决定复核优先级。例如可以把以下结果送入复核队列必填字段缺失或格式不符合 Schema。同一字段在正文、表格和附件中出现互相矛盾的候选值。金额与币种、日期范围或主体关系不符合既定规则。低清页面、手写内容或复杂表格中的字段。无法定位回原文页面的抽取结果。这里的置信度不应被当作最终正确率而更适合用作分流信号。系统可以把规则冲突和低置信结果集中展示业务人员只需确认高风险字段并将修正结果回流到规则与样本集。交付时保留数据、证据和审核状态文档抽取的最终输出不应只是一张孤立表格。更适合下游使用的交付结构通常同时包含字段值、来源证据和审核状态。以 JSON 或表格交付时可以为每个字段保留文档 ID、页码、位置、原始文本、归一化值、抽取方式、校验结果和审核状态。这样数据治理、业务系统和复核人员可以围绕同一份结果协作不需要在文件夹和表格之间反复查找。Scriber 在抽取链路中的定位Scriber 面向企业文档信息抽取场景适合围绕业务字段定义、抽取规则、人工审核和结构化交付建立处理链路。评估这类能力时建议不要只选版式单一的样本而是混入扫描件、表格页和历史模板观察字段 Schema 是否被满足、异常结果是否能被分流、来源位置是否支持回查。把 Schema、证据和审核状态作为抽取结果的一部分文档处理才能从“识别出文本”进一步变成可接入业务流程的数据资产。