自动著录要不要进正式库，关键不在模型，而在复核状态

某个数字档案室项目做自动著录试点，演示环境里效果很好：上传一份扫描后的文件，系统从 OCR 文本里抽出题名、责任者、文号、日期、保管期限，页面右侧还给出置信度。项目会上大家最关心模型准确率，讨论要不要换更大的模型、要不要追加训练样本、要不要把抽取规则再写细一点。

问题通常在演示之后冒出来。业务人员开始批量处理几百份材料，系统把候选字段直接覆盖到目录库。过了两周，抽查发现同一批文件里的责任者写法不一致，有的日期取了成文日期，有的取了签发日期；保管期限遇到表格材料时被误判；个别密级字段从正文片段里提取，缺少业务规则依据。再往回查，系统只能看到“某天批量导入成功”，看不到每个字段原来是什么、机器建议是什么、谁确认过、为什么被退回过。

自动著录的危险处不在于模型会犯错。任何识别和抽取都会犯错，OCR 也会错，人工录入也会错。危险处在于错误进入正式库以后披上了“已确认数据”的外衣。目录字段一旦被下游检索、统计、移交、开放审核、保管期限鉴定使用，再把它改回来就不是改一个文本框那么简单。

正式字段和候选字段要隔离

自动著录的第一条系统规则很朴素：机器抽取结果先进入候选区，不能直接写入正式字段。候选区要保存机器建议值，也要保存建议来自哪一页、哪一段、哪个 OCR 版本、哪个规则版本、哪个模型版本。否则复核人员看到一个字段，只知道它是系统给出的结果，却不知道依据在哪里。

比较稳的表结构可以从字段级候选开始，而不是整条目录级候选。

create table archive_field_candidate (
  id bigserial primary key,
  record_id varchar(64) not null,
  field_name varchar(64) not null,
  machine_value text not null,
  evidence_page int,
  evidence_text text,
  confidence numeric(5, 4),
  ocr_version varchar(64),
  rule_version varchar(64),
  model_version varchar(64),
  review_state varchar(32) not null,
  reviewer varchar(64),
  review_opinion text,
  created_at timestamp not null default now(),
  updated_at timestamp not null default now()
);

这张表的重点在于隔离“建议值”和“正式值”。正式目录表继续承担系统事实，候选表承担机器建议和复核过程。题名可以通过，责任者可以退回，日期可以要求补证，保管期限可以交给业务规则复核。每个字段有自己的状态，批量处理时才不会被一条“整条记录已通过”盖住细节。

有些项目会把候选值直接放在目录表的扩展 JSON 里，这样做在小试点里省事，后面很容易失控。复核列表、退回原因统计、字段级审计、批量回写和质量抽查都要围绕候选状态查询。候选数据长期藏在扩展字段里，开发人员每次都要临时解析，业务人员也很难按字段维度看问题。

复核状态要能表达现场动作

复核状态不要设计得太花，也不能只剩“通过”和“失败”。自动著录进入真实业务后，常见动作至少有五类：机器已生成、等待复核、人工确认、退回重算、已回写正式库。涉及敏感字段时，还可能需要二次审核。

一个可落地的状态流可以这样写：

generated -> needs_review
needs_review -> confirmed
needs_review -> rejected
rejected -> regenerated
regenerated -> needs_review
confirmed -> written_back
confirmed -> second_review
second_review -> written_back

状态命名要让业务人员一眼看懂。generated 表示机器已经给出建议；needs_review 表示等待人工处理；confirmed 表示字段级确认，不代表整条目录都可回写；rejected 表示要记录退回原因；written_back 才表示正式字段已经变更。每一次状态变化都要写日志，记录操作者、时间、旧值、新值和意见。

很多团队会问：如果模型置信度很高，能不能自动通过？可以做，但要先限定字段。比如页码、文号格式、年度这类字段可以设置自动通过阈值；保管期限、密级、开放状态、责任者规范名就要谨慎。自动通过也要留下规则版本和阈值，不然以后无法解释为什么某个字段没有经过人工确认。

状态设计还要考虑批量操作。复核人员不会一条一条点几千次，他们会按批次处理相同规则下的候选结果。系统要允许按字段、门类、来源批次和置信度筛选，也要限制危险批量操作。比如同一批次里保管期限字段全部确认，系统可以要求二次确认并生成批次号；题名字段批量回写前，应抽样展示若干证据片段，避免机械通过。

退回原因比准确率更能指导改进

自动著录项目一开始都喜欢谈准确率。准确率当然要看，但只看总准确率，项目经理很难知道下一步该改哪一层。一个字段错了，可能是 OCR 把字识别错，也可能是版面分割错，也可能是规则没有识别附件，也可能是模型把正文里的引用日期当成成文日期。

退回原因要分层记录。最少可以分成六类：

这张表比“模型还不够准”更有价值。退回原因积累到一定数量后，团队会看到问题集中在哪一层。如果 OCR 错误多，继续调大模型意义不大；如果字段冲突多，要优化证据展示和冲突选择；如果规则不适用多，要把门类模板补起来；如果权限不明多，就要让档案业务规则先行，而不是把判断压给模型。

退回原因还可以反向改进样本库。每周抽取退回最多的 20 个字段，保存原图、OCR 文本、机器建议、人工结果和退回理由，形成小规模评测集。下一次升级模型、抽取规则、字段模板或 OCR 流程时，用同一批样本回归。这样团队才知道升级带来的变化，而不是凭几次演示感受判断。

回写正式库前要生成可审计批次

字段确认以后，系统仍然不能马上悄悄改正式库。回写是一个数据变更动作，要有批次、审批和回滚记录。批次里至少要包含记录数、字段数、涉及门类、操作者、审批人、回写前后值、候选来源和执行结果。

可以把回写批次设计成两张表：一张记录批次，一张记录明细。

create table archive_writeback_batch (
  id bigserial primary key,
  batch_no varchar(64) not null unique,
  source varchar(32) not null,
  state varchar(32) not null,
  applicant varchar(64) not null,
  approver varchar(64),
  total_fields int not null,
  created_at timestamp not null default now(),
  executed_at timestamp
);

create table archive_writeback_item (
  id bigserial primary key,
  batch_no varchar(64) not null,
  candidate_id bigint not null,
  record_id varchar(64) not null,
  field_name varchar(64) not null,
  old_value text,
  new_value text not null,
  result varchar(32) not null,
  error_message text
);

这套设计有一个好处：以后出了问题，可以按批次回看。某天责任者字段大量异常，运维人员不用从目录表里猜；可以直接查是哪一批候选写回，来源是什么，谁审批，哪些记录成功，哪些失败。必要时还能按批次导出差异，交给业务人员复核。

批量回写也要有失败处理。正式库可能有字段锁定、版本冲突、记录不存在、权限不足、格式校验失败等情况。系统不能因为其中几条失败就把结果写成“成功”，也不能把成功和失败混在一条日志里。最好的做法是每个字段一条明细，批次状态单独记录：全部成功、部分成功、全部失败、已回滚。

复核界面要服务判断，不要只服务点击

自动著录复核界面常见误区是把字段、建议值、确认按钮排成表格，让复核人员快速点完。这样界面看起来效率很高，实际会把判断依据藏起来。复核人员需要看到候选值旁边的证据片段、原图位置、字段规则、历史同类写法和退回入口。

题名字段可以展示标题附近的原图区域；日期字段要展示上下文，避免把收文日期当成成文日期；责任者字段要关联规范名；保管期限要展示对应分类规则；密级和开放状态要明确提示需要人工判断。不同字段的复核界面可以共用框架，但证据展示不能一刀切。

复核人员还需要“保留原值”的按钮。机器建议不一定优于已有目录，尤其是历史数据经过人工整理后，自动抽取只是补充检查。系统如果只提供“采用建议”和“退回”，会让复核人员把很多问题归成退回；有了“保留原值”，才能区分机器建议错误和原字段无需修改。

界面还要让复核人员能写结构化意见。举个例子，日期字段退回时不要只写“错了”，最好能选择“取值位置错误”“日期类型错误”“原文缺失”“需业务部门确认”。责任者字段退回时，可以选择“简称未规范”“同名机构冲突”“印章文字误识别”。这些选项后面会变成统计口径，帮助项目组判断下一轮该修 OCR、修规则、修规范名库，还是修复核流程。

如果复核意见只能写自由文本，后期统计会非常痛苦。结构化原因和补充说明可以同时存在，前者用于统计和回归，后者保留现场细节。

验收时看四份材料

自动著录能力要进入项目验收，不能只演示一份文件的抽取效果。验收时至少看四份材料。

第一份是候选字段清单。随机抽取一批记录，查看机器建议、证据页、证据片段、置信度、版本和状态。没有证据来源的候选字段，不能算可复核。

第二份是退回原因统计。看退回集中在哪些字段、哪些门类、哪些来源批次。这个统计能说明项目组是否知道问题在哪一层。

第三份是回写批次日志。抽查某个批次的申请、审批、执行、失败明细和回写前后值。正式库发生过什么变化，必须能讲清楚。

第四份是回归样本。拿前期退回样本重新跑一遍，比较升级前后的字段结果。没有回归样本，模型换了、规则改了、OCR 升级了，项目组只能凭感觉判断变好还是变坏。

领至科技在设计档案 AI 辅助著录方案时，会把自动著录放在“候选、复核、回写、审计”的链路里看。模型负责提出建议，系统负责保留证据，业务人员负责确认边界，日志负责留下可复盘材料。这样做会让前期设计慢一点，但能减少后期批量返工。

自动著录可以提高效率，前提是它没有把未确认的机器建议伪装成正式事实。需要对照相关方案资料时，可以通过文末原文进入领至科技官网。

候选字段要保留模型来源

自动著录进入候选库时，应记录候选值来自哪个模型、哪个版本、哪段证据、哪次任务。人工复核通过后，也不要把这些来源信息删掉。后续如果发现某个模型版本经常给错保管期限或题名，就能按来源回查。

候选字段越清楚，人工复核越省力。复核人员看到的不应只有一个结果，还应看到证据、置信度和产生过程。