quiz.json

{
  "lesson": "28-long-context-evaluation",
  "title": "长上下文评估 — NIAH、RULER、LongBench、MRCR",
  "questions": [
    {
      "stage": "pre",
      "question": "原始的 NIAH 基准衡量什么？",
      "options": [
        "tokenizer 繁殖率",
        "模型能否在长上下文中、在受控的不同深度检索到一个植入的事实",
        "嵌入余弦漂移",
        "仅多跳推理"
      ],
      "correct": 1,
      "explanation": "NIAH = 大海捞针：植入一个事实，让模型检索它，并扫描深度和长度。"
    },
    {
      "stage": "pre",
      "question": "为什么宣称的上下文窗口常常与可用上下文相差很大？",
      "options": [
        "注意力随长度和任务退化；规格表的最大值在多跳或推理负载下很少成立",
        "tokenizer 截断",
        "嵌入溢出",
        "beam search 变慢"
      ],
      "correct": 0,
      "explanation": "用于推理的有效上下文通常是宣称最大值的 25-50%。"
    },
    {
      "stage": "check",
      "question": "RULER 相比 NIAH 增加了什么？",
      "options": [
        "翻译任务",
        "更快的推理",
        "逐 token 的 logprob",
        "覆盖检索、多跳追踪、聚合和 QA 的 13 种任务类型，在多个上下文长度上进行"
      ],
      "correct": 3,
      "explanation": "RULER 把 NIAH 扩展为多任务长上下文基准，能抓住那些在 NIAH 上饱和却在别处失败的模型。"
    },
    {
      "stage": "check",
      "question": "什么是“迷失在中间”（lost in the middle）效应？",
      "options": [
        "模型对放在长输入中间的内容关注不足；depth=0.5 常常比 depth=0 或 1 表现更差",
        "模型重排 token",
        "模型遗忘第一个 token",
        "模型丢失标点"
      ],
      "correct": 0,
      "explanation": "上下文中部的内容最不受关注；扫描深度会暴露呈 U 形的准确率曲线。"
    },
    {
      "stage": "check",
      "question": "为什么仅用 NIAH 的评估必须辅以多跳测试？",
      "options": [
        "多跳更快",
        "NIAH 缺少真值",
        "NIAH 无法在长上下文上运行",
        "前沿模型可以在单针检索上得满分，却仍在多跳变量追踪或聚合任务上失败"
      ],
      "correct": 3,
      "explanation": "通过检索并不意味着通过推理；多跳基准能暴露真实的上限。"
    },
    {
      "stage": "post",
      "question": "NoLiMa 着重考验什么？",
      "options": [
        "流式输出",
        "延迟",
        "分词",
        "与查询不共享任何字面 token 的针，因此检索需要一个语义推理步骤"
      ],
      "correct": 3,
      "explanation": "NoLiMa 去除词面重叠，使模型必须推理而非匹配关键词。"
    },
    {
      "stage": "post",
      "question": "长上下文的规格表应该报告哪两个数字？",
      "options": [
        "有效检索长度（例如 90% NIAH 通过）和有效推理长度（例如 70% 多跳通过）",
        "仅 GPU 内存和延迟",
        "仅宣称的最大值",
        "仅每秒 token 数"
      ],
      "correct": 0,
      "explanation": "区分检索有效长度和推理有效长度，对真实世界的论断至关重要。"
    },
    {
      "stage": "post",
      "question": "为什么要测量长上下文长度下的首 token 时间（time-to-first-token）？",
      "options": [
        "100 万 token 的预填充（prefill）可能耗时数十秒；仅看准确率会掩盖影响产品的延迟",
        "分词很慢",
        "RAG 所要求",
        "beam search 依赖它"
      ],
      "correct": 0,
      "explanation": "长 prompt 的预填充成本巨大；延迟必须与准确率一并跟踪。"
    }
  ]
}