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的prompt，GPT-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这些指标在生成任务上早就被证明和人类判断相关性很低了，但很多候选人还在用。
我现在的做法是分场景选指标。如果是检索任务，看Recall@K和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系统，你在这个过程中踩到的坑、学到的经验，比任何八股文都有价值。面试官能分辨出谁是真正做过的人，就像老中医能把脉出谁是真的练过功夫一样。
