做 LLM 方向这几年我面过不少人也常帮团队把候选人从简历里捞出来做技术面。见得多了以后有个感受特别强烈网上流传的“LLM 面试必问的 8 个问题”大家其实都能搜到题目但真正答好的人很少。问题不出在记忆力出在大多数人都没有从原理、数据、训练、部署这条链路里亲手把一个模型跑通过。这篇内容就围绕这 8 道高频淘汰题展开我会把每道题的考察点、答题思路、常见错法、以及我实际带人和面试时积累的实操经验都拆开讲适合正在准备 LLM 岗位面试的同学也适合那些想从“调 API”进阶到“能独立负责模型训练与落地”的工程师。你不一定要用这篇东西去押题但你可以把它当成一份体检清单看看自己在哪一环节还是空的。1. 别背题先搞懂 LLM 面试到底在考什么1.1 面试官真正想判断的三件事我一般面候选人的时候心里其实只装了三件事。第一这个人是不是真的训练过或调优过模型还是只调过 API。调 API 没有错但它和训练模型是两种完全不同的能力。训练过的人对显存、数据格式、收敛状态、bad case 有一套切身体会遇到问题知道去哪个环节找原因。第二这个人能不能在资源有限的环境下给出可落地的方案。比如一张 4090 只有 24GB 显存你要微调 7B 模型是全参还是 LoRAbatch size 怎么配梯度累积怎么设这都需要自己算过而不是嘴里念几个名词。第三这个人遇到问题时有没有成体系的排查思路。大模型项目 80% 的时间都在处理坏样本召回不行、指令不听话、格式输出乱、显存爆炸。面试官问一句“你的模型效果不好怎么办”就是看你会不会直接说“加数据、调参”还是会先定位问题再动手。这几年我还特别看一个标准能不能讲清楚自己踩过的坑。模型 loss 为什么降不下去、加了数据为什么反而变差、RAG 检索出来一堆乱七八糟的内容怎么办这些东西只有实际跑过才讲得出细节。很多候选人简历写得漂亮一到追问就露出底色就是因为他只记住了流程没有记住流程里的意外。所以与其说面试在考这 8 个问题不如说它是在用这 8 个问题去验证你有没有真的跟 LLM 较过劲。下面这张清单就是我整理出来的高频题也是后面每一章要拆解的对象。1.2 高频淘汰问题全景清单先把 8 道高频题放在这里我特意在表格里写了“主要淘汰原因”因为这就是面试官问这些题的真实目的。编号高频问题典型问法主要淘汰原因1Transformer 为什么用自注意力位置编码怎么设计“为什么不用 RNNRoPE 怎么理解”只背公式说不出设计动机2预训练、SFT、RLHF 到底各解决什么问题“SFT 之后模型为什么变‘听话’”把几个阶段混为一谈3PPO 在 RLHF 里优化的目标是什么“RLHF 三阶段的损失函数怎么理解”说不清 reward 和 KL 惩罚的关系4如何给 LLM 外挂知识库“RAG 效果不好怎么排查”没有完整链路经验5LoRA 和全量微调怎么选显存怎么算“为什么 LoRA 省显存rank 怎么取”只调过 API没算过内存6推理显存怎么估算KV Cache 为什么消不掉“7B 模型部署要多少显存”对部署没有概念7Agent 是什么工具调用怎么保证可靠“工具一多 Agent 就乱怎么办”只会概念没做过工程8数据标注和对话数据怎么构造“给你一批聊天记录怎么精调模型”对数据质量没有判断力这张表其实就是一张体检单。前 3 题是原理体检中间 3 题是工程体检后面 2 题是数据与前沿体检。大多数候选人不是挂在不会而是挂在“知道一个词但没做过一件事”。下面我按这个顺序把每道题的答题逻辑、现场常见失误以及可以直接用的经验都展开讲。2. 理论与原理题用“为什么”来回答2.1 自注意力、位置编码与长度外推第一题一般从 Transformer 切入。面试官通常会问为什么是自注意力它比 RNN 和 CNN 好在哪里。有经验的回答一定不是上来就扔 QKV 公式而是先讲动机。序列建模最核心的矛盾是长距离依赖。RNN 是逐步传递信息每一步都有信息损耗而且没法并行CNN 靠局部窗口扩大感受野但对全局关系建模绕了很多弯。自注意力的思路很直接让序列里任意两个 token 直接做交互一步看到全局同时矩阵运算天然适合并行。这是它在 Transformer 里地位这么稳的根本原因。但“任意两个 token 直接交互”也带来代价计算复杂度是序列长度的平方。序列 1000 的时候还能接受到几千几万显存和耗时都顶不住。所以面试官往往会接着问长文本怎么办这种题可以分两层答。第一层是算力层面的优化比如 FlashAttention它并没有把算法复杂度变成线性而是通过分块计算和重计算明显减少显存读写量让长序列在同样的显卡上从“跑不动”变成“能跑”。第二层是模型结构层面的长度外推常见的有位置编码插值、NTK 感知缩放等。能把这两层分开讲面试官基本就知道你部署过真实的长文本任务。位置编码也是必考。Transformer 本身没有顺序概念必须把位置信息塞进去。很多人只会说“加一个位置向量”但说不清 RoPE 为什么是现在的主流。RoPE 的直观理解是把每个 token 的 query 和 key 向量按照位置的不同旋转一个角度旋转后的向量做内积结果里天然包含两个 token 的相对位置关系。这也是它被叫“旋转位置编码”的原因。现场如果能画一个二维向量旋转的示意再解释“内积含相对位置旋转角度随位置递增”这题基本就稳了。反之如果只背“RoPE 是旋转位置编码”面试官一追问就露馅。补一句“我在做外推评测时短文本和长文本是分开测的很多模型短文本表现很好一长就崩问题往往出在位置编码上”这种细节比背十个公式都有说服力。2.2 预训练、SFT 与 RLHF 的三级火箭第二题和第三题通常会连在一起问预训练、指令微调、RLHF 分别是什么关系。很多人张口就是“预训练学知识SFT 学对话RLHF 学价值观”方向对但太粗。面试官想听的是每个阶段到底改变了模型的什么。预训练做的是下一个 token 预测。这个目标看起来简单但模型在大量 token 上做自监督学习本质上是在拟合语言世界的统计规律。它学到的是“知识密度”和“语言能力”包括语法、事实、推理的潜在表征但这些知识不是“服务态度”。所以一个纯预训练模型可能知识丰富但不会好好回答你的问题你问一句它续写一段完全不理会你的指令。SFT 要解决的就是把“续写模式”变成“问答模式”。SFT 的数据是人工写好的指令和回答模型通过交叉熵损失去模仿这些回答的格式和风格慢慢学会了“用户问什么我就针对性地答什么”。理解这个区别很重要很多候选人把预训练和 SFT 都叫“训练”但面试官想听的恰恰是它们目标的不同。RLHF 则是在 SFT 的基础上进一步做偏好对齐。它分三步用人类偏好排序训练一个奖励模型然后用强化学习让策略模型去最大化奖励同时加一个 KL 惩罚防止模型跑太远。如果面试官追问 PPO 到底在优化什么你可以这样回答PPO 在 RLHF 里优化的不是“生成正确下一个词”而是“生成让奖励模型打分更高的回复”。但奖励模型不是上帝它只是人类偏好的代理所以目标函数里一定有一个 KL 项约束策略模型不要离 SFT 模型太远。面试官爱问“RLHF 之后模型变笨怎么办”这就是典型的奖励过优化问题。策略模型为了拿高分可能生成讨好奖励模型的空话或者牺牲真实能力去迎合偏好结果客观评测下降。这时候重点不是去背 PPO 的 update 公式而是讲清楚“最大化代理目标本来就有可能偏离真实目标”再加一句“所以我们训练时会控制 KL 的权重也会用多组偏好数据交叉验证奖励模型”这两句话能把理论和实践串起来含金量比公式高得多。2.3 从损失函数到 SFT 数据配比很多面试官对理论题不会只停留在概念层他会突然扔一道计算题SFT 的 loss 怎么算。这个问题至少有三分之一候选人答不好。SFT 用的还是交叉熵损失但关键细节是计算 loss 时只计算回答部分的 token而不是把用户指令也一起算进去。原因是对话模板里指令部分不是模型要学习生成的它只是条件。如果指令部分也参与反向传播模型会把“看到指令本身”当成学习目标导致训练不稳定。实现上通常用 label mask 把输入部分的标签设成 -100loss 计算时自动忽略。这里如果能说出“我在写训练循环时就是把非回答位置的 labels 设成 -100”面试官基本就能确认你亲手写过训练代码而不是只会跑脚本。数据配比是 SFT 的另一个大坑。经常有同学问我攒了几十万条数据效果怎么还是不行问题通常不在数量在质量。SFT 阶段高质量的小数据往往比低质量的超大数据更有用。判断数据质量有几条实用标准指令覆盖是否多样、回答是否准确、是否过短、是否重复、有没有泄露和格式残留。尤其是最后一条很多从网上抓的聊天记录里带着“用户”“助手”这类模板残渣甚至有“以下是一段高质量回答”这种元评论模型学进去之后推理时会把这类废话也生成出来。这类数据必须做正则清洗和人工抽检不然后患无穷。如果面试官让你现场设计一套 SFT 数据集我建议按这个顺序答先确定任务范围把指令分成若干类比如问答、摘要、改写、抽取、代码等再控制每类的比例核心任务占比高一些接着清洗和去重用 embedding 相似度去重是很实用的方法最后抽检和试训用小模型跑 1 到 2 个 epoch人工看输出质量再决定要不要扩量。这套流程不需要高级架构但面试官一听就知道你是真的做过数据工程而不是只会套 Template。3. 工程实战题没跑过项目背书一定露馅3.1 RAG 外挂知识库完整链路与排查顺序第四题通常是这样的现在有一个客服场景要给 LLM 接入企业知识库你怎么做。千万别一上来就说“用向量数据库加 langchain”。面试官想听的是完整链路文档解析、切片、向量化、召回、重排、注入 Prompt、生成、评测。每一步都有坑。文档解析是最容易被忽略的PDF 表格、扫描件、多栏排版解析不对后面全是错的。切片要兼顾语义完整性和检索效率我常用的策略是固定窗口加重叠窗口 400 到 800 字重叠 50 到 100 字再根据文档标题做层级切分避免把一句话从中间切断。向量化模型要选和领域匹配的通用 embedding 在专业术语上经常翻车。召回之后别急着扔给模型先看召回结果够不够准。RAG 效果差第一步先定位是“没召回”还是“没生成好”。怎么定位“没召回”的表现是检索出来的片段跟问题根本不相关模型当然答不对。这时候去查切分方式、embedding 效果、query 改写以及是不是缺了关键词召回这种兜底。如果召回结果挺相关但模型没按片段答那问题在 Prompt 或生成参数。你可以把命中的 chunk 直接给模型加一句“只能依据给定资料回答”观察输出很快就能分清责任。这个“先定位责任再动手”的思路比盲目调参有用得多。问答效果变差还有一种很隐蔽的情况知识库里混入了被污染的条目检索到它们之后模型被误导。你可以把这个当加分项讲在工程上做来源过滤、置信度过滤和诱饵测试定期抽检知识库里有没有“看起来高质量但实际错误”的内容。“Agent 记忆中毒”这个现象本质上也是同一类问题外部信息被注入到记忆或知识库里Agent 再被这些信息牵着走。你能在 RAG 环节主动提到“知识库污染需要监控”说明你对可靠性有真实的理解这是很多只会调 API 的人讲不出来的。3.2 LoRA 与显存估算一张 4090 够不够第五题和第六题经常打包考你要微调一个 7B 模型手头只有一张 24GB 的 4090怎么办。标准答案有两个层次。第一层选 LoRA。LoRA 的原理是冻结原模型权重在旁边插入低秩矩阵 A 和 B用 A×B 去近似权重更新量 ΔW。因为 A 和 B 的秩很小需要训练和保存的参数远小于全量参数所以显存和存储都大幅下降。第二层你得把“为什么省显存”讲透。省的不只是参数存储还有优化器状态和梯度。全量微调时Adam 优化器要为每个参数保存一阶动量、二阶动量和梯度光是这几份状态就比模型本身还占显存。LoRA 只训练小矩阵这些额外开销全都被压到很小同时基座模型可以用 4-bit 量化加载一张 4090 确实能跑 7B 的 LoRA 微调。关于 rank 怎么选我给一个务实的区间最常用的是 8 到 64。任务越专一、数据量越少rank 可以越小任务复杂、多任务混合rank 需要大一点。dropout 一般设 0.05 到 0.1太大容易欠拟合。很多人会问“rank 越大越好吗”不是。rank 只决定更新空间的表达能力不是决定模型能力的唯一因素数据质量和训练策略影响更大。面试时如果能举一个自己的实验rank 16 和 rank 64 在某个评测集上结果差不多但训练速度差了不少这句话比背十篇论文都有用。显存估算问题也有一个很实用的公式思路。推理阶段模型显存主要看参数量和量化位宽比如 7B 模型用 FP16 加载模型权重约 7×214GB再加上激活、KV Cache 和少量开销单卡 24GB 可以推理但要留缓存余量。微调阶段全参微调一个 7B 模型光梯度加优化器状态可能就要权重的 12 倍左右所以实际显存需求非常夸张而 LoRA 微调因为只训练低秩矩阵常用模式是量化基座加少量 adapter整体通常在 10 到 20GB 级别正好落在 4090 这张卡的能力范围内。面试官要是进一步问 KV Cache你要能说出来它是为每个历史 token 缓存 key 和 value避免重复计算但显存也随序列长度线性增长所以长上下文场景下它常常比模型权重更吃显存这也是很多部署优化会做 PagedAttention、量化 KV Cache 的原因。能说到这个深度说明你不是只会调库。3.3 端侧部署与 GGUF 量化从服务器到安卓这一节单独拎出来是因为最近很多岗位的 JD 里都写了“有小模型端侧部署经验优先”。面试官会问LLM 能跑到安卓手机上吗。答案是能而且已经不是玩具级。这背后的关键格式就是 GGUF。你可以把它理解成一种专门为本地推理设计的模型封装格式它在存储层面对模型权重做了量化比如 Q4_K_M、Q5_K_M 这些不同档位质量损失和体积之间需要权衡。很多人说“本地跑模型”底层基本都是 GGUF 格式配合 llama.cpp 这类推理引擎。我在实际体验里3 到 4GB 的量化模型可以在中高端手机上流畅跑起来内存占用可控响应速度虽然比不上云端但离线场景完全够用。面试中如果聊到这里千万不要只停留在“能跑”上要主动讲清楚量化位选择Q4 通常能把 7B 模型压到 4GB 左右大部分场景下效果可接受但如果你的任务对数字推理或专业术语要求高Q5、Q6 会更稳。再讲一句“端侧还要做系统兼容测试不同品牌、不同处理器的调度策略差异很大”马上能让面试官觉得你是有真机测试经验的而不是看了论文之后强行装懂。端侧部署和云端的另一个关键差异是内存与散热模型一跑起来 CPU 降频、内存占用过高App 容易被系统杀掉。我踩过的坑是只考虑了模型体积没考虑峰值内存结果低端机上推理到一半直接被杀。后来的方案是降低上下文长度、使用流式输出和分块推理把峰值内存压下来。这类细节是八股题里查不到的经验现场说出来非常加分。4. 前沿热点与综合设计Agent、数据标注、安全与评测4.1 Agent 的可靠性工程工具调用和记忆污染第七题在最近的面试里出现频率明显变高了。面试官会问你了解 Agent 吗怎么让 Agent 稳定地使用工具。很多候选人的回答停留在“Agent 就是让 LLM 调用工具ReAct 框架”。这不算错但不够。你要答出工程问题工具数量一多模型就会开始乱选工具或者把参数格式写错。我实际解决这个问题的思路是第一把每个工具的 schema 写清楚参数名和类型必须严格定义尽量用必填参数减少歧义第二在系统提示词里给 1 到 2 个少样本示例让模型知道什么场景应该选什么工具第三要求模型先输出思考过程再以严格 JSON 格式输出工具调用后端做 schema 校验解析失败就自动重试一次第四给 Agent 设置最大调用轮数防止它在错误路径上无限循环。这四件事听起来不 fancy但能把工具调用的成功率从百分之六七十拉到百分之九十以上。关于安全面试官有时会把话题引到 Agent 记忆和知识库污染上。比如外部资料里被人塞进一段恶意指令Agent 检索到之后就会按恶意指令执行。工程上可以做输入过滤、输出过滤、来源标记和权限隔离。面试中如果能主动提到“通过污染记忆或知识库来对 Agent 进行红队攻击”这类方向并且说“我们会在数据入库前做清洗重要操作需要二次确认”就已经跑赢了大多数候选人。这里的加分重点不是你知道这个攻击名词而是你理解Agent 的能力越强越要敬畏它的输入来源。可靠性和安全不是上线后补的功能而是架构的一部分。这个认知在 LLM 应用落地时非常值钱。4.2 聊天记录怎么变成高质量训练数据第八题是数据题也是最容易暴露实战经验的一题。面试官会给一个具体场景我们有大量历史客服聊天记录想用它们精调 LLM你会怎么做。先别急着说“直接拿去训练”。聊天记录和指令数据之间隔着很远的路。第一步是清洗去掉隐私信息、URL、手机号、身份证和内部工号这一步既是合规要求也是基本的伦理底线。第二步是抽取从一段对话里抽出一个问题-回答对或者一个完整的多轮上下文。第三步是改写原始客服回答往往啰嗦、有错别字、语气不合适需要用规则或更强的模型做润色但润色之后必须人工抽检防止引入事实错误。第四步是构造负例比如让模型学会说“我不知道”而不是硬答。很多团队都尝试过“用聊天记录直接精调”但效果不好原因常常是数据质量不过关。比如对话里用户一直在追问模型学到的却是“答非所问”比如客服经常发送“亲亲”“您好”这些开场白模型把这种模板也学了比如不同客服的答案互相矛盾模型夹在中间输出就变得颠三倒四。我的建议是从记录里先人工整理前 500 条高质量样本跑一个小模型试训看模型有没有学会基本的格式和语气再决定要不要批量生产。批量生产也别忘了做去重和分布统计同一个问题被问了 3 万遍那就不是数据多样性是灾难。“元评论残留”这个坑也是数据题里的高频话题。所谓元评论就是数据里混入了“以上是回答”“这是一个很好的例子”“作为 AI 助手”这类描述性文本。模型学多了用户问问题时它也会产生类似的赘述。清洗时要重点匹配这类句式并检查有没有“system:”“assistant:”等模板标签残留在回答里。面试官问“你怎么判断一份数据能不能用”你可以给他一把尺子格式正确性、事实一致性、指令多样性、覆盖均匀性、污染率。这五个维度不需要复杂工具就能人工评分是数据质量最基本的度量方式。能把这一套讲清楚数据题基本就拿下了。4.3 端到端方案设计从数据到上线最后再补一类开放题假设你要给一个垂直行业做一个大模型助手存量数据就是过去的聊天记录和服务文档怎么设计整个项目。这种题没有标准答案但考察点很明确你能不能做技术选型。我通常会先反问一个问题知识需要实时更新吗预算多少如果知识以问答记录为主、更新不频繁可以考虑文档解析加 RAG再加少量 SFT 微调让它学会行业语气如果回复要求很高、格式要求稳定SFT 的比例要提高。完整链路至少包括数据收集与清洗、RAG 库建设、模型微调、评测回归、灰度上线、线上监控这几个环节。只盯着模型本身的人很难答出这种全链路问题。评测环节特别容易被忽视。很多人只会说“看 loss、看 BLEU、看 ROUGE”但在大模型场景这些指标只能做粗筛。实用的做法是建一套领域评测集里面包含真实用户问题、标准答案、困难样本和对抗样本每次模型更新后都跑一遍再人工对输出打分维度包括正确性、相关性和安全性。上线之后还要看线上日志里的拒绝率、超时率和用户反馈形成一个“数据-训练-评测-监控”的闭环。我见过太多项目埋头调模型最后发现失败的根因是评测集太简单模型在测试集上刷分一到真实场景就崩。面试时把“先建立评测闭环再迭代模型”这句话说出来会明显比只会堆技术名词的人高一个段位。5. 现场高频失误与最后的冲刺建议5.1 三个最容易当场被淘汰的表现根据我观察到的现场情况有三个表现最容易导致当场被淘汰。第一概念和实操脱节。比如被问到“你微调过模型吗”回答说“跑过开源框架里的示例”再追问“训练时显存占用到了多少、loss 多少、怎么调的”就答不上来。这会被直接判定为简历注水。解决办法很简单哪怕只是跑通一个小模型也要把训练参数、显存占用、bad case 记在笔记里能说出具体数字和踩坑过程。第二背数字不背逻辑。有人很顺溜地说“LoRA rank 一般设 8、16、64”但你要问他为什么就卡住了。数字只是起点背后的取舍逻辑才是面试官要的。第三不追问需求就开答。比如“怎么做一个客服助手”他直接开始背 RAG 流程完全不管用户场景、数据量、成本约束。正确的打开方式是先反问几个关键约束再给分层方案这体现的是工程判断力而不是记忆力。5.2 我自己的准备路线与避坑清单最后分享一套我在带新人时反复推荐的准备路线特别适合准备 LLM 面试的人。第一步把一款开源的 7B 模型在自己的机器上跑通用 GGUF 格式体验一下量化加载和推理第二步用几百条公开指令数据做一次 LoRA 微调记录训练前后的输出差异第三步选一个垂直领域比如产品说明书搭一个最小的 RAG 问答服务自己构造 20 个问题做评测第四步把 RLHF 三阶段和 PPO 的论文找出来不要求全懂但要把“奖励模型、策略模型、KL 惩罚”这三个词画成一张闭环图。这个路线不需要太多硬件但能覆盖掉这 8 道高频题里的大部分考点。我在实际带人的过程中还有几条避坑经验不要在简历里写“精通 LLM”除非你真能扛住半小时追问不要只盯着模型参数训练数据质量永远是第一位的不要拿到一堆工具就盲目上 Agent先在一个可控场景里验证工具调用的准确率不要忽视测试集泄露问题如果训练数据里已经包含了评测问题所有指标都是假的。这些话听起来很朴素但每一个背后都是真实项目踩出来的坑。准备面试不是背题库而是把做过的实验、踩过的坑、调过的参数变成自己的故事。这样即使遇到没准备过的题目你也知道该怎么思考因为面试官真正要看到的向来不是你的题库而是你的工程本能。 
长河君 · 2026/10/27 3:05:31 · 阅读 1.2k LLM面试8大高频淘汰题拆解：从原理到部署的实战指南
做 LLM 方向这几年我面过不少人也常帮团队把候选人从简历里捞出来做技术面。见得多了以后有个感受特别强烈网上流传的“LLM 面试必问的 8 个问题”大家其实都能搜到题目但真正答好的人很少。问题不出在记忆力出在大多数人都没有从原理、数据、训练、部署这条链路里亲手把一个模型跑通过。这篇内容就围绕这 8 道高频淘汰题展开我会把每道题的考察点、答题思路、常见错法、以及我实际带人和面试时积累的实操经验都拆开讲适合正在准备 LLM 岗位面试的同学也适合那些想从“调 API”进阶到“能独立负责模型训练与落地”的工程师。你不一定要用这篇东西去押题但你可以把它当成一份体检清单看看自己在哪一环节还是空的。1. 别背题先搞懂 LLM 面试到底在考什么1.1 面试官真正想判断的三件事我一般面候选人的时候心里其实只装了三件事。第一这个人是不是真的训练过或调优过模型还是只调过 API。调 API 没有错但它和训练模型是两种完全不同的能力。训练过的人对显存、数据格式、收敛状态、bad case 有一套切身体会遇到问题知道去哪个环节找原因。第二这个人能不能在资源有限的环境下给出可落地的方案。比如一张 4090 只有 24GB 显存你要微调 7B 模型是全参还是 LoRAbatch size 怎么配梯度累积怎么设这都需要自己算过而不是嘴里念几个名词。第三这个人遇到问题时有没有成体系的排查思路。大模型项目 80% 的时间都在处理坏样本召回不行、指令不听话、格式输出乱、显存爆炸。面试官问一句“你的模型效果不好怎么办”就是看你会不会直接说“加数据、调参”还是会先定位问题再动手。这几年我还特别看一个标准能不能讲清楚自己踩过的坑。模型 loss 为什么降不下去、加了数据为什么反而变差、RAG 检索出来一堆乱七八糟的内容怎么办这些东西只有实际跑过才讲得出细节。很多候选人简历写得漂亮一到追问就露出底色就是因为他只记住了流程没有记住流程里的意外。所以与其说面试在考这 8 个问题不如说它是在用这 8 个问题去验证你有没有真的跟 LLM 较过劲。下面这张清单就是我整理出来的高频题也是后面每一章要拆解的对象。1.2 高频淘汰问题全景清单先把 8 道高频题放在这里我特意在表格里写了“主要淘汰原因”因为这就是面试官问这些题的真实目的。编号高频问题典型问法主要淘汰原因1Transformer 为什么用自注意力位置编码怎么设计“为什么不用 RNNRoPE 怎么理解”只背公式说不出设计动机2预训练、SFT、RLHF 到底各解决什么问题“SFT 之后模型为什么变‘听话’”把几个阶段混为一谈3PPO 在 RLHF 里优化的目标是什么“RLHF 三阶段的损失函数怎么理解”说不清 reward 和 KL 惩罚的关系4如何给 LLM 外挂知识库“RAG 效果不好怎么排查”没有完整链路经验5LoRA 和全量微调怎么选显存怎么算“为什么 LoRA 省显存rank 怎么取”只调过 API没算过内存6推理显存怎么估算KV Cache 为什么消不掉“7B 模型部署要多少显存”对部署没有概念7Agent 是什么工具调用怎么保证可靠“工具一多 Agent 就乱怎么办”只会概念没做过工程8数据标注和对话数据怎么构造“给你一批聊天记录怎么精调模型”对数据质量没有判断力这张表其实就是一张体检单。前 3 题是原理体检中间 3 题是工程体检后面 2 题是数据与前沿体检。大多数候选人不是挂在不会而是挂在“知道一个词但没做过一件事”。下面我按这个顺序把每道题的答题逻辑、现场常见失误以及可以直接用的经验都展开讲。2. 理论与原理题用“为什么”来回答2.1 自注意力、位置编码与长度外推第一题一般从 Transformer 切入。面试官通常会问为什么是自注意力它比 RNN 和 CNN 好在哪里。有经验的回答一定不是上来就扔 QKV 公式而是先讲动机。序列建模最核心的矛盾是长距离依赖。RNN 是逐步传递信息每一步都有信息损耗而且没法并行CNN 靠局部窗口扩大感受野但对全局关系建模绕了很多弯。自注意力的思路很直接让序列里任意两个 token 直接做交互一步看到全局同时矩阵运算天然适合并行。这是它在 Transformer 里地位这么稳的根本原因。但“任意两个 token 直接交互”也带来代价计算复杂度是序列长度的平方。序列 1000 的时候还能接受到几千几万显存和耗时都顶不住。所以面试官往往会接着问长文本怎么办这种题可以分两层答。第一层是算力层面的优化比如 FlashAttention它并没有把算法复杂度变成线性而是通过分块计算和重计算明显减少显存读写量让长序列在同样的显卡上从“跑不动”变成“能跑”。第二层是模型结构层面的长度外推常见的有位置编码插值、NTK 感知缩放等。能把这两层分开讲面试官基本就知道你部署过真实的长文本任务。位置编码也是必考。Transformer 本身没有顺序概念必须把位置信息塞进去。很多人只会说“加一个位置向量”但说不清 RoPE 为什么是现在的主流。RoPE 的直观理解是把每个 token 的 query 和 key 向量按照位置的不同旋转一个角度旋转后的向量做内积结果里天然包含两个 token 的相对位置关系。这也是它被叫“旋转位置编码”的原因。现场如果能画一个二维向量旋转的示意再解释“内积含相对位置旋转角度随位置递增”这题基本就稳了。反之如果只背“RoPE 是旋转位置编码”面试官一追问就露馅。补一句“我在做外推评测时短文本和长文本是分开测的很多模型短文本表现很好一长就崩问题往往出在位置编码上”这种细节比背十个公式都有说服力。2.2 预训练、SFT 与 RLHF 的三级火箭第二题和第三题通常会连在一起问预训练、指令微调、RLHF 分别是什么关系。很多人张口就是“预训练学知识SFT 学对话RLHF 学价值观”方向对但太粗。面试官想听的是每个阶段到底改变了模型的什么。预训练做的是下一个 token 预测。这个目标看起来简单但模型在大量 token 上做自监督学习本质上是在拟合语言世界的统计规律。它学到的是“知识密度”和“语言能力”包括语法、事实、推理的潜在表征但这些知识不是“服务态度”。所以一个纯预训练模型可能知识丰富但不会好好回答你的问题你问一句它续写一段完全不理会你的指令。SFT 要解决的就是把“续写模式”变成“问答模式”。SFT 的数据是人工写好的指令和回答模型通过交叉熵损失去模仿这些回答的格式和风格慢慢学会了“用户问什么我就针对性地答什么”。理解这个区别很重要很多候选人把预训练和 SFT 都叫“训练”但面试官想听的恰恰是它们目标的不同。RLHF 则是在 SFT 的基础上进一步做偏好对齐。它分三步用人类偏好排序训练一个奖励模型然后用强化学习让策略模型去最大化奖励同时加一个 KL 惩罚防止模型跑太远。如果面试官追问 PPO 到底在优化什么你可以这样回答PPO 在 RLHF 里优化的不是“生成正确下一个词”而是“生成让奖励模型打分更高的回复”。但奖励模型不是上帝它只是人类偏好的代理所以目标函数里一定有一个 KL 项约束策略模型不要离 SFT 模型太远。面试官爱问“RLHF 之后模型变笨怎么办”这就是典型的奖励过优化问题。策略模型为了拿高分可能生成讨好奖励模型的空话或者牺牲真实能力去迎合偏好结果客观评测下降。这时候重点不是去背 PPO 的 update 公式而是讲清楚“最大化代理目标本来就有可能偏离真实目标”再加一句“所以我们训练时会控制 KL 的权重也会用多组偏好数据交叉验证奖励模型”这两句话能把理论和实践串起来含金量比公式高得多。2.3 从损失函数到 SFT 数据配比很多面试官对理论题不会只停留在概念层他会突然扔一道计算题SFT 的 loss 怎么算。这个问题至少有三分之一候选人答不好。SFT 用的还是交叉熵损失但关键细节是计算 loss 时只计算回答部分的 token而不是把用户指令也一起算进去。原因是对话模板里指令部分不是模型要学习生成的它只是条件。如果指令部分也参与反向传播模型会把“看到指令本身”当成学习目标导致训练不稳定。实现上通常用 label mask 把输入部分的标签设成 -100loss 计算时自动忽略。这里如果能说出“我在写训练循环时就是把非回答位置的 labels 设成 -100”面试官基本就能确认你亲手写过训练代码而不是只会跑脚本。数据配比是 SFT 的另一个大坑。经常有同学问我攒了几十万条数据效果怎么还是不行问题通常不在数量在质量。SFT 阶段高质量的小数据往往比低质量的超大数据更有用。判断数据质量有几条实用标准指令覆盖是否多样、回答是否准确、是否过短、是否重复、有没有泄露和格式残留。尤其是最后一条很多从网上抓的聊天记录里带着“用户”“助手”这类模板残渣甚至有“以下是一段高质量回答”这种元评论模型学进去之后推理时会把这类废话也生成出来。这类数据必须做正则清洗和人工抽检不然后患无穷。如果面试官让你现场设计一套 SFT 数据集我建议按这个顺序答先确定任务范围把指令分成若干类比如问答、摘要、改写、抽取、代码等再控制每类的比例核心任务占比高一些接着清洗和去重用 embedding 相似度去重是很实用的方法最后抽检和试训用小模型跑 1 到 2 个 epoch人工看输出质量再决定要不要扩量。这套流程不需要高级架构但面试官一听就知道你是真的做过数据工程而不是只会套 Template。3. 工程实战题没跑过项目背书一定露馅3.1 RAG 外挂知识库完整链路与排查顺序第四题通常是这样的现在有一个客服场景要给 LLM 接入企业知识库你怎么做。千万别一上来就说“用向量数据库加 langchain”。面试官想听的是完整链路文档解析、切片、向量化、召回、重排、注入 Prompt、生成、评测。每一步都有坑。文档解析是最容易被忽略的PDF 表格、扫描件、多栏排版解析不对后面全是错的。切片要兼顾语义完整性和检索效率我常用的策略是固定窗口加重叠窗口 400 到 800 字重叠 50 到 100 字再根据文档标题做层级切分避免把一句话从中间切断。向量化模型要选和领域匹配的通用 embedding 在专业术语上经常翻车。召回之后别急着扔给模型先看召回结果够不够准。RAG 效果差第一步先定位是“没召回”还是“没生成好”。怎么定位“没召回”的表现是检索出来的片段跟问题根本不相关模型当然答不对。这时候去查切分方式、embedding 效果、query 改写以及是不是缺了关键词召回这种兜底。如果召回结果挺相关但模型没按片段答那问题在 Prompt 或生成参数。你可以把命中的 chunk 直接给模型加一句“只能依据给定资料回答”观察输出很快就能分清责任。这个“先定位责任再动手”的思路比盲目调参有用得多。问答效果变差还有一种很隐蔽的情况知识库里混入了被污染的条目检索到它们之后模型被误导。你可以把这个当加分项讲在工程上做来源过滤、置信度过滤和诱饵测试定期抽检知识库里有没有“看起来高质量但实际错误”的内容。“Agent 记忆中毒”这个现象本质上也是同一类问题外部信息被注入到记忆或知识库里Agent 再被这些信息牵着走。你能在 RAG 环节主动提到“知识库污染需要监控”说明你对可靠性有真实的理解这是很多只会调 API 的人讲不出来的。3.2 LoRA 与显存估算一张 4090 够不够第五题和第六题经常打包考你要微调一个 7B 模型手头只有一张 24GB 的 4090怎么办。标准答案有两个层次。第一层选 LoRA。LoRA 的原理是冻结原模型权重在旁边插入低秩矩阵 A 和 B用 A×B 去近似权重更新量 ΔW。因为 A 和 B 的秩很小需要训练和保存的参数远小于全量参数所以显存和存储都大幅下降。第二层你得把“为什么省显存”讲透。省的不只是参数存储还有优化器状态和梯度。全量微调时Adam 优化器要为每个参数保存一阶动量、二阶动量和梯度光是这几份状态就比模型本身还占显存。LoRA 只训练小矩阵这些额外开销全都被压到很小同时基座模型可以用 4-bit 量化加载一张 4090 确实能跑 7B 的 LoRA 微调。关于 rank 怎么选我给一个务实的区间最常用的是 8 到 64。任务越专一、数据量越少rank 可以越小任务复杂、多任务混合rank 需要大一点。dropout 一般设 0.05 到 0.1太大容易欠拟合。很多人会问“rank 越大越好吗”不是。rank 只决定更新空间的表达能力不是决定模型能力的唯一因素数据质量和训练策略影响更大。面试时如果能举一个自己的实验rank 16 和 rank 64 在某个评测集上结果差不多但训练速度差了不少这句话比背十篇论文都有用。显存估算问题也有一个很实用的公式思路。推理阶段模型显存主要看参数量和量化位宽比如 7B 模型用 FP16 加载模型权重约 7×214GB再加上激活、KV Cache 和少量开销单卡 24GB 可以推理但要留缓存余量。微调阶段全参微调一个 7B 模型光梯度加优化器状态可能就要权重的 12 倍左右所以实际显存需求非常夸张而 LoRA 微调因为只训练低秩矩阵常用模式是量化基座加少量 adapter整体通常在 10 到 20GB 级别正好落在 4090 这张卡的能力范围内。面试官要是进一步问 KV Cache你要能说出来它是为每个历史 token 缓存 key 和 value避免重复计算但显存也随序列长度线性增长所以长上下文场景下它常常比模型权重更吃显存这也是很多部署优化会做 PagedAttention、量化 KV Cache 的原因。能说到这个深度说明你不是只会调库。3.3 端侧部署与 GGUF 量化从服务器到安卓这一节单独拎出来是因为最近很多岗位的 JD 里都写了“有小模型端侧部署经验优先”。面试官会问LLM 能跑到安卓手机上吗。答案是能而且已经不是玩具级。这背后的关键格式就是 GGUF。你可以把它理解成一种专门为本地推理设计的模型封装格式它在存储层面对模型权重做了量化比如 Q4_K_M、Q5_K_M 这些不同档位质量损失和体积之间需要权衡。很多人说“本地跑模型”底层基本都是 GGUF 格式配合 llama.cpp 这类推理引擎。我在实际体验里3 到 4GB 的量化模型可以在中高端手机上流畅跑起来内存占用可控响应速度虽然比不上云端但离线场景完全够用。面试中如果聊到这里千万不要只停留在“能跑”上要主动讲清楚量化位选择Q4 通常能把 7B 模型压到 4GB 左右大部分场景下效果可接受但如果你的任务对数字推理或专业术语要求高Q5、Q6 会更稳。再讲一句“端侧还要做系统兼容测试不同品牌、不同处理器的调度策略差异很大”马上能让面试官觉得你是有真机测试经验的而不是看了论文之后强行装懂。端侧部署和云端的另一个关键差异是内存与散热模型一跑起来 CPU 降频、内存占用过高App 容易被系统杀掉。我踩过的坑是只考虑了模型体积没考虑峰值内存结果低端机上推理到一半直接被杀。后来的方案是降低上下文长度、使用流式输出和分块推理把峰值内存压下来。这类细节是八股题里查不到的经验现场说出来非常加分。4. 前沿热点与综合设计Agent、数据标注、安全与评测4.1 Agent 的可靠性工程工具调用和记忆污染第七题在最近的面试里出现频率明显变高了。面试官会问你了解 Agent 吗怎么让 Agent 稳定地使用工具。很多候选人的回答停留在“Agent 就是让 LLM 调用工具ReAct 框架”。这不算错但不够。你要答出工程问题工具数量一多模型就会开始乱选工具或者把参数格式写错。我实际解决这个问题的思路是第一把每个工具的 schema 写清楚参数名和类型必须严格定义尽量用必填参数减少歧义第二在系统提示词里给 1 到 2 个少样本示例让模型知道什么场景应该选什么工具第三要求模型先输出思考过程再以严格 JSON 格式输出工具调用后端做 schema 校验解析失败就自动重试一次第四给 Agent 设置最大调用轮数防止它在错误路径上无限循环。这四件事听起来不 fancy但能把工具调用的成功率从百分之六七十拉到百分之九十以上。关于安全面试官有时会把话题引到 Agent 记忆和知识库污染上。比如外部资料里被人塞进一段恶意指令Agent 检索到之后就会按恶意指令执行。工程上可以做输入过滤、输出过滤、来源标记和权限隔离。面试中如果能主动提到“通过污染记忆或知识库来对 Agent 进行红队攻击”这类方向并且说“我们会在数据入库前做清洗重要操作需要二次确认”就已经跑赢了大多数候选人。这里的加分重点不是你知道这个攻击名词而是你理解Agent 的能力越强越要敬畏它的输入来源。可靠性和安全不是上线后补的功能而是架构的一部分。这个认知在 LLM 应用落地时非常值钱。4.2 聊天记录怎么变成高质量训练数据第八题是数据题也是最容易暴露实战经验的一题。面试官会给一个具体场景我们有大量历史客服聊天记录想用它们精调 LLM你会怎么做。先别急着说“直接拿去训练”。聊天记录和指令数据之间隔着很远的路。第一步是清洗去掉隐私信息、URL、手机号、身份证和内部工号这一步既是合规要求也是基本的伦理底线。第二步是抽取从一段对话里抽出一个问题-回答对或者一个完整的多轮上下文。第三步是改写原始客服回答往往啰嗦、有错别字、语气不合适需要用规则或更强的模型做润色但润色之后必须人工抽检防止引入事实错误。第四步是构造负例比如让模型学会说“我不知道”而不是硬答。很多团队都尝试过“用聊天记录直接精调”但效果不好原因常常是数据质量不过关。比如对话里用户一直在追问模型学到的却是“答非所问”比如客服经常发送“亲亲”“您好”这些开场白模型把这种模板也学了比如不同客服的答案互相矛盾模型夹在中间输出就变得颠三倒四。我的建议是从记录里先人工整理前 500 条高质量样本跑一个小模型试训看模型有没有学会基本的格式和语气再决定要不要批量生产。批量生产也别忘了做去重和分布统计同一个问题被问了 3 万遍那就不是数据多样性是灾难。“元评论残留”这个坑也是数据题里的高频话题。所谓元评论就是数据里混入了“以上是回答”“这是一个很好的例子”“作为 AI 助手”这类描述性文本。模型学多了用户问问题时它也会产生类似的赘述。清洗时要重点匹配这类句式并检查有没有“system:”“assistant:”等模板标签残留在回答里。面试官问“你怎么判断一份数据能不能用”你可以给他一把尺子格式正确性、事实一致性、指令多样性、覆盖均匀性、污染率。这五个维度不需要复杂工具就能人工评分是数据质量最基本的度量方式。能把这一套讲清楚数据题基本就拿下了。4.3 端到端方案设计从数据到上线最后再补一类开放题假设你要给一个垂直行业做一个大模型助手存量数据就是过去的聊天记录和服务文档怎么设计整个项目。这种题没有标准答案但考察点很明确你能不能做技术选型。我通常会先反问一个问题知识需要实时更新吗预算多少如果知识以问答记录为主、更新不频繁可以考虑文档解析加 RAG再加少量 SFT 微调让它学会行业语气如果回复要求很高、格式要求稳定SFT 的比例要提高。完整链路至少包括数据收集与清洗、RAG 库建设、模型微调、评测回归、灰度上线、线上监控这几个环节。只盯着模型本身的人很难答出这种全链路问题。评测环节特别容易被忽视。很多人只会说“看 loss、看 BLEU、看 ROUGE”但在大模型场景这些指标只能做粗筛。实用的做法是建一套领域评测集里面包含真实用户问题、标准答案、困难样本和对抗样本每次模型更新后都跑一遍再人工对输出打分维度包括正确性、相关性和安全性。上线之后还要看线上日志里的拒绝率、超时率和用户反馈形成一个“数据-训练-评测-监控”的闭环。我见过太多项目埋头调模型最后发现失败的根因是评测集太简单模型在测试集上刷分一到真实场景就崩。面试时把“先建立评测闭环再迭代模型”这句话说出来会明显比只会堆技术名词的人高一个段位。5. 现场高频失误与最后的冲刺建议5.1 三个最容易当场被淘汰的表现根据我观察到的现场情况有三个表现最容易导致当场被淘汰。第一概念和实操脱节。比如被问到“你微调过模型吗”回答说“跑过开源框架里的示例”再追问“训练时显存占用到了多少、loss 多少、怎么调的”就答不上来。这会被直接判定为简历注水。解决办法很简单哪怕只是跑通一个小模型也要把训练参数、显存占用、bad case 记在笔记里能说出具体数字和踩坑过程。第二背数字不背逻辑。有人很顺溜地说“LoRA rank 一般设 8、16、64”但你要问他为什么就卡住了。数字只是起点背后的取舍逻辑才是面试官要的。第三不追问需求就开答。比如“怎么做一个客服助手”他直接开始背 RAG 流程完全不管用户场景、数据量、成本约束。正确的打开方式是先反问几个关键约束再给分层方案这体现的是工程判断力而不是记忆力。5.2 我自己的准备路线与避坑清单最后分享一套我在带新人时反复推荐的准备路线特别适合准备 LLM 面试的人。第一步把一款开源的 7B 模型在自己的机器上跑通用 GGUF 格式体验一下量化加载和推理第二步用几百条公开指令数据做一次 LoRA 微调记录训练前后的输出差异第三步选一个垂直领域比如产品说明书搭一个最小的 RAG 问答服务自己构造 20 个问题做评测第四步把 RLHF 三阶段和 PPO 的论文找出来不要求全懂但要把“奖励模型、策略模型、KL 惩罚”这三个词画成一张闭环图。这个路线不需要太多硬件但能覆盖掉这 8 道高频题里的大部分考点。我在实际带人的过程中还有几条避坑经验不要在简历里写“精通 LLM”除非你真能扛住半小时追问不要只盯着模型参数训练数据质量永远是第一位的不要拿到一堆工具就盲目上 Agent先在一个可控场景里验证工具调用的准确率不要忽视测试集泄露问题如果训练数据里已经包含了评测问题所有指标都是假的。这些话听起来很朴素但每一个背后都是真实项目踩出来的坑。准备面试不是背题库而是把做过的实验、踩过的坑、调过的参数变成自己的故事。这样即使遇到没准备过的题目你也知道该怎么思考因为面试官真正要看到的向来不是你的题库而是你的工程本能。