1. 为什么这8个问题能决定面试生死面过几十个LLM方向的候选人之后我越来越确信一件事面试官问的那些问题表面上考的是知识点实际上考的是你有没有真正动手做过东西。背八股文的人能把Transformer的公式默写出来但你问他“为什么Q和K要做缩放”他大概率会愣住。而真正做过项目的人可能公式记不全但他能告诉你“不缩放的话softmax会饱和梯度直接没了我训的时候loss卡在2.3不动排查了一天才发现是这里的问题”。这就是区别。LLM面试和传统NLP面试最大的不同在于这个领域变化太快很多知识还没有沉淀成教科书上的标准答案。面试官自己可能也是边做边学所以他问的问题往往不是“请解释注意力机制”这种可以照本宣科的而是“你遇到过什么坑”“你怎么选的方案”“如果让你重新做你会怎么改”。这些问题没有标准答案但有一个东西是藏不住的——你到底有没有真正训过模型、调过参数、排过bug。我整理了一下近几年高频出现的面试题挑出8个最能区分“真做过”和“只背过”的问题。每个问题我都会拆成三层面试官到底想听什么、你应该怎么回答、以及常见的送命回答长什么样。不管你是准备跳槽还是在带团队招人这篇内容应该都能帮到你。注意下面涉及的所有技术细节我都尽量用“实际项目中会遇到什么”的角度来讲而不是教科书式的定义。如果你发现某个点和你背的材料不一样以实际操作为准。2. 问题一Transformer里的缩放因子到底在防什么2.1 面试官真正想听的不是公式“为什么注意力机制里要除以根号d_k”这个问题几乎每场面试都会出现。大部分候选人会回答“为了防止内积过大导致softmax梯度消失”这个答案对但只对了一半。面试官如果接着问“那为什么是根号d_k而不是d_k”能答上来的人就少了一大半。我自己的理解是这样的假设Q和K的每个维度都是独立的、均值0方差1的随机变量那么它们的内积q·k的方差就是d_k。也就是说维度越高内积的波动范围越大。除以根号d_k之后方差被拉回到1附近softmax的输入就不会因为维度高而变得极端。但这里有个容易被忽略的点这个推导假设了Q和K的分布是标准正态。实际训练中Q和K的分布会随着训练过程变化所以缩放因子严格来说只是一个“合理的初始化策略”而不是一个永远最优的固定值。有些工作比如Google的T5就试过不用缩放因子在某些设置下也能训起来但收敛更慢、更不稳定。2.2 一个真实的排查案例我之前训一个12层的模型loss在前500步一直卡在2.3左右不降。排查了一圈最后发现是初始化的时候把Q和K的方差设大了导致softmax输出接近one-hot梯度几乎为零。把初始化改回标准正态之后loss在200步内就降到了1.8。这个经历让我在面试里特别关注候选人有没有类似的“手感”。如果你只是背了“除以根号d_k防止梯度消失”但没遇到过因为这个问题导致的训练失败那你的理解就还停留在纸面上。2.3 怎么回答才能加分我的建议是分三层回答第一层说结论防止softmax饱和导致梯度消失第二层说推导内积方差随维度增长缩放后方差归一第三层说边界这是基于标准正态假设的实际中需要根据初始化策略调整。能说到第三层的人面试官基本就能判断你是真训过模型的。3. 问题二Tokenization看着简单坑在哪3.1 BPE不是万能的“你了解哪些Tokenization方法”这个问题看起来是送分题但面试官真正想考的是你有没有被Tokenizer坑过。BPE、WordPiece、Unigram这些算法本身不难理解难的是在实际项目里怎么选、怎么调。我做过一个中文为主的场景一开始直接用了GPT-2的Tokenizer结果发现中文一个字被拆成两三个token序列长度直接翻倍训练成本上去了不说模型对中文的理解也明显变差。后来换成了针对中文优化的Tokenizer同样的语料序列长度降了40%效果还提升了。这里的关键是Tokenizer的选择直接决定了你的模型“看到”的世界是什么样的。英文里“unhappiness”被拆成“un”“happi”“ness”可能没问题但中文里“葡萄”被拆成“葡”“萄”就丢失了语义。所以做中文场景一定要检查Tokenizer的切分结果不能拿来就用。3.2 词表大小的权衡词表大小是另一个容易被忽视的点。词表太小序列变长计算量增加词表太大embedding矩阵参数量暴涨小数据集上容易过拟合。我的经验是英文场景32k到50k比较常见中文场景可以到80k到100k多语言场景可能需要128k以上。但这不是绝对的。如果你的数据量很小比如只有几百万token词表设太大反而有害。我见过一个团队用128k的词表训一个只有500万token的数据集结果embedding层严重过拟合下游任务效果还不如32k词表的模型。3.3 面试中的加分回答如果你能在回答里提到“我会先统计语料的字符分布然后根据覆盖率来确定词表大小”或者“我会检查Tokenizer对领域术语的切分是否合理”面试官会觉得你是真正处理过数据的。相反如果只说“BPE是自底向上合并高频字符对”那就太教科书了。4. 问题三Embedding模型怎么选才不踩雷4.1 排行榜不等于你的场景“你用过哪些Embedding模型”这个问题背后面试官想知道的是你有没有在真实业务里做过选型。现在Embedding模型排行榜很多MTEB上每天都有新模型刷榜但排行榜高不代表适合你的场景。我踩过的一个坑在一个法律文书检索的场景里直接用了一个排行榜很高的通用Embedding模型结果发现它对法律术语的区分度很差“原告”和“被告”的向量余弦相似度居然有0.92。后来换了一个在法律领域数据上微调过的模型相似度降到了0.65检索准确率直接翻了一倍。所以选Embedding模型的第一步不是看排行榜而是看你的场景和训练数据分布。通用模型在通用场景下表现好但垂直领域一定要做领域适配。4.2 维度不是越高越好另一个常见误区是认为Embedding维度越高越好。实际上高维度带来的收益在超过某个阈值后就非常有限了但存储和计算成本是线性增长的。我做过一个对比测试在检索任务上768维和1024维的模型效果差距不到2%但1024维的索引体积大了33%检索延迟也明显增加。如果你的场景对延迟敏感或者需要处理千万级别的文档Embedding维度就是一个必须仔细权衡的参数。我的建议是先用一个中等维度的模型比如384或512跑baseline如果效果不够再考虑升维。4.3 怎么在面试里体现深度回答这个问题的时候不要只列模型名字。你可以说“我会先在一个小规模验证集上对比几个候选模型重点看它们在困难样本上的表现而不是只看平均指标”。这句话就能让面试官知道你是真正做过选型的人。5. 问题四Function Calling的边界在哪里5.1 它不是万能胶Function Calling是这两年LLM应用开发里最热的概念之一但很多候选人对它的理解停留在“让模型调用外部工具”这个层面。面试官如果问“Function Calling有什么局限性”能答好的人不多。我实际用下来的感受是Function Calling的可靠性高度依赖于模型的指令遵循能力。小模型或者没经过专门微调的模型经常会出现参数格式错误、调用不存在的函数、或者该调用的时候不调用。我做过一个测试同一个Function Calling的promptGPT-4的调用准确率能到95%以上但一个7B的开源模型只有60%左右。所以如果你的场景对可靠性要求很高要么用大模型要么在Function Calling外面加一层校验和重试逻辑。我通常会在解析模型输出的时候做严格的schema校验如果格式不对就重新生成最多重试三次。5.2 多函数调用的顺序问题另一个容易被忽视的点是当有多个函数可以调用时模型怎么决定调用顺序我遇到过一个场景用户问“帮我查一下明天北京的天气然后推荐一个适合的户外活动”。模型先调用了天气查询拿到结果后又调用了活动推荐这个顺序是对的。但有时候模型会先调活动推荐再调天气查询导致推荐的活动和天气不匹配。解决这个问题的方法是在prompt里明确说明依赖关系或者在函数定义里加上前置条件。但更根本的是你需要一个编排层来管理函数调用的顺序和依赖不能完全依赖模型自己判断。5.3 面试里怎么答出差异化如果你能在回答里提到“我会给每个函数定义清晰的输入输出schema并且在prompt里说明调用顺序的约束”或者“我会在函数调用失败时设计降级策略”面试官会觉得你不仅用过Function Calling还真正处理过它的边界情况。6. 问题五微调还是RAG怎么选6.1 这不是一个二选一的问题“什么时候该微调什么时候该用RAG”这个问题在面试里出现的频率极高。很多候选人的回答是“知识更新用RAG风格调整用微调”这个答案没错但太粗糙了。我实际做项目的时候决策逻辑要细得多。首先看数据如果你的领域数据是私有的、频繁更新的RAG更合适如果你的任务是固定的、输入输出格式很明确的微调更合适。其次看成本RAG需要维护向量数据库和检索管道微调需要标注数据和训练资源。最后看延迟RAG多了一次检索微调后的模型直接推理延迟更低。但现实中很多场景是两者结合。比如我做过一个客服场景先用RAG检索知识库然后用一个微调过的小模型来生成回答。这样既保证了知识的新鲜度又保证了回答风格的统一。6.2 微调的数据量门槛很多人以为微调需要大量数据其实不是。对于指令遵循类的任务几千条高质量的数据就能看到明显效果。我做过一个实验用5000条数据微调一个7B模型在特定任务上的表现超过了GPT-3.5的zero-shot。但关键是数据质量不是数量。1000条精心标注的数据效果可能比10000条噪声数据好得多。6.3 面试中的决策框架我建议在面试里用一个简单的决策树来回答先问“知识是否需要频繁更新”是则RAG再问“输出格式是否高度固定”是则微调最后问“延迟和成本约束是什么”根据约束做取舍。能把这个逻辑讲清楚比背任何结论都有说服力。7. 问题六Agent的容错控制怎么做7.1 Agent不是一条直线Agent相关的面试题这两年明显增多尤其是“你怎么保证Agent的可靠性”这个问题。很多候选人的回答是“加一个反思步骤”但反思本身也可能出错而且会增加延迟和成本。我在实际项目里的做法是分层容错。第一层是输入校验确保Agent接收到的任务描述是完整的、可执行的。第二层是执行监控每一步操作后检查结果是否符合预期如果不符合就回滚或者重试。第三层是输出校验最终结果要经过一个独立的验证模块确保没有幻觉或者格式错误。这个思路借鉴了传统软件工程里的防御性编程但在Agent场景下需要针对LLM的特点做调整。比如LLM的输出是自然语言校验就不能用简单的类型检查而需要用另一个LLM或者规则引擎来判断。7.2 记忆污染怎么防Agent的长期记忆是一个双刃剑。好的记忆能让Agent记住用户的偏好和历史交互但错误的记忆会导致Agent在后续对话中持续犯错。我遇到过一种情况Agent在一次对话中错误地记录了用户的地址之后每次推荐餐厅都基于这个错误地址用户纠正了好几次都没用。解决这个问题的方法是在写入记忆之前做一次确认或者在记忆里加上置信度和时间戳低置信度的记忆在使用前需要重新验证。另外记忆的更新策略也很重要不能只增不删要有一个过期机制。7.3 面试里怎么体现工程思维如果你能在回答里提到“我会给Agent的每一步操作设计可观测性指标比如调用成功率、平均重试次数、异常类型分布”面试官会觉得你不仅懂算法还懂工程。这在Agent岗位的面试里是很大的加分项。8. 问题七怎么评估一个LLM应用的好坏8.1 自动指标不够用“你怎么评估模型效果”这个问题看起来简单但能答好的人很少。BLEU、ROUGE这些指标在生成任务上早就被证明和人类判断相关性很低了但很多候选人还在用。我现在的做法是分场景选指标。如果是检索任务看RecallK和MRR如果是分类任务看F1和AUC如果是生成任务用LLM-as-a-judge做 pairwise 比较再人工抽检一部分。关键是不要只看一个指标要有一个指标组合。8.2 人工评估怎么做才靠谱人工评估最大的问题是主观性和不一致性。同一个回答不同标注员的评分可能差很多。我的经验是第一给标注员提供详细的评分标准最好有正例和反例第二让多个标注员评同一批数据计算一致性第三定期校准确保标注标准没有漂移。另外人工评估的成本很高所以要用在刀刃上。我通常会用自动指标做粗筛然后对差异大的样本做人工评估这样能用有限的预算拿到最有价值的信息。8.3 面试中的评估框架回答这个问题的时候我建议先问清楚场景然后给出一个分层的评估方案离线指标、在线A/B、人工评估。能说出“离线指标好不代表线上效果好因为线上有分布偏移和用户行为的变化”面试官就会知道你是有实战经验的。9. 问题八你踩过最大的坑是什么9.1 这个问题没有标准答案“你踩过最大的坑是什么”这是我最喜欢问的问题因为它能看出一个人是不是真正做过项目。背八股文的人会编一个听起来很专业的坑但细节经不起追问。真正做过项目的人讲起自己踩过的坑来会眉飞色舞连当时怎么排查的、试了哪些方案、最后怎么解决的都能说得清清楚楚。我自己印象最深的一个坑是在一个RAG项目里检索模块的召回率一直上不去排查了很久才发现是文档切分的问题。我们一开始按固定长度切分结果很多关键信息被切断了。后来改成按语义切分召回率直接提升了20个百分点。9.2 怎么讲好一个坑讲坑的时候重点不是坑本身有多难而是你的排查思路和解决方法。我通常会按这个结构来讲现象是什么、我一开始怎么想的、试了哪些方案、最后发现根因是什么、怎么解决的、之后怎么预防类似问题。这个结构能让面试官看到你的思考过程而不仅仅是结果。9.3 不要编坑最后说一个很重要的点不要编。面试官如果追问细节编的坑很容易露馅。而且真正做过项目的人坑是讲不完的根本不需要编。如果你觉得自己没有坑可讲那可能说明你还没有真正深入做过一个项目。10. 面试之外的一点个人体会带了几年团队之后我发现一个规律那些在面试里能把这些开放性问题答好的人往往不是最聪明的而是最有耐心的。他们愿意花时间去排查一个loss不降的原因愿意为了0.5%的效果提升去尝试不同的Tokenizer愿意在评估上花比训练更多的时间。LLM这个领域现在很热但热意味着浮躁。很多人急着发论文、刷榜、跳槽却不愿意沉下心来做一些“脏活累活”。但恰恰是这些脏活累活决定了你的模型能不能真正上线、能不能真正解决问题。如果你正在准备面试我的建议是不要只背答案去找一个真实的问题从头到尾做一遍。哪怕只是微调一个小模型、搭一个简单的RAG系统你在这个过程中踩到的坑、学到的经验比任何八股文都有价值。面试官能分辨出谁是真正做过的人就像老中医能把脉出谁是真的练过功夫一样。
