TryJev
← 返回博客
问题设计最佳实践选择评分是非模式

如何为 Jev 设计有效的问题（选项、粒度、阈值）

·约 4 分钟

如何为 Jev 设计有效的问题

决策模型的质量，很大程度就是问题的质量。本指南讲 Jev 的问题设计：措辞、类型、粒度，以及把概率变成产品行为的阈值逻辑。

一句话总结：一个问题只做一个决策。3–5 个互斥选项。尽量别加「其他」。把问题写成你将来要编译的那个 if。

从分支出发，而不是从数据出发

不好的写法：

「分析这条消息，描述客户的情绪状态。」

好的写法：

「这条工单该由哪个团队处理？」

后一句能直接映射到代码：

if (selected === 'billing') return enqueueBilling();

说不出对应分支，问题就还没设计好。

三种类型，三种用途

类型 何时用 返回
选择 从 N 个队列 / 意图里选一个 选中项 + 各选项概率
评分 放到量表上（紧急度、匹配度） 加权位置 + 各等级概率
是非 带置信度的 yes/no 概率 0–1

选择

{
  "type": "choice",
  "text": "这条消息真正的意图是什么？",
  "options": ["真诚提问", "阴阳怪气", "随口聊聊"]
}

评分

{
  "type": "score",
  "text": "多久之内回复比较合适？",
  "options": ["今天", "三天内", "不着急"]
}

是非

{
  "type": "noul",
  "text": "这条消息是否包含退款诉求？"
}

有效的选项措辞

要做

  • 用标注员已经会说的日常标签（「阴阳怪气」「账务」）。
  • 选项在语法和长度上平行。
  • 互斥（不要既有「愤怒」又有「烦躁」，除非这就是你的标签体系）。

不要

  • 生造术语（「负面情感信号」）。
  • 混抽象层级（「账务」「技术」「存在主义焦虑」）。
  • 一个选项塞两个决策（「billing_or_sales」）。

为什么「其他」通常不是好默认

  1. 它会吸走所有不确定。
  2. 你看不清哪个真实标签失败了。
  3. 模型学会用它来摊手。

更好模式： 允许分布摊平，然后上阈值：

if (confidence < 0.55) return humanReview();

粒度经验法则

类型 甜区 备注
选择 3–5 选项 7+ 概率会摊薄
评分 3–4 等级 「低 / 中 / 高」好过 1–10
是非 二分 需要三结果就改选择

有 15 个客服队列？先聚成 4–6 个宏队列，再一次调用分子队列。

分开不同的决策

意图和紧急度是两个判断。一次 API 调用问两个问题，不要硬融合：

"questions": [
  { "type": "choice", "text": "……意图……", "options": ["…"] },
  { "type": "score", "text": "……紧急度……", "options": ["…"] }
]

融合会迫使模型取平均，两边都会变糊。

状态文本是问题的一半

再好的问题，配太薄的状态也不行。做分类时：

  • 保留语气、标点、语气词。
  • 相关时带上说话人 / 渠道。
  • 不要摘要掉证据。

阈值即产品策略

把 confidence 当策略输入，而不只是模型分数：

置信度 策略示例
≥ 0.85 全自动
0.55–0.85 建议 + 确认
< 0.55 人工队列

在 50–100 条标注样本上调。词汇漂移（新功能、新市场）后重调。

反模式

  1. 大杂烩问题——「分类、摘要，并建议回复。」
  2. 没有分支的分类学——代码用不到的标签。
  3. 11 分量表——没人能给出依据。
  4. 伪装成「综合」的隐藏「其他」。
  5. 在决策模型上要小作文。

上线前清单

  • 每个问题对应真实的 switch / if
  • 选项互斥、像人话
  • 选择 3–5 项（评分 3–4 级）
  • 不同决策拆开问
  • 阈值 + 人工兜底已定义
  • 日志含 distribution 与延迟

FAQ

选项要用英文吗？
跟标签与界面语言一致。state 保持用户语言。

怎么测问题质量？
写 20 条对抗样本；好问题不需要额外规则就能分开它们。

能用少样本示例吗？
代表性文本走 state 模式；示例放在文档里，别塞进每次 prompt。

相关阅读