面向限定答案的决策API：从通用推理到有界决策的工程化落地

一、背景：为什么需要“限定答案”的决策接口

大模型在开放域生成任务中表现出色，但在业务系统里，大量调用并非要求“自由创作”，而是要求“在有限选项内给出判断”。典型场景包括：内容是否合规、工单应路由到哪个队列、交易是否需要人工复核、图像中是否包含目标物体、结构化表单的字段应取哪个枚举值。这类问题的共同特征是答案空间有界、判定标准可枚举、对响应延迟敏感。

直接使用通用推理接口处理这类任务存在三个结构性问题：

1. 输出冗长：通用接口倾向于生成完整解释，解析成本高，且容易引入不符合枚举约束的取值。
2. 延迟偏高：自回归逐token生成的模式，使输出长度直接决定响应时间，难以满足准实时要求。
3. 计量不匹配：按输入输出双向计费的模式，在“短问题、短答案、高频次”的决策场景中成本不经济。

面向限定答案的决策API正是针对上述痛点设计的专用接口形态：它将模型能力收敛到有界问题域，以结构化输入换取结构化输出，并通过缓存、多问题批处理与推理数据驻留等机制，把“判断”这件事做成可预测、可计量、可治理的基础设施能力。

二、接口定位与能力边界

2.1 定位：判断层，而非生成层

决策API在系统架构中处于“判断层”，其上游是业务规则引擎与数据管道，下游是动作执行器。它不承担长文本生成、多轮对话或复杂工具编排职责，而是回答“是/否”“属于哪一类”“取哪个枚举值”这类有界问题。与通用推理接口相比，其核心差异体现在：

• 答案空间受限：输出被约束在预定义选项或结构化schema内，降低后处理复杂度。
• 延迟优先：通过专用推理路径与缓存机制，响应速度显著优于通用调用路径。
• 计量简化：仅按输入token计费，输出不计费，便于对高频短输出场景做成本建模。

2.2 能力边界与适用性判断

该接口适用于答案可枚举、判定标准可书面化、单次请求问题数量可控的场景。对于需要开放式解释、长链推理或创造性输出的任务，仍应使用通用推理接口。工程上建议以如下标准做分流：

• 问题可归结为有限标签集或布尔判定 → 决策API；
• 需要生成解释性文本或面向用户的自然语言回复 → 通用推理接口；
• 需要多步工具调用与状态维持 → 智能体编排层，决策API可作为其中单步判断节点。

三、输入契约：原生JSON、图像与批量问题

3.1 结构化输入优先

决策API支持原生JSON输入，这意味着业务系统可以将待判定对象以结构化形式直接传入，无需先拼接为自然语言提示词。这一设计带来两个工程收益：其一，减少提示词构造层的维护成本；其二，字段语义明确，便于在指令中引用具体路径，降低歧义。

示意性请求结构如下（字段名为说明性示例，实际以接口文档为准）：

{
  "instructions": "根据以下规则判断工单应路由至哪个队列",
  "questions": [
    {
      "id": "q1",
      "input": {
        "ticket_type": "refund",
        "amount": 128.5,
        "channel": "web",
        "has_attachment": true
      }
    }
  ]
}

3.2 图像作为问题上下文

接口支持在问题指令中包含图像，使多模态判定与文本判定共用同一调用路径。适用于质检、内容审核、单据识别后的字段校验等场景。工程上应注意：图像输入会显著增加输入token量，需在成本模型中单独核算，并对图像做必要的压缩与裁剪，避免无效像素进入计量。

3.3 单次最多400个问题

单次请求可提交的问题上限提升至400个，为先前上限的两倍。这一变化对批量判定场景意义明显：可将同一批次、同一指令下的多个待判对象合并为一次调用，摊薄网络往返与指令开销。实践中建议按“同一指令、同一schema、同一优先级”三个维度做批分组，避免将异质问题混批导致指令冲突。

四、输出契约与解析策略

决策API的输出面向有界答案，工程上应按“强约束解析 + 兜底策略”设计消费端：

1. schema校验：对返回的枚举值或布尔结果做严格校验，拒绝越界取值。
2. 缺失处理：对未返回结果的问题项，按业务优先级进入重试队列或降级规则引擎。
3. 幂等消费：以问题id作为幂等键，确保批处理重试不产生重复动作。
4. 审计留痕：记录输入摘要、指令版本与返回结果，满足可追溯要求。

需要强调的是，有界答案不等于零错误。对高风险判定（如资金动作、权限变更），应保留人工复核或二次判定通道，将决策API定位为“提效层”而非“唯一裁决层”。

五、性能与延迟优化路径

5.1 缓存复用上下文

针对复用上下文的提示缓存是延迟与成本优化的关键手段。当多条请求共享同一段长指令或同一批规则说明时，命中缓存的输入部分按更低的单价计量。工程建议：

• 将稳定不变的规则说明、schema定义置于指令前部，易变字段后置，提升缓存命中率；
• 对同一业务域的批量任务保持指令模板一致，避免逐请求改写导致缓存失效；
• 监控缓存命中率作为核心指标，纳入容量与成本看板。

5.2 推理数据驻留

接口在美国和欧盟提供推理数据驻留支持，这对有数据本地化要求的业务至关重要。架构设计时应将“数据驻留区域”作为部署参数纳入配置管理，确保请求路由到合规区域，并在日志与审计中记录驻留属性。

5.3 容量与延迟的地区差异

服务容量在亚洲多个地区持续扩充，意味着跨区域调用时的延迟表现存在差异。实践中建议：按用户地理分布选择就近接入点；对延迟敏感的在线判定链路，建立多区域探活与自动切换机制；将P99延迟而非平均值作为SLO目标。

六、成本模型与容量规划

该接口仅按输入token计费，输出token免费，缓存命中的输入按更低单价计量。这一计费结构决定了成本优化的重心从“控制输出长度”转向“控制输入体积与提升缓存命中”：

• 压缩输入：精简JSON字段、去除冗余文本、对图像做必要裁剪；
• 提高批密度：在400问题上限内合理合批，摊薄指令开销；
• 提升缓存命中：稳定指令前缀，减少模板漂移；
• 分层调度：对非实时判定使用低优先级队列，对在线链路保留容量余量。

容量规划上，应以“每秒问题数 × 平均输入token”估算吞吐需求，并结合缓存命中率折算有效单价，避免仅按原始单价做预算导致偏差。

七、落地实践要点

1. 指令版本化：将指令与schema纳入版本管理，判定结果关联版本号，便于回溯与灰度。
2. 灰度与对照：新指令上线前，与既有规则引擎或旧版本指令做并行对照，评估一致率。
3. 失败隔离：决策API调用失败不应阻塞主链路，应降级到规则兜底或人工队列。
4. 可观测性：采集请求量、问题数分布、缓存命中率、P99延迟、schema校验失败率等指标。
5. 安全边界：对输入做敏感信息脱敏，对输出做枚举白名单校验，防止越权判定。

八、结语

面向限定答案的决策API，本质上是把模型能力从“通用生成”收敛为“有界判断”，并通过结构化输入、批量问题、缓存复用与数据驻留等机制，使其具备准实时、可计量、可治理的工程属性。对于拥有大量高频判定需求的业务系统，合理的做法是：先识别出答案可枚举的判断点，再以指令版本化与schema校验保障可控性，最后用缓存命中率与输入体积管理成本。在此基础上，可将该能力与百度智能云侧的通用类目能力（如对象存储承载输入素材、日志服务承载审计留痕、监控告警保障SLO）协同编排，形成从数据接入、判断执行到结果消费的完整链路。