LLM面试8大硬核问题：Transformer注意力、Tokenization与Function Calling深度解析-北京尧图网络

1. 为什么这8个问题成了LLM岗位的硬门槛面过LLM方向的人大概都有体会面试官不太爱问“你用过哪些框架”这种能背答案的题反而喜欢盯着几个基础概念往深里挖。原因很直接——大模型这行当工具半年换一茬但底层那套东西几年都没怎么变。Transformer的注意力怎么算、Tokenization到底切了什么、Embedding为什么能表达语义、Function Calling的协议怎么设计这些才是决定一个人能不能真正调得动模型、排得了bug的分水岭。我自己带过几轮面试也被人面过不少次。有个很明显的规律简历上写“熟悉LLM应用开发”的人里大概一半在问到“Self-Attention的复杂度是多少、为什么”的时候就卡住了。这不是刁难而是因为如果你不知道注意力是O(n²)你就不会理解为什么长上下文那么贵、为什么会有各种稀疏注意力和滑窗的变体、为什么RAG在某些场景下比硬塞长文本更划算。这些判断直接影响工程决策。这篇文章面向的是准备LLM相关岗位面试的人也适合已经在大模型应用一线、想把自己知识体系补扎实的工程师。我会把这8个高频问题逐个拆开不光给答案更讲清楚面试官问这个问题时到底想听到什么、哪些回答是加分项、哪些是踩雷区。文中涉及的具体参数和代码都是基于常见工程实践整理的你可以直接拿去对照自己的理解查漏补缺。需要先说明一点不同公司、不同岗位对这8个问题的侧重不一样。做推理优化的会往KV Cache和量化方向追问做Agent的会往Function Calling和规划能力上追问做数据侧的会往Tokenization和Embedding质量上追问。所以下面的内容我会尽量把每个问题的“基础答案”和“进阶追问”都覆盖到你按自己的方向取舍。2. 问题一Transformer的注意力机制到底在算什么2.1 从“查字典”理解QKV三件套面试官问注意力机制最想确认的是你有没有真正理解Q、K、V各自的角色而不是背出那个softmax公式。我一般会这么解释把注意力想象成一次带权重的查字典过程。你手里有个查询词Query字典里每个词条有个索引Key每个词条对应一个释义Value。你用Query去和所有Key算相似度相似度高的词条它的Value就被赋予更高的权重最后把所有Value按权重加权求和就是这次查询的结果。对应到公式上就是Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V这里的sqrt(d_k)是缩放因子d_k是Key向量的维度。为什么要除这个因为当维度很大时Q和K的点积结果方差会变大softmax之后会变得非常尖锐梯度几乎消失。除以sqrt(d_k)能把方差拉回到1附近训练才稳定。这个细节很多人答不上来但它是面试官判断你“是背的还是懂的”的关键分水岭。2.2 多头注意力不是简单的并行Multi-Head Attention经常被误解成“把注意力算好几遍然后拼起来”。更准确的理解是把模型的表示空间切成多个子空间每个头在各自的子空间里独立地学习一种关注模式。有的头可能关注语法依赖有的头关注指代关系有的头关注位置邻近。最后把各头的输出拼接再投影等于让模型同时从多个角度理解同一段文本。这里有个实操中容易忽略的点头的数量不是越多越好。头太多每个头的维度就太小表达能力反而下降。常见的配置是d_model512时用8个头每个头64维d_model768时用12个头。这个比例关系在面试里如果能主动说出来会显得你有工程直觉。2.3 复杂度为什么是O(n²)以及它带来的连锁反应自注意力的计算量随序列长度n的平方增长这是LLM领域最核心的约束之一。具体来说QK^T这一步是n×d和d×n的矩阵乘得到n×n的矩阵计算量是O(n²d)再乘以V又是O(n²d)。所以序列翻倍计算量翻四倍。这个事实直接解释了一堆工程现象为什么上下文窗口从4K扩到128K时推理成本涨得那么凶为什么FlashAttention这种IO感知的算法能大幅提速它没有改变O(n²)的计算量而是减少了显存读写为什么长文本场景下大家更愿意用RAG而不是无脑塞进上下文。面试时如果你能把这些串起来讲面试官基本会认定你是真做过事的。注意面试中被问到“怎么优化长序列”不要一上来就说“用稀疏注意力”。先问清楚场景——是训练还是推理、是追求精度还是追求吞吐。不同答案对应的方案完全不同上来就给方案反而暴露你没做过权衡。3. 问题二Tokenization为什么会影响模型的一切3.1 分词不是预处理是模型世界观的一部分很多人把Tokenization当成一个无关紧要的预处理步骤这是大错特错。模型看到的从来不是文字而是token序列。分词方式直接决定了模型能多高效地表达某种语言、数字运算能力如何、代码理解能力如何。以BPEByte Pair Encoding为例它的核心思路是从字符开始不断把出现频率最高的相邻对合并成新的token。训练语料里“ing”出现得多它就会被合并成一个token中文里“的”出现得多也会被合并。最终词表大小通常控制在几万到十几万之间。词表太小序列会变长推理变慢词表太大Embedding矩阵会膨胀低频token训练不充分。3.2 为什么同一个问题换个分词就答不对有个经典现象早期模型做算术题经常出错一个原因是数字被切得七零八落。比如“1234”可能被切成“12”和“34”两个token模型很难理解这是一个整体数值。后来很多模型专门对数字做了逐位切分算术能力就上来了。这说明分词策略是会影响模型能力的不是中性的。中文场景下这个问题更明显。同样一句话用不同的分词器token数量可能差30%以上。token多意味着更贵、更慢、更容易超出上下文。所以做中文应用时选模型不能只看效果榜单还要看它的分词器对中文是否友好。我实测过几个主流模型同样一段500字的中文token数从600到900不等成本差距相当可观。3.3 面试里怎么答才显得专业被问到Tokenization我建议按这个层次答先说清楚它是什么把文本映射成整数序列的过程再说主流方法BPE、WordPiece、SentencePiece的区别然后落到工程影响词表大小、序列长度、多语言支持、特殊token的处理。如果能补一句“特殊token比如BOS、EOS、PAD、以及对话模板里的角色标记处理不当会导致模型行为异常”基本就到位了。实操心得调试对话模型时如果发现模型总是“抢话”或者不按格式输出先检查对话模板的token拼接是否正确。很多诡异问题根源都在这里而不是模型本身。4. 问题三Embedding凭什么能表示语义4.1 从“坐标”到“语义距离”Embedding本质上是把离散的符号词、句子、图片映射到连续向量空间里的一个点。这个映射的关键性质是语义相近的东西在空间里的距离也近。比如“猫”和“狗”的向量距离会比“猫”和“汽车”近得多。这个性质不是人为设计的是训练出来的。以Word2Vec为代表的早期方法通过“预测上下文”或“用上下文预测中心词”的任务让经常出现在相似上下文里的词获得相似的向量。到了Transformer时代Embedding通常是模型第一层的输出或者用整个序列的池化结果来表示句子。4.2 余弦相似度为什么成了默认选择比较两个Embedding的相似度最常用的是余弦相似度而不是欧氏距离。原因是余弦相似度只看方向不看长度而向量的长度往往受文本长度、词频等因素影响方向才更能反映语义。公式是cosine_sim(A, B) (A · B) / (||A|| * ||B||)取值范围从-1到1越接近1越相似。实际做检索时通常会把所有向量归一化成单位向量这样余弦相似度就等价于点积可以用矩阵乘法一次性算完速度快很多。4.3 选Embedding模型的几个硬指标现在Embedding模型排行榜很多但选型不能只看榜单分数。我一般看这几个维度维度说明常见取舍维度大小向量维度越高表达力越强但存储和计算成本越高768维是常见平衡点1024/1536用于高精度场景最大长度能处理多长的文本512 token适合短句8K适合长文档多语言能力是否支持中英混合中文场景必须实测不能只看英文榜单推理速度每秒能编码多少条大批量离线场景可放宽在线检索要卡紧领域适配通用还是垂直法律、医疗等垂直领域建议微调有个坑要提醒不同模型产出的向量空间是不通用的。你不能用A模型编码文档库、用B模型编码查询那样相似度计算毫无意义。换模型必须全量重编码这个成本要提前算进去。5. 问题四Function Calling的协议怎么设计才靠谱5.1 它解决的是“模型怎么调用外部能力”Function Calling也叫Tool Use让模型能够输出结构化的调用请求而不是只输出自然语言。比如用户问“北京今天天气怎么样”模型不是直接编一个答案而是输出一个调用get_weather(city北京)的请求由外部系统真正执行后再把结果喂回模型。这个机制的价值在于模型的知识是静态的、有截止日期的而真实世界的信息是动态的。通过Function Calling模型可以查数据库、调API、执行计算能力边界被大幅扩展。5.2 一个可靠的调用协议长什么样设计Function Calling协议核心是把工具的“说明书”写清楚。通常包括工具名、功能描述、参数列表每个参数的名字、类型、是否必填、描述。模型根据这份说明书决定调不调、调哪个、传什么参数。{ name: search_flights, description: 根据出发地、目的地和日期查询航班, parameters: { type: object, properties: { origin: {type: string, description: 出发城市}, destination: {type: string, description: 到达城市}, date: {type: string, description: 日期格式YYYY-MM-DD} }, required: [origin, destination, date] } }描述写得好不好直接决定调用准确率。我踩过的坑是描述太笼统模型会乱调参数类型不明确模型会传错格式。比如日期如果不写清楚格式模型可能传“明天”“下周三”这种自然语言导致解析失败。5.3 多轮调用和错误处理才是难点单次调用不难难的是多轮场景。模型调了一个工具拿到结果后可能需要再调另一个或者根据结果决定下一步。这时候要处理几个问题调用链的最大轮数限制防止死循环、工具执行失败时怎么把错误信息反馈给模型、并行调用的结果怎么合并。我的经验是错误信息要结构化地返回给模型而不是抛一个异常就完事。比如返回{error: 城市名无法识别, suggestion: 请使用标准城市名}模型看到后往往能自我纠正重新发起调用。这比直接失败要健壮得多。注意Function Calling的安全边界必须自己把控。模型输出的参数不能直接拼进SQL或系统命令一定要做校验和转义。这是很多事故的源头。6. 问题五大模型的“幻觉”到底怎么产生的6.1 幻觉不是bug是生成机制的副产品面试官问幻觉想听的不是“模型会瞎编”这种表面答案而是你对生成机制的理解。大模型的本质是下一个token的概率预测器它优化的目标是“让输出看起来像训练数据里的合理续写”而不是“说真话”。当模型没有足够知识时它会基于语言模式生成一个“看起来合理”的答案这就是幻觉。从概率角度看模型在每个位置输出的是整个词表上的分布采样策略温度、top-k、top-p决定了它选哪个token。温度越高越容易选到低概率token输出越发散幻觉概率也越高。所以幻觉和创造性其实是同一枚硬币的两面。6.2 哪些场景幻觉最严重根据我的观察这几类场景幻觉高发一是涉及具体数字、日期、人名的事实性问题二是训练数据稀少的领域三是需要多步推理的问题四是被诱导性提问时比如“请证明XXX是对的”。理解这些高发场景才能有针对性地做防护。6.3 工程上怎么压制幻觉压制幻觉的手段分几层。最直接的是RAG把相关资料检索出来塞进上下文让模型基于给定材料回答而不是靠记忆。其次是提示词约束明确要求“如果材料中没有相关信息就回答不知道”。再往上是后验校验对模型输出做事实核查比如用另一个模型或规则系统验证关键信息。手段适用场景成本效果RAG有知识库的场景中显著降低事实性幻觉提示词约束所有场景低有限但必要后验校验高准确率要求高有效但增加延迟降低温度事实性问答低减少发散微调垂直领域很高长期有效需要清醒认识到目前没有哪种方法能完全消除幻觉。工程上的目标是把它压到可接受的范围并且在关键场景加人工兜底。7. 问题六RAG和微调到底怎么选7.1 两者解决的不是同一个问题这是面试里区分度很高的一题。很多人把RAG和微调当成二选一其实它们解决的是不同层面的问题。RAG解决的是“模型不知道某个具体事实”的问题它把外部知识动态注入上下文。微调解决的是“模型行为不符合要求”的问题它通过调整参数改变模型的输出风格、格式、领域能力。打个比方RAG像是给考生发了一本参考书考试时可以翻微调像是让考生去上了几个月的专项培训班把知识内化了。前者灵活、更新快、成本低后者稳定、不占上下文、但更新麻烦、成本高。7.2 决策树什么情况选什么我一般用这个判断流程如果需求是“让模型知道最新的、私有的、频繁变化的事实”选RAG。如果需求是“让模型稳定输出某种格式、掌握某种专业表达、或者压缩提示词长度”选微调。如果两者都要可以组合——先微调让模型学会领域语言和输出规范再用RAG补充动态事实。有个常见误区是“数据不够就微调”。微调需要的数据量取决于任务但通常至少几百到几千条高质量样本。数据不够时RAG是更务实的选择因为它对数据量的要求低得多几条文档就能用。7.3 成本账要算清楚RAG的成本主要在检索系统向量库、Embedding计算和更长的上下文token费用。微调的成本主要在训练GPU时间和维护每次基础模型更新都要重训。从长期看如果知识更新频繁RAG的边际成本更低如果任务固定、调用量大微调能省下大量上下文token费用。这个账在面试里如果能算出来会非常加分。8. 问题七怎么评估一个大模型应用的好坏8.1 离线评估和在线评估要分开看评估是LLM工程里最容易被低估的环节。很多人做完应用就凭感觉说“效果不错”这在面试里是减分项。专业的做法是建立分层评估体系离线用标注数据集算指标在线用A/B测试看业务指标。离线指标常见的有准确率、召回率、F1用于分类和检索、BLEU/ROUGE用于生成但这两个指标和人类判断相关性有限、以及基于LLM的自动评估用强模型给弱模型的输出打分。在线指标则看用户点击、采纳率、任务完成率、平均对话轮数等。8.2 LLM-as-Judge的坑用大模型做评估器现在很流行但有几个坑必须知道。一是位置偏见模型倾向于给排在前面的选项更高分所以评估时要随机打乱顺序。二是长度偏见长回答往往得分更高哪怕内容注水。三是自我偏好模型倾向于给自己或同系列模型的输出打高分。所以用LLM做评估时最好用多个模型交叉验证并且定期用人工标注校准。8.3 构建评估集的实操建议评估集的质量决定评估的价值。我的建议是从真实用户query里采样覆盖高频场景和边界case每条样本标注标准答案或评分标准定期更新因为用户需求会漂移。规模上初期200-500条就能看出问题成熟后建议上千条。别追求一次到位评估集是迭代出来的。实操心得评估集里一定要包含“模型应该拒答”的样本。很多应用出事不是因为答错而是因为该拒答的时候硬答。这类样本能暴露安全防护的漏洞。9. 问题八LLM应用的延迟和成本怎么优化9.1 先定位瓶颈在哪优化之前先测量。LLM应用的延迟通常分几块输入处理分词、检索、模型推理prefill和decode、输出处理。prefill是处理输入prompt的阶段可以并行通常较快decode是逐token生成的阶段是延迟的主要来源因为它是串行的。所以输出越长延迟越高。成本方面主要看输入token数和输出token数。输入贵在prefill输出贵在decode而且输出token通常单价更高。所以优化成本的一个直接思路是能少输出就少输出能短上下文就短上下文。9.2 几个立竿见影的优化手段手段优化目标原理代价KV Cache延迟缓存已计算的Key/Value避免重复计算显存占用量化成本延迟用低精度表示权重减少计算和显存轻微精度损失批处理吞吐多个请求一起推理提高GPU利用率单请求延迟可能增加提示词压缩成本精简输入减少token可能损失信息流式输出感知延迟边生成边返回用户更早看到内容不降低总延迟缓存语义结果成本延迟相似问题直接返回缓存答案需要相似度判断KV Cache值得展开说。自回归生成时每生成一个新token都要重新计算所有历史token的注意力。KV Cache把历史token的Key和Value存下来新token只需要计算自己的Q然后和缓存的K、V做注意力。这把每步的计算量从O(n²)降到O(n)是推理加速的基石。代价是显存序列越长、批越大KV Cache占用越高这也是为什么长上下文推理那么吃显存。9.3 成本优化的取舍哲学优化不是免费的每个手段都有代价。量化会损失精度批处理会增加延迟提示词压缩可能丢信息。所以优化的前提是明确约束是延迟敏感还是成本敏感是可接受轻微精度损失还是必须无损把这些想清楚才能做出合理的取舍。面试时如果能把“没有银弹只有权衡”这个态度表达出来比背一堆优化技巧更能打动面试官。10. 面试现场的几个真实体会聊完这8个问题再说点面试现场的东西。我见过不少候选人知识其实不差但答得让人抓不住重点。一个很实用的技巧是回答技术问题时先给一句话的结论再展开细节。比如被问“注意力复杂度是多少”先说“O(n²)因为要算所有位置两两之间的相似度”然后再补充缩放因子、多头、优化手段。这样面试官第一时间就知道你懂后面的展开是加分。另一个体会是不会的问题别硬编。LLM领域很广没人什么都懂。遇到不会的可以说“这块我了解得不深但我的理解是……如果有偏差请指正”。诚实加上一点推理比胡编乱造强得多。面试官往往更看重你的思考方式而不是标准答案。最后这8个问题不是孤立的。它们背后是一条完整的链路文本怎么变成tokentoken怎么变成向量向量怎么通过注意力交互模型怎么调用外部工具应用怎么评估和优化。把这条链路打通面试时无论从哪个点切入你都能接得住。这也是我一直建议的别把知识点当孤岛背要连成网。

LLM面试8大硬核问题：Transformer注意力、Tokenization与Function Calling深度解析

相关推荐

AI应用架构设计：从LLM选型到Agent与MCP的工程实践

用Java构建企业级AI Agent框架：核心原理与工程落地实践

表格与数据库数据进RAG：从CSV、Excel到LlamaHub的完整实战

更多资讯

原神抽卡模拟器开发指南：概率模型、代码实现与验证

C++/MFC扫雷完整程序：大作业从能跑到交得掉的避坑指南

Java大鱼吃小鱼项目实战：从面向对象到多线程的完整实现

AI漫剧制作全流程指南：从剧本到成片

学术论文双红线问题：查重与AIGC检测的智能解决方案

1024 给后端工程师的一份验证清单：把“我觉得”变成证据

今日更新

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？