古籍 OCR 与知识库构建

要解决什么问题

影印版古籍往往只有扫描图或粗糙 OCR 文本：无标点、错字多、卷篇结构难辨。若还要做人物、地名、官职等结构化抽取并导入图数据库，手工从识别到标注再到导出三元组，链路长且容易在「改原文」和「标错实体」上失控。

本技能把 shiji-kb 类「智能体本体」流程（自然语言 SKILL 驱动 Agent、行内实体标注、lint 校验、人在环）收成一条可复用管线：从影印图 / 无标点 OCR / 已数字化带标点文本任一入口，产出可校对的 Markdown 底本、18 类行内标注，以及 entities.csv、triples.csv、knowledge.json、kg.ttl、Neo4j 导入对等格式。

如何工作

输入分三条路：

• 扫描图（.jpg / .png / .pdf）→ 阶段 0 先拿纯文本（查数字化库、FireRed-OCR / DeepSeek-OCR-2 本地 VLM、或腾讯云等 API，可混合交叉验证）→ 再进 A/B/C
• 仅 OCR 纯文本 → 阶段 A 后处理
• 维基文库 / ctext / 书格等已标点文本 → 直接 阶段 B 实体标注

阶段 A（OCR 后处理） 按单向流水线：勘探噪声与卷篇结构 → 清洗 → Markdown 结构化 → 句读（夹注 【】 独立作用域）→ 校验；铁律是字符保真，不繁简转换、不擅自改字，用 verify_ocr_preserve.py 逐字核对。

阶段 B 用固定 SYSTEM_PROMPT（temperature=0）做 18 类 〖TYPE 实体〗 行内标注，支持 〖TYPE 显示名|规范名〗 消歧；只加标记不改原文、不嵌套、标题行不标；lint_tags.py 做语法与保真检查。

阶段 C 用 export_kb.py 解析 .tagged.md，导出实体清单、同句共现与类型启发式关系三元组，以及 RDF / Neo4j 等目标格式；多文件可用 --merge 去重。

适用边界

模糊缺损页、纯手写批注、竖排未切列、超长单页（本地约 8192 token 上限）会显著拉低识别或结构质量；本地 VLM 需要 NVIDIA GPU（约 8GB 起，更强模型更高）。腾讯云通用 OCR 无竖排参数，竖排需先切列旋转。未公开珍本若走云端，文本会出公网，优先本地 OCR 并注意版权。实体边界与关系推断仍有 AI 误差，应坚持「只标不改」并配合人工复核，订正多版本互校宜在管线外进行。