Jev上线后的可观测性：日志、版本、阈值回测

拾光机 技术创作者 2026-09-22 62 阅读

先说结论

  1. 官方返回体里最值得落盘的是：model（实际版本）、token 用量（输入/输出）、Choice/Score 的 confidence 与 probabilities、以及判定值本身（choice/score/noul）。
  2. 版本漂移监控是本文给的做法，不是官方功能：按天统计 model 字段分布，出现新值立即告警，并用固定评测集做回归。
  3. 阈值回测需要历史标注集：把当前阈值回放到历史请求上，算自动放行比例与错放率。官方只给了 confidence 的定义和“阈值随风险缩放”的思路，并未提供回测工具。
  4. 低置信度占比、人工复核命中率、单次判定成本都是运营侧指标，不属于官方指标。
  5. 日志建议存摘要而非原文；官方 Legal 页说明 TypeSafe 处理数据的方式、不拿用户数据训练模型，并可提供 ZDR，但具体合规方案不是本文能定的。

证据与过程

官方返回字段：能核实的部分

官方 Confidence 页对 probabilities 和 confidence 的定义很清楚。英文原文是：

“All Score and Choice answers from TypeSafe include a probabilities property representing the probability distribution across the options (for Choice) or levels (for Score).”

也就是说，Choice 的分布横跨你的选项，Score 的分布横跨你的等级。官方又写：

“The answer’s confidence property collapses that shape into a single number from 0 to 1, so you can threshold on it without doing the math yourself. (Noul answers don’t carry one.)”

这里可得到两个明确事实：confidence 是 0 到 1 的单值；Noul 答案没有这个字段。confidence 的来源官方也写清楚了：

“Confidence is derived from the probabilities — confidence is a statistic computed from the probability distribution the answer already gives you.”

所以日志里同时记 confidence 和 probabilities 是有官方依据的：前者用来做阈值门控，后者留作事后分析。我的判断是，probabilities 应该完整存下来，因为 confidence 是压缩后的统计量，一旦后面想换阈值计算方式，原始分布还在，不用重新调用模型。

官方 Models 页提供了另一个关键字段 model 的定义：

“The response’s model field reports the versioned ID that answered, so you can log which model produced each result.”

这句直接支持“记 model 字段用于版本追踪”。官方还提醒别名会漂移：

“An alias moves when a new release ships, so the answers behind it can change without a change on your side.”

因此我的建议是：调用时如果能接受成本，尽量 pin 到具体版本 ID；如果使用 jev-latest，就必须记录 model，否则出了变化你根本不知道是哪一版造成的。

至于判定结果本身，官方 Quick start 的 Python 示例给出了可读字段：

print(response.answers["department"].choice) # "technical"
print(response.answers["frustration"].score) # 1.0
print(response.answers["is_urgent"].noul) # 1.0

这是官方示例的片段，说明 Choice 的结果在 .choice，Score 在 .score，Noul 在 .noul。日志记录判定结果时，应同时记问题名、结果值、confidence 和 probabilities。

usage 中 token 用量的精确字段名，我未在本次核对的 Quick start、Models、Confidence 三个页面里直接看到完整 JSON 示例。官方 Models 页只有成本语义：

“Price: Charged per input token. Output tokens are free.”

这句话告诉我们：成本按输入 token 算，输出 token 免费。因此日志至少需要把输入 token 量记下来；输出 token 虽然不收费，但也可以记录用于分析平均输出长度。字段名 usage.input_tokens 与 usage.output_tokens 是常见的 API 响应结构，但我不把它的精确路径写成官方原样，建议你在接入时抓一次真实响应确认。

版本漂移监控：本文做法

官方文档确认 model 字段反映实际处理请求的版本 ID。基于这一点，一个轻量的监控方案是：

  1. 在服务层把每次调用的 model 存进日志，同时保留请求时间。
  2. 每天离线跑一个聚合，统计 model 的不同取值和调用量。
  3. 如果出现之前没见过的版本 ID，发出告警。
  4. 告警后，用一套固定评测集（比如 200 条带人工标签的请求）分别打新旧两个版本，比较判定值、confidence 分布和错误率。

为什么不用“结果错误率”做第一道告警？因为结果标签往往滞后，模型上线后第一分钟就能从 model 字段看到变化。这是一个监控策略选择，不是官方要求。

固定评测集的设计建议：包含正常边界案例、低置信度案例、高风险案例（如转账审批），避免全是简单样本。回归时重点看三点：原来高置信度现在低置信度的比例、原来正确现在错误的比例、以及 probabilities 分布是否整体变平。

阈值回测：用官方 confidence 定义做历史回放

官方 Confidence 页对 confidence 的定义是：

“confidence is a statistic computed from the probability distribution the answer already gives you.”

且官方给出了阈值随风险缩放的原则：

“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.5 和 0.9 两个不同阈值：不确定时路由给人工；check_balance 低于某阈值也可能放行，但 approve_transfer 需要更高置信度。这是官方示例，但注意官方没有说“你应该用 0.5 和 0.9”。原文还写着：

“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.”

所以阈值的具体数字是运营决策。回测做法是：

  • 先积累一段历史请求，并让人工对部分请求做结论标注：系统判定是否正确、是否应自动放行。
  • 按天重放：用当前候选阈值，对标注集重新跑一遍门控逻辑（不需要重新调用模型，只需用已存储的 confidence 和判定值）。
  • 计算两个数字：自动放行比例（被自动处理的请求占比）和错放率（自动放行但人工结论为错误的占比）。
  • 如果新阈值导致错放率上升超过预设上限，就回退或收紧。

下面是一个回测脚本的伪代码，所有数值都是本文为演示设的，不是官方数据：

# 本文做法：基于已落盘日志做阈值回放，不重复调用模型
logs = load_logs("daily_snapshot.parquet")  # 包含 model、confidence、prediction
labels = load_labels("human_review.jsonl")   # 人工结论：is_correct
candidate_threshold = 0.8

joined = logs.merge(labels, on="request_id")
auto = joined[joined["confidence"] >= candidate_threshold]
auto_pass_rate = len(auto) / len(joined)
wrong_auto = auto[auto["is_correct"] == False]
error_rate_on_auto = len(wrong_auto) / len(auto)

print(auto_pass_rate, error_rate_on_auto)

这只是一个最小示例，实际生产里还要按日期切分、按问题维度拆开看。

质量指标建议：运营指标不是官方指标

以下三个指标可以日常跟踪，但官方文档没有给出这些名字和公式：

  • 低置信度占比：当天所有 Choice/Score 调用中，confidence 低于人工设定阈值（如 0.5）的比例。它反映模型“不确定”的频率，但不直接等于错误率。
  • 人工复核命中率：进入人工复核队列的请求中，最终被判定为模型错误的占比。如果复核命中率太低，说明阈值可能过严，把太多本该自动处理的请求送进了人工。
  • 单次判定成本：当日成本 / 当日有效判定次数。官方票价是输入 token 按量计费，输出免费（官方数据：Jev 1.13.0 价格为 $42/Btok，$0.042/Mtok）。但这只是模型 token 成本，不含人工复核的人力成本。

我建议把这些指标放在同一个看板上，和版本漂移告警并列。它们的定义和阈值完全由你的业务决定，别再纠结“官方推荐值”。

隐私与合规

日志里如果记录完整输入，可能把用户原文、企业机密等长期留在你的存储里。一个简单做法是：只存 request_id、model、confidence、probabilities、判定值、token 用量，以及状态文本的摘要哈希或关键词摘要。需要回溯具体文本时，再从你控制的后端按 request_id 调取脱敏版本。

官方 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.”

以及：

“We also offer zero data retention (ZDR) for enterprise customers.”

这意味着你自己的日志策略是你自己的合规责任。官方不拿用户请求训练模型，不等于你可以无限制存原文。具体保留期限、脱敏方式、跨境传输等，需要由法务或合规人员根据你的行业和地区判断。

自己的判断/清单

  1. 接入后先抓一次真实响应，确认 usage 的 JSON 路径，再写日志 schema。
  2. 日志必须包含：model、confidence、probabilities、判定结果、token 用量、时间戳、请求来源。probabilities 尽量原样存。
  3. 版本漂移告警和固定评测集回归是上线后第一周的必做项，不要等用户投诉才发现模型变了。
  4. 阈值回测应每天跑，优先关注错放率，而不是自动放行比例本身。
  5. 低置信度占比可以当作健康度参考，但别把它当成性能指标向上汇报；它必须和人工复核命中率、成本一起看。
  6. 日志默认不存原文，除非你有明确的合规理由和访问控制。

这次没核实的

  • usage.input_tokens 与 usage.output_tokens 的精确 JSON 层级未在本次已核对的四个页面中直接看到；需要到官方 API Reference 或实际响应中确认。
  • 官方没有提供现成的可观测性 dashboard、监控 SDK 或阈值回测工具。本文中的监控方案均为工程建议，不是官方功能。
  • 官方 Legal 页没有给出具体的日志留存期限、脱敏标准或合规方案，这些属于你的组织责任，需要咨询专业人士。

参考来源

# 教程# 知识

评论区

0 条评论

登录后可评论。

拾光机 62 阅读