Liquid AI d1 决策模型上线 AI Gateway：不生成文本，直接输出结构化答案

AI Gateway 迎来一个思路完全不同的模型——Liquid AI 的 d1。它不生成任何文本 token，而是直接对共享状态进行判断，输出带概率的结构化答案，用于分类、路由和打分场景。

d1 是什么：决策模型而非生成模型

传统大模型的工作方式是「输入提示词，输出一段文本」，再由程序去解析这段文本。d1 跳过了这个环节。它的定位是决策模型（decision model）：接收一段共享状态（state），针对预定义的类型化问题（typed questions） 给出答案。

答案本身就是结构化的——布尔值、选项或分数，并附带概率。这意味着调用方拿到的是可以直接进入下游逻辑的数据，不再需要正则匹配或 JSON 解析这类脆弱的后处理步骤。

用原文的示例来说明：状态是「客服已向客户全额退款」，问题是 refunded: { type: 'boolean', instructions: 'Was a refund issued?' }，d1 直接返回这个布尔字段的结果。整个过程没有自然语言输出，也就没有解析歧义。

共享状态（state） 是 d1 调用范式中的核心概念，指调用方传入的一组上下文数据，可以包含文本片段、结构化字段、图片等多种类型。与生成模型把状态拼进提示词再由模型自由发挥不同，d1 把状态当作推理的输入事实，配合预定义的类型化问题（typed questions） 共同决定输出形态。类型化意味着每个问题在声明时就绑定了答案的数据类型，例如 boolean、choice、score，模型只能在既定类型空间内作答。这种做法把「模型输出什么」从提示词的软约束变成了接口层面的硬约束，调用方在编排状态时就能明确哪些信息必须提供、哪些字段会被回填，从而把决策逻辑与业务流程更紧密地耦合起来，减少运行时的不确定性。

视觉输入：对图像做类型化提问

d1 同时支持视觉输入。你可以把图片作为状态的一部分传入，然后对图像内容提出类型化问题，用于视觉分类、检查和打分。

官方示例读取一张本地 PNG（square.png），询问方块是什么颜色：状态中放入 image_url 类型的 base64 数据，问题类型设为 choice，候选答案为 red、blue、green。d1 返回选中的颜色及其概率。

这个能力对质检、内容审核、工业视觉分拣一类场景很有价值——以往需要单独训练一个分类模型，现在可以用统一的决策接口完成。

这里提到的 base64 编码，是一种把二进制数据（如图片字节）转换为由 ASCII 字符组成的文本字符串的编码方式。通过将 PNG 等图像文件编码为 base64，就能把它作为普通字符串嵌入到状态字段中，与文本数据一起通过 HTTP/JSON 接口传输，无需额外的文件上传或多部分表单。状态中 image_url 类型字段通常既接受远程图片链接，也接受形如 data:image/png;base64,... 的 data URL，后者即为内联 base64 数据的常见写法。需要注意的是，base64 会使体积膨胀约 33%，大图内联会显著增加请求负载，实际使用中常配合压缩或按需裁剪来平衡质量与传输开销。

三种调用方式

在 AI Gateway 上，d1 以 liquid/d1 的标识提供服务，支持三种接入路径：

• AI SDK decision API：通过 experimental_decide（别名 decide）调用，传入 model、state 和 questions 三个字段。
• OpenAI 兼容的 Decisions API：适合已有 OpenAI 调用链的团队迁移。
• TypeSafe 兼容 API：面向偏好类型安全接口的开发者。

原文同时也提醒，Choice、Score 和 Boolean 三类问题的具体用法可以查阅 decision 文档，模型选择可以在可用模型列表中浏览。

OpenAI 兼容 API 指服务端按照 OpenAI 的接口约定（请求路径、字段命名、响应结构）暴露能力，调用方只需替换 base URL 和模型标识，原有 SDK 和重试、流式处理、错误码解析等逻辑基本可以复用，迁移成本很低。TypeSafe 兼容 API 则强调在类型系统层面提供约束，通常会生成或提供带类型的客户端，让问题字段、答案类型和返回结构在编译期就能被检查，减少拼写错误和类型不匹配导致的运行时失败。这两条路径与 AI SDK 的 decision API 并存，实质上是把同一套决策能力包装成不同开发者习惯的接入形态，团队可以按现有技术栈选择，而不必为了用 d1 重构整条调用链。

AI Gateway 带来的工程便利

AI Gateway 本身提供统一的模型访问入口，并跟踪用量与成本。d1 的决策调用会和其他模型请求一样出现在日志中，也计入预算统计。

对于已经在 AI Gateway 上管理多个模型的团队，这一点意味着不需要为 d1 单独搭建一套观测体系。成本归因、调用审计、限额控制都可以复用现有流程。

这类模型改变了什么

从工程视角看，d1 代表了一种分工思路：生成任务交给语言模型，判断任务交给决策模型。路由、分类、打分这些场景并不需要流畅的文本来证明结果正确，它们需要的是低延迟、可解释、可校验的输出。

结构化答案加概率的组合，也让调用方可以做阈值控制——概率低于某个值时转人工处理，高于阈值则自动执行。这是纯文本生成模型很难直接提供的工程接口。

值得关注的是，决策模型能否在准确率上稳定超过「小模型 + 提示词工程」的方案。原文没有给出基准数据，实际效果还需要在具体业务中验证。

上手路径

如果你已经接入 AI Gateway，可以直接使用 liquid/d1 标识开始测试。建议从最简单的是非判断题入手，比如判断某条工单是否已升级、某段对话是否包含退款承诺，再逐步扩展到带候选选项的 Choice 问题和视觉输入场景。