quiz.json

{
  "lesson": "29-dialogue-state-tracking",
  "title": "对话状态跟踪",
  "questions": [
    {
      "stage": "pre",
      "question": "对话状态跟踪在多个回合间维护什么？",
      "options": [
        "仅一段自由文本历史",
        "一个槽-值字典，表示用户当前的目标，并在每个回合后更新",
        "对话的一个嵌入",
        "一份带词性标注的转录稿"
      ],
      "correct": 1,
      "explanation": "DST 维护一个结构化的槽-值映射，供后端据此采取行动。"
    },
    {
      "stage": "pre",
      "question": "联合目标准确率（Joint Goal Accuracy, JGA）衡量什么？",
      "options": [
        "每个槽都完全正确的回合所占比例（全对或全错）",
        "平均槽准确率",
        "每回合延迟",
        "余弦相似度"
      ],
      "correct": 0,
      "explanation": "JGA 是每回合所有槽的严格匹配；按槽计的准确率更宽松。"
    },
    {
      "stage": "check",
      "question": "为什么每个回合从历史重新生成整个状态能自然地处理用户更正？",
      "options": [
        "它使用更少的 token",
        "它在 GPU 上运行",
        "它避免使用嵌入",
        "读取完整历史让模型能重新推导出最终状态，包括 'actually...' 这样的更正，而无需显式的回滚逻辑"
      ],
      "correct": 3,
      "explanation": "全历史重新生成通过从整段对话重新计算最终状态来吸收更正。"
    },
    {
      "stage": "check",
      "question": "哪个 2026 模式能用 5 行代码给出一个保证有效的槽字典？",
      "options": [
        "手写正则",
        "BM25 检索",
        "LLM + Instructor + Pydantic schema，配合受约束或经校验的输出",
        "TF-IDF 分类器"
      ],
      "correct": 2,
      "explanation": "Pydantic schema + Instructor 会自动对照槽本体校验 LLM 的状态输出。"
    },
    {
      "stage": "check",
      "question": "为什么要给你的 DST schema 做版本管理？",
      "options": [
        "事后添加新槽会使较旧的训练数据失效，并破坏纵向评估",
        "JSON 所要求",
        "减少 token 数",
        "提速收益"
      ],
      "correct": 0,
      "explanation": "未做版本管理的 schema 变更会悄悄破坏训练数据对齐和评估可比性。"
    },
    {
      "stage": "post",
      "question": "为什么对合规敏感领域的 DST 必须在 LLM 抽取之外包含一个基于规则的检查？",
      "options": [
        "规则避免使用嵌入",
        "仅靠 LLM 的 DST 可能错误抽取破坏性参数（金额、账户、日期）；规则层强制确定性约束",
        "LLM 更慢",
        "规则是多语言的"
      ],
      "correct": 1,
      "explanation": "合规领域需要确定性的强制执行；规则能捕捉 LLM 引入的槽错误。"
    },
    {
      "stage": "post",
      "question": "通过 LLM 在每个回合重新生成状态有什么成本顾虑？",
      "options": [
        "每回合重新读取完整历史会带来 O(n^2) 的总 token 用量；要给较旧回合设上限或做摘要",
        "更多嵌入",
        "余弦成本",
        "嵌入漂移"
      ],
      "correct": 0,
      "explanation": "全历史重新生成的 token 用量随回合数呈二次方增长；给历史设上限或使用滚动摘要。"
    },
    {
      "stage": "post",
      "question": "为什么在破坏性后端操作之前需要显式的确认流程？",
      "options": [
        "延迟",
        "确认能提升 JGA",
        "tokenizer 所要求",
        "即便是好的 DST 也有非零的槽错误率；确定性的确认可防止操作打到错误账户或错误金额"
      ],
      "correct": 3,
      "explanation": "破坏性操作需要用户确认，因为 DST 永远不可能零错误。"
    }
  ]
}