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_model=512时用8个头，每个头64维；d_model=768时用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序列。分词方式直接决定了模型能多高效地表达某种语言、数字运算能力如何、代码理解能力如何。

以BPE（Byte 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模型排行榜很多，但选型不能只看榜单分数。我一般看这几个维度：

有个坑要提醒：不同模型产出的向量空间是不通用的。你不能用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：把相关资料检索出来塞进上下文，让模型基于给定材料回答，而不是靠记忆。其次是提示词约束：明确要求“如果材料中没有相关信息，就回答不知道”。再往上是后验校验：对模型输出做事实核查，比如用另一个模型或规则系统验证关键信息。

需要清醒认识到：目前没有哪种方法能完全消除幻觉。工程上的目标是把它压到可接受的范围，并且在关键场景加人工兜底。

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值得展开说。自回归生成时，每生成一个新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个问题不是孤立的。它们背后是一条完整的链路：文本怎么变成token，token怎么变成向量，向量怎么通过注意力交互，模型怎么调用外部工具，应用怎么评估和优化。把这条链路打通，面试时无论从哪个点切入，你都能接得住。这也是我一直建议的：别把知识点当孤岛背，要连成网。