第七章结构化生成与 API 表面 on Machine Learning 学习笔记

7.1 response format 与 grammar constraints

Mon, 01 Jan 0001 00:00:00 +0000

response format 与 grammar constraints#

到了这一章，问题已经不再是“请求怎样走”或者“执行层怎样选 token”，而是“这些 token 在生成时怎样被限制在某种结构空间里”。这就是 response format 和 grammar constraints 进入执行链的地方。

这一节解决什么问题#

这一节主要回答三件事：

response_format 为什么最后会落到采样参数里；
grammar constraint 为什么不是后处理，而是生成期约束；
为什么结构化约束必须和执行层一起理解，而不能只当作 API 表面功能。

`response_format` 真正落在哪#

从 ChatCompletionRequest.to_sampling_params 可以直接看出，response_format 并不会停留在 OpenAI-compatible 请求表面，而是会被转换成：

json_schema
structural_tag
或其他结构化约束字段

也就是说，对 runtime 来说，它最后看到的不是 “response_format 是什么对象”，而是“这一轮 token selection 受什么结构约束”。

如果把这条链先压成图，会更容易看清：

flowchart LR
 A["response_format"] --> B["to_sampling_params(...)"]
 B --> C["json_schema / structural_tag / regex / ebnf"]
 C --> D["SamplingParams"]
 D --> E["token selection"]

图里最重要的一点是：response_format 的终点不是“另一个响应对象”，而是执行层里的约束输入。

为什么 grammar constraint 不是后处理#

如果结构化输出只是后处理，系统应该先自由生成，再在结果出来后检查格式。但当前设计不是这样：约束在 to_sampling_params(...) 阶段就进入了执行层的参数集合。

7.2 tool choice、function calling 与 parser

Mon, 01 Jan 0001 00:00:00 +0000

tool choice、function calling 与 parser#

上一节讲的是“怎样限制输出空间”，这一节讲的是“怎样把已经生成出来的结构解释成工具调用语义”。这两件事容易被混在一起，但它们不是同一个层次的问题。

这一节解决什么问题#

这一节主要回答三件事：

tool choice 为什么最终还是要落到执行约束里；
function calling parser 为什么不是 grammar backend；
parser 在 streaming 和 non-streaming 场景里分别承担什么角色。

一张图先看 function calling 的两层关系#

flowchart LR
 A["tool_choice / tools"] --> B["get_structure_constraint(...)"]
 B --> C["json_schema / structural_tag constraint"]
 C --> D["SamplingParams"]
 D --> E["model output"]
 E --> F["FunctionCallParser parse"]
 F --> G["tool call objects"]

这张图最重要的一点是：tool choice 先改写执行期约束，parser 再解释输出结果。这两件事都属于 function calling，但不发生在同一层。

parser 解决的不是“限制”，而是“解释”#

FunctionCallParser 的职责从类定义就写得很清楚：它处理的是 function / tool call 的解析，而不是 token 级约束本身。

7.3 Responses API 与 built-in tools

Mon, 01 Jan 0001 00:00:00 +0000

Responses API 与 built-in tools#

前两节已经把结构化约束和 function calling parser 讲清楚了，但如果只停在这里，这一章仍然缺一块很重要的表面：当响应不再只是一次性文本，而是一个可以被追踪、检索、取消，甚至带着工具上下文继续推进的运行中实体时，系统怎样管理它。

这一节解决什么问题#

这一节主要回答三件事：

Responses API 为什么不只是“另一种返回格式”；
background request、retrieve、cancel 为什么会让 response 长成一个实体；
built-in tools 为什么在这个 surface 里更显眼。

Responses API 改写的不是字段，而是工作流#

OpenAIServingResponses.create_responses 最值得注意的不是参数多，而是它把 response 变成了一个之后还能被继续操作的对象。

一旦进入 background 模式，请求就不再只是“一次 request-response”，而会长出：

background
request_id / response_id
response store
background task lifecycle
retrieve / cancel 语义

这说明 Responses API 改写的不是字段，而是工作流。

这条工作流如果先压成一张图，会更容易看清：

flowchart LR
 A["create_responses(...)"] --> B["foreground response"]
 A --> C["background task + response_store"]
 C --> D["retrieve_responses()"]
 C --> E["cancel_responses()"]

图里最重要的一点是：一旦进入 background 模式，response 就不再只是当前连接里的一次性结果，而会继续活在系统里。

第七章 结构化生成与 API 表面 on Machine Learning 学习笔记

7.1 response format 与 grammar constraints

response format 与 grammar constraints#

这一节解决什么问题#

response_format 真正落在哪#

为什么 grammar constraint 不是后处理#

7.2 tool choice、function calling 与 parser

tool choice、function calling 与 parser#

这一节解决什么问题#

一张图先看 function calling 的两层关系#

parser 解决的不是“限制”，而是“解释”#

7.3 Responses API 与 built-in tools

Responses API 与 built-in tools#

这一节解决什么问题#

Responses API 改写的不是字段，而是工作流#

第七章结构化生成与 API 表面 on Machine Learning 学习笔记

`response_format` 真正落在哪#