LLM岗位面试8个生死题：从Transformer原理到Agent容错全解析

面试现场：LLM岗位的8个“生死题”，你踩了几个坑？

每年的招聘季我都会面一批 LLM 方向的候选人，简历都写得漂漂亮亮——熟悉Transformer、做过SFT、用过主流开源模型。可一旦进入技术面，我只需要抛出8个基础问题，筛掉率就能轻松超过一半。不是候选人不够聪明，而是太多人把精力花在“刷论文标题”和“跑别人的代码”上，对底层的原理、训练的关键细节、工程落地的坑完全没有概念。

这8个问题算不上刁钻，恰恰是日常开发中最常遇到的场景：模型为什么这样设计、训练时哪些参数要盯、推理为什么这么慢、数据集怎么处理、评估到底看什么指标、Agent为什么总给你瞎答。任何一个问题答不透，都说明你只用了 LLM，没有真正理解 LLM。这篇文章把这8个问题连同我的真实面试追问、候选人的典型死法、以及我自己踩坑后的纠正方式全部写出来，希望能帮准备面试的朋友把“用过”变成“懂”。

注意：这不是一份背诵版题库。面试官和你之间不是“背书比赛”，而是看你在面对未知问题时怎么拆解、怎么推理。所以下面每一问里，我重点写“回答的思路”而不是“标准答案”。

1. 面试官视角：8个问题的筛选逻辑

很多候选人有个误区，觉得面试就是“我会的多就赢”。真实情况恰恰相反，LLM方向的面试更看重“你能不能把一件事讲清楚”。这8个问题是我结合日常研发工作里最常卡壳的环节设计的，覆盖面既有模型原理，也有工程落地。

1.1 问的不是答案，是思维链路

我在面试中观察到的典型现象是：候选人知道“Transformer 用了自注意力”，但当我追问“为什么非要用自注意力，RNN 不是也能处理序列吗”时，对方就哑了。这说明他对这个知识点的理解是“背下来的”，不是“推出来的”。

好的回答应该是一条链路：从问题出发 -> 分析现有方法的缺陷 -> 提出新方案 -> 权衡代价 -> 得出结论。面试官真正想看的就是这个链路，而不是最终那句话。所以下面是8个问题，每个我都会拆出“考察点”、“面试官心里的期望链路”、“答不上的典型表现”三块，方便你自测。

1.2 为什么“答不上来”会直接淘汰

这8个问题覆盖了一个 LLM 工程师日常工作的全部核心节点。如果你连“为什么用 AdamW 而不是 SGD”这种问题都要想半天，我只能合理怀疑：第一，你的模型训练经验停留在跑通 demo 级别；第二，出了问题你根本没有定位能力；第三，后续团队的模型效果出现异常，你可能连从哪个方向排查都不知道。

淘汰并不是因为你“知识量不够”，而是因为你表现出“没有构建系统性认知”的能力。这恰恰是LLM工程岗区别于算法研究岗的地方——工程岗要求你既懂论文，也能写代码，还能在算力不可控、数据不干净的现实环境里把事情做成。任何一个环节出现明显认知缺口，都是风险信号。

2. 架构原理：必知的Transformer底层逻辑

2.1 第一问：Transformer为什么用自注意力，结构上有哪些关键设计

这一问几乎是LLM面试的“开胃菜”，但大多数人只答了半句“自注意力能捕捉长距离依赖”。我当然知道它能捕捉长距离依赖，RNN 也可以啊。我要你说清楚的是“同为序列建模，自注意力凭什么胜出”。

期望的回答链路是：RNN 是顺序计算的，t 时刻的隐状态依赖 t-1 时刻的输出，这导致两个致命问题——无法并行、长距离信息会经过多步衰减。LSTM 的引入只能缓解梯度问题，不能真正解决信息衰减。自注意力把所有位置的 token 两两做相关性计算，任何一个位置都能直接看到全局，路径长度是 O(1) 级别，于是“长距离依赖”这个物理瓶颈消失了。

更关键的是并行性：Transformer 的注意力计算可以改写成矩阵乘法，整个序列一次算完，这才让大模型在 GPU 集群上训练成为可能。如果你还能说出“Attention is All You Need”里多头注意力的设计逻辑——每个头关注不同的子空间，有的头捕获语法关系，有的头捕获语义指代，模型的表达能力就变成了“多视角并行”，那面试官基本就会点头了。

实操心得：不要死记“QKV”，要能从代码实现的角度推导维度变化。比如 batch size 为 B、序列长度为 L、隐藏维度为 D，Q、K、V 的维度都是 B x L x D，注意力权重的形状是 B x num_heads x L x L。能写出这套形状变化的候选人，说明他至少自己实现过，而不是只会调接口。

2.2 第二问：训练LLM时，哪些超参数最关键？你怎么定初始值

这个问题看着简单，但坑特别多。候选人最常见的回答是“学习率设1e-4，用AdamW”完事。如果真这么简单，训练大模型就不会是门“玄学”了。

面试官想听到的，是你对每个超参数背后“资源约束”的理解。LLM 训练最大的敌人是显存和算力，所以 batch size 不是拍脑袋定的，它取决于你用的并行策略。数据并行下，global batch size = per_gpu_batch_size × gradient_accumulation_steps × num_gpus。当你显存不够时，你的第一反应应该是调小 per_gpu_batch_size，然后用梯度累积把 global batch size 拉回去，而不是直接改小 batch size 导致收敛不稳定。

学习率的初始值则要关注两个特殊现象。第一，过大的学习率会让 loss 在训练早期直接发散，表现为前几百步 loss 不降反升。第二，LLM 常用 warmup 策略——前几千步把学习率从接近0线性升到目标值，目的是让模型先找到一个相对平滑的损失曲面区域，再大步前进。还有一个容易忽略的点：权重衰减（weight decay）默认只作用在非 bias 和非 LayerNorm 参数上，因为对这两类参数做 L2 惩罚会破坏归一化的稳定性。能说出这个细节的候选人，说明他是真的调过参的。

面试官的追问点通常是“你训练的 loss 到 3.0 后怎么继续往下降”。这考的是你对数据配比、学习率衰减策略（cosine annealing）、梯度裁剪（grad clip）的综合运用。答得好的候选人会说“我会先看是否过拟合，再考虑降低峰值学习率、增加有效数据、裁掉极端梯度”，而不是张口就说“换更大的模型”。

2.3 第三问：推理速度上不去，瓶颈在哪儿？KV Cache和量化怎么选

推理性能优化是 LLM 工程落地的一个大头，没有之一。你问任何做过部署的工程师，他都能跟你聊一晚上显存和时延。这道题我主要用来考察候选人是否真正“部署”过模型，而不是只看过文档。

核心知识点是 KV Cache。自回归解码时，每生成一个 token，都需要用前面所有 token 的 K、V 向量和当前 token 的 Q 做注意力计算。如果不缓存，每一步都重新计算前面所有 token 的 K、V，复杂度是 O(n²)，实际推理慢得没法用。KV Cache 就是拿显存换速度：把已经算好的历史 K、V 存下来，每步只算当前 token 的新 K、V。于是问题演化成“显存怎么分配”。缓存大小约等于 2 × num_layers × num_heads × head_dim × seq_len × batch_size × dtype_size，一个 7B 模型在长上下文的场景下，KV Cache 轻松吃掉十几个 GB 显存。

所以面试的时候你要主动说出三个优化方向：第一是 KV Cache 量化（比如从 FP16 压到 INT8，显存减半但几乎没有精度损失）；第二是 GQA（分组查询注意力），让多个查询头共享一组 K、V，显著减少缓存量；第三是投机采样（speculative decoding），用小模型草拟多个token，大模型一次性验证，把单步延迟吃满。

经验补充：热词榜里的“安卓本地运行GGUF格式LLM”，走的其实也是量化路线。GGUF 本质就是把模型权重量化到 4bit、8bit 再打包，让消费级设备和手机也能跑起来。面试提到这个例子会很加分，说明你关注了生态工具链，而不只是论文。

3. 训练与数据：真实研发中的硬骨头

3.1 第四问：做数据标注时，质量和数量哪个更重要？怎么搭流程

“LLM怎么数据标注”这个热搜词，恰恰也是面试高频题。很多候选人大谈特谈“我清理了100万条数据”，但问他是怎么清理的，回答是“写正则去重”。预算和规则清洗只是数据工程最表层的动作，真正的价值在于搭建“数据飞轮”。

数据标注的第一步永远是搞清楚“你要让模型学会什么行为”。同样是给一个问答对打标签，用于 SFT 和用于 RLHF 的标准完全不一样。SFT 阶段，要求标签是“唯一正确答案”；RLHF 阶段，标签要变成“偏好排序”，你需要让标注员在多个回答中选更好的，而不是选唯一的。如果这一步搞混了，后面的训练效果一定乱七八糟。

第二是质量控制。我踩过的坑是：不给出标注规范就让外包团队开工，结果返回来的数据里出现大量“虽然...但是...”的万能句式，模型学完之后所有回答都变得又臭又长。正确流程是：写标注规范 -> 先让标注员标200条 -> 我亲自验收并写反馈 -> 修正规范 -> 再批量铺开。标注不是一次性的，规范和真实数据永远会打架，你得跑几个来回才能收敛。

第三是沿用“众包投票”的思路做质量过滤。同一条数据让3个人标，投票一致性低于60%的直接丢弃，这种“难例”往往是标注规范最模糊的地方，也是模型最容易学坏的地方。此外还要做“难例挖掘”：把模型在验证集上预测概率最低的那批样本挑出来，让标注员重新标或者剔除，这比随机清洗数据的效率高得多。

3.2 第五问：预训练、SFT、RLHF三者到底什么关系？能跳过中间步骤吗

这道题几乎每场必问，因为很多候选人只跑过 SFT，却对 “为什么要分阶段” 缺乏理解。预训练教模型“说话”——通过下一词预测任务，让模型掌握语言规律和世界知识。但预训练出来的模型只会续写，不会“回答你指定的问题”。于是 SFT 登场，用一批（指令，期望回答）的监督数据，把模型的行为从“续写”掰到“问答”上。

SFT 之后的模型能回答问题了，但还是存在两个毛病：第一，它不知道“什么时候应该承认自己不知道”，倾向于瞎编；第二，它回答的风格不是人类偏好风格，可能过于冗长或者缺乏礼貌。RLHF 解决的就是这两个问题。你训练一个奖励模型来模仿人类的偏好排序，再用 PPO 或 DPO 来微调策略模型。这一步的本质是把“满足人类偏好”从损失函数层面注入模型行为。

至于能不能跳过 SFT 直接 RLHF？答案是“不行，但很多人不知道为什么”。RLHF 阶段策略模型的初始策略如果是纯预训练模型，它生成的内容五花八门，奖励模型根本没法有效打分——奖励模型只会对那些“位于分布中”的样本给出有意义的分值。SFT 相当于把一个“野马”先驯成“可用但不够优雅”的状态，RLHF 再把它训练成“懂规矩的助手”。没有 SFT 的 RLHF，奖励信号噪声太大，训练极不稳定。

3.3 第六问：模型效果怎么评估？不能只看 Benchmark 分数

评估问题可能是 8 问里最容易被轻视的。候选人通常回答“跑一下 MMLU、BBH、HumanEval 排行榜”就完事，但这并不是一个工程师的完整答案——Benchmark 只能作为门槛，真实场景的评估远没有这么简单。

我这些年实践下来的评估维度至少有三个：离线指标、生成质量采样、线上A/B。离线指标里除了 MMLU 这类知识问答，更要关注模型在你自己业务数据上的效果。比如你做客服场景，就应该标注500条真实用户问题并建立“业务评估集”，模型在每个版本迭代后都跑一遍这个集合，而不是幻想 MMLU 涨分等于客服效果好。

生成质量采样则是从测试集里随机抽100条，一条条看模型的输出，记录“有没有瞎编”、“逻辑是否连贯”、“语气是否得体”。这一环节碎片时间就能做，但对感知模型质量必不可少。我经常在离线指标提升的情况下，靠人工抽样发现模型“变油了”——开始大量使用套话和空话。这是自动指标永远发现不了的问题。

工程提示：评估框架可以直接用热词里的 harness 系工具，比如 lm-evaluation-harness，它能帮你标准化跑几十个公开 benchmark，跑完导出 JSON。但一定记住，harness 只是基准线，你的私有评估集才是最终裁判。如果面试官追问“评估集怎么建”，你要说出“按业务场景分类、保证覆盖低频难例、定期更新防泄露”这套方法论。

4. 系统与工程：从单模型到可靠Agent

4.1 第七问：长文本场景下，模型为什么“记不住”前面内容？怎么解决

LLM 处理长文本的局限性，是面试中的高频场景。候选人最常见的回答是“位置编码不够强，换成更好的位置编码就行”——这句话只对了一半。长文本失效的本质原因是多重的，至少要能从三个角度分析。

第一是位置编码外推。模型训练时见过的序列长度上限比如4K，你推到16K输入时，RoPE 这种编码虽然可以外推，但注意力分布会发生偏移，模型会“懵”。解决方法包括：用 ALiBi 位置编码、做插值（position interpolation）、或者用 YaRN 这类改进插值方法。这些都是成熟手段，但你要能说清“为什么简单地拉长训练序列会昂贵”。

第二是注意力分散。序列拉到 32K 时，注意力矩阵是 32K × 32K，模型很容易把注意力分数摊得太薄，导致“信息稀释”。解决思路是滑窗注意力 + 全局锚点 token 的混合架构，只让部分关键位置拥有全局视野，其余位置只看局部窗口。这几乎成了长文本模型的标配设计。

第三是评测陷阱。有些模型号称“支持128K上下文”，但你在第64K的位置问它第2K出现过的内容，它可能完全没记住。面试官问的其实是“你有没有验证过真实上下文利用率”。实操建议是：分段填空测试，每间隔一段就插入一个依赖前文的事实问题，看模型在远距离上的准确率曲线。这个曲线才是工程可用的上下文长度。

4.2 第八问：Agent 经常出现幻觉和失控，你怎么做容错

热词里有几个挺有代表性的词条：“LLM智能体自主容错控制”和“LLM元评论残留”。这些正是 Agent 工程化的痛点。今年几乎每个团队都在做 Agent，但真正能稳定上生产的没几个。面试这个问题，我要的是你“对不可控系统的敬畏心”。

Agent 的失控场景很典型：它会捏造工具调用的返回结果，会连续犯错后仍然自信满满，会陷入一个死循环反复调用同一个失败接口，甚至会因为上下文太长把早期的重要指令“遗忘”掉。对此你的回答必须体现三个层次的容错设计。

第一是输出验证。所有 Agent 调用外部工具的结果，都要做格式校验和逻辑校验。你写一个数学计算 Agent，模型返回 JSON 里有计算结果，你就不能直接信，要自己再算一遍交叉验证。第二是状态机上限控制。给 Agent 的“思考-行动-观察”循环设置最大轮数，达到上限就强制进入兜底策略，比如“向用户坦白当前无法完成该任务”，而不是让它继续无意义地循环。第三是元监控。对模型输出加一层评判模型（LLM-as-a-judge），专门检测“回答是否存在信息冲突”、“是否偏离原始用户指令”。我在实盘里发现，“元评论残留”问题特别容易出现在长对话 Agent 中——模型在生成最终回答时，会无意中把自己内部推理过程混进去。这种问题靠规则过滤很难捕获，只能加监控层去拦截。

面试加分项：主动聊你自己的失败案例。你说“我做 Agent 时最强的体会是：工具返回的结果必须校验，不然模型会一本正经地告诉你一个从未发生过的结果”比你说“我精通 Agent 架构”有说服力一百倍。面试官也是常年踩坑的人，听到真实案例立刻就会产生共鸣。

5. 自查清单：8个问题速答框架

这里给你一份我自己用的速答框架，每个问题不用背，理解之后再根据自己的项目经历包装成自己的话，比什么都有用。

6. 最后一点个人体会

面了这么多人，我最大的感受是：LLM 面试的问答题，本质上是在测试一个人“有没有亲自解决过问题”。模型会不会、数据怎么标、推理怎么部署、Agent 怎么让它靠谱，这些东西你只要在项目里真实地摸过一遍，就一定说得出来。你要做的不是把这些答案背下来，而是去真实地训练一个小模型、用 GGUF 在本地跑一次推理、搭一个最小 Agent 让它出错再修复它。整个过程走完，面试时你不需要背任何东西，你只需要回忆。

所以我的建议是：与其花两周时间刷面试题，不如花两周时间自己从零训练一个 1B 级别的对话模型。把数据清洗、SFT、评估、量化、部署全流程跑通，这个项目能覆盖的面试问题范围远超这 8 问。等你自己亲手调完那一堆令人头大的超参数之后，你会发现自己面对面试官时，连说话底气都不一样了。