TypeSafe AI发布Jev 1.14：决策模型登录AI Gateway，新增图像与长上下文支持

TypeSafe AI 的决策模型 Jev 迎来 1.14 版本更新，并正式上线 AI Gateway。与生成自由文本的传统大模型不同，Jev 专注于结构化决策任务——你向它传入状态和一组问题，它会返回带概率的、类型化的 Choice、Score 和 Boolean 答案。

什么是决策模型？

Jev 的定位是「面向软件的决策模型」。在实际工程场景中，很多 AI 需求并不是让模型写一段话，而是让它在有限选项里做判断：这段内容属于哪个类别、这个请求应该路由到哪条管线、这条日志是否存在异常、某张图片是否符合条件。

传统做法是把这些问题包装成 prompt，然后解析模型返回的自由文本。这种方案不仅解析成本高，还容易因格式抖动导致下游流程失败。Jev 的思路是从接口层面消灭这种不确定性——所有问题一次性并行请求，直接返回类型化答案和对应概率。

据官方介绍，该模型可覆盖分类、路由、评分和自动化验证等场景，这让它更适合嵌入到已有的软件系统中，而不是作为独立的对话应用存在。

类型化输出（Typed Output） 是 Jev 与传统大模型最本质的区别。传统 LLM 的输出是一个 token 序列，本质上是字符串；即便通过 JSON mode 或 function calling 约束格式，返回值在类型系统层面仍然是不透明的——下游代码必须做运行时校验，例如用 Zod 或 Pydantic 解析，并在解析失败时走降级分支。Jev 把这种约束前移到了模型接口本身：调用方在 questions 参数中声明字段名和类型（boolean、choice、score），模型直接返回已满足该 schema 的结构化对象，无需二次解析。

概率输出（Probability） 则解决了另一个工程痛点。自由文本的「确定性」只能靠措辞隐式表达（如「很可能」「也许」），无法量化；而 Jev 为每个答案附带一个 0-1 的置信度，使下游可以写出显式的阈值逻辑，例如 if (answer.probability < 0.8) routeToHuman()。这把 AI 决策从「非确定性黑箱」变成了可观测、可路由、可审计的组件，是它能嵌入软件系统的关键前提。

两项关键更新：图像输入与长上下文

图像作为状态的一部分

Jev 1.14 开始接受图像输入。开发者可以将图片以 file part 的形式与文本一起放入 state，然后针对图像内容提出 Boolean 或其他类型的问题。

官方给出的示例是读取一张本地 PNG 产品照片，询问「该图像是否以红色为主」。代码中通过 AI SDK 的 experimental_decide 调用模型 typesafe-ai/jev-1.14.0，state 数组中同时包含文本描述和文件部分：

const result = await decide({
  model: 'typesafe-ai/jev-1.14.0',
  state: [
    { type: 'text', text: 'A product photo from a support ticket.' },
    { type: 'file', mediaType: 'image/png', data: readFileSync('./photo.png') },
  ],
  questions: {
    red: { type: 'boolean', instructions: 'Is the image predominantly red?' },
  },
});

模型返回的 result.answers.red 即为带概率的布尔答案。这种模式对于客服工单自动分类、内容审核等需要结合视觉信息的判断流程尤为实用。

AI SDK 是 Vercel 推出的开源工具库，用于在 TypeScript/JavaScript 中统一调用不同厂商的模型。它通过 provider 抽象层，让同一份调用代码可以切换 OpenAI、Anthropic 或本示例中的 TypeSafe AI，无需改动业务逻辑。

state 与 questions 的分离 是 Jev API 的核心设计。state 描述「当前情境」——可以是一段文本、一张图片、一段日志，甚至混合多种模态；questions 描述「要问什么」——可同时声明多个字段，模型并行给出各自答案。这种分离带来两点好处：一是同一份 state 可以复用于多组问题，减少重复传入；二是问题集合本身是类型化的，前端代码可以据此静态推导返回值的类型，做到端到端的类型安全。experimental_decide 中的 experimental_ 前缀则提示该 API 仍处于快速迭代阶段，签名可能变化。

实验性长上下文模式

针对文档、日志或超长对话历史，Jev 1.14 提供了实验性长上下文模式，通过 providerOptions.typesafe.longContext: true 开启。

官方示例读取一段支持日志，判断「日志中是否提到送达商品出现损坏」。与图像输入类似，开发者只需将长文本作为 state 传入，配合 Boolean 问题即可获得结构化判断结果。

长上下文模式的标注仍是「实验性」，这意味着它在稳定性和成本上可能还有变化空间，适合先行评估而非直接用于关键生产路径。

长上下文（Long Context） 指的是模型单次请求能够处理的输入长度上限。常规模式下，模型可能只接受几千 token；开启 longContext 后，可扩展到数万乃至更多，代价通常是更高的延迟与费用，且注意力在超长输入上的衰减可能影响判断稳定性。

对决策任务而言，长上下文的意义在于：很多判断依赖全文而非局部线索。例如「日志中是否提到送达商品出现损坏」，损坏描述可能出现在第 500 行，而无关的异常堆栈占据前 4000 行。若截断输入，模型可能错过关键证据；若先做检索再判断，又引入了额外的召回失败风险。长上下文模式让状态整体进入模型，减少工程链路层级，但正因为成本与稳定性尚未定档，官方标注为「实验性」，建议先用于可回退的评估流程。

企业级特性与生态集成

Jev 在合规和数据安全上提供了明显面向企业客户的选项：

• Zero Data Retention：可逐请求启用，承诺不保留数据
• No Training：可逐请求启用，承诺数据不用于训练
• 可观测性：决策调用会出现在日志和自定义报表中，并计入预算统计
• Gateway 兼容：接受其他 Gateway provider options，统一放在 providerOptions.gateway 对象中

这些能力让 Jev 更容易通过企业采购中的安全审查。对于已经把 AI Gateway 作为统一入口的团队，新增一个决策模型意味着无需引入新的供应商管理流程。

Zero Data Retention（ZDR） 与 No Training 是企业采购 AI 服务时最常见的两项合规门槛。前者要求服务方在请求完成后不持久化任何用户数据，通常以「逐请求开关」形式提供，便于企业在处理敏感工单时临时启用；后者则承诺输入输出不被用于改进模型权重。二者常与 SOC 2、GDPR 等审计框架一并被安全团队核查。

AI Gateway 则扮演统一入口的角色：团队只需维护一套凭证、计费与日志体系，就能接入多家模型供应商。Jev 通过接受 providerOptions.gateway 对象兼容这一机制，意味着已经使用 Gateway 的组织无需新建采购或密钥管理流程即可试用，显著降低了引入新模型的边际成本。这也是「决策模型」能被快速采纳的组织层面前提。

对开发者的实际意义

从工程视角看，Jev 1.14 的价值不在于模型能力本身有多强，而在于它把「AI 参与决策」这件事标准化了。类型化输出消除了 prompt 解析层，概率输出则为下游阈值判断提供了依据——你可以设定「置信度低于某阈值时转人工」，而不必猜测模型文字表达的确定性。

图像和长上下文两项更新，则把这套决策范式从纯文本分类扩展到了更贴近真实业务的输入形态。客服工单、物流日志、产品照片这些非结构化数据，现在可以直接进入同一个决策接口。

官方建议开发者查阅 AI Gateway 上关于决策模型的文档、Jev 的实用案例以及知识库资源，以评估其在自身场景中的适用性。