examination/topics/interview-prep/ai-engineering/single_choice.json

{
  "topic": "ai-engineering",
  "type": "single_choice",
  "schema_version": "1.0.0",
  "generated": "2026-09-09T10:00:00+08:00",
  "questions": [
    {
      "id": "sc-001",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "context-engineering"
      ],
      "question": "在 RAG（Retrieval-Augmented Generation）系统中，以下哪种检索策略最能有效提升最终生成答案的相关性？",
      "options": {
        "A": "始终返回 Top-1 相关性最高的文档片段",
        "B": "使用语义向量检索 + 重排序（Re-ranking）的两阶段检索",
        "C": "将所有检索到的文档一次性拼接后发送给 LLM",
        "D": "仅依赖关键词 BM25 检索，不做向量化处理"
      },
      "answer": "B",
      "explanation": "两阶段检索（先粗召回、再精排）是当前 RAG 系统的最佳实践。第一阶段用向量检索从大量文档中快速召回候选集，第二阶段用 Cross-Encoder 等重排序模型对候选集精排，能显著提升检索到的文档与查询的相关性。A 选项只返回一个片段，信息量不足且容错性差；C 选项将所有文档拼接会导致上下文窗口浪费和信息噪声；D 选项仅依赖关键词检索无法处理语义相近但词汇不同的查询，召回率不足。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-002",
      "type": "single_choice",
      "difficulty": 2,
      "tags": [
        "context-engineering"
      ],
      "question": "当 LLM 的上下文窗口有限时，以下哪种策略最适合处理一篇超过窗口大小的长文档摘要任务？",
      "options": {
        "A": "将文档截断至上下文窗口大小，直接丢弃超出部分",
        "B": "采用 Map-Reduce 策略：先分段摘要，再对摘要进行二次综合",
        "C": "多次重复发送同一文档以「加深」模型记忆",
        "D": "将文档拆分后并行发送给多个独立 LLM 实例，取第一个返回的结果"
      },
      "answer": "B",
      "explanation": "Map-Reduce 是长文档处理的经典模式：Map 阶段将文档切分为多个 chunk 并行生成局部摘要，Reduce 阶段将所有局部摘要合并生成最终摘要。这种方法既保证了信息覆盖的完整性，又避免了上下文溢出。A 选项会丢失大量关键信息；C 选项重复发送并不能增加有效信息量，反而浪费 token；D 选项只取第一个结果忽略了其他分段的信息，且无综合步骤。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-003",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "harness-engineering",
        "ai-agent"
      ],
      "question": "在 Agent 编排框架中，ReAct 模式与 Plan-and-Execute 模式的核心区别是什么？",
      "options": {
        "A": "ReAct 模式不支持工具调用，仅用于对话场景",
        "B": "ReAct 采用逐步推理-行动的循环，Plan-and-Execute 先制定完整计划再逐步执行",
        "C": "Plan-and-Execute 模式不支持在执行过程中动态调整计划",
        "D": "ReAct 模式只能处理单步任务，无法处理多步骤复杂任务"
      },
      "answer": "B",
      "explanation": "ReAct（Reasoning + Acting）的核心是 Thought → Action → Observation 的逐步循环，每一步根据当前观察决定下一步行动，适合需要动态调整的探索型任务。Plan-and-Execute 则先让 LLM 生成一个完整的多步计划，再由执行器逐步实施，适合目标明确、步骤可预知的任务。A 错误：ReAct 广泛用于工具调用场景。C 错误：大多数 Plan-and-Execute 实现支持在执行中根据反馈修改计划。D 错误：ReAct 的循环结构天然支持多步任务。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-004",
      "type": "single_choice",
      "difficulty": 4,
      "tags": [
        "ai-agent"
      ],
      "question": "在多 Agent 系统中，「共享黑板（Blackboard）」通信模式的核心特征是？",
      "options": {
        "A": "所有 Agent 通过点对点消息直接通信，无需中间媒介",
        "B": "设置一个中心调度器，由它决定哪个 Agent 在何时执行任务",
        "C": "Agent 通过读写共享的全局状态空间进行间接通信，无需直接对接",
        "D": "所有 Agent 共享同一个 LLM 实例，通过内存隔离实现并行"
      },
      "answer": "C",
      "explanation": "黑板（Blackboard）模式源自人工智能经典架构，核心思想是维护一个共享的全局数据结构（黑板），各 Agent 独立地读取黑板上的信息、执行推理并将结果写回黑板，从而实现间接的松耦合通信。A 描述的是点对点（Peer-to-Peer）通信模式；B 描述的是中心调度（Central Orchestrator）模式；D 描述的是模型共享架构，与通信模式无关。黑板模式的优势在于 Agent 之间不需要了解彼此的存在，便于扩展和替换。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-005",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "mcp",
        "tool-calling"
      ],
      "question": "在 MCP（Model Context Protocol）协议中，以下关于 Tool、Resource、Prompt 三个核心要素的描述，正确的是？",
      "options": {
        "A": "Tool 是 LLM 可调用的外部函数，Resource 是服务端提供的数据源，Prompt 是预定义的提示词模板",
        "B": "Tool 和 Resource 的区别仅在于命名不同，功能完全相同",
        "C": "Prompt 是 LLM 生成的输出格式约束，Tool 是客户端向服务端发送的请求",
        "D": "Resource 只能返回文本数据，不支持图片或结构化数据"
      },
      "answer": "A",
      "explanation": "MCP 协议定义了三个核心原语：Tool 代表 LLM 可以调用的外部函数（如 API 调用、代码执行），由客户端发起调用；Resource 是服务端暴露的数据源（如文件、数据库记录），通常由客户端按 URI 读取；Prompt 是服务端提供的预定义提示词模板，供客户端在构造请求时使用。B 错误：Tool 涉及执行操作，Resource 涉及数据读取，语义和实现不同。C 错误：Prompt 不是输出约束，而是输入模板。D 错误：Resource 支持多种内容类型，包括图片和结构化数据。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-006",
      "type": "single_choice",
      "difficulty": 4,
      "tags": [
        "permission"
      ],
      "question": "在设计 LLM Agent 的权限治理体系时，「最小权限原则（Principle of Least Privilege）」的最佳实践是？",
      "options": {
        "A": "为 Agent 配置管理员权限，确保它在任何场景下都能顺利完成任务",
        "B": "每次工具调用时动态申请权限，根据当前任务上下文授予刚好够用的最小权限集",
        "C": "所有工具调用一律禁止，需要人工逐条审批后才能执行",
        "D": "将权限配置写死在代码中，运行时不允许任何变更"
      },
      "answer": "B",
      "explanation": "最小权限原则要求 Agent 仅获得完成当前任务所必需的最小权限。动态权限申请是最佳实践——Agent 在执行每个工具调用前声明其意图和所需权限，系统根据任务上下文和安全策略决定是否授权。这既保证了安全性（避免过度授权），又保证了灵活性（不同任务授予不同权限）。A 违反最小权限原则，过度授权带来安全风险；C 过于严格会阻塞正常工作流，适用于高风险操作而非所有操作；D 的静态权限无法适应不同任务的差异化需求。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-007",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "pluggable-config"
      ],
      "question": "在可插拔配置架构中，Provider 抽象层的核心价值是什么？",
      "options": {
        "A": "让系统只能使用特定厂商的 LLM，确保输出质量一致",
        "B": "统一不同 LLM 供应商的接口差异，使上层应用无需感知底层模型切换",
        "C": "自动生成 Prompt 模板，不需要人工编写任何提示词",
        "D": "为每个 LLM 供应商创建独立的应用程序，互不干扰"
      },
      "answer": "B",
      "explanation": "Provider 抽象层（如 LiteLLM、OpenAI 兼容接口）的核心价值在于屏蔽不同 LLM 供应商的 API 差异（请求格式、认证方式、响应结构等），为上层应用提供统一的调用接口。当需要切换底层模型时（如从 GPT-4 切换到 Claude），只需修改配置而不必改动业务代码。A 与可插拔理念相悖；C 属于 Prompt Engineering 工具的功能，与 Provider 抽象层无关；D 违背了抽象层「统一接口」的初衷。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-008",
      "type": "single_choice",
      "difficulty": 2,
      "tags": [
        "guardrail"
      ],
      "question": "以下关于 LLM Guardrail 中 PII（个人可识别信息）检测的描述，正确的是？",
      "options": {
        "A": "PII 检测只需要在输入端执行，输出端无需处理，因为 LLM 不会凭空生成个人信息",
        "B": "PII 检测应同时覆盖输入和输出，且需要支持正则匹配与上下文感知的 NER 模型结合",
        "C": "PII 检测会显著降低系统性能，因此在生产环境中应该完全跳过",
        "D": "PII 检测只适用于金融行业，其他行业不需要"
      },
      "answer": "B",
      "explanation": "PII 检测需要在输入和输出两个方向上都进行。输入端防止敏感信息泄露给 LLM，输出端防止 LLM 在生成内容中包含用户提供的或训练数据中的敏感信息。技术实现上，正则匹配适合检测格式固定的 PII（如手机号、身份证号），NER 模型适合检测上下文相关的 PII（如人名、地址），两者结合效果最佳。A 错误：LLM 可能通过 RAG 或记忆机制在输出中泄露输入中的 PII；C 错误：PII 检测是合规要求，性能问题可以通过异步检测、缓存等手段优化；D 错误：所有处理用户数据的行业都应考虑 PII 检测。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-009",
      "type": "single_choice",
      "difficulty": 4,
      "tags": [
        "llm-ops"
      ],
      "question": "在 LLM 应用的可靠性保障中，使用 JSON Mode / Structured Output 的主要目的是什么？",
      "options": {
        "A": "提升 LLM 的推理速度，减少响应延迟",
        "B": "确保 LLM 输出符合预定义的结构化格式，降低下游解析失败的风险",
        "C": "限制 LLM 只能回答特定领域的问题",
        "D": "减少 LLM 的幻觉问题，提升事实准确性"
      },
      "answer": "B",
      "explanation": "JSON Mode / Structured Output（如 OpenAI 的 response_format、Function Calling 的参数约束）的核心目的是确保 LLM 的输出符合预定义的 schema 结构，从而让下游系统可以可靠地解析和处理输出。这解决了 LLM 输出格式不稳定导致的集成问题。A 错误：结构化输出约束甚至可能略微增加延迟（需要额外的格式校验）；C 错误：结构化输出约束的是格式而非内容领域；D 错误：结构化输出不直接解决幻觉问题——模型仍可能在有效 JSON 中生成虚假内容，解决幻觉需要 RAG、事实校验等其他手段。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-010",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "llm-ops"
      ],
      "question": "当 LLM 服务出现临时性故障（如 rate limit 或 503 错误）时，以下哪种重试策略最为合理？",
      "options": {
        "A": "立即无限次重试，直到成功为止",
        "B": "采用指数退避（Exponential Backoff）+ 抖动（Jitter）策略，并设置最大重试次数",
        "C": "不进行任何重试，直接将错误返回给用户",
        "D": "每次固定间隔 1 秒重试，重试 100 次"
      },
      "answer": "B",
      "explanation": "指数退避 + 抖动是处理临时性故障的标准策略。指数退避（每次重试间隔翻倍，如 1s → 2s → 4s → 8s）避免了在服务恢复前持续施压；抖动（在退避间隔上加入随机偏移）防止多个客户端同时重试造成「惊群效应（Thundering Herd）」。设置最大重试次数可避免无限循环。A 会加剧服务端压力并可能触发更严厉的限流；C 无法应对可恢复的临时故障，用户体验差；D 的固定间隔策略在大规模部署时容易引发同步重试风暴。",
      "source": null,
      "related": []
    }
  ]
}