PDF-OCR文件识别篇（五）：字段定义与提示词工程

抽取质量的关键不在「怎么调模型」，而在「怎么跟模型说话」。本模块用系统提示词 + 按表注入字段定义两段式，把通用大模型驯成针对你这套表格的专业抽取器。

5.1 系统提示词 `SYSTEM_PROMPT`

定义在 AiPdfExtractionServiceImpl，固化了 7 条抽取铁律。这是所有表共用的「底座规则」：

逐字保留：严格按原文抽取，禁止概括、改写、缩写、翻译、合并、推测、补全；完整保留全部文字、数字、单位、括号与符号。
字段约束 ：若给了「字段清单」，columns 必须与之完全一致（同名、同序、不缺、不改名、不新增、不合并）；每个 row 都要含全部字段，无内容填 ""。
输出形态 ：键值型登记表 → JSON 对象；多行明细表 → {"columns":[...], "rows":[{列名:值,...}, ...]}。
合并单元格向下填充：纵向合并的值属于它跨越的所有行，必须在每一行都重复填入，绝不能只在首行填、其余留空。
跨页折行合并：若某行只有个别单元格有少量文字、标识列（如序号、记录编号）为空，说明是上一行被折断的续接文字，合并回上一行，不单独成行。
去掉页眉页脚、页码（如「--- 2 ---」）、表格标题等无关内容。
只输出 JSON，不要任何解释或 markdown 代码块。

第 4、5 条最关键------它们直接对抗 PDF 表格最常见的两类结构破坏。配合第 4 章百度 OCR 识别出的结构化 JSON 作为输入：提示词约束 + 结构化输入，两头夹，才压得住。

提示词里的「领域身份」可按需替换。比如把开头设成「你是某某单据的结构化抽取专家」，能进一步收敛模型对该领域术语的理解，但 7 条铁律是通用的。

5.2 字段注册表 `TableSchemaRegistry` + `table-schema.json`

字段定义文件

resources/schema/table-schema.json 按「表格标题」定义每张表的结构示例：

java 复制代码

"基本信息表": {
  "title": "基本信息表",
  "rootKey": "基本信息",
  "type": "object",
  "example": {
    "单位名称": "示例科技有限公司",
    "注册地址": "某省某市某区某路1号",
    "统一社会信用代码": "9100000000000000XX",
    "联系电话": "010-00000000",
    "证件文号列表": ["示字〔2021〕4号", "..."],
    "指标": {
      "指标A": { "数值": 5588.22, "单位": "t/a", "说明": "..." }
    }
  }
}

example 是一份「填好的样表」，直接示范字段名、嵌套层级、数据类型------比干巴巴列字段名更能约束模型输出。

注册表加载与匹配

TableSchemaRegistry 在 @PostConstruct 时加载，外部文件 schemaPath 优先，否则用 classpath 内置，按「去表号/空白」归一化后的标题建索引：

java 复制代码

public TableSchema getByTitle(String title) {
    TableSchema s = schemas.get(normalize(title));     // ① 精确匹配
    if (s != null) return s;
    for (entry : schemas)                              // ② 包含兜底
        if (key.length() >= 4 && (norm.contains(key) || key.contains(norm)))
            return entry.getValue();
    return null;
}
// normalize: 去掉开头「表N / 表N-N」前缀与所有空白

为什么按标题而非表号匹配？因为同一类表在不同文档里表序号可能不同（这份里是表48，那份里可能是表46），标题更稳定。

外部文件优先还有个运维价值：不重启、不重新打包就能调字段定义，线上发现某表抽得不对，改 JSON 文件即可。

5.3 动态注入 `buildSchemaBlock`

抽取每张表时，把该表的字段定义拼进用户提示词。逻辑分三档：

java 复制代码

TableSchema schema = tableSchemaRegistry.getByTitle(title);
if (schema == null) return "";                         // ③ 未配置 → 自由抽取

if (schema.getExample() != null) {                     // ① 有结构示例（首选）
    // 数组型：要求输出 {"rootKey": [元素,...]}，每个元素严格遵循示例
    // 对象型：要求严格遵循结构示例
    return "请输出 JSON 对象，严格遵循下面的「结构示例」..." + prettyJson(example);
}
if (schema.getFields() 非空) {                          // ② 只有字段清单
    // 登记表：给「字段清单（对象键，不缺不改不增）」
    // 明细表：给「columns 必须与字段完全一致」
}

最终拼出的用户提示词大致是：

复制代码

表格标题：表3 设备明细表
请输出 JSON 对象，格式为 {"设备明细": [元素, ...]}；数组每个元素严格遵循下面的「元素结构示例」...
元素结构示例：
{ "设备编号": "...", "设备名称": "...", "规格": "...", ... }

以下是该表百度 OCR 识别出的内容 JSON（跨页已合并），请严格据此抽取为结构化 JSON，逐行输出、不要遗漏任何一行......
<OCR 识别结果 JSON>

5.4 这套提示工程为什么有效

手段	对抗的问题
系统提示词「逐字保留」	模型自作主张改写/缩写
系统提示词「合并填充 / 折行合并」	PDF 表格结构破坏
`example` 结构示例	字段名漂移、层级随意、类型乱填
按标题匹配 + 外部文件优先	表号差异、线上免重启调整
强制 `json_object` + 低温（见第 6 章）	输出非 JSON、随机性过高

一句话：铁律定下限，结构示例定上限，对齐输入降难度。 三者缺一，抽取质量都会塌方。

PDF-OCR文件识别篇（五）：字段定义与提示词工程

5.1 系统提示词 SYSTEM_PROMPT

5.2 字段注册表 TableSchemaRegistry + table-schema.json

字段定义文件

注册表加载与匹配

5.3 动态注入 buildSchemaBlock

5.4 这套提示工程为什么有效

5.1 系统提示词 `SYSTEM_PROMPT`

5.2 字段注册表 `TableSchemaRegistry` + `table-schema.json`

5.3 动态注入 `buildSchemaBlock`