Jev 置信度与兜底策略实战

Jev 的每个响应都带 confidence 分数——这一个字段，把模型从”尝鲜”变成”生产组件”。分数告诉你模型哪里有把握、哪里在猜，你就可以自动化有把握的、分流剩下的。这篇讲阈值怎么定、三条兜底路径怎么设计、整个回路怎么监控才不会悄悄烂掉。

TL;DR： 阈值从 0.8 起步：以上自动化，以下分流。低置信度条目三选一——换更锋利的问法重试、升级人工、或给通用 LLM 做一次完整判断。持续盯 confidence 分布：整体往低漂移，是输入或问题措辞变化最早的警报。

confidence 在响应里是什么

每种题型的 Jev 答案都带同一形态。打分题示例——示例数据（example fixture），正式字段名以官方文档为准：

{
  "answer": 8,
  "scale": [1, 10],
  "confidence": 0.86,
  "rationale": "The answer addresses the core question but omits the setup step."
}

把它当路由信号读，不要当真理。有用的心智模型：confidence 把条目按”能否安全自动化”排序。分布的顶部给自动化，底部给人审，具体的切线由你的错误代价决定。

阈值怎么定：0.8 起步，用数据调

这些数字是起点，不是法律。真正要紧的调参回路：

1. 先跑一周，把每个答案连同 confidence 记日志，暂不对低置信度做动作。
2. 人工标注低置信度样本的一部分。
3. 算出错误实际从哪里开始——安全切线经常比 0.8 高或低。
4. 把阈值定在那里，每季度回看。

三条兜底路径

confidence 低于阈值时，应该发生且只发生以下三件事之一：

import json, os, requests

def judge_with_fallback(prompt: str, threshold: float = 0.8) -> dict:
    # Confirm the exact model slug on the OpenRouter model page
    resp = requests.post(
        "https://openrouter.ai/api/v1/chat/completions",
        headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
        json={
            "model": "typesafe/jev-1.13",
            "messages": [{"role": "user", "content": prompt}],
        },
        timeout=30,
    )
    result = json.loads(resp.json()["choices"][0]["message"]["content"])

    if result["confidence"] >= threshold:
        return result  # 自动化
    if result["answer"] == "unclear" or result["confidence"] < threshold / 2:
        return {"route": "human"}  # 深度不确定：绝不重试循环
    return {"route": "llm_review", "jev": result}  # 中间段：完整 LLM 判断

封装函数在置信时返回 fixture 形态的答案，否则返回路由决策；这里展示的形态都是示例数据（example fixture），正式字段名以官方文档为准。三条路按顺序：

• 换更锋利的问法重试——给中间段。经常是问题的问题，不是模型的问题：按《问题设计》那篇把边界写明再问一次。只重试一次，绝不循环。
• 升级人工——给深度不确定段，以及一切涉及钱或法律后果的条目。unclear 答案就是为这个存在的。
• 通用 LLM 完整判断——给”人不必看但一次调用能解决”的中间段。聊天模型写完整的论证；Jev 的低置信度答案作为上下文一并带过去。

监控回路

三个指标能在用户之前抓住大多数故障：

发票审批闸口的 case 是保守阈值的典型样本——几乎全审、几乎不自动化；工单分流场景则是高流量下相反的平衡。当”报错”其实是响应形态读错了而不是置信度低，《Jev 常见报错排查》有对应的修复。

本文适用版本 Jev 1.13。