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
217 lines
15 KiB
JSON
217 lines
15 KiB
JSON
{
|
||
"topic": "ai-engineering",
|
||
"type": "fill_blank",
|
||
"schema_version": "1.0.0",
|
||
"generated": "2026-09-09T10:00:00+08:00",
|
||
"questions": [
|
||
{
|
||
"id": "fb-001",
|
||
"type": "fill_blank",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"context-engineering"
|
||
],
|
||
"question": "在 RAG（Retrieval-Augmented Generation）系统中，向量数据库的核心作用是将文本块（chunk）通过 Embedding 模型转化为高维向量后进行存储，并在查询时通过______匹配返回与用户问题语义最相近的文档片段，从而为 LLM 提供上下文信息。",
|
||
"answer": [
|
||
"相似度",
|
||
"向量相似度",
|
||
"语义相似度",
|
||
"余弦相似度",
|
||
"近似"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "RAG 系统的工作流程分为检索（Retrieval）和生成（Generation）两个阶段。在检索阶段，用户的问题先通过 Embedding 模型编码为向量，然后在向量数据库中执行相似度搜索（如余弦相似度、欧氏距离、内积等），找到与问题语义最接近的 top-k 文档片段。向量数据库（如 Milvus、Pinecone、Chroma、FAISS）的核心价值在于高效地进行近似最近邻（ANN）搜索，避免了传统关键词匹配无法处理语义理解的局限性。检索到的文档片段作为上下文注入 Prompt，帮助 LLM 生成更准确、有依据的回答。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-002",
|
||
"type": "fill_blank",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"context-engineering"
|
||
],
|
||
"question": "在 Prompt 模板设计中，系统角色定义（System Role）通常放在对话的最前面，用于约束 LLM 的行为边界和输出格式。这种将角色、指令和约束统一注入 Prompt 的工程方法被称为______，它强调通过系统性地构造上下文来控制 LLM 的行为。",
|
||
"answer": [
|
||
"Prompt Engineering",
|
||
"prompt engineering",
|
||
"提示工程",
|
||
"提示词工程"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "Prompt Engineering（提示工程）是指通过精心设计输入给 LLM 的文本（Prompt），来引导模型产生期望输出的工程方法。System Role 是 Prompt Engineering 中的关键组成部分，它定义了模型的身份、能力边界、行为准则和输出格式。例如，在一个客服助手中的 System Role 可能定义为「你是一个专业的客服助手，只能回答与产品相关的问题，回复时使用简洁的语气」。好的 System Role 设计能显著降低模型幻觉率、提高输出一致性和可控性。在更广泛的 Context Engineering（上下文工程）视角下，System Role 只是上下文构建的一个环节，还包括检索注入、Few-shot 示例、工具描述等多个维度。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-003",
|
||
"type": "fill_blank",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"harness-engineering",
|
||
"ai-agent"
|
||
],
|
||
"question": "ReAct（Reasoning + Acting）模式是一种将 LLM 的推理和行动能力结合的智能体框架。其核心循环包含三个步骤：首先 LLM 进行内部推理（Thought），然后决定并执行一个外部操作（Action），最后根据操作结果获取反馈（______），并将反馈作为下一轮推理的输入。",
|
||
"answer": [
|
||
"Observation",
|
||
"observation",
|
||
"观察"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "ReAct 模式由 Yao et al. (2022) 在论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出。其核心思想是让 LLM 交替进行推理（Thought）和行动（Action），形成 Thought → Action → Observation 的循环。具体流程为：(1) Thought：LLM 分析当前状态，制定下一步计划；(2) Action：LLM 选择并调用一个工具（如搜索引擎、计算器、API）；(3) Observation：将工具返回的结果作为观察反馈给 LLM。这个循环不断重复，直到 LLM 认为已获得足够信息可以给出最终答案。ReAct 的优势在于将 Chain-of-Thought（思维链）推理与工具调用无缝结合，既保持了推理的可解释性，又扩展了模型的能力边界。LangChain、LlamaIndex 等主流框架都实现了 ReAct Agent。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-004",
|
||
"type": "fill_blank",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"tool-calling",
|
||
"harness-engineering"
|
||
],
|
||
"question": "在 LLM 的 Tool Calling（函数调用）机制中，当模型决定使用某个工具时，它会输出一个符合 JSON Schema 规范的结构化参数。这个参数对象中，最外层必须包含 \"name\"（工具名称）和 \"______\"（工具所需的输入参数）两个核心字段。",
|
||
"answer": [
|
||
"arguments",
|
||
"parameters",
|
||
"input",
|
||
"params",
|
||
"args"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "现代 LLM 的 Tool Calling 机制（如 OpenAI 的 Function Calling、Anthropic 的 Tool Use）要求模型以结构化 JSON 格式输出工具调用请求。标准格式包含两个核心字段：(1) name：要调用的工具/函数名称，必须与系统中注册的工具名精确匹配；(2) arguments（或 parameters）：一个 JSON 对象，包含该工具所需的全部输入参数，参数结构需符合预先定义的 JSON Schema。例如，调用天气查询工具时，输出可能为 {\"name\": \"get_weather\", \"arguments\": {\"city\": \"北京\", \"unit\": \"celsius\"}}。框架层负责解析这个 JSON 并执行实际的函数调用，然后将结果返回给 LLM 继续推理。这种设计将 LLM 的「意图理解」与「工具执行」解耦，是 Harness Engineering（驾驭工程）的核心模式之一。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-005",
|
||
"type": "fill_blank",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"ai-agent"
|
||
],
|
||
"question": "在多智能体架构中，Agent 之间协作的一种常见模式是「共享状态」模式：多个 Agent 共同访问和修改一个中心化的______，每个 Agent 读取共享信息、执行自己的子任务后，将结果写回该状态，从而实现跨 Agent 的信息流转与协作。",
|
||
"answer": [
|
||
"状态",
|
||
"上下文",
|
||
"shared state",
|
||
"上下文状态",
|
||
"状态空间",
|
||
"黑板",
|
||
"黑板系统",
|
||
"共享上下文",
|
||
"全局状态"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "在多智能体系统（Multi-Agent System）中，Agent 间的协作模式主要有三种：(1) 共享状态（Shared State/Blackboard）模式：所有 Agent 共享一个中心化的状态存储（如 Blackboard），每个 Agent 可以读取全局状态、执行子任务并将结果写回，实现松耦合协作。LangGraph 的 StateGraph 就是这种模式的典型实现。(2) 消息传递（Message Passing）模式：Agent 之间通过直接发送消息通信，没有共享状态。(3) 层级委托（Hierarchical Delegation）模式：由一个主 Agent 将任务分解并委派给子 Agent。共享状态模式的优势是实现简单、状态透明，但需要注意并发写入时的竞态条件和状态一致性问题。在实际工程中，常结合状态快照（Checkpoint）和事务机制来保证可靠性。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-006",
|
||
"type": "fill_blank",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"mcp",
|
||
"ai-agent"
|
||
],
|
||
"question": "MCP（Model Context Protocol）是由 Anthropic 提出的开放协议，用于标准化 LLM 应用与外部数据源和工具之间的连接。MCP 的三大核心要素是：Server（提供能力的服务端）、Client（消费能力的客户端），以及定义在 Server 和 Client 之间通信的______。",
|
||
"answer": [
|
||
"协议",
|
||
"通信协议",
|
||
"消息协议",
|
||
"Protocol",
|
||
"transport",
|
||
"传输层",
|
||
"JSON-RPC"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "MCP 的架构围绕三个核心要素展开：(1) MCP Server：暴露工具（Tools）、资源（Resources）和提示模板（Prompts）的服务端程序，负责与具体的外部数据源或 API 对接。(2) MCP Client：嵌入在 LLM 应用（如 IDE、聊天界面）中的客户端，负责发现和调用 Server 提供的能力。(3) 协议本身：定义了 Server 和 Client 之间基于 JSON-RPC 2.0 的通信规范，包括能力发现（initialize）、工具调用（tools/call）、资源读取（resources/read）等标准方法。MCP 的核心价值在于解决了「M×N 集成问题」——传统方式下 M 个 LLM 应用对接 N 个工具需要 M×N 个适配器，而 MCP 将其降低为 M+N 个。协议支持 stdio 和 HTTP+SSE 两种传输方式。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-007",
|
||
"type": "fill_blank",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"permission"
|
||
],
|
||
"question": "在 AI Agent 的权限治理中，沙箱（Sandbox）执行环境通过进程隔离、文件系统隔离和______隔离等机制，确保 Agent 执行的代码或命令不会影响宿主系统安全。常见的沙箱技术包括 Docker 容器、gVisor 和 Firecracker。",
|
||
"answer": [
|
||
"网络",
|
||
"网络隔离",
|
||
"namespace",
|
||
"命名空间",
|
||
"资源",
|
||
"资源隔离",
|
||
"cgroup"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "沙箱执行环境是 AI Agent 权限治理的核心防线，通过多层隔离机制限制 Agent 的能力边界：(1) 进程隔离：使用 Linux namespace 或容器技术，使 Agent 进程无法看到或访问宿主系统的其他进程。(2) 文件系统隔离：通过只读挂载或 overlay filesystem 限制 Agent 只能访问特定目录，阻止读取/修改敏感文件。(3) 网络隔离：通过网络命名空间、iptables 规则或代理层限制 Agent 的网络访问范围，防止未授权的外部请求。(4) 资源隔离：使用 cgroup 限制 CPU、内存、磁盘 I/O 等资源使用，防止资源耗尽攻击。在 QwenPaw 等框架中，sandbox_config 支持配置 mount 权限和网络限制，确保 Agent 只能在授权范围内执行操作。gVisor 和 Firecracker 提供了比传统 Docker 更强的内核级隔离。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-008",
|
||
"type": "fill_blank",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"pluggable-config"
|
||
],
|
||
"question": "在 AI 框架的可插拔配置设计中，Provider 抽象层通过统一的接口（如 chat、embed、complete 等方法）屏蔽不同 LLM 供应商的 API 差异。当需要切换底层模型（如从 OpenAI 切换到 Qwen）时，只需修改配置中的______字段，无需改动业务代码。",
|
||
"answer": [
|
||
"provider",
|
||
"provider_id",
|
||
"providerId",
|
||
"provider_name",
|
||
"模型供应商"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "Provider 抽象层是现代 AI 框架实现可插拔架构的关键设计模式。其核心思想是定义一套标准化接口（通常包括 chat/completion、embedding、function calling 等方法），然后为不同的 LLM 供应商（OpenAI、Anthropic、Qwen、本地模型等）实现具体的适配器。配置层面通常通过 provider 字段（或 provider_id）来指定使用哪个后端。例如在 QwenPaw 中，切换模型只需在配置文件中修改 provider 和 model 字段，框架会自动路由到对应的适配器实现。这种设计遵循了 SOLID 原则中的依赖倒置原则（DIP）——业务代码依赖于抽象接口而非具体实现。Provider 抽象层还统一处理了认证管理、请求重试、响应格式标准化、Token 计费等横切关注点，极大降低了切换和维护成本。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-009",
|
||
"type": "fill_blank",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"guardrail"
|
||
],
|
||
"question": "在 LLM 应用的 Guardrail（安全护栏）系统中，PII（Personally Identifiable Information，个人身份信息）检测是重要的防护环节。通过预定义的______表达式（如匹配手机号、身份证号、邮箱地址等模式），可以在输入和输出阶段自动识别并脱敏敏感信息，防止数据泄露。",
|
||
"answer": [
|
||
"正则",
|
||
"正则表达式",
|
||
"regex",
|
||
"Regular Expression",
|
||
"regexp"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "PII 检测是 Guardrail 系统的基础能力之一。正则表达式（Regular Expression）因其高效、确定性强的特点，是实现 PII 模式匹配的首选技术。常见的正则匹配策略包括：(1) 中国大陆手机号：以 1 开头、第二位 3-9、后续 9 位数字；(2) 身份证号：18 位，包含地区码、出生日期、顺序码和校验位；(3) 邮箱地址：用户名 + @ + 域名格式。在实际 Guardrail 架构中，正则匹配通常作为第一层快速筛查（低延迟、高召回），配合 NER（命名实体识别）模型作为第二层精细检测（高精度、低误报）。检测到 PII 后的处理策略包括：阻断（Block）、脱敏（Mask/Redact，如将身份证号替换为占位符）、或告警。Guardrail 系统还应支持正则规则的热更新，以便快速应对新出现的 PII 模式。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "fb-010",
|
||
"type": "fill_blank",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"llm-ops"
|
||
],
|
||
"question": "在 LLM 应用的可靠性工程中，当 API 调用失败（如限流 429 错误）时，指数退避重试是标准策略。其等待时间的计算公式为：delay = min(base * 2^n + random, max_delay)，其中 base 是基础延迟，n 是当前重试次数，max_delay 是最大等待上限，random 是随机抖动值。增加随机抖动（jitter）的目的是防止多个客户端在重试时产生______效应。",
|
||
"answer": [
|
||
"惊群",
|
||
"惊群效应",
|
||
"thundering herd",
|
||
"Thundering Herd",
|
||
"同步",
|
||
"同步重试"
|
||
],
|
||
"answer_rule": "any",
|
||
"explanation": "指数退避（Exponential Backoff）是分布式系统中最常用的重试策略，公式为 delay = min(base * 2^n + jitter, max_delay)。其中 base 通常设为 1 秒，n 从 0 开始递增。例如第 1 次重试等待约 1 秒，第 2 次约 2 秒，第 3 次约 4 秒，依此类推直到 max_delay（通常 60-120 秒）。引入随机抖动（jitter）至关重要——如果不加抖动，所有遇到 429 错误的客户端会在完全相同的时间点重试，形成「惊群效应」（Thundering Herd），导致服务端在短时间内再次承受峰值压力，陷入反复限流的恶性循环。常见的 jitter 策略有：(1) Full Jitter：在 [0, base*2^n] 范围内随机取值；(2) Equal Jitter：基础值的一半 + 随机值；(3) Decorrelated Jitter：基于上一次等待时间计算。在 LLM Ops 实践中，建议结合 Circuit Breaker（熔断器）使用，当连续失败超过阈值时暂停重试，避免无意义的资源消耗。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
} |