LLM面试8大硬门槛：从Transformer到Function Calling的深度拆解

1. 为什么这8个问题成了LLM面试的硬门槛

这两年带团队、帮朋友内推、做技术评审，前后面过的大模型相关候选人没有一百也有八十。一个很明显的感受是：简历上写着“熟悉LLM”“做过大模型应用”的人越来越多，但真正能把这8个基础问题讲清楚的人，比例低得吓人。很多候选人能聊RAG、能聊Agent、能聊微调，可一旦问到Transformer的注意力机制到底怎么算、Tokenization为什么会影响模型表现、Function Calling的底层是怎么实现的，就开始含糊其辞。

这8个问题之所以成为面试的“硬门槛”，核心原因在于它们覆盖了LLM从输入到输出、从训练到推理、从单模型到工具调用的完整链路。面试官问这些问题，不是想考你背没背过公式，而是想判断三件事：第一，你对模型行为的理解是“调包侠”级别还是“知道所以然”级别；第二，遇到线上问题时，你能不能从原理层面定位根因；第三，你做技术选型和方案设计时，有没有足够的判断依据。

我见过太多候选人，RAG的pipeline搭得很溜，但被问到“为什么你的Embedding模型选这个而不是那个”时，只能回答“社区推荐的多”。这种回答在初级岗位可能勉强过关，但一旦涉及到中高级岗位，基本就是减分项。因为Embedding模型的选择直接决定了检索质量的上限，你连选型逻辑都说不清楚，面试官很难相信你能在复杂场景下做出正确决策。

所以这篇文章，我打算从面试官视角出发，把这8个问题逐个拆开，讲清楚每个问题到底在考什么、合格的回答应该包含哪些层次、常见的错误回答长什么样、以及我在实际面试中最看重的加分点是什么。不管你是准备面试的候选人，还是正在带团队的技术负责人，这些内容都应该能给你一些直接的参考。

提示：这篇文章的定位是“面试复盘+知识梳理”，不是八股文背诵手册。我会尽量把每个问题背后的原理讲透，但不会堆砌公式。如果你想要的是“标准答案模板”，那可能会失望；如果你想要的是“真正理解这些概念后自然能答出来”的状态，那这篇应该对你有用。

2. 八个必问问题逐个拆解

2.1 问题一：Transformer的自注意力机制到底在算什么

这是出现频率最高的问题，没有之一。几乎每一场LLM相关的面试，都会以某种形式问到注意力机制。但面试官真正想听的，不是你把“QKV”三个字母展开成Query、Key、Value，而是你对注意力本质的理解。

自注意力的核心思想可以用一句话概括：让序列中的每个位置，都能根据与其他位置的相关性，动态地聚合信息。这里的“相关性”就是通过Query和Key的点积来衡量的。具体来说，对于输入序列的每个token，我们把它映射成三个向量：Query（我要找什么）、Key（我有什么可以被找）、Value（我实际携带的信息）。然后用Query和所有位置的Key做点积，得到注意力分数，经过softmax归一化后，作为权重对Value进行加权求和。

面试官通常会追问几个层次的问题。第一层是“为什么要除以根号d_k”，这个问题考的是你对梯度稳定性的理解。点积的方差会随着维度d_k增大而增大，如果不缩放，softmax的输入会落在梯度极小的区域，导致训练困难。第二层是“多头注意力解决了什么问题”，这个问题考的是你对子空间表示的理解。单个注意力头只能学习一种相关性模式，多头允许模型在不同的表示子空间中并行捕捉不同类型的依赖关系。第三层往往是“自注意力的计算复杂度是多少，有什么优化方向”，这就涉及到O(n²)的复杂度问题，以及稀疏注意力、线性注意力等优化方案。

我在面试中最看重的加分点是：候选人能不能用自己的话把注意力的计算过程讲清楚，而不是背公式。比如有人会这样解释：“你可以把注意力想象成一个软性的查字典过程，Query是你要查的词，Key是字典里的索引，Value是索引对应的解释。不同的是，这里不是精确匹配，而是根据相似度对所有解释做加权平均。”这种回答就说明他真的理解了。

常见的错误回答包括：把QKV的来源搞混（比如以为Q来自解码器、KV来自编码器，这在交叉注意力中是对的，但自注意力中三者都来自同一个输入）；说不清楚为什么要做缩放；把多头注意力简单理解为“多个注意力结果拼接”。这些错误在初级候选人中非常普遍，但如果你面的是中高级岗位，这些错误基本是致命的。

2.2 问题二：Tokenization为什么会影响模型表现

Tokenization这个问题，很多候选人觉得“不就是分词吗”，但实际上它是LLM中最被低估的环节之一。面试官问这个问题，通常是想考察你对模型输入表示的理解深度。

Tokenization的本质是把原始文本转换成模型可以处理的离散符号序列。目前主流的方案是子词分词（Subword Tokenization），包括BPE、WordPiece、Unigram等。为什么不用词级别或字符级别？词级别的词汇表太大，而且无法处理未登录词；字符级别的序列太长，而且单个字符携带的语义信息太少。子词分词是在两者之间找平衡。

Tokenization影响模型表现的方式有很多。首先是词汇表大小和序列长度的权衡。词汇表越大，每个token携带的信息越多，序列越短，但嵌入矩阵和输出层的参数量也越大。其次是分词粒度对语义的影响。比如“unhappiness”可能被分成“un”“happi”“ness”，这种切分方式是否合理，直接影响模型对词义的理解。第三是多语言场景下的公平性问题。如果一个分词器主要在英文语料上训练，那么中文、阿拉伯语等语言的token效率会很低，同样的内容需要更长的序列，导致推理成本更高、效果更差。

我在实际面试中会追问一个具体场景：“如果你的模型在代码生成任务上表现不好，你会从Tokenization的角度做哪些排查？”合格的回答应该包括：检查分词器对代码中常见符号（如缩进、括号、运算符）的处理方式；对比不同分词器在代码语料上的压缩率；考虑是否需要针对代码领域重新训练分词器。这种问题没有标准答案，但能看出候选人有没有实际排查经验。

注意：很多候选人会把Tokenization和Embedding混为一谈。Tokenization是把文本变成token ID序列，Embedding是把token ID变成向量。两者是前后衔接的关系，但解决的问题完全不同。面试中如果混淆这两个概念，会显得基础不扎实。

2.3 问题三：Embedding模型的选型逻辑是什么

Embedding模型的选型，是RAG系统中最关键的决策之一。面试官问这个问题，通常是想考察你有没有自己的评估框架，而不是简单地“看排行榜”。

选型的第一维度是任务类型。对称检索（如相似问题匹配）和非对称检索（如query到文档的检索）对模型的要求不同。前者需要模型对语义等价但表述不同的文本给出相近的向量，后者需要模型理解query和文档之间的语义相关性。第二维度是语言和领域。多语言场景需要多语言Embedding模型，垂直领域（如医疗、法律、代码）可能需要领域适配的模型。第三维度是维度与性能的权衡。高维度向量检索精度更高，但存储和计算成本也更高。第四维度是最大输入长度。很多Embedding模型的最大长度是512个token，如果你的文档块超过这个长度，就会被截断，导致信息丢失。

我在面试中最看重的加分点是：候选人能不能说出自己实际做过的对比实验。比如“我在一个中文客服场景下对比了BGE、M3E和text-embedding-ada-002，发现BGE在短query上的召回率最高，但在长文档上的表现不如M3E，最后根据我们的query长度分布选择了BGE。”这种回答比“我看排行榜上BGE排第一”有说服力得多。

常见的错误回答包括：只看MTEB排行榜选模型，不考虑自己的实际场景；忽略Embedding模型的推理成本（有些模型虽然效果好，但推理速度慢，不适合在线场景）；不做归一化处理就计算余弦相似度。这些细节在面试中很容易被追问，一旦答不上来就会暴露实践经验不足。

2.4 问题四：Function Calling的底层是怎么实现的

Function Calling是Agent方向面试的必问题。很多候选人会用过OpenAI的Function Calling API，但被问到“底层是怎么实现的”时，就说不清楚了。

Function Calling的本质是让模型输出结构化的工具调用请求。实现方式通常有两种：一种是在训练阶段加入工具调用的数据，让模型学会在特定情况下输出特定格式的调用请求；另一种是在推理阶段通过Prompt Engineering和约束解码，引导模型输出符合Schema的JSON。目前主流方案是两者结合。

面试官通常会追问几个细节。第一，模型怎么知道有哪些工具可用？答案是把工具的Schema描述放在System Prompt或Function定义中，模型根据这些描述来判断是否需要调用工具、调用哪个工具。第二，模型输出的参数格式怎么保证正确？这涉及到约束解码（Constrained Decoding）技术，比如通过有限状态机限制输出只能符合JSON Schema。第三，多轮工具调用怎么处理？模型输出工具调用请求后，系统执行工具并把结果返回给模型，模型再决定下一步是继续调用工具还是生成最终回答。

我在实际面试中会问一个场景题：“如果模型总是调用错误的工具，你会怎么排查？”合格的回答应该包括：检查工具描述是否清晰、是否有歧义；检查Few-shot示例是否覆盖了边界情况；考虑是否需要微调模型来提升工具选择的准确率；检查是否存在多个工具功能重叠的情况。这种问题能看出候选人有没有实际调试过Agent系统。

2.5 问题五：LLM的幻觉问题怎么从工程角度缓解

幻觉问题是LLM落地过程中最头疼的问题之一。面试官问这个问题，不是想听你说“幻觉是因为模型训练数据有噪声”这种泛泛而谈，而是想考察你有没有系统性的缓解方案。

从工程角度缓解幻觉，通常有四个层次。第一层是检索增强，通过RAG把事实性知识注入上下文，让模型基于检索到的内容生成回答，而不是完全依赖参数化知识。第二层是Prompt约束，通过System Prompt明确要求模型“如果不确定就说不确定”“只基于提供的上下文回答”。第三层是输出验证，对模型生成的回答做事实性校验，比如用另一个模型或规则引擎检查关键实体和数值是否正确。第四层是人工兜底，在高风险场景下引入人工审核环节。

我在面试中最看重的加分点是：候选人能不能区分不同类型幻觉的缓解策略。比如事实性幻觉（模型编造了不存在的事实）和忠实性幻觉（模型偏离了提供的上下文）的缓解方法就不同。前者更需要检索增强，后者更需要Prompt约束和输出验证。能做出这种区分的候选人，通常在实际项目中踩过足够多的坑。

2.6 问题六：如何评估一个LLM应用的效果

评估是LLM应用从Demo走向生产的关键环节。面试官问这个问题，通常是想考察你有没有建立完整的评估体系，而不是只看BLEU、ROUGE这些传统指标。

LLM应用的评估通常包括几个维度。第一是任务指标，比如分类任务的准确率、生成任务的BLEU/ROUGE、检索任务的召回率。第二是人工评估，通过标注人员对生成质量、相关性、流畅度等维度打分。第三是模型评估，用更强的模型（如GPT-4）作为裁判来评估输出质量。第四是线上指标，比如用户点击率、满意度、会话轮数等。

我在实际面试中会追问一个关键问题：“你怎么保证评估集的质量？”很多候选人会忽略这一点，但实际上评估集的质量直接决定了评估结果的可信度。合格的回答应该包括：评估集要覆盖典型场景和边界场景；评估集的标注要有明确的标准和一致性检查；评估集要定期更新，避免模型过拟合。这些细节能看出候选人有没有真正做过评估体系。

2.7 问题七：LLM的推理优化有哪些手段

推理优化是LLM工程化落地的核心问题。面试官问这个问题，通常是想考察你对推理瓶颈的理解，以及你掌握多少优化手段。

推理优化的手段可以分为几个层次。第一层是模型层面，包括量化（INT8、INT4）、剪枝、蒸馏、稀疏化等。第二层是系统层面，包括KV Cache、Paged Attention、连续批处理（Continuous Batching）、投机解码（Speculative Decoding）等。第三层是硬件层面，包括算子融合、显存优化、多卡并行等。

我在面试中最看重的加分点是：候选人能不能量化不同优化手段的收益和代价。比如量化能把显存占用降低一半，但可能带来一定的精度损失；投机解码能提升生成速度，但需要额外的草稿模型。能说清楚这些权衡的候选人，通常在实际部署中积累了不少经验。

2.8 问题八：如果让你从零设计一个LLM应用，你会怎么做

这是一个开放性问题，通常出现在面试的最后阶段。面试官问这个问题，不是想听你背架构图，而是想考察你的系统设计能力和技术判断力。

一个合格的回答应该包括几个部分。第一是需求分析，明确应用场景、用户群体、核心指标。第二是技术选型，包括基座模型选择、Embedding模型选择、向量数据库选择、推理框架选择等。第三是架构设计，包括数据流、模块划分、接口设计。第四是评估方案，包括离线评估和线上评估。第五是迭代计划，包括冷启动、数据飞轮、持续优化。

我在面试中最看重的加分点是：候选人能不能根据场景做出合理的取舍。比如在低延迟场景下，可能需要选择更小的模型、更激进的量化策略；在高准确率场景下，可能需要引入多路召回、重排序、人工审核等环节。能做出这种取舍的候选人，通常有比较完整的项目经验。

3. 面试官视角的评分逻辑

3.1 初级、中级、高级岗位的区分标准

同样是这8个问题，不同级别的岗位，面试官的期望是不同的。初级岗位更看重基础概念的准确性，比如能不能正确解释注意力机制、能不能说清楚Tokenization的作用。中级岗位更看重实际应用经验，比如有没有做过Embedding选型、有没有调试过Function Calling。高级岗位更看重系统设计能力和技术判断力，比如能不能设计完整的评估体系、能不能在复杂场景下做出合理取舍。

我在面试中通常会根据候选人的级别调整追问的深度。面初级候选人时，如果基础概念答对了，我就会适可而止；面高级候选人时，我会不断追问“为什么”和“如果……怎么办”，直到摸到候选人的能力边界。

3.2 什么样的回答会被直接淘汰

根据我的面试经验，以下几种回答基本会被直接淘汰。第一种是概念混淆，比如把Tokenization和Embedding混为一谈，或者把自注意力和交叉注意力搞混。第二种是只会调包，比如问Embedding选型逻辑时，只能回答“我看别人都用这个”。第三种是缺乏实践经验，比如问Function Calling调试时，只能回答理论上的实现方式，说不出实际踩过的坑。第四种是过度包装，比如简历上写着“精通LLM”，但连最基本的注意力计算都说不清楚。

提示：面试中最忌讳的是“不懂装懂”。如果你对某个问题确实不了解，坦诚说“这块我了解不深，但我的理解是……”比胡编乱造要好得多。面试官通常能一眼看出你是不是在硬撑。

3.3 加分项和减分项速查表

4. 准备这8个问题的实操建议

4.1 怎么把知识变成自己的话

准备面试时，最有效的方法不是背答案，而是用自己的话把每个概念讲一遍。你可以找一个不懂技术的朋友，尝试用生活化的类比解释注意力机制、Tokenization、Embedding这些概念。如果你能让对方听懂，说明你真的理解了。

我在带新人时经常让他们做这个练习：把Transformer的注意力机制讲给一个高中生听。能讲清楚的人，面试时基本不会卡壳。讲不清楚的人，通常是因为自己也没完全理解。

4.2 怎么补充项目经验

如果你没有实际的大模型项目经验，可以通过几个方式补充。第一是复现经典项目，比如用LangChain搭一个RAG系统，用vLLM部署一个开源模型。第二是做对比实验，比如对比不同Embedding模型在你的场景下的表现，对比不同量化方案的推理速度和精度。第三是参与开源项目，通过阅读和贡献代码来积累经验。

这些经历在面试中都可以作为项目经验来聊，关键是要能说清楚你做了什么、为什么这么做、遇到了什么问题、怎么解决的。

4.3 面试中的表达技巧

面试中的表达，最重要的是结构化。回答每个问题时，可以先给一个一句话的总结，然后分点展开，最后如果有实际案例就补充一个案例。比如回答“Embedding选型逻辑”时，可以这样说：“我的选型逻辑主要看四个维度：任务类型、语言领域、维度性能和最大长度。具体来说……”这种结构化的表达能让面试官快速抓住你的思路。

另外，面试中要主动暴露思考过程。比如被问到一个不会的问题时，可以说：“这个问题我没有直接经验，但我会从以下几个角度来思考……”这种回答方式比直接说“不知道”要好得多，因为它展示了你的分析能力。

4.4 常见追问及应对策略

面试官在问完基础问题后，通常会追问一些更深的问题。比如问完注意力机制后，可能会追问“Multi-Query Attention和Grouped-Query Attention的区别是什么”；问完Embedding选型后，可能会追问“如果Embedding模型的最大长度不够怎么办”。应对这些追问，关键是要理解问题的本质，而不是死记答案。

比如Multi-Query Attention和Grouped-Query Attention的区别，本质上是KV Cache的显存占用和模型效果之间的权衡。理解了这一点，就能自然地回答出：MQA让所有注意力头共享同一组KV，显存占用最小但效果可能下降；GQA把注意力头分组，每组共享一组KV，是在MQA和标准MHA之间的折中方案。

5. 我踩过的坑和给候选人的建议

5.1 过度准备八股文反而容易翻车

我见过一些候选人，把网上能找到的面试题都背了一遍，但面试时一被追问就露馅。原因很简单：八股文的答案是死的，但面试官的追问是活的。如果你只是背了答案，没有真正理解背后的原理，面试官稍微换个角度问，你就答不上来了。

我的建议是：把80%的时间花在理解原理上，20%的时间花在组织表达上。原理理解了，表达自然就流畅了；原理没理解，背再多答案也没用。

5.2 项目经验要经得起深挖

简历上写的每一个项目，都要经得起面试官的深挖。我面试时经常会问：“这个项目中你遇到的最大挑战是什么？”“如果重新做一遍，你会怎么改进？”“这个方案的局限性是什么？”这些问题没有标准答案，但能看出候选人有没有真正参与过项目。

如果你只是参与了项目的一小部分，就如实说清楚你负责的部分，不要夸大。面试官通常能通过追问判断出你的真实贡献。

5.3 坦诚比完美更重要

最后说一点：面试中遇到不会的问题，坦诚说“这块我了解不深”并不可怕，可怕的是不懂装懂。我见过太多候选人，因为硬撑而暴露了更多问题。相反，那些坦诚承认不足、但能展示出学习能力和思考方式的候选人，往往能获得更好的评价。

这个行业变化太快，没有人能什么都懂。面试官真正想找的，不是“什么都会的人”，而是“能快速学习、能解决问题的人”。所以，与其花时间包装自己，不如花时间提升自己的真实能力。