★ FEATURED ARTICLE 1. 为什么这8个问题能直接决定面试成败面过几十个LLM方向的候选人之后我发现一个很残酷的现实简历上写着熟悉Transformer做过大模型微调的人一抓一大把但真正能把这8个问题讲清楚的人可能连三成都不到。这不是危言耸听而是这个领域从2023年爆发到现在大量速成选手涌入造成的必然结果——会用LangChain搭个Demo和真正理解大模型底层机制中间隔着一条很深的鸿沟。面试官问这些问题本质上不是考你背没背过概念而是通过你的回答判断三件事第一你是真的动手做过还是只停留在调包层面第二你对模型行为的理解是知其然还是知其所以然第三遇到线上问题时你有没有独立排查和解决的能力。这三个维度恰恰是区分能干活的人和会吹牛的人的分水岭。这篇文章我打算把这8个高频问题逐个拆开不光给你标准答案更重要的是告诉你面试官到底想听什么、哪些回答是雷区、以及怎么用你自己的项目经验把答案讲出彩。不管你是准备跳槽的工程师还是刚入行想系统梳理知识体系的新人这篇内容都值得你花时间啃完。我会尽量用大白话把原理讲透同时补充大量实操中才会遇到的细节——这些东西你在任何一本教材里都找不到。先给个整体框架这8个问题大致覆盖了这几个方向Transformer架构的核心机制、Tokenization的工程细节、Embedding的原理与应用、Function Calling的实现逻辑、以及大模型训练和推理中的关键取舍。每一个都是硬骨头但每一个也都有清晰的回答套路。2. Transformer架构从Self-Attention的计算过程说起2.1 面试官问讲讲Self-Attention时他真正想听什么几乎每场LLM面试都会从Transformer开刀而Self-Attention是必问中的必问。大部分候选人的回答是这样的Self-Attention就是通过Q、K、V三个矩阵计算注意力权重然后加权求和。这个回答不能说错但只能拿及格分因为它没有体现你对细节的理解。面试官真正想听到的是你对计算过程的完整把握。我来还原一下一个高分回答应该包含的层次首先输入序列的每个token经过Embedding层之后得到一个维度为d_model的向量。假设序列长度是n那输入矩阵X的shape就是(n, d_model)。然后通过三个线性变换矩阵W_Q、W_K、W_V分别得到Query、Key、Value三个矩阵。这里有个细节很多人会忽略W_Q、W_K、W_V的维度不一定是d_model × d_model在多头注意力中每个头的维度是d_model/hh是头数。接下来是核心计算Attention(Q, K, V) softmax(QK^T / √d_k) V。这个公式里的每一个部分都值得展开讲。QK^T计算的是每对token之间的相似度得到一个(n, n)的矩阵这个矩阵的每个元素(i, j)表示第i个token对第j个token的关注程度。除以√d_k是为了防止点积结果过大导致softmax梯度消失——当d_k很大时点积的方差会随之增大softmax的输出会趋近于one-hot分布梯度几乎为零。这个缩放因子的推导过程如果你能讲清楚面试官会立刻对你刮目相看。然后是softmax归一化把相似度转成概率分布。最后用这个概率分布对V加权求和得到每个位置的输出。整个过程可以理解为每个token都在问我应该关注序列中哪些其他token然后根据相似度打分再根据分数从其他token那里提取信息。2.2 多头注意力为什么不是简单的多搞几个头很多人对多头注意力的理解停留在把d_model分成h份每份独立做Attention最后拼接。这个描述没错但面试官如果追问为什么要多头而不是单头用更大的维度很多人就卡壳了。核心原因在于不同的头可以学习到不同类型的依赖关系。有的头可能关注语法结构比如主谓关系有的头可能关注语义相似性有的头可能关注位置邻近性。如果只用单头模型只能用一组注意力权重来表达所有类型的关系表达能力受限。这就像你用一只眼睛看世界和用两只眼睛看世界的区别——不只是视野更宽而是能感知深度。实操中还有一个容易踩的坑多头注意力的输出拼接之后还需要经过一个线性变换W_O。这个W_O的作用是把多个头的信息融合起来不是可有可无的。我在早期自己实现Transformer的时候一度以为拼接完就完事了结果训练出来的模型效果差了一大截排查了很久才发现漏了这个W_O。2.3 位置编码为什么正弦函数能表达位置信息Transformer本身是 permutation-invariant 的也就是说如果你把输入序列打乱Self-Attention的输出只是跟着打乱模型本身感知不到顺序。所以必须额外注入位置信息这就是位置编码的作用。原始论文用的是正弦位置编码PE(pos, 2i) sin(pos / 10000^(2i/d_model))PE(pos, 2i1) cos(pos / 10000^(2i/d_model))。面试官可能会问为什么用正弦函数而不是直接用位置索引0, 1, 2, ...原因有几个层面。第一直接用整数索引的话数值范围会随着序列长度增长而无限增大不利于训练稳定。第二正弦函数的输出范围固定在[-1, 1]而且不同位置之间的编码差异是有规律的。第三也是最重要的一点正弦编码允许模型通过线性变换表达相对位置关系。具体来说PE(posk)可以表示为PE(pos)的线性函数这让模型能够泛化到训练时没见过的序列长度。不过现在主流的大模型比如LLaMA系列大多改用RoPE旋转位置编码了。RoPE的核心思想是把位置信息编码成旋转矩阵作用在Q和K上这样注意力分数天然就包含了相对位置信息。如果你在面试中提到RoPE并且能说清楚它和正弦编码的区别绝对是加分项。2.4 从Encoder-Decoder到Decoder-Only的架构演变面试中经常会被问到为什么现在的大模型基本都是Decoder-Only架构这个问题看似简单但回答好需要你对NLP架构的演变有整体认知。最早的Transformer是Encoder-Decoder结构Encoder负责理解输入Decoder负责生成输出中间通过Cross-Attention连接。这种结构适合翻译、摘要这类seq2seq任务。后来BERT只用了Encoder擅长理解类任务分类、NER等GPT只用了Decoder擅长生成类任务。那为什么现在GPT系列、LLaMA系列、Qwen系列全都选择了Decoder-Only核心原因是** scaling law 和训练效率**。Decoder-Only架构在训练时可以用标准的自回归语言建模目标预测下一个token这个目标天然适合大规模无标注数据。而且Decoder-Only的架构更简单参数量更容易堆上去训练和推理的工程实现也更统一。另外研究发现Decoder-Only模型在足够大的规模下理解能力也不输甚至超过Encoder-Only模型这就让一个架构打天下成为可能。但这里有个细节值得注意Decoder-Only在推理时是自回归的也就是一个一个token往外蹦这导致推理速度受限于内存带宽而非计算能力。这也是为什么现在有那么多推理优化技术KV Cache、Speculative Decoding、量化等——本质上都是在解决自回归生成的效率问题。3. Tokenization那些你以为懂了其实没懂的细节3.1 BPE、WordPiece、SentencePiece到底有什么区别Tokenization是LLM的第一道工序也是最容易被忽视的环节。面试官问这个问题往往是想考察你对工程细节的关注程度。BPEByte Pair Encoding的思路是从字符级别开始不断合并出现频率最高的相邻字符对直到达到预设的词表大小。GPT系列用的就是BPE的变体。WordPiece是BERT用的方法和BPE类似但合并的标准不是频率而是似然增益——也就是说它选择合并后能最大程度提升语言模型概率的那对字符。SentencePiece则是Google提出的最大的特点是它把输入当作原始字节流处理不依赖预分词pre-tokenization这使得它对中文、日文等没有空格分隔的语言特别友好。LLaMA系列用的就是SentencePiece。面试中如果被问到中文场景下应该选哪种我的建议是优先考虑SentencePiece。原因很简单中文没有天然的空格分隔如果用BPE或WordPiece预处理阶段的分词策略会严重影响最终效果。SentencePiece直接处理原始文本避免了这个问题。3.2 词表大小怎么定一个被低估的工程决策词表大小vocab_size是一个看似不起眼但影响深远的超参数。词表太小一个词会被拆成很多subword序列变长推理变慢词表太大Embedding层的参数量暴涨而且低频词的训练不充分。以LLaMA为例它的词表大小是32000而GPT-2是50257GPT-4据传用的是100000左右的词表tiktoken的cl100k_base。中文场景下词表大小通常需要更大一些因为中文字符本身就有几万个如果词表太小很多常用汉字都会被拆成字节序列严重影响效率。这里有个实操经验如果你在微调一个中文LLM发现模型对某些专业术语的处理很差比如医学、法律领域的词汇一个可能的原因就是这些词在原始词表中被拆得太碎。解决方案有两种一是扩充词表需要重新训练Embedding层二是用领域数据继续做tokenizer的训练。前者成本高但效果彻底后者成本低但提升有限。3.3 Tokenizer和模型不匹配会怎样这是一个非常实际的坑。我见过有人拿LLaMA的tokenizer去处理数据然后喂给Qwen模型训练结果loss完全不收敛。原因很简单不同模型的tokenizer词表和ID映射完全不同token ID 100在LLaMA里可能对应the在Qwen里可能对应的。模型Embedding层是根据自己的词表训练的你喂进去错误的ID相当于给模型输入了乱码。所以记住一条铁律tokenizer必须和模型严格匹配。如果你要做模型融合或者迁移学习tokenizer的对齐是第一步也是最容易出错的一步。4. Embedding不只是把词变成向量4.1 Embedding的本质从离散到连续的映射Embedding这个词在LLM语境下有两层含义。第一层是模型内部的Embedding层把token ID映射成稠密向量第二层是独立的Embedding模型比如用于语义搜索、RAG的文本向量化模型。面试中要区分清楚面试官问的是哪个。模型内部的Embedding层本质上就是一个查找表一个shape为(vocab_size, d_model)的矩阵输入token ID就取出对应的行。这个矩阵是跟模型一起训练的训练完成后语义相近的token对应的向量在空间中距离也相近。这也是为什么我们能用king - man woman ≈ queen这种向量运算来做类比推理。独立的Embedding模型则是另一回事。它们通常基于BERT或类似的Encoder架构通过对比学习训练目标是把语义相似的文本映射到相近的向量空间。常见的评估基准是MTEBMassive Text Embedding Benchmark涵盖了检索、分类、聚类、语义相似度等多种任务。4.2 选Embedding模型时最容易踩的三个坑第一个坑只看排行榜不看场景。MTEB排行榜上排名靠前的模型不一定适合你的场景。比如有些模型在检索任务上很强但在分类任务上表现一般。你得先明确自己的下游任务是什么再去选对应的模型。第二个坑忽略维度对存储和检索速度的影响。Embedding维度从768到4096不等维度越高表达能力越强但存储成本和检索时的计算量也越大。如果你有上亿条数据要做向量检索维度每增加一倍存储成本就翻一倍检索延迟也会明显增加。这时候可以考虑用Matryoshka Embedding俄罗斯套娃式Embedding它允许你在推理时灵活截断维度在精度和效率之间做权衡。第三个坑不做领域适配。通用Embedding模型在专业领域医疗、法律、金融的表现往往不尽如人意。如果你的数据有很强的领域特性建议用领域数据对Embedding模型做微调或者至少做一下hard negative mining让模型学会区分领域内的相似样本。4.3 向量数据库选型别为了用而用RAG火了之后很多人一上来就搭向量数据库但其实不是所有场景都需要。如果你的数据量在十万条以内用FAISS或者甚至numpy做暴力检索完全够用延迟也在可接受范围内。只有当数据量到了百万级以上或者需要支持复杂的元数据过滤、多租户隔离等功能时才需要考虑Milvus、Qdrant、Weaviate这类专业的向量数据库。选型时重点看几个指标召回率、QPS、延迟、过滤能力、运维成本。我个人的经验是中小规模场景下Qdrant的性价比很高部署简单过滤功能也够用大规模场景下Milvus的分布式能力更强但运维复杂度也上去了。5. Function Calling让模型从会说到会做5.1 Function Calling的底层实现原理Function Calling是Agent的基础能力面试中问到的频率越来越高。很多人以为Function Calling是模型真的调用了函数其实不是。模型做的事情是根据用户的输入和可用的函数描述生成一个结构化的JSON里面包含函数名和参数。真正执行函数的是外部的应用程序。举个例子你定义了一个get_weather(city: str)的函数用户问北京今天天气怎么样。模型会输出类似{name: get_weather, arguments: {city: 北京}}的JSON。你的程序解析这个JSON调用实际的天气API把结果返回给模型模型再根据结果生成自然语言回复。理解这个流程很重要因为它决定了你在工程上需要注意什么。比如模型的输出不一定是合法的JSON尤其是小模型你需要做容错处理函数的参数描述要尽可能清晰因为这直接影响模型能否正确提取参数函数数量不宜过多否则会占用大量context window而且模型容易选错。5.2 参数描述怎么写才能让模型准确提取这是实操中非常关键但很少被提及的细节。Function Calling的准确率很大程度上取决于你的函数描述和参数描述写得好不好。几个原则第一函数名要语义明确用search_flights而不是sf第二参数描述要包含类型、格式、示例比如date: str, 格式为YYYY-MM-DD例如2024-01-15第三对于枚举类型的参数把所有可能的值列出来第四如果参数之间有依赖关系在描述中说明。我做过一个对比测试同一个函数用模糊的描述和详细的描述模型提取参数的准确率差了将近30个百分点。所以千万别在这上面偷懒。5.3 多轮Function Calling的状态管理实际应用中用户的需求往往需要多轮函数调用才能完成。比如帮我订一张明天从北京到上海的机票要靠窗的位置这可能需要先调用搜索航班再调用选座最后调用下单。每一轮的输出都要作为下一轮的输入同时还要维护对话历史。这里最大的挑战是错误处理。如果中间某一步失败了比如没有靠窗的位置了模型需要能够理解失败原因并决定是重试、换方案还是告知用户。这就要求你在prompt中明确告诉模型每种错误码的含义和对应的处理策略。另外一个坑是context window的管理。多轮Function Calling会产生大量的中间结果如果不做裁剪很快就会超出模型的context限制。我的做法是只保留最近几轮的完整结果更早的轮次只保留摘要。6. 大模型训练与推理中的关键取舍6.1 预训练、微调、RAG什么时候该用哪个这是面试中非常高频的一道场景题。很多人一上来就说微调但其实不是所有场景都适合微调。预训练适合从零开始训练一个基础模型成本极高动辄几百万美元只有大厂或研究机构才做。微调适合让模型适配特定任务或领域风格成本中等需要几千到几万条高质量数据。RAG适合让模型访问外部知识成本最低不需要训练只需要搭建检索系统。选择的核心判断标准是你需要改变的是模型的能力还是模型的知识。如果是知识比如最新的政策、公司内部文档用RAG如果是能力比如输出格式、推理风格、领域术语的理解用微调。两者也可以结合先用微调让模型学会领域语言再用RAG注入实时知识。6.2 LoRA和全量微调怎么选LoRALow-Rank Adaptation是目前最流行的参数高效微调方法。它的核心思想是不修改原始模型参数而是在每层旁边加一对低秩矩阵只训练这两个小矩阵。这样做的好处是显存占用大幅降低训练速度更快而且可以为不同任务训练不同的LoRA权重切换时只需要加载对应的权重即可。但LoRA不是万能的。如果你的任务和原始模型的预训练目标差异很大比如从英文模型适配到中文法律领域LoRA的效果可能不如全量微调。另外LoRA的rank选择也很关键rank太小表达能力不足rank太大参数量上去了就失去了参数高效的意义。实践中常用的rank是8到64之间具体取决于任务复杂度。6.3 量化精度和速度的平衡艺术量化是推理优化的核心手段之一。简单说就是把模型权重从FP16压缩到INT8或INT4减少显存占用和计算量。常见的量化方法有GPTQ、AWQ、GGUF等。GPTQ是训练后量化速度快但精度损失相对较大AWQ在量化时考虑了激活值的分布精度更好GGUF是llama.cpp用的格式支持CPU推理适合在消费级硬件上跑模型。量化最需要注意的是精度损失对下游任务的影响。有些任务对精度不敏感比如闲聊INT4量化后几乎看不出差别但有些任务很敏感比如代码生成、数学推理量化后错误率会明显上升。所以量化之后一定要在你的实际任务上做评估不能只看困惑度perplexity这个指标。7. 面试中的加分项与送命题7.1 怎么用项目经验把标准答案讲出差异化前面讲的都是知识点但面试中真正让你脱颖而出的是你怎么把这些知识点和你的实际经验结合起来。举个例子当面试官问讲讲你对Attention的理解你可以这样回答Attention的核心是QK^T计算相似度再对V加权求和。我在做长文本摘要的项目时发现标准Attention在序列长度超过2048之后效果明显下降排查后发现是因为注意力被稀释了——序列越长每个token分到的注意力权重越少。后来我们改用了滑动窗口注意力加全局token的方案在保持线性复杂度的同时关键信息的召回率提升了15%左右。这种回答既展示了你对原理的理解又体现了你解决实际问题的能力比干巴巴地背公式强太多了。7.2 哪些回答会让面试官直接扣分根据我自己的面试经验以下几种回答是明显的减分项第一种是背书式回答把教材上的定义一字不差地背出来但一问细节就露馅。第二种是万能式回答什么问题都用注意力机制上下文理解来搪塞没有具体内容。第三种是过度自信式回答明明不了解某个技术却硬要装作很懂结果被追问几句就崩了。第四种是贬低式回答比如说BERT已经过时了RNN完全没用了这种绝对化的表述会让面试官觉得你缺乏技术判断力。正确的做法是会就是会不会就坦诚说这块我了解不深但我的理解是...然后把你确定知道的部分讲清楚。面试官更看重的是你的思维方式和学习能力而不是你当前的知识储备。7.3 反问环节怎么问出水平面试最后的反问环节很多人觉得是走过场其实这是展示你技术品味的好机会。不要问薪资、加班这种HR环节该问的问题而是问一些能体现你思考深度的问题。比如你们现在推理服务的延迟瓶颈主要在哪里是KV Cache的显存占用还是batch调度或者你们做RAG的时候怎么处理检索结果和模型知识冲突的情况这种问题会让面试官觉得你是真的做过、想过而不是来碰运气的。8. 我踩过的坑和给你的备考建议聊了这么多技术细节最后说点实在的。我自己当年准备LLM面试的时候走了不少弯路。最开始是疯狂刷论文从Attention is All You Need到各种变体看了一大堆但面试的时候发现根本用不上——面试官不会让你推导公式他们更关心你能不能把复杂的东西讲简单。后来我调整了策略每学一个概念就试着用大白话给一个完全不懂技术的朋友讲一遍。如果讲不清楚说明我自己也没真懂。这个方法帮我发现了很多知识盲区比如我一度以为自己懂位置编码但当我试图解释为什么正弦函数能表达相对位置的时候才发现自己根本没理解到位。另外一个建议是一定要动手写代码。不用从头实现一个完整的Transformer虽然如果你能写出来绝对是加分项但至少要能手写Self-Attention的核心计算能用PyTorch搭一个简单的文本分类模型能调通一个LoRA微调的流程。面试中问到实操细节的时候有没有动过手一听就能听出来。还有一点关注最新的技术动态但不要盲目追新。面试官更看重你对基础原理的理解而不是你知道多少个新名词。与其花时间研究最新的某个小众微调方法不如把LoRA、量化、RAG这些主流技术的细节吃透。最后面试前一定要做模拟。找朋友或者对着镜子把常见的8个问题完整地讲一遍录音回听。你会发现自己有很多口头禅、逻辑跳跃、表述不清的地方这些在真实面试中都是扣分项。练个三五遍之后你的表达会流畅很多自信心也会上来。这个领域的面试确实有难度但只要你把基础打牢把项目做扎实把表达练清楚拿到心仪的offer只是时间问题。
阅读完成 · 觉得有帮助？
