官方 Jev 模型与 legal 页上线前必读

先说结论

1. 官方 Models 页当前只公开一个版本化模型：Jev 1.13，模型 ID 是 jev-1.13.0；两个别名 jev-latest 和 jev-preview 当前都指向它。
2. 官方文档明确写到，响应里的 model 字段会返回实际回答的版本化 ID，因此可以把它写进日志，用来监控版本漂移；官方还建议，如果已经针对某个版本调过置信度阈值，应固定该版本 ID，而不是继续用 jev-latest。
3. Legal 页本身只给出三份文档入口，并明确写了“不会用用户数据训练模型”以及企业级 ZDR；但具体保留期限、PII 处理限制、合同细节并未在这一页展开。
4. Confidence 页把置信度定义为从概率分布算出的一个 0 到 1 的数字，并给出高/中/低三档路由思路；其中阈值只是示例，不是通用标准。
5. 上线前必读的是三页：System One 概念页、Confidence 页、legal 页；同时所有在线调用都应把 model 字段接入日志、告警和回归测试。

官方 Models 页逐条核对：模型、别名与版本字段

官方 Models 页明确写到：

“Every model on this page is served by the same endpoint, POST /v1/systemone . The request’s model field selects which one handles the call.”

这句说明所有模型共用 /v1/systemone 端点，靠请求体的 model 字段选择。页面当前模型的表格给出的官方数据如下：

• 版本：Jev 1.13，模型 ID：jev-1.13.0；
• 价格：每 Btok 42 美元、每 Mtok 0.042 美元；页面还写 Charged per input token. Output tokens are free. A Btok is a billion tokens and an Mtok is a million tokens.；
• 速率限制：250,000 tokens per second / 1,200 requests per minute；
• 上下文长度：64k tokens per request; 32k tokens for state plus the longest question；
• 输入：Text only. String, JSON object, or array of text values. No image, audio, or video input.

这些是官方数据，不是我的推算。需要特别注意：官方原文还写明速率限制是动态调整的：

“Rate limits are adjusting dynamically. We are serving a very large volume of demand, and the limits above can change without notice while we do…”

所以我不会把这些速率数字当成 SLA 或者固定承诺。上线评估容量时应以页面实时的 250,000 tokens per second / 1,200 requests per minute 为参考，但要留出变化余量。

语言支持方面，官方 Models 页英文原句是：

“English is the primary training language and where accuracy is currently best. Other languages, including CJK scripts, are handled but not equally well; test on your own content before relying on Jev for a non-English workload, and pay close attention to Confidence when routing.”

这意味着中文等 CJK 文本虽然在支持范围内，但官方没有给出可比肩英文的准确率指标。中文业务上线前，必须用自有评测集做回归，不能直接把英文场景的阈值照搬过来。

数据处理方面，Models 页还写了两个与合规直接相关的句子：

“Jev is not fine-tuned or LoRA-adapted with customer data. It is trained with RLCD to return calibrated decisions, and the same weights serve every account.”

“Jev is not trained on customer requests or responses. See Legal for the Data Processing Agreement, the Privacy Policy, and details on zero data retention (ZDR) for enterprise customers.”

这两条说明模型权重不是按客户数据微调出来的，也不使用客户请求和响应用于训练。但需要注意的是，这并不等于“你的数据不会以其他方式被处理”。它能回答“训练用途”的一部分，不能回答“保留期限”和“PII 处理边界”的全部问题。

别名会漂移，需要固定版本 ID

官方 Models 页的别名表也是关键。jev-latest 和 jev-preview 当前都解析到 jev-1.13.0，页面还有一句：

“An alias moves when a new release ships, so the answers behind it can change without a change on your side. The response’s model field reports the versioned ID that answered, so you can log which model produced each result. If you have tuned confidence thresholds against a specific version, pin that version’s ID instead of the alias and move to the new one on your own schedule.”

这句我把它拆成三层理解：

1. 别名不是稳定版本。即使代码没改，jev-latest 背后可能悄悄升级；
2. 响应中有一个 model 字段，会返回实际处理请求的版本化 ID，例如 jev-1.13.0；
3. 如果已经把置信度阈值调到某个版本上，官方文档建议固定（pin）该版本的 ID，按自己的节奏迁移。

这正好能支撑版本漂移监控。把这句官方原话和自己的工程建议分开说：官方说“可以 log、可以 pin”；本文接着给出一套最小可落地的版本监控做法。

列模型接口

官方 Models 页还给出了列出模型的 curl 示例，我把它整理成可执行的命令：

curl https://api.typesafe.ai/v1/models 
  -H "Authorization: Bearer $TYPESAFE_API_KEY"

这个接口返回模型名、描述和发布日期。需要留意：官方原文说 GET /v1/models 目前列出别名；但版本化 ID 如 jev-1.13.0 无论是否出现在列表中都可用于 model 字段。也就是说，不能只用 /v1/models 的返回当作全部可用模型判断，版本化 ID 要另行确认。

官方 Legal 页只写了这些，不要引申

官方 Legal 页 内容非常简短，但上线前值得逐条看。它开头的原文是：

“These documents cover how TypeSafe handles your data when you have an account with us, including data retention, our commitment not to train models on user data, and the general customer agreements that govern your use of TypeSafe.”

页面接下来只列了三份文档：

文档	页面写明的用途
Data Processing Agreement	how we process customer data on your behalf, including data retention.
Master Customer Agreement	the general terms that apply to your TypeSafe account.
Privacy Policy	what data we collect and how we use it, including our commitment not to train models on user data.

以及一句企业级条款：

“We also offer zero data retention (ZDR) for enterprise customers. Contact privacy@typesafe.ai to learn more.”

我能确认的是：官方 Legal 页明确提到“不训练用户数据”和企业级 ZDR；不能确认的是：具体保留期限是多少天、哪些请求落入 ZDR 范围、PII 是否允许处理、输出是否可作为决策依据。页面本身没有展开这些内容，只指向文档。遇到合规审查时，应当进一步打开三个法律文档，或发邮件给 privacy@typesafe.ai 确认，而不是只停留在 Legal 概览页。

System One 与 Confidence 对“使用方式”的边界

Legal 解决数据与合同边界，使用方式边界还要看另外两页。

System One 概念页 给模型的能力划了一条清晰的线：

“System One models do not write replies, produce code, or generate explanations of their reasoning.”

它还说 System One 返回的是“typed answers and probabilities”，而不是长文本生成。这意味着不能把 Jev 当成聊天模型或代码生成模型用；它适合做结构化判断。比如工单里的场景，路由、评分、二元判断等。

Confidence 文档 则说明置信度的来源：

“confidence is a statistic computed from the probability distribution the answer already gives you. TypeSafe computes it for you and returns it on every Choice and Score answer, so the common case needs no extra work on your side.”

注意：官方写明 Noul 答案不携带 confidence；Choice 和 Score 有。它还写：

“A confidence threshold is not one number. Different actions within the same system should be gated at different levels depending on the consequences of getting it wrong.”

这非常重要。不要从全局只设一个 0.9 或者 0.5 阈值。下面给出版本策略和合规清单时，我得把“阈值属于工程决策”这点说清楚。

官方 Confidence 页也提供了一段示例代码，用来演示不同置信度下不同处理路径。我把它简化成三档逻辑：

confidence = action.confidence

if confidence < 0.5:
    route_to_human(user_message)
elif action.choice == "check_balance":
    show_balance(account_id)
elif action.choice == "approve_transfer":
    if confidence > 0.9:
        confirm_then_execute(account_id)
    else:
        ask_user_to_confirm(account_id)

这段代码来自官方页面示例，但它只是官方给出的一个示例，不是强制标准。页面自己也说：

“The correct threshold values depend on your domain and the performance of the model for your use case. Start with conservative thresholds, test with your own data, and adjust as you observe results.”

所以阈值必须根据业务风险自测，不能照抄。

我的判断：版本漂移监控与上线前清单

以下内容是我基于上述官方文档做出的判断，不是官方要求。写在这里是为了可操作。

版本漂移监控三件事

1. 每次调用记录 model 字段。响应中有一个 model 字段会返回实际回答的版本化 ID。把它和 request_id、时间、问题 hash 写入日志。这样即使以后 jev-latest 自动迁移，你也能定位到哪些调用落在 jev-1.13.0，哪些落在新版本。
2. 建立版本变更告警。可以写一个简单规则：如果某时间内 model 字段出现非预期值，或与上一版基线不同，触发告警。
3. 上线前用固定评测集回归。固定版本 ID 后，再用固定评测集跑一遍；只有当分数、置信度分布、路由准确率都稳定后再上线新版本。

下面给一个极简的日志字段示例。注意这不是官方 SDK 代码，而是我建议的工程做法：

import datetime

def build_version_log(request_id, response):
    # 这是本文建议的工程日志切片，不是官方 SDK 代码。
    # 依据官方 Models 页：response 的 model 字段报告实际版本 ID。
    return {
        "request_id": request_id,
        "model": response.get("model"),
        "timestamp": datetime.datetime.utcnow().isoformat(),
    }

这里的 response.get("model") 是通用伪代码。实际 SDK 的字段访问方式要以官方 SDK 文档为准，但日志思路是通用的。

合规问答清单

问题	官方页面能回答到什么程度	我的判断
能不能处理用户 PII？	Models 页只说输入为文本；Legal 页未直接写 PII 可/不可，只指向 DPA 和 Privacy Policy	不能只看 Models/Legal 概览就投产处理 PII；必须打开 DPA/Privacy Policy 或联系官方确认
输出能不能作为决策依据？	Confidence 页给置信度机制，但没说“可作为决策依据”或承担法律责任	输出是概率判断，建议只做辅助路由，高风险操作必须人工复核或二次确认
要不要留人工复核？	Confidence 页官方示例里低置信度路由到人工，但这是示例不是强制条款	高风险动作（如转账审批）应保留人工复核；低风险只读操作可自动放行

这套清单里，“官方页面能回答到什么程度”是我从页面原文能推出的内容；“我的判断”是我基于工程实践给出的保守建议。二者分开，避免把工程建议写成官方承诺。

上线前必读三页

• System One 概念页：理解 Jev 输出的是结构化概率判断，不是自由文本，避免按 LLM 用法设计系统。
• Confidence 页：理解置信度从概率分布计算、阈值应随风险分级，避免全系统用一个死阈值。
• Legal 页：确认数据保留、训练条款、合同条款入口，避免只关注技术而踩合规坑。

这次没核实的

以下内容我这次未能核实，必须明确写出来：

1. Legal 页只给出文档入口，没有展开 DPA、Master Customer Agreement、Privacy Policy 的具体条款。因此具体数据保留期限、PII 处理条件、训练数据范围等未能核实，需要调用方直接打开文档或联系 privacy@typesafe.ai。
2. 官方 Quick start 页面是否直接以响应示例形式出现 jev-1.13.0，本次未单独逐字核对。本稿使用的 jev-1.13.0 来自 Models 页当前模型表和别名表，不依赖 Quick start 示例。
3. 速率限制是动态调整的，页面写着可能无通知变化。因此任何容量规划数字都应以当天页面为准，不能当作固定 SLA。
4. 非英语语言支持，尤其是 CJK 文本，页面只说“handled but not equally well”，没有给出准确率或可量化的基准，需要自己在业务数据上回归测试。

参考来源

• 官方 Models 页
• 官方 Legal 页
• 官方 System One 概念页
• 官方 Confidence 文档