Probabilities output is messed up

快速结论：在 Ollama 0.40.1 的 SystemOne 接口（/v1/systemone）里，使用 "type": "choice" 时选项键顺序会改变提示词，从而改变模型给出的概率；当两个选项概率接近时，交换 criteria 的键顺序就可能翻转结果。优先把 true/false 这种二值判断题改为 "type": "noul"。

适用环境：已确认：Ollama 0.40.1；Windows；Intel CPU；Intel GPU；模型 nimble:latest（Q8_0），CPU 推理（评论中的复现环境）。请求体使用 questions.<name>.criteria 与 "type": "choice" / "type": "noul"。

最快修复方案：对 true/false 这类二值判定，改用 "type": "noul"，不再使用 "choice"。评论中给出的示例表明，noul 无论 criteria 键顺序如何，都会固定把 false 作为 A、true 作为 B，并返回一个数值（P(true)），在测试的八条消息上两种键顺序得到完全相同的数值。

注意事项：noul 只是消除顺序带来的不稳定，并不等于无偏；它在数值上接近 choice 中 false 排在前的表现。因此阈值不要默认套用 0.5，应基于自己标注的几十条消息来选取。如果必须使用 choice 且标签多于两个，评论建议把选项按多种顺序各发一次请求并平均概率，代价是每种顺序多一次请求。以上结论基于 nimble:latest（Q8_0）、CPU、每格单次请求的有限测试，换模型或换环境未必完全一致。

问题场景

用户在 Ollama 0.40.1 上调用 http://ip:11434/v1/systemone 接口，请求体中包含 questions.criteria，并通过某种 type（截图中对应 choice）让模型在 true / false 之间做判定。当把 criteria 里两个选项的顺序对调后，同一条输入得到的输出概率与最终判定不一致，出现 Probabilities output is messed up 这类现象。

报错原文

Probabilities output is messed up

Output results are inconsistent when criteria keys are swapped
version: 0.40.1
api: http://ip:11434/v1/systemone

原因分析

根据评论，这不是概率解析（parsing）的 bug，而是 "type": "choice" 构造提示词的方式导致的：choice 会把用户书写的 criteria 键按顺序映射成字母，第一个键变成 A，第二个变成 B，然后读取每个字母对应的概率。因此交换 true 和 false 会改变提示词本身，模型对位置的偏好（position effect）会把结果推动到另一个选项，在两个选项概率都较低、差距不大时（例如评论中约 0.095 与 0.011）尤其容易翻转胜负。

评论还指出，"type": "noul" 就是为这种 true/false 问题准备的类型，它固定把 false 呈现为 A、true 呈现为 B，与 criteria 键的顺序无关，返回单个数值即 P(true)。

环境排查

Ollama 版本：0.40.1（Issue 中确认）。
操作系统：Windows；CPU：Intel；GPU：Intel（Issue 中确认）。
模型：nimble:latest（Q8_0），评论中的复现使用 CPU 推理。
请求体关键字段：model、state、questions.<name>.type、instructions、criteria。
确认当前使用的是 "type": "choice" 还是 "type": "noul"；前者会受键顺序影响，后者不会。
确认两次请求之间是否只交换了 criteria 键的顺序，其余字段保持一致。

解决步骤

把二值判断题的 type 从 choice 改为 noul，只保留一个数值输出 P(true)。评论给出的示例形式为："need_tool": { "type": "noul", "instructions": "...", "criteria": { "true": "...", "false": "..." } }。
请求 http://localhost:11434/v1/systemone，观测返回的单个概率值，而不是两个字母 A/B 的概率。
分别按 true 在前和 false 在前的两种键顺序各发一次，确认 noul 下两次返回的数值一致。
如果业务上必须继续使用 choice，且标签多于两个，则把选项按若干种不同顺序分别发送请求，再对概率取平均，以降低位置效应（每种顺序多一次请求）。

验证方法

用自己标注的一小组消息（建议几十条）分别走 noul 与 choice：若 noul 在交换 criteria 键顺序后返回完全相同的数值，说明位置效应已被消除；再用这批标注数据选取合适的判定阈值，而不是默认使用 0.5。评论中的表格显示，noul 在八条测试消息上两种键顺序的数值完全一致，而 choice 在边界样本上会漂移 0.03 至 0.32，并曾让 1234×5678 这一条翻转判定。