前几天我在一轮 LLM 面试里挂了一个候选人。简历非常漂亮：微调过 7B 模型、搭过 RAG 知识库、做过 Agent 工具调用，项目经历满满一页。结果我问他“LoRA 的秩为什么选 16”，他说因为教程默认 16；我问“注意力公式里为什么要除以根号 d”，他沉默；我又问“长对话下 KV Cache 大概占多少显存”，他开始讲 batch size 的配置。
这三个问题其实都不算难题，但它们挂在那个节点上，整场面试基本可以宣告结束了。我做技术面试官这几年，最常遇到的情况不是候选人不懂，而是候选人把大模型当成了一个“背知识点的东西”来准备。所以这篇我把 LLM 面试里出现频率最高、答不上来大概率被淘汰的 8 个问题逐一拆开，讲清楚面试官到底在问什么、期望听到什么、为什么你答不好就会被挂。
1. 淘汰背后：这 8 题考察的能力边界在哪里
先说一个很多人没想明白的事：面试官问这些题，不是要考你背书能力。大模型方向现在的技术栈非常杂，从数据管线到训练调优、从推理部署到评测迭代，每一层都有大量细节。一个岗位面试只有几十分钟，面试官必须在有限时间里快速判断你有没有“真正上手做过东西”，而不是只看简历上写了什么。
我自己的经验是，候选人回答问题通常有三个层次：
| 层次 | 表现 | 面试官判断 |
|---|---|---|
| 背概念 | 能说出名词定义，但说不出为什么 | 可能读过文档，但没踩过坑 |
| 懂原理 | 能推导公式、讲清机制 | 有基础，可培养 |
| 能落地 | 能结合工程场景讲取舍、讲代价 | 直接可用，大概率能独立扛项目 |
这 8 个问题分别对应四类能力：原理深度、工程落地、评估体系、系统设计。比如注意力机制考原理，Tokenizer 和数据清洗考工程，幻觉治理考系统设计，评测方法考复盘能力。一个候选人如果四类里有两类以上答得空洞，我就会怀疑简历里的项目是不是只做了很浅的参与。
这也是为什么标题说“答不上来直接淘汰”。不是说面试官故意卡人，而是这些问题背后都默认了一件事：你至少亲手跑通过一条像样的模型链路。没跑过的人，哪怕背了再多概念，一到追问就会露馅。
2. 第一道必问题：注意力机制为什么总被拿来当试金石
2.1 问题形态与标准回答
面试官起手大概率问：“讲一下 Transformer 的注意力机制，Q、K、V 分别是什么？”这是最简单也最容易被小看的问题。标准回答是：
[ Attention(Q,K,V)=softmax(\frac{QK^T}{\sqrt{d_k}})V ]
Q 是查询向量，K 是键向量，V 是值向量。Q 和 K 做点积得到相关性分数，除以根号 d_k 缩放后过 softmax 变成权重，再对 V 加权求和。
多数人能答到这里。但接下来才是关键。
2.2 追问一：为什么除以根号 d_k
这个问题能筛掉一大半人。原因有两层：
第一层是从方差角度。如果 Q 和 K 的每个维度都是均值为 0、方差为 1 的独立随机变量，那么 Q 和 K 的点积结果是 d_k 个乘积之和，方差会变成 d_k。点积数值的绝对值会随维度变大而变大，softmax 对大的输入非常敏感，梯度会变得极小，训练基本推不动。除以根号 d_k 就是把方差重新压回 1 附近，让 softmax 处于梯度合理的工作区间。
第二层是从物理意义角度。缩放系数本质上是调节注意力分布的“温度”。除以根号 d 等价于让 logits 变小，分布更平滑；不除的话分布会更尖锐，几乎变成 one-hot，丢失上下文信息。
我面过不少候选人，能把第一层说清楚的大概只有一半，能主动提温度解释的更少。能答到这层，说明你不仅看过公式，还想过它的数值行为。
2.3 追问二：多头注意力的计算复杂度与显存体感
追问节奏一般是“那注意力计算复杂度是多少，为什么长文本很费显存”。QK^T 得到的是一个 n×n 的矩阵，所以单头注意力的计算复杂度是 O(n²)，n 是序列长度。这个 n² 是长上下文的核心瓶颈，也是后面 KV Cache 问题的铺垫。
这里有个常见的低分回答：候选人背出了“复杂度是 O(n²)”就停了。高分回答会顺带讲工程体感：“所以 Flash Attention 才要把计算分块，把 QK^T 的结果留在 SRAM 而不是写回显存；也正因为复杂度是平方增长，从 2K 到 8K 上下文，光注意力计算量就涨 16 倍，所以业界才对稀疏注意力、线性注意力那么感兴趣。”能主动提到 Flash Attention，面试官通常会愿意继续深聊，因为这说明你真的部署过。
2.4 我见过的高分答法
有一个候选人我印象很深。他答完公式后直接说：“实际部署的时候，我还会关心另一个问题——QK^T 中间矩阵不能落显存。所以我会用 torch.compile 配 flash attention kernel；如果算子不支持，我宁可把 batch size 调小也不会强行堆长序列。”这种回答信息量完全不同，等于亲口告诉面试官：我跑过训练/推理，我知道瓶颈在哪。
3. 第二道必问题：Tokenizer 与数据出口——真正干活的人才答得上来的细节
3.1 问题形态
“分词器是怎么工作的？BPE 和 WordPiece 有什么区别？”这题看起来偏基础，但特别能区分做没做过训练。因为 tokenizer 直接决定了数据进入模型的方式，而数据质量又决定了下游效果的一半。
3.2 BPE 和 WordPiece 的本质区别
BPE（Byte Pair Encoding）的核心思路是从字符开始，反复合并出现频率最高的相邻 token 对，直到达到目标词表大小。合并的候选不涉及任何概率模型，只看频次。
WordPiece 不一样，它选择合并的依据不是原始频次，而是合并后能让语言模型似然增加最多的那一对，本质上是在算互信息或者似然增益。所以 WordPiece 对语义边界的敏感度通常更高，但实现和训练也更复杂。SentencePiece 则是一个把“文本->token”整套流程统一起来的工具，支持 BPE/Unigram 等不同算法，并且把空白字符也当成普通符号处理，避免了“词前带空格”导致的词表膨胀。
大多数候选人能说出“BPE 是频率合并”，但被问 WordPiece 和 BPE 差异时就卡住。如果你做过数据侧工作，这题应该是送分题，因为你在清洗和构造训练语料时会明显感觉到两种策略对样本质量的要求不同。
3.3 高频追问：OOV 怎么办，数字和中文怎么切
继续追问一般是“遇到 OOV（词表外词）怎么做”。现代 BPE 基本都是 byte-level，理论上任何 Unicode 字符都能被拆成字节片段，所以 OOV 问题被极大缓解了，代价是单个 token 的信息密度变低。
中文和大数字是 Tokenizer 最容易翻车的地方。很多中文模型一个常用汉字会被切成一个 token，但某些生僻字要拆成两个甚至三个 byte 片段。数字更麻烦，“123456”可能被切成一串零散 token，模型对数字的感知能力直接变差。做过训练的人会告诉你，数字最好统一格式，加入正则把连续数字归一化或强制按位分组，否则数学能力会被分词方式拖后腿。
3.4 数据标注和清洗的坑
这题我很喜欢追问“你训练数据里有没有遇过 token 爆炸”。我处理用户评论类数据时踩过一个大坑：数据里混了大量网址、Emoji 变体、乱码字符。BPE 在计算合并频率时把这些低频但杂乱的符号也纳入了统计，最后词表里堆了几百个只出现一两次的垃圾 token，既浪费词表容量，又拉低句子的 token 利用率。
后来我统一做了清洗：URL 用占位符替换、Emoji 按大类映射、乱码直接过滤、再跑一遍重复检测。清洗后训练语料的 token 总数直接降了 15%，训练速度也明显提升。所以如果你准备面试，可以从“数据出口决定模型效果上限”这个角度准备答案，比单纯背双字母组合定义强得多。
4. 第三道必问题：采样参数不是背出来的，是算出来的
4.1 问题形态
“生成时 temperature、top-k、top-p 分别是怎么工作的？你平时怎么配？”这题考察的也是真做过的程度。因为没跑过服务的人，对这几个参数的理解通常停留在“temperature 调高更随机”这种模糊层面。
4.2 temperature 的本质公式
temperature 不是一个直接加到概率上的系数，它作用在 logits 上。假设第 i 个 token 的 logit 是 l_i，temperature 为 T，那么 softmax 变成：
[ p_i=\frac{\exp(l_i/T)}{\sum_j \exp(l_j/T)} ]
当 T 趋近 0，最大 logit 对应的概率趋近 1，生成变成贪心；当 T 变大，所有 logit 被抹平，分布趋于均匀，生成更多样。T=1 就是不做缩放。注意“T 越大越随机”只是近似描述，准确地说 T 改变的是分布的尖锐程度，不是注入随机性。
Top-k 是只保留 logits 最高的 k 个候选重新归一化；top-p 是保留概率累积达到 p 的最小候选集合。两者可以连用，实践中很常见。
4.3 参数对比
| 方法 | 控制维度 | 适用场景 | 常见风险 |
|---|---|---|---|
| temperature | 全局分布尖锐度 | 对话、写作 | T 过大容易胡言乱语 |
| top-k | 候选数量硬截断 | 通用生成 | k 太大等于没截，k 太小限制多样性 |
| top-p | 累积概率软截断 | 对话/摘要 | p 接近 1 时基本无作用 |
| beam search | 多条候选打分 | 翻译、摘要 | 对话类容易重复单调 |
4.4 实战参数与一次事故
我在代码生成任务里的经验配置是 T=0.2、top-p=0.9，偶尔加 temperature 0.1 的重复惩罚。开放域写作会调到 T=0.8、top-p=0.95。
有一次我做客服助手，为了让它更“活泼”把 T 拉到 0.9，结果模型开始一本正经编造不存在的退款规则。事后排查发现 T 过高让低概率的幻觉 token 更容易冒头。生产环境里我后来统一改成 T=0.4 以下，再用系统层约束兜底。这题答到这种细节，面试官基本就会觉得你有线上服务的体感。
5. 第四道必问题：微调选型——你是在背名词还是在做工程
5.1 问题形态
“项目里你做过微调吗？为什么选 LoRA 而不是全参数？”这道题被问到的概率极高，也是最容易暴露简历水分的地方。
5.2 三种方式的取舍
全参数微调：把所有参数都更新。效果上限最高，对数据量要求也高，训练成本最大。7B 模型用 AdamW 做全参数微调，优化器状态加梯度加参数本身，显存开销大约是参数量的 16~20 倍，也就是 7B 模型至少要上百 GB 显存，单卡基本跑不动。
LoRA 的核心是低秩分解：冻结原权重 W，只训练两个低秩矩阵 A 和 B，更新量为 ΔW = A×B。秩 r 一般取 8、16、32、64。可训练参数量变成 r×d 级别，比如 7B 模型用 r=16 时，trainable 参数可能只有 0.1%~1%，显存大幅下降。代价是表达空间受限，理论上不如全参灵活。
前缀微调（P-tuning v2）则是在输入序列前加一组可学习的连续向量，只训练这些前缀参数。它不改变权重，靠提示向量引导模型行为。优点是参数更少、切换任务很快，缺点是可解释性差，效果对初始化敏感。
5.3 训练成本怎么算
面试里你可以直接给一个数量级感：全参微调 7B 通常要 4~8 张 80G 显卡，LoRA 微调单张 24G 勉强能跑，prefix-tuning 甚至可以更低。这些数字不需要很精确，但能说出来说明你至少规划过预算。
5.4 LoRA 的秩怎么选：实操心得
关于秩，我翻了两次车之后总结的经验是：
- 数据量小（几百条）用 r=8，防止过拟合；
- 任务复杂但数据中等（几千条）用 r=16~32；
- 数据量很大且领域专精，可以试 r=64，配合早停观察验证集 loss。
最直接的判断方法是看训练集 loss 和验证集 loss 的剪刀差。如果训练 loss 降很快但验证 loss 不动，先降秩，同时加 dropout，而不是盲目加数据。
这里我要特别提醒一点：如果你简历写了微调，面试官大概率会追问“你的 base 模型是哪个，用的什么框架，数据量多少，怎么判断效果”。如果答不上这些细节，比直接承认没做过更扣分。
6. 第五道必问题：RAG 和微调的分界线，是最典型的工程选型题
6.1 问题形态
“客户有一个知识库，经常更新，你选择 RAG 还是微调？”这是工程选型题，没有标准答案，考察的是你的取舍逻辑。
6.2 判断框架
我的回答框架是四维判断：
| 维度 | 倾向 RAG | 倾向微调 |
|---|---|---|
| 知识时效性 | 知识频繁更新 | 知识相对稳定 |
| 可解释性 | 需要引用来源、追责 | 只关心输出效果 |
| 成本 | 算力有限，快速上线 | 有训练资源，批量调用 |
| 数据形态 | 文档零散、规模大 | 结构化的指令-期望输出对 |
还有一个很少有人提的点：知识密度。如果知识库是几十万篇文档，RAG 几乎是唯一现实选项，因为你很难把几十万篇文档的内容都塞进模型参数里，即便微调能记住，也会有严重的灾难性遗忘。
6.3 常见的“混用”方案
高分回答不是二选一，而是讲混用：RAG 负责实时信息和外部知识的召回，微调负责格式、语气和指令遵循能力。比如客服场景，政策文档走 RAG 检索引用，但“如何礼貌拒绝用户、如何缩写话术”这种风格问题走轻量 LoRA。前者解决“知识不存在”，后者解决“表达不对”。
6.4 我翻车过的项目
我有过一次很深刻的教训。做一个内部知识问答系统时，团队为了“省掉检索链路的复杂度”，直接对领域语料做了全参微调。结果模型对训练文档里的具体数字记得很牢，但对训练集之外的新政策一概胡编。后来改成 RAG 方案，把文档切块、向量检索、引用标注，又用一个小 LoRA 修输出格式，整体幻觉率降了接近一半。
所以我现在面试听到“我们应该先微调”这种结论时，都会追问“为什么不是 RAG”。不是微调不对，而是如果候选人没有比较过二者代价，说明他大概率没经历过真实的知识类项目。
7. 第六道必问题：幻觉治理——怎么把 AI 系统做成可靠系统
7.1 问题形态
“模型总在编造答案，你怎么解决？”这题是所有做过生产项目的人都会遇到的。回答如果只说“在 prompt 里加‘不要编造’”，基本等于没答。
7.2 分层回答框架
我的回答会分三层：
第一层是数据侧。训练和微调数据里，凡是知识型问答，尽量构造“问题-支撑材料-答案”三元组，让模型学会基于材料回答，而不是凭记忆补全。如果模型对训练材料的记忆很深，可以混入“拒答样本”，强化不知道时主动承认。
第二层是模型侧。解码参数上把温度压低，降低低概率 token 被采中的几率，配合 top-p 截断。更深的是偏好对齐，构造“有依据回答 > 含糊回答 > 编造回答”的偏好对做 DPO，让模型在策略层面学会拒答。
第三层是系统侧。这是决定可靠性的关键。检索链路要带引用来源，输出要做校验器检查，比如抽取答案中的关键实体并判断是否出现在召回文档中；不确定时就拒绝回答或转人工。对应到 Agent 系统里，这就是自主容错控制的一部分：工具调用失败要有重试，数值异常要有校验，超时要有降级方案。
7.3 自一致性与约束解码
方法论上我会提自一致性采样：同一问题采样多次，对多个答案做一致性投票。如果答案之间差异大，说明模型不确定，宁可拒答。约束解码更激进一点，用正则或语法约束强制输出符合预期结构，比如 JSON 里只允许枚举值。
7.4 指标口径很重要
聊到后面一定要落到指标：幻觉率怎么统计？拒答率怎么统计？这两个指标通常是矛盾的，你要讲清楚自己的阈值设计。我常用的口径是：在 500 条测试样本上，答非所问算幻觉，无依据回答算幻觉，答案没落在召回文档范围但语义正确也算“可疑”。先用自动规则粗筛，再人工抽检 100 条算精确率。没有这个口径，你说“幻觉降低了”就是空话。
7.5 低分答案的典型特征
低分答案通常只有一招：“我在 prompt 里强调不要编造。”这不是完全没用，但它只能挡住模型“主动发挥”，挡不住因为知识缺失导致的自信输出。面试官只要追问“你怎么量化 prompt 的作用”，就露馅了。
8. 第七道必问题：上下文长度与 KV Cache——性能体感才是照妖镜
8.1 问题形态与计算
“为什么长上下文这么贵？什么是 KV Cache？”这道题纯粹是工程体验题，没部署过模型的人很难答到点子上。
Transformer 解码是自回归的，每生成一个 token 都需要用之前所有 token 的 K 和 V 去算注意力。如果不缓存，每个 token 都要重新算一遍前面的 K、V，复杂度会从 O(n) 变成 O(n²)。KV Cache 就是在显存里缓存历史时刻的 K 和 V 矩阵，换时间。
但缓存也有代价：显存线性增长。以 7B 模型为例，假设 hidden_size 是 4096，层数 32，序列长度 2048，用 FP16（每元素 2 字节），单层 K 和 V 各是 [2048, 4096] 的矩阵，两层算下来单层 33 MB，乘 32 层就是 1 GB 左右。序列翻到 4096，光 KV Cache 就接近 2~4 GB。这就是为什么越长的对话，越容易 OOM 或被迫降低 batch size。
8.2 常见优化手段：GQA、滑动窗口、稀疏注意力
面试里能答到这里，接下来就可以讲优化：
GQA（分组查询注意力）是当前主流落地选择。把 KV head 数量减少到几组，多个 query head 共享一组 K、V，KV Cache 显著缩小。典型做法是每 4 个 query head 配 1 个 KV head，缓存直接减到四分之一。
滑动窗口注意力让每个 token 只看到附近窗口的 token，复杂度从平方降为线性。稀疏注意力进一步结构化：某些全局 token（比如 [CLS] 或指令 token）看全场，其余 token 只看局部。
8.3 长上下文与位置编码
追问还会到“超过训练长度怎么办”。这里要讲 RoPE 外推的问题：直接用超长序列，模型对没见过的大旋转角度不免疫，困惑度会崩。解法有位置插值、NTK-Aware 缩放，以及用更长序列做少量继续训练。没有做过长上下文调优的人通常说不出 NTK 和插值之间的区别，这里也是分水岭。
8.4 服务端怎么处理对话变长
工程上还有个常被忽视的点：用户来回对话，上下文越积越长，如果无脑全量输入，KV Cache 越来越大，时延越来越高。做服务端时要主动做截断、压缩或摘要。我的做法是：设定水位线，超过阈值后把旧对话用一个小模型压缩成摘要，保留最近几轮完整原文。这个细节会让面试官觉得你真的在运营线上服务。
9. 第八道必问题：模型评测——你说效果好，拿什么证明？
9.1 问题形态
“你上个项目效果怎么衡量？用了哪些指标？和什么基线比？”这题直接决定面试官相不相信你说的“效果好”。
9.2 公开基准与领域评测
公开基准要说得出名字和适用场景：MMLU 测知识广度，GSM8K 测数学推理，HumanEval 测代码生成，HELM/OpenCompass 是多任务综合套件。但更关键是领域评测，公开基准做得好看不等于业务场景好用。你要有自己的领域测试集，比如客服场景下用 1000 条历史工单，标注好“正确回答”“需要转人工”“拒答”三类标签。
9.3 线上指标与 bad case 闭环
线上评估我会用两层：第一层是离线自动指标，计算准确率、幻觉率、拒答率、上下文引用覆盖率；第二层是线上 A/B，取真实流量按用户维度的满意度、重试率、转人工率来比较。如果看到某个类目一直出问题，就把它拉回评测集里做回归，形成闭环。
9.4 实操：构建评测集和 eval harness
关于评测的执行，我特别推荐把自己模型接入现成的评估 harness 跑批量测试，而不是人工逐条看。开源生态里现在有非常成熟的 eval 工具链，你把模型以标准接口接进去，配置好任务列表，就能自动跑出多个基准的分数。我入职新团队时第一件事就是把基线模型的分数跑一遍，后面所有微调实验都拿同一套 harness 做回归对比，避免凭感觉说“这个版本效果好”。
构建评测集有一个很容易踩的坑：标注一致性问题。两个人对同一条回答的评分可能完全不同，所以要有明确的打分规则。我给每个维度写清“什么情况算 1 分，什么情况算 2 分”，然后抽 50 条算标注员间一致性，太低就重新对齐口径。没有这套流程，你的评测结果根本不可信。
9.5 低分回答长什么样
低分回答是：“效果挺好的，用户反馈不错。”没有基线，没有数据集，没有指标，没有 bad case 分析。这种回答一出来，面试官会怀疑整段项目经历的真实参与度，因为一个大模型项目不可能不涉及评测环节。
10. 加分技巧：把工程经验融进答案的三条思路
10.1 每个答案都顺手带一个复杂度或显存数量级
不管面试官问微调还是推理，你都可以把话题引到代价意识上。比如聊采样时补一句“这个参数组合在一次 7B 服务的 batch 推理下，时延大概增加 15%”；聊长上下文时，直接算一下 KV Cache 的显存。面试官听到数量级，心里就知道你是亲自跑过服务的。
10.2 每个方案都要带“这个方案的代价是什么”
只讲优点不讲代价，是新手最明显的标志。说完 LoRA 要补一句“它表达空间有限，复杂任务可能不如全参”；说完 RAG 要补“检索链路有召回率瓶颈，切块策略要调优”。这种“代价意识”在系统设计题里比任何标准答案都加分。
10.3 用真实项目里的动手细节收尾
面试最后可以主动补一个能体现动手能力的细节。我团队里最认可的经历之一，是候选人讲他把一个开源 7B 模型量化成 GGUF 格式，在安卓手机上跑通了一个本地问答 demo，还在端侧做了一套评测脚本。这种事难度不高，但它证明了一件很重要的事：这个人愿意为验证一个想法动手把整条链路跑通。反而是简历上写满了“大规模训练”但说不出任何部署细节的人，更容易让我警觉。
另外，如果你正好做过“LLM 智能体容错控制”相关的功能，比如给 Agent 加工具调用重试、加校验器、加降级策略，千万要放在项目亮点里。现在做 Agent 的人很多，但能把可靠性工程讲清楚的人很少，这几乎是面试官最愿意深挖的加分领域。
10.4 我作为面试官的最后建议
我面过的候选人里，最后能拿到 offer 的，大部分不是背题最熟练的人，而是能在某个问题上主动承认“这里我踩过坑，当时没考虑到，后来这样解决”的人。大模型行业变化太快，没人能保证自己掌握每个细节。但如果你能证明自己碰到问题时会追根因、会量化、会复盘，你就是面试官愿意招的人。反过来，一道题答不上来就硬编，比直接说“我没仔细研究过”要减分得多。
