利用 JSON Schema 增强 LLM 在多层嵌套输出中的稳定性

在处理非结构化文本并将其转换为三层嵌套的实体-属性-关系结构时，GPT-4o 与 Claude 3.5 Sonnet 的表现差异明显。通过 API 的 response_format 传递 JSON Schema，GPT-4o 能够极高地维持输出稳定性，开发者无需在 Prompt 里重复强调格式要求。

即使面对如下复杂的嵌套结构，GPT-4o 在开启 JSON Mode 或 Structured Outputs 后依然能精准填充，极少出错，且不会出现漏写括号或在末尾添加废话的情况：

{
  "type": "object",
  "properties": {
    "entities": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "attributes": {
            "type": "array",
            "items": { "type": "object", "properties": { "key": { "type": "string" }, "value": { "type": "string" } } }
          }
        }
      }
    }
  }
}

相比之下，Claude 3.5 Sonnet 在嵌套深度超过三层时，偶尔会把 entity_name 误写为 entityName。不过它对正则约束的理解较深，建议通过 Tool Use 来强制格式化。DeepSeek-V2.5 在大规模数据下表现尚可，但在极端复杂结构中可能会将数组扁平化，导致后端解析报错。

针对不同场景的选型建议：GPT-4o 可直接对接生产 API 并专注于业务逻辑；Claude 3.5 适用于强推演后的 JSON 输出，建议配合 Tool Use；DeepSeek 则在处理简单嵌套时性价比高，复杂结构可通过 One-Shot 示例优化。

在定义 Schema 时，应强制设置 required 字段并避免 additionalProperties: true，否则模型随机删除字段会导致后端程序异常。

若将输出结果存储在数据库中，可参考 Supabase 平台发布的 pg_jsonschema 扩展，它为 json 和 jsonb 类型增加了校验支持。当复杂数据总是被统一消费时，使用文档数据类型更合适，否则恢复原始输入可能需要 5 次 join 操作。

在部署相关文档至 GitHub Pages 时，若出现 Page not found · GitHub Pages 404 File not found 报错，通常是因为 the site configured at this address does not contain the requested file。此时应检查文件名大小写是否与 URL 一致及文件权限，若访问根目录则必须提供 index 文件。更多详情可查阅 GitHub Pages 完整文档或关注 @githubstatus 了解 GitHub Status。