1. 为什么这8个问题能决定面试生死面过LLM岗位的人都有一个共同感受面试官的问题看起来平平无奇但每一个都在试探你的知识边界到底在哪里。我前后参与过几十场大模型相关的技术面试既有作为候选人的经历也有作为面试官的经验慢慢发现一个规律——真正拉开差距的从来不是你背了多少名词而是你对底层机制的理解是否经得起追问。这篇文章聊的8个问题基本覆盖了LLM面试中最核心的知识板块Transformer架构、Tokenization、注意力机制、位置编码、训练与推理的差异、Function Calling、幻觉问题、模型评估。每一个问题往下追问三层就能判断出一个人是“看过几篇公众号”还是“真正动过手”。适合谁来读如果你是准备转型做大模型方向的算法工程师、正在准备面试的应届生、或者想从传统NLP转向LLM应用开发的从业者这篇内容可以直接当作复习提纲来用。我不会只给标准答案而是把每个问题背后的考察逻辑、常见陷阱、以及面试官真正想听到的东西拆开来讲。注意面试中最大的忌讳不是“不知道”而是“不懂装懂”。面试官追问两句就能识破反而扣分更严重。正确的做法是坦诚说明自己了解的边界然后展示你的推理过程。2. 八个核心问题逐一拆解2.1 Transformer为什么能取代RNN成为主流架构这个问题几乎是LLM面试的开场必问题但很多人只答“因为注意力机制更好”这等于没答。面试官想听的是你对计算范式差异的理解。RNN的核心问题是串行计算。处理一个长度为n的序列必须逐步计算第t步依赖第t-1步的隐状态。这意味着无法在时间维度上并行训练效率极低。而且长序列会出现梯度消失或爆炸虽然LSTM/GRU通过门控机制缓解了一部分但本质上没有解决长距离依赖的问题。Transformer用自注意力机制把序列中任意两个位置之间的路径长度缩短为O(1)。每个token都可以直接“看到”序列中所有其他token计算复杂度是O(n²·d)但关键在于所有位置的计算可以完全并行。这就把训练效率提升了一个数量级使得在超大规模数据上训练成为可能。但这里有个常见的追问“O(n²)的复杂度不是比RNN的O(n)更差吗”答案是在GPU并行计算的场景下O(n²)的并行计算远比O(n)的串行计算快。而且实际应用中序列长度通常不会大到让二次方复杂度成为瓶颈。后续的稀疏注意力、线性注意力等变体也都是在试图解决这个理论上的效率问题。面试官如果继续追问“多头注意力到底在做什么”你需要解释多头注意力相当于让模型在不同的表示子空间中分别学习注意力模式。比如一个头可能关注语法依赖关系另一个头可能关注语义相似度。最后把所有头的输出拼接再投影得到综合表示。头数不是越多越好通常64-128维的每个头维度是比较常见的设计。2.2 Tokenization到底在做什么为什么它这么重要Tokenization是很多人容易忽略的环节觉得不就是分词吗但面试官问这个问题往往是在考察你对模型输入输出全链路的理解。LLM处理的不是字符也不是完整的词而是subword token。主流方案有BPE、WordPiece、SentencePiece等。以BPE为例它从字符级别开始不断合并出现频率最高的相邻字符对直到词表达到预设大小。这样既能处理未登录词又能控制词表规模。为什么重要几个关键原因词表大小直接影响模型参数量。Embedding层的大小是vocab_size × hidden_dim如果词表翻倍这部分参数也翻倍。Tokenization方式影响模型对中文的处理能力。很多开源模型的中文词表覆盖不够导致一个中文字被拆成多个token不仅浪费上下文窗口还影响语义理解。不同语言的token效率差异巨大。同样一句话英文可能10个token中文可能需要30个token这直接影响推理成本和上下文利用率。面试中常见的追问是“如果让你为一个垂直领域设计tokenizer你会怎么做”这时候你需要考虑领域术语的覆盖、词表大小的权衡、以及是否需要保留特殊token如[CLS]、[SEP]、工具调用标记等。实操心得在实际项目中我遇到过因为tokenizer对某些专业术语切分不合理导致模型在微调后仍然频繁出错的情况。后来通过扩充词表并重新训练embedding层解决了问题。这个经验在面试中讲出来比背概念有说服力得多。2.3 位置编码的演进说明了什么问题Transformer本身是置换不变的——如果不加位置编码把输入序列打乱输出结果不变。这显然不符合语言模型的需求所以位置编码是必须的。从最原始的正弦位置编码到可学习的位置嵌入再到RoPE旋转位置编码和ALiBi这个演进过程反映了什么问题正弦位置编码是固定的不需要训练但外推能力差——训练时见过512长度推理时给1024长度效果会急剧下降。可学习的位置嵌入灵活一些但同样受限于训练时的最大长度。RoPE的核心思想是通过旋转矩阵将位置信息编码到注意力计算中使得注意力分数天然包含相对位置信息。它的优势在于相对位置编码的形式让模型更容易学到“距离近的token关系更紧密”这个归纳偏置同时通过旋转角度的设计理论上可以支持一定的长度外推。ALiBi则更简单粗暴直接在注意力分数上加一个与距离成正比的惩罚项距离越远惩罚越大。它的外推能力很好但表达能力可能不如RoPE。面试官问这个问题其实是在考察你是否理解位置编码对长文本处理能力的影响。现在很多模型宣称支持128K甚至更长的上下文背后往往涉及位置编码的插值、NTK-aware缩放等技术。如果你能把这些串起来讲面试官会眼前一亮。2.4 训练和推理阶段到底有什么本质区别这个问题看似基础但能答清楚的人不多。很多人只知道“训练要算梯度推理不用”但面试官想听的是更深层的差异。训练阶段是teacher forcing模式每个位置都能看到完整的目标序列通过attention mask控制可以并行计算所有位置的loss。显存占用主要包括模型参数、梯度、优化器状态Adam的话是参数的2倍、激活值。激活值往往是大头因为每一层的中间输出都需要保存用于反向传播。推理阶段是自回归生成每次只能生成一个token然后把它拼接到输入中再生成下一个。这里的关键优化技术包括KV Cache缓存之前所有token的Key和Value矩阵避免重复计算。这是推理加速最核心的手段但会占用大量显存。量化把FP16降到INT8或INT4减少显存占用和计算量。投机采样用一个小模型快速生成多个候选token再用大模型验证提升生成速度。Continuous Batching动态合并多个请求提高GPU利用率。面试中如果问到“为什么推理比训练慢”你需要指出训练虽然计算量大但可以并行推理是串行的而且受限于内存带宽——每生成一个token都要把整个模型参数读一遍。这就是为什么大模型推理对显存带宽如此敏感。2.5 Function Calling的实现原理是什么Function Calling是LLM应用开发中最实用的能力之一但很多人只会调API不知道背后发生了什么。本质上Function Calling是通过Prompt Engineering和结构化输出实现的。模型在训练时会被注入大量包含工具调用格式的数据学会在特定情况下输出结构化的JSON包含函数名和参数。推理时系统把可用的工具描述名称、参数schema、功能说明作为system prompt的一部分传给模型模型根据用户输入决定是否调用工具、调用哪个工具、传什么参数。关键细节工具描述的质量直接影响调用准确率。参数命名要清晰描述要具体枚举值要完整。模型可能产生幻觉调用——调用不存在的函数或传入非法参数。工程上需要做严格的校验和兜底。多轮工具调用的编排逻辑很复杂。模型可能需要先调用A获取信息再根据结果决定是否调用B。这需要应用层维护状态机。面试中常见的追问是“如果模型一直不调用工具怎么办”解决方案包括在prompt中强化工具调用的指令、提供few-shot示例、设置强制调用模式tool_choice参数、以及在应用层做意图识别兜底。注意Function Calling的可靠性在生产环境中是很大的挑战。我见过太多demo很惊艳但上线后调用失败率超过30%的案例。核心问题往往出在工具描述不够精确和缺少异常处理机制上。2.6 大模型的幻觉问题能彻底解决吗幻觉是LLM的“阿喀琉斯之踵”面试官问这个问题不是要你给出一个完美方案而是看你对问题本质的理解。幻觉的根源在于LLM本质上是基于概率的文本生成器它的目标是生成“看起来合理”的文本而不是“真实”的文本。当模型的知识边界模糊时它会倾向于编造一个流畅但错误的答案而不是说“我不知道”。缓解幻觉的手段有很多但各有局限RAG检索增强生成把外部知识检索出来塞进上下文让模型基于事实生成。但如果检索质量差反而会引入新的错误。RLHF通过人类反馈训练模型更倾向于说“不知道”。但这会降低模型的回答覆盖率而且标注成本极高。约束解码限制输出必须来自某个知识库或符合特定格式。适用于特定场景但通用性差。自我一致性检查让模型多次生成并交叉验证。成本高且对系统性错误无效。面试中如果能指出“幻觉不可能彻底解决只能通过工程手段把风险降到可接受范围”并给出具体的缓解策略组合会比单纯罗列方法更有深度。2.7 如何评估一个大模型的好坏评估是LLM领域最混乱也最重要的话题之一。面试官问这个问题是在考察你的工程判断力。评估分为几个层次通用能力评估MMLU、BBH、GSM8K等基准测试。但这些基准存在数据泄漏和过拟合问题分数高不代表实际好用。领域特定评估根据业务场景设计测试集。比如客服场景看意图识别准确率代码场景看编译通过率。人类评估最可靠但最贵。通常采用A/B测试或成对比较。LLM-as-Judge用强模型评估弱模型的输出。成本低但存在偏见比如倾向于给更长的回答打高分。实际项目中我通常采用分层评估策略先用自动化基准做粗筛再用领域测试集做精评最后用小规模人类评估做终审。关键是评估集要持续更新避免模型“刷分”。面试中如果问到“BLEU和ROUGE还能用吗”你需要指出这些基于n-gram重叠的指标在生成式任务中相关性很差现在更多用于快速对比或作为辅助指标不能作为唯一标准。2.8 如果让你从零搭建一个LLM应用你会怎么做这是综合性最强的问题考察的是系统设计能力。我的思路通常分四层模型层选开源还是闭源开源可控但需要自己部署和优化闭源省事但有API成本和数据隐私问题。根据业务场景做权衡。数据层数据从哪里来怎么清洗怎么构造训练/评估集RAG的话向量库怎么选Embedding模型用哪个应用层Prompt怎么设计Function Calling怎么编排多轮对话状态怎么管理异常怎么处理评估与监控层上线后怎么持续评估怎么收集bad case怎么做A/B测试每一层都有大量的技术选型和工程细节。面试官不指望你面面俱到但希望看到你有结构化思考的能力而不是上来就说“用LangChain搭一下”。3. 面试官真正在考察什么3.1 知识深度比广度更重要LLM领域发展太快没有人能掌握所有细节。面试官更看重的是你在某个方向上的深度。比如你做过RAG那检索策略、chunk大小选择、rerank模型选型这些细节能不能讲清楚你做过微调那数据配比、学习率调度、灾难性遗忘怎么处理3.2 工程思维比理论推导更实用学术界的面试可能要求你推导注意力公式但工业界更关心你能不能把模型跑起来、跑得稳、跑得便宜。显存优化、推理加速、成本控制这些工程能力往往是决定offer的关键。3.3 踩坑经验比标准答案更值钱面试中如果候选人能讲出“我遇到过XX问题排查后发现是XX原因最后用XX方案解决了”这比背诵任何标准答案都有说服力。因为这说明你真的动过手而不是只看过论文。4. 常见问题与排查技巧实录4.1 面试中答不上来怎么办不要慌也不要瞎编。可以这样回应“这个点我了解得不够深入但根据我的理解可能是XX方向我会从XX角度去分析。”展示你的思考过程比直接说“不知道”好得多。4.2 如何准备项目经验部分面试官问项目时重点不是你做了什么而是为什么这么做。提前把项目中的关键技术决策梳理清楚为什么选这个方案有没有对比过其他方案遇到了什么困难怎么解决的效果如何量化4.3 八股文要背吗基础概念必须熟练但不能只背答案。面试官稍微换个角度问背答案的人就露馅了。正确的做法是理解原理然后用自己的话讲出来。4.4 面试中的高频陷阱问题陷阱问题考察点应对思路“你觉得XX模型怎么样”是否有独立判断结合具体场景分析优缺点不要泛泛而谈“如果效果不好怎么办”排查思路从数据、模型、超参、评估四个维度系统排查“你最大的缺点是什么”自我认知说一个真实的、正在改进的缺点“为什么选择我们公司”动机和匹配度结合业务方向和技术栈具体说明5. 我个人的复习建议如果你正在准备LLM面试我的建议是不要只刷题要动手。把Transformer的代码手写一遍把一个小模型微调跑通把RAG流程搭起来。这些实操经验会让你在面试中有讲不完的细节。另外保持对新技术的好奇心。LLM领域每个月都有新东西出来面试官很可能问到最新的技术进展。不需要每个都深入研究但至少要知道大概是什么、解决什么问题。最后面试是双向选择。面试官在考察你你也在考察团队的技术氛围和业务方向。遇到只会背八股文的面试官其实你也能判断出这个团队的技术水平。实操心得我见过很多候选人理论知识很扎实但一问到“你实际跑过什么模型”就卡壳了。在LLM这个领域动手能力比什么都重要。哪怕你只是用LoRA微调过一个7B模型只要能讲清楚数据构造、训练配置、评估方法就比背一百道八股文强。