OpenAI Node 库中 JSON Schema 的 nullable 修饰符问题解析

在 OpenAI Node 库的使用过程中，开发者发现了一个关于 JSON Schema 中 nullable 修饰符的重要问题。这个问题主要出现在使用 Zod 库定义可空字段时，不同的语法会导致模型行为不一致。

问题背景

在使用 Zod 定义可空字段时，开发者通常有两种方式：

1. 使用联合类型：z.union([z.string(), z.null()])
2. 使用 .nullable() 方法：z.string().nullable()

这两种方式在生成的 JSON Schema 中会表现为不同的结构：

• 联合类型会生成 { "type": ["string", "null"] }
• .nullable() 方法会生成 { "type": "string", "nullable": true }

问题表现

开发者发现，当使用第二种方式（.nullable() 方法）时，GPT-4o 模型总是返回字符串而不会返回 null 值，而第一种方式（联合类型）则能正常工作。这意味着在结构化输出中，nullable 修饰符被模型忽略了。

技术分析

这个问题实际上涉及 JSON Schema 规范的实现差异。虽然两种语法在语义上都表示字段可为空，但在 JSON Schema 的不同版本中，对可空性的表示方式有所不同：

1. 联合类型方式使用的是 JSON Schema Draft 7 的标准方式
2. .nullable() 方式使用的是 OpenAPI 规范中常见的扩展属性

OpenAI 的模型最初可能只完整支持第一种标准方式，而对扩展的 nullable 属性支持不完整。

解决方案

OpenAI 团队已经确认并修复了这个问题。现在 API 已经更新，完全支持 nullable 属性。开发者可以放心使用 .nullable() 方法来定义可空字段。

进阶问题

虽然基础的可空字段问题已经解决，但开发者报告在嵌套结构中仍然存在问题。例如：

z.object({
  foo: z.string().nullable(),
  bar: z.array(
    z.object({
      baz: z.number().nullable(),
    })
  ).nullable(),
});

在这种情况下，嵌套的可空字段（如 baz）可能仍然会被模型填充而不是返回 null。这可能是模型在处理复杂嵌套结构时的另一个限制，建议开发者在遇到这种情况时：

1. 明确在描述中说明可为空的情况
2. 或者提供默认值作为备选方案

最佳实践

基于当前情况，建议开发者在定义可空字段时：

1. 优先使用 .nullable() 方法，语法更简洁
2. 对于关键的可空字段，在描述中明确说明可为空的情况
3. 对于复杂嵌套结构，进行充分测试以确保模型行为符合预期
4. 考虑为可为空字段提供合理的默认值作为备选方案

随着 OpenAI 不断改进其模型和 API，这类结构化输出的问题将会得到更好的解决，为开发者提供更稳定可靠的体验。