# 模型配置

# LLM结构化输出(JSON)

LLM模型默认输出格式为普通文本格式，可以设置输出标准的json格式，方便后续解析使用

当您需要模型像程序一样输出标准格式（这里主要指 JSON 格式）而不是自然语言文本，方便工具进行标准化处理或展示时，可以使用格式化输出能力。
要启用该能力，需在在模型配置中设置输出格式，来指定模型输出JSON格式，甚至通过定义JSON Schema结构，进一步定义模型输出哪些字段信息。
与通过提示词控制模型输出 JSON 格式的方法（不推荐）相比，使用结构化输出能力有以下好处：

输出更可靠：输出结构始终符合预期数据类型，包括结构中字段层级、名称、类型、顺序等，不必担心丢失必要的字段或生成幻觉的枚举值等，
使用更加简单：使用JSON Schema配置来定义，提示词可更加简单，无需在提示词中反复强调或使用强烈措辞。
原理：直接作用在模型推理时的候选词采样阶段，输出json结构更加精准

支持此功能的模型：

对于平台提供的模型，在模型配置页面能看到此选项的，则为默认已支持可直接使用，未看到此选项的可联系平台管理员支持
对于用户自定义新增的模型，需要在添加模型时配置支持此能力，详情可咨询管理员

# json_object方式（简单）

建议采用下面的json_schema，输出更加精准

如图所示，此方式设置很简单，直接在模型设置中，设置输出格式为json_object即可，需要在提示词中给出预期的json结构。
注：此设置仅保证模型输出的结构是标准的json结构，并不保证json的内容是否符合预期，如果进一步保证内容符合预期，可使用下面的json_schema方式。

# json_schema方式（推荐）

如图所示，此方式设置比较复杂，需要编写标准的json schema用于描述json结构。
注：此设置除了会保证模型输出的结构是标准的json结构，还会保证输出的内容格式与json schema中描述的一致。

如何写json_schema，格式如下，其中 {...} 里的为你真正的json结构的schema：

{
    "name":"my_schema",
    "strict": true,
    "schema": {...}
}

举例，假如我需要的json是：

{"user_id":"zhangsan","order_id":"abcd"}

那么json_schema定义如下：

{
  "name":"my_schema",
  "strict": true, 
  "schema": {
    "type": "object",
    "properties": {
      "user_id": { "type": "string", "description": "用户编号" },
      "order_id": { "type": "string", "description": "订单编号" }
    },
    "required": ["user_id", "order_id"],
    "additionalProperties": false
  }
}

注意：

采用国际标准的json schema (opens new window)定义结构。
当您需要模型严格按照结构输出时，需配置 strict 字段为 true。
当您配置 strict 字段为 false 或者未配置 strict 字段，会生成合法 JSON 结构的内容，同时尽可能参考您的定义的结构，不会对语法校验及报错。
请注意同级字段的先后顺序，模型输出将根据 schema 字段定义的字段顺序数据。

小提示

最简单的生成json schema方法就是把自己的一个json例子扔给GPT让它帮忙转换为标准的json schema，然后再在这基础上微改。
参考提示词，请替换json样例为你的json输出样例：

帮我生成一个用于LLM结构化输出的json schema，格式例子如下：
{
  "name":"my_schema",
  "strict": true, 
  "schema": {
    "type": "object",
    "properties": {
      "user": { "type": "string", "description": "用户" },
    },
    "required": ["user"],
    "additionalProperties": false
  }
}
我的json样例如下：
{"user_id":"zhangsan","order_id":"abcd"}
请直接输出json schema，不用做过多解释

# json_object与json_schema区别

结构化输出	json_schema	json_object
生成 JSON 回复	是	是
可定义 JSON 结构	是	否仅保障回复是合法 JSON
是否推荐	是	否
严格模式	支持通过设置 strict 为 `true` 生效。遵循语法，若有不支持的结构会显示报错。	不涉及
配置方式	{ "name":"my_schema", "strict": true, "schema": {...} }	选择输出格式为json_object，提示词中定义格式

# 附1. JSON Schema 语法支持说明

说明

按关键字的作用域分类，JSON Schema 有效关键字全集 https://json-schema.org/understanding-json-schema/keywords

下面支持的关键字代表已支持关键字对应的输出格式约束语义。

会自动忽略 JSON Schema 规范中没有格式约束语义的关键字。

使用明确不支持的关键字，会显式报错。

请勿与 frequency_penalty，presence_penalty 等采样参数共同使用，可能会导致模型输出异常。

# Schema 层面公共关键字

type
- integer
- number
- string
- boolean
- null
- array
- object
$ref
- 只支持 # 开头的本地相对引用
$defs
const
enum
anyOf
oneOf
- 不严格保证 exactly one 语义
allOf
- 不严格保证 all 语义

# type 相关的关键字

"type": "integer"
- minimum
- maximum
- exclusiveMinimum
- exclusiveMaximum
- 以上无法 100% 保证区间语义。
"type": "array"
- prefixItems
- items
- unevaluatedItems
"type": "object"
- properties
- required
- additionalProperties
- unevaluatedProperties

# 附2. JSON Schema 定义建议

# 字段命名与描述

字段命名含糊/无描述，导致模型难以判断含义。使用清晰有意义的英文名（如 user_name），并配合 description 详细说明字段用途。
错误示例

{
  "type": "object",
  "properties": {
    "v1": {
      "type": "string"
    }
  }
}

改进后示例

{
  "type": "object",
  "properties": {
    "user_name": {
      "type": "string",
      "description": "用户的姓名"
    }
  }
}

# 字段类型与结构设计

避免冗余嵌套与不必要复杂化
不过度使用 $ref，结构尽可能一次性展开。无意义的嵌套会增加模型生成难度，提高出错概率。
错误示例

{
  "type": "object",
  "properties": {
    "date": {
      "type": "object",
      "properties": {
        "value": {
          "type": "string",
          "description": "日期"
        }
      }
    }
  }
}

改进后示例

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "description": "日期，格式为 YYYY-MM-DD"
    }
  }
}

字段类型要明确、例子需补充
错误示例

{
  "score": {
    "type": "string"
  }
}

改进后示例

{
  "score": {
    "type": "integer",
    "description": "成绩，0到100的整数"
  }
}

说明：类型应尽量贴合实际业务。对于数字、布尔值等不能简单用 string 替代。

# 字段取值与约束设计

明确枚举值与格式
错误示例

{
  "status": {
    "type": "string"
  }
}

改进后示例

{
  "status": {
    "type": "string",
    "description": "处理状态，可为：pending、success 或 failed",
    "enum": ["pending", "success", "failed"]
  }
}

# 结构层级与必填项

所有需要的结构明确 required，这样模型会始终输出所有必需字段，格式更规范。
推荐使用 required 时，始终加上"additionalProperties": false。
错误示例

{
  "type": "object",
  "properties": {
    "steps": { "type": "array", "items": { "type": "string" } },
    "final_answer": { "type": "string" }
  }
  // 没有 required
}

改进后示例

{
  "type": "object",
  "properties": {
    "steps": { "type": "array", "items": { "type": "string" } },
    "final_answer": { "type": "string" }
  },
  "required": ["steps", "final_answer"],
  "additionalProperties": false
}

# 业务语义简明清楚，避免歧义

错误示例

{
  "type": "object",
  "properties": {
    "id": { "type": "string", "description": "用户或订单编号" }
  }
}

改进后示例

{
  "type": "object",
  "properties": {
    "user_id": { "type": "string", "description": "用户编号" },
    "order_id": { "type": "string", "description": "订单编号" }
  }
}

# 附3. Prompt 建议

# 指明任务目标，简洁表达意图

只需直接描述实际希望模型完成的任务即可，无须再过多强调“请用 JSON 输出”、“请用如下格式输出”等。
不必在 prompt 中重复 schema 结构的信息，避免造成矛盾或冗余。

错误示例

请用如下 JSON 格式输出，并包含字段 steps、final_answer：8x + 9 = 32，x+y=1。

改进后示例

请求解：8x + 9 = 32，x + y = 1。

# 结合结构化信息写业务内容，而不是格式引导

关注“内容本身”，而非“输出形式”。
业务描述越具体，LLM 更易给出符合 schema 的内容。

错误示例

请输出一个包含 steps 和 final_answer 字段的 JSON。

改进后示例

请一步步推理解答：8x + 9 = 32, x+y=1，并写出最终答案。

← 新增模型工作流节点 →