把一份简历交给大模型，要求返回 JSON，最先遇到的问题往往是少括号、类型错误、字段漏写或格式漂移。结构化输出和约束解码缓解了这些问题，于是一个很容易出现的误解是：只要 JSON 永远能通过 Schema 校验，简历解析就已经可靠。
这混淆了两件完全不同的事。Schema 约束回答“输出长什么样”，事实抽取回答“值从哪里来、是否属于正确记录、没有证据时该不该为空”。一个系统可以每次都生成完美合法的 JSON，同时稳定地把上一家公司的岗位放进下一段经历，或替候选人补全原文不存在的毕业时间。
四层质量不能用一个“成功率”代替
结构化简历解析至少包含四道门：
- 语法合法：输出能否被 JSON 解析器读取；
- Schema 合规：字段、类型、枚举、必填项和嵌套结构是否满足约束；
- 语义有据：字段值是否被原文支持，边界和记录归属是否正确；
- 业务可用：错误代价、置信度和人工处置是否满足入库要求。
约束解码主要提升前两层。2023 年的 Grammar-Constrained Decoding 研究展示了利用语法约束控制语言模型输出结构，并在信息抽取等任务上进行实验。2024 年 8 月，OpenAI 公布 Structured Outputs，也明确区分了普通 JSON 模式与严格匹配开发者 Schema，并说明结构匹配并不能避免值本身出错。
因此，评测报告中的“JSON 合法率 100%”值得保留，但它只是接口可靠性，不是字段准确率。
Schema 首先是一份业务契约
JSON Schema 能表达对象、数组、类型、枚举、必填字段和条件关系。但在简历场景，真正困难的不是写出 string 或 array，而是定义字段语义。
例如 jobTitle 是候选人原文岗位、标准岗位，还是企业内部岗位族？endDate 遇到“至今”应返回空、特殊枚举还是当前日期？项目经历嵌在工作经历中时，是独立记录还是父记录的子数组？如果这些问题没有写进契约，大模型、标注员和下游系统会各自发明答案。
GoLLIE 关于零样本信息抽取的研究表明，详细标注指南对模型遵循未见过的抽取任务非常关键。字段名本身不是完整指导。一个生产 Schema 应为每个字段配套：定义、正反例、边界规则、空值规则、原文与标准值关系，以及冲突时的优先级。
Schema 还应版本化。增加必填字段、改变枚举或重新解释日期，都可能让历史数据与新模型不可比。版本号要跟随每次解析结果，不能只存在接口文档里。
强制填满字段，往往会制造幻觉
如果所有字段都设为必填，模型在没有证据时仍必须产生一个值。对联系方式、学历和工作日期而言，结构完整不如明确缺失安全。
更稳妥的字段状态至少区分：
observed：原文直接出现；normalized：由原文按明确规则映射；inferred：根据上下文推断，必须单独标记；missing：未找到证据；ambiguous：存在多个合理解释；invalid：原文存在但无法通过格式或逻辑校验。
NIST 2024 年生成式 AI 风险管理画像将 confabulation 作为需要管理的风险之一。对简历数据，流畅但不存在的值比一个诚实的空字段更危险，因为它会进入搜索、匹配、统计甚至自动化决策。
不要用“请勿幻觉”一句提示词承担控制责任。Schema 应允许缺失，抽取器应返回证据，校验器应检查矛盾，高风险字段应支持拒绝自动入库。
证据对象应该和字段一起返回
与其让模型只返回 company: 某科技公司，不如把结果设计为一个证据信封：
- 原始值和标准值；
- 页码、区域或字符范围；
- 所属记录 ID；
- 抽取方法与模型版本；
- 使用过的规范化规则；
- 置信度或风险信号；
- 校验结果和处置状态。
证据位置可以来自 OCR 坐标、PDF 字符范围或版面区域。对于 OCR-free 模型，也要设计能回指页面区域的中间表示。否则人工看到一个可疑日期时，只能重新通读整份简历。
证据还支持自动一致性检查。例如，工作开始日期晚于结束日期、年龄与毕业年份明显冲突、同一经历的公司和岗位来自相距很远的版面区域，都可以触发复核。这些检查不能证明字段正确，但能高效发现一类可解释错误。
解析管线不要让一个模型承担所有职责
一个可靠管线可以拆成：文件与版面处理、候选片段识别、结构化抽取、确定性校验、标准化、记录对齐和人工回退。
邮箱、电话、URL 和部分日期适合确定性解析；开放技能、岗位职责和记录关系可能需要模型理解；标准岗位和技能映射需要词表版本与候选集合；最终写入还要受业务规则约束。把所有步骤塞进一次大模型调用，会让错误来源和回退策略不可见。
生成失败时也不要无限重试。应区分：Schema 编译或不支持、模型拒答、输出被截断、字段校验失败、证据不足和服务异常。只有明确知道重试能改变什么时才重试，否则同一输入可能只是重复生成不同的错误值。
评测要把格式分数和事实分数并列报告
建议至少报告：
- JSON 解析成功率与 Schema 通过率；
- 单值字段 Exact Match；
- 多值字段 Precision、Recall 与 F1；
- 经历记录对齐后的字段准确率；
- 无证据生成率和错误补全率；
- 证据位置正确率；
- 缺失、歧义和拒答的校准情况；
- 自动入库覆盖率与剩余错误率。
还要单独构造挑战集：双栏、扫描件、跨页经历、混合语言、同名公司、日期歧义和原文本身矛盾。只用格式整齐的标准简历，会高估 Schema 管线的实际价值。
上线前应该问的七个问题
- Schema 是否定义字段语义，而不只是类型？
- 没有证据时是否允许返回缺失或歧义？
- 每个核心字段能否回到原页和原文？
- 标准化值是否保留原始值与词表版本？
- 格式失败、事实失败和服务失败是否分别记录？
- 低置信字段如何进入人工复核，复核结果如何回流？
- Schema 或模型升级后，固定集是否重新回归？
结构化输出是可靠工程的重要基础，它让接口不再因为一个括号崩溃。但它没有替代信息抽取、证据追踪和业务风险控制。真正值得信任的简历解析，不只返回“格式正确的答案”，还要知道答案来自哪里，以及什么时候不应该给答案。