1. 为什么这8个问题成了LLM岗位的硬门槛面过LLM岗位的人大概都有这种体验简历上写着“熟悉Transformer”“做过RAG项目”“微调过开源模型”结果面试官第一个问题就把人问住了。不是问得多偏而是问得太基础——基础到很多人以为自己会实际上答不完整。我参与过不少轮大模型方向的技术面试也帮朋友做过模拟面。一个很明显的规律是能把这8个问题答利索的人不一定做过最炫的项目但答不上来的人基本在初筛阶段就被划掉了。原因很简单LLM岗位现在不缺“调包侠”缺的是真正理解模型内部在发生什么、知道工程边界在哪的人。面试官问这些问题不是考记忆力是在判断你有没有能力在模型出问题时定位到根因。这8个问题大致覆盖了这几个方向Transformer架构的核心机制、Tokenization的实际影响、注意力计算的复杂度、位置编码的演进、Function Calling的工程实现、模型幻觉的成因与缓解、上下文窗口的管理策略、以及微调与提示工程的取舍。每一个都不是孤立的知识点而是串起来构成了一条“从输入文本到模型输出”的完整链路。你答得上一个说明你懂一个环节你能把几个串起来讲清楚面试官才会认为你真的做过端到端的事情。这篇文章我打算按面试的真实节奏来写不是教科书式的知识点罗列而是把每个问题拆成“面试官到底想听什么”“标准答案的骨架是什么”“哪些细节能加分”“哪些回答会直接减分”四个层面。中间会穿插我自己踩过的坑和带人时发现的常见误区。适合正在准备LLM岗位面试的人也适合已经入行但想系统梳理一遍底层逻辑的工程师。2. Transformer架构面试官真正想确认的三件事2.1 自注意力到底在算什么别只背公式几乎每场LLM面试都会从Transformer切入但面试官问法差别很大。初级岗位可能直接问“Self-Attention的公式是什么”高级岗位则会问“为什么Self-Attention比RNN更适合长序列建模”。这两种问法背后考察的深度完全不同。先说公式层面。Self-Attention的核心计算是Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V这个公式很多人能默写但面试官真正想确认的是你理解每一步在干什么。Q和K的点积是在计算“当前token和其他token的相关性分数”除以sqrt(d_k)是为了防止点积结果过大导致softmax梯度消失softmax把分数归一化成权重最后用这些权重对V做加权求和。关键点在于这个过程是并行的每个token的位置输出可以同时计算不依赖前一个时间步的结果。这正是Transformer比RNN快的原因也是它能扩展到超长序列的基础。面试官如果追问“为什么要除以sqrt(d_k)”你要能说出假设Q和K的每个分量都是独立同分布、均值0方差1的随机变量那么它们的点积的方差就是d_k。当d_k很大时点积的数值范围会很大softmax的输出会趋近于one-hot梯度会变得极小。除以sqrt(d_k)就是把方差拉回到1附近保持梯度的稳定性。这个解释比单纯说“防止梯度消失”要具体得多面试官一听就知道你是真理解而不是背的。2.2 多头注意力不是简单的并行而是子空间投影Multi-Head Attention经常被误解成“把Self-Attention跑几遍然后拼起来”。这个理解不算错但太浅了。面试官想听的是多头机制让模型在不同的表示子空间里学习不同的注意力模式。具体来说假设模型维度是512头数是8那么每个头的维度就是64。输入经过线性变换后被拆成8组Q、K、V每组独立做注意力计算最后把8个头的输出拼接起来再过一层线性变换。这样做的好处是一个头可能关注语法依赖关系另一个头可能关注语义相似度还有一个头可能关注位置邻近性。如果只有一个头这些模式会混在一起模型很难同时学好。我在实际调试模型时发现一个有意思的现象某些头在训练后会变得“几乎不活跃”注意力权重接近均匀分布。这说明模型自己学会了某些头不需要特别关注特定模式。面试时如果你能提到这一点说明你不仅看过论文还实际观察过模型行为这是很强的加分项。2.3 残差连接和LayerNorm的位置选择有讲究Transformer的每个子层后面都有残差连接和LayerNorm但这两者的顺序在不同变体里是不一样的。原始论文用的是Post-LN先做Attention/FFN再残差LayerNorm后来很多模型改成了Pre-LN先LayerNorm再做Attention/FFN最后残差。这个区别在面试中经常被忽略但它直接影响训练稳定性。Post-LN在深层模型中容易出现梯度消失需要小心的学习率预热Pre-LN则更稳定但表达能力和最终性能可能略有差异。如果你面的是需要手写Transformer的岗位面试官可能会让你解释为什么现在主流模型大多用Pre-LN或者RMSNorm。RMSNorm是LayerNorm的简化版去掉了均值中心化只做方差归一化计算更快且效果相当。这些细节能答上来说明你对架构演进有跟踪。3. Tokenization被低估的面试重灾区3.1 BPE、WordPiece和SentencePiece的区别不只是算法Tokenization看起来是个预处理步骤但它在面试中的出现频率远超很多人的预期。原因很实际Tokenization直接决定了模型的输入长度、词表大小、多语言能力和对未登录词的处理方式。面试官问这个问题是在判断你有没有处理过真实数据。BPEByte Pair Encoding的核心思想是从字符级别开始不断合并出现频率最高的相邻字符对直到达到预设的词表大小。WordPiece和BPE类似但合并的标准不是频率而是似然增益。SentencePiece则更进一步它把空格也当作普通字符处理不依赖预分词因此对中文、日文等没有明显词边界的语言更友好。面试中常见的追问是“为什么GPT系列用BPE而BERT用WordPiece”这个问题没有标准答案但你可以从工程角度回答BPE的实现更简单合并规则更直观适合大规模训练WordPiece在相同词表大小下可能产生更少的token对英文任务更高效。关键是要说明选择取决于具体场景而不是哪个绝对更好。3.2 中文Tokenization的坑比英文多得多如果你面的是国内团队中文Tokenization几乎必问。一个典型的坑是很多开源模型的中文词表覆盖不足导致一个常用汉字被拆成多个byte token。比如“你好”在某些模型里可能被编码成3到4个token而英文的“hello”只有1个token。这直接导致中文输入的有效上下文长度缩水推理成本上升。我在实际项目中遇到过这种情况同一个模型英文输入2000 token能处理的内容中文输入需要3500 token才能表达同样的信息量。解决办法通常是在微调时扩充中文词表或者选择原生支持中文的模型。但扩充词表会改变embedding层的维度需要重新训练或至少做embedding对齐这是有成本的。面试时如果你能说出这个trade-off面试官会认为你真正处理过中文场景。另一个常见问题是特殊token的处理。比如padding token、CLS token、SEP token在不同模型里的定义和使用方式不同。如果你在面试中被问到“如何计算一个batch里不同长度序列的attention mask”你要能说清楚padding位置的mask要设为负无穷这样softmax之后权重为0不会影响有效token的表示。3.3 词表大小对模型性能的隐性影响词表大小是一个需要权衡的参数。词表太小常见词被拆成多个token序列变长计算量增加词表太大embedding矩阵参数量膨胀低频词训练不充分而且softmax层的计算量也会增加。一般来说英文模型的词表在3万到5万之间比较常见多语言模型可能到10万以上。但词表大小不是越大越好关键要看词频分布和语言覆盖。面试时如果被问到“给你一个垂直领域的数据集你会怎么设计词表”你可以从这几个角度回答先统计领域内的高频词和专有名词确保它们不被拆碎保留通用词表的基础部分以维持泛化能力对领域特有词做增量合并。这个回答既展示了技术理解也展示了工程思维。4. 位置编码从正弦函数到RoPE的演进逻辑4.1 为什么Self-Attention本身不知道顺序Transformer的Self-Attention有一个根本性的特点它对输入序列的顺序是不敏感的。也就是说如果把“猫追狗”和“狗追猫”的token打乱顺序输入在没有位置编码的情况下注意力计算的结果是一样的。这显然不符合语言理解的需求。位置编码就是用来解决这个问题的。原始Transformer用的是正弦位置编码通过不同频率的sin和cos函数为每个位置生成一个唯一的向量然后直接加到token的embedding上。这种编码的好处是不需要训练可以外推到训练时没见过的长度缺点是外推能力有限而且在深层模型中位置信息容易衰减。面试中如果问“正弦位置编码为什么能表示相对位置”你要能解释对于任意固定的偏移量k位置pk的编码可以表示为位置p编码的线性变换。这个性质使得模型能够学习到相对位置关系而不仅仅是绝对位置。但实际中这种线性关系在训练后是否被模型有效利用是有争议的。4.2 可学习位置编码的局限与RoPE的突破可学习位置编码如BERT使用的把每个位置的embedding作为参数训练优点是灵活缺点是无法处理超过最大训练长度的序列。如果训练时最大长度是512推理时来了一个600长度的输入后面88个位置没有对应的embedding只能截断或报错。RoPERotary Position Embedding是目前主流大模型广泛采用的位置编码方案。它的核心思想不是“加”位置信息而是通过旋转矩阵把位置信息“乘”进Q和K的表示里。具体来说对于位置m的query向量和位置n的key向量它们的点积会自然地包含一个与(m-n)相关的旋转角度。这意味着RoPE天然编码了相对位置信息而且理论上可以外推到更长的序列。我在实际使用中发现RoPE的外推能力也不是无限的。当推理长度远超训练长度时注意力分数会出现异常模型输出质量明显下降。常见的缓解方法包括位置插值把长序列的位置映射回训练时的范围和NTK-aware缩放。面试时如果能提到这些工程技巧说明你不只是知道RoPE的概念还处理过实际的长文本问题。4.3 ALiBi和其他轻量方案的取舍ALiBiAttention with Linear Biases是另一种位置编码方案它不修改embedding而是在注意力分数上直接加一个与距离成正比的偏置项。距离越远偏置越负注意力权重越小。这种方案的优点是实现极简外推能力好缺点是它假设位置关系是单调递减的对于某些需要长距离依赖的任务可能不够灵活。面试中如果被问到“你会选哪种位置编码”不要直接说“RoPE最好”。更好的回答是看任务需求。如果是标准的大模型预训练RoPE是目前的主流选择生态支持好如果推理时需要处理超长序列且不想做复杂的缩放ALiBi可能更省事如果是特定领域的短序列任务可学习位置编码也够用。展示出你根据场景做选择的能力比给出一个绝对答案更重要。5. Function Calling从Prompt技巧到工程协议5.1 Function Calling不是简单的JSON输出Function Calling是LLM应用开发中的核心能力也是面试中区分“做过Demo”和“做过产品”的分水岭。很多人以为Function Calling就是让模型输出一段JSON然后解析出来调用函数。这个理解太表面了。真正的Function Calling涉及几个层面模型需要理解用户的自然语言意图判断是否需要调用工具选择合适的工具提取正确的参数处理参数缺失或格式错误的情况最后把工具返回的结果整合回自然语言回复。这是一个完整的闭环任何一个环节出问题都会导致体验崩溃。面试中常见的问题是“如果模型输出的JSON格式不对怎么办”初级回答是“用正则表达式提取”或“重试”。更好的回答是在prompt中明确约束输出格式使用JSON Schema做校验如果校验失败则把错误信息反馈给模型让它重新生成。更工程化的做法是在解码阶段做约束比如用语法引导的解码grammar-constrained decoding强制模型只能输出合法的JSON。这个回答能体现出你对生产环境可靠性的理解。5.2 工具描述的设计比模型能力更关键在实际项目中Function Calling的成功率很大程度上取决于工具描述的质量。我见过太多团队把工具描述写得含糊不清然后抱怨模型“太笨”。其实问题出在描述上。一个好的工具描述应该包含工具的功能一句话概括、每个参数的类型和含义、参数的取值范围或枚举值、什么情况下应该调用这个工具、什么情况下不应该调用。这些信息要写得像给一个新员工看的文档而不是像给机器看的代码注释。模型对自然语言的理解能力很强但它不会猜你的意图。举个例子如果你有一个查询天气的工具描述里只写“获取天气信息”模型可能在你问“今天适合穿什么”的时候不调用它。但如果你写“当用户询问天气、温度、是否下雨、穿衣建议时调用此工具”模型的调用准确率会明显提升。面试时如果你能举出这种具体的优化案例比空谈“优化prompt”有说服力得多。5.3 多工具场景下的选择与编排当系统里有几十个工具时Function Calling的难度会指数级上升。模型需要在众多工具中选择正确的那个还要处理工具之间的依赖关系。比如用户说“帮我订一张明天去北京的机票然后预约一个接机服务”这需要先调用航班查询工具拿到结果后再调用接机预约工具而且接机时间要依赖航班到达时间。这种编排逻辑目前主要靠两种方式实现一种是在prompt里写清楚工具之间的依赖关系和调用顺序另一种是用外部的编排引擎如状态机或工作流引擎来管理。前者灵活但不可靠后者可靠但需要额外开发。面试时如果被问到“如何保证多步工具调用的正确性”你可以说对于关键业务流程不要完全依赖模型的自主编排而是用代码定义好状态转移模型只负责在每一步做局部决策。这个回答体现了你对可靠性的重视。6. 幻觉问题面试官想听的不是“用RAG”6.1 幻觉的根源在训练目标和解码策略“模型为什么会产生幻觉”是LLM面试的高频问题。很多人第一反应是“因为训练数据不够”或“因为模型不够大”。这些回答不算错但没有触及本质。幻觉的根本原因在于语言模型的训练目标是最大化下一个token的似然概率而不是保证事实正确性。模型学到的是“什么样的文本看起来合理”而不是“什么是真的”。当模型遇到训练数据中少见或没有的情况时它会根据学到的语言模式“编造”一个看起来合理的答案而不是说“我不知道”。另一个重要因素是解码策略。贪心解码每次选概率最高的token容易陷入重复和保守输出束搜索Beam Search会探索多条路径但可能选出整体概率高但事实错误的序列采样Sampling增加了多样性但也增加了随机性带来的错误。温度参数调高幻觉概率通常上升调低输出变得保守但可能更准确。面试时如果你能把这些因素串起来讲说明你对生成过程有完整的理解。6.2 RAG不是万能药检索质量决定上限RAG检索增强生成被很多人当成解决幻觉的银弹。但实际上RAG的效果高度依赖检索质量。如果检索到的文档不相关或包含错误信息模型会基于错误信息生成更“自信”的错误答案这比没有RAG更糟糕。我在实际项目中的经验是RAG系统的瓶颈通常在检索环节而不是生成环节。向量检索的召回率、chunk的切分策略、embedding模型的选择、rerank的引入每一个环节都会影响最终效果。面试时如果被问到“如何设计一个RAG系统”不要只讲“把文档切块、向量化、检索、拼接prompt”这个流水线而要讲清楚每个环节的取舍。比如chunk大小是固定长度还是按语义切分embedding模型是用通用的还是领域微调的检索后要不要做rerank这些细节才是区分经验深浅的地方。6.3 让模型说“不知道”比让它答对更难一个反直觉的事实是训练模型在不确定时输出“我不知道”比训练它答对问题更难。因为训练数据里几乎没有“我不知道”这种表达模型没有学过在什么情况下应该拒绝回答。常见的做法包括在prompt里明确指示“如果信息不足请回答不知道”用RLHF训练模型校准置信度在系统层面加一个置信度阈值低于阈值时直接返回兜底话术。但这些方法都有局限。prompt指示容易被模型忽略RLHF需要大量标注数据置信度阈值很难设定得准确。面试时如果被问到这个问题你可以说完全消除幻觉目前不现实工程上的目标是“可控”。对于高风险场景不要让模型直接输出最终答案而是让模型输出结构化的信息由外部系统做校验和兜底。这个思路比追求“零幻觉”更务实。7. 上下文窗口不是越大越好而是越有效越好7.1 长上下文的“迷失中间”现象现在很多模型宣称支持128K甚至更长的上下文但实际使用中你会发现模型对上下文中间部分的信息利用率明显低于开头和结尾。这就是所谓的“Lost in the Middle”现象。原因和注意力机制的特性有关。在长序列中注意力权重容易集中在开头如系统prompt和结尾如最近的对话中间部分的信息被“淹没”。这不是模型容量不够而是注意力分配的问题。面试时如果被问到“如何处理长文档问答”你可以说不要把所有内容一股脑塞进上下文而是先用检索或摘要的方式筛选出最相关的片段再送给模型。这比单纯扩大上下文窗口更有效。7.2 上下文压缩的几种实用策略在实际工程中上下文管理是一个持续优化的过程。常见的策略包括滑动窗口只保留最近N轮对话、摘要压缩把历史对话总结成一段话、关键信息提取只保留实体和意图相关的信息、分层记忆短期记忆用完整对话长期记忆用向量检索。每种策略都有代价。滑动窗口简单但会丢失早期信息摘要压缩需要额外的模型调用增加延迟和成本关键信息提取需要设计抽取规则可能漏掉重要细节分层记忆架构复杂调试难度高。面试时如果你能说出这些trade-off并给出一个你实际用过的方案和效果会非常有说服力。7.3 位置编码外推与注意力稀疏化的工程取舍从模型层面看支持长上下文需要解决两个问题位置编码的外推和注意力计算的复杂度。RoPE的位置插值和NTK缩放是常见的解决方案但它们会改变注意力分布可能影响短序列的性能。注意力稀疏化如只计算局部窗口或固定模式的注意力可以降低计算量但会损失全局信息。目前没有一个完美的方案工程上通常是根据业务场景做取舍。如果业务主要是短对话不需要折腾长上下文如果是文档分析可能需要结合检索和分块策略如果是代码生成长上下文的收益可能更明显因为代码的依赖关系跨度大。面试时展示出你根据场景做技术选型的能力比背诵某个方案的细节更重要。8. 微调与提示工程什么时候该动模型什么时候不该8.1 提示工程的边界在哪里提示工程是成本最低的适配方式但它有明确的边界。当任务需要模型掌握训练数据中不存在的新知识、新格式或新风格时提示工程的天花板很快就到了。你可以通过few-shot示例让模型学会一个简单的分类任务但你很难通过提示让模型学会一个它从未见过的专业术语体系。面试中常见的问题是“什么时候选择微调而不是提示工程”一个实用的判断标准是如果任务可以通过清晰的指令和少量示例描述清楚优先用提示工程如果任务需要模型内化大量领域知识、遵循复杂的输出格式、或者对延迟和成本有严格要求微调后可以用更小的模型则考虑微调。8.2 LoRA和全量微调的选型逻辑LoRALow-Rank Adaptation是目前最流行的参数高效微调方法。它的核心思想是在预训练模型的权重矩阵旁边加一个低秩分解的旁路只训练这个旁路冻结原始权重。这样做的好处是显存占用小、训练速度快、可以快速切换不同任务的适配器。但LoRA不是万能的。如果目标任务和预训练任务差异很大或者需要模型学习全新的能力LoRA的低秩假设可能不够用全量微调或至少更大的秩可能更合适。面试时如果被问到“LoRA的秩怎么选”你可以说从8或16开始试观察验证集效果如果欠拟合就增大秩如果过拟合就减小秩或增加dropout。关键是要有实验设计的思路而不是给一个固定值。8.3 数据质量比数据数量重要一个数量级无论是微调还是提示工程数据质量都是决定效果的核心因素。我见过太多团队花大量时间收集了几万条数据结果效果还不如精心构造的几百条。低质量数据的典型特征包括标注不一致、格式混乱、包含错误信息、覆盖不均衡。一个实用的做法是先人工构造100到200条高质量样本用它们做few-shot或微调观察效果。如果效果不错再逐步扩充数据如果效果不好先检查数据质量而不是盲目增加数量。面试时如果你能分享这种“小步快跑”的数据迭代经验比空谈“数据很重要”有说服力得多。9. 面试中的表达策略知道和讲清楚是两回事9.1 用“问题-方案-取舍”的结构组织回答技术面试中面试官不仅看你知不知道答案更看你有没有解决问题的思路。一个有效的表达结构是先确认问题的边界和约束再给出方案最后说明取舍和适用场景。比如被问到“如何优化LLM的推理速度”不要直接说“用量化”。更好的回答是先问清楚场景——是延迟敏感还是吞吐敏感硬件是什么模型规模多大然后给出可能的方案量化INT8/INT4、蒸馏用小模型替代、KV Cache优化、批处理、投机解码等。最后说明每个方案的代价量化可能损失精度蒸馏需要训练KV Cache增加显存批处理增加延迟。这种回答展示的是工程判断力而不是知识点记忆。9.2 不会的问题怎么处理面试中遇到不会的问题是正常的关键是怎么处理。最忌讳的是不懂装懂编一个听起来合理但错误的答案。面试官通常对这个领域很熟一眼就能看出来。更好的做法是坦诚说这个点我不太确定但我可以从相关的角度分析一下。然后把你确定知道的部分讲清楚把不确定的部分标记出来。比如被问到“FlashAttention的具体实现”如果你没看过论文可以说我知道它主要是通过分块计算和重计算来减少显存访问具体的内核实现我没有深入研究但我理解它的目标是让注意力计算更适配GPU的存储层次。这种回答既诚实又展示了你的知识迁移能力。9.3 用实际案例替代抽象描述面试中最有说服力的永远是具体案例。与其说“我熟悉RAG”不如说“我做过一个法律文档问答系统用了BGE的embedding模型chunk大小设为512重叠128检索后加了cross-encoder做rerank最终准确率从72%提升到89%”。具体的数字、工具名、参数和效果对比能让面试官立刻判断出你的经验深度。我在帮人做模拟面时经常发现一个现象很多人明明做过不错的项目但讲出来平平无奇。问题通常出在只讲了“做了什么”没讲“为什么这么做”和“遇到了什么问题”。面试官想听的是你的决策过程和踩坑经验而不是项目说明书。10. 几个容易被忽略但会直接减分的细节10.1 混淆概念比不知道更致命面试中有些错误是“不知道”有些错误是“搞混了”。后者更致命因为它说明你的知识体系有结构性缺陷。常见的混淆包括把微调和RAG混为一谈、把Tokenization和Embedding混为一谈、把Transformer的Encoder和Decoder结构混为一谈、把模型幻觉和模型错误混为一谈。避免这种错误的方法是在准备面试时画一张知识图谱把相关概念的关系理清楚。比如RAG是在推理时引入外部知识微调是在训练时改变模型参数两者解决的是不同层面的问题可以结合使用。这种清晰的概念边界是面试官判断你是否“科班”的重要依据。10.2 对最新进展一无所知LLM领域变化很快面试官通常会关注你有没有跟踪最新进展。不需要你读遍所有论文但至少要知道主流模型的基本情况、常见工具链的更新、以及社区讨论的热点问题。比如如果面试官提到“MoE架构”你要知道它是什么、为什么能降低推理成本、有哪些代表模型。如果提到“Agent”你要能说清楚Agent和普通Function Calling的区别、当前的主要挑战是什么。这些不需要你成为专家但完全不知道会显得你和行业脱节。10.3 忽视工程约束谈方案很多候选人在面试时喜欢谈“理想方案”但忽略了实际工程中的约束。比如被问到“如何部署一个LLM服务”有人会大谈模型架构和算法优化却不提显存限制、并发处理、监控告警、成本控制这些工程问题。在实际工作中工程约束往往比算法选择更能决定方案是否可行。面试时如果你能主动提到“这个方案在A100上可能可行但在消费级显卡上需要做量化”或者“这个方案的延迟在200ms左右如果业务要求100ms以内需要换思路”面试官会认为你是一个有落地经验的人而不是只会纸上谈兵。准备LLM面试本质上不是背八股文而是系统梳理自己对整个技术栈的理解。这8个问题之所以成为必问是因为它们覆盖了从模型原理到工程落地的关键节点。你不需要每个问题都答得完美但至少要能在每个方向上说出自己的思考和经验。面试官要找的不是全知全能的人而是遇到问题时知道从哪里入手、知道如何权衡、知道怎么验证的人。把这一点传递出去比答对任何单个问题都重要。 LLM面试必问的8个核心问题：从Transformer到微调的深度解析
1. 为什么这8个问题成了LLM岗位的硬门槛面过LLM岗位的人大概都有这种体验简历上写着“熟悉Transformer”“做过RAG项目”“微调过开源模型”结果面试官第一个问题就把人问住了。不是问得多偏而是问得太基础——基础到很多人以为自己会实际上答不完整。我参与过不少轮大模型方向的技术面试也帮朋友做过模拟面。一个很明显的规律是能把这8个问题答利索的人不一定做过最炫的项目但答不上来的人基本在初筛阶段就被划掉了。原因很简单LLM岗位现在不缺“调包侠”缺的是真正理解模型内部在发生什么、知道工程边界在哪的人。面试官问这些问题不是考记忆力是在判断你有没有能力在模型出问题时定位到根因。这8个问题大致覆盖了这几个方向Transformer架构的核心机制、Tokenization的实际影响、注意力计算的复杂度、位置编码的演进、Function Calling的工程实现、模型幻觉的成因与缓解、上下文窗口的管理策略、以及微调与提示工程的取舍。每一个都不是孤立的知识点而是串起来构成了一条“从输入文本到模型输出”的完整链路。你答得上一个说明你懂一个环节你能把几个串起来讲清楚面试官才会认为你真的做过端到端的事情。这篇文章我打算按面试的真实节奏来写不是教科书式的知识点罗列而是把每个问题拆成“面试官到底想听什么”“标准答案的骨架是什么”“哪些细节能加分”“哪些回答会直接减分”四个层面。中间会穿插我自己踩过的坑和带人时发现的常见误区。适合正在准备LLM岗位面试的人也适合已经入行但想系统梳理一遍底层逻辑的工程师。2. Transformer架构面试官真正想确认的三件事2.1 自注意力到底在算什么别只背公式几乎每场LLM面试都会从Transformer切入但面试官问法差别很大。初级岗位可能直接问“Self-Attention的公式是什么”高级岗位则会问“为什么Self-Attention比RNN更适合长序列建模”。这两种问法背后考察的深度完全不同。先说公式层面。Self-Attention的核心计算是Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V这个公式很多人能默写但面试官真正想确认的是你理解每一步在干什么。Q和K的点积是在计算“当前token和其他token的相关性分数”除以sqrt(d_k)是为了防止点积结果过大导致softmax梯度消失softmax把分数归一化成权重最后用这些权重对V做加权求和。关键点在于这个过程是并行的每个token的位置输出可以同时计算不依赖前一个时间步的结果。这正是Transformer比RNN快的原因也是它能扩展到超长序列的基础。面试官如果追问“为什么要除以sqrt(d_k)”你要能说出假设Q和K的每个分量都是独立同分布、均值0方差1的随机变量那么它们的点积的方差就是d_k。当d_k很大时点积的数值范围会很大softmax的输出会趋近于one-hot梯度会变得极小。除以sqrt(d_k)就是把方差拉回到1附近保持梯度的稳定性。这个解释比单纯说“防止梯度消失”要具体得多面试官一听就知道你是真理解而不是背的。2.2 多头注意力不是简单的并行而是子空间投影Multi-Head Attention经常被误解成“把Self-Attention跑几遍然后拼起来”。这个理解不算错但太浅了。面试官想听的是多头机制让模型在不同的表示子空间里学习不同的注意力模式。具体来说假设模型维度是512头数是8那么每个头的维度就是64。输入经过线性变换后被拆成8组Q、K、V每组独立做注意力计算最后把8个头的输出拼接起来再过一层线性变换。这样做的好处是一个头可能关注语法依赖关系另一个头可能关注语义相似度还有一个头可能关注位置邻近性。如果只有一个头这些模式会混在一起模型很难同时学好。我在实际调试模型时发现一个有意思的现象某些头在训练后会变得“几乎不活跃”注意力权重接近均匀分布。这说明模型自己学会了某些头不需要特别关注特定模式。面试时如果你能提到这一点说明你不仅看过论文还实际观察过模型行为这是很强的加分项。2.3 残差连接和LayerNorm的位置选择有讲究Transformer的每个子层后面都有残差连接和LayerNorm但这两者的顺序在不同变体里是不一样的。原始论文用的是Post-LN先做Attention/FFN再残差LayerNorm后来很多模型改成了Pre-LN先LayerNorm再做Attention/FFN最后残差。这个区别在面试中经常被忽略但它直接影响训练稳定性。Post-LN在深层模型中容易出现梯度消失需要小心的学习率预热Pre-LN则更稳定但表达能力和最终性能可能略有差异。如果你面的是需要手写Transformer的岗位面试官可能会让你解释为什么现在主流模型大多用Pre-LN或者RMSNorm。RMSNorm是LayerNorm的简化版去掉了均值中心化只做方差归一化计算更快且效果相当。这些细节能答上来说明你对架构演进有跟踪。3. Tokenization被低估的面试重灾区3.1 BPE、WordPiece和SentencePiece的区别不只是算法Tokenization看起来是个预处理步骤但它在面试中的出现频率远超很多人的预期。原因很实际Tokenization直接决定了模型的输入长度、词表大小、多语言能力和对未登录词的处理方式。面试官问这个问题是在判断你有没有处理过真实数据。BPEByte Pair Encoding的核心思想是从字符级别开始不断合并出现频率最高的相邻字符对直到达到预设的词表大小。WordPiece和BPE类似但合并的标准不是频率而是似然增益。SentencePiece则更进一步它把空格也当作普通字符处理不依赖预分词因此对中文、日文等没有明显词边界的语言更友好。面试中常见的追问是“为什么GPT系列用BPE而BERT用WordPiece”这个问题没有标准答案但你可以从工程角度回答BPE的实现更简单合并规则更直观适合大规模训练WordPiece在相同词表大小下可能产生更少的token对英文任务更高效。关键是要说明选择取决于具体场景而不是哪个绝对更好。3.2 中文Tokenization的坑比英文多得多如果你面的是国内团队中文Tokenization几乎必问。一个典型的坑是很多开源模型的中文词表覆盖不足导致一个常用汉字被拆成多个byte token。比如“你好”在某些模型里可能被编码成3到4个token而英文的“hello”只有1个token。这直接导致中文输入的有效上下文长度缩水推理成本上升。我在实际项目中遇到过这种情况同一个模型英文输入2000 token能处理的内容中文输入需要3500 token才能表达同样的信息量。解决办法通常是在微调时扩充中文词表或者选择原生支持中文的模型。但扩充词表会改变embedding层的维度需要重新训练或至少做embedding对齐这是有成本的。面试时如果你能说出这个trade-off面试官会认为你真正处理过中文场景。另一个常见问题是特殊token的处理。比如padding token、CLS token、SEP token在不同模型里的定义和使用方式不同。如果你在面试中被问到“如何计算一个batch里不同长度序列的attention mask”你要能说清楚padding位置的mask要设为负无穷这样softmax之后权重为0不会影响有效token的表示。3.3 词表大小对模型性能的隐性影响词表大小是一个需要权衡的参数。词表太小常见词被拆成多个token序列变长计算量增加词表太大embedding矩阵参数量膨胀低频词训练不充分而且softmax层的计算量也会增加。一般来说英文模型的词表在3万到5万之间比较常见多语言模型可能到10万以上。但词表大小不是越大越好关键要看词频分布和语言覆盖。面试时如果被问到“给你一个垂直领域的数据集你会怎么设计词表”你可以从这几个角度回答先统计领域内的高频词和专有名词确保它们不被拆碎保留通用词表的基础部分以维持泛化能力对领域特有词做增量合并。这个回答既展示了技术理解也展示了工程思维。4. 位置编码从正弦函数到RoPE的演进逻辑4.1 为什么Self-Attention本身不知道顺序Transformer的Self-Attention有一个根本性的特点它对输入序列的顺序是不敏感的。也就是说如果把“猫追狗”和“狗追猫”的token打乱顺序输入在没有位置编码的情况下注意力计算的结果是一样的。这显然不符合语言理解的需求。位置编码就是用来解决这个问题的。原始Transformer用的是正弦位置编码通过不同频率的sin和cos函数为每个位置生成一个唯一的向量然后直接加到token的embedding上。这种编码的好处是不需要训练可以外推到训练时没见过的长度缺点是外推能力有限而且在深层模型中位置信息容易衰减。面试中如果问“正弦位置编码为什么能表示相对位置”你要能解释对于任意固定的偏移量k位置pk的编码可以表示为位置p编码的线性变换。这个性质使得模型能够学习到相对位置关系而不仅仅是绝对位置。但实际中这种线性关系在训练后是否被模型有效利用是有争议的。4.2 可学习位置编码的局限与RoPE的突破可学习位置编码如BERT使用的把每个位置的embedding作为参数训练优点是灵活缺点是无法处理超过最大训练长度的序列。如果训练时最大长度是512推理时来了一个600长度的输入后面88个位置没有对应的embedding只能截断或报错。RoPERotary Position Embedding是目前主流大模型广泛采用的位置编码方案。它的核心思想不是“加”位置信息而是通过旋转矩阵把位置信息“乘”进Q和K的表示里。具体来说对于位置m的query向量和位置n的key向量它们的点积会自然地包含一个与(m-n)相关的旋转角度。这意味着RoPE天然编码了相对位置信息而且理论上可以外推到更长的序列。我在实际使用中发现RoPE的外推能力也不是无限的。当推理长度远超训练长度时注意力分数会出现异常模型输出质量明显下降。常见的缓解方法包括位置插值把长序列的位置映射回训练时的范围和NTK-aware缩放。面试时如果能提到这些工程技巧说明你不只是知道RoPE的概念还处理过实际的长文本问题。4.3 ALiBi和其他轻量方案的取舍ALiBiAttention with Linear Biases是另一种位置编码方案它不修改embedding而是在注意力分数上直接加一个与距离成正比的偏置项。距离越远偏置越负注意力权重越小。这种方案的优点是实现极简外推能力好缺点是它假设位置关系是单调递减的对于某些需要长距离依赖的任务可能不够灵活。面试中如果被问到“你会选哪种位置编码”不要直接说“RoPE最好”。更好的回答是看任务需求。如果是标准的大模型预训练RoPE是目前的主流选择生态支持好如果推理时需要处理超长序列且不想做复杂的缩放ALiBi可能更省事如果是特定领域的短序列任务可学习位置编码也够用。展示出你根据场景做选择的能力比给出一个绝对答案更重要。5. Function Calling从Prompt技巧到工程协议5.1 Function Calling不是简单的JSON输出Function Calling是LLM应用开发中的核心能力也是面试中区分“做过Demo”和“做过产品”的分水岭。很多人以为Function Calling就是让模型输出一段JSON然后解析出来调用函数。这个理解太表面了。真正的Function Calling涉及几个层面模型需要理解用户的自然语言意图判断是否需要调用工具选择合适的工具提取正确的参数处理参数缺失或格式错误的情况最后把工具返回的结果整合回自然语言回复。这是一个完整的闭环任何一个环节出问题都会导致体验崩溃。面试中常见的问题是“如果模型输出的JSON格式不对怎么办”初级回答是“用正则表达式提取”或“重试”。更好的回答是在prompt中明确约束输出格式使用JSON Schema做校验如果校验失败则把错误信息反馈给模型让它重新生成。更工程化的做法是在解码阶段做约束比如用语法引导的解码grammar-constrained decoding强制模型只能输出合法的JSON。这个回答能体现出你对生产环境可靠性的理解。5.2 工具描述的设计比模型能力更关键在实际项目中Function Calling的成功率很大程度上取决于工具描述的质量。我见过太多团队把工具描述写得含糊不清然后抱怨模型“太笨”。其实问题出在描述上。一个好的工具描述应该包含工具的功能一句话概括、每个参数的类型和含义、参数的取值范围或枚举值、什么情况下应该调用这个工具、什么情况下不应该调用。这些信息要写得像给一个新员工看的文档而不是像给机器看的代码注释。模型对自然语言的理解能力很强但它不会猜你的意图。举个例子如果你有一个查询天气的工具描述里只写“获取天气信息”模型可能在你问“今天适合穿什么”的时候不调用它。但如果你写“当用户询问天气、温度、是否下雨、穿衣建议时调用此工具”模型的调用准确率会明显提升。面试时如果你能举出这种具体的优化案例比空谈“优化prompt”有说服力得多。5.3 多工具场景下的选择与编排当系统里有几十个工具时Function Calling的难度会指数级上升。模型需要在众多工具中选择正确的那个还要处理工具之间的依赖关系。比如用户说“帮我订一张明天去北京的机票然后预约一个接机服务”这需要先调用航班查询工具拿到结果后再调用接机预约工具而且接机时间要依赖航班到达时间。这种编排逻辑目前主要靠两种方式实现一种是在prompt里写清楚工具之间的依赖关系和调用顺序另一种是用外部的编排引擎如状态机或工作流引擎来管理。前者灵活但不可靠后者可靠但需要额外开发。面试时如果被问到“如何保证多步工具调用的正确性”你可以说对于关键业务流程不要完全依赖模型的自主编排而是用代码定义好状态转移模型只负责在每一步做局部决策。这个回答体现了你对可靠性的重视。6. 幻觉问题面试官想听的不是“用RAG”6.1 幻觉的根源在训练目标和解码策略“模型为什么会产生幻觉”是LLM面试的高频问题。很多人第一反应是“因为训练数据不够”或“因为模型不够大”。这些回答不算错但没有触及本质。幻觉的根本原因在于语言模型的训练目标是最大化下一个token的似然概率而不是保证事实正确性。模型学到的是“什么样的文本看起来合理”而不是“什么是真的”。当模型遇到训练数据中少见或没有的情况时它会根据学到的语言模式“编造”一个看起来合理的答案而不是说“我不知道”。另一个重要因素是解码策略。贪心解码每次选概率最高的token容易陷入重复和保守输出束搜索Beam Search会探索多条路径但可能选出整体概率高但事实错误的序列采样Sampling增加了多样性但也增加了随机性带来的错误。温度参数调高幻觉概率通常上升调低输出变得保守但可能更准确。面试时如果你能把这些因素串起来讲说明你对生成过程有完整的理解。6.2 RAG不是万能药检索质量决定上限RAG检索增强生成被很多人当成解决幻觉的银弹。但实际上RAG的效果高度依赖检索质量。如果检索到的文档不相关或包含错误信息模型会基于错误信息生成更“自信”的错误答案这比没有RAG更糟糕。我在实际项目中的经验是RAG系统的瓶颈通常在检索环节而不是生成环节。向量检索的召回率、chunk的切分策略、embedding模型的选择、rerank的引入每一个环节都会影响最终效果。面试时如果被问到“如何设计一个RAG系统”不要只讲“把文档切块、向量化、检索、拼接prompt”这个流水线而要讲清楚每个环节的取舍。比如chunk大小是固定长度还是按语义切分embedding模型是用通用的还是领域微调的检索后要不要做rerank这些细节才是区分经验深浅的地方。6.3 让模型说“不知道”比让它答对更难一个反直觉的事实是训练模型在不确定时输出“我不知道”比训练它答对问题更难。因为训练数据里几乎没有“我不知道”这种表达模型没有学过在什么情况下应该拒绝回答。常见的做法包括在prompt里明确指示“如果信息不足请回答不知道”用RLHF训练模型校准置信度在系统层面加一个置信度阈值低于阈值时直接返回兜底话术。但这些方法都有局限。prompt指示容易被模型忽略RLHF需要大量标注数据置信度阈值很难设定得准确。面试时如果被问到这个问题你可以说完全消除幻觉目前不现实工程上的目标是“可控”。对于高风险场景不要让模型直接输出最终答案而是让模型输出结构化的信息由外部系统做校验和兜底。这个思路比追求“零幻觉”更务实。7. 上下文窗口不是越大越好而是越有效越好7.1 长上下文的“迷失中间”现象现在很多模型宣称支持128K甚至更长的上下文但实际使用中你会发现模型对上下文中间部分的信息利用率明显低于开头和结尾。这就是所谓的“Lost in the Middle”现象。原因和注意力机制的特性有关。在长序列中注意力权重容易集中在开头如系统prompt和结尾如最近的对话中间部分的信息被“淹没”。这不是模型容量不够而是注意力分配的问题。面试时如果被问到“如何处理长文档问答”你可以说不要把所有内容一股脑塞进上下文而是先用检索或摘要的方式筛选出最相关的片段再送给模型。这比单纯扩大上下文窗口更有效。7.2 上下文压缩的几种实用策略在实际工程中上下文管理是一个持续优化的过程。常见的策略包括滑动窗口只保留最近N轮对话、摘要压缩把历史对话总结成一段话、关键信息提取只保留实体和意图相关的信息、分层记忆短期记忆用完整对话长期记忆用向量检索。每种策略都有代价。滑动窗口简单但会丢失早期信息摘要压缩需要额外的模型调用增加延迟和成本关键信息提取需要设计抽取规则可能漏掉重要细节分层记忆架构复杂调试难度高。面试时如果你能说出这些trade-off并给出一个你实际用过的方案和效果会非常有说服力。7.3 位置编码外推与注意力稀疏化的工程取舍从模型层面看支持长上下文需要解决两个问题位置编码的外推和注意力计算的复杂度。RoPE的位置插值和NTK缩放是常见的解决方案但它们会改变注意力分布可能影响短序列的性能。注意力稀疏化如只计算局部窗口或固定模式的注意力可以降低计算量但会损失全局信息。目前没有一个完美的方案工程上通常是根据业务场景做取舍。如果业务主要是短对话不需要折腾长上下文如果是文档分析可能需要结合检索和分块策略如果是代码生成长上下文的收益可能更明显因为代码的依赖关系跨度大。面试时展示出你根据场景做技术选型的能力比背诵某个方案的细节更重要。8. 微调与提示工程什么时候该动模型什么时候不该8.1 提示工程的边界在哪里提示工程是成本最低的适配方式但它有明确的边界。当任务需要模型掌握训练数据中不存在的新知识、新格式或新风格时提示工程的天花板很快就到了。你可以通过few-shot示例让模型学会一个简单的分类任务但你很难通过提示让模型学会一个它从未见过的专业术语体系。面试中常见的问题是“什么时候选择微调而不是提示工程”一个实用的判断标准是如果任务可以通过清晰的指令和少量示例描述清楚优先用提示工程如果任务需要模型内化大量领域知识、遵循复杂的输出格式、或者对延迟和成本有严格要求微调后可以用更小的模型则考虑微调。8.2 LoRA和全量微调的选型逻辑LoRALow-Rank Adaptation是目前最流行的参数高效微调方法。它的核心思想是在预训练模型的权重矩阵旁边加一个低秩分解的旁路只训练这个旁路冻结原始权重。这样做的好处是显存占用小、训练速度快、可以快速切换不同任务的适配器。但LoRA不是万能的。如果目标任务和预训练任务差异很大或者需要模型学习全新的能力LoRA的低秩假设可能不够用全量微调或至少更大的秩可能更合适。面试时如果被问到“LoRA的秩怎么选”你可以说从8或16开始试观察验证集效果如果欠拟合就增大秩如果过拟合就减小秩或增加dropout。关键是要有实验设计的思路而不是给一个固定值。8.3 数据质量比数据数量重要一个数量级无论是微调还是提示工程数据质量都是决定效果的核心因素。我见过太多团队花大量时间收集了几万条数据结果效果还不如精心构造的几百条。低质量数据的典型特征包括标注不一致、格式混乱、包含错误信息、覆盖不均衡。一个实用的做法是先人工构造100到200条高质量样本用它们做few-shot或微调观察效果。如果效果不错再逐步扩充数据如果效果不好先检查数据质量而不是盲目增加数量。面试时如果你能分享这种“小步快跑”的数据迭代经验比空谈“数据很重要”有说服力得多。9. 面试中的表达策略知道和讲清楚是两回事9.1 用“问题-方案-取舍”的结构组织回答技术面试中面试官不仅看你知不知道答案更看你有没有解决问题的思路。一个有效的表达结构是先确认问题的边界和约束再给出方案最后说明取舍和适用场景。比如被问到“如何优化LLM的推理速度”不要直接说“用量化”。更好的回答是先问清楚场景——是延迟敏感还是吞吐敏感硬件是什么模型规模多大然后给出可能的方案量化INT8/INT4、蒸馏用小模型替代、KV Cache优化、批处理、投机解码等。最后说明每个方案的代价量化可能损失精度蒸馏需要训练KV Cache增加显存批处理增加延迟。这种回答展示的是工程判断力而不是知识点记忆。9.2 不会的问题怎么处理面试中遇到不会的问题是正常的关键是怎么处理。最忌讳的是不懂装懂编一个听起来合理但错误的答案。面试官通常对这个领域很熟一眼就能看出来。更好的做法是坦诚说这个点我不太确定但我可以从相关的角度分析一下。然后把你确定知道的部分讲清楚把不确定的部分标记出来。比如被问到“FlashAttention的具体实现”如果你没看过论文可以说我知道它主要是通过分块计算和重计算来减少显存访问具体的内核实现我没有深入研究但我理解它的目标是让注意力计算更适配GPU的存储层次。这种回答既诚实又展示了你的知识迁移能力。9.3 用实际案例替代抽象描述面试中最有说服力的永远是具体案例。与其说“我熟悉RAG”不如说“我做过一个法律文档问答系统用了BGE的embedding模型chunk大小设为512重叠128检索后加了cross-encoder做rerank最终准确率从72%提升到89%”。具体的数字、工具名、参数和效果对比能让面试官立刻判断出你的经验深度。我在帮人做模拟面时经常发现一个现象很多人明明做过不错的项目但讲出来平平无奇。问题通常出在只讲了“做了什么”没讲“为什么这么做”和“遇到了什么问题”。面试官想听的是你的决策过程和踩坑经验而不是项目说明书。10. 几个容易被忽略但会直接减分的细节10.1 混淆概念比不知道更致命面试中有些错误是“不知道”有些错误是“搞混了”。后者更致命因为它说明你的知识体系有结构性缺陷。常见的混淆包括把微调和RAG混为一谈、把Tokenization和Embedding混为一谈、把Transformer的Encoder和Decoder结构混为一谈、把模型幻觉和模型错误混为一谈。避免这种错误的方法是在准备面试时画一张知识图谱把相关概念的关系理清楚。比如RAG是在推理时引入外部知识微调是在训练时改变模型参数两者解决的是不同层面的问题可以结合使用。这种清晰的概念边界是面试官判断你是否“科班”的重要依据。10.2 对最新进展一无所知LLM领域变化很快面试官通常会关注你有没有跟踪最新进展。不需要你读遍所有论文但至少要知道主流模型的基本情况、常见工具链的更新、以及社区讨论的热点问题。比如如果面试官提到“MoE架构”你要知道它是什么、为什么能降低推理成本、有哪些代表模型。如果提到“Agent”你要能说清楚Agent和普通Function Calling的区别、当前的主要挑战是什么。这些不需要你成为专家但完全不知道会显得你和行业脱节。10.3 忽视工程约束谈方案很多候选人在面试时喜欢谈“理想方案”但忽略了实际工程中的约束。比如被问到“如何部署一个LLM服务”有人会大谈模型架构和算法优化却不提显存限制、并发处理、监控告警、成本控制这些工程问题。在实际工作中工程约束往往比算法选择更能决定方案是否可行。面试时如果你能主动提到“这个方案在A100上可能可行但在消费级显卡上需要做量化”或者“这个方案的延迟在200ms左右如果业务要求100ms以内需要换思路”面试官会认为你是一个有落地经验的人而不是只会纸上谈兵。准备LLM面试本质上不是背八股文而是系统梳理自己对整个技术栈的理解。这8个问题之所以成为必问是因为它们覆盖了从模型原理到工程落地的关键节点。你不需要每个问题都答得完美但至少要能在每个方向上说出自己的思考和经验。面试官要找的不是全知全能的人而是遇到问题时知道从哪里入手、知道如何权衡、知道怎么验证的人。把这一点传递出去比答对任何单个问题都重要。