1. 为什么这 8 个问题能决定你的去留最近帮团队面试了不少 LLM 方向的候选人前前后后见了二十多个人有刚毕业的校招生也有号称做了三四年 NLP 的老兵。感触很深的一点是简历上写得天花乱坠的大模型项目经验往往在几个最基础的问题上就露了馅。所谓基础不是让你手推 Transformer 的数学公式而是看你是否真的理解自己每天在调的东西到底是什么。这 8 个问题我反复使用基本成了团队面试 LLM 岗位的固定题本。它们不偏门、不刁钻甚至在各种面经里都能看到变体但恰恰是这种好像都见过的问题最能筛掉那些背了一堆八股文却不懂原理的人。你需要明白面试官问这些问题不是要考倒你而是想通过你的回答方式来判断你遇到没见过的 bug 时有没有排查思路你调参的时候是在瞎试还是心里有数你能不能在团队里和其他人有效沟通模型相关的问题。这篇文章把这些题目的考察意图、背后的原理、以及面试官心里的理想答案都拆开讲一遍。我不是站在面试官角度教你背答案而是站在一个常年和 LLM 打交道的人的角度告诉你哪些理解是真正重要的。无论你是正准备面试还是已经在做相关开发但觉得自己基础不够扎实这篇文章都值得你花半小时认真看完。2. 问题一Transformer 的注意力机制到底在算什么这个问题 100% 会出现但很多人的回答让我非常不满意。常见的回答是注意力机制就是让模型关注重要的部分。这种回答等于没答。我需要听到的是你能把 Q、K、V 这三个矩阵的关系说清楚能解释为什么需要缩放点积能说出多头注意力解决了什么问题。通俗地理解注意力机制做的事情就是在词与词之间建立关联权重。假设你有一句话小明因为生病所以今天没来上课模型在处理生病这个词的时候需要知道它和小明关系紧密这样后续生成他的时候才知道他指代的是谁。这个关系紧密的程度就是注意力权重。具体到实现层面每个 token 会生成三个向量Query查询、Key键、Value值。你可以把这个过程类比成图书馆找书你的需求是 Query书架上的标签是 Key书的内容是 Value。你先拿着需求去比对标签找到最匹配的书架再从那里面取内容。注意力分数的计算方式就是 Query 点乘 Key得到的值越大说明越匹配。点积之后为什么要除以一个缩放因子这是很多人忽略的细节。如果向量维度很大点积的结果会很大经过 softmax 之后梯度会消失训练就不稳定。除以 d_k 的平方根是为了把点积的方差压回一个合理的范围。面试官如果追问到这里你要能说出这个动机而不是只记得公式里有这么个操作。多头注意力是另一个重点。单头注意力只能学到一种关系模式但实际语言中词与词的关系有很多种语法依赖、语义关联、指代关系等。多头注意力相当于并行跑了好几组不同的 QKV 变换每一组学习不同的关系模式最后把结果拼起来。这也是为什么 Transformer 的表达能力比 RNN 强很多的核心原因之一。还有一个容易被忽视的坑注意力机制本身没有位置信息。你说我喜欢这个因为那个模型根本不知道这个和那个谁先谁后因为注意力计算和顺序无关。所以必须加位置编码。这部分你要是能主动讲出来面试官对你的印象会好很多因为你展现的是体系化的理解而不是碎片化的知识点。3. 问题二预训练、微调、RLHF 到底各解决什么问题简历上几乎人人写用过 Lora 微调做过 RLHF 对齐但当我问这三者分别解决什么问题它们之间是什么关系时能答清楚的人不到三成。很多人把微调和 RLHF 混为一谈这是致命的认知模糊。先建立一个大框架大模型的能力是分层构建的。预训练解决的是语言理解和世界知识的问题。这个阶段用海量文本做自监督学习说白了就是让模型看无穷无尽的文本不断预测下一个词。经过这个阶段模型学会了语法、事实知识、推理的雏形。但这时候的模型是知识渊博但不会聊天的你问它问题它可能会接一段看起来相关但完全不符合你需求的自由联想文本。微调SFT解决的是学会对话的格式和风格。你用一批高质量的人工标注数据——用户提问加上理想回答——去调整模型让它学会当别人这样问的时候你应该这样答。这个阶段主要改变的是模型的响应风格和遵循指令的能力。注意一个关键点SFT 能让模型表现得听话但模型可能会一本正经地胡说八道因为它并不知道哪些知识是对的。RLHF基于人类反馈的强化学习解决的是对齐人类偏好的问题。人类标注员对模型的多个回答做排序训练一个奖励模型再用强化学习去优化策略。这一步让模型的输出更符合人类对好回答的判断标准更有帮助、更安全、更少有害内容。RLHF 不是在教模型新知识而是在校准模型的价值观和行为偏好。我在面试中特别喜欢追问的一个点是如果模型回答里有事实性错误你应该用 SFT 还是 RLHF 来解决答案是都不一定。事实性错误往往是模型本身缺少相关知识你可以通过补充检索RAG或者继续预训练来注入知识微调在这个场景下帮助有限。这个问题考察的是你能不能区分模型不知道和模型不配合这两类问题的本质差异。4. 问题三Llama 这种开源模型和 ChatGPT 这种闭源模型技术路线差在哪这个问题看起来像闲聊实际上考察的是你对整个 LLM 生态的全局视野。很多人只知道一个是开源的一个是闭源的但说不出两者在技术路线上的核心差异和各自的取舍逻辑。Llama 系列模型的开源策略本质上是把预训练 微调 部署整套链路开放出来。这意味着你可以在基座模型上做各种后训练实验可以私有化部署在自有服务器上可以针对特定领域数据做继续预训练。对开发者和研究者来说可定制性是最核心的价值。闭源模型的优势在于整体的训练管线更完善。OpenAI 这类公司人力财力雄厚在数据清洗、对齐策略、安全评测等环节投入了大量资源所以模型的开箱即用体验和安全性通常更好。你可以通过 API 快速集成但无法拿到权重也就意味着无法真正意义上定制模型的内在行为。这里我想提醒一个很多人容易忽略的层面生态差异。开源的 Llama 衍生出了一个庞大的工具链包括各种微调框架、量化工具、推理加速库、本地部署方案。你现在能在自己的 Mac 或者普通显卡的电脑上跑一个 7B 或 13B 的模型几乎完全依赖这个生态的成熟。闭源模型则形成了以 API 为中心的生态各种 Agent 框架、函数调用能力都在这个基础上构建。面试时如果你能补充一个自己的判断——比如在某些对数据隐私要求极高的行业里开源模型几乎是唯一选择但代价是需要养一个懂模型部署和优化的团队——这会让面试官觉得你不仅懂技术还有业务层面的思考。这种视角在高级岗位的面试中尤其加分。5. 问题四什么是上下文窗口长上下文为什么那么难上下文窗口就是指模型一次能看到的 token 数量。GPT-4 支持 128K 上下文Claude 3 做到了 200K国内的一些开源模型也在往这个方向猛冲。但支持那么长的上下文和真的能有效利用那么长的上下文是两回事能分清这一点的人很少。先说为什么长上下文这么难。根本原因在于注意力机制的计算复杂度是二次方的。上下文长度翻一倍计算量就变成原来的四倍。比如上下文从 4K 涨到 8K注意力计算量直接涨 4 倍。所以很多模型虽然宣称支持 128K实际上在用的时候你会发现后半段的信息利用得很差模型更关注开头和结尾的内容中间的被忽略了。业界管这叫lost in the middle现象。面试官问这个问题的时候通常还想听到你对几种主流长上下文方案的了解。当前大致有三条技术路线第一位置编码改进。RoPE旋转位置编码是目前最主流的选择绝大多数开源模型都基于它做长度外推。但 RoPE 本身也有限制直接外推到训练长度之外效果会崩所以出现了各种改进方案比如 NTK-aware 缩放、YaRN、LongRoPE 等。简单理解这些方法的思路都是既然直接外推不行那我就对位置维度做某种形式的插值或缩放让模型以为自己还在训练长度范围内。第二Attention 结构的稀疏化或线性化。比如滑动窗口注意力只让每个 token 关注附近的 token全局注意力只在特定层保留。这类方案的目的是降低长上下文的计算复杂度但会牺牲一部分全局建模能力。第三用检索来解决长文档的需求。你不是非要把整本书塞进上下文你可以把文档切成块先检索出相关的部分只把相关的几段喂给模型。RAG 本质上就是在绕过长上下文窗口的物理限制。实操中还有一个很容易踩的坑训练长上下文的成本。把模型从 4K 训练到 32K需要构造长文本样本、调整训练策略GPU 显存消耗成倍增加。很多开源模型号称支持长上下文其实只是训练了一小部分长样本实际效果并不稳定。所以做产品的时候不要贪窗口长度够用就行该上 RAG 就上 RAG。6. 问题五LoRA 微调为什么能省显存它微调时到底改动了什么LoRA 现在几乎成了微调的代名词但很多人的理解停留在它是一种高效微调方法这个层面。如果你只能说出这句话面试基本就凉了一半。全参数微调意味着你要为模型每一个参数计算梯度。一个 7B 模型哪怕用半精度存储光模型本身就要 14GB 显存而训练时还需要存优化器状态、梯度、激活值总显存需求轻松突破 100GB。这就是为什么全参微调 7B 模型至少要一张 A100 40GB 起步的原因。LoRA 的核心思想是我不直接更新原始权重矩阵而是冻结原始权重在旁边加两个低秩的小矩阵来模拟权重的更新量。以 W 表示一个权重矩阵它的维度是 d×d。LoRA 把更新量 ΔW 分解成 A×B其中 A 是 d×rB 是 r×dr 远远小于 d比如 r8。你需要训练的就是 A 和 B 这两个小矩阵的参数总参数量可能只有原来的千分之一甚至更少。为什么能这样简化因为研究者发现微调过程中模型权重的变化量其实是低秩的也就是说 ΔW 可以用很低的维度来近似表达。你可以理解为模型本来已经学会了绝大部分知识微调只是在原有基础上做小幅修正而小幅修正可以用更紧凑的方式来表达。LoRA 是在这个观察基础上做的工程化落地。面试层级的问题来了LoRA 微调完之后模型权重变了吗答案是原始权重矩阵 W 没有变你把训练好的 A 和 B 乘起来得到 ΔW然后把这个 ΔW 加到 W 上推理时可以合并或者保持两个矩阵独立推理时先算原始路径再算新路径。很多人在这个细节上栽跟头。另一个我被问过也喜欢反问别人的问题是r秩怎么选r 太小表达能力不够微调效果差r 太大失去了省参数的意义。8 到 16 是比较常用的起点具体要看你的任务复杂度。还有一点要记得LoRA 加在哪些层上是有讲究的通常加在注意力层的 QKV 投影上效果性价比最高但不同任务的最优组合需要自己实验排查。7. 问题六什么是幻觉有哪些工程上的缓解手段幻觉问题现在是 LLM 落地的头号拦路虎。面试官问这个问题不只想听你复述模型会一本正经地胡说八道还想知道你有没有真正处理过这个问题能不能给出工程上可行的方案。先定义清楚问题幻觉指的是模型生成了与事实不符、或者与用户输入矛盾的内容。它可以分成两种类型一种叫内在幻觉就是模型把知识记混了生成的答案内部自相矛盾另一种叫外在幻觉就是模型编造了不存在的事实比如问一个不存在的软件库的用法模型能给你像模像样地编出一整套 API 文档。工程上的缓解手段通常分三个层次第一个层次是输入侧。最有效的手段是 RAG也就是给模型外挂一个知识库。模型不知道怎么回答的时候先去知识库检索相关文档把检索结果拼到提示词里再让模型回答。这个方案能大幅减少纯粹的知识型幻觉。但 RAG 不是银弹检索到的文档如果不相关反而会诱导模型产生新的幻觉。所以检索质量本身很关键。第二个层次是模型侧。通过微调或者 RLHF 对模型的行为进行约束。比如在训练数据中刻意加入大量不知道的场景教会模型说这个我不太确定我没有相关的知识。也可以让模型学会在回答时引用依据如果答案能从给定的上下文中找到出处就附上原文找不到就直接承认不知道。第三个层次是输出侧。在推理阶段做校验。比如对于数字类、事实类的答案接入一个验证器去核查。更简单的策略是设计提示词要求模型在不确定的时候输出我不确定而不是硬答。还可以使用采样参数控制降低 temperature 能让模型更保守、更倾向于高频的确定性输出。面试时如果你想显得更有实操经验可以说一个我在实际项目里特别依赖的细节幻觉问题的改善很难通过一个方法彻底解决本质上是一个系统工程。RAG 解决了知识来源问题对齐解决了态度问题校验兜底解决了输出可信度问题三层缺一不可。能说出这种层级化思路的候选人我会认为他是真的做过事情的。8. 问题七RAG 和微调怎么选这两个方案冲突吗这个问题的普遍性在于很多业务场景里你既可以选择 RAG 也可以选择微调但两者的适用条件完全不同。如果选错了方案项目周期和数据成本会差出一大截。RAG 的核心理念是不改变模型改变模型看到的内容。它适合的场景有知识库的内容经常更新比如政策法规、产品文档需要检查答案的出处和可信度冷启动阶段没有足够的训练数据。RAG 最大的优势是灵活知识更新只需要更新向量数据库不需要重新训练模型。但它也有天花板检索质量和生成逻辑是脱节的检索到了错误的片段生成结果就会跟着错。微调适合的场景是希望改变模型的表达风格、输出格式、领域术语的运用方式模型本身的领域能力不足比如医疗诊断模型需要理解专业术语需要稳定复现某种行为模式。微调的问题在于数据和算力成本高而且每次更新都需要重新训练不适合知识频繁变化的场景。一个常见的误区是这两个方案是互斥的。恰恰相反在实际工程中它们经常叠加使用。举个例子法律问答系统里你可以先微调模型让它学会法律文书的结构和正式的语气然后在每次问答时通过 RAG 检索最新的法条和判例喂给模型作为参考依据。这样模型既有领域表达能力又能保证答案基于最新、真实的法律信息。关于选型我给一个我自己常用的判断框架面试里你直接说出来会显得很专业先问知识更新频率高则优先 RAG低则可以考虑微调再问错误容忍度绝对不能出错且需要追溯来源的场景优先 RAG风格类、结构类的要求优先微调最后看资源约束数据少、算力紧、希望快速上线无脑 RAG。9. 问题八模型推理速度太慢你会从哪些方向上优化这个问题几乎是我面试的压轴题因为它能测试出候选人有没有真正部署过模型而不只是在别人的框架里跑过 Demo。推理优化是一个庞大的话题但核心可以拆成几个层面。计算层面最常见的优化是 KV Cache。这个我要强调一下因为很多人理解不到位。自回归生成的时候每一步都要算注意力而算注意力的时候需要用到之前所有 token 的 Key 和 Value。如果每次从头算代价是 O(N²)但如果你把之前算出来的 K 和 V 缓存起来每一步就只算新 token 的 QKV代价降成 O(N)。KV Cache 是几乎所有推理框架的默认行为但它非常吃显存所以在服务端要做显存管理在端侧要做量化压缩。模型层面的优化主要是量化。把权重从 FP16 降到 INT8 或者 INT4模型体积直接减半甚至减到四分之一推理速度也相应提升。量化的原理是神经网络其实对数值精度没有想象中那么敏感合理设计的量化方案可以把精度损失控制在很小的范围。但量化不是无脑做的还要考虑激活值的分布有些层对量化很敏感需要混合精度处理。结构层面的优化是投机采样。思路很直接小模型负责草拟未来几步的 token大模型只需要一次性验证这些 token 是否合理。因为小模型生成速度快大模型验证速度快于生成速度整体吞吐能提升两到三倍。这个方案在服务端推理里越来越流行。工程层面还有一个很多新人不知道的技巧采用 vLLM 这类推理框架而不是裸用 Transformers 库。vLLM 实现的 PagedAttention 把 KV Cache 的管理方式优化到了接近操作系统虚拟内存的水平显存利用率极大提升吞吐量能比 naive 实现高上好几倍。最后还有一个经常被忽略的维度业务层面的优化。如果不需要流式输出长回答可以让模型直接生成最终结果而不是逐步输出如果用户只是做分类抽取没必要用最大的模型合理的缓存策略能把高频问题的回答直接命中。在面试中提到这个层面说明你是从系统角度思考问题的而不只盯着模型这一层。10. 面试官没明说但很在意的三个隐藏考点这 8 个问题之外还有三个面试官几乎必然会观察的隐藏点它们不会以独立题目的形式出现但贯穿在整个面试过程中。第一个是承认不知道的能力。LLM 领域迭代太快没有人什么都懂。当被问到不熟悉的具体技术时我见过最优秀的候选人会这样说这个具体实现我不太确定但我对它的基本原理的理解是……这种回答让我看到一个工程师最重要的品质——诚实地面对知识的边界同时有问题定位和推理的能力。相反那些硬着头皮编答案的候选人在工程协作中会是非常危险的。第二个是在回答中展现为什么的思考深度。举个例子你用过 LoRA 吗好的回答不只是用过而是我们在一个法律文本抽取的项目中用了 LoRA之所以选 r16 而不是 8是因为我们试过 r8 之后发现抽取的 F1 有明显下降说明任务复杂度需要更高的表达容量同时我们还对比了加在注意力层和 FFN 层的效果差异。这种回答的核心价值在于他展示了调参过程是假设驱动、实验验证的而不是拍脑袋。第三个是对开源生态的熟悉程度。我会观察候选人是否了解当前主流的开源模型家族、微调框架、推理框架、评测基准。这不是要求你去背每个项目的 README而是希望看到你是一个活跃在社区里的人知道哪里在发生什么变化。LLM 这种快速迭代的领域信息获取和学习能力可能比当前的知识存量更重要。11. 一些亲身经历的面试小建议我从面试和被面试两个角度给你几个实在的建议。如果你正在准备面试不要只看面经。面经能帮你画出知识地图但真正的理解需要动手。我的建议是自己选一个开源模型在本地或云端完整地做一次微调记录下每个关键步骤的显存变化、效果对比再自己搭一个 RAG 服务亲眼看一看检索质量对生成答案的影响有多大再部署一个量化模型实测推理速度。这三件事做完你的理解会超过大多数只看文档的候选人。面试过程中要想清楚面试官问问题不是在审问你而是在通过你的回答来想象未来和你在一个团队里工作的画面。这个人遇到问题会不会自己钻研追问细节的时候他是不是有耐心他对不懂的东西是诚实地跳过还是强行解释把这些想明白了你就知道应该展现出什么状态。被问到不会的问题一个大忌是慌张。你有两种情况可以坦白一种是你真的完全不了解这个领域那就大方说这块我不太了解我了解的是相邻的……另一种是你知道思路但记不清细节那就把思路说出来然后补充具体参数/公式记不太清了如果给我时间我可以查证后补上。这两种回答方式在面试官的心里都是及格的比编一个错误答案强得多。最后提醒一句面试是双向的。好的候选人也会问面试官你们上线了哪些模型推理成本大概在什么量级遇到过最大的工程挑战是什么。这些问题不仅让你判断这个团队值不值得加入也传递了一个信息——我是带着工程师的实战思维来面这个岗位的。