Sezika 的三种决策原语：选择、评分与真假判断

Sezika 的三种决策原语：选择、评分与真假判断

Sezika 用 Choice、Score 和 Boolean 表达三种常见的语义判断。选择哪一种原语，决定了问题如何描述、候选如何比较，以及应用应该怎样解释结果。建模时先把问题说清楚，往往比事后处理一个模糊答案更有价值。

Choice：明确候选，比较语义

Choice 面向有限候选选择。调用方为候选提供稳定标识和可理解的描述，模型返回这些候选的概率分布与选中项。

假设客服系统要对消息“发票金额不对，而且好像扣了两次”进行分派，可以定义“账单与支付”“账号访问”“软件故障”“其他”四个候选。候选标识用于程序处理，文字描述用于表达语义。两者承担不同职责：程序无需依赖展示文案进行分支判断，模型也不必猜测内部编号的含义。

候选应该处于相近的抽象层级。“账单问题”和“请求帮助”混在一起，容易出现覆盖关系；“软件故障”和“网络故障”是否互斥，则取决于具体业务定义。模型无法替调用方消除分类体系中的歧义。

加入“其他”也需要认真设计。一个“其他”候选只是类别的一部分，不等于应用已经获得可靠的未知输入检测能力。它需要有代表性的训练与评测样本，并与后续复核流程配合。

Score：评价有序程度

Score 面向有序等级，例如“影响轻微、影响中等、影响严重”。等级顺序定义了评分尺度，结果保留各等级的概率，并计算概率加权得分。

在 Sezika 的等级语义中，第一个等级对应数值 0，第二个对应 1，依此类推。若有 K 个等级，得分范围为 0 到 K−1。得分可以写成：

score = Σ(i × pᵢ)

这里的 pᵢ 是第 i 个等级的概率。这个公式说明了为什么得分可能是小数：它表达分布的期望值，而不是模型发明了一个新的等级。

例如，使用三级影响标准时，一个接近 1 的得分，可能来自“中等影响”占主导，也可能来自“轻微”和“严重”两端都有较大概率。这两种情况有不同的业务含义。因此，应用应保留分布，避免只保存一个小数。

Score 的尺度必须在使用前定义。把“满意、正常、紧急”放在同一组中，不构成清晰的有序评价；如果要判断紧急程度，应让所有等级都围绕紧急程度展开。

Boolean：把命题说完整

Boolean 面向真假判断，输出命题成立的概率。它最适合表达一个边界清楚的问题，例如“这条消息是否明确提到重复收费”。

“这条消息是否合理”则需要补充标准：合理指事实充分、符合格式，还是满足某个政策？如果判断依据没有进入输入，模型只能依赖自己的经验猜测。

真假判断还需要区分“文本中声称成立”和“现实中确实成立”。一条消息写着“我已经付过款”，模型可以判断它表达了付款声明；真实付款状态仍应查询交易系统。模型可以理解语言，事实核验需要可信的数据来源。

一个状态，多个清楚的问题

可以围绕同一条消息设置三类问题：用 Choice 进行业务分派，用 Score 评估影响程度，用 Boolean 识别是否提到重复收费。每个问题都应说明自己评价什么，避免把分类、程度与事实核验揉成一个判断。

在独立的 decision-v1 协议中，问题具有显式类型和标识。Choice 使用候选标识与文本，Score 使用有序等级，Boolean 可以分别说明命题及真假条件。结构化表达让调用方更容易检查请求，也让评测可以针对各题型进行。

多个问题并不意味着模型只计算一次。问题、候选与状态共同构成输入序列，实际计算和预算要按当前执行路径衡量。

用好分布，而不是只取第一名

候选之间的概率接近，说明当前输入下模型难以拉开差异；分布很集中，则说明模型更偏向某个候选。集中程度和答案是否正确仍是两回事。

业务系统可以据此设计观察指标和复核策略，但阈值应来自对应任务的验证集，而不是凭直觉指定一个“万能置信度”。当前独立模型输出仍属于未校准概率，正式使用前需要完成任务评测与校准。

三种原语提供了清楚的表达工具。最终效果还取决于候选体系、问题措辞、数据质量与模型适用范围。把这些定义清楚，模型输出才有稳定的业务含义。

相关接口和使用说明见 Sezika 项目文档。

---

关注我们，扫码进群沟通

欢迎关注我们，扫码加入微信或 QQ 交流群，一起交流技术实践，分享使用经验和问题反馈。

微信交流二维码

QQ 交流群：IoTSharp，群号 63631741

请扫码并关注我们，进群沟通。若二维码暂时无法使用，可通过 QQ 群号 63631741 搜索加入。