适用读者：面 LLM 应用/Agent 岗的人；已有 S20/S21 基础，需要"面试口径"的人。
前置：S20（大模型应用）、S21（Agent 工程）、S25-J14。
覆盖旧文：3507–3569（63 篇编号题，约 39 万字符）→ 按题族归并为 5 族。
扩展点：E-S25-047（题族归并法：把 63 题压成 5 条主线）、E-S25-048（RAG 五问的标准答法）、E-S25-049（Agent 高可用与延迟的分层策略）。
下一篇：S25-J16 · LLM 与 Agent 题库（下）：速答与模型原理。
1. 一句话结论
63 道编号题其实是 5 条主线：RAG 流水线、Agent 运行时、工程化（网关/调度/高可用）、模型原理、评估。按主线答，一题能带出五题；按题号背，换个问法就崩。
出处：
A-3507–A-3569（LLM/Agent 面试题库）。
2. 题族归并（E-S25-047）
| 族 | 代表题号 | 主线一句话 |
|---|---|---|
| A · RAG | 3540/3541/3554/3556/3558/3559/3560/3561/3562/3563/3564/3565/3566/3567 | 检索质量决定上限，提示词只决定下限 |
| B · Agent 运行时 | 3510/3513/3522/3523/3524/3529/3530/3533/3539/3543/3512/3551 | 循环 + 状态 + 工具 + 记忆 |
| C · 工程化 | 3519/3532/3534/3536/3537/3546/3547/3548/3549/3525/3528 | 延迟、限流、发布、排障 |
| D · 模型原理 | 3552/3568/3569/3567 | 注意力、位置编码、范式 |
| E · 评估 | 3556/3559/3567 | 检索看召回，生成看忠实 |
3. RAG 五问（E-S25-048）
3.1 切块（3540）：大小与重叠怎么定
| 参数 | 经验起点 | 依据 |
|---|---|---|
| chunk size | 300–800 tokens | 太小丢上下文，太大稀释相似度 |
| overlap | 10–20% | 防答案被切断 |
| 结构优先 | 按标题/段落切 | 语义边界 > 固定长度 |
加分点：父文档召回——小块检索、大块喂给模型（解决"切太小丢上下文、切太大不精确"的矛盾）。
3.2 嵌入模型怎么选（3541）
看四个指标：检索命中率（MTEB/自建集）、向量维度与成本、语言覆盖（中文能力）、最大输入长度。判据：必须在你自己的数据上测——公开榜单与业务分布常常不一致。
3.3 检索不到怎么排查（3558）
① 文档在不在库里（切块/入库失败？）
② query 与文档表述差异（换说法就查不到 → 语义鸿沟）
③ 向量模型是否匹配（同一模型建库与查询）
④ topK 太小 / 过滤条件过严
⑤ 排序问题（召回有但排到后面 → 加 Rerank）
3.4 语义鸿沟怎么解（3564）
Query 改写（LLM 扩写/多查询）、HyDE（先生成假答案再检索）、混合检索（稠密+稀疏）、字段加权、Rerank 重排。
3.5 评估（3556/3567）
| 阶段 | 指标 |
|---|---|
| 检索 | Recall@k、MRR、命中率、上下文精确率 |
| 生成 | 忠实度（Faithfulness）、答案相关性、上下文利用率 |
| 端到端 | 人工打分、LLM-as-a-Judge、RAGAS 三件套（faithfulness / answer relevancy / context precision） |
判据：RAG 的问题 80% 出在检索，20% 出在提示词；先测 Recall@k 再谈生成。
4. Agent 运行时六问
| 问 | 答 |
|---|---|
| 什么是 Agent（3513） | LLM + 上下文 + 工具 + 循环，关键在"能自主决定下一步动作" |
| 规划方法（3530/3541） | ReAct（边想边做）、Plan-and-Execute（先规划后执行）、ToT/树搜索、反射式重规划 |
| 记忆设计（3522/3524） | 短期=上下文窗口+压缩；长期=外部存储+检索（见 S21-J10） |
| 记忆覆盖（3523） | 写时去重/合并、读时按相关性排序、定期整合遗忘 |
| 多 Agent 协作（3512/3551） | 分工（管理者/对等/去中心化）+ 是否引入新信息（S21-J17） |
| 安全可控（3533） | 权限最小化、审批点、沙箱、输出校验、可审计轨迹 |
| 工具调用可靠性（3543） | schema 校验 + 重试 + 降级 + 参数示例（S21-J11） |
| 多轮对话设计（3515） | 会话状态机 + 槽位填充 + 超时/重连 + 上下文压缩 |
5. 工程化：延迟、限流、发布（E-S25-049）
5.1 P95 延迟怎么降（3536/3528）
| 手段 | 效果 | 代价 |
|---|---|---|
| 快慢分离 | 轻任务小模型/规则，重任务才上大模型 | 路由复杂度 |
| 流式输出 | 感知延迟大幅下降（首 token 快） | 不确定总时长 |
| 并行化 | 检索与生成、多工具并行 | 依赖编排能力 |
| 缓存 | 前缀缓存（Prompt Caching）省 prefill | 命中率取决于前缀稳定性 |
| 压缩上下文 | 减少输入 token | 可能丢信息 |
| 预取/预热 | 高频问题预生成 | 命中率与存储成本 |
RT 预算示例：路由 20 ms + 检索 80 ms + 首 token 400 ms + 生成 800 ms ≈ 1.3 s；若 SLA 是 1.5 s，优化重点在首 token 与检索并行。
5.2 分层超时与熔断（3537）
连接超时 1 s / 单次调用 30 s / 整体链路 60 s
检索失败 → 降级为无检索直答
模型超时 → 换备用模型 / 返回已生成部分
连续失败 N 次 → 熔断该模型，走兜底
判据："熔断模型不是熔断业务"——模型不可用时，业务要有"降级回答 + 转人工"的路径。
5.3 发布与启停（3532/3534）
- 发布期不报错：新版本先"影子流量"验证 + 灰度比例 + 双版本共存（提示词/模型都可版本化）
- 启停设计：优雅停机——停止接新请求 → 等在途完成（上限 30 s）→ 清理长连接
- 内存泄漏排查（3525）：会话缓存无 TTL、事件监听未注销、向量库客户端连接未释放、流式响应未关闭
5.4 网关与调度（3548/3549）
| 组件 | 职责 |
|---|---|
| Gateway | 统一鉴权、配额与限流、模型路由、重试与降级、成本计量、审计 |
| 调度器 | 队列与优先级、批处理（提高吞吐）、GPU 复用、超时与抢占 |
判据：网关是"成本与权限"的闸门，调度器是"吞吐与延迟"的调节阀——别混成一个组件。
5.5 高并发下的 LLM 限流（3546/3519）
三层：入口 QPS 限流 → 用户/租户配额（Token 预算）→ 模型侧并发上限。关键：按 token 而非请求数 计量，因为长 prompt 的成本差异是数量级的。
6. 模型原理三问（简答口径）
| 问 | 答 |
|---|---|
| 自注意力（3569） | softmax(QKᵀ/√d)V；并行 + 全局感受野，比 RNN 的串行更适合长序列；代价是 O(n²) |
| 位置编码（3552） | 正弦/可学习/RoPE（旋转位置编码，相对位置、可外推）；没有位置编码则词序信息丢失 |
| ReAct vs CoT（3568） | CoT 只在"想"，ReAct 在"想 + 做 + 观察"循环里更新 |
判据："为什么比 RNN 好"要答并行性与长依赖，不要只答"效果好"。
7. 反例：五种"背了会被反问倒"的答法
| 说法 | 问题 |
|---|---|
| "RAG 就是向量检索 + 拼提示词" | 缺切块/重排/评估，答不到三层 |
| "换个更大的模型就好了" | 未定位是检索问题还是生成问题 |
| "Agent 就是 Function Calling" | 缺循环、状态、记忆与终止条件 |
| "加缓存就快了" | 前缀缓存要求前缀稳定；动态内容无命中 |
| "多 Agent 一定更强" | 不引入新信息时等算力持平甚至更差 |
8. 自测
- 63 题归并成哪五族？各族主线一句话？
- 切块大小与重叠的经验值？父文档召回解决什么矛盾？
- RAG 检索不到的五步排查？
- 把 P95 降下来的六种手段，各付什么代价？
- 为什么 LLM 限流要按 token 而不是请求数？
答案
- RAG / Agent 运行时 / 工程化 / 模型原理 / 评估。
- 300–800 tokens、重叠 10–20%；解决"切小丢上下文、切大不精确"。
- 入库 → query 差异 → 模型匹配 → topK/过滤 → 排序。
- 快慢分离、流式、并行、缓存、压缩、预取。
- 长 prompt 与短 prompt 成本差数量级，按请求数会放过高消耗调用。
9. 下一篇
S25-J16 · LLM 与 Agent 题库（下）：速答与模型原理 —— 3731–3788 的 63 道短答题（Agent 定义、上下文工程、KV Cache/前缀缓存、MoE、benchmark、产品对比）的速答卡。