1. 为什么这8个问题成了LLM面试的硬门槛
面过十几场大模型岗位之后，我发现一个很明显的规律：面试官在前二十分钟基本不会问太偏的东西，翻来覆去就是那么几个核心问题。但恰恰是这几个看起来“基础”的问题，淘汰率最高。我见过不少简历上写着“熟悉Transformer”“有LLM微调经验”的候选人，一问到具体机制就卡壳，场面相当尴尬。
这篇文章想做的事情很直接：把这8个高频问题拆开揉碎，不光告诉你“标准答案”长什么样，更要讲清楚面试官问这个问题到底想考察什么、你应该往哪个方向答、哪些坑千万别踩。适合正在准备大模型方向面试的算法工程师、AI产品经理，也适合刚入门想系统梳理知识体系的朋友。哪怕你暂时不面试，把这8个问题吃透，对理解LLM的整体运作机制也有很大帮助。
需要提前说明的是，不同公司、不同岗位对这几个问题的侧重点不一样。做推理优化的团队更关注KV Cache和量化，做Agent的团队会深挖Function Calling的边界条件，做预训练的团队则会把Tokenization和注意力机制问到底。所以我在每个问题后面都会标注“面试官真正想听的加分项”，你可以根据目标岗位灵活调整准备重点。
2. 八个必问问题逐个拆解
2.1 问题一：Transformer的自注意力机制到底在算什么
这个问题几乎是所有LLM面试的开场白。面试官问这个不是想听你背“QKV三个矩阵相乘”，而是想确认你对信息流动的理解是否到位。
自注意力的核心操作可以拆成三步。第一步，把输入序列的每个token映射成三个向量：Query、Key、Value。你可以把它想象成一个检索系统——Query是你要查的关键词，Key是每本书的索引标签，Value是书里的实际内容。第二步，用Query和所有Key做点积，得到一组注意力分数，分数越高说明这个位置越应该关注那个位置的信息。第三步，对分数做softmax归一化，然后加权求和所有的Value，得到每个位置的输出表示。
这里有个细节很多人会忽略：为什么要除以根号d_k？d_k是Key向量的维度。当维度很大时，点积的结果会变得很大，softmax之后会趋近于one-hot分布，梯度几乎消失。除以根号d_k相当于把方差拉回到1附近，保证梯度稳定。这个操作叫“缩放点积注意力”，面试时能主动提到这一点，说明你不是只看了几篇科普文。
多头注意力则是把上面的过程并行做多次，每次用不同的投影矩阵，最后拼接起来再做一次线性变换。为什么要多头？单个注意力头只能学到一种关注模式，多头可以让模型同时关注语法关系、语义关联、位置邻近性等不同维度的信息。就像你读一句话时，大脑同时在处理词性、句法结构、上下文指代等多个层面的信息。
面试官真正想听的加分项：能说清楚QKV的物理含义，能解释缩放因子的作用，能说明多头注意力的设计动机。如果还能提到注意力矩阵的稀疏化趋势（比如Longformer、BigBird的思路），基本就稳了。
2.2 问题二：Tokenization为什么不能简单地按空格切
Tokenization是很多人觉得“太基础”而忽略的环节，但面试官恰恰喜欢从这里切入，因为它的设计直接影响模型的能力边界。
最直觉的做法是按空格或字符切分，但这样做有几个致命问题。按空格切，中文、日文等没有空格的语言就没法处理；按字符切，序列会变得非常长，计算量爆炸，而且单个字符携带的语义信息太少。所以现代LLM普遍采用子词切分算法，典型代表是BPE和SentencePiece。
BPE的核心思路是：从字符级别开始，统计相邻字符对的出现频率，把最高频的字符对合并成一个新的子词，重复这个过程直到词表达到预设大小。这样做的好处是，常见词会被完整保留为一个token，罕见词会被拆成多个子词，既控制了词表规模，又避免了OOV问题。比如“unhappiness”可能被切成“un”“happi”“ness”三个token。
SentencePiece和BPE的区别在于，它直接把输入当作字节流处理，不依赖预分词，对多语言场景更友好。LLaMA系列用的就是SentencePiece的BPE变体。
这里有个实际工程中很容易踩的坑：词表大小和序列长度的权衡。词表越大，每个token携带的信息越多，序列越短，推理越快，但嵌入矩阵和输出层的参数量也会增加。词表太小，序列变长，注意力计算量是O(n²)增长，推理成本急剧上升。所以你会看到不同模型的词表大小差异很大，GPT-2是50257，LLaMA是32000，有些中文优化模型会扩到100000以上。
面试官真正想听的加分项：能对比BPE、WordPiece、Unigram等不同算法的优劣，能解释词表大小对推理成本和模型效果的影响，最好能结合具体模型举例。
2.3 问题三：位置编码为什么需要，绝对位置和相对位置有什么区别
Transformer的自注意力本身是置换不变的——把输入序列打乱顺序，注意力计算的结果不变。但语言是有顺序的，“猫追老鼠”和“老鼠追猫”意思完全相反。所以必须显式地注入位置信息。
最早的做法是正弦位置编码，用不同频率的sin和cos函数生成位置向量，直接加到token的嵌入上。这种编码的优点是理论上可以外推到训练时没见过的长度，但实际效果一般，因为模型很难从这种编码中学会精确的相对位置关系。
后来出现了可学习的位置编码，把每个位置的向量当作参数训练。GPT系列早期用的就是这种。问题是训练长度之外的位置没有对应的参数，外推能力差。
现在主流方案是相对位置编码，典型代表是RoPE和ALiBi。RoPE的思路很巧妙：它不直接加位置向量，而是对Query和Key向量做旋转操作，旋转角度和位置成正比。这样两个位置之间的注意力分数只依赖于它们的相对距离，天然具备更好的外推性。ALiBi更简单，直接在注意力分数上加一个和距离成正比的惩罚项，距离越远惩罚越大。
实际面试中，如果你能说清楚“RoPE为什么比正弦编码外推性好”，基本就能和其他候选人拉开差距。核心原因是RoPE把位置信息编码进了注意力计算的旋转矩阵中，相对位置关系在点积过程中自然体现，而不是像正弦编码那样把位置信息混入嵌入向量后再做点积。
面试官真正想听的加分项：能推导RoPE的旋转矩阵形式，能解释ALiBi的惩罚项设计，能讨论长度外推的实际工程方案（比如NTK-aware插值、YaRN）。
2.4 问题四：KV Cache是什么，为什么能加速推理
这个问题是区分“只会训练”和“懂推理部署”的分水岭。很多候选人训练模型很熟，但一问到推理优化就露怯。
自回归生成的特点是逐个token输出，每生成一个新token，都需要和前面所有token做注意力计算。如果不做任何优化，每生成一个token都要重新计算前面所有token的Key和Value，计算量随序列长度线性增长，总计算量是O(n²)。
KV Cache的思路很直接：把前面已经计算过的Key和Value缓存起来，生成新token时只需要计算当前token的Query，然后和缓存的Key做注意力，再和缓存的Value加权求和。这样每步的计算量从O(n)降到O(1)，总计算量从O(n²)降到O(n)。
但KV Cache不是没有代价的。它占用的显存和序列长度、层数、注意力头数、头维度成正比。以LLaMA-7B为例，假设序列长度4096，32层，32个头，头维度128，那么KV Cache的大小大约是2×32×32×4096×128×2字节，算下来超过2GB。这还只是单条序列，如果做批量推理，显存压力会成倍增加。
所以实际部署中会用到各种KV Cache优化技术。MQA让所有注意力头共享同一组Key和Value，GQA把注意力头分组，每组共享一组KV。这两种方案都能大幅降低KV Cache的显存占用，代价是轻微的效果损失。现在很多新模型默认用GQA，就是在效果和效率之间找平衡。
面试官真正想听的加分项：能估算KV Cache的显存占用，能对比MHA、MQA、GQA的优劣，能提到PagedAttention这类显存管理方案。
2.5 问题五：Function Calling的底层是怎么实现的
Function Calling是Agent方向面试的必问题。很多人以为这是模型“天生”就会的能力，其实背后是一套精心设计的提示工程加微调流程。
基本流程是这样的：你在调用API时，除了传入用户消息，还要传入一个工具列表，每个工具包含名称、描述和参数schema。模型在生成回复时，如果判断需要调用工具，就会输出一个结构化的JSON，包含工具名和参数。你的程序解析这个JSON，执行对应的函数，把结果再传回给模型，模型基于结果生成最终回复。
关键点在于，模型并不是真的“理解”了工具的功能，而是通过训练学会了“看到这类描述和这类用户请求，应该输出这种格式的JSON”。所以工具描述的质量直接影响调用准确率。描述要清晰、参数要明确、边界情况要说明。我见过太多人工具描述写得含糊不清，然后抱怨模型调用不准，其实问题出在描述上。
另一个容易踩的坑是并行调用。有些场景下模型需要同时调用多个工具，比如“帮我查一下北京和上海的天气”，模型应该输出两个工具调用请求。这要求你的解析逻辑能处理数组形式的输出，而不是只处理单个对象。
还有错误处理。工具执行可能失败，模型需要根据错误信息决定是重试、换工具还是直接告诉用户失败。这需要在提示中明确告诉模型“如果工具返回错误，你应该怎么做”。
面试官真正想听的加分项：能说清楚工具描述的设计原则，能处理并行调用和错误恢复，能讨论如何评估Function Calling的准确率。
2.6 问题六：微调和RAG分别适合什么场景
这个问题考察的是你对技术选型的判断力，不是单纯的知识点。面试官想看你有没有实际做过方案决策。
微调的本质是调整模型参数，让模型学会新的行为模式或领域知识。适合的场景包括：固定格式的输出（比如总是输出特定结构的JSON）、特定风格的回复（比如客服话术）、领域术语的理解（比如医疗、法律）。微调的优点是推理时不需要额外检索，延迟低；缺点是更新成本高，知识更新需要重新训练，而且容易灾难性遗忘。
RAG的本质是在推理时动态检索外部知识，拼接到提示中让模型参考。适合的场景包括：知识频繁更新的场景（比如新闻问答）、需要引用来源的场景、长尾知识覆盖。RAG的优点是知识更新只需更新检索库，成本低；缺点是检索质量直接影响效果，而且增加了推理延迟。
实际项目中，两者经常结合使用。比如先用微调让模型学会领域术语和输出格式，再用RAG补充实时知识。决策的关键因素是：知识更新频率、对延迟的敏感度、标注数据的数量和质量、以及团队的技术栈。
面试官真正想听的加分项：能给出具体的决策框架，能估算微调和RAG的成本差异，能讨论混合方案的工程实现。
2.7 问题七：如何评估一个LLM的输出质量
评估是LLM落地中最难也最容易被忽视的环节。面试官问这个问题，是想看你有没有从“跑通demo”进化到“保证线上质量”。
自动评估指标方面，BLEU和ROUGE适合有标准答案的任务，比如翻译和摘要，但它们和人类判断的相关性有限。Perplexity适合评估语言模型的流畅度，但和下游任务效果不是线性关系。现在更常用的是用强模型做裁判，比如用GPT-4给候选输出打分，但要注意裁判模型本身的偏差。
人工评估方面，需要设计清晰的评分标准，比如相关性、准确性、流畅度、安全性等维度，每个维度给出具体的评分锚点。标注员之间的一致性要用Kappa系数衡量，太低说明标准不够清晰。
线上评估方面，A/B测试是金标准，但需要足够的流量和明确的业务指标。对于对话系统，用户满意度、会话轮数、任务完成率都是重要信号。对于生成任务，点击率、转化率、人工抽检通过率都需要监控。
实际工程中，我通常会搭建一个三层评估体系：离线用自动指标快速筛选，人工评估做质量把关，线上A/B测试做最终决策。每一层都有明确的通过标准，不达标就不进入下一层。
面试官真正想听的加分项：能设计完整的评估pipeline，能讨论评估成本和效果的权衡，能提到LLM-as-Judge的偏差和缓解方法。
2.8 问题八：LLM的幻觉问题怎么缓解
幻觉是LLM落地绕不开的坎。面试官问这个问题，不是要你给出“完美解决方案”，而是看你有没有系统性的思考。
幻觉的根源可以从三个层面理解。数据层面，训练数据中存在错误信息和矛盾信息，模型学到了这些噪声。模型层面，自回归生成的目标是最大化似然，不是保证事实正确性，模型倾向于生成“看起来合理”的内容。推理层面，采样策略（比如temperature）引入的随机性会增加幻觉概率。
缓解手段也对应三个层面。数据层面，清洗训练数据，过滤低质量来源，增加事实性数据的权重。模型层面，用RLHF让模型学会“不知道就说不知道”，或者用检索增强让模型基于给定文档回答。推理层面，降低temperature，用束搜索代替采样，或者用self-consistency让模型多次生成后投票。
实际落地中，RAG是最常用的方案，因为它能直接把事实依据提供给模型。但RAG本身也有幻觉风险——如果检索到的文档本身有误，模型会忠实地复制错误。所以检索质量监控和来源可信度评估同样重要。
面试官真正想听的加分项：能区分不同类型幻觉（事实性、忠实性、逻辑性），能设计多层防御体系，能讨论幻觉检测的自动化方案。
3. 面试官视角：他们到底在考察什么
3.1 知识深度 vs 工程判断力
这8个问题看似在考知识点，实际上每一题都在同时考察两个维度：你对原理的理解深度，以及你在实际工程中的判断力。
以KV Cache为例，能背出定义只是及格线。面试官更想听到的是：你在什么场景下会选择MQA而不是GQA？PagedAttention解决了什么具体问题？显存不够时你的降级方案是什么？这些问题没有标准答案，但能看出你有没有真正部署过模型。
再比如Function Calling，能说出基本流程只是入门。面试官会追问：工具描述写多详细才够？模型调用错了你怎么排查？并行调用的结果怎么合并？这些细节只有在实际项目中踩过坑的人才能答得上来。
所以准备面试时，不要只背知识点，要多问自己“如果我来做这个决策，我会怎么选，为什么”。把每个问题都当成一个实际工程问题来思考，答案自然就有深度了。
3.2 不同岗位的考察侧重点
算法工程师岗位：重点在Transformer细节、注意力机制变体、位置编码、微调方法。会要求手写注意力代码，或者推导RoPE的旋转矩阵。对数学功底要求较高。
推理优化岗位：重点在KV Cache、量化、蒸馏、并行策略。会问显存估算、吞吐量优化、延迟降低的具体方案。对工程经验要求较高。
Agent方向岗位：重点在Function Calling、任务规划、多轮对话管理、工具编排。会问工具描述设计、错误恢复、多Agent协作。对系统设计能力要求较高。
AI产品经理岗位：重点在技术选型、评估体系、成本估算、场景判断。不会要求手写代码，但要求能和技术团队顺畅沟通，能做出合理的方案决策。
3.3 回答框架：从“是什么”到“怎么用”
我建议每个问题都按这个框架来组织回答：先用一句话说清楚“是什么”，然后用两三句话解释“为什么这样设计”，最后用具体例子说明“实际怎么用”。
比如回答位置编码，可以这样说：位置编码是为了给置换不变的注意力机制注入顺序信息（是什么）。正弦编码外推性差是因为位置信息混入了嵌入向量，RoPE通过旋转操作让相对位置在点积中自然体现（为什么）。在实际部署中，如果推理长度超过训练长度，我会用NTK-aware插值来扩展RoPE的基频（怎么用）。
这个框架的好处是逻辑清晰，面试官能快速抓住你的思路。而且“怎么用”部分往往能引出更多讨论，让你有机会展示工程经验。
4. 高频追问与避坑指南
4.1 那些容易翻车的追问
面试官问完基础问题后，通常会有一到两个追问，这些追问才是真正拉开差距的地方。我整理了几个高频追问和应对思路。
追问一：“你刚才说多头注意力能捕捉不同模式，那怎么验证每个头确实学到了不同的东西？”这个问题考察的是你对可解释性研究的了解。可以提到注意力可视化、头剪枝实验、以及“有些头确实冗余”的发现。
追问二：“BPE词表大小设为多少合适？”这个问题没有标准答案，但你可以给出决策框架：看语言分布（中文多就需要更大词表）、看推理成本预算、看嵌入层参数量占比。然后给一个经验值，比如多语言场景64000到100000，英文为主32000到50000。
追问三：“KV Cache显存不够时你怎么办？”可以从几个角度答：用GQA或MQA降低KV头数、用量化压缩KV精度、用PagedAttention做显存分页、限制最大序列长度、做请求排队和批处理调度。
追问四：“RAG检索到的文档和模型知识冲突时怎么处理？”这是RAG落地中最棘手的问题。可以答：在提示中明确告诉模型“优先参考给定文档”，同时监控冲突率，如果冲突频繁说明检索质量有问题，需要优化检索策略或更新模型知识。
4.2 常见误区与纠正
误区一：把Transformer等同于LLM。Transformer只是架构，LLM还涉及预训练目标、微调方法、对齐技术等。面试时如果只谈Transformer，会显得知识面窄。
误区二：认为微调一定比RAG好。实际上大部分场景RAG的性价比更高，微调适合格式和风格调整，知识注入还是RAG更灵活。
误区三：忽视Tokenization的影响。很多人觉得这是预处理步骤不重要，但实际上词表设计直接影响模型的多语言能力、推理成本和输出质量。
误区四：把幻觉当成纯技术问题。幻觉也涉及产品设计——在什么场景下可以容忍幻觉，在什么场景下必须零容忍，这需要和业务方对齐。
4.3 面试前的准备清单
根据我的经验，面试前一周可以按这个清单来准备：
- 手写一遍缩放点积注意力和多头注意力的代码，确保能默写出来
- 推导一遍RoPE的旋转矩阵，理解为什么它能编码相对位置
- 估算一次KV Cache的显存占用，记住公式和典型数值
- 设计一个Function Calling的工具描述，想清楚每个字段的作用
- 准备一个RAG和微调选型的实际案例，能说清楚决策依据
- 整理一套评估方案，覆盖离线、人工、线上三个层面
- 想清楚幻觉缓解的多层策略，能结合实际场景讨论
5. 从面试题到实际工作的能力映射
5.1 这些知识在真实项目中怎么用
面试题不是孤立的，每一题都对应实际工作中的核心能力。
Transformer和注意力机制的理解，决定了你能不能读懂最新的论文，能不能根据业务需求调整模型结构。比如做长文本处理时，你需要判断是用稀疏注意力、线性注意力还是滑动窗口，这些决策都建立在扎实的原理理解上。
Tokenization的知识在 multilingual 场景中特别重要。如果你要做东南亚市场的产品，词表对泰语、越南语的支持程度直接影响效果。你需要知道怎么评估词表覆盖率，怎么扩展词表，怎么处理新词。
KV Cache和推理优化直接关系到成本。一个日活百万的对话产品，推理成本可能是最大的支出项。你能不能通过GQA、量化、批处理把成本降下来，直接决定产品的商业可行性。
Function Calling和RAG是Agent产品的核心。工具描述写得好不好，检索策略设计得合不合理，直接决定用户体验。这些能力不是靠背题能获得的，需要在项目中反复迭代。
评估体系是保证质量的关键。没有评估就没有优化方向。你需要能设计合理的指标，能搭建自动化的评估pipeline，能根据评估结果做决策。
5.2 持续学习的方向建议
LLM领域变化很快，面试题也在不断更新。但底层原理是相对稳定的，把基础打牢，新东西学起来就快。
建议重点关注几个方向：一是高效推理技术，包括量化、蒸馏、稀疏化、投机解码；二是Agent架构，包括任务规划、工具编排、多Agent协作；三是评估和对齐，包括RLHF、DPO、可解释性；四是多模态融合，包括视觉-语言模型、语音-语言模型。
学习方式上，我建议“论文+代码+实践”三管齐下。读论文理解思路，读代码理解实现，跑实验验证效果。只看论文不写代码，面试时容易被追问细节问倒；只写代码不读论文，容易缺乏方向感。
5.3 面试之外：构建自己的知识体系
面试只是手段，不是目的。真正重要的是构建一套自己的知识体系，能快速理解新技术，能做出合理的工程决策。
我的做法是维护一个“问题-方案-效果”的笔记库。每遇到一个问题，记录可能的解决方案，实际尝试后的效果，以及为什么某些方案有效或无效。时间长了，这个笔记库就成了自己的决策参考。
另外，多和同行交流也很重要。很多工程细节不会写在论文里，只在口口相传中流传。比如某个量化方案在特定硬件上的实际加速比，某个RAG策略在特定领域的召回率，这些信息往往比论文更有价值。
最后再分享一个小技巧：面试时如果遇到不会的问题，不要硬编。可以说“这个问题我没有实际经验，但根据我的理解，可能的思路是……”，然后展示你的推理过程。面试官往往更看重思考方式，而不是标准答案。诚实加上合理的推理，比胡编乱造要好得多。
