wonder
0f68a64829
Deploy Examination / deploy (push) Successful in 10s
Subtopics: - distributed-microservice: 45 questions (分布式微服务架构) - message-queue: 45 questions (消息队列) - k8s-observability: 45 questions (K8s与可观测性) - go-java-concurrency: 45 questions (Go/Java并发模型) - database-advanced: 35 questions (数据库进阶) - ai-engineering: 35 questions (AI工程实践) Question types: single_choice, true_false, fill_blank, short_answer, code_reading
78 lines
5.5 KiB
JSON
78 lines
5.5 KiB
JSON
{
|
||
"topic": "ai-engineering",
|
||
"type": "true_false",
|
||
"schema_version": "1.0.0",
|
||
"generated": "2026-09-09T10:00:00+08:00",
|
||
"questions": [
|
||
{
|
||
"id": "tf-001",
|
||
"type": "true_false",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"context-engineering",
|
||
"ai-agent"
|
||
],
|
||
"question": "在 RAG（检索增强生成）架构中，向量数据库的语义检索结果可以完全替代 LLM 的参数化知识，因此 RAG 系统不需要依赖 LLM 自身的预训练知识。",
|
||
"answer": false,
|
||
"explanation": "这个说法是错误的。RAG 的核心设计理念是「检索 + 生成」协同工作，而非替代关系。向量数据库提供的语义检索结果作为上下文（context）注入 prompt，但 LLM 仍然需要利用自身的参数化知识来理解检索结果、进行推理、整合信息并生成最终回答。检索结果通常只是片段化的、可能包含噪声的参考资料，LLM 的预训练知识起到语义理解、逻辑推理和知识补全的关键作用。两者是互补关系，缺一不可。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-002",
|
||
"type": "true_false",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"harness-engineering",
|
||
"ai-agent"
|
||
],
|
||
"question": "ReAct 模式与 Plan-and-Execute 模式的核心区别在于：ReAct 采用「思考→行动→观察」的即时循环，而 Plan-and-Execute 先生成完整计划再逐步执行，因此 Plan-and-Execute 更适合需要多步回溯和动态调整的复杂任务。",
|
||
"answer": false,
|
||
"explanation": "这个说法是错误的。虽然前半部分对两种模式的描述是正确的——ReAct 是 Thought→Action→Observation 的交替循环，Plan-and-Execute 是先规划再执行——但结论恰好相反。ReAct 的逐步交替模式天然支持每一步根据观察结果动态调整策略，更适合需要频繁回溯和动态调整的任务。Plan-and-Execute 的计划一旦生成，调整成本较高（需要重新规划），更适合目标明确、步骤可预判的任务。在实际工程中，Plan-and-Execute 通常需要加入 re-planning 机制来弥补这一不足。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-003",
|
||
"type": "true_false",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"mcp",
|
||
"tool-calling"
|
||
],
|
||
"question": "MCP（Model Context Protocol）协议定义的三大核心要素是 Tool、Resource 和 Prompt，其中 Tool 允许服务端暴露可执行函数供 LLM 调用，Resource 提供只读的数据访问接口，Prompt 则定义了预构建的交互模板。",
|
||
"answer": true,
|
||
"explanation": "这个说法是正确的。MCP 协议确实定义了这三个核心要素：Tool 是服务端提供的可执行函数（如查询数据库、调用 API），LLM 可以主动调用它来完成操作；Resource 是只读的数据源（如文件内容、数据库记录），为 LLM 提供上下文信息但不允许修改；Prompt 是预定义的 prompt 模板，用于标准化交互模式。这种设计将「可执行操作」「只读数据」和「交互模板」三者清晰分离，各有不同的权限级别和交互语义，是 MCP 安全模型的基础。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-004",
|
||
"type": "true_false",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"permission",
|
||
"guardrail"
|
||
],
|
||
"question": "在 AI Agent 的权限治理中，最小权限原则（Principle of Least Privilege）意味着 Agent 在每个任务阶段只应被授予完成该任务所必需的最低限度权限，而不是在整个会话期间拥有固定的全量权限。",
|
||
"answer": true,
|
||
"explanation": "这个说法是正确的。最小权限原则是 AI Agent 安全设计的基石。具体实施中，Agent 的权限应该随任务阶段动态调整：例如在数据读取阶段只授予只读权限，在需要写入时才临时提升权限，任务完成后立即收回。这与传统的「全量授权」模式有本质区别。Human-in-the-Loop 机制通常配合最小权限使用——当 Agent 需要超出当前权限的操作时，请求人类审批而非默认放行。这种设计显著降低了 Agent 误操作或被攻击后的损害范围。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-005",
|
||
"type": "true_false",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"guardrail",
|
||
"llm-ops"
|
||
],
|
||
"question": "当 LLM 输出需要作为结构化数据被下游系统消费时，使用 JSON Mode（或 Structured Output）配合 JSON Schema 校验，可以完全消除输出格式错误的问题，无需额外的容错处理。",
|
||
"answer": false,
|
||
"explanation": "这个说法是错误的。JSON Mode / Structured Output 虽然能大幅提升输出格式的合规率，但不能「完全消除」问题。原因包括：（1）即使 JSON 语法正确，语义层面仍可能不符合业务预期（如枚举值在合法范围内但不符合业务逻辑）；（2）不同模型对 JSON Mode 的支持程度不同，部分模型可能在边界情况下仍然输出不合规内容；（3）Token 限制可能导致 JSON 被截断；（4）网络传输和序列化过程也可能引入问题。工程实践中，JSON Schema 校验应作为第一道防线，之后仍需业务层的容错处理（如重试、fallback、日志告警等），形成多层防御体系。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
} |