前几天我在一轮 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 的本质区别BPEByte 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_itemperature 为 T那么 softmax 变成[ p_i\frac{\exp(l_i/T)}{\sum_j \exp(l_j/T)} ]当 T 趋近 0最大 logit 对应的概率趋近 1生成变成贪心当 T 变大所有 logit 被抹平分布趋于均匀生成更多样。T1 就是不做缩放。注意“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 实战参数与一次事故我在代码生成任务里的经验配置是 T0.2、top-p0.9偶尔加 temperature 0.1 的重复惩罚。开放域写作会调到 T0.8、top-p0.95。有一次我做客服助手为了让它更“活泼”把 T 拉到 0.9结果模型开始一本正经编造不存在的退款规则。事后排查发现 T 过高让低概率的幻觉 token 更容易冒头。生产环境里我后来统一改成 T0.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 模型用 r16 时trainable 参数可能只有 0.1%~1%显存大幅下降。代价是表达空间受限理论上不如全参灵活。前缀微调P-tuning v2则是在输入序列前加一组可学习的连续向量只训练这些前缀参数。它不改变权重靠提示向量引导模型行为。优点是参数更少、切换任务很快缺点是可解释性差效果对初始化敏感。5.3 训练成本怎么算面试里你可以直接给一个数量级感全参微调 7B 通常要 4~8 张 80G 显卡LoRA 微调单张 24G 勉强能跑prefix-tuning 甚至可以更低。这些数字不需要很精确但能说出来说明你至少规划过预算。5.4 LoRA 的秩怎么选实操心得关于秩我翻了两次车之后总结的经验是数据量小几百条用 r8防止过拟合任务复杂但数据中等几千条用 r16~32数据量很大且领域专精可以试 r64配合早停观察验证集 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、VKV 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 的大部分不是背题最熟练的人而是能在某个问题上主动承认“这里我踩过坑当时没考虑到后来这样解决”的人。大模型行业变化太快没人能保证自己掌握每个细节。但如果你能证明自己碰到问题时会追根因、会量化、会复盘你就是面试官愿意招的人。反过来一道题答不上来就硬编比直接说“我没仔细研究过”要减分得多。