用 Ollama 提取结构化数据：JSON 合法之后，还要验收什么

先写出“没有信息”时的正确结果 假设应用要从设备说明中提取名称、型号和维护日期。名称通常明确，维护日期却可能根本没有出现。设计输出时应先决定缺失日期用空值、缺失字段还是错误状态表示，并让结构定义与提示采用同一规则。否则，要求每个字段都有一个字符串，反而可能让下游分不清真实资料与模型补全。 一份能暴露缺失值问题的样例 用自拟材料“名称：会议室显示器；型号：M-27；购入日期：2025-08-01；维护日期未记录”测试。预期 name 为“会议室显示器”，model 为“M-27”，maintenance_date 为 null。购入日期虽然也是合法日期，却不能填进维护日期；这类错误可以通过结构校验，同时在事实层面完全错误。 若采用必填且允许空值的约定，三个字段都要出现在 required 中，但 maintenance_date 的类型允许 string 或 null。必填回答的是“对象里必须有这个键”，允许空值回答的是“资料没有给出值时怎样表示”，两者并不矛盾。不要将 null 字符串与 JSON 的 null 混用，否则后续程序可能把它当成真实文字。 再用“维护日期：2025-02-30”测试业务校验。它可以是一个字符串，却不是有效日历日期；根据应用约定，应标记异常并保留来源，不能自行推算成三月的某一天。日期格式、日历有效性与原文依据需要分别检查。 结构约束放在哪里 Ollama 官方资料区分 JSON 输出与带 Schema 的结构化输出。format 可以设为 json，也可以接收描述对象、属性及必填字段的 JSON Schema。前一种方式主要解决输出形式，后一种方式进一步约束字段结构。文档还建议把 Schema 的文字表示放进提示，帮助模型理解预期结果。 让生成与校验使用同一份定义 Python 示例以 Pydantic 定义模型，先生成 Schema，再用 model_validate_json 解析返回内容；JavaScript 示例使用 Zod 生成 JSON Schema 并解析响应。这样的组织方式减少了“提示说一种类型、解析器期待另一种类型”的维护问题。 建议把校验失败作为明确分支保存，记录失败字段与原始输入，不要直接把无法解析的文本写入业务表。若允许重试，应给出具体错误和有限次数，避免同一材料被反复请求。 格式正确之后仍要核对事实 为每种字段准备一份可人工核对的小样本：原文明确给出、原文存在歧义、原文完全缺失。逐项对照来源，检查模型有没有把猜测当成事实。枚举字段还应覆盖不属于已知类别的情况，决定是否需要“未知”选项。 如果提取的是图片内容，同样要区分“模型返回了一个符合结构的对象”与“图片识别准确”。文档提供了视觉模型配合 format 的示例，但结构约束本身不会为物体名称或图中文字提供真实性保证。 为失败样例保留一个处理出口 生产接入前，约定解析失败、类型不符、业务冲突三类结果怎样返回。解析失败可要求模型按已给结构重新生成；日期或型号在原文中相互矛盾时，重试不一定能增加证据，转人工核对或保留待确认状态更有意义。将这些状态与成功对象分开，避免一份半成品被下游当成已经验收的数据。 部署前确认运行位置 本次核对时，官方页面明确说明 Ollama Cloud 尚不支持 structured outputs。把本地接口的配置迁到云端前，应重新确认该限制及实际模型能力。低温度是文档给出的稳定输出建议，也不能替代字段与事实验收。 最终交付应包含字段定义、缺失值规则、校验失败处理和一组固定样本。后续换模型或修改提示时重复运行这些样本，比只查看一条漂亮的 JSON 更容易发现回归。

本篇涉及的工具1

Ollama

在模型响应中约束字段结构

适合场景

希望从描述文本或图片中抽取固定字段、并接入后续程序的开发者。

需要留意

需分别核对结构与事实；所核对文档注明 Cloud 暂不支持。

了解项目 访问官网