🎯题库与情境练习

{"bank":[{"analysis":"四框架定位不同：**Ollama** 本地一键跑模型，适合开发/Demo；**vLLM** 面向生产高吞吐（PagedAttention + Continuous Batching）；**llama.cpp** 面向 CPU 与轻量端侧，无 GPU 也能跑；**TGI** 面向 HuggingFace 生态的生产推理。无 GPU 的端侧场景对应 llama.cpp。","answer":"C","chapter":"AI落地·推理框架","difficulty":1,"explain":{"A":"Ollama 定位是开发/Demo 的一键运行，不是端侧嵌入式方案。","B":"vLLM 强依赖 GPU 与显存，定位是生产级高吞吐服务。","D":"TGI 是 HF 生态的生产推理服务，同样以 GPU 部署为主。"},"id":"bs-01-001","options":["Ollama","vLLM","llama.cpp","TGI"],"source":"chapter","stem":"在没有 GPU 的手机、嵌入式等端侧设备上跑模型，最匹配的推理框架是？","subject":"模型部署","type":"single"},{"analysis":"选型先问“吞吐还是延迟优先、有没有 GPU、团队栈是什么”。vLLM 的 PagedAttention 降低 KV Cache 显存碎片、Continuous Batching 让 batch 动态进出，是吞吐优先的生产首选；Ollama 吞吐与并发弱，llama.cpp 性能上限低，逐条推理没有批处理与显存管理。","answer":"A","chapter":"AI落地·推理框架","difficulty":2,"explain":{"B":"Ollama 是开发利器不是生产方案，吞吐、并发与可观测都弱。","C":"llama.cpp 面向 CPU 与端侧，性能上限低，扛不住高并发生产。","D":"逐条串行调用没有批处理与显存复用，吞吐最差。"},"id":"bs-01-002","options":["vLLM","Ollama","llama.cpp","直接用原生 transformers 逐条串行推理"],"source":"chapter","stem":"团队要自建在线推理服务，业务以高并发、吞吐优先为第一目标，最匹配的框架是？","subject":"模型部署","type":"single"},{"analysis":"7B × 2 字节 ≈ **14GB**（口诀：FP16 十四 G、INT8 七 G、INT4 三点五）。这只是显存账里的静态部分，还要再加上动态的 KV Cache、激活与框架开销。","answer":"C","chapter":"AI落地·推理框架","difficulty":2,"explain":{"A":"3.5GB 对应 INT4（约 0.5 字节/参数）。","B":"7GB 对应 INT8（1 字节/参数）。","D":"28GB 相当于按 4 字节/参数估算，量级错误。"},"id":"bs-01-003","options":["约 3.5GB","约 7GB","约 14GB","约 28GB"],"source":"chapter","stem":"一个 7B 模型以 FP16 加载（每参数 2 字节），仅模型权重约占多少显存？","subject":"模型部署","type":"single"},{"analysis":"口诀“**权重静态 KV 动态**”：模型权重加载即占、基本不变；KV Cache 随“并发 × 上下文长度”线性增长，是动态大头；激活是前向计算的临时占用；框架开销常驻 1~2GB 量级。估算顺序是先算权重、再估 KV，并留约 20% 余量。","answer":"B","chapter":"AI落地·推理框架","difficulty":2,"explain":{"A":"权重是静态项，加载后占用基本固定。","C":"激活是前向计算的临时占用，量级较小。","D":"框架开销相对固定，不随并发与上下文线性增长。"},"id":"bs-01-004","options":["模型权重","KV Cache","激活","框架开销"],"source":"chapter","stem":"在“显存 ≈ 模型权重 + KV Cache + 激活 + 框架开销”的账里，随并发数与上下文长度线性增长、最容易成为爆显存元凶的是？","subject":"模型部署","type":"single"},{"analysis":"兼容接口的意义是“**应用侧零改造**”：已有 OpenAI SDK 只替换 base_url 就能切到自部署服务。接口协议不改变模型精度，也不能替代鉴权与限流——它们是独立的服务化能力。","answer":"A","chapter":"AI落地·推理框架","difficulty":1,"explain":{"B":"接口协议与模型效果无关。","C":"显存由权重与 KV Cache 决定，与接口形式无关。","D":"鉴权与限流是必须另外实现的安全与容量措施。"},"id":"bs-01-005","options":["应用侧无需改造，现有 OpenAI SDK 换个 base_url 即可接入","自动提升模型回答的准确率","可以省掉 GPU 显存占用","可以替代鉴权与限流"],"source":"chapter","stem":"自建推理服务提供 OpenAI 兼容 API（如 /v1/chat/completions）最直接的价值是？","subject":"模型部署","type":"single"},{"analysis":"服务化三件套是兼容 API、鉴权、限流。兼容 API 让应用不改代码，鉴权防止未授权调用，限流按容量设定 QPS / 并发 / token 配额阈值，两者合起来让服务“能用且不被打爆”。","answer":"A","chapter":"AI落地·推理框架","difficulty":2,"explain":{"B":"首 token 时延由 Prefill 与算力决定，与鉴权限流无关。","C":"量化掉点由量化方法与验证流程决定。","D":"上下文窗口由模型能力与显存容量决定。"},"id":"bs-01-006","options":["防止服务被滥用白嫖，并按容量阈值避免被打爆","降低首 token 的时延","减少量化带来的精度掉点","自动扩展上下文窗口长度"],"source":"chapter","stem":"推理服务上线生产时，配置“鉴权 + 限流”这两件的主要作用是？","subject":"模型部署","type":"single"},{"analysis":"量化即用更少位数近似表示参数，7B 口径下 FP16 ≈ 14GB、**INT8 ≈ 7GB**、INT4 ≈ 3.5GB。INT8 掉点很小，常被称为均衡之选。","answer":"B","chapter":"AI落地·量化微调","difficulty":1,"explain":{"A":"3.5GB 对应 INT4（约 0.5 字节/参数）。","C":"14GB 是 FP16 的基线大小。","D":"28GB 相当于按 4 字节/参数估算，量级错误。"},"id":"bs-02-001","options":["约 3.5GB","约 7GB","约 14GB","约 28GB"],"source":"chapter","stem":"同一个 7B 模型改为 INT8（每参数约 1 字节）后，权重显存约为？","subject":"模型部署","type":"single"},{"analysis":"口诀“**AWQ 保通道推理快，GPTQ 校准稳，KV 量化省长文**”。AWQ 是激活感知量化，保护对激活影响大的通道，推理时无需逐 token 反量化、速度表现好；GPTQ 靠校准数据逐层补偿误差；SmoothQuant 把难量化维度平滑到另一边，常与 INT8/INT4 组合；KV 量化作用在 KV Cache 上。","answer":"A","chapter":"AI落地·量化微调","difficulty":2,"explain":{"B":"GPTQ 的核心是校准数据逐层误差补偿，不以激活感知为特点。","C":"SmoothQuant 是把难量化的维度平滑到另一边后配合低比特量化。","D":"KV 量化针对 KV Cache 降精度，用于节省长上下文显存。"},"id":"bs-02-002","options":["AWQ","GPTQ","SmoothQuant","KV 量化"],"source":"chapter","stem":"“激活感知、保护被大激活值点亮的通道、推理速度快”描述的是哪种量化方法？","subject":"模型部署","type":"single"},{"analysis":"量化选型三问：够 FP16 就别量化（精度无损）；够 INT8 用 INT8（掉点小、部署简单）；只够 INT4 时用 INT4（AWQ 优先）并必须做掉点验证。精度、显存、速度是三角权衡，不是单向下压。","answer":"A","chapter":"AI落地·量化微调","difficulty":2,"explain":{"B":"无脑 INT4 会带来不必要的掉点，且未必需要。","C":"显存充足时量化是用精度换不来收益。","D":"KV Cache 量化主要缓解长上下文显存压力，不能替代权重精度选型。"},"id":"bs-02-003","options":["显存够 FP16 就不量化；够 INT8 用 INT8；只够 INT4 才上 INT4 且必测掉点","无论显存是否充足，一律先量化到 INT4 省显存","显存充足也要先量化到 INT4，把省下的显存留作备用","先量化 KV Cache，再据此决定权重精度"],"source":"chapter","stem":"关于权重量化的选型顺序，正确的做法是？","subject":"模型部署","type":"single"},{"analysis":"铁律是“**量化必测掉点**”：先建业务测试集（核心/边界/对抗分层），FP16 跑基线，INT4 同集跑一遍对比 diff，掉点不超过业务阈值才上线。不同任务敏感度差异很大，代码与数学推理最敏感，别人说够用不等于你的业务够用。","answer":"A","chapter":"AI落地·量化微调","difficulty":2,"explain":{"B":"他人的结论不能替代自测，任务分布不同掉点差异大。","C":"显存下降是量化的收益，不是可上线的质量判据。","D":"速度提升同样不能证明回答质量可接受。"},"id":"bs-02-004","options":["在业务测试集上对比 FP16 基线，掉点是否在业务阈值内","社区里大家都说这个方法效果好","显存占用是否明显下降","推理速度是否明显变快"],"source":"chapter","stem":"判断某个 INT4 量化版本能否上线，正确的依据是？","subject":"模型部署","type":"single"},{"analysis":"LoRA 冻结原模型，旁挂一组低秩小矩阵 A×B（秩 r 常取 8~64），只训这两个小矩阵，因此参数量与显存开销大幅下降，单卡即可微调 7B。知识类需求应优先 RAG，格式语气用 Prompt，领域术语与固定表达才考虑 LoRA。","answer":"A","chapter":"AI落地·量化微调","difficulty":2,"explain":{"B":"全量微调的算力与显存成本远高于 LoRA，不是其原理。","C":"只改提示词属于 Prompt 工程，不改变模型行为。","D":"推理时替换层不是 LoRA 的训练方式。"},"id":"bs-02-005","options":["冻结原模型参数，只训练旁挂的低秩小矩阵","对原模型全部参数做全量重训","只调整提示词，不改变任何模型参数","在推理时动态替换模型的部分层"],"source":"chapter","stem":"LoRA 微调的基本原理是？","subject":"模型部署","type":"single"},{"analysis":"这是灾难性遗忘：只喂领域数据会让通用能力退化。对策是训练时混入 **10~20% 通用指令数据**，评测时同时看“领域集上涨 + 通用集不下降”。数据质量优先于数量，500 条高质量胜过 5000 条噪声。","answer":"A","chapter":"AI落地·量化微调","difficulty":3,"explain":{"B":"轮数越多越容易过拟合领域数据，反而加剧遗忘。","C":"只用领域数据正是遗忘的成因。","D":"删长样本与遗忘无关，还会损害数据多样性。"},"id":"bs-02-006","options":["训练时混入 10~20% 通用指令数据，并用通用测试集做回归","把训练轮数拉到 20 个 epoch 以上","只用领域数据再多训几轮","删掉训练集里较长的样本"],"source":"chapter","stem":"LoRA 微调后出现“通用能力退化、不会正常聊天了”，最有效的对策是？","subject":"模型部署","type":"single"},{"analysis":"RAG 五步为**切分、Embedding、检索、重排、生成**，整体分“离线建库 + 在线问答”两段。重排一定发生在检索之后、生成之前，因为它的输入就是召回的候选块。","answer":"A","chapter":"AI落地·RAG 链路","difficulty":1,"explain":{"B":"必须先切分并嵌入建库，才可能被检索到。","C":"生成不可能排在检索与重排之前。","D":"重排依赖检索结果，无法先于检索执行。"},"id":"rag-01-001","options":["切分 → 嵌入 → 检索 → 重排 → 生成","检索 → 切分 → 重排 → 嵌入 → 生成","嵌入 → 切分 → 生成 → 检索 → 重排","重排 → 检索 → 切分 → 嵌入 → 生成"],"source":"chapter","stem":"RAG 从文档到答案的正确链路顺序是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"切分三原则是**语义完整、长度适中、留点重叠**：按段落/标题/问答对切以免腰斩句子，块长控制在嵌入模型上限内的 256~512 token，相邻块重叠 10~20% 避免边界信息丢失；表格与代码应整块保留。口诀说“切分是 RAG 一半质量”。","answer":"A","chapter":"AI落地·RAG 链路","difficulty":2,"explain":{"B":"固定长度硬切会腰斩句子，零重叠还会丢边界信息，是 RAG 头号杀手。","C":"一句一块会丢失上下文，召回后难以支撑回答。","D":"整章一块往往超出嵌入与生成模型的上下文上限。"},"id":"rag-01-002","options":["按标题或段落等语义边界切，块长约 256~512 token，相邻块保留 10~20% 重叠","固定每 500 字硬切，块与块之间不重叠","每一句话切一块，保证块足够小","整章内容切成一个块，保证上下文完整"],"source":"chapter","stem":"下列切分做法中，最符合 RAG 切分原则的是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"向量检索强在语义相近（“咋退款”≈“如何退款”），弱在专有名词与编号；BM25 强在精确词匹配但不懂同义。生产标配是**混合检索**：两路各召回 top-k，合并去重后再重排。","answer":"A","chapter":"AI落地·RAG 链路","difficulty":2,"explain":{"B":"维度大小不解决精确匹配问题。","C":"temperature 影响生成随机性，与召回无关。","D":"top-k=1 会进一步降低召回率，漏掉正确答案。"},"id":"rag-01-003","options":["BM25 关键词检索，与向量检索组成混合检索","把 Embedding 的向量维度调得更大","把生成阶段的 temperature 调高","把召回 top-k 直接设成 1"],"source":"chapter","stem":"用户用型号、编号、人名等专有名词提问时召回效果差，最应该补充的是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"向量召回是速度快但精度有限的粗排；Reranker 把“问题 + chunk”一起编码打分，精度高但慢，所以只对 top（如 50）精排到 top-n（3~8）。原则是“**召回宁多勿漏，精排宁缺毋滥**”。","answer":"A","chapter":"AI落地·RAG 链路","difficulty":2,"explain":{"B":"重排发生在检索之后，不负责建库。","C":"生成由大模型完成，重排只负责排序。","D":"上下文压缩是另一步优化，不是重排的职责。"},"id":"rag-01-004","options":["用交叉编码器对召回的 top-k 精排，把最相关的 top-n 交给模型","替代 Embedding 完成建库","负责生成最终答案","压缩提示词的长度"],"source":"chapter","stem":"重排（Reranker）在 RAG 中的作用是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"精排后的 chunk 不是越多越好：过多低相关块会引入噪声、挤占上下文窗口，甚至把真正相关的内容挤出窗口。“**塞太多 = 自找幻觉**”，3~8 个通常够用，召回阶段才应该宁多勿漏。","answer":"A","chapter":"AI落地·RAG 链路","difficulty":2,"explain":{"B":"更多上下文不等于更准，噪声会干扰模型判断。","C":"输入变长会让 Prefill 更慢，TTFT 反而上升。","D":"检索本身仍然有效，问题出在给模型的资料质量。"},"id":"rag-01-005","options":["噪声淹没信号并挤占上下文，反而更容易出现幻觉","答案准确率一定随之提升","首 token 时延一定会变快","检索环节会彻底失效"],"source":"chapter","stem":"把精排后送入模型的 top-n 从 3~8 扩大到 20 以上，最可能的后果是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"低分 chunk 是幻觉源。提示词应约束“**只根据给定资料回答，资料不足就明说，不要编**”；检索为空或低分时走兜底，如实告知并给人工入口，同时答案要标注引用来源，让用户可查证。","answer":"A","chapter":"AI落地·RAG 链路","difficulty":2,"explain":{"B":"无资料自由发挥正是幻觉的典型来源。","C":"硬塞低分资料会让模型基于错误依据编造。","D":"复用旧答案与用户当前问题无关，属于错误回答。"},"id":"rag-01-006","options":["如实说明没找到，并给出人工入口或改问建议","照常让模型自由发挥作答","把分数最低的 chunk 也塞进提示词","直接返回上一个问题的答案"],"source":"chapter","stem":"检索结果为空或全部低于分数阈值时，正确的兜底设计是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"Agent = 模型（大脑，负责决策）+ 工具（手脚，搜索/数据库/API/代码执行）+ 循环（思考→行动→观察→再思考）。循环必须设步数与超时上限，否则存在死循环风险。","answer":"A","chapter":"AI落地·Agent","difficulty":1,"explain":{"B":"这些是生成采样参数，不是 Agent 的结构要素。","C":"这是 RAG 链路的组成部分。","D":"这是通用系统架构，与 Agent 定义无关。"},"id":"rag-02-001","options":["模型 + 工具 + 循环","提示词 + 温度 + top-p","向量库 + 重排 + 生成","前端 + 后端 + 数据库"],"source":"chapter","stem":"Agent 的三个基本要素是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"ReAct 循环为 Thought → Action → Observation → Thought → … → Final Answer，关键是把 Observation 喂回模型，由模型判断信息是否足够、下一步做什么。**Agent 的智能在循环，不在单次调用**。","answer":"A","chapter":"AI落地·Agent","difficulty":2,"explain":{"B":"提示词长度不构成循环中的决策能力。","C":"工具越多越容易选错，描述清晰比数量重要。","D":"温度只影响输出随机性，与多步决策无关。"},"id":"rag-02-002","options":["把工具的观察结果喂回模型，由模型决定继续调用还是给出最终回答","单次调用的提示词写得足够长","接入的工具数量足够多","把 temperature 调得足够高"],"source":"chapter","stem":"ReAct 模式中，Agent 的“智能”主要体现在哪里？","subject":"RAG 与 Agent","type":"single"},{"analysis":"工具定义三要素：名字 + 描述（做什么，**描述质量决定调用准确率**）、参数 schema（字段/类型/必填/说明）、返回结构（模型读得懂的 Observation）。","answer":"A","chapter":"AI落地·Agent","difficulty":2,"explain":{"B":"返回值加密会让模型读不懂观察结果。","C":"实现语言对模型不可见，不影响调用决策。","D":"部署地域影响时延，不影响是否调用。"},"id":"rag-02-003","options":["工具名称与描述是否写清楚，参数 schema 是否明确","工具的返回值是否做了加密","工具用什么编程语言实现","工具服务部署在什么地域"],"source":"chapter","stem":"决定模型能否正确调用某个工具，最关键的因素是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"模型会编参数，生产上必须“**参数先校验再执行**”，并按最小必要授予工具权限；写库、支付、删除等高风险动作必须人工确认，且全程记录调用日志以便追溯。","answer":"A","chapter":"AI落地·Agent","difficulty":2,"explain":{"B":"直接信任模型参数是典型的安全事故。","C":"只校验个数拦不住类型、范围与越权参数。","D":"让模型自证不能替代系统侧的校验。"},"id":"rag-02-004","options":["先按 schema 校验再执行，高风险动作还要人工确认","直接信任模型参数并立即执行","只校验参数个数是否一致","让模型自己再确认一遍即可"],"source":"chapter","stem":"模型给出的工具调用参数，在执行前应当如何处理？","subject":"RAG 与 Agent","type":"single"},{"analysis":"选型口诀“**步骤固定用工作流，开放任务用 Agent，混合场景用工作流骨架 + 关键步 Agent**”。工作流每步确定、成本固定，符合合规诉求；评审常问“为什么不用工作流”，别为了 Agent 而 Agent。","answer":"A","chapter":"AI落地·Agent","difficulty":2,"explain":{"B":"自主 Agent 路径不可控、成本不固定，不符合合规要求。","C":"多 Agent 协商会进一步放大不可控与不可复现。","D":"每次自决流程会让结果无法复现与审计。"},"id":"rag-02-005","options":["工作流：由人设计固定步骤，可控且成本低","完全自主决策的 Agent","多个 Agent 自由协商","让模型每次自行决定流程"],"source":"chapter","stem":"报销审核、客服 SOP 这类步骤固定且合规要求高的业务，最合适的形态是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"生产约束四闸：**步数上限**（如 5~10 步）防死循环、**超时**（如 30s~2min）控总时长、**人工确认**（写库/支付/删除必确认）、**降级**（卡住或超限时转人工或给部分结果）。四闸缺一不可。","answer":"A","chapter":"AI落地·Agent","difficulty":2,"explain":{"B":"这些是生成采样参数，不是 Agent 的循环约束。","C":"这是 RAG 链路的处理步骤。","D":"这些是服务化与安全措施，不等于 Agent 循环边界。"},"id":"rag-02-006","options":["步数上限、超时、人工确认、降级","温度、top-p、max_tokens、频率惩罚","输入、检索、重排、生成","登录、鉴权、限流、审计"],"source":"chapter","stem":"Agent 上线前的“四道闸”指的是？","subject":"RAG 与 Agent","type":"single"},{"analysis":"Prefill 一次处理全部输入并计算 KV，是**计算密集**阶段，决定 TTFT；Decode 逐 token 生成、受**显存带宽**限制，决定 TPOT。口诀“**TTFT 治 Prefill，TPOT 治 Decode**”，瓶颈在哪就优化哪。","answer":"A","chapter":"AI落地·推理优化","difficulty":1,"explain":{"B":"Decode 决定每 token 时延（TPOT），不决定首 token。","C":"检索属于 RAG 链路，与 LLM 推理阶段划分无关。","D":"前端渲染不属于服务端 TTFT 的构成。"},"id":"yh-01-001","options":["Prefill 阶段","Decode 阶段","向量检索阶段","前端渲染阶段"],"source":"chapter","stem":"首 token 时延（TTFT）主要由哪个阶段决定？","subject":"推理优化","type":"single"},{"analysis":"Decode 逐 token 生成，每一步都要读取权重与 KV Cache，属于**显存带宽密集**，因此大 batch、显存带宽与量化是主要优化方向；而 Prefill 是算力密集，对应更强 GPU 或 PD 分离。","answer":"A","chapter":"AI落地·推理优化","difficulty":2,"explain":{"B":"网络带宽影响传输，不决定单步解码速度。","C":"磁盘 IO 主要影响模型加载而非逐 token 解码。","D":"CPU 主频不是 GPU 解码阶段的主要瓶颈。"},"id":"yh-01-002","options":["显存带宽","网络带宽","磁盘 IO","CPU 主频"],"source":"chapter","stem":"Decode 阶段的性能瓶颈主要是？","subject":"推理优化","type":"single"},{"analysis":"KV 显存 ≈ 2 × 层数 × 隐层维 × **上下文长度 × 并发数** × 字节数。“2”代表 Key 与 Value 两份。并发翻倍 KV 翻倍；上下文 4K → 32K 则 KV 约 ×8；INT8/FP8 KV 量化还能把字节数减半或更多。","answer":"A","chapter":"AI落地·推理优化","difficulty":2,"explain":{"B":"语言种类不进入 KV Cache 的估算式。","C":"标点数量不是独立变量，不构成线性因子。","D":"前端页面数量与服务端 KV Cache 无关。"},"id":"yh-01-003","options":["并发数与上下文长度","用户使用的语言种类","回答里标点符号的数量","前端页面的数量"],"source":"chapter","stem":"KV Cache 的显存占用会随下列哪组变量线性增长？","subject":"推理优化","type":"single"},{"analysis":"传统做法为 KV 预分配连续显存，实际占用远小于分配量，造成碎片浪费。PagedAttention 把 KV 按“页”分配（类似操作系统虚拟内存分页），碎片趋近于零，显存利用率大幅提升，同卡可跑更多并发。","answer":"A","chapter":"AI落地·推理优化","difficulty":2,"explain":{"B":"权重加载速度与显存分页机制无关。","C":"提示词注入属于输入侧安全防护。","D":"召回率由检索与重排环节决定。"},"id":"yh-01-004","options":["传统 KV Cache 预分配连续显存造成的碎片浪费","模型权重加载太慢","提示词注入攻击","向量检索召回率低"],"source":"chapter","stem":"PagedAttention 解决的核心问题是？","subject":"推理优化","type":"single"},{"analysis":"静态 Batch 必须等最长请求生成完才整批出结果，短请求干等。Continuous Batching 逐步动态进出：完成的移出、新的补进，**batch 常满**，吞吐接近硬件上限。","answer":"A","chapter":"AI落地·推理优化","difficulty":2,"explain":{"B":"静态加大 batch 仍然存在“等齐”问题。","C":"“等最长的”正是静态 Batch 的缺陷本身。","D":"减少层数是模型结构改动，不属于批处理调度。"},"id":"yh-01-005","options":["每生成一步就移出已完成请求、补入新请求，让 batch 始终接近满员","把固定的 batch size 设得尽可能大","让所有请求等最长的那条一起返回","减少模型的层数以加快推理"],"source":"chapter","stem":"Continuous Batching 相比静态 Batch 的关键改进是？","subject":"推理优化","type":"single"},{"analysis":"Batch 不是越大越好：更大的 batch 通常提升吞吐，但会推高 TPOT（每 token 变慢），属于**吞吐与延迟的权衡**，要在 SLO 约束下找平衡点，并用优化前后的对比数据证明收益。","answer":"A","chapter":"AI落地·推理优化","difficulty":3,"explain":{"B":"吞吐与时延存在权衡，不存在同时无限变好。","C":"batch 越大，KV Cache 等显存占用越高。","D":"大 batch 带来的排队与显存压力同样会影响 TTFT。"},"id":"yh-01-006","options":["吞吐上升但 TPOT 变差，需要按 SLO 权衡取舍","吞吐与时延同时无限变好","与显存占用完全无关","TTFT 必然下降且不受影响"],"source":"chapter","stem":"把 batch 无限制调大，最可能出现的结果是？","subject":"推理优化","type":"single"},{"analysis":"每千次成本 ≈（单次平均输入 token × 输入单价 + 单次平均输出 token × 输出单价）× 1000。输入侧不只是提示词模板，还包括上下文与检索 chunk；RAG 场景里 chunk 常是输入 token 的大头，漏算会导致成本严重低估。","answer":"A","chapter":"AI落地·成本容量","difficulty":2,"explain":{"B":"模板属于输入的显式组成部分，一般不会漏。","C":"输出长度是公式里的显式乘项。","D":"单价是公式的乘数，属于必填项。"},"id":"yh-02-001","options":["检索注入的上下文 token（RAG 场景下 chunk 往往是大头）","提示词模板的固定部分","模型输出的平均长度","输入与输出各自的 token 单价"],"source":"chapter","stem":"估算“每千次调用成本”时，最容易被漏掉的一项是？","subject":"推理优化","type":"single"},{"analysis":"自部署单价会随 GPU 利用率浮动，利用率越低实际单价越高（利用率 30% 时实际单价约为理论 3 倍）。请求量不大时 API 更划算，量大到能跑满卡再考虑自建；口诀“**量小用 API，量大再自部**”。","answer":"A","chapter":"AI落地·成本容量","difficulty":2,"explain":{"B":"团队规模不直接决定单位调用成本。","C":"参数量影响显存需求，不决定哪种方式更便宜。","D":"网速不是成本核算的核心变量。"},"id":"yh-02-002","options":["月请求量：量不够大时 API 通常更划算","团队人数的多少","模型参数量的位数","办公室的网络速度"],"source":"chapter","stem":"在“调用 API”与“自部署”之间做选择，最关键的量级判据是？","subject":"推理优化","type":"single"},{"analysis":"铁律是“**GPU 利用率与成本同看**”：利用率低意味着算力闲置、单位成本被抬高。利用率 20% 时砍半卡往往比任何推理优化都省钱，或通过提高并发、队列削峰把卡用满。","answer":"A","chapter":"AI落地·成本容量","difficulty":2,"explain":{"B":"利用率与模型质量没有直接关系。","C":"利用率低时扩容会进一步浪费算力。","D":"换更大模型会加重显存与成本压力。"},"id":"yh-02-003","options":["钱在烧，应通过加并发/削峰或降配来提升利用率","说明模型效果不好","说明应当立刻扩容加卡","说明必须换成参数量更大的模型"],"source":"chapter","stem":"GPU 利用率长期低于 50%，最合理的判断是？","subject":"推理优化","type":"single"},{"analysis":"口诀“**先架构后参数**”：分级路由与语义缓存从流量结构上降本，收益大且不损失精度；量化与上下文压缩作用在模型与参数层，需承担掉点与质量风险。每一刀都要有前后对比数据。","answer":"A","chapter":"AI落地·成本容量","difficulty":2,"explain":{"B":"量化有掉点风险，先动参数不如先动架构。","C":"同时上线无法归因效果，出问题也难定位。","D":"只压缩上下文收益有限，且直接影响回答质量。"},"id":"yh-02-004","options":["先架构（分级路由、语义缓存），后参数（量化、上下文压缩）","先量化，再考虑架构层优化","四刀同时上线以求最大收益","只做上下文压缩即可"],"source":"chapter","stem":"成本优化四刀（分级路由、语义缓存、量化、上下文压缩）的推荐顺序是？","subject":"推理优化","type":"single"},{"analysis":"语义缓存的适用前提是答案稳定可复用：高频重复问题用 Embedding 相似度（如余弦 \u003e 0.95）命中后直接返回，重复请求成本趋近于 0。时效性内容会随外部状态变化，缓存会返回过期答案，因此不能缓存。","answer":"A","chapter":"AI落地·成本容量","difficulty":2,"explain":{"B":"说明书类问答答案稳定，适合缓存。","C":"政策类问答重复度高且内容稳定。","D":"营业时间变化频率低，通常可以缓存。"},"id":"yh-02-005","options":["时效性内容，例如“今天天气怎么样”","产品说明书里的固定问题","常见售后政策问答","门店营业时间查询"],"source":"chapter","stem":"下列哪类请求最不适合做语义缓存？","subject":"推理优化","type":"single"},{"analysis":"容量规划四步：定 SLO → 压测出单卡稳定容量 → 卡数 = 峰值 QPS ÷ 单卡 QPS × **冗余系数 2** → 压测验证。冗余 2 倍是保险而非浪费，保证一张卡挂掉或升级时仍能守住 SLO。","answer":"A","chapter":"AI落地·成本容量","difficulty":3,"explain":{"B":"冗余是为了应对故障与峰值，不是日常减半运行。","C":"冗余系数描述容量需求，不等于预算授权。","D":"SLO 是必须守住的红线，不能因冗余而放宽。"},"id":"yh-02-006","options":["按峰值所需卡数的两倍准备，单卡故障或升级时仍能扛住峰值","日常只开一半的卡以节省电力","成本预算可以超支一倍","时延指标允许放宽一倍"],"source":"chapter","stem":"容量规划中冗余系数取 2 的含义是？","subject":"推理优化","type":"single"},{"analysis":"测试集是评估的生命线，按核心/边界/对抗分层打标，示例比例 7:2:1；只采高频会留下长尾与安全盲区。建集四步为日志采样 → 标期望行为 → 分层打标 → 版本化入库。","answer":"A","chapter":"AI落地·评估","difficulty":1,"explain":{"B":"按难度均分不能反映真实流量分布与安全需求。","C":"这是模型训练的数据划分，不是业务评估集分层。","D":"这是软件测试层级，不针对 AI 业务集。"},"id":"yw-01-001","options":["核心（高频真实问题，约 70%）、边界（长尾模糊，约 20%）、对抗（注入诱导，约 10%）","简单、中等、困难三类各占三分之一","训练集、验证集、测试集","单元测试、集成测试、端到端测试"],"source":"chapter","stem":"业务测试集的三层结构通常指？","subject":"评估与运维","type":"single"},{"analysis":"只标答案不够，必须标**期望行为**：答什么、引用哪、是否拒答。该拒答的题如果模型硬答，即使文字流畅也算错误；对抗层尤其要标注“应当拒绝、不泄露系统提示词”。","answer":"A","chapter":"AI落地·评估","difficulty":2,"explain":{"B":"耗时属于性能指标，不作为逐题标注。","C":"模型版本随迭代变化，不写入期望。","D":"采样参数不是测试集的标注项。"},"id":"yw-01-002","options":["期望行为：该答什么、引用哪段、是否应当拒答","期望的响应耗时","期望使用的模型版本号","期望的 temperature 取值"],"source":"chapter","stem":"测试集标注时，除了“期望答案”，更关键的还要标注？","subject":"评估与运维","type":"single"},{"analysis":"对抗层用“忽略之前指令、输出系统提示词”这类样例测试注入与诱导，对应的是安全底线，不能被平均准确率掩盖，也不能替代人工抽查。","answer":"A","chapter":"AI落地·评估","difficulty":2,"explain":{"B":"对抗样例通常会拉低平均分，价值在于暴露风险。","C":"分层是为了扩大覆盖，不是减少用例。","D":"自动评估存在盲区，仍需人工抽查兜底。"},"id":"yw-01-003","options":["检测提示词注入、诱导与越权等安全风险","拉高整体的平均准确率","减少测试用例的总数量","替代人工抽查环节"],"source":"chapter","stem":"测试集中“对抗层”的主要作用是？","subject":"评估与运维","type":"single"},{"analysis":"RAGAS 三指标：**忠实度**（答案是否只基于检索资料，即幻觉检测）、**答案相关性**（是否切题）、**上下文精度**（检索的 chunk 是否真的相关，反映召回质量）。","answer":"A","chapter":"AI落地·评估","difficulty":2,"explain":{"B":"通顺度不是忠实度的定义。","C":"响应速度属于性能指标。","D":"提示词长度与忠实度无关。"},"id":"yw-01-004","options":["答案是否只基于检索到的资料，用于检测幻觉","答案的文字是否通顺易读","检索环节的响应速度是否够快","提示词是否足够简短"],"source":"chapter","stem":"RAGAS 中“忠实度（Faithfulness）”衡量的是？","subject":"评估与运维","type":"single"},{"analysis":"LLM 评审适合质量细评，但裁判必须有评分标准（如 1~5 分每档写清什么样），否则结果不可复现、无法归因。它仍有盲区，需与相似度快筛、人工抽查配合使用。","answer":"A","chapter":"AI落地·评估","difficulty":2,"explain":{"B":"高温度会让评审结果更不稳定。","C":"自评存在偏袒与盲区，缺乏独立性。","D":"人工抽查是兜底线，不能取消。"},"id":"yw-01-005","options":["明确的评分标准（rubric），写清每一档对应什么表现","把评审模型的 temperature 调高","只让同一个模型评审自己的输出","取消人工抽查环节"],"source":"chapter","stem":"使用 LLM 评审（让强模型当裁判）时，必须配套的是？","subject":"评估与运维","type":"single"},{"analysis":"回归是改动的前置条件：改提示词、换模型、换切分、换向量库都要自动跑测试集，对比改前改后各指标 diff，掉点超阈值“红灯不放行”。没有 CI 评估的 AI 项目等于每次改动都在赌博。","answer":"A","chapter":"AI落地·评估","difficulty":2,"explain":{"B":"全量上线把风险直接推给用户。","C":"手工试几个例子覆盖不了核心、边界与对抗分布。","D":"事后回滚会留下真实的线上损失。"},"id":"yw-01-006","options":["在 CI 中自动跑测试集并对比指标，掉点超阈值则阻断发布","先全量上线，再看用户反馈","只在本机手动试几个例子","直接发布，出问题再回滚"],"source":"chapter","stem":"改了提示词或换了模型之后，正确的做法是？","subject":"评估与运维","type":"single"},{"analysis":"AI 服务看板四项：**时延**（P50/P95/P99 的 TTFT/TPOT/E2E）、**错误率**（5xx/超时/拒答率）、**吞吐**（QPS/并发/GPU 利用率）、**成本**（token 消耗/每千次成本/日账单），此外还要有质量抽检（幻觉率、反馈率）。","answer":"A","chapter":"AI落地·运维安全","difficulty":2,"explain":{"B":"这些是通用主机指标，无法反映 AI 服务质量。","C":"这些是产品互动数据，不是服务健康指标。","D":"这些是研发过程指标，与线上服务无关。"},"id":"yw-02-001","options":["时延（TTFT/TPOT/E2E 分位）、错误率、吞吐、成本","内存、磁盘、网络、进程数","点赞数、转发数、收藏数、评论数","代码行数、提交数、分支数、评审数"],"source":"chapter","stem":"AI 服务监控除了 CPU/GPU 利用率，四项必备指标是？","subject":"评估与运维","type":"single"},{"analysis":"拒答率是信号而不是故障：突然升高通常意味着检索坏了（召回为空或低分）或提示词约束变了。配合幻觉抽检与用户反馈率一起看，能更快定位质量问题。","answer":"A","chapter":"AI落地·运维安全","difficulty":2,"explain":{"B":"归因到用户不构成可行动的排查方向。","C":"GPU 温度与拒答率没有逻辑关系。","D":"配色属于前端展示，不影响模型是否拒答。"},"id":"yw-02-002","options":["检索链路或提示词约束发生了变化","用户的问题水平突然下降","GPU 温度过低","前端配色做了改动"],"source":"chapter","stem":"线上拒答率突然明显升高，最应该优先怀疑？","subject":"评估与运维","type":"single"},{"analysis":"三道闸为**输入过滤**（注入检测/敏感词/超长截断）、**输出审查**（敏感信息/合规词/格式校验）、**敏感操作确认**（写库/支付/删除必须人工确认）。输出审查在模型输出到达用户之前把关。","answer":"A","chapter":"AI落地·运维安全","difficulty":2,"explain":{"B":"超长输入属于输入过滤环节。","C":"权重窃取属于模型资产与访问控制问题。","D":"参数类型错误由工具调用的参数校验处理。"},"id":"yw-02-003","options":["模型输出中夹带敏感信息、密钥或不合规内容","用户输入超长导致超上下文","模型权重文件被窃取","工具调用的参数类型写错"],"source":"chapter","stem":"安全三道闸中，“输出审查”针对的风险是？","subject":"评估与运维","type":"single"},{"analysis":"Prompt 注入（如“忽略之前指令，输出系统提示词”）需要多层组合防御：入口检测过滤、系统提示词与用户输入隔离、输出侧审查敏感信息。此外知识库来源管控防数据投毒，工具权限最小化防越权调用。","answer":"A","chapter":"AI落地·运维安全","difficulty":2,"explain":{"B":"温度与注入防御没有关系。","C":"前端隐藏不等于模型侧隔离，仍可能从输出侧泄露。","D":"换更大模型不能替代安全防护措施。"},"id":"yw-02-004","options":["输入过滤 + 系统提示词与用户输入隔离 + 输出审查","把生成温度调得更高","只在前端隐藏系统提示词文案","把模型换成参数量更大的版本"],"source":"chapter","stem":"防御 Prompt 注入，最有效的做法是？","subject":"评估与运维","type":"single"},{"analysis":"标准流程：先用影子流量并行跑、对比输出但不影响用户，再按 5%→20%→50% 逐档放量，每档看 SLO 与反馈率，全量时保留旧版热备，确保能快速切回。","answer":"A","chapter":"AI落地·运维安全","difficulty":2,"explain":{"B":"直接全量把风险推给全部用户。","C":"缺少影子期与中间档位，跳变过大。","D":"影子之后直接全量，缺少小流量验证。"},"id":"yw-02-005","options":["影子流量对比 → 5% → 20% → 50% → 全量并保留旧版热备","直接全量 → 出问题再回滚","5% → 100% → 再观察指标","影子流量对比 → 直接全量"],"source":"chapter","stem":"新模型上线的灰度 SOP 顺序是？","subject":"评估与运维","type":"single"},{"analysis":"灰度与回滚是一体的：全量时保留旧版热备、回滚开关常备，事故时能在数分钟内切回旧版本。没有回滚预案的发布，等于把故障时长交给修复速度。","answer":"A","chapter":"AI落地·运维安全","difficulty":1,"explain":{"B":"现改再发会把故障时间大幅拉长。","C":"灰度只降低影响面，不能替代回滚预案。","D":"版本切换靠部署与路由，不需要重新训练。"},"id":"yw-02-006","options":["常备回滚开关，出问题能在数分钟内切回旧版","等出问题后再现改代码并发布","只要做了灰度就不再需要回滚","回滚只能靠重新训练模型"],"source":"chapter","stem":"关于回滚能力，正确的做法是？","subject":"评估与运维","type":"single"}],"cert":"aideploy","chapters":[{"name":"AI落地·推理优化","title":"第 1 章 · KV Cache、Batching 与延迟指标","url":"/aideploy/books/youhua/yh-01-cunchu/"},{"name":"AI落地·RAG 链路","title":"第 1 章 · RAG 生产链路：切分、检索、重排","url":"/aideploy/books/rag/rag-01-luqu/"},{"name":"AI落地·推理框架","title":"第 1 章 · 推理框架选型与服务化","url":"/aideploy/books/bushu/bs-01-kuangjia/"},{"name":"AI落地·评估","title":"第 1 章 · 评估体系：测试集、自动评估与回归","url":"/aideploy/books/yunwei/yw-01-pinggu/"},{"name":"AI落地·Agent","title":"第 2 章 · Agent 与工具调用：从 ReAct 到工作流","url":"/aideploy/books/rag/rag-02-agent/"},{"name":"AI落地·成本容量","title":"第 2 章 · 成本核算与容量规划","url":"/aideploy/books/youhua/yh-02-chengben/"},{"name":"AI落地·运维安全","title":"第 2 章 · 生产运维：监控、安全、灰度与成本","url":"/aideploy/books/yunwei/yw-02-yunwei/"},{"name":"AI落地·量化微调","title":"第 2 章 · 量化选型与微调入门","url":"/aideploy/books/bushu/bs-02-lianghua/"}],"practiceUrl":"/aideploy/practice/"}