Choice类型返回每个预定义选项的label及对应probability（总和为1.0），并附带整体confidence值，结构为含label和probability字段的choices数组。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Choice 类型返回的是什么结构
Choice 类型用于从你预定义的有限选项中做选择，Jev 不生成文字，而是直接返回每个选项对应的概率分布和整体置信度。响应体里一定包含 choices 数组，每个元素带 label 和 probability 字段，还附带一个 confidence 值（0–1 之间），表示模型对本次选择判断的确定性。
常见错误是把 label 当成字符串匹配结果——它只是你提交时定义的标识符，不是模型“生成”的内容；也不支持模糊匹配或子串匹配，必须完全一致。
- 提交时
choices字段必须是非空数组，且每个label是唯一、不可重复的字符串 - 返回的
probability总和恒为 1.0（浮点精度内），不需归一化 - 若所有
probability都接近 0.33（三选一时），说明状态信息不足以支撑区分，不是模型故障，而是输入信号弱
Score 类型输出是否支持自定义等级序列
支持，但必须在请求中显式声明 scale 字段，且只能是有序字符串数组，比如 ["low", "medium", "high"] 或 ["critical", "high", "normal", "low"]。Jev 不会推断语义顺序，只按数组索引位置理解等级高低。
容易踩的坑是混用数字和字符串混合标度，例如 [0, "medium", 2] ——这会导致 400 错误，scale 必须类型统一。
-
scale至少含 2 个元素，最多 10 个 - 响应中返回
score字段是字符串（对应你定义的某个scale元素），同时附带probabilities数组，长度与scale一致 - 没有 “中间值插值”，比如三档标度不会返回 “between medium and high” 这类描述
Noul 类型为什么只返回单个数值
Noul 是布尔型判断的专用类型，输入是一个命题（如 "user_input_contains_sql"），输出就是该命题为真的概率，一个 0 到 1 之间的 float，字段名固定为 truth_probability。它不返回理由、不返回置信度分拆，也没有备选解释路径。
这个设计就是为了消除解析成本：你的代码可以直接 if response.truth_probability > 0.95: block()，不用再 JSON 解析、字段校验、类型转换。
- 命题文本本身不参与计算逻辑，只作为语义锚点；真正影响判断的是你传入的
state - 如果返回值是
0.51，不代表“略微倾向成立”，而代表模型在当前状态下的最优估计——它没有“犹豫”概念，只有概率输出 - 不要试图用 Noul 替代 Choice，比如把
["allow", "deny"]拆成两个 Noul 请求，那样既慢又贵，违背并行设计初衷
多个问题能否共用一次请求的 state 并独立返回
可以，而且这是 Jev 的核心能力之一。你在单次请求中提交一个 state（任意长度文本或扁平 JSON），再附上多个 questions 对象，每个指定 type（choice / score / noul）和对应参数。响应中每个问题的结果独立存在，互不影响。
典型误用是把不同语义粒度的问题塞进同一个请求却没隔离 context，比如用同一段日志同时判断“是否含 SQL 注入”（Noul）和“归属服务模块”（Choice），结果可能因特征混淆导致低置信度——这不是 bug，是语义干扰。
- 所有问题共享同一个
state输入，但模型内部为每个问题构建独立注意力上下文 - 响应中每个问题结果带
id字段（如果你提交时设了），方便映射回原始请求 - 不支持嵌套问题或条件依赖，比如“先执行 question A，再根据其结果决定 question B 的参数”——这种逻辑必须由调用方在 HTTP 层控制
Jev 的响应格式极简，但边界清晰。最常被忽略的一点是：它不提供 fallback 字段、不返回 raw logits、不暴露温度或 top-k 参数——所有这些都被封装进决策过程，对外只暴露「可执行结果」。写客户端时，别试图兼容传统 LLM 的 error handling 模式，它的失败只有一种：HTTP 状态码非 200 或 schema 校验失败。
