LLM面试8大硬门槛：从Transformer到幻觉，答不上来直接淘汰

1. 为什么这8个问题成了LLM面试的硬门槛面过几十个LLM方向的候选人之后我越来越确信一件事这个领域的面试已经过了“你会不会调API”的阶段。现在面试官抛出的问题几乎全部指向同一个核心——你到底有没有真正理解过大模型内部在发生什么。标题里说的“答不上来直接淘汰”听起来有点狠但站在面试官的角度想想一个连Tokenization和Embedding区别都说不清的人你怎么放心让他去调Prompt、做RAG、搭Agent这篇文章的由来是我最近帮团队整理面试题库时把过去一年问过的、真正能区分候选人水平的问题做了系统梳理。最终收敛到8个方向Transformer架构理解、Tokenization机制、Embedding原理与应用、注意力机制细节、Function Calling设计、模型微调策略、推理优化、以及幻觉与可靠性问题。这8个问题覆盖了从底层原理到工程落地的完整链路任何一个答不上来基本可以判断候选人在这个方向上缺乏深度实践。适合谁来读如果你正在准备LLM方向的面试不管是算法岗还是应用工程岗这篇内容可以当作一份自检清单。如果你是面试官也可以直接拿去用每个问题我都附上了“及格线”和“加分项”的区分标准。如果你只是对LLM感兴趣的技术人这里面的原理拆解和实操经验同样能帮你建立起一套完整的认知框架。下面我逐个拆解每个问题都会说清楚面试官到底想考什么、你应该怎么回答、以及我在实际面试中见过的典型翻车现场。2. Transformer架构不只是“Attention is All You Need”2.1 面试官真正想考的是什么“介绍一下Transformer”这个问题几乎每场面试都会出现。但面试官想听的绝对不是你把论文摘要背一遍。我通常会在候选人讲完标准答案之后追问三个问题为什么用LayerNorm而不是BatchNorm为什么是多头而不是单头位置编码为什么用正弦函数而不是可学习参数这三个追问能直接区分出“看过论文”和“真正理解设计动机”的人。大部分候选人能说出“多头可以捕捉不同子空间的特征”但当我问“那为什么不是越多头越好”时就卡住了。实际上头的数量受限于d_model每个头的维度是d_model / h头太多会导致每个头的维度太小表达能力反而下降。这个细节在原始论文里没有明说但在实际调参时非常关键。2.2 编码器与解码器的结构差异很多人把Transformer当成一个整体来讲但面试中你需要清晰地拆开说。编码器是双向注意力每个位置可以看到全序列解码器是因果注意力每个位置只能看到自己和之前的位置。这个差异直接决定了它们适合的任务类型。我一般会这样解释编码器像一个“全局审阅者”它需要看到完整上下文才能理解每个词的含义适合分类、抽取、Embedding生成等任务。解码器像一个“逐字写作的人”它只能基于已写的内容决定下一个词适合文本生成。而Encoder-Decoder结构比如T5、BART则是“先读懂再写”适合翻译、摘要这类需要理解输入再生成输出的任务。实际面试中我会让候选人画一下三种结构的注意力矩阵形状。这个看似简单的问题能直接暴露对方是否真正动手实现过Transformer。2.3 残差连接与层归一化的工程考量残差连接看起来简单但它在深层Transformer中的作用远超“防止梯度消失”。我试过在24层以上的模型中移除残差连接训练直接崩掉loss完全不下降。原因是残差连接保证了梯度可以绕过非线性变换直接回传这对于深层网络的稳定训练是必须的。LayerNorm的位置也有讲究。原始论文用的是Post-LN先做注意力/FFN再归一化但后来GPT-2开始改用Pre-LN先归一化再做注意力/FFN。Pre-LN的训练更稳定不需要warmup就能收敛但最终效果可能略逊于精心调参的Post-LN。这个取舍在实际项目中非常实用——如果你训练资源有限Pre-LN是更安全的选择。实操心得如果你在面试中被问到“训练不收敛怎么办”优先检查LayerNorm的位置和初始化方式。我踩过的坑是Post-LN结构下如果不做learning rate warmup前几千步的梯度范数会爆炸。2.4 位置编码的选型逻辑正弦位置编码的优势在于它可以外推到训练时没见过的序列长度。但在实际使用中外推效果往往不如预期。后来RoPE旋转位置编码成为主流因为它通过旋转矩阵编码相对位置信息在长序列上表现更好。现在很多开源模型LLaMA、Qwen等都用RoPE。面试中如果候选人能说出“RoPE通过绝对位置编码的方式实现了相对位置编码的效果”我会给加分。如果再能解释清楚RoPE的远程衰减特性——即随着距离增大注意力分数自然衰减——那就是资深级别的理解了。3. Tokenization大模型的第一道关卡3.1 为什么Tokenization值得单独问很多人觉得Tokenization只是预处理不重要。但实际项目中Tokenization直接影响到模型的效果、推理成本、甚至多语言能力。我见过一个真实案例某个团队做中文法律文书摘要模型效果一直不好排查了很久才发现是Tokenizer把很多法律术语切碎了导致模型根本学不到完整的术语表示。面试中我会问“BPE、WordPiece、SentencePiece有什么区别各自适合什么场景”这个问题能直接看出候选人有没有处理过真实数据。3.2 BPE、WordPiece与SentencePiece的核心差异BPEByte Pair Encoding的思路是从字符开始不断合并出现频率最高的相邻对。它的优点是简单、通用缺点是合并规则是基于频率的可能产生不合理的子词。GPT系列用的是BPE的变体。WordPiece是BERT用的方法它和BPE的区别在于BPE选频率最高的对WordPiece选能最大化语言模型似然的对。实际效果上WordPiece更倾向于产生有语言学意义的子词。SentencePiece的最大特点是它把输入当作原始字节流处理不依赖空格分词。这对中文、日文等没有空格分隔的语言非常重要。LLaMA系列用的就是SentencePiece。方法核心思路代表模型适合场景BPE合并最高频相邻对GPT系列英文为主通用场景WordPiece最大化语言模型似然BERT需要语言学合理性SentencePiece字节流处理不依赖空格LLaMA、T5多语言、中文场景3.3 词表大小的取舍词表大小是一个经典的工程取舍。词表太小一个词被切成很多token序列变长推理变慢词表太大Embedding矩阵参数量增加低频词训练不充分。常见的词表大小在32K到128K之间。LLaMA-2用的是32K而一些中文模型会扩展到64K甚至100K。我在实际项目中的经验是如果你的应用场景以中文为主词表至少要到50K以上否则很多常用词会被切碎。你可以用一个简单的方法验证拿一批业务数据统计平均每个词被切成几个token。如果超过2个说明词表可能偏小。3.4 特殊Token的设计与使用面试中很少有人主动提到特殊Token但这恰恰是实际工程中容易出问题的地方。[CLS]、[SEP]、[PAD]、[UNK]这些是基础但在对话模型中|system|、|user|、|assistant|这些角色标记的设计直接影响模型的行为。我踩过的一个坑在微调对话模型时没有正确设置|assistant|标记的loss mask导致模型把用户的问题也当作需要生成的内容来学习结果模型开始“自问自答”。正确的做法是只在assistant回复的部分计算loss其他部分mask掉。注意事项不同模型的特殊Token不同做微调时一定要查清楚基座模型的Token配置。用错Token会导致模型行为完全异常而且很难排查。4. Embedding从词向量到语义搜索的基石4.1 Embedding的本质是什么Embedding就是把离散的符号映射到连续的向量空间。但面试中我会追问“为什么Embedding能表达语义相似性”这个问题的核心在于分布式假设出现在相似上下文中的词含义相似。训练过程中模型通过预测上下文任务自然地把语义相近的词推到一起。但要注意Transformer产生的Embedding和Word2Vec的Embedding有本质区别。Word2Vec是静态的每个词只有一个向量Transformer是动态的同一个词在不同上下文中会有不同的向量。这就是为什么BERT的Embedding在语义任务上远优于Word2Vec。4.2 如何选择Embedding模型现在Embedding模型排行上常见的选项包括OpenAI的text-embedding-3系列、BGE系列、GTE系列、E5系列等。选择时需要考虑几个维度维度大小、最大输入长度、多语言支持、推理速度、以及是否支持指令前缀。我的经验是如果做中文语义搜索BGE-large-zh-v1.5是一个很稳的选择维度1024最大长度512。如果需要多语言BGE-M3支持100语言而且同时支持稠密检索、稀疏检索和多向量检索。如果追求极致速度可以用BGE-small或GTE-small维度降到384或512效果下降在可接受范围内。模型维度最大长度多语言适合场景BGE-large-zh1024512中文中文语义搜索BGE-M310248192100多语言、长文本GTE-large1024512英文为主英文语义搜索text-embedding-3-small15368191多语言通用场景4.3 向量检索的实操细节拿到Embedding之后下一步是向量检索。很多人直接用余弦相似度做暴力搜索数据量小的时候没问题但超过10万条就需要用近似最近邻ANN算法。常用的库包括Faiss、Annoy、HNSW等。我实测下来HNSW在召回率和速度之间平衡得最好。关键参数是M每个节点的连接数和efConstruction构建时的搜索深度。M越大召回率越高但内存占用也越大。一般M设为16-64efConstruction设为100-200。还有一个容易忽略的点归一化。如果你用余弦相似度一定要先把向量归一化到单位长度否则内积和余弦相似度不等价。我见过有人忘了归一化导致检索结果完全不对。4.4 Embedding微调的必要性与方法通用Embedding模型在垂直领域往往表现不佳。比如医疗、法律、金融这些领域术语的语义和通用领域差异很大。这时候就需要微调Embedding模型。微调Embedding通常用对比学习构造正样本对语义相似的句子和负样本对语义不相似的句子用InfoNCE损失训练。正样本可以从业务数据中挖掘比如同一篇文档的不同段落、同一问题的不同表述。负样本可以用in-batch negatives即同一个batch内其他样本作为负例。我做过一个法律领域的Embedding微调用2000对法律问答数据训练了3个epoch检索准确率从62%提升到了81%。数据量不需要很大但质量一定要高。5. 注意力机制面试中的分水岭5.1 自注意力的计算过程自注意力的核心公式是Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V。面试中我会让候选人逐步解释这个公式的每个部分。QK^T计算的是每对位置之间的相似度除以sqrt(d_k)是为了防止点积过大导致softmax梯度消失softmax把相似度转成概率分布最后用这些概率对V加权求和。这个解释大部分人能说出来。但我会接着问“为什么要除以sqrt(d_k)而不是d_k”这个问题的答案在于当d_k较大时点积的方差会增大导致softmax的输出趋近于one-hot梯度变得极小。除以sqrt(d_k)可以把方差拉回到1附近保持梯度的稳定性。这个细节在论文里有提但很多人看的时候跳过了。5.2 多头注意力的并行计算多头注意力的实现方式是把d_model分成h份每份维度是d_model/h然后并行做h次注意力计算最后拼接起来再做一次线性变换。这样做的好处是不同的头可以关注不同的模式有的头关注语法关系有的头关注语义相似性有的头关注位置邻近性。实际实现中我们不会真的创建h个独立的Q、K、V矩阵而是用一个大的线性层把d_model映射到3 * d_model然后reshape成h个头。这样可以用矩阵乘法一次性完成所有头的计算效率更高。5.3 注意力变体从稀疏注意力到Flash Attention标准注意力的计算复杂度是O(n^2)序列长度增加时计算量爆炸。为了解决这个问题出现了很多变体稀疏注意力只计算部分位置对线性注意力用核函数近似softmaxFlash Attention通过分块计算和重计算减少显存占用。Flash Attention是目前最实用的优化。它不改变注意力的数学结果但通过tiling技术把注意力计算分块避免了一次性存储完整的n x n注意力矩阵。我实测下来Flash Attention可以把长序列训练的显存占用降低50%以上速度提升2-3倍。面试中如果候选人能说出“Flash Attention的核心是IO感知它把计算分成小块在SRAM中完成减少HBM的读写”那就是加分项。5.4 注意力可视化与可解释性注意力权重可以用于分析模型的行为。比如在翻译任务中你可以可视化源语言和目标语言之间的注意力矩阵看看模型是否正确对齐了词。但要注意注意力权重不等于解释。有研究表明注意力权重和梯度的重要性并不总是一致。所以用注意力做可解释性分析时要谨慎下结论。6. Function Calling从对话到行动的桥梁6.1 Function Calling解决了什么问题大模型本身只能生成文本不能查天气、不能发邮件、不能操作数据库。Function Calling就是让模型能够“调用外部工具”的机制。它的核心思路是模型根据用户的意图生成一个结构化的函数调用请求通常是JSON格式应用程序执行这个函数把结果返回给模型模型再基于结果生成最终回复。这个机制让LLM从“聊天机器人”变成了“智能体”。面试中我会问“Function Calling和传统的意图识别槽位填充有什么区别”核心区别在于传统方法需要预先定义所有意图和槽位扩展性差Function Calling让模型自己决定调用哪个函数、传什么参数灵活得多。6.2 函数定义的设计要点函数定义的质量直接影响调用准确率。我总结了几条经验函数名要语义清晰get_weather比func1好得多。参数描述要详细包括类型、取值范围、是否必填、默认值。枚举值要列全如果参数是枚举类型把所有可能的值列出来。避免函数功能重叠如果两个函数功能相似模型容易混淆。一个常见的坑是参数描述太模糊导致模型传错参数。比如date参数如果不说明格式模型可能传2024-01-01也可能传Jan 1, 2024。明确写“格式为YYYY-MM-DD”可以大幅降低错误率。6.3 多轮函数调用的处理复杂任务往往需要多轮函数调用。比如用户说“帮我订明天从北京到上海的机票然后加到日历里”模型需要先调用search_flights拿到结果后调用book_flight最后调用add_calendar_event。处理多轮调用时关键是要维护好对话状态。每次函数调用的结果都要追加到对话历史中让模型知道上一步做了什么。同时要设置最大调用轮数防止模型陷入无限循环。实操心得我建议在系统提示中明确告诉模型“如果函数调用失败尝试其他方式或告知用户”否则模型可能会反复调用同一个失败的函数。6.4 错误处理与容错设计Function Calling的错误处理是工程中的难点。常见的错误包括函数不存在、参数格式错误、函数执行超时、返回结果为空。每种错误都需要不同的处理策略。我的做法是在函数执行层做参数校验如果参数不合法返回一个结构化的错误信息给模型让模型重新生成。如果函数执行超时返回超时提示让模型决定是重试还是告知用户。如果函数不存在直接告诉模型“该函数不可用”避免模型反复尝试。这种容错设计是构建可靠AI系统的关键。面试中如果候选人能主动提到错误处理我会认为他有实际工程经验。7. 模型微调从通用到专用的必经之路7.1 全量微调、LoRA与QLoRA的取舍全量微调更新所有参数效果最好但显存需求大。一个7B模型全量微调需要至少4张A100 80G。LoRA只训练低秩矩阵显存需求降低到1/3左右效果接近全量微调。QLoRA在LoRA基础上把基座模型量化到4-bit显存需求进一步降低单张24G显卡就能微调7B模型。选择哪种方式取决于你的资源和需求。如果数据量很大百万级全量微调值得投入。如果数据量在几千到几万条LoRA足够。如果资源极其有限QLoRA是唯一选择。方法显存需求7B训练速度效果适合场景全量微调4x80G慢最好大数据量、追求极致效果LoRA1x40G快接近全量中小数据量、快速迭代QLoRA1x24G较慢略逊于LoRA资源受限7.2 数据质量比数量更重要我做过一个对比实验用1000条高质量数据和10000条低质量数据分别微调结果1000条高质量数据的效果明显更好。高质量数据的标准是格式统一、答案准确、覆盖多样、无重复。数据标注是另一个关键环节。LLM的数据标注和传统NLP不同不需要标注每个token的标签而是需要构造高质量的输入-输出对。我的经验是让标注人员先写一个“理想回答”然后让模型生成几个回答标注人员从中选择最好的并修改。这样效率比从零写高得多。7.3 微调中的过拟合与灾难性遗忘微调最容易出现的问题是过拟合和灾难性遗忘。过拟合表现为训练loss持续下降但验证loss开始上升。灾难性遗忘表现为模型在通用任务上的能力下降。解决过拟合的方法包括早停、数据增强、Dropout、权重衰减。解决灾难性遗忘的方法包括混合通用数据一起训练、使用LoRA只更新部分参数、降低学习率。我通常会在微调数据中混入10%-20%的通用指令数据这样可以在保持专用能力的同时减缓通用能力的下降。8. 推理优化让模型跑得更快更省8.1 KV Cache的原理与优化自回归生成时每生成一个token都需要重新计算所有之前token的Key和Value。KV Cache把这些中间结果缓存起来避免重复计算。没有KV Cache时生成n个token的计算量是O(n^2)有了KV Cache计算量降到O(n)。但KV Cache会占用大量显存。对于一个7B模型序列长度2048batch size 1KV Cache大约占用1.5GB。如果batch size增大或序列变长显存占用会线性增长。优化方法包括MQAMulti-Query Attention让所有头共享K和VGQAGrouped-Query Attention让每组头共享K和V。LLaMA-2 70B用的就是GQA。8.2 量化推理的实操量化是把模型参数从FP16降到INT8或INT4减少显存占用和加速推理。常用的量化方法包括GPTQ、AWQ、GGUF等。GGUF格式特别适合在消费级硬件上运行支持CPU和GPU混合推理。我实测下来7B模型用Q4_K_M量化后显存占用从14GB降到4GB左右推理速度提升约1.5倍效果下降在可接受范围内。如果追求更高精度可以用Q5或Q8量化但显存占用和速度会相应变化。注意事项量化后的模型在某些任务上可能出现明显的质量下降特别是需要精确计算或长链推理的任务。建议在量化后做一轮评估确认关键指标没有大幅下降。8.3 批处理与连续批处理批处理可以提升GPU利用率但传统的静态批处理需要等最长的序列生成完才能返回结果。连续批处理Continuous Batching允许新请求动态加入正在运行的batch大幅提升吞吐量。vLLM和TensorRT-LLM都支持连续批处理。我实测过vLLM和HuggingFace Transformers的吞吐量对比在同样的硬件上vLLM的吞吐量是Transformers的5-10倍。这个差距主要来自PagedAttention和连续批处理。9. 幻觉与可靠性LLM落地的最后一道坎9.1 幻觉的成因分析幻觉是指模型生成了看似合理但实际错误的内容。成因包括训练数据中的错误信息、模型过度泛化、解码策略过于激进、以及模型缺乏事实核查能力。面试中我会问“如何减少幻觉”常见的回答包括RAG、温度调低、提示词约束。但我会追问“RAG能完全解决幻觉吗”答案是不能。RAG只能提供正确的参考信息但模型仍然可能忽略或错误解读这些信息。所以RAG之后还需要做引用验证和一致性检查。9.2 RAG系统中的可靠性设计RAG的可靠性取决于检索质量和生成质量。检索方面要确保召回的文档确实相关。我通常会用交叉编码器做重排序把检索到的Top-20文档重新打分选出Top-5最相关的。生成方面要约束模型只基于检索到的内容回答如果检索结果不包含答案模型应该明确说“不知道”。一个实用的技巧是在提示词中要求模型标注每个事实的来源。比如“根据文档[1]...”。这样用户可以验证信息的可靠性也方便排查错误。9.3 评估与监控LLM应用的评估比传统软件复杂得多因为输出是开放式的。我通常从几个维度评估准确性事实是否正确、相关性是否回答了问题、完整性是否覆盖了关键点、安全性是否有害内容。自动化评估可以用LLM-as-Judge让一个更强的模型来打分。但要注意LLM-as-Judge也有偏差比如倾向于给更长的回答打高分。所以最好结合人工评估定期抽样检查。监控方面要记录每次请求的输入、输出、检索结果、函数调用记录。当用户反馈问题时可以快速定位是检索问题、生成问题还是函数调用问题。10. 面试中的加分项与翻车现场10.1 什么样的回答能让面试官眼前一亮根据我面试的经验加分项通常包括主动提到工程中的取舍和权衡、能说出自己踩过的坑和解决方法、对最新技术保持关注、以及能清晰地解释复杂概念。比如问到Embedding时如果候选人能说出“BGE-M3支持稠密、稀疏和多向量三种检索方式我在项目中用稠密检索做粗排稀疏检索做精确匹配”这就是有实际经验的体现。问到推理优化时如果能说出“vLLM的PagedAttention把KV Cache分页管理减少了显存碎片”说明确实动手部署过。10.2 常见的翻车回答翻车回答通常有几类只背概念不理解原理、过度自信但细节错误、以及完全缺乏工程思维。我印象最深的一个候选人问到“Transformer为什么比RNN好”时他说“因为Transformer可以并行计算”。这个回答本身没错但当我追问“那RNN为什么不能并行”时他答不上来。实际上RNN的隐藏状态依赖前一步的计算结果天然是串行的。而Transformer的注意力机制可以一次性看到所有位置所以可以并行。这个追问直接暴露了他只是记住了结论没有理解本质。另一类翻车是过度自信。有个候选人在回答“如何减少幻觉”时斩钉截铁地说“用RAG就能解决”。当我追问“如果检索到的文档本身有错误怎么办”时他愣住了。实际上RAG只是把问题从“模型不知道”变成了“模型基于错误信息回答”并没有从根本上解决可靠性问题。10.3 如何准备这8个问题我的建议是不要死记硬背答案而是动手做一遍。自己实现一个简单的Transformer跑一遍Tokenization训练一个小的Embedding模型搭一个RAG系统部署一次vLLM。这些实操经验会让你在面试中的回答有血有肉而不是干巴巴的概念。另外准备几个自己项目中的案例。面试官最喜欢听的是“我在项目中遇到了什么问题我是怎么分析和解决的”。这种故事比任何标准答案都有说服力。最后再分享一个小技巧面试中遇到不会的问题不要硬编。可以说“这个我没有深入研究过但根据我的理解可能是...”。面试官更看重你的思考过程而不是标准答案。诚实和逻辑清晰比假装什么都懂要好得多。