AI Agent / LLM 应用工程师面试题与答案（2026-05）

调研日期：2026-05-02（K 章节增补于 2026-05-14） 目标读者：求职者（应届到 staff 级）+ 招聘方覆盖：11 大分类 / 92 道题 / 难度分级 / 含一手论文 + Anthropic / OpenAI / DeepSeek 官方资料

Executive Summary

本报告按 11 大分类整理 AI Agent / LLM 应用工程师面试题，每题给：

分类	题数	难度分布	重点
A. LLM 基础	11	1⭐ 8⭐⭐ 2⭐⭐⭐	Transformer / RoPE / KV cache / 长上下文 / 推理优化 / Prefill·Decode
B. 训练 / 微调	10	1⭐ 7⭐⭐ 2⭐⭐⭐	SFT / DPO / GRPO / LoRA / R1 涌现
C. 提示词工程	9	1⭐ 7⭐⭐ 1⭐⭐⭐	CoT / Self-Consistency / ReAct / 自动 prompt 优化
D. RAG	10	1⭐ 7⭐⭐ 2⭐⭐⭐	Hybrid / Reranker / GraphRAG / Self-RAG / RAGAS
E. Agent	12	1⭐ 6⭐⭐ 5⭐⭐⭐	核心分类：6 patterns / 多 agent / 失败模式 / harness
F. Memory	8	1⭐ 5⭐⭐ 2⭐⭐⭐	MemGPT / mem0 / progress 文件 / memory corruption
G. 系统设计	8	0⭐ 1⭐⭐ 7⭐⭐⭐	客服 / coding / 搜索 / LLM 网关 / 高并发 / 成本 / 沙箱 / 闭环
H. 评估	6	0⭐ 2⭐⭐ 4⭐⭐⭐	judge bias / pairwise / benchmark hack / 漂移
I. 安全 / 护栏	6	0⭐ 1⭐⭐ 5⭐⭐⭐	OWASP / Prompt Injection / NeMo Guardrails / EU AI Act
J. 行为题 / 实战	7	0⭐ 2⭐⭐ 5⭐⭐⭐	Hashimoto harness 闭环 / 0-1 落地路线
K. Agent 评测	5	0⭐ 2⭐⭐ 3⭐⭐⭐	通用 benchmark / trajectory 三层粒度 / tool-use / 生产监控 / 业务领域 Agent 评测

学习路径建议： - 应届 / 初级：A + B + C + 部分 D，能讲清核心概念即可 - 3-5 年（中级）：全部 A-F + 部分 G/H/K，要有项目案例 - 5-10 年（资深 / staff）：全部 11 类，G/J/K 是主战场，要能从架构层讨论取舍 - 架构师 / staff+：J 行为题决定差异，必须有 Hashimoto harness 思维 + 量化落地案例

A. LLM 基础（11 题）

A1. ⭐⭐ 为什么 Transformer 用 Layer Norm 而不是 Batch Norm？

核心答案：LayerNorm 沿 feature 维度对单样本归一化，与 batch 无关，天然支持变长序列与单条推理——这正是 Transformer 不用 BatchNorm 的核心原因。

BatchNorm 为什么不适合 NLP：BatchNorm 沿 batch 维度对每个特征做归一化，依赖 batch 内统计量。NLP 场景下：

来源：Vaswani et al. 2017《Attention Is All You Need》https://arxiv.org/abs/1706.03762；Zhang & Sennrich 2019《Root Mean Square Layer Normalization》

A2. ⭐ 多头注意力的"多头"到底有什么用？单头加大维度行不行？

核心答案：单头只能产生一种"关系视角"，多头注意力把 d_model 拆成 h 份独立投影 Q/K/V，是 h 个低秩注意力的混合，表达力严格强于同参数量的单头。

来源：Vaswani 2017；Ainslie et al. 2023《GQA: Training Generalized Multi-Query Transformer》https://arxiv.org/abs/2305.13245

A3. ⭐⭐ RoPE 相比绝对位置编码的优势？为什么外推还是会崩？

核心答案：RoPE 把位置编码作用在 Q/K 上而非 embedding 上，用旋转矩阵让注意力得分天然依赖相对距离；但训练上下文窗口外的高频分量旋转角度未见过，导致外推崩溃，需要 NTK/YaRN 等缩放方案修复。

核心机制：RoPE（Su et al. 2021）将位置 m 表示为旋转矩阵 R_m，使得 <R_m·q, R_n·k> = f(q, k, m-n)，天然编码相对位置。

为什么外推会崩：RoPE 高频分量在训练上下文外旋转角度落入未见区域，注意力分布塌缩，所以纯外推 2k→32k 会崩。

A4. ⭐⭐⭐ vLLM 的 PagedAttention 解决了什么问题？为什么吞吐能涨 24 倍？

核心答案：PagedAttention 借鉴 OS 虚拟内存把 KV cache 切成固定大小 block 管理，解决了传统连续显存分配的三类碎片问题，配合 continuous batching 让吞吐相对 HuggingFace TGI 提升 2-4×、相对 FasterTransformer 24×。

问题背景：传统推理为每个 request 预分配 max_seq_len 的 KV cache 连续显存，导致三类碎片：

核心机制：把 KV cache 切成固定大小 block（如 16 token），每个序列维护一个 block table（逻辑→物理映射），与 OS 虚拟内存原理一致。

延伸：SGLang 的 RadixAttention 进一步把所有历史前缀组织成 radix tree 自动缓存复用，对 agent 多轮场景尤其有效——可视为 PagedAttention 的进化版。

来源：Kwon et al. 2023《Efficient Memory Management for LLM Serving with PagedAttention》（SOSP’23）https://arxiv.org/abs/2309.06180

A5. ⭐⭐ Lost in the Middle 是什么？工程上怎么缓解？

核心答案：Lost in the Middle（Liu et al. 2023）指长上下文窗口中放在中间位置的 gold passage 准确率呈 U 形塌陷，10+ documents 时可能低于 closed-book 基线；工程上靠重排、多轮检索、原生长上下文模型缓解。

现象：在长上下文 QA 中，把 gold passage 放在 prompt 开头或结尾，模型准确率高；放中间则显著下降，呈 U 形曲线，10+ documents 时中间位置准确率可能低于无上下文（closed-book）基线。

延伸：RULER 基准：Hsieh et al. 2024（NVIDIA）提出的更严苛长上下文基准，包含 needle-in-haystack、变量追踪、多跳 QA 等 13 类任务，比纯 NIAH 更能反映真实能力。

A6. ⭐⭐ Speculative Decoding 原理？什么场景收益最大？

核心答案：Speculative Decoding 用小 draft model 一次性自回归生成 K 个 token，target model 一次 forward 并行验证，rejection sampling 保证输出分布与原模型一致；draft/target 分布相似且 target memory-bound 时收益最大。

主流变体：EAGLE-2/3、Medusa（多个 LM head 并行预测）、Llama 3.1 self-speculative。

场景收益：代码生成、确定性强的任务接受率高（70-90%）；开放生成接受率低（30-50%）。

A7. ⭐ Prefix Caching 与 KV Cache 的区别？

核心答案：KV Cache 是单 request 内部 decode 阶段复用 K/V 的优化；Prefix Caching 是跨 request 复用相同前缀（system prompt、few-shot、agent 历史）的 prefill 优化，能把 TTFT 降 10-100×。

场景收益：在 agent / RAG / 多轮对话场景，system prompt 通常 1-4k token、几乎所有请求共享，prefill 阶段 TTFT 可下降 10-100×。

工程取舍：缓存 block 占显存，命中率低时反而拖慢，需要监控 cache hit rate。

A8. ⭐⭐⭐ FlashAttention 1/2/3 各解决了什么？为什么 H100 上 FA3 能再快 1.5-2×？

核心答案：FlashAttention 系列通过 tiling + online softmax 把标准 attention 显存从 O(N²) 降到 O(N)；FA3 针对 H100 的 WGMMA / TMA / 原生 FP8 三项 Hopper 特性，BF16 下达 740 TFLOPS（75% 峰值），比 FA2 快 1.5-2×。

问题背景：标准 attention 显存复杂度 O(N²)（要存 N×N 的 attention matrix），是长序列瓶颈。

FA1（Dao 2022）：tiling + online softmax，把 Q/K/V 分块加载到 SRAM 计算，不实例化完整 attention matrix，显存降到 O(N)，速度也快——因为 attention 是 memory bound，少读 HBM 就快。

FA2（Dao 2023）：优化了并行划分（按 seq_len 而非 batch 并行）和 warp-level 调度，A100 上达 ~50-72% 峰值 FLOPs。

性能数字：BF16 下 H100 740 TFLOPS（75% 峰值），比 FA2 快 1.5-2×；FP8 接近 1.2 PFLOPS。

A9. ⭐⭐ Continuous Batching vs Static Batching？

核心答案：Static batching 等齐整个 batch 才退出，长短请求混合时 GPU 利用率经常 <30%；continuous batching（ORCA 2022）按 token 级调度，配合 PagedAttention 吞吐相比 static 提升 5-23×。

Static batching 的痛点：等齐 batch_size 个 request，一起 prefill+decode 直到全部结束。长短请求混在一起时，短请求结束后该 slot 空闲到最长请求结束（"head-of-line blocking"），GPU 利用率经常 <30%。

Continuous batching 机制：也叫 in-flight batching（Yu et al. ORCA 2022 提出），按 token 级别调度：

工程取舍：prefill 与 decode 混在一起会产生延迟抖动。chunked prefill 把长 prefill 切成 token 块、与 decode 交错调度可缓解，是 vLLM v0.6+ 默认。

来源：Yu et al. 2022《Orca: A Distributed Serving System for Transformer-Based Generative Models》（OSDI）

A10. ⭐⭐ 上下文越长效果越好吗？工程上 128k 真能用吗？

核心答案：理论上下文窗口与有效窗口差距很大，RULER 显示宣称 128k/200k 的多数模型 32k 之外性能急剧下降；工程上默认走 RAG，复杂多跳推理建议 32k 内最稳。

有效窗口的现实：RULER 基准显示宣称 128k/200k 的多数模型在 32k 之外性能急剧下降，仅 GPT-4、Claude 3.5、Gemini 1.5 Pro 在 64k+ 仍稳定。

A11. ⭐⭐ LLM 推理为什么分 Prefill 和 Decode 两阶段？两者瓶颈有何不同？

核心答案：prefill / decode 是自回归推理的两个阶段——prefill 把整段 prompt 一次性并行算出 KV cache 并吐出第一个 token，是 compute-bound（算力受限），决定 TTFT；decode 逐个 token 自回归生成、每步只算 1 个 token 却要反复读全部 KV cache 与权重，是 memory-bound（显存带宽受限），决定 TPOT。两阶段特性相反，所以现代推理框架把它们当作不同的优化对象。

维度	Prefill	Decode
并行度	高（一次处理所有 token）	低（一次 1 个 token）
瓶颈	算力（compute-bound）	显存带宽（memory-bound）
GPU 利用率	高	低
延迟指标	TTFT	TPOT / ITL

为什么是推理优化的核心：两阶段特性差异巨大，工程上才衍生出一系列优化手段：

加分句：prefill 决定 TTFT、decode 决定 TPOT，二者在 SLA 上往往要分别定指标、分别优化，所以 vLLM / SGLang / TensorRT-LLM 都把这两阶段当作独立的优化对象。

B. 训练 / 微调（10 题）

B1. ⭐ 预训练、后训练、任务微调三者怎么拆分？

核心答案：三阶段按“目标—数据—成本”递减切分：预训练学通用知识（万亿 token、占 95%+ 成本）；后训练做对齐（SFT + DPO/PPO/GRPO，百万-千万样本）；任务微调适配下游领域（几千-几万样本，多用 LoRA）。

工程经验：领域微调优先 LoRA + base 还是 chat 模型，要看是否需要保留指令遵循能力——保留就基于 chat、纯做风格/格式适配；做强领域知识注入则基于 base 重新做完整后训练栈。

B2. ⭐⭐ DPO vs PPO 的核心区别？为什么近两年 DPO 更流行？

核心答案：PPO 需要载入 actor/ref/critic/RM 四个模型且超参敏感；DPO 从数学上推导出闭式最优 policy，把偏好对当作监督式损失训练，仅需 policy + ref 两个模型，训练栈与 SFT 一致——这是 Llama-3、Qwen2 等纷纷转向 DPO 的根因。

PPO 路径痛点：PPO（RLHF 经典路径）先训 reward model（RM），再用 RM 给 policy 打分，用 PPO 做 actor-critic 更新，需同时载入 actor、ref、critic、reward 四个模型，显存 ≥4× 单模型，超参敏感（KL 系数、clip ratio、advantage 归一化），训练不稳定。

DPO 核心机制：DPO（Rafailov et al. 2023）从数学上证明：在 Bradley-Terry 偏好模型 + KL 约束下，最优 policy 有闭式解，可直接用偏好对 (chosen, rejected) 做监督式损失：-log σ(β(log π(y_w)/π_ref(y_w) - log π(y_l)/π_ref(y_l)))。

生态现状：Llama-3、Qwen2 后训练主路径都是 DPO 或其变种（IPO、KTO、SimPO）。

B3. ⭐⭐⭐ DeepSeek R1 的 GRPO 为什么有效？相比 PPO 省了什么？

核心答案：GRPO 去掉 critic 网络，用组内 reward 均值/标准差做 advantage 归一化，显存省一半、方差更低，配合 RLVR 可验证奖励，让 R1-Zero 从 base 模型纯 RL 涌现 long CoT。

核心创新：GRPO（Group Relative Policy Optimization，DeepSeek-Math 2024 提出，R1 验证）的关键创新是去掉 critic（value 网络），对同一 prompt 采样 G 个 response（典型 G=64），用组内 reward 的均值/标准差做 advantage 归一化：A_i = (r_i - mean(r)) / std(r)，再做 PPO-like 的 clipped objective + KL 正则。

R1 实证：R1-Zero 直接从 base 模型纯 RL（无 SFT）跑出 reasoning 行为：长 CoT、自我验证、aha moment，AIME 从 15.6%→71.0%。R1 正式版加了少量 cold-start SFT 让格式更稳定。

B4. ⭐⭐ LoRA 与 QLoRA 显存怎么算？为什么 QLoRA 能在单卡 24G 跑 65B？

核心答案：全参微调显存 ≈ 16-20× 参数量字节；LoRA 冻结原权重只训低秩 adapter，但权重仍占 fp16 显存；QLoRA 用 4-bit NF4 量化把冻结权重再压 4×，加 Double Quantization 和 Paged Optimizer，65B 单卡可跑。

实测：65B 模型 QLoRA 约 33GB，单 A100-48G 或双 RTX 3090 可跑，效果与 fp16 LoRA 几乎无差。

工程取舍：QLoRA 训练慢 30-40%（反量化开销），推理需 merge 回原精度或用 GPTQ/AWQ 重新量化部署。

B5. ⭐⭐ GPTQ / AWQ / FP8 对比？部署该选哪个？

核心答案：GPTQ 早、生态全但对激活分布敏感；AWQ 保护 1% salient 通道精度更稳，已成 vLLM 默认 INT4 方案；FP8 在 H100/H200 原生支持，几乎无精度损失且训练推理统一。

B6. ⭐⭐ 蒸馏在 LLM 时代和过去 BERT 时代有什么不一样？

核心答案：BERT 时代靠 logit/hidden state 对齐做白盒蒸馏，工程重；LLM 时代主流是数据蒸馏（黑盒）——大模型直接生成 (prompt, response) 数据让小模型 SFT，训练栈与微调一致，且可跨架构传递 reasoning 能力。

BERT 时代（白盒蒸馏）：DistilBERT、TinyBERT 用 student 模仿 teacher 的 logits（KL 散度）+ hidden state（MSE）+ attention map，需配对前向、对齐层数，工程重。

LLM 时代主流（数据蒸馏 / 黑盒蒸馏）：用大模型生成大量高质量 (prompt, response) 数据，小模型直接 SFT。典型案例：

混合做法：on-policy distillation——student 自己采样、teacher 打分纠正，效果介于 SFT 和 RL 之间。

实证效果：R1-Distill-Qwen-32B 在 AIME 上 72.6%，超过 o1-mini，证明蒸馏可以传递 reasoning 能力。

B7. ⭐ SFT 数据量到底要多少？数据质量如何评估？

核心答案：SFT 数据量按目标分档（500-5000 做风格、1-10 万做领域知识、百万级做完整 instruct tuning），但 LIMA 证明 1000 条精选样本就能让 65B base 接近 GPT-4 对话质量——宁少而精。

LIMA 实证：Zhou et al. 2023 证明 1000 条精选样本即可让 65B base 达到接近 GPT-4 的对话质量——“Less Is More for Alignment”。

工程取舍：宁少而精——脏数据带来的伤害比缺数据更大。

B8. ⭐⭐ 灾难性遗忘怎么解决？

核心答案：灾难性遗忘是微调后通用能力下降的现象，根因是参数被新任务拉偏；缓解组合是 LoRA + 混入 5-30% 通用数据 + 小学习率短训练 + 持续 eval，必要时叠加 EWC、replay、Model souping。

现象与机制：在领域数据上微调后，通用能力（写作、数学、多语言）显著下降。机制：参数被新任务 loss 拉走，原本编码通用知识的方向被覆盖。

生产推荐组合：LoRA r=64 + 20% 通用数据混入 + lr=2e-5 + 1 epoch + 持续 eval MMLU/MT-Bench 监控。

来源：Kirkpatrick et al. 2017《Overcoming catastrophic forgetting》（EWC）

B9. ⭐⭐ RLVR（DAPO 等）解决了什么 RLHF 痛点？

核心答案：RLVR（RL with Verifiable Rewards）用程序判定 0/1 奖励替代 RM，消除了 RLHF 的标注贵、reward hacking、偏好噪声三大痛点；DAPO 在 GRPO 基础上加 Clip-Higher、Dynamic Sampling 等四项工程改进，是当前 SOTA 开源 RLVR 算法。

RLVR 核心思路：在数学、代码、形式逻辑等可自动验证的任务上，直接用程序判定 reward（答案匹配、单测通过、定理证明器验证），0/1 信号，无 RM。

DAPO 改进（Yu et al. 2025 ByteDance，开源 SOTA RLVR 算法，相对 GRPO）：

B10. ⭐⭐⭐ 为什么 R1 能从 base 模型纯 RL 涌现 long CoT？

核心答案：base 模型能力门槛 + verifiable reward + GRPO 稳定性三者协同——base 已在预训练阶段见过海量推理数据，可验证奖励逼出真推理，GRPO 让长 horizon 训练稳定，于是 self-reflection、回溯、aha moment 自发涌现。

工程意义：reasoning 能力从“标注教出来”转向“RL 自激发”，扩展性好得多。

C. 提示词工程（9 题）

C1. ⭐ CoT 为什么有效？什么模型规模才会出现？

核心答案：CoT（Wei et al. 2022）让模型显式生成推理步骤再给答案，本质是把复杂多步推理”展开”到 token 序列中——属于涌现能力，只有 60B+ 规模才显著生效。

核心机制：每个 token 的生成都基于前序 token，相当于把问题分解为一系列单步推理。原 paper 关键发现：CoT 是涌现能力，<10B 模型上几乎无效甚至变差，60B+ 才显著提升，PaLM-540B 上 GSM8K 从 17.9%→56.9%（CoT 单独）；叠加 self-consistency 后到 74%+。

演进：现代模型（GPT-4o/Claude/Gemini）已默认 CoT，零样本 “Let’s think step by step”（Kojima 2022）就能触发。R1/o1 后，长 CoT（数千 token 含回溯/验证）由 RL 训出而非 prompt 触发。

C2. ⭐⭐ Self-Consistency 原理？相对 CoT 何时收益最大？

核心答案：Self-Consistency（Wang et al. 2022）对同一问题以 temperature>0 采样 N 条不同 CoT 路径，对最终答案做 majority vote——正确答案在多条独立推理路径下应当一致，多数投票能放大正确信号。

收益数据：GSM8K 上比 greedy CoT 提升 ~17 个百分点（PaLM 55%→74%）。

变体与演进：universal self-consistency（用 LLM judge 选最一致答案）。R1/o1 时代趋势是把 self-consistency 内化进训练。

C3. ⭐⭐ ToT 相比 CoT 的核心区别？什么任务才值得用？

核心答案：CoT 是线性单链推理——一条路走到底错了无法回头；ToT（Tree of Thoughts，Yao et al. 2023）把推理建模为树搜索，可回溯剪枝，但成本飙升 2 个数量级。

核心机制：每步生成多个候选”thought”，由 LLM 自评估每个 state 的价值（promising / sure / impossible），用 BFS 或 DFS 展开，可回溯剪枝。

收益数据：在 Game of 24 上，GPT-4 CoT 4%、ToT 74%；creative writing、mini crosswords 等也大幅提升。代价：每个问题 LLM 调用数从 1 翻到 50-200，成本和延迟暴增 2 个数量级。

延伸：生产实践用 MCTS + LLM（AlphaCode 2、AlphaGeometry）是 ToT 的工业级版本。R1 后 long CoT 内置回溯，ToT 的相对价值下降。

C4. ⭐⭐ ReAct 的核心是什么？解决了 CoT 没解决的问题？

核心答案：ReAct（Yao et al. 2022）= Reasoning + Acting 交错——把推理拆成 Thought → Action → Observation 循环，把模型不知道的事实外化给工具，是现代 agent 框架的概念原型。

问题背景：CoT 只在模型内部 token 推理，无法访问外部世界，幻觉无法被纠正。

核心机制：模型先 “Thought: 我需要查 X”，输出 “Action: search[X]”，工具执行后把结果作为 “Observation: …” 喂回 prompt，再下一轮 Thought。

地位：ReAct 是现代 agent 框架（LangChain、AutoGPT、Claude tool use、OpenAI function calling）的概念原型。HotpotQA 上比纯 CoT 提升 ~10 个百分点，幻觉率下降一半。

C5. ⭐⭐ Self-Refine 和 Reflexion 区别？

核心答案：两者都是”模型自我反思修正”，但层次不同——Self-Refine 是单次任务内迭代、纯靠模型自评；Reflexion 是跨 episode 的”言语强化学习”、有外部 verifier 信号。

Self-Refine（Madaan et al. 2023）：单次任务内的迭代——generate → self-feedback → refine，全在一个 trajectory 里循环 N 轮，无外部 reward 信号、无跨任务记忆。在 7 个任务上平均提升 20%。

Reflexion（Shinn et al. 2023）：跨 episode 的”言语强化学习”——agent 在一次任务失败后（由外部 verifier 给二元 reward），用 LLM 把失败原因总结成自然语言”lesson”存入 episodic memory，下一次任务时把 lesson 加进 prompt 影响行为。在 HumanEval 上 GPT-4 Reflexion 91%，超过 GPT-4 baseline 80%。

工程实践：常组合使用——每 episode 内 Self-Refine + 跨 episode Reflexion。

C6. ⭐ Few-shot vs Zero-shot 怎么选？

核心答案：先 zero-shot baseline，eval 失败后再加 few-shot example 定向修复——别一上来就堆 example。

经验法则：先 zero-shot baseline，eval 失败后再加 example 定向修复。

C7. ⭐⭐⭐ Prompt Injection 有哪些攻击面？防御纵深怎么做？

核心答案：Prompt Injection 没有 100% 解（Simon Willison 结论），必须按”LLM 不可信”做系统设计，通过多层防御纵深降低风险。

根本结论（Simon Willison）：prompt injection 没有 100% 解，必须按”LLM 不可信”做系统设计。

C8. ⭐⭐ DSPy / OPRO / APE 自动 prompt 优化各是什么思路？

核心答案：APE 用 LLM 当 prompt 生成器；OPRO 把 LLM 当 optimizer 迭代爬山；DSPy 是”prompt 的 PyTorch”——把 prompt 工程从手工调字变成”写程序 + 编译”。

对比选择：研究/一次性任务用 APE/OPRO；生产 pipeline、需要可维护和持续优化用 DSPy；纯交互调优仍依赖人工 + eval set。

C9. ⭐⭐ Anthropic《Building Effective Agents》对 agent 设计提出了什么核心原则？

核心答案：Anthropic 2024 年这篇 blog 的核心立场：先用最简单的方案，能不上 agent 就别上——把 LLM 系统分成 workflow 和 agent 两类，多数生产场景应该用 workflow。

何时上 agent：仅在任务步数无法预知、需要环境交互、错误成本可承受时使用。

D. RAG（10 题）

D1. ⭐ RAG 的标准 pipeline 是什么？每个阶段的瓶颈在哪？

核心答案：标准 RAG pipeline = Ingestion + Retrieval + Generation 三段，每段都是独立工程问题，生产 RAG ≠ "embedding + 向量库 + LLM"——它是一个工程系统，每段都要单独评估和迭代。

D2. ⭐⭐ 切分策略对比：fixed / semantic / late chunking 怎么选？

核心答案：Chunking 策略五种主流方案各有取舍，经验是先用 recursive structural 做 baseline，专题场景再上 contextual / late chunking。

D3. ⭐⭐ 2026 年 embedding 模型怎么选？BGE-M3 / Cohere v4 / Voyage 3 / OpenAI text-3 取舍？

核心答案：Embedding 选型按"语言 / 部署形式 / 模态"分四档；关键陷阱：MTEB 分数有版本差异（v1 / v2 / MMTEB），不同模型挂的版本不一样，直接横比是误导，自家场景必须重测。

D4. ⭐⭐ Hybrid search（dense + BM25）为什么比单 dense 好？怎么融合？

核心答案：Hybrid search 用 dense + BM25 互补——dense 擅长语义近似，BM25 补罕见词 / 精确匹配 / 专有名词 / 数字的洞，召回率比单 dense 提升 5-15 个百分点。

为什么互补：dense embedding 擅长语义近似（"医生" ≈ "doctor"），但对罕见词、精确匹配、专有名词、数字经常失效（embedding 把它们压到稠密空间会丢失）。BM25（基于词频 + IDF）刚好补这个洞——精确词命中、稀有词高权重。生产 RAG dense + BM25 召回率比单 dense 提升 5-15 个百分点（多个 paper 数据）。

实证：Anthropic Contextual Retrieval 的实验：单 embedding → +contextual embedding → +contextual BM25 → +rerank，retrieval 失败率从 5.7% → 4.0% → 3.7% → 1.9%，呈阶梯式提升。

D5. ⭐⭐ Reranker 是什么？为什么 cross-encoder 比 bi-encoder 好那么多？

核心答案：Reranker 用 cross-encoder 做 query-doc 拼接 + 全层 self-attention 交互，相关性建模比 bi-encoder（embedding 双塔）强 20-40%，代价是慢 100×，所以只用来对召回 top-100 精排到 top-10。

生产用法：bi-encoder 召回 top-100 → cross-encoder rerank 到 top-10 → 喂 LLM。这是性价比最优组合：召回快、精排准、context 短。

踩坑：reranker 能力上限取决于召回——召回 top-100 里没有相关文档，rerank 也救不了；reranker 不能替代召回，只能锦上添花。

D6. ⭐⭐⭐ GraphRAG / Self-RAG / CRAG / Agentic RAG 各解决什么问题？

核心答案：四种进阶 RAG 范式各解决一个朴素 RAG 的短板——跨实体推理（GraphRAG）、检索时机判断（Self-RAG）、召回质量参差（CRAG）、多跳迭代（Agentic RAG）。

D7. ⭐⭐ RAGAS 4 大指标是什么？分别度量什么？

核心答案：RAGAS 是 RAG 评估的事实标准，4 大核心指标都用 LLM-as-judge 实现，覆盖"生成是否忠实 + 检索精度 / 召回 + 答案是否切题"。

实战阈值：4 个指标都 ≥ 0.7 算合格生产；Faithfulness < 0.7 优先修；Context Recall < 0.7 调 retriever。

D8. ⭐⭐⭐ 长上下文（1M）vs RAG，到底怎么选？

核心答案：长上下文与 RAG 互补不替代——单文档深度理解走长上下文，跨文档 / 增量更新 / 高 QPS 走 RAG，复杂场景做 hybrid（RAG 召回 + 长上下文消化）。

常见误解："Gemini 1.5 Pro 1M context 来了，RAG 该死了。" 实际上两者互补不替代。

来源：Hsieh et al. 2024《RULER》；Liu 2023《Lost in the Middle》；TianPan blog（具体数字单源，仅供参考）

D9. ⭐⭐ 中文 RAG 有什么特殊性？

核心答案：中文 RAG 有 7 个工程特殊点——无空格分词、英文 embedding 在中文退化、reranker 走中文 SOTA、同义词膨胀大、混合检索权重要调、领域 OOV 严重、citation 格式敏感。

D10. ⭐⭐⭐ 设计一个 RAG 系统，怎么做评估和持续优化？

核心答案：把 RAG 当成 ML 系统而非 prompt——三层评估（组件级 / 端到端 / 回归集）+ 持续优化闭环（trace → bad case → 归因 → 改一处跑全量），所有组件都要有指标 / 版本 / 回滚。

关键工程纪律：把 RAG 当成 ML 系统而非 prompt——每个组件都有指标、版本、回滚机制；retriever 和 generator 解耦，可独立升级；evaluation 模型必须比生产模型强，避免"自己评自己"。

E. Agent（12 题，核心分类）

E1. ⭐⭐⭐ Anthropic Building Effective Agents 把 agent 模式分成 workflow 和 agent 两类，区别是什么？为什么这个区分重要？

核心答案：Anthropic 原文：“Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage.” 区别的核心是控制流由谁主导——workflow 由人工代码编排，agent 由 LLM 自主决策。

为什么这个区分重要：90% 生产场景用 workflow 就够（routing / parallelization / orchestrator-workers / evaluator-optimizer），只有任务步数无法预知 + 需要环境交互 + 错误成本可承受时才上 agent。Anthropic 反对”什么任务都上 agent”的 hype。

面试回答关键：能说出”先用 workflow，agent 是兜底”+ 说得出 6 大 patterns 中哪个 pattern 适合什么场景。

E2. ⭐⭐⭐ Anthropic 6 大 agentic patterns 分别是什么？什么场景用哪个？

核心答案：6 大 pattern 覆盖”基础块 + 5 种 workflow 组合”，agent 模式是这 6 类之外的真正动态形态，适合步数无法预知的任务。

Agent 是 7 类 pattern 之外——agent 在 loop 中自己决定何时调工具、何时停止，适合 step 数无法预知的真正动态任务（如 SWE-bench、Computer Use）。

E3. ⭐⭐ ReAct loop / Plan-and-Execute / Reflexion 区别？

核心答案：三者都是 agent 推理范式，区别在规划深度和学习粒度——ReAct 单步动态、Plan-and-Execute 前置规划、Reflexion 跨任务学习。

E4. ⭐⭐⭐ 多 agent 协作模式 supervisor / hierarchical / swarm 怎么选？

核心答案：三种 sub-agent 协作拓扑各有适用场景——supervisor 适合清晰拆解、hierarchical 适合长 horizon、swarm 适合探索。Anthropic 推荐优先 supervisor 模式，避免 democracy 投票决策。

反模式：让多个 agent 自由群聊投票决策——成本爆炸且经常陷入死循环。

Anthropic 推荐：优先 orchestrator-workers（即 supervisor 模式）而非 democracy；任务正交分配 + 共享 state 单写多读。

实战经验：超过 3 层 hierarchy 通常意味着架构有问题，应该重新拆任务。

来源：Anthropic 2024《Building Effective Agents》；Anthropic《How we built our multi-agent research system》

E5. ⭐⭐ MCP（Model Context Protocol）是什么？为什么 2026 年增速这么快？

核心答案：MCP 由 Anthropic 2024-11 推出，是 LLM 客户端与外部工具/数据源之间的统一开放协议——本质是”agent 的 USB”，2025-Q4 治理转入独立 MCP Steering Committee（含 Anthropic / Block / OpenAI / Microsoft）。

它是什么：一个开放协议，让 LLM 客户端（Claude Desktop、Cursor、Cline、自研 agent）和外部数据源/工具（GitHub、Slack、Postgres、文件系统）之间用统一接口对话。

对求职者意义：MCP 在 Anthropic Applied AI Engineer JD 已是显式必备（“production experience with… MCP, and deployment at scale”）；2026 年增速最快的单一技能（LangChain ecosystem 16.9% 出现率）。提前学习能吃 6-12 个月红利。

E6. ⭐⭐⭐ Agent 4 种典型失败模式（Anthropic 总结）及对策？

核心答案：Anthropic 在 Effective Harnesses for Long-Running Agents 把数千次长跑失败归纳为 4 类——这正是 harness engineering 要解决的核心问题。

E7. ⭐⭐⭐ Hashimoto 的 “harness engineering” 核心思想是什么？怎么落地？

核心答案：Mitchell Hashimoto（HashiCorp 创始人）2026-02 在 My AI Adoption Journey Step 5 命名 harness engineering，原文 verbatim：“It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”

核心思想：每次 agent 犯错，不要只是希望它下次做得更好；要工程化环境，让它物理上无法以同样方式再犯。

OpenAI 的工程化等式：Agent = Model + Harness；分工原则 “Humans steer. Agents execute.”。

Anthropic 实证定律：能不能用 coding agent 真正解决问题，强相关于这个 agent 能不能验证自己的工作。

对求职者意义：staff 级面试经常问”如何让 agent 不再犯同样错”——能讲清”约束环境而非约束模型”+ 给具体例子（如 lint message 本身就是 prompt、deny-first 权限）才是合格答案。

E8. ⭐⭐ Function calling / Tool use 怎么设计才能让 agent 用得对？

核心答案：Tool use 设计要把”写工具描述”当 prompt 工程对待——Anthropic 实测 agent 性能正比于工具描述清晰度。

Anthropic 总结：把”写工具描述”当 prompt 工程对待，不是后端 API 文档。

来源：Anthropic 2024《Building Effective Agents》；Anthropic Tool Use docs

E9. ⭐⭐⭐ Computer Use / Browser Agent 怎么工作？什么场景实用？

核心答案：Computer Use（Anthropic 2024-Q4 推出）让 Claude 操作桌面：截屏 → LLM 看图 + 推理 → 输出鼠标键盘操作 → 系统执行 → 再截屏。Browser Use（开源框架，91k+ ⭐）类似但限于浏览器，基于 Playwright/Selenium，DOM 解析 + 视觉双路。

生产建议：能用 API 就别用 Computer Use；只在确实没有更好选择时使用。

E10. ⭐⭐⭐ 90% 的 Loop of Death 是怎么发生的？怎么防？

核心答案：Loop of Death = agent 进入无限循环烧 token 直到耗尽。防御靠纵深——硬性 max iteration / timeout / 进度检测 / HITL 告警等多层 deterministic safeguards。

真实事故（按媒体报道）：曾有 Claude Code sub-agent 烧掉 27M token 跑 4.6 小时无限循环；某 agent 单次烧 $40 API 费的报告（具体数字来源待核实）。

Anthropic 在 multi-agent research system 里强调：agent 必须有 deterministic safeguards（retry logic + checkpoints + budget），不能纯靠 LLM 自己感觉”够了”。

E11. ⭐⭐⭐ Agent benchmark（SWE-bench / GAIA / WebArena）是怎么被 hack 的？

核心答案：Berkeley RDI / Sky Computing Lab 在《How We Broke Top AI Agent Benchmarks》系统审计了一批主流 agent benchmark（SWE-bench、WebArena、GAIA、Terminal-Bench、OSWorld 等）发现多数都可被 hack 出近完美分数而不真正完成任务。

来源：Berkeley RDI 审计报告；LiveBench https://livebench.ai/；Chatbot Arena (LMSYS)

E12. ⭐⭐⭐ Agent harness 包括哪些核心组件？设计原则是什么？

核心答案：harness 不是 7 大组件采购清单，而是两条核心法则 + 四大支柱——核心是”约束环境而非约束模型”。

四大支柱（功能层 / “做什么”，参考 OpenAI / Anthropic / Stripe 实践收敛）：

支撑设施（不是 harness 本身，但运行需要）：MCP、沙箱（E2B / microVM）、护栏（NeMo Guardrails）这 3 个是 harness 强约束的直接实现；LLM 网关 / 推理服务器 / 可观测性 / 评估 4 类是任意 LLM 应用都需要的基础设施品类，不是 harness 工程的方法论特征。

来源：Hashimoto；OpenAI Harness Engineering；Anthropic Effective Harnesses；Augment Code Harness Engineering for AI Coding Agents

F. Memory（8 题）

F1. ⭐⭐ MemGPT 系统设计（OS-style 分层记忆）核心思想是什么？

核心答案：MemGPT（Packer et al. 2023, Berkeley）把 LLM 类比成被 context window 限制的 CPU，把记忆系统类比成 OS 的虚拟内存——LLM 自己通过工具在分层存储间 page in/out，把"窗口不够用"从硬限制变成软限制。

关键机制：LLM 自己有工具去 read/write 各层（pagein、pageout、search_recall、archival_insert），就像进程主动 page in/out 内存。当 main context 接近上限时，LLM 自己决定什么搬出去到 recall、什么从 archival 拉进来。

意义：把"context window 不够用"从硬限制转成软限制，agent 可以处理远超窗口的长任务。

实战意义：MemGPT 概念 2026 年仍是 Letta（开源继承）、Mem0、Zep 等记忆系统的设计参考，但具体实现已演进。

F2. ⭐⭐ Letta / mem0 / Zep 三个主流记忆系统的区别？

核心答案：三者覆盖三种不同抽象层级——Letta 给 agent 一个完整的"自我"，Mem0 给已有应用挂一层轻量记忆 layer，Zep 用图结构强化时序与关系推理。

Letta（MemGPT 商业版，开源 + 云）：直接基于 MemGPT 论文实现，面向构建有状态 agent——agent 自己有 core memory（自我描述 + 用户描述）+ recall memory（对话历史）+ archival memory（语义事实）。强调 agent 持久化、跨会话不丢身份。适合：对话 agent、长期陪伴助手。

Mem0（开源 + SaaS）：轻量记忆 layer，挂在已有应用上——LLM 抽取用户事实 / 偏好，写入向量库 + 可选图存储；按 user / session / agent 三层 hierarchy 索引。强调易接入（一行 API）。适合：客服、个性化推荐、ChatGPT-like 应用快速接入记忆。论文（arXiv:2504.19413）报告在长对话记忆 benchmark 上显著优于 RAG / full-context baseline。

Zep（开源 + 云）：graph-based 记忆——把对话抽成 episodic / entity / edge 三类节点，时序 + 关系一起建模；强调对历史时间线的精确召回。适合：销售 CRM、客户档案、需要时序推理的场景。

F3. ⭐ 工作记忆 vs 情景记忆 vs 语义记忆怎么区分？

核心答案：借自认知心理学三类长期记忆划分——工作记忆是"现在用的"，情景记忆是"带时间的事件"，语义记忆是"去时间化的事实"。三者在 LLM 系统里要分层存储，混在一锅会导致检索时事件和事实混乱。

陷阱：很多记忆系统把三类混存一锅，导致检索时事件和事实混乱。Zep 的图存储是少数明确分层的设计。

F4. ⭐⭐ 记忆系统的"检索 + 写入 + 更新 + 遗忘"四个动作怎么设计？

核心答案：记忆系统的四个动作不是 CRUD 的直接映射——写入要有"价值判断"门槛，更新要解决冲突，遗忘要支持衰减与 GDPR，否则极容易触发 memory corruption。

写入：不是把每句话都存——LLM extractor 判断"这句话有 long-term value 吗"才写。Mem0 用 4 种操作：

更新：当新事实与旧事实冲突（"我喜欢咖啡" → 一周后"我不喜欢咖啡了"），系统要 update 而非 append；通常 retrieval 时返回最新版本，但可保留历史版本支持时间旅行。

遗忘：长期不用的记忆按 LRU / 指数衰减分降低权重；user 显式删除支持（GDPR 要求）；矛盾事实可触发"哪个对"的人工 / LLM 仲裁。

Anthropic Memory Tool（2025 公测）由模型自己管理 memory，对话开头自动 read，期间动态 write/update。

F5. ⭐⭐⭐ progress 文件 + git 作为 memory bridge 是什么？为什么对长任务 agent 关键？

核心答案：长任务 agent 必然会跑爆 context window，纯靠 LLM context 不可能记住"我跑到第几步、改了哪些文件、待办是什么"。Anthropic 的解法是把进度持久化到文件系统（progress 文件 + git）而非 context window——前者是 long-term memory，后者是 working memory。

问题背景：Anthropic 在《Effective Harnesses for Long-Running Agents》给的核心设计：长任务 agent 必然会跑爆 context window，纯靠 LLM context 不可能记住"我跑到第几步、改了哪些文件、待办是什么"。

解法：把进度持久化到文件系统而非 context window。具体做法：

Anthropic 原文："It's still essential that the model leaves the environment in a clean state after making a code change. We found that the best way to elicit this behavior was to ask the model to commit its progress to git with descriptive commit messages and to write summaries of its progress in a progress file."

断点续跑：下次会话开头让 agent 跑 5 步开机协议（pwd → git log → progress 文件 → dev server → 基础测试），就能从断点续跑。

关键洞察：context window 是"working memory"，文件系统是"long-term memory"——把这两者明确解耦是长任务 agent 设计的基本功。

F6. ⭐⭐ Memory Corruption（记忆污染）是什么？怎么防？

核心答案：Memory corruption 指错误事实进入长期记忆后污染所有后续决策——短期无症状但持续误导，是长期记忆系统最隐蔽的失败模式，必须通过写入门槛、来源标记、审计 trail 多层防御。

为什么严重：long-term memory 一旦被污染，短期内无症状，但会持续误导未来对话；用户可能根本不知道某条错误事实是什么时候、为什么进的。

来源：综合 Mem0 / Letta 工程实践；OWASP LLM Top 10 关于 data poisoning 的描述

F7. ⭐⭐ context compaction（上下文压缩）应该什么时候触发？怎么做？

核心答案：当 context window 用量超过阈值（如 70%）、用户显式触发、sub-task 切换、或长 tool 输出后，要主动压缩；主流三种策略是滑窗 + 摘要、结构化 summarization、sub-agent 隔离。

F8. ⭐⭐⭐ 设计一个 agent 的记忆系统，端到端怎么做？

核心答案：端到端记忆系统按时间尺度 + 数据特性分五层（working / session / user profile / episodic / knowledge base），配合"写入 pipeline + 检索 pipeline"两条主链路，再加评估和工程纪律收口。

写入 pipeline：每轮对话结束 → LLM extractor 抽出 "facts about user / decisions / actions" → 去重（MD5 + 向量相似度）→ 冲突检测（与现有 memory 对比） → 决定 ADD/UPDATE/DELETE/NOOP → 写入对应层 + 标 source/confidence/timestamp。

G. 系统设计（8 题）

G1. ⭐⭐⭐ 设计一个生产级客服 Agent（含 RAG / 多轮 / fallback / 人工接管）

核心答案：基于 Anthropic Routing pattern 的分层架构，RAG hybrid 检索 + reranker 兜底召回，小模型做意图大模型做回答，工具调用走 deny-first 权限，叠加 fallback 链和人工接管触发器。

多轮：summary buffer（最近 10 轮原文 + 之前的滚动摘要），用户画像和订单状态作为 system prompt 注入。

Fallback 链：主模型超时/限流 → 备用模型 → 模板兜底（“已为您转人工”）。

关键 metrics：解决率（无需人工）、首轮命中率、CSAT、p95 延迟、每会话成本、幻觉率（LLM-judge 抽检）。

渐进部署：shadow → 5% canary → 灰度 → 全量，每阶段挂在线 A/B 看 CSAT。

G2. ⭐⭐⭐ 设计 Coding Agent（参考 Claude Code / Cursor / Devin）

核心循环（harness engineering）：read → plan → act → observe → repeat，每步把 tool 结果回写进 context。

Cursor vs Claude Code 关键差异：Cursor 偏 IDE 内联补全（diff apply），Claude Code 偏终端 agentic（自由调工具）。Devin 强调长程自治 + VM 持久化环境。

G3. ⭐⭐ 设计搜索 Agent（query rewriting / 多轮检索 / reranking）

核心答案：query 改写扩召回 → hybrid search 多路召回 → cross-encoder reranker 精排 → 多轮 agentic 补检 → 带 citation 的 grounded 合成，召回率优先用 reranker 兜底精度。

关键决策：embedding 选 bge-m3 / text-embedding-3-large；reranker 用 bge-reranker-v2 / Cohere v3；chunking 用结构化（by heading）而非固定 size；召回率比精度优先（reranker 兜底）。

G4. ⭐⭐⭐ 设计 LLM 网关（routing / fallback / 缓存 / 限流 / 计费）

核心答案：网关串起 router → fallback 链 → 双层缓存（exact + semantic）→ 多维限流 → 计量计费 → 全链 trace，对外 SSE 透传不缓冲。

关键 metric：p99 TTFT、cache hit rate、fallback 触发率、每千 token 成本。

G5. ⭐⭐⭐ 高并发 LLM 服务（QPS 万级 / token 流式 / 长尾延迟）

核心答案：QPS 万级假设单次 LLM 调用平均 3-5 秒，意味着同时在飞 3-5 万连接，纯 LLM 厂商单租户 RPM 远不够，必须多 region + 多账号 + 多厂商池化。

Metrics：TTFT（time to first token）p50/p99、TBT（time between tokens）、并发 in-flight、queue depth、429/5xx rate。

G6. ⭐⭐⭐ 成本优化：prompt caching + model routing + semantic cache 怎么省 80%？

核心答案：prefix caching + 模型路由 + 语义缓存 + 输出控制四板斧组合，实测可达 70-90% 成本降幅。

踩坑：semantic cache 阈值要保守（0.95+），否则 false positive 严重伤害用户体验，需要 LLM-judge 离线验证；cache 要有 TTL 应对内容更新。

G7. ⭐⭐⭐ 沙箱设计：E2B / Daytona / microVM / gVisor 怎么选？

核心答案：该题考察隔离强度 vs 启动延迟 vs 成本 trade-off。LLM agent 短任务首选 E2B（Firecracker），长程开发环境用 Daytona，自托管走 Firecracker + Jailer + seccomp。

G8. ⭐⭐ Observability + Evaluation 闭环怎么搭？

方案	隔离	冷启动	成本	适用
Docker (runc)	弱（共享 kernel）	<1s	低	受信代码、CI
gVisor	中（用户态 syscall 拦截）	~1s	低	一般受控代码
Firecracker / microVM	强（独立 kernel）	100-300ms	中	多租户函数
E2B	强（基于 Firecracker）	<500ms	中	LLM agent 代码执行（SaaS）
Daytona	强（workspace VM）	秒级	中高	dev environment、长任务
完全 VM	最强	秒-分钟	高	极敏感场景

核心答案：Tracing（harness 全链路）+ 离线 Eval（黄金集 + LLM-judge CI gate）+ 在线监控反馈（thumb up/down + 自动指标 + bad case 回灌黄金集），形成 Hashimoto harness 自愈闭环。

关键：Eval 不是一次性，是和测试一样持续跑的 CI gate；漂移监控用滑窗对比近 7d vs 近 30d 的 metric 分布。

H. 评估（6 题）

H1. ⭐⭐⭐ LLM-as-judge 三大 bias 及缓解

核心答案：LLM-as-judge 有三类经典偏见——位置偏好、冗长偏好、自偏好——MT-Bench 论文已经系统给出诊断与缓解套路。

H2. ⭐⭐ Pairwise vs Pointwise 怎么选？

核心答案：Pointwise 给绝对分、便于上 dashboard 但尺度不稳；pairwise 做相对比较、agreement 更高但组合数贵；模型选型用 pairwise，生产监控用 pointwise + rubric。

H3. ⭐⭐⭐ Benchmark 是怎么被 hack 的？（Berkeley RDI 警告）

核心答案：从数据污染到 judge hacking，benchmark 高分常常是"刷"出来而非"做"出来的——Berkeley RDI 长期警告 leaderboard overfitting，实战必须靠私有黄金集兜底。

Berkeley RDI（Sky Computing Lab / Ion Stoica 团队）长期警告 leaderboard overfitting，推动 LiveBench（题目持续更新）、Chatbot Arena（真人盲评）等动态评估。

实战缓解：自家黄金集（私有，绝不公开）+ 真实用户日志采样人工评估 + 多 benchmark 交叉验证，不信任任何单一榜单。

H4. ⭐⭐⭐ 在线 A/B 评估 + 漂移监控怎么做？

核心答案：A/B 评估讲究稳定分桶 + 多维度业务指标 + 显著性 + guardrail；漂移监控分输入、输出、质量、模型版本四类，配合每日黄金集回归才能及时发现退化。

来源：Anthropic / OpenAI 关于在线评估的 cookbook；Langfuse / Helicone 监控功能

H5. ⭐⭐ Judge 模型必须强于被测的"判官原则"

核心答案：Judge 模型能力应 ≥ 被评估模型，否则会出现"小模型评不出大模型的回答好在哪"的盲区。

实操：Sonnet 4.6 评 Sonnet 4.6 输出，用 Opus 4.7 / GPT-5+ 做 judge；评 Opus 级别，只能用更强模型 + 多 judge 投票 + 人工 spot check 兜底。例外：格式合规、关键词命中等 deterministic 任务可以用小模型 judge。

H6. ⭐⭐⭐ 三层组合：自家黄金集 + LLM judge + 人工校准

核心答案：工业界共识方案是"私有黄金集 + LLM judge + 人工校准"三层叠加——金标固定真相、judge 跑回归、人工抽检守住 judge 与人工的 agreement 阈值。

I. 安全 / 护栏（6 题）

I1. ⭐⭐⭐ OWASP LLM Top 10（2025 版前三）

核心答案：OWASP 2025 版前三是 Prompt Injection、Sensitive Information Disclosure（从 2023 #6 跃升至 #2）、Supply Chain，基于真实部署案例更新。

2025 版新增类别：Excessive Agency（权限过大）、System Prompt Leakage、Vector/Embedding Weaknesses、Misinformation、Unbounded Consumption（成本/资源 DoS）。

I2. ⭐⭐⭐ Prompt Injection 类型与防御

核心答案：Prompt injection 在 agent 时代头号威胁是间接注入（恶意指令藏在 RAG/网页/邮件里），防御要做纵深——输入识别、最小权限工具、spotlighting 数据标注、输出过滤、Planner/Executor 双 LLM 隔离。

I3. ⭐⭐ Jailbreak 攻击（DAN / role-play / many-shot）

核心答案：Jailbreak 通过 role-play、长 context many-shot、渐进式 Crescendo、编码绕过等方式诱导模型违反安全策略；防御依赖厂商 RLHF + 应用层 classifier + context 长度控制 + 多轮 drift 监控。

I4. ⭐⭐⭐ NeMo Guardrails 5 类 rails

核心答案：NVIDIA NeMo Guardrails 提供 Input / Dialog / Retrieval / Execution / Output 五类可组合 rails，串联拦截或改写并 fallback；关键是每类挑 1-2 个高 ROI 的开，否则延迟/成本爆炸。

部署模式：5 类 rails 串联，任一 rail 触发即拦截或改写并 fallback；rail 本身可以是规则、小分类器或另一个 LLM 调用。关键：rail 不是越多越好，每类挑 1-2 个高 ROI 的开，否则延迟/成本爆炸。

I5. ⭐⭐⭐ Deny-first 权限模型 / 沙箱防御纵深

核心答案：Deny-first（Claude Code 采用）默认禁止所有工具/命令、显式白名单允许，配合工具签名、权限策略、进程 sandbox、网络/文件隔离、审计构成 6 层纵深；任一层失守由其他层兜底。

Deny-first 机制：默认所有工具/命令禁止，显式白名单允许；Bash 命令按 verb + path 粒度授权（git status allow, git push --force deny）；destructive 操作每次弹出用户确认；--dangerously-skip-permissions 仅限受控环境。

关键原则：任一层失守，其他层兜底；不要假设 LLM 永远不被 inject。

I6. ⭐⭐ EU AI Act 2026-08 高风险义务

核心答案：EU AI Act 2024 通过、分阶段生效——2025-02 禁止性条款、2025-08 GPAI 通用模型条款、2026-08 高风险系统义务全面生效（招聘/信贷/教育/关键基础设施/执法/司法等），罚款上限 €35M 或 7% 全球营收。

高风险系统核心义务：风险管理体系（全生命周期）；数据治理（训练/验证数据质量记录）；技术文档与日志保留；透明度（用户知道在与 AI 交互）；人类监督（human oversight）；准确性、稳健性、网络安全；CE marking 与 conformity assessment；罚款最高 €35M 或 7% 全球营收。

对工程师的影响：招聘类 LLM 应用、信贷风控 LLM 应用、医疗辅助决策 LLM 都属高风险——需要可审计 logging、bias 评估报告、人工 override 机制、模型卡片。

J. 系统行为题 / 实战题（7 题）

J1. ⭐⭐⭐ 分享 agent 项目踩坑（STAR）

核心答案：用 STAR 框架讲一个有量化结果 + 有归因分析 + 有"沉淀到流程/系统"的真实案例，体现 harness engineering 视角。

回答框架：Situation（项目背景：什么 agent、目标用户、规模）→ Task（你的角色和具体职责）→ Action（怎么发现问题、调研、设计方案、执行）→ Result（量化指标改善 + 沉淀的方法论）。

关键：量化、有归因分析、有"沉淀到流程/系统"的部分（harness engineering 视角）。

J2. ⭐⭐ 怎么评估一个 prompt 是否好？

核心答案：四件套——黄金集 + LLM-judge + A/B + 用户反馈，离线和在线都要看，缺一不可。

常见反模式：只用"我自己测了 5 条感觉不错" → 在线必翻车；只看 benchmark 不看业务指标；只跑离线不上 A/B（不同流量分布表现差异巨大）。

J3. ⭐⭐⭐ Agent 跑爆 context 怎么办？

辅助手段：文件级而非全库注入（用 Grep/Glob 定位再 Read 单文件）；prompt caching 让重复 system prompt 不占新 token 预算；定期/任务节点之间清理已无关的中间产物。

J4. ⭐⭐⭐ 怎么让 agent 不再犯同样的错（harness engineering）

核心答案：核心思想引用 Hashimoto——"anytime you find an agent makes a mistake, engineer a solution such that the agent never makes that mistake again." Harness 工程的复利效应就在这里。

关键认知：Agent 是系统而非黑盒——它的能力 = 模型能力 + harness 能力（prompt + 工具 + permission + 监控 + 评估闭环）。模型能力提升靠厂商，harness 能力提升靠你自己，复利效应在 harness。

J5. ⭐⭐ 多 agent 协作冲突怎么处理？

核心答案：架构上优先用 orchestrator-workers 模式而非自由群聊，再配合任务分区、锁、reviewer agent、深度限制等手段控制冲突面。

反模式：让多个 agent 自由群聊投票决策——成本爆炸且经常陷入死循环或 echo chamber。

J6. ⭐⭐⭐ 怎么 debug 一个 hallucination 问题？

核心答案：Hallucination 不是"模型病了"，多数是 prompt / RAG / 上下文工程缺陷，按"复现 → 归因 → 修 → 加测试"的系统化流程排查。

关键：hallucination 不是"模型病了"——多数情况是 prompt/RAG/上下文工程缺陷，debug 流程本质和普通 bug 一样：复现 → 归因 → 修 → 加测试。

来源：Anthropic Contextual Retrieval；OpenAI 关于减少 hallucination 的官方建议

J7. ⭐⭐⭐ 团队从 0 到 1 落地 LLM 应用，优先级是什么？

核心答案：4 周路线图（staff 级思考）——Week 1 找场景 + 建黄金集，Week 2 商用模型 + RAG MVP，Week 3 eval + guardrail 闭环，Week 4 灰度上线。

长期（2-6 月）：成本优化（prompt caching + routing + semantic cache）、harness 能力沉淀（每个 bad case 形成永久回归）、模型/能力升级有 A/B 兜底。

K. Agent 评测（5 题）

K1. ⭐⭐ Agent benchmark 全景：tau-bench / SWE-bench Verified / OSWorld / WebArena / GAIA / TheAgentCompany 各侧重什么？

核心答案：Agent benchmark 按"任务领域"分四大类——编码（SWE-bench Verified）、桌面浏览器（OSWorld / WebArena）、对话工具（tau-bench）、多步研究 / 通用工作（GAIA / TheAgentCompany）。不要只刷单一榜单——E11 的结论是任何 benchmark 都可能被 hack，2026 推荐多 benchmark 交叉 + 自家黄金集 + Arena 真人盲评三层。

选型指引：(a) 编码 → SWE-bench Verified；(b) 客服 / 业务流 → tau-bench；(c) 桌面自动化 → OSWorld；(d) 浏览器 → WebArena；(e) 多跳研究 → GAIA；(f) 通用远程办公 → TheAgentCompany。生产场景永远不要只信单一 benchmark——E11 提到的 hack 模式（数据污染、format gaming、judge hacking）每个榜单都中招过。

⚠️ 适用边界：以上都是通用 / 跨领域学术 benchmark，只适合作基模能力 baseline 对比或选型参考——不能用来评测专业领域 Agent（电商 / 旅行 / 金融 / 客服 / 多智能体业务助手等）。业务领域 Agent 评测见 K5。

K2. ⭐⭐⭐ Agent trajectory evaluation：step-level / trajectory-level / outcome-level 三层粒度怎么权衡？

核心答案：Agent 输出不是单条 response 而是一条 trajectory（thought / action / observation 序列），评估要分三层粒度：(1) Outcome-level（最终成败 0/1）；(2) Trajectory-level（整条路径合不合理）；(3) Step-level（每一步动作单独打分）。粒度越细 signal 越多但成本越高，训练用 outcome、离线 eval 用 trajectory、关键场景才上 step。

陷阱：(1) Outcome 通过不代表 trajectory 健康（agent 可能 hack benchmark）；(2) Step-level reward 容易催生作弊行为；(3) 三层都用 LLM-judge 时要警惕 judge bias（self-preference / verbosity）。

K3. ⭐⭐ Tool-use correctness 怎么评：参数 hallucinate / 选错工具 / 漏调工具 / 用错顺序都怎么 catch？

核心答案：Tool-use 评估要分别覆盖"该不该调"、"调对了吗"、"参数对不对"、"顺序对不对"四个维度。生产标配 = static schema validation + LLM-judge trajectory eval + 黄金集 + 线上 trace 抽样 + dry-run 二次确认。

BFCL（Berkeley Function-Calling Leaderboard）是 2024 年起的 tool-use 标准 benchmark，包含 simple / multiple / parallel / multi-turn 等多个子任务，可作为离线 baseline 参考。

K4. ⭐⭐⭐ 上线 Agent 持续评估闭环：哪些指标该设 SLO？bad case 归因到 harness 怎么落地？

核心答案：生产 Agent 评估闭环 = 多层指标 SLO + 全量 trace + 自动 bad case 检测 + 人工归因 + harness 沉淀。Agent 不是 chat，单看正确率不够——必须同时跟成本、延迟、安全、轨迹健康四维。

反模式：(1) 只跑离线 benchmark 上线（线上分布差异大）；(2) 没 trace 直接看汇总指标（出 bug 无从查）；(3) bad case 修一个忘一个，没回归 CI（同样错误反复犯）；(4) 评估 model 比生产 model 弱（判官原则违背）。

来源：Hashimoto《Harness Engineering》；Anthropic《Effective Harnesses for Long-Running Agents》；Langfuse docs https://langfuse.com/docs；OpenAI Evals docs

K5. ⭐⭐⭐ 业务领域 Agent / 多 Agent 业务助手怎么评？

核心答案：业务领域 Agent（电商导购、旅行助手、客服、金融 / 法律咨询、内部 RAG 等）不能用 K1 那种学术 benchmark 评——必须建业务转化率 + 子 Agent 准确率 + 黄金集回归 + Harness 健康度四层评测体系。学术 benchmark 仅作选模型 baseline，真正决定上不上线的是线上 A/B 业务指标。

维度	通用 benchmark（K1）	业务领域 Agent（K5）
目标	选哪个基模	这版能不能上线
指标	绝对分（73.5%）	相对增量（+1.77pp 转化率）
数据	公开 / 学术集	自家黄金集 + 线上 trace
维度	任务完成率	业务漏斗 + 子 Agent + harness 健康
判定	离线一次跑	线上 A/B 兜底
粒度	整体	必须分子 Agent + 分场景

反模式（来自飞猪 AI 智能体「问一问」、酒店 AI 预定助手、千问酒店 MCP 等项目踩坑）：

进阶：多 Agent 协同矩阵 + 算法策略灰度切换的系统，还要评算法侧 vs LLM 侧打分一致性（两条路径产出策略 / 答案的相对差异）、多版本算法 A/B 节点级回归（按节点切换的局部影响）、LLM 辅助特征工程的产出可复用率（LLM 产出策略 vs 工程人工复核后的留存率）。

来源：飞猪 AI 智能体「问一问」工程实践（酒店 Agent 准确率 93.1%、3 分率 62.1%）；酒店 AI 预定助手 A/B 数据（列表页-订单页+1.77%、日均增量 GMV 46w）；千问飞猪酒店 MCP 春节日均 GMV 300w；Anthropic《How we built our multi-agent research system》；J7 0-1 落地路线 / J4 harness 闭环

术语速查表

软件工程基础

lint 软件工程 — 静态代码检查工具，扫描源码找潜在 bug 与风格问题

不实际运行代码的情况下分析源码，识别潜在 bug、未使用变量、风格违规、可疑用法。常见工具：

JavaScript/TypeScript：ESLint、Biome
Python：Pylint、Ruff、Flake8
Go：golangci-lint
Rust：clippy
Shell：shellcheck

在 Agent 工程中，lint 经常被用作 harness 的硬约束——把 lint 错误反馈给模型重写代码，比单纯在 prompt 里说"请遵守编码规范"可靠得多（Augment Code 把这叫做 Constraint Harness）。

type check / 类型检查 软件工程 — 验证变量、参数、返回值类型是否匹配

确保代码中变量赋值、函数调用的类型一致：

静态类型语言：TypeScript / Go / Rust / Java 编译期检查
动态语言加注解：Python 用 mypy / pyright / Pyre，Ruby 用 Sorbet

对 Agent：让 agent 写完代码后强制跑 tsc --noEmit / mypy . / cargo check，类型错误作为反馈喂回模型继续修。比让 agent 自己"声明检查过类型"可靠得多——这是 harness 工程的典型做法。

CI/CD 软件工程 — 持续集成 / 持续部署流水线

CI（Continuous Integration）：每次代码提交自动跑测试、构建、lint、type check 等校验。
CD（Continuous Deployment）：通过校验后自动部署到测试 / 预发 / 生产环境。

常见工具：GitHub Actions、GitLab CI、Jenkins、CircleCI、Buildkite。

在 Agent 工程里，CI 是最重要的 deterministic 反馈源——LLM 自评不可靠，但 CI 通过/失败是 0/1 信号，可以直接作为 ground truth。Hashimoto 的 harness engineering 强调"能不能解决问题强相关于 agent 能不能验证自己的工作"。

sandbox / 沙箱 软件工程 — 隔离的代码执行环境，限制对外部资源的访问

让不可信代码（用户上传、LLM 生成）在受限环境中跑，防止破坏宿主系统。隔离强度从弱到强：

Docker (runc)：共享 kernel，弱隔离，启动 <1s
gVisor：用户态 syscall 拦截，中隔离
Firecracker / microVM：独立 kernel，强隔离，~100-300ms 冷启
E2B：基于 Firecracker 的 SaaS，LLM Agent 代码执行首选
完全 VM：最强隔离，秒-分钟级冷启

Agent 跑用户/LLM 生成代码必须沙箱，并叠加纵深防御：网络出口白名单 + 文件系统只读 + 时间/内存配额 + 不挂载 host 凭据。

canary / 金丝雀发布 软件工程 — 先给少量流量上新版本，观察无异常再全量

来自煤矿用金丝雀检测毒气的典故。部署流程典型为：shadow（双跑不返回）→ 1% → 5% → 25% → 50% → 100%，每阶段观察核心指标无回归才推进。

对 LLM 应用：新 prompt / 新模型 / 新 agent harness 上线必走 canary，关键指标（解决率、CSAT、refusal 率、p99 延迟、单次成本）任何一个恶化 > 阈值就回滚。LLM 应用的"非确定性"特性让 canary 比传统软件更重要。

A/B test 软件工程 — 对照试验，把流量切成两组分别用新旧版本，比较关键指标差异

按 user_id hash 切流量保证一个用户始终进同一桶（避免体验跳变）。判定要素：

业务指标：转化率、CSAT、留存——验证假设
代理指标：thumb up/down、refusal 率、对话轮数
Guardrail metric：成本、延迟不能恶化超阈值
观察窗口：至少 1-2 周覆盖业务周期
统计显著性：t-test / Mann-Whitney 检验

LLM 应用调 prompt / 换模型 / 改 RAG 都应过 A/B；只靠 offline eval 上线常翻车（线上流量分布与黄金集差异大）。

GMV / UV / CSAT / NPS / 转化率 业务指标 — 电商 / 旅行 / 客服业务最常用的几个北极星指标

业务侧验收 Agent 是否上线最看的几个指标：

GMV (Gross Merchandise Value)：商品交易总额，电商核心指标。日均 GMV、月 GMV、增量 GMV（A/B 实验组比对照组多出来的）都是常见口径。
UV (Unique Visitor) / DAU (Daily Active User)：独立访客数 / 日活用户。UV 看流量，DAU 看粘性。
PV (Page View)：页面浏览量，UV × 人均浏览次数。
CTR (Click-Through Rate)：点击率，曝光后点击占比；推荐系统核心指标。
转化率 (Conversion Rate)：漏斗各环节转化——列表页→详情页、详情页→订单页、详情页→支付。电商 / 旅行场景 +1pp 即显著、+1.5-2pp 算大幅提升。
CSAT (Customer Satisfaction Score)：用户满意度评分（1-5 或 1-10），客服 Agent 必看。
NPS (Net Promoter Score)：净推荐值，"你有多大可能推荐给朋友"，-100 到 100。
首轮解决率 / FCR (First Contact Resolution)：首次交互就解决问题的比例，客服 Agent 关键指标。

Agent 工程关注：把模型 / prompt / RAG 改动放进 A/B 看这些业务指标，而非只看离线 benchmark 分数。改动让 benchmark 涨但 GMV / CSAT 跌的情况非常常见。

HITL / human-in-the-loop 软件工程 — 关键决策点引入人工审核 / 确认

Agent 自治走到关键节点时暂停等待人工：

高风险操作前：转账、发邮件、删数据、合并 PR
置信度低时：模型自评 confidence < 阈值
法规要求：医疗诊断、信贷决策、招聘筛选（EU AI Act 高风险系统要求）

设计原则："Humans steer. Agents execute."（OpenAI Harness Engineering）。Agent 不是替代人，是放大人的判断——把人放在制定计划、设定约束、审核结果的位置，agent 处理执行。

SLO / SLI / SLA / Error Budget 软件工程 — 服务质量的"目标 / 指标 / 合约 / 预算"四件套，来自 SRE

Google SRE 体系定义的四个术语：

SLI (Service Level Indicator)：一个指标——可观测的数字。如"成功率 99.5%"、"p99 延迟 280ms"、"任务完成率 92%"。
SLO (Service Level Objective)：在 SLI 上设定的目标。如"成功率 SLO = 99.9%（30 天滑窗）"。是工程团队对内的承诺。
SLA (Service Level Agreement)：和用户 / 客户的合约，违约要赔钱 / 退服务费。通常比 SLO 宽（SLO 99.9% → SLA 99.5%），留缓冲。
Error Budget：1 - SLO。SLO 99.9% 意味着 30 天有 43.2 分钟"预算"可以不达标，预算用完就冻结非必要发布。

Agent 应用怎么用：

每个 Agent 场景定 1-3 个 SLO：如"客服 Agent 解决率 SLO = 85%"、"p99 端到端延迟 SLO ≤ 5s"、"单任务平均成本 SLO ≤ $0.05"
触发告警：实时 SLI 跌破 SLO 80% 警告，跌破 SLO 直接 page oncall
冻结发布：error budget 烧完了，禁止合并非紧急修复
业务 SLO vs 技术 SLO：业务 SLO（转化率 / CSAT / GMV）属于产品验收，技术 SLO（延迟 / 错误率 / cost）属于工程兜底，两层都要

经验法则：SLO 不是越严越好——99.99% 比 99.9% 贵 5-10 倍，且大概率超过用户感知阈值。Google 建议"刚刚够用户不抱怨"的水位。

TTL / Time To Live 软件工程 — 数据 / 缓存 / 凭据的有效期

到期自动失效。常见用法：

Cache TTL：Redis 缓存设 1h / 24h
Prompt Caching TTL：Anthropic 默认 5 分钟，可选 1 小时
Session TTL：用户会话 24h-7d
凭据 TTL：JWT、临时 AWS 凭据通常 1h
Memory TTL：低 confidence 记忆短 TTL，高 confidence 长 TTL（Memory Corruption 防御之一）

LLM 基础概念

token LLM 基础 — LLM 的最小输入/输出单位，由 tokenizer 切分得到

英文：一个 token 通常对应 1 个常用词或半个长词（约 4 字符）
中文：一个 token 约对应 0.5-2 个汉字（取决于 tokenizer 训练）
代码：标点 / 缩进 / 符号都各占 token

经验换算：1000 英文单词 ≈ 1300 token；1000 汉字 ≈ 1500-2000 token。

为什么重要：context window、API 计费、推理速度都按 token 算。控制 token 数 = 控制成本和延迟。Anthropic / OpenAI / Google 各自的 tokenizer 不同，相同文本 token 数差 ±20% 很常见。

embedding LLM 基础 — 把文本/图片映射为高维稠密向量，语义相近的向量距离近

文本 → 神经网络 → 一个 768 / 1024 / 1536 / 3072 维的浮点数向量。同义词 / 同主题文本的向量在空间中距离近（cosine similarity 高）。

主要用途：

检索：query embedding → 找最相似的 doc embedding（RAG 召回）
聚类：相似主题文档自动分组
分类：用相似度做 zero-shot 分类
去重：相似度 > 阈值视为重复

主流模型 2026：OpenAI text-embedding-3-large、Cohere v4、Voyage-3、BGE-M3（开源 SOTA，中英双语 + dense/sparse/multi-vector 三合一）。

context window / 上下文窗口 LLM 基础 — 模型单次能处理的 token 上限

包含 system prompt + 历史对话 + 用户输入 + 模型输出，所有都计算在内。2026 主流模型：

GPT-4o：128k
Claude 3.5 Sonnet / Opus：200k
Gemini 1.5 Pro：1M-2M
Llama 3.1：128k

注意：宣称窗口 ≠ 有效窗口。RULER 基准显示多数模型在窗口 1/4 之外性能急剧下降（Lost in the Middle）。工程建议把"应当塞入 context"的阈值定在 8-32k，更长走 RAG 或层级摘要。

prefill / decode LLM 基础 — LLM 推理的两阶段：处理输入 → 逐 token 生成

Prefill：把 prompt 所有 token 一次性喂入模型计算 KV cache。compute-bound（受 GPU 算力限制），一次能并行处理整段 prompt。延迟决定 TTFT。
Decode：一次生成一个 token，每个 token 都要复用前面所有 token 的 KV cache。memory-bound（受显存带宽限制），延迟决定 TPOT / ITL（inter-token latency）。

两个阶段瓶颈不同，调优策略也不同——prefill 优化靠并行 / FlashAttention，decode 优化靠 continuous batching / speculative decoding。因为特性相反，工程上还有 PD 分离（Prefill/Decode Disaggregation，用不同 GPU 池分别处理，如 DistServe/Mooncake）和 chunked prefill（把长 prefill 切块与 decode 交错调度）两类调度优化。详见 A11。

KV cache LLM 基础 — 注意力中已计算过的 K (Key) / V (Value) 矩阵缓存

生成第 t 个 token 时需要前面所有 token 的 K/V 参与注意力计算。把它们缓存下来避免每次重算，是 LLM 推理的最基础优化。

显存占用：2 × num_layers × num_heads × head_dim × seq_len × batch × bytes_per_elem。70B 模型上 128k 上下文的 KV cache 可达数十 GB，远超模型权重本身。

进阶优化：

PagedAttention：分块管理，去碎片
GQA/MQA：减少 K/V 头数，KV cache 减小到 1/8 ~ 1/H
KV cache 量化：FP8 KV cache（H100 原生）显存减半
prefix caching：跨 request 复用相同前缀的 KV

autoregressive / 自回归 LLM 基础 — 一次生成一个 token，下一个 token 的生成依赖前面所有 token

GPT 类 decoder-only 模型的生成方式：P(x_t | x_1, ..., x_{t-1})。每生成一个 token 都要跑一次完整 forward（虽然能复用 KV cache），所以输出长度直接决定延迟。

对比：BERT 是非自回归（masked LM，一次预测所有 mask 位置），扩散模型（diffusion）也是非自回归（一次去噪整段）。

自回归的代价催生了大量加速技术：speculative decoding、parallel decoding、Medusa、EAGLE 等。

logit LLM 基础 — 模型输出的原始未归一化得分，每个词汇表 token 一个值

decoder 最后一层输出 [vocab_size] 维的 logit 向量；过 softmax 后得到下一个 token 的概率分布。

工程上能拿到 logit（或 top-k logprob）的场景：

计算 perplexity（评估模型对文本的"惊讶"程度）
Self-Consistency 取候选 logprob 加权
LLM-as-judge 用 yes/no logit 差值作 confidence
DPO 损失函数直接用 logprob 计算
Speculative decoding 用 logit 做 rejection sampling

注意：OpenAI / Anthropic 商用 API 默认只返回采样结果，需显式开 logprobs 选项。

temperature LLM 基础 — 控制采样随机性的超参数，0 = 确定性，>1 = 高随机

P(token) ∝ exp(logit / T)：

T=0：greedy，每次选 argmax，结果可复现（同输入同输出）
T=0.7-1.0：通用对话推荐范围
T>1：越大越随机，多样性高但容易胡说

何时调高：Self-Consistency 需要多样路径、creative writing、brainstorm。
何时调低：代码生成、数学推理、严格格式输出，T=0.1-0.3。

陷阱：T=0 不完全等同 deterministic——浮点 GPU 算子的非确定性 + 并发调度可能让相同 prompt 的输出仍有微差。

attention sink LLM 基础 — 模型把大量注意力集中到序列开头几个 token 的现象

Xiao et al. 2023 发现：长序列推理时，靠后的 token 往往把不成比例多的注意力分给了序列最前面的几个 token（即使它们语义无关）——这些 token 成为"sink"，吸收掉 softmax 必须分配的归一化质量。

工程意义：

StreamingLLM：滑窗推理保留开头 sink token，可处理无限长序列
解释了 Lost in the Middle：中间 token 注意力被首尾压榨
解释了为什么截断序列开头会大幅伤害性能——sink 没了

Transformer 架构

LayerNorm / RMSNorm 架构 — Transformer 主流归一化层，沿 feature 维度对单样本归一化

LayerNorm：y = (x - μ) / σ * g + b，沿 hidden 维度求均值方差。与 batch 无关，天然支持变长序列与单条推理——这是 Transformer 选 LayerNorm 而非 BatchNorm 的原因。

RMSNorm（Zhang & Sennrich 2019）：y = x / sqrt(mean(x²)+ε) * g，去掉减均值和 bias。Llama / PaLM / Mistral 等现代 LLM 几乎都改用 RMSNorm，省 7-64% 归一化耗时且效果不降。

Pre-LN vs Post-LN：LN 在残差前做（Pre-LN）训练比放残差后（Post-LN）稳定，可去掉 warmup，GPT-2 起几乎统一用 Pre-LN。

RoPE / Rotary Position Embedding 架构 — 旋转位置编码，把位置信息编码进 Q/K 旋转矩阵

Su et al. 2021。把位置 m 表示为旋转矩阵 R_m 作用在 Q/K 上，使得 <R_m·q, R_n·k> = f(q, k, m-n)——注意力得分只依赖相对距离。

优点：(1) 无额外参数；(2) 天然编码相对位置；(3) 可与线性注意力兼容。已成 Llama / Qwen / Mistral 等绝大多数现代 LLM 的位置编码方案。

外推问题：纯外推 2k→32k 会崩——高频分量旋转角度落入未见区域。缓解：

NTK-aware scaling：低频维度插值、高频近似不变
YaRN（Peng 2023）：加 attention temperature + 按维度分段缩放，Llama-3.1 128k、Qwen2.5 用的就是这套

NTK-aware scaling / YaRN 架构 — RoPE 长度外推方案，让 2k 训练的模型能跑 32k / 128k context

RoPE 纯外推会崩——高频分量在训练上下文外旋转角度落入未见区域。两种工程化方案：

NTK-aware scaling（NTK = Neural Tangent Kernel）：对低频维度做插值（拉伸 base），高频维度近乎不变。简单有效，不需重训。
YaRN（Peng et al. 2023）：在 NTK 基础上加 attention temperature 调整 + 按频率维度分段缩放（高频严格保留、低频强插值），需少量长上下文数据微调（万级 token 长度样本）。

主流应用：

Llama-3.1 128k → YaRN
Qwen2.5 / Qwen3 → YaRN
Mistral-7B 32k 早期版本 → NTK
GPT-4 / Claude → 闭源，可能用自研方案 + 长上下文持续训练

经验数字：YaRN 在 4× 上下文扩展（2k→8k 或 32k→128k）几乎无损；8× 以上仍有性能下降。极致长上下文（1M+）通常需要重训而非仅靠 YaRN。

GQA / MQA 架构 — Grouped/Multi Query Attention，多个 Q 头共享同一组 K/V 头

标准 multi-head attention：H 个头各有独立 Q/K/V。

MQA：所有 Q 头共享一套 K/V（极端形态）
GQA：把 H 个 Q 头分成 G 组，每组共享一套 K/V（折中），G=H/8 是常见配置

收益：KV cache 减小到 1/8 ~ 1/H，推理吞吐显著提升，效果几乎无损。Llama-2 70B / Llama-3 / Mistral / Qwen2 等都用 GQA。

MoE / Mixture of Experts 架构 — 混合专家模型，每个 token 只激活部分 expert FFN

把传统 dense FFN 换成 N 个并行的 expert FFN + 一个 router。每个 token 通过 router 选 top-k 个 expert（k 通常 1-2），只激活这部分 expert 计算。

优点：参数量大、算力省。Mixtral 8x7B 总参数 47B，激活参数仅 13B；DeepSeek-V3 671B 总参数，激活仅 37B。同等推理成本下 capacity 远超 dense 模型。

挑战：(1) 训练时负载均衡（防一两个 expert 被过度使用）；(2) 显存占用按总参数计而非激活参数；(3) 通信开销大（expert parallelism）。

multi-head attention / 多头注意力 架构 — 把 d_model 拆成 h 份独立投影 Q/K/V，每头学不同子空间的关系

单头注意力对每对 token 只产生一个 attention 分布——一种"关系视角"。多头（h=8/32/64/128）让模型同时学多种关系——句法头关注短距离依赖，语义头关注共指、远程实体。

为什么单头加大维度不行：多头是 h 个低秩注意力的混合，表达能力严格更强；单头是一个高秩注意力，自由度反而少。

进阶变体：GQA / MQA 在 KV 侧减头省显存，Q 侧仍保多头。

推理加速

FlashAttention 推理加速 — 通过 tiling + online softmax 不实例化完整 attention 矩阵的 attention 计算

Dao 2022。标准 attention 显存 O(N²)（要存 N×N 的 attention matrix），长序列瓶颈。FlashAttention 把 Q/K/V 分块加载到 GPU SRAM 计算，不写出完整 attention matrix，显存降到 O(N)，速度也快——attention 是 memory-bound，少读 HBM 就快。

演进：

FA1（2022）：A100 上 ~25% 峰值 FLOPS
FA2（2023）：优化并行划分、warp 调度，A100 ~50-72% 峰值
FA3（Shah 2024）：针对 H100 用 WGMMA 异步张量核心 + TMA + producer/consumer warp，BF16 达 740 TFLOPS（75% 峰值），FP8 接近 1.2 PFLOPS

PagedAttention 推理加速 — vLLM 提出，把 KV cache 像 OS 虚拟内存一样切成固定大小 block 管理

Kwon et al. 2023。解决传统推理 KV cache 的三类碎片问题：

内部碎片：预分配 max_seq_len 但实际只用一小部分
外部碎片：请求间隙无法复用
共享前缀无法去重

机制：KV cache 切成固定大小 block（如 16 token），每个序列维护 block table（逻辑→物理映射）。显存利用率从 ~20% 提到 >96%；同 prompt 多采样共享前缀 block；配合 continuous batching 吞吐相对 HuggingFace TGI 提升 2-4×，相对 FasterTransformer 24×。

vLLM 推理加速 — UC Berkeley 开源的高吞吐 LLM 推理引擎，实现 PagedAttention

2023 年起的事实标准开源推理服务器。核心特性：

PagedAttention 显存管理
Continuous Batching
Prefix Caching 自动开启
Chunked prefill（v0.6+ 默认，prefill/decode 交错调度降抖动）
FP8 KV cache（H100/H200）
支持 GPTQ / AWQ 量化

对比：TGI（HuggingFace）、TensorRT-LLM（NVIDIA，私有更快）、SGLang（前缀复用更彻底）、LMDeploy（OpenCompass 出品）。

continuous batching 推理加速 — 按 token 级别动态调度，请求结束即退出、新请求随时插入

也叫 in-flight batching，Yu et al. ORCA 2022 提出。对比 static batching（等齐 batch 再一起跑，长短请求混在一起时 GPU 利用率经常 <30%），continuous batching：

每个 decode step 后，已完成的 request 立刻退出
新到的 request 立刻插入空槽并先做 prefill，再加入 decode batch
配合 PagedAttention 无显存碎片

vLLM 数据：吞吐相比 static 提升 5-23×。已成所有现代推理引擎的默认。

speculative decoding 推理加速 — 小 draft 模型快速猜 K 个 token，大模型一次 forward 并行验证

Leviathan et al. 2023。流程：

小 draft model（1-7B）自回归生成 K 个 token（K=5 典型）
大 target model（70B+）一次 forward 并行验证 K+1 个位置
前 j 个被接受 + 第 j+1 个拒绝 → 保留前 j 个 + 采样一个新 token

数学上保证输出分布与原模型完全一致（rejection sampling）。

收益条件：(1) draft 与 target 分布相似（接受率 >60%）；(2) 大模型受 memory bandwidth 限制，并行验证不增延迟。代码生成接受率 70-90%，开放生成 30-50%。变体：EAGLE-2/3、Medusa、Llama 3.1 self-speculative。

prefix caching 推理加速 — 跨 request 缓存相同前缀的 KV cache，跳过 prefill 重新计算

KV cache 是单 request 内复用；prefix caching 是跨 request 复用——多个 request 共享 system prompt / few-shot / agent 历史时，首次计算后缓存这部分 KV，后续 request 直接命中跳过 prefill。

效果：agent / RAG / 多轮对话场景，system prompt 通常 1-4k token、几乎所有请求共享，TTFT 可下降 10-100×。

实现：vLLM --enable-prefix-caching、SGLang RadixAttention（用 radix tree 自动管理所有历史前缀）、Anthropic prompt caching API（5min TTL，cached 部分 0.1× 价格）。

TTFT / Time to First Token 推理加速 — 从 request 发出到第一个 token 返回的延迟

主要由 prefill 决定（处理 input 所有 token）。计费、监控的核心指标之一。

降低 TTFT 的手段：

Prefix Caching（命中后 TTFT 降 80%+）
减短 prompt（RAG 召回精度上去后能砍 chunk）
FlashAttention / 更新硬件
Speculative decoding
Chunked prefill（不阻塞其他请求 decode）

伴生指标：TPOT（time per output token，单 token 间隔，也叫 TBT/ITL）— 由 decode 决定。

TPOT / Time Per Output Token 推理加速 — decode 阶段每生成一个 token 的平均延迟（也叫 ITL / TBT）

与 TTFT 配对的另一核心延迟指标：TTFT 衡量"等多久看到第一个字"（由 prefill 决定），TPOT 衡量"后续每个字蹦多快"（由 decode 决定）。流式输出的体感速度 ≈ 1/TPOT（tokens/s）。

别名：ITL（inter-token latency）、TBT（time between tokens）。
瓶颈：decode 是 memory-bound，TPOT 主要受显存带宽 + batch 大小影响。
降低手段：continuous batching 提吞吐、speculative decoding 一步多吐、GQA/MQA / KV 量化减小 KV cache 读取量。
SLA 实践：TTFT 与 TPOT 往往分别定指标（如 p99 TTFT < 1s、TPOT < 50ms），并通过 PD 分离 / chunked prefill 解耦优化。

量化

FP16 / BF16 / FP8 量化 — 低精度浮点格式，省显存省算力

FP16（half）：5 位 exp + 10 位 mantissa，动态范围窄，训练易溢出
BF16（brain float）：8 位 exp + 7 位 mantissa，动态范围同 FP32，精度低但训练稳，A100/H100 起的默认训练精度
FP8（H100/H200 原生）：E4M3（前向）+ E5M2（反向），动态范围比 INT8 大 ~10⁴×，几乎无精度损失，throughput 是 BF16 的 2×

混合精度训练：权重和梯度用 BF16/FP16，optimizer state 仍用 FP32。

INT4 / INT8 / NF4 量化 — 整数量化，把 FP16 权重压到 4/8 bit 整数

部署阶段把权重量化到低 bit 整数，推理时反量化回浮点计算。

INT8：精度损失通常 <1%，部署友好
INT4（GPTQ / AWQ）：7B 模型从 14GB 压到 ~4GB，普通显卡可跑大模型
NF4（NormalFloat 4-bit，QLoRA 用）：信息论最优的正态分布量化，专为 LLM 权重分布设计

INT8 / INT4 量化通常需要校准集（128-512 样本），AWQ 更智能（保护 1% salient 通道）。极致显存场景再用 GGUF（llama.cpp 格式）+ 3-bit / 2-bit 量化跑手机端。

AWQ / Activation-aware Weight Quantization 量化 — 保护 1% salient 通道的 INT4 权重量化

Lin et al. 2023。核心洞察：只需保护 ~1% 的"重要权重通道"（由激活幅值识别）即可保住精度。对这些通道按 per-channel scale 放大再量化。

对比 GPTQ：实现更简单，Llama-2 上困惑度更低，已成 vLLM / TensorRT-LLM 默认。

GPTQ 量化 — 较早的 post-training 4-bit 权重量化

Frantar 2022。用 OBQ 启发的逐层最小化量化误差，需要少量校准集（128 样本）。优点：早、生态全（exllama / vllm / TGI 都支持）；缺点：对激活分布敏感，重要通道可能被压坏。

2026 部署选型：H100/H200 → FP8；A100/3090 → AWQ INT4；手机/边缘 → INT4 + GGUF。

微调与对齐

SFT / Supervised Fine-Tuning 微调 — 监督微调，用 (prompt, response) 对数据训练模型

最基础的指令微调方式：把 (输入, 期望输出) 对当做监督学习样本，cross-entropy loss 教模型学指令跟随。

经验数据量：

基于 chat 模型做格式/风格适配：500-5000 高质量样本
注入新领域知识：1-10 万样本 + 5-20% 通用数据混入
从 base 做完整 instruct tuning：百万级（Llama 3 用 ~1000 万）

LIMA 论文：1000 条精选样本即可让 65B base 接近 GPT-4 对话质量——质量 >> 数量。

LoRA / Low-Rank Adaptation 微调 — 冻结原权重，只训练低秩 adapter 矩阵

Hu et al. 2021。把权重更新分解为两个低秩矩阵 ΔW = BA（r=8/16/64），只训练这两个矩阵，可训参数减少 100-10000×。

显存：

全参微调 ≈ 16-20× 参数量字节，7B 需 >100GB
LoRA：冻结原权重仍要 FP16 加载，7B 需 ~14GB + adapter

优点：可训参数少 / 多个 adapter 可热切换 / 缓解灾难性遗忘。

QLoRA 微调 — 4-bit 量化冻结权重 + LoRA adapter，单卡 24G 跑 65B 微调

Dettmers et al. 2023。三项关键：

4-bit NF4 量化冻结权重：7B 从 14GB 压到 ~4GB
Double Quantization：把量化常数也量化，省 ~0.4 bit/param
Paged Optimizer：NVIDIA unified memory，OOM 时溢出到 CPU

65B 模型 QLoRA 约 33GB，单 A100-48G 或双 RTX 3090 可跑。代价：训练慢 30-40%（反量化开销）。

RLHF 对齐 — Reinforcement Learning from Human Feedback，用人类偏好做 RL 训练

三步走：(1) SFT 训出 base policy；(2) 人类标注 (chosen, rejected) 偏好对训出 Reward Model；(3) 用 RM 给 policy 输出打分，PPO/RLOO/REINFORCE 等算法更新 policy。

InstructGPT、ChatGPT 让 RLHF 出圈。三大痛点：

RM 训练需大量人类偏好标注（10 万对级），贵
RM 容易被 hack（policy 学会迎合 RM 表面偏好）
主观任务的偏好本身嘈杂

催生了 DPO、GRPO、RLVR 等简化/改良方案。

RM / Reward Model 对齐 — 用人类偏好训出来的"打分模型"，给 LLM 输出打分

RLHF 第二步训出。输入：(prompt, response)，输出：一个 scalar reward。训练 loss 是 Bradley-Terry：让 RM 在 (chosen, rejected) 对上给 chosen 更高分。

常见弱点：

Reward hacking：policy 学会迎合 RM 表面偏好（如长度、特定开头）
Goodhart's Law：RM 一变成 RL 目标就不再代表真实人类偏好
泛化差：训练分布外 RM 打分不可信

替代方案：DPO 完全去掉 RM，RLVR 用程序判定 reward。

DPO / Direct Preference Optimization 对齐 — 从数学上证明可以不用 RM、直接监督式优化偏好

Rafailov et al. 2023。证明：在 Bradley-Terry 偏好模型 + KL 约束下，最优 policy 有闭式解，可直接用偏好对 (chosen, rejected) 做监督式损失：

L_DPO = -log σ(β(log π(y_w)/π_ref(y_w) - log π(y_l)/π_ref(y_l)))

优势：(1) 无 RM / 无在线采样 / 无 critic，仅 policy + ref 两个模型；(2) 用 SFT 同样的训练栈；(3) 超参稳定。

劣势：严重依赖偏好数据质量；容易过拟合 chosen 的表面模式；reward hacking 风险大。

Llama-3、Qwen2 后训练主路径都是 DPO 或其变种（IPO、KTO、SimPO）。

PPO / Proximal Policy Optimization 对齐 — RLHF 经典算法，actor-critic + clipped objective

Schulman 2017。Actor 学策略，critic 学 value function 估计 advantage，clip 限制每步策略更新幅度防崩。

RLHF 中需同时载入 actor / ref / critic / reward 四个模型，显存 ≥4× 单模型。超参敏感（KL 系数、clip ratio、advantage 归一化），训练不稳定。

催生了 DPO（去 RL）、GRPO（去 critic）、RLOO（用平均 reward 当 baseline）等简化方案。

GRPO / Group Relative Policy Optimization 对齐 — DeepSeek 提出，去掉 critic，用组内 reward 均值做 baseline

DeepSeek-Math 2024 提出，R1 验证。核心创新：去掉 critic（value 网络），对同一 prompt 采样 G 个 response（典型 G=64），用组内 reward 的均值/标准差做 advantage 归一化：A_i = (r_i - mean(r)) / std(r)，再做 PPO-like 的 clipped objective + KL 正则。

效果：

显存省一半（无 critic），70B 级 RL 在合理资源内可行
组内归一化天然提供 baseline，方差比 PPO 的 GAE 还低
配合 RLVR，R1-Zero 直接从 base 模型纯 RL 涌现 long CoT

RLVR / RL with Verifiable Rewards 对齐 — 用程序判定的 0/1 reward 做 RL，无需 RM

在数学、代码、形式逻辑等可自动验证的任务上，直接用程序判定 reward：答案匹配、单测通过、定理证明器验证。

优势：

无标注成本
信号干净，无 RM hack 空间
可大规模并行 rollout

DeepSeek-R1、DAPO（ByteDance 开源 SOTA）都属此类。局限：仅适用可验证任务，开放对话仍需 RLHF / DPO。

catastrophic forgetting / 灾难性遗忘 微调 — 在新任务上微调后，原通用能力显著下降

机制：参数被新任务 loss 拉走，原本编码通用知识的方向被覆盖。

缓解组合（生产推荐）：

5-30% 通用数据混入新数据
LoRA 而非全参（低秩约束）
小学习率（lr=1e-5 起）+ 短训练（1-2 epoch）
持续 eval MMLU / MT-Bench 监控

进阶：EWC（按 Fisher 信息加权 L2 正则）、Model Souping（微调模型与原模型权重平均）、MoE 路由扩展。

提示词与推理范式

CoT / Chain of Thought 提示词 — 让模型先输出推理步骤再给答案

Wei et al. 2022。最简形式："Let's think step by step"（Kojima 2022 zero-shot CoT）。

为什么有效：(1) 增加有效 compute（更多 forward step）；(2) 把"系统 1"直觉答题转成"系统 2"分步推理；(3) 暴露错误推理便于 self-consistency 投票纠正。

是涌现能力，<10B 模型几乎无效。Long CoT（R1 / o1 用 RL 训出，含回溯/自我验证，数千 token 长）是 2025 的新范式。

ToT / Tree of Thoughts 提示词 — 把推理建模为树搜索，每步多候选 + 自评估 + 回溯

Yao et al. 2023。CoT 是线性单链，错了无法回头；ToT 每步生成多个候选 thought，LLM 自评估状态价值（promising / sure / impossible），BFS/DFS 展开可回溯剪枝。

Game of 24 上 GPT-4 CoT 4% vs ToT 74%。代价：LLM 调用数从 1 涨到 50-200。

适合：解空间需显式搜索（puzzle、规划、定理证明），中间状态可评估。不适合：闲聊、摘要、翻译。

ReAct 提示词 — Reasoning + Acting，思考-行动-观察循环

Yao et al. 2022。结构 Thought → Action → Observation 循环：模型先 "Thought: 我需要查 X"，输出 "Action: search[X]"，工具结果作为 "Observation: ..." 喂回 prompt，再下一轮 Thought。

三大效果：

把模型不知道的事实外化给工具，减少幻觉
Reasoning 由 observation 引导，错了能纠偏
提供可解释的 trace 便于 debug

是现代 agent 框架（Claude tool use、OpenAI function calling、LangChain、AutoGPT）的概念原型。

Reflexion 提示词 — 跨 episode 的"言语强化学习"，把失败原因存为 lesson

Shinn et al. 2023。Agent 在一次任务失败后（由外部 verifier 给二元 reward），用 LLM 把失败原因总结成自然语言 lesson 存入 episodic memory，下一次任务时把 lesson 加进 prompt 影响行为。

vs Self-Refine：

Self-Refine 单局优化、纯靠模型自评
Reflexion 跨局学习、有外部 ground-truth verifier

HumanEval 上 GPT-4 Reflexion 91%，超过 GPT-4 baseline 80%。

Self-Refine 提示词 — 单任务内迭代：generate → self-feedback → refine 循环

Madaan et al. 2023。在一个 trajectory 里循环 N 轮，无外部 reward、无跨任务记忆。7 个任务平均提升 20%。

陷阱：弱模型自评不准，可能越改越差。生产常组合 Self-Refine（局内）+ Reflexion（跨局）。

self-consistency 提示词 — 对同一问题采样 N 条 CoT，对最终答案做 majority vote

Wang et al. 2022。temperature>0 采样 N 条 CoT 路径，对最终答案投票。GSM8K 上比 greedy CoT 提升 ~17 个百分点（PaLM 55%→74%）。

收益大场景：(1) 答案空间离散（数字、选择题）；(2) 模型错误率 <50%；(3) 推理路径多样（temperature 0.7-1.0）。代价：N×（典型 N=5-40），开放生成不适用。

few-shot / zero-shot 提示词 — Prompt 中给/不给示例

Zero-shot：直接说要求，无示例。"翻译成英文：你好"
Few-shot（in-context learning）：prompt 里给 1-N 个 (输入, 输出) 示例。GPT-3 论文最早系统化。

何时 few-shot：(1) 任务格式新颖/输出结构复杂（JSON schema、特定 markdown）；(2) 分类任务标签多。

何时 zero-shot：通用任务现代模型已饱和（摘要、翻译、QA），加 example 反而引入偏差。

陷阱：example 顺序影响大（recency bias）；偶然规律会被学走；example 多了 Lost in the Middle。建议 ≤8 条。

RAG

RAG / Retrieval-Augmented Generation RAG — 检索增强生成：先检索相关文档，再让 LLM 基于上下文回答

标准 pipeline = Ingestion + Retrieval + Generation：

Ingestion：document loader → chunking → embedding → 向量库写入
Retrieval：query rewriting → embedding → vector search → reranker → top-k
Generation：构造 prompt（含 retrieved chunks）→ LLM 生成 → 后处理 + citation

每段都有瓶颈：chunking 切大小、embedding 选型、召回率不足、context 顺序、模型不忠于 context。生产 RAG ≠ "embedding + 向量库 + LLM"——是一个工程系统。

chunking RAG — 把文档切成适合 embedding / 检索的小块

策略：

Fixed：按 token + overlap，简单但易在句中段中断
Recursive / Structural：按 markdown header / code block / paragraph 切，生产默认
Semantic：按句间 embedding 相似度切
Late Chunking（Jina 2024）：先 long-context embedding 整文档，再 token-level 切
Contextual Retrieval（Anthropic 2024）：每个 chunk 加 LLM 生成的"上下文前缀"再 embed，retrieval 失败率降 49%

BM25 RAG — 基于词频 + IDF 的经典稀疏检索算法

Okapi BM25。文档与 query 的相关性按 Σ IDF(qi) · f(qi,d) · (k+1) / (f + k·(1-b+b·|d|/avgdl)) 计算。强项：精确词命中、稀有词高权重、专有名词、数字。短板：同义词不通（"医生" vs "doctor"）。

与 dense embedding 互补——hybrid search 把两者融合，召回率比单 dense 提升 5-15 个百分点。

hybrid search RAG — dense embedding + BM25 双路召回 + 融合

dense embedding 擅长语义近似，BM25 擅长精确词匹配，两者互补。

融合方法：

RRF (Reciprocal Rank Fusion)：score(d) = Σ 1/(k + rank_i(d))，k=60。生产首选，无需归一化两路分数
加权和：α·dense + (1-α)·bm25，需要调 α 且分数归一化
学习式融合：把 top-N 喂 reranker 接管最终排序

Anthropic Contextual Retrieval 实验：单 embedding → +contextual embedding → +BM25 → +rerank，失败率 5.7% → 4.0% → 3.7% → 1.9%。

reranker / cross-encoder RAG — 把召回 top-N 用更精确（更慢）的模型重新打分

Bi-encoder（embedding）：query / doc 分别编码再 cosine 比对，快但无交互。
Cross-encoder（reranker）：query + doc 拼接喂 transformer，每层 self-attention 交互，相关性建模能力强 20-40%（NDCG@10），慢 100×。

生产标配：bi-encoder 召回 top-100 → cross-encoder rerank 到 top-10 → 喂 LLM。

主流：Cohere Rerank v3/v4、BGE-reranker-v2-m3（开源 SOTA 中英）、Jina Reranker v2、Mixedbread。

陷阱：召回 top-100 里没有相关文档，rerank 也救不了——reranker 锦上添花，不能替代召回。

主流 embedding 模型选型 RAG — BGE-M3 / Cohere v4 / Voyage-3 / OpenAI text-3-large / Qwen3-Embedding 怎么选

2026 主流 embedding 模型对比：

OpenAI text-embedding-3-large（3072 维）：英文 baseline，API 友好，$0.13/M tokens；中文一般。
Cohere embed-v4（1024-1536 维，多模态）：MTEB v2 顶级，支持文本+图像同空间，多语言 100+；企业 SaaS 首选。
Voyage-3-large（1024 维）：MTEB v2 综合第一，中文表现优秀，retrieval 任务略胜 Cohere。
BGE-M3（BAAI，1024 维）：开源 SOTA，同时支持 dense + sparse + multi-vector (ColBERT-style) 三种模式，中英双语；自托管首选。
Qwen3-Embedding-8B（阿里 2025）：开源中文 SOTA 之一，与 BGE-M3 各有胜场。
Conan-Embedding（腾讯）/ Yi-Embedding（零一）：国产中文方案。

选型框架：

中文为主 → BGE-M3 / Voyage-3 / Qwen3-Embedding
多模态 → Cohere v4
纯英文 + API → OpenAI text-3-large
自托管私有部署 → BGE-M3

关键陷阱：

MTEB 有版本差异（v1 / v2 / MMTEB），不同模型挂的版本不一样，直接横比误导——自家场景必须重测
Dense vs Sparse 看场景：精确词命中（专有名词 / 编号）BM25 + dense 混合（hybrid search）比单 dense 提升 5-15pp

vector DB / 向量数据库 RAG — 专门存 embedding 并支持近似最近邻 (ANN) 检索；Pinecone / Milvus / Qdrant 等

主流：

Pinecone：SaaS，企业首选
Milvus：开源 + 云
Qdrant：Rust 写，性能好
Weaviate：带知识图谱功能
pgvector：Postgres 扩展，已有 PG 直接用
Vespa / Elasticsearch：搜索引擎扩展向量
Chroma：本地开发友好

ANN 算法：HNSW（最常见）、IVF、ScaNN（Google）。索引时间 vs 检索精度 vs 显存有 trade-off。

GraphRAG / Self-RAG / CRAG / Agentic RAG RAG — 朴素 RAG 的 4 个进阶变体，各解决不同短板

朴素 RAG 在多文档跨实体推理、召回质量不稳、多跳查询场景下都会力不从心。四个常见进阶方案：

GraphRAG（微软 2024）：先用 LLM 从文档抽 entity + relation 建知识图谱，按社区做层次摘要；query 时既能 vector search 又能图遍历。解决"跨多文档跨实体推理时朴素 RAG 召回不全"。代价：ingestion 成本大涨（每 chunk 一次 LLM 抽取）。
Self-RAG（Asai 2023）：训练单一 LM 自己生成 reflection token 决定 (a) 要不要检索 (b) retrieved 是否相关 (c) answer 是否被 context 支撑 (d) 整体 utility。解决"什么时候检索、检索后怎么用"的判断。需训练。
CRAG (Corrective RAG，Yan 2024)：retrieved chunks 经 lightweight evaluator 打分，分高直接用、中等触发 web 重新搜索、低退回基础生成。解决"召回质量参差不齐"时盲目使用 retrieved。
Agentic RAG：让 agent 决定 query rewriting → 多轮检索 → 子 agent 分工。解决多跳问题、需迭代检索。DeepResearch 类产品就是这一路。

实战选择：

普通 QA → 朴素 RAG + reranker
跨文档跨实体复杂推理 → GraphRAG
召回质量不稳 → CRAG
多跳推理 / 需迭代搜索 → Agentic RAG

RAGAS RAG — RAG 评估事实标准，4 大核心指标都用 LLM-as-judge 实现

Es et al. 2023。四大指标：

Faithfulness（忠实度）：答案中每个 claim 能否从检索 context 推出。<0.7 = 模型在编造
Context Precision（检索精度）：top-K 中真正相关的占比。低 = retriever 召回噪声
Context Recall（检索召回）：ground truth 信息是否都被检索到。低 = 召回不全
Answer Relevancy（答案相关性）：答案是否真的回答了原问题

生产阈值：4 个指标都 ≥0.7 算合格；Faithfulness < 0.7 优先修；Context Recall < 0.7 调 retriever。

Agent 工程

harness / harness engineering Agent — 包裹 LLM 的代码骨架与工程化体系，让 agent 物理上无法重复犯错

Mitchell Hashimoto 2026 命名："anytime you find an agent makes a mistake, take the time to engineer a solution such that the agent never makes that mistake again."

不是模型微调，而是工程化环境让模型物理上无法以同样方式再犯错。

两条法则：

强约束：能用 deterministic 约束（lint / type check / sandbox / CI 硬失败）就不用 prompt
自愈循环：agent 能从环境拿 ground truth、自我评估、失败可 checkpoint 恢复

OpenAI 公式：Agent = Model + Harness；"Humans steer. Agents execute."

LangChain / LangGraph / LlamaIndex / Haystack Agent — 主流 Agent / LLM 应用开发框架

2024-2026 主流框架对比：

LangChain（Harrison Chase / LangChain Inc.）：最早出圈的 LLM 应用框架，定位是"LLM 应用的胶水"——连 LLM、prompt 模板、工具、向量库、文档加载器。优点：生态最全；缺点：抽象层多容易过度封装，Anthropic Building Effective Agents 明确反对"过度抽象"。
LangGraph（LangChain Inc.）：基于 LangChain 的有状态 graph 编排——把 agent / workflow 建模成节点 + 边，每个节点是 LLM 调用或工具，边可条件跳转。比 LangChain 更适合复杂多步 / 多 agent 协同；阿里飞猪等多 agent 业务系统主流选择之一。
LlamaIndex（Jerry Liu）：聚焦 RAG，文档摄取 / 索引 / 检索 / 查询 pipeline 设计精细。RAG 重场景比 LangChain 更专业。
Haystack（deepset）：开源 RAG 框架，企业级（含 K8s 部署 / API server），欧洲社区主导。
Anthropic SDK 直调：Anthropic 在 Building Effective Agents 推荐——简单场景直接调 API 比裹一层 framework 更易理解、bug 更少。

经验：先用 SDK 直调写原型；workflow 模式（routing / parallelization / orchestrator-workers）成熟后再考虑 LangGraph；纯 RAG 场景考虑 LlamaIndex；避免一上来就 LangChain "全家桶"。

MCP / Model Context Protocol Agent — Anthropic 推出的开放协议，让 LLM 客户端用统一接口连接外部工具/数据源

2024-11 推出，2025-Q4 转入独立 Steering Committee（Anthropic / Block / OpenAI / Microsoft）。三种核心原语：

Resources：可读资源（文件、DB 行）
Tools：可执行函数（带 schema）
Prompts：可复用 prompt 模板

解决"每接一个新工具就要写一遍 adapter"的 N×M 问题。2026 年增速最快的单一技能，97M+ 月下载，已是 Anthropic Applied AI Engineer JD 显式必备。

tool use / function calling Agent — LLM 通过结构化 schema 调用外部函数

模型输出 {"name": "search", "arguments": {"query": "..."}} JSON，runtime 解析后真实执行函数，结果回喂模型。Anthropic Tool Use API、OpenAI function calling 都是同思路。

设计原则（Anthropic 实测："agent 性能正比于工具描述清晰度"）：

工具描述像写 docstring：用途 / 参数 / 返回值 / 错误情况
粒度小、组合强（Read / Edit / Bash / Grep 而非 do_anything）
强制前置约束（Edit 强制 Read-before-Edit）
错误信息当 prompt（"command not found, did you mean X?"）
Deny-first 权限

Computer Use / Browser Agent Agent — 让模型操作桌面 GUI 或浏览器

Anthropic 2024-Q4 推出 Computer Use。流程：截屏 → LLM 看图 + 推理 → 输出鼠标键盘动作（click X,Y / type text / scroll）→ 系统执行 → 再截屏循环。

Browser Use（开源框架）类似但限于浏览器，基于 Playwright + DOM 增强（把可点击元素加序号叠加到截图）。

实用场景：无 API 网站自动化、桌面软件自动化、端到端 e2e 测试。局限：慢、贵、安全性差、对 canvas 渲染应用支持差。生产建议：能用 API 就别用。

sub-agent Agent — 主 agent 派出的、有独立 context 的子任务 agent

主 agent 把"读 30 个文件做研究"丢给 sub-agent，sub-agent 有自己的独立 context 窗口，只把 final summary 回报给主 agent——主 context 不被中间产物污染。

Claude Code Task 工具、OpenAI Swarm、CrewAI 等都支持。是防止 Loop of Death 和 context 爆炸的关键手段之一。

AGENTS.md / CLAUDE.md Agent — 给 agent 看的项目说明书，写明协议 / 约束 / 启动流程

Agent 进入项目时自动读取。通常包含：

项目背景 / 架构概览
5 步会话开机协议：pwd → git log → progress 文件 → 启动 dev server → 跑基础测试
编码规范 / 风格约束
禁止操作（生产环境、敏感目录、unsafe 命令）
已知坑 / 反模式
测试运行方式

Hashimoto 视角：每行 AGENTS.md ≈ 一次错误的封堵。是 harness engineering 的隐式提示形态。

deny-first Agent — 默认禁止所有工具/命令，显式白名单才允许

Claude Code 采用的权限模型。Bash 命令按 verb + path 粒度授权：

git status allow
git push --force deny（destructive）
rm -rf 弹出用户确认
cat ~/.ssh/* deny（敏感路径）

对应安全原则：任一层失守，其他层兜底。配合 sandbox、网络出口白名单、文件系统只读做纵深防御。

progress 文件 / progress.md Agent — 把 agent 任务进度持久化到文件，跨会话续跑

Anthropic Effective Harnesses 给的核心设计：长任务 agent 必然跑爆 context window，纯靠 LLM context 不可能记住"我跑到第几步"。

解法：

progress.md / PLAN.md：agent 每完成一个里程碑写"已完成 X / 当前在 Y / 下一步 Z / 关键决策 / 风险点"
git commit：每次代码改动强制 git commit + descriptive message，git log 本身就是工作日志，且能回退到任意状态

下次会话执行 5 步开机协议从断点续跑。核心洞察：context window 是"working memory"，文件系统是"long-term memory"。

Loop of Death Agent — Agent 进入无限循环烧 token 直到耗尽

常见模式：

重试循环：tool 失败 → 重试一模一样的调用 → 再失败……
目标漂移：每步小修小补但整体没进展
互相否定：multi-agent 反复推翻对方决策
格式幻觉：死磕调不通的工具调用格式

防御纵深：

硬性 max iteration（5-30 步）
Execution timeout（5-30 分钟）
Token budget（per-task hard cap）
进度检测（连续 N 步无 diff 强停）
失败重复检测（同 tool call 失败 3 次跳出）
成本告警 + HITL

Memory Corruption / 记忆污染 Agent — 错误事实进入长期记忆后污染所有后续决策

例：用户开玩笑"我是亿万富翁"被存进语义记忆，之后 agent 一直按假设推理。

防御：

写入门槛：LLM 评估"事实可信度 + long-term value"双高才写
来源标记：每条 memory 带 source（user_said / tool_returned / inferred）+ confidence
TTL 衰减：低 confidence 短 TTL
审计 trail：所有 memory 写入有 trace_id
用户可见可编辑：GDPR 合规 + 污染纠正
prompt injection 防御：tool 返回数据标 untrusted，不直接写入

评估与安全

Trace + Eval 工具栈 评估 — Langfuse / LangSmith / Phoenix / Helicone / Patronus 等可观测平台

LLM 应用 / Agent 的"全链路追踪 + 评估"工具，2026 主流：

Langfuse（开源 + SaaS）：开源 SOTA，self-hostable，trace + prompt 版本化 + eval + cost 跟踪一站式。中小团队首选。
LangSmith（LangChain Inc.，闭源 SaaS）：LangChain 生态原生集成最深，trace 可视化好，eval framework 成熟。
Phoenix（Arize AI 开源）：聚焦 LLM 应用的 trace + monitoring，集成 OpenTelemetry 好。
Helicone（开源 + SaaS）：proxy 模式接入快，cost / cache hit / latency 监控直观。
Patronus（SaaS）：聚焦"hallucination / safety detector"，做生产级实时拦截，企业方向。
Datadog / Grafana / Prometheus：通用 APM / metrics 平台也开始支持 LLM trace（Datadog LLM Observability、Grafana Tempo）。

核心能力对齐项：

Trace：prompt → tool_call → response → cost / latency 串成完整 trace
Prompt 版本化：每次 prompt 改动一个 hash，可在 dashboard 切换并对比
Eval：CI 上跑黄金集，回归报警
Cost & Cache hit rate：单 trace 成本、cache 命中分布
User feedback / thumb up-down：直接打到 trace 上做 bad case 入库

选型：自建优先 Langfuse；LangChain 重度用户 LangSmith；纯 trace 监控用 Phoenix；安全 / 实时拦截用 Patronus。

主流 LLM eval benchmark 评估 — MMLU / MT-Bench / Chatbot Arena / HumanEval / LiveBench / BFCL 各测什么

按测什么能力分类：

MMLU (Massive Multitask Language Understanding)：57 学科多选题，通用知识基准；GPT-4 ~88%。批评：题目泄漏严重、单选难辨细节差异。
HumanEval（OpenAI 2021）：164 道 Python 编程题 + 单测验证，代码生成基准。已被刷穿（多数前沿模型 90%+），不再有区分度，推荐 SWE-bench Verified。
MT-Bench（LMSYS 2023）：80 道多轮对话题，用 GPT-4 当 judge 1-10 打分。对话能力经典 benchmark，但 judge bias 严重。
Chatbot Arena / LMArena（LMSYS / Berkeley）：真人盲评 pairwise，Elo 评分。最权威也最贵；2024 起被怀疑刷分（厂商针对性优化"问候 / 解释 / 列表格式"等 Arena 偏好）。
LiveBench（Abacus AI 等）：月度更新题目防数据污染，coverage 推理 / 数学 / 代码 / 语言 / 数据 / 指令；持续更新性最强。
BFCL (Berkeley Function-Calling Leaderboard)：Tool use / function calling 标准 benchmark，含 simple / multiple / parallel / multi-turn。
GSM8K / MATH / AIME：数学推理基准，AIME 是 R1 / o1 当前主战场。

实战：从 2026 视角，单一 benchmark 都已不可信——必须多 benchmark 交叉验证 + 自家黄金集 + Arena 真人盲评三层。

Eval / Evaluation 评估 — LLM 应用 / Agent 的"打分"环节：offline / online / CI 三层评估

LLM / Agent 应用的 eval 不是单一动作，是一套体系。常见层次：

Offline eval：在固定 dataset / 黄金集上跑模型 / prompt / pipeline，看指标。每次 prompt 改动跑回归，CI 上自动化。
Online eval：线上流量上抽样评估，配合 A/B 看业务 metric 变化、bad case 检测、用户反馈打标。
Pre-prod eval：上线前在预发流量上做 shadow eval（双跑不返回用户），对比新旧版本轨迹差异。
Adversarial eval / Red team：人工 + 自动化构造对抗样本（jailbreak、prompt injection、edge case），评估安全护栏。

Eval 工具栈分类：

通用 framework：OpenAI Evals、DeepEval、Promptfoo、Inspect AI——CLI / 库形式跑评估
集成在可观测平台：Langfuse / LangSmith / Phoenix 都内置 eval framework，与 trace 联动
RAG 专用：RAGAS（faithfulness / context relevancy 等 4 维）
Tool use 专用：BFCL（Berkeley Function-Calling Leaderboard）
领域专用：每家自家黄金集 + LLM-judge rubric

Eval 类型按打分方式：

Reference-based（有标准答案）：精确匹配、BLEU / ROUGE、单测通过、答案集合命中——客观但需标注
Reference-free（无标准答案）：LLM-as-judge 给 0-1 分或 1-5 分；适合开放生成、对话；judge bias 是大坑
Pairwise：A vs B 对比，模型选型常用，agreement 比 pointwise 高
User feedback：thumb up/down、CSAT、留存——业务侧最终验收

经验法则：(1) 没 eval 就改 prompt = 改盲；(2) Eval model 必须 ≥ 被评估 model（判官原则）；(3) 黄金集要版本化 + 私有；(4) 每个 bad case 都要回归进黄金集——harness engineering 闭环。

LLM-as-judge 评估 — 用强 LLM 给候选输出打分，替代人工评估

把"评估"建模成 LLM 任务：让 judge 模型读 (prompt, response)，输出 0-1 分 / pass/fail / pairwise 谁更好。可大规模并行、便宜、可在 CI 自动化。

三大 bias：

Position bias：pairwise 时 judge 偏 A 或 B
Verbosity bias：偏好更长回答
Self-preference：GPT-4 偏好 GPT-4 输出

判官原则：judge 模型能力应 ≥ 被评估模型，否则评不出大模型回答好在哪。生产标配三层：自家黄金集 + LLM judge + 人工校准。

Lost in the Middle 评估 — 长上下文 QA 中，关键信息放中间时模型准确率显著下降

Liu et al. 2023 实验：把 gold passage 放 prompt 开头或结尾，模型准确率高；放中间则呈 U 形曲线下降，10+ documents 时中间位置可能低于无上下文 baseline。

工程缓解：

重排——把最相关 chunk 放最前/最后（reranker + 头尾穿插）
多轮检索 + 摘要而非一次塞满
用支持原生长上下文的模型（Claude / Gemini 1.5 Pro 在 RULER 上更稳）

prompt injection 安全 — 用户或外部内容劫持模型行为，绕过 system prompt

OWASP LLM Top 10 的 #1。类型：

直接注入："ignore previous instructions, do X"
间接注入：恶意指令藏在 RAG 文档 / 网页 / PDF / 邮件 / 工具返回里——agent 时代的头号威胁
越狱（jailbreak）：DAN / role-play / many-shot
Payload smuggling：Base64 / Unicode 同形 / 图片 OCR 注入
Tool 滥用：让 agent 调敏感工具

Simon Willison 结论：prompt injection 没有 100% 解，必须按"LLM 不可信"做系统设计。dual-LLM 模式 = Planner（看 trusted 决策）+ Executor（看 untrusted 但无工具权限）。

hallucination / 幻觉 评估 — 模型生成看似合理但实际错误的内容

来源：

训练数据偏差 / 过时
RAG 召回不全或不准
Context 太长信号被稀释
模型自由发挥（无 grounding）

debug 流程：复现 + 量化触发率 → 归因（RAG 召回 / 模型用 context / 工具调用）→ 修复 → 加回归 → 生产监控（faithfulness scorer 实时拦截）。

关键认知：hallucination 多数是 prompt / RAG / 上下文工程缺陷，不是"模型病了"。

guardrails 安全 — 围绕 LLM 的输入/输出/工具/对话各环节的安全护栏

NVIDIA NeMo Guardrails 5 类：

Input rails：PII 脱敏、prompt injection 检测、topic 限定
Dialog rails：基于 Colang DSL 控制对话流，硬编码关键决策点
Retrieval rails：剔除低质 / 敏感 / 不可信 chunk
Execution rails：工具调用前参数白名单 / 授权检查
Output rails：幻觉检测 / 敏感数据外泄过滤 / 毒性过滤

关键：rail 不是越多越好，每类挑 1-2 个高 ROI 的开，否则延迟/成本爆炸。

jailbreak / 越狱 安全 — 绕开模型安全训练让它输出有害内容

常见手法：

DAN（Do Anything Now）：让模型扮演无限制 AI
Role-play："我们写小说，角色 X 解释如何做 Y"
Many-shot（Anthropic 2024 披露）：长 context 塞几十个假问答示例，让模型 ICL 后顺着回答
Crescendo：多轮渐进式拉到敏感话题
Encoding：Base64 / leetspeak / 低资源语言绕过

防御：厂商 RLHF safety training + 应用层 input/output classifier（Llama Guard）+ 限制 max context（对抗 many-shot）+ red team 定期演练。

Bibliography（关键来源汇总）

论文 / 学术资源

业界 / 官方资料

Methodology Appendix

本报告所有事实声明均尽力基于一手来源；若发现错误请按上面 Bibliography 链接核实。具体模型版本号 / 价格 / benchmark 分数等”硬数字”建议读者按发布日期查最新版。

AI Agent / LLM 应用工程师面试题与答案研究报告