结构化提取

模型多吐了一个字段,要接受还是拒绝

提取结果里多了一个 `confidence`,前端看着挺有用,于是直接展示成了“可信度”。问题是,这个字段可能既没有定义,也没有经过标定。多出来的字段不一定无害:它可能让下游把未经约定的值当成依据。

阅读文本 / Reading text
本文使用合成样本演示处理方法。代码已通过隔离环境中的示例检查;这不代表对所有真实文件或产品效果的保证。处理重要文件前,请保留原件,并按文中的边界与验收项复核。 提取结果里多了一个 confidence ,前端看着挺有用,于是直接展示成了“可信度”。问题是,这个字段可能既没有定义,也没有经过标定。多出来的字段不一定无害:它可能让下游把未经约定的值当成依据。 先决定接口是开放还是封闭 内部探索工具可以允许扩展字段,稳定的交付接口则常需要更严格的边界。JSON Schema 的 additionalProperties: false 能拒绝当前对象未定义的属性,但不会自动递归覆盖每个嵌套对象。每一层允许什么,都应写清楚。 这不意味着所有接口都应该拒绝所有扩展。关键是明确选择,并为升级留下版本机制。今天默默忽略、明天突然使用同名字段,容易让历史数据产生不同解释。 把未知字段变成可观察的错误 from jsonschema import Draft202012Validator schema = {"type": "object", "required": ["name", "evidence"], "properties": {"name": {"type": "string"}, "evidence": {"type": "object", "required": ["page"], "properties": {"page": {"type": "integer", "minimum": 1}}, "additionalProperties": False}}, "additionalProperties": False} validator = Draft202012Validator(schema) valid = lambda x: not list(validator.iter_errors(x)) assert valid({"name": "Demo", "evidence": {"page": 1}}) assert not valid({"name": "Demo", "confidence": 0.99, "evidence": {"page": 1}}) assert not valid({"name": "Demo", "evidence": {"page": 1, "guess": True}}) 本例中的数值 0.99 只是一个应被拒绝的合成输入,不是任何模型的真实质量结果。示例同时检查顶层与嵌套层,防止只封闭外层、内部仍任意扩展的疏漏。 拒绝之后要给出可修复的信息 情况 返回信息应包括 不要做什么 顶层多字段 未知键名、协议版本 自动把它显示为可信指标 内层多字段 对象路径、未知键名 只返回一句 JSON 错误 新版本合法扩展 明确的新 schema 偷偷放宽旧版本 模型重复输出多余键 提取任务失败原因 每次删除后装作原输出合格 丢弃字段也是一种数据处理决定 若确实采用“读取已知字段、忽略其他字段”,应记录原始结果和过滤行为。否则很难分清源数据本来没有某项,还是接口层把它去掉了。字段丢弃也不应成为掩盖模型不遵守协议的方式。 给翻译与提取各留一条边界 文档翻译输出与结构化字段输出是两份不同的契约。使用 OmniDoc(产品入口) 处理文档时,可以把字段清单用于译后核对,但不能因为译文流畅,就自动接受额外的业务判断或置信度字段。 参考: JSON Schema additionalProperties 。 - 1 -
更新于 2026-10-08