项目全景：从影像到语义资产的工程蓝图

古籍数字化项目最容易掉进两个误区：一是把“扫描+OCR”当作全部交付，最终得到一堆难以复用的图片和勉强能搜的文本；二是把“知识图谱”当作终点，却没有稳定的上游生产线，导致图谱更新靠手工、质量靠运气。本章要做的，是把这类项目重新定义为一条可度量、可追溯、可迭代的“数字化生产线”：输入是纸本文献与既有影像，输出是可以被检索、被计算、能持续增量的语义资产，并且能以接口形式服务检索、校勘、研究与应用开发。

更具体地说，你需要一张工程蓝图，回答四个问题：交付物有哪些、每一步产出什么中间件、如何用指标把质量与成本钉死、在约束条件下如何做技术与组织决策。后续章节将分别深入每个关键环节；本章先把全景搭起来，让你在立项、招标、团队协作、验收与长期运营时都有统一语言。

---

交付物地图：从“文件”到“资产”的层级

古籍数字化的交付物不应只按文件类型（JPG、TXT、XML）划分，而应按“可复用资产层级”划分。推荐把交付物分成五层，每层都能独立验收，并向上提供可追溯依赖。

影像资产（Image Assets）

影像资产不只是“图像文件”，而是“图像 + 元数据 + 可定位能力”的组合：

• **母版影像**：无损或近无损（TIFF/JP2），带色彩管理（ICC Profile），用于长期保存与再处理。
• **发布影像**：面向访问与标注（JPEG/JP2/PNG），可按需裁切、金字塔切片。
• **页级元数据**：页序、版式（单栏/双栏/界栏）、破损/污渍标记、拍摄参数、设备与操作员信息。
• **可定位协议**：建议支持 IIIF（Image API + Presentation API），使“页/行/字”的坐标可被外部工具引用与复用。

参考：<https://iiif.io/>

验收关键点：同一页在不同处理阶段（去畸变、裁切、二值化）之间能建立稳定映射；否则后续标注坐标会漂移，结构化与抽取将不可控。

可检索文本（Searchable Text）

可检索文本至少有两种形态，面向不同需求：

• **阅读文本**：按页或按段落排版，保留换行与标点策略（可后置）。
• **训练/计算文本**：更强调一致性与可对齐性，如行级/字级序列、带置信度与对齐信息。

不要只交付“纯 TXT”。最低建议交付“文本 + 位置信息（行/字框）+ 置信度”，为校对、结构化与抽取提供支点。

结构化标注（Structural Annotations）

古籍的“结构”通常比现代文档复杂：卷/篇/条、题名、作者、序跋、凡例、正文、注、夹注、校勘记、牌记、版心、行款、书口等。结构化标注至少覆盖三类：

1. 版面结构：页内区域（正文区、注释区、边栏、插图、牌记）。 2. 逻辑结构：卷→篇→节→条目→段→句（可按项目目标裁剪）。 3. 文本现象：异体字、避讳、缺字、衍文、圈点、批注、重文号等。

常用承载格式包括 TEI-XML、ALTO XML、PAGE-XML、JSON（自定义 schema）。工程上建议：上游保持“轻量、可演进”的 JSON 标注；对外发布与学术交换再导出 TEI（因为 TEI 规范强、但落地成本高）。

知识抽取产物（Extraction Outputs）

抽取产物介于文本与图谱之间，是“可解释的结构化数据集”，典型包括：

• **实体表**：人名、地名、官名、书名、机构、年号、时间表达等（含出处定位）。
• **事件/关系表**：任官、迁徙、编纂、刊刻、从属、引用、谱系等。
• **证据链**：每条抽取结果都能回指到页/行/句，最好能回到影像坐标（方便复核与纠错）。

抽取产物是图谱构建的原料，也是模型评估与持续训练的数据闭环入口，必须像“数据产品”一样版本化管理。

知识图谱与应用接口（Knowledge Graph & APIs）

图谱不是把实体关系“灌进数据库”就完事，而应包含：

• **本体/模式层（Schema/Ontology）**：类、属性、约束、命名空间与对齐策略（与 CIDOC CRM、Dublin Core、BIBFRAME、GeoNames 等的映射可逐步做）。
• **实例层（Instances）**：实体、关系、事件、证据节点。
• **一致性规则**：唯一性、基数、类型约束、时间区间合理性等（可用 SHACL/OWL 约束或在应用层校验）。
• **服务层接口**：检索（全文/结构/图谱）、标注回写、证据可视化、导出（RDF/JSON-LD/CSV）、权限与审计。

---

端到端生产线：采集→语义资产的可落地流程

把流程画出来的价值在于：每一步都有“输入/输出/质量门（quality gate）”，并且能做里程碑验收与并行协作。下面给出一个可直接套用的端到端流程图；后续章节会逐步把每个节点变成可执行的工程模块。

```mermaid graph TD A[采集/接收影像] --> B[预处理: 纠偏/裁切/去噪/切分] B --> C[版面分析: 区域/行/字检测] C --> D[识别: OCR/HTR + 置信度] D --> E[质量评估: 抽样/回归/漂移监控] E --> F[校对: 人工/众包/半自动] F --> G[结构化: 逻辑层级/现象标注] G --> H[信息抽取: 实体/关系/事件] H --> I[图谱构建: 清洗/对齐/消歧/约束] I --> J[服务发布: 搜索/IIIF/Graph API/SPARQL] J --> K[反馈闭环: 纠错->重训->重建] K --> C ```

采集与预处理：把“可识别性”当作第一原则

采集阶段最怕“只要能看清就行”的心态。OCR/HTR 的上限往往由影像质量决定；后期算法与人工只能在上限之下做权衡。预处理的目标不是“让图更漂亮”，而是让后续模块更稳定：

• **几何**：纠偏、去弯曲、去透视、统一页边距；为坐标体系建立基准。
• **光照与色彩**：均光、白平衡、色卡校正（有条件建议拍摄时就做）。
• **噪声与破损**：去噪、去底纹、补洞属于“有风险操作”，需要保留原始母版，并对处理结果做版本化。
• **切分策略**：册/卷/页的边界、双页合一拆分、连页缺失与重拍处理。

> 引用（工程底线）：影像预处理必须“可逆或可重做”。任何不可逆的操作（如覆盖母版、不可追溯的批量二值化）都会在后续结构化与证据对齐阶段放大成本。

版面分析与识别：把“对齐”放进第一批需求

很多团队把版面分析当作“高级功能”，先 OCR 出整页文本再说；但古籍项目里，对齐能力直接决定校对成本、结构化难度与抽取可信度。建议在识别阶段就产出：

• **区域框（Region）**：正文、注、边栏、图像等。
• **行框（Line）**：行序、阅读顺序、跨栏规则。
• **字框或字序列（Char）**：有条件则字级框；没有字框也要保证行内字符序列与置信度可追溯。

识别引擎选择上，常见组合是：

• 印刷体：PaddleOCR / Tesseract（定制训练）/ 商业引擎。
• 手写/刻写差异大：HTR（如基于 CRNN/Transformer 的自训练，或使用 Transkribus 等平台思想自行落地）。
• 竖排与繁简混排：需要明确字符集、方向检测、标点策略与异体字编码方案（后续章节会专门讨论）。

质量评估与校对：把抽样变成制度，而不是临时检查

校对是成本黑洞。你无法在预算有限时实现“全量逐字人工复核”，但你可以用制度化抽样把风险锁定，并用“人机协同”把单页成本压下来。推荐把校对分三层：

1. 自动评估：基于置信度分布、语言模型困惑度、版面异常（行距突变、字符密度异常）筛出高风险页。 2. 抽样复核：按卷/页型/版式分层抽样，估计整体 CER/WER 与方差。 3. 目标校对：优先校对将进入结构化与抽取的关键字段（题名、人物、地名、时间、条目标题），而不是平均用力。

校对工具应支持：影像-文本联动定位、差分回写、批量替换规则、审计日志与冲突解决（多校对员协作）。如果工具无法提供“修改前后差异 + 修改人 + 时间 + 证据定位”，就很难建立可追溯的数据资产。

结构化、抽取、图谱：从“结果导向”转为“证据导向”

结构化与抽取阶段最重要的观念是：每个结构节点与每条抽取结果都必须带证据。没有证据的图谱，无法校验、无法增量更新、也无法获得学术与业务信任。

• 结构化：先做“稳定、低争议”的层级（卷/篇/条目/段），再逐步扩展到注释系统、校勘记与复杂文本现象。
• 抽取：先从“可规则化”的字段入手（官职、人名模式、地名后缀、年号格式），再引入统计/深度模型。
• 图谱：先建立 schema 与约束，再导入实例；否则后期返工会非常痛苦（关系类型、时间建模、同名消歧都会牵一发动全身）。

---

指标体系：把质量、成本、进度纳入同一张仪表盘

没有指标，生产线就无法管理；没有统一指标，外包与协作就无法验收。指标体系建议按五类组织：影像、识别、校对、抽取、图谱一致性与服务能力。

影像质量指标：从“分辨率”扩展到“可识别性”

常见可量化指标：

• **分辨率**：DPI 或像素尺寸（建议明确最低阈值，如 300–600 DPI，视字大小与保存目标而定）。
• **清晰度**：可用拉普拉斯方差、MTF 近似指标做批量检测（用于发现虚焦/抖动）。
• **几何畸变**：倾斜角分布、页边距稳定性、弯曲程度（可用版面基线拟合残差度量）。
• **色彩一致性**：白平衡漂移、色卡偏差（ΔE）用于长期批次一致性管理。
• **缺页/重复页检测**：哈希/特征匹配 + 页码识别交叉验证。

工程建议：影像指标要能自动化跑批输出报告，并把异常页列表回流到重拍或人工确认队列。

OCR/HTR 指标：用 CER/WER 描述“可用程度”

古籍更推荐使用 字符错误率（CER） 作为主指标，定义为：

$$ CER = \frac{S + D + I}{N} $$

其中 $S$ 为替换数（Substitution）、$D$ 为删除数（Deletion）、$I$ 为插入数（Insertion）、$N$ 为参考文本字符数。对于以词为单位的现代文本常用 WER，但古籍无空格分词、异体字多，CER 更稳定。

除了整体 CER，还建议同时监控：

• **按版式分层的 CER**：正文/注/牌记往往差异巨大。
• **按字符类别的 CER**：常用字/罕见字/数字/时间表达/人名地名。
• **置信度校准曲线**：置信度是否真的能预测错误概率（决定“目标校对”是否有效）。

校对成本指标：把人力投入与质量收益绑定

校对成本不要只看“总工时”，而要拆成可优化的结构：

• **单位产出成本**：元/千字、元/页、分钟/页。
• **有效修改率**：每小时有效修正字符数（剔除无意义改动）。
• **返工率**：二次校对发现的错误占比，反映流程与工具问题。
• **冲突率**：多人协作的合并冲突数量，反映任务切分与权限策略是否合理。

> 侧边栏（实践经验）：当 CER 已经低于某个阈值后，继续追求“极致正确”的边际成本会急剧上升。多数项目需要定义“面向检索可用”“面向抽取可用”“面向出版可用”三档质量目标，并匹配不同校对深度。

抽取与结构化指标：F1 之外必须有“可复核性”

抽取任务常用 Precision/Recall/F1，但古籍项目还需要强调“可复核性”：

• **字段级 F1**：人名、地名、官职、时间等分别计算。
• **证据覆盖率**：抽取结果中带页/行/句定位的比例。
• **跨批次稳定性**：同一规则/模型在不同卷、不同版式上的性能波动。
• **错误类型分布**：边界错误、类型错误、消歧错误、时间解析错误等（用于驱动迭代）。

图谱一致性指标：约束可解释、违规可定位

图谱质量不能只靠抽样查看。建议建立“可执行的约束”并统计违规情况，例如：

• **唯一性**：同一书名+卷次+页码不应重复；同一人物在同一谱系节点不应出现多重冲突 ID。
• **类型一致性**：实体属性类型（日期、地理坐标、引用关系）必须符合 schema。
• **时间合理性**：任官开始时间 < 结束时间；出生 < 死亡；年号映射到公元不越界。
• **链接质量**：外部对齐（如 GeoNames、CBDB、Wikidata）链接的置信度分布与人工抽查通过率。

实现方式上，可选 RDF+SHACL、Property Graph+约束检查任务、或在数据入库前做验证（推荐至少有一个“入库前验证”关卡）。

---

常见约束与工程决策：预算、人力、版权、设备、算力

古籍项目的难点往往不在某个算法，而在约束下的系统最优化。下面把最常见的约束转成可操作的决策点。

经费与人力：先定义“交付层级”，再定工具与外包边界

• 预算紧张时优先保证：母版影像质量、基础对齐（页/行）、可追溯版本管理。
• 人力不足时优先策略：目标校对 + 抽样评估 + 抽取字段优先级；避免全量深校。
• 外包协作建议：把“可验证的中间产物”作为分包交付（如版面行框、校对差分日志、结构化 JSON），减少黑箱式“一次性交付”。

版权与合规：把“可用范围”写进数据与接口的权限模型

很多项目在后期才发现影像不能公开，导致接口、图谱与演示都要重做。建议在立项时明确：

• 影像、文本、结构化与图谱的**授权范围是否一致**（常常不一致）。
• 是否允许对外提供下载、只读浏览、或仅提供检索结果片段。
• 内部标注工具的访问控制、审计与水印策略。

工程上应在数据目录与 API 层都带上权限字段（如 `access_level: internal/public/restricted`），并在流水线产物中继承传播，避免“下游误发布”。

设备与算力：把吞吐量目标写成公式

吞吐量目标可以粗略写成：

$$ Throughput = \frac{\text{页数}}{\text{总耗时}} = \min(T_{scan}, T_{pre}, T_{ocr}, T_{qa}, T_{proof}) $$

瓶颈常在校对与结构化，而不是 OCR 推理。算力投入要与瓶颈匹配：

• 如果 OCR/版面分析是瓶颈：GPU/推理加速/批处理调度有价值。
• 如果校对是瓶颈：工具体验、任务拆分、规则辅助与高风险页筛选更划算。
• 如果抽取与图谱是瓶颈：需要数据规范、消歧策略与约束体系，而不是盲目堆模型。

---

参考技术栈与工程组织：数据分层、版本、日志、编排

把“研究型脚本”升级成“生产线”，核心是工程组织方式。下面给出一套可落地、团队协作友好的参考架构（可按规模裁剪）。

数据分层：Bronze / Silver / Gold 思路迁移到古籍

• **Bronze（原始层）**：母版影像、原始拍摄元数据、接收清单；只追加不修改。
• **Silver（处理中间层）**：预处理影像、版面框、OCR 原始结果（含置信度）、校对差分日志。
• **Gold（业务资产层）**：结构化文本、抽取表、图谱实例、对外发布包（TEI/JSON-LD/RDF）。

分层的好处是：任何下游问题都能定位到上游版本；任何算法更新都能在 Silver 层重跑并对比差异。

版本管理：代码用 Git，数据用 DVC/对象存储，产物可追溯

建议组合：

• **Git**：代码、配置、schema、本体、标注规范文档。
• **DVC 或类似机制**：对大文件数据集做版本指针管理，绑定到 Git commit。
• **对象存储（S3/MinIO/OSS）**：存放影像与中间产物，按项目/批次/版本组织。
• **数据指纹**：对关键产物计算哈希（如 SHA256），用于一致性校验与去重。

可追溯日志：不仅是运行日志，更是“数据血缘”

流水线应能回答：“某条图谱关系来自哪一页哪一行？用的是哪个 OCR 模型？哪个校对员改过？何时导入图谱？”。建议至少记录：

• 任务运行元信息：任务 ID、输入版本、输出版本、耗时、资源消耗。
• 模型元信息：模型名称、训练数据版本、超参数摘要、推理阈值。
• 人工操作元信息：修改差分、操作者、时间、审核状态。
• 证据链接：文本 span、影像坐标、IIIF URL。

实现上可以从轻量做起：每个任务输出一个 `run.json`，集中汇总到 PostgreSQL/ClickHouse 做报表。

流水线编排：从脚本串联到 DAG 调度

小规模项目可以先用 Makefile/脚本约定；中规模以上建议采用 Airflow/Prefect/Dagster 一类编排工具，把每步变成可重跑的任务节点。一个关键原则是：输入不变则输出可复现（配置与模型版本纳入输入）。

下面是一段“任务配置”示例（仅作为组织方式参考），强调可复现与可追溯：

```yaml pipeline: dataset: localgazetteer_demo version: v0.3.0 steps: preprocess: deskew: true dewarp: "light" output_format: "jp2" layout: model: "layout_v2.1" regions: ["main", "notes", "marginalia"] ocr: engine: "paddleocr" model: "ch_traditional_vertical_v1" export: with_confidence: true with_bboxes: true qa: sample_rate: 0.02 stratify_by: ["page_type", "print_quality"] ```

---

贯穿全书的示例项目设定：以“地方志选段”跑通全链路

为了让后续章节的技术细节不悬空，本书将使用一个贯穿示例：某地《X府志》选取若干卷（含序跋、凡例、人物志、职官志、疆域图说等），兼具常见难点：竖排、界栏、夹注、异体字、部分破损与重影。示例目标不是追求“全书全量”，而是跑通可复用的工程方法：

• 规模：约 500–800 页影像（可分批次导入）。
• 交付优先级：

1) 页/行对齐的可检索文本（面向检索与校对） 2) 条目级结构（人物条、官职条、地名条） 3) 人名/地名/官职/时间抽取与证据回指 4) 图谱服务：按人/地/官职聚合检索与关系浏览

数据目录规范：让每个文件“自解释、可批处理、可对齐”

推荐一个兼顾纸书归档与机器处理的目录结构（示例）：

```text loc