LLM 面试这几年卷到什么程度？从大厂到创业公司，只要岗位名字里带“大模型”三个字，面试官几乎必问 Transformer、Tokenizer、RAG、微调、Agent 这一串。很多候选人简历写得花团锦簇，一开口却连“为什么 Decoder-only 能当生成模型”“RLHF 和 DPO 到底是什么关系”都说不利索。这篇文章不给你一本“标准答案”，而是把面试中最高频的 8 个必问题拆开揉碎，讲清楚每道题面试官到底想听什么、哪些答法属于“当场淘汰”级别、怎么答才能拿到加分。无论你面的是大模型算法岗、应用工程岗还是 AI Infra 岗，这份清单基本够用了。
1. LLM 面试到底在考什么：先看懂面试官的出题逻辑
1.1 面试官真正想考察的三种能力
很多候选人以为面试就是背八股，Transformer 结构、注意力公式、训练流程背得滚瓜烂熟，结果面完才发现面试官根本不按套路出牌。我面过不少人，也陪朋友模拟面过很多轮，一个很直观的感受是：现在的 LLM 面试已经从“知识复读机”进化到了“工程判断题”。
面试官真正想验证的无非三件事。第一，模型理解力——你是不是真的知道 token 怎么切、位置编码怎么加、KV Cache 为什么占显存，而不是只会调 API。第二，工程判断力——给你一个业务场景，你是先上提示词还是直接微调？RAG 的切片大小怎么定？召回结果不好是改 embedding 还是改 rerank？这些选择背后有没有成本意识。第三，系统落地力——评估怎么做、数据怎么标、坏例子怎么收集、上线之后怎么迭代。很多候选人死在第二和第三层，因为他们只学过“模型怎么训练”，没想过“模型怎么用”和“怎么证明它好用”。
所以这篇不是一篇八股速成手册，更像是一张出题地图。我会顺着面试官最常见的追问路径，把 8 个必问题串起来，每一个问题都给出基础答法、进阶答法和淘汰答法的对照。你可以在面试前对照着自查，看看哪一环是你的薄弱点。
1.2 8 问全景总览：先看地图再上路
为了让你对这 8 个问题有个整体印象，我先把它们列成一张表。这张表也可以当你的面试复习清单，每准备完一题就划掉一个。
| 序号 | 必问问题 | 对应考察点 | 典型淘汰答法 |
|---|---|---|---|
| 1 | Transformer 的核心机制是什么，为什么它能成为大模型的基础 | 模型骨架、注意力机制、位置编码 | 只会说“注意力机制”，讲不清 QKV 和缩放 |
| 2 | Token 和 Tokenizer 是什么，BPE 分词是怎么做的 | 数据源头、词表设计、序列长度 | 以为 Token 就是“字”，不知道 BPE 合并过程 |
| 3 | 预训练、SFT、RLHF/DPO 三个阶段分别解决什么问题 | 训练方法论、对齐技术 | 分不清 SFT 和 RLHF，以为 RLHF 就是 PPO |
| 4 | RAG 的工作原理是什么，为什么能缓解幻觉 | 检索增强、切分策略、重排设计 | 把 RAG 理解成“直接把搜来的文本拼进 prompt” |
| 5 | LLM 为什么会产生幻觉，工程上怎么缓解 | 根因分析、生成策略、评估意识 | 把幻觉归咎于“模型太笨”，没有系统方案 |
| 6 | 长上下文的瓶颈在哪，KV Cache 是什么 | 注意力复杂度、推理优化、显存计算 | 完全没听过 KV Cache，不清楚长文本为何贵 |
| 7 | 提示工程、RAG、微调怎么选，LoRA 原理是什么 | 工程选型、成本判断、参数高效微调 | 一张口就“微调一个私有模型”，缺少取舍逻辑 |
| 8 | Function Calling 和 Agent 是什么，评估体系怎么搭 | Agent 落地、工具调用、线上评估 | 只会写一个 ReAct 循环，没有任何评估和兜底 |
这 8 题不是孤立的，第 4、5、6 题其实是同一个问题的三个侧面——如何让模型在真实场景里稳定输出。第 3 题和第 7 题又形成对照：训练侧怎么让模型“会听指令”，应用侧怎么在“不动模型权重”的前提下达到类似效果。面试官最喜欢干的事，就是从答案里拎出一条线，顺着往下追。所以下面每一题我都会刻意标注“可被追问的方向”。
2. Transformer 与 Tokenizer：前两问从“骨架”和“砖块”开始
2.1 第一问：Transformer 的核心机制，怎么答才算过关
这题几乎 100% 会出现，但大多数人答得太浅。面试官问“讲讲 Transformer”，不是想听你背一遍“Encoder-Decoder 结构、多头注意力、残差连接、LayerNorm”这种目录，而是想看你对每个模块存在的必要性有没有真实理解。
首先要能把注意力公式讲明白：Q（查询）、K（键）、V（值）三个向量，注意力分数是 Q 和 K 的点积，然后除以 √d_k 做缩放，再过 softmax 得到权重，最后加权求和 V。这里有个高频追问点：为什么点积之后要除以 √d_k？因为当向量维度 d_k 变大时，点积的数值会跟着变大，softmax 会进入饱和区，梯度变得很小，训练基本推不动。除以 √d_k 的本质是把点积结果拉回到一个合理的尺度范围内。如果只是背公式，不解释这一步，面试官基本能判断你只是停留在“见过”的层面。
第二个高频追问点是：为什么现在主流生成模型都是 Decoder-only 结构？这里可以简单对比一下：BERT 的 Encoder 是双向注意力，适合做理解任务；GPT 的 Decoder 是带因果掩码的单向注意力，每个位置只能看左边的 token，天然适合自回归生成。而生成恰恰是 LLM 最核心的能力，所以 Decoder-only 成了事实标准。更进阶一点可以说，Decoder-only 在训练时也可以统一成“下一个 token 预测”的方式，预训练和下游任务的目标完全一致，工程设计简单。
第三，一定要能说出缩放点积注意力之外的关键工程细节。比如 Transformer 为什么需要残差连接——深层网络里梯度传导困难，残差结构相当于给梯度开了一条“高速公路”。为什么用 LayerNorm 而不是 BatchNorm——NLP 里序列长度变化大，BatchNorm 在 batch 维度上统计均值方差非常不稳定，而 LayerNorm 在单样本内部做归一化，和序列长度无关，推理时也更稳定。
到这里，基础答法已经过关。但如果你能再补一句“多头的意义是让模型在多个子空间里并行关注不同信息，比如一个头关注语法关系，另一个头关注指代消解”，这就是加分项。淘汰答法也很典型：有人会说“Transformer 就是有自注意力机制的模型”，然后再也挤不出第二句。这基本等于告诉面试官你没做过任何深入功课。
2.2 位置编码：从加法到旋转，RoPE 为什么成为事实标准
Transformer 本身对 token 顺序没有感知，它是集合操作，把序列打乱，注意力结果不变。所以要靠位置编码把“第几个 token”的信息掺进去。这一题经常作为第一问的追问出现，如果你能接上，就已经超过一半竞争对手。
最朴素的做法是绝对位置编码，也就是在 embedding 上直接加一个位置向量，比如原始的 Transformer 用正弦余弦函数，或者像 BERT 那样直接学一个位置 embedding。但绝对位置编码有个问题：它把位置信息当作“绝对坐标”，模型不容易外推到训练时没见过的长度，而且它对相对位置关系的表达能力比较弱。
现在的主流方案是 RoPE，旋转位置编码。它的思想很直观：把位置差异编码成“向量之间的夹角”，也就是每个位置的向量在二维平面上做旋转，位置距离越远，两个向量夹角越大，注意力分数里就带上了相对位置信息。你不需要把公式全部背下来，但最好能说出核心直觉——RoPE 让模型关注的是“相对距离”而不是“绝对编号”，所以外推性更强，这也是 LLaMA、Qwen 等一系列模型选它的原因。
再往下挖一层，面试官可能会问“你知道 RoPE 怎么被用来扩展上下文吗”，这就是送分题了。RoPE 的旋转频率和三角函数里的频率参数有关，如果原始模型只训练到 4096 长度，直接推到 32K 会失效。NTK-aware scaling 的思路是调整旋转频率的基准，让位置信息随着长度增长而慢慢变化，类似信号处理里的“频闪”；YaRN 则进一步修正了注意力分数的温度。能说出这些，说明你真的动手调过参数或读过相关代码，而不是只刷过面经。
2.3 第二问：Token 与 Tokenizer，BPE 与前缀词表
第二问考察的是数据链路最底层的东西。面试官问“Token 是什么”，如果你回答“Token 就是词语或者字”，只能算勉强及格。更准确的说法是：Token 是模型处理文本的最小单位，是 tokenizer 把原始文本切分后得到的编号序列。模型看到的从来不是字符串，而是词表里的整数 ID。
最常考察的算法是 BPE（Byte Pair Encoding，字节对编码）。它的核心流程是迭代地合并最高频的相邻字节对或字符对，直到达到预设词表大小。举个直观例子：语料里 constantly 和 constant 经常出现，BPE 会学出一个 token “const”，两个词都能拆成“const + antly”和“const + ant”，比整词存两个 token 更省空间，也比按字符切分更能保留语义单元。用这种统计方法，BPE 可以在“词级”和“字符级”之间找到平衡，既能压缩序列长度，又能处理未登录词。
这里有个中文场景的经典考点：中文不像英文天然有空格分词，单字信息密度高，所以用 BPE 或 SentencePiece 时，常用汉字可能单独成 token，常用词可能合并成双字 token。实际效果就是同样一段中文文本，token 数量往往比英文多 1.5 到 2 倍。这直接影响两个事情：一是上下文窗口能装多少内容，二是 API 计费成本。如果你面的是应用岗，能主动提到“我们在做长文档处理时得考虑中文 token 膨胀”，面试官会立刻对你另眼相看。
面试官还喜欢追问词表大小的选择。词表太小，每个 token 携带的信息量不足，序列会变长，计算量变大；词表太大，embedding 层和输出层的参数量会爆炸。现在主流模型词表大多在 32K 到 128K 之间。这里有个容易忽略的点：词表大小直接决定 embedding 矩阵参数。比如 128K 词表、4096 维隐藏层，光 embedding 就是约 5 亿参数，占总参数量比重不小。能说出这个数量级感，说明你真算过。
回答这题时最容易翻车的地方是什么？是把 tokenizer 理解成“分词工具”，忽略它和 BPE/SentencePiece 的算法细节，或者答不出来“未登录词怎么处理”。我见过有人很自信地说“没见过的词就随机给个 id”，这是错误的，BPE 会把单词拆成已知子词单元，最坏情况拆到字节级别，绝不会随机映射。
3. 训练三阶段与对齐：从“会说话”到“听人话”
3.1 第三问：预训练、SFT、RLHF/DPO，为什么要三连
这题考察的是你对 LLM 生产流程全链路的理解。先说结论：预训练解决“说什么”，SFT 解决“怎么说”，对齐解决“该不该说”。
预训练是拿海量语料做“下一个 token 预测”。模型的目标只是统计上更准确地猜下一个词，所以它的核心能力是语言能力、知识存储和世界建模。但这个阶段产出的模型并不好用，你问它问题，它大概率会以“作为一个语言模型”式的叙述继续编下去，而不是乖乖回答。
SFT（有监督微调）把模型从“续写机器”拉向“指令助手”。我们用大量人工编写的“指令-回答”对，让模型学会指令跟随、输出格式、语气语调。这个阶段本质上是教会模型模仿好的回答，但它只是模仿，缺少更细粒度的价值判断。比如面对“这个方案好不好”这类主观问题，SFT 数据里可能只有一种答案，模型并不知道为什么好。
RLHF（基于人类反馈的强化学习）或 DPO（直接偏好优化）解决的是“排序”问题。它不再要求模型输出唯一正确的答案，而是让模型知道，面对同一个问题，A 回答比 B 回答更符合人类的偏好。这个偏好可以是安全性、有帮助性、无害性，甚至可以是“更像我们公司想要的口吻”。RLHF 本质上是在给模型装一个价值标尺。
这里面有一个很常见的基础问题：SFT 和 RLHF 的数据有什么区别？答案是 SFT 数据是“单轮问答对”，模型学的是分布；RLHF 数据是“偏好对”，即同一个问题给多个不同质量的回答，标注员给它们排序。很多候选人会顺着说“所以 RLHF 数据更难标”，其实不完全是，SFT 的指令数据难在对“多样性”和“质量”同时有要求，偏好数据难在“一致性”和“尺度把握”，两者难点不同。
面试官特别喜欢顺水推舟问一句：“如果只在 SFT 上原地打转，不上 RLHF 会怎么样？”你可以答：模型大概率仍然是可用的，指令跟随也不错，但面对拒绝类、价值观冲突类、或者权衡性场景时，它缺少“宁可不说也不乱说”的判断力。所以对齐阶段不是可选项，而是安全上线的关键步骤。
3.2 PPO 与 DPO：为什么不能把二者混为一谈
这一小节是第三问最容易深挖的地方。如果你只说“用了 RLHF，PPO 是里面的策略梯度算法”，那面试官多半会追问细节。你需要至少建立起这么几个区分：RLHF 是一种框架，PPO 是强化学习算法，DPO 是对齐方法，三者的包含关系经常被面试者说反。
PPO 的实现涉及四个模型：策略模型、参考模型、奖励模型、价值模型。训练时，先让策略模型生成回答，奖励模型打分，然后用 PPO 优化策略，目标是让奖励分数尽量高，同时用 KL 散度惩罚策略模型偏离参考模型太远，防止它为了刷奖励而崩坏语言能力。也就是说，PPO 里“奖励模型”是一个显式的中间产物。它的优点是灵活、效果上限高，缺点是训练非常不稳定，超参数多，对显存和数据质量都很敏感。
DPO 的思路更聪明：它不显式训练奖励模型，而是直接用偏好对数据改写训练目标。核心论点是，在一个合理的约束下，最优策略和奖励函数之间存在一个闭式解，你不需要真的去拟合那个奖励函数，而是把这个闭式解代回优化目标里。于是，模型的训练目标变成了：给定偏好对“好回答 vs 坏回答”，让好回答的生成概率相对上升，坏回答的生成概率相对下降，同时控制对参考模型的偏离程度。这是一个非常简洁的优化目标，工程实现也简单很多，不需要在训练过程中跑奖励模型。
我记得有一次模拟面试，候选人说“DPO 就是把 RM 去掉了”，这个说法其实有点危险。DPO 确实不训练 RM，但它的数学推导里隐式地包含了一个奖励函数的最优形式，它只是“不显式建模”而已。你如果能答到“隐式奖励”这个层次，面试官基本不会再往下深挖了。如果还能补充一句“DPO 在偏好数据噪声较大时可能不如 PPO 稳健”，那说明你不只是背了论文标题。
还有个加分点，就是“奖励黑客”现象。奖励模型如果没设计好，策略模型能刷出高奖励但输出质量很差的例子。PPO 体系里这是经典难题，DPO 因为不依赖动态奖励信号，反而绕开了一部分这种风险。当然，DPO 也有自己的坑，比如偏好数据里 if 排序噪声大，模型会过度自信。这些都是可以展开聊的经验点。
3.3 数据标注：LLM 食物链的下游，也是面试里容易冷场的点
现在很多 LLM 招聘 JD 里会写“熟悉数据标注流程”，面试官也可能突然问“你了解 LLM 的数据标注吗”。这个问题的背后逻辑是：模型能力的天花板很大程度上取决于数据质量，尤其是对齐阶段，偏好数据的好坏直接决定模型“审美”是否在线。
预训练数据的标注重点在清洗，包括去重、去噪、过滤低质量内容、识别 PII（个人敏感信息）、语言识别。这一类工作更多是工程和数据管道问题，不太涉及人工评判。真正需要“人肉标注”的是 SFT 数据和偏好数据。SFT 数据要求高质量、高多样性，通常要有明确的写作规范，比如“回答必须基于已知事实”“不能使用不确定的语气描述医疗建议”。偏好数据则要求标注员对同一问题下的多个回答进行排序，核心难点是排序标准的一致性，不然两个人给出的偏好可能完全相反。
这里有个工程细节很重要：标注一致性通常用 Cohen‘s Kappa 或 Krippendorff’s Alpha 来衡量，比如两个标注员对同一批样本的排序完全一致，Kappa 是 1.0，随机乱标接近 0，一般要求达到 0.6 到 0.8 以上才算合格。达不到就说明标注指南太模糊，需要重新迭代指南而不是继续催标注员。
因为热搜词里出现了“llm 怎么数据标注”，我多说一句实际操作层面的心得：最有效的做法是先标 20 条“金标样”，由专家团队逐条写理由，再让标注员理解并练习。之后每名标注员正式标注前先测一批一致性，过了才能上岗。很多团队省掉这一环，结果模型训练出来的偏好倾向是噪声而不是用户真实偏好，上线后效果一塌糊涂。
4. RAG、幻觉与长上下文：应用层的三座大山
4.1 第四问：RAG 到底解决了什么问题，切片和召回怎么做
大模型上线后最现实的问题就是“信息不新鲜”“内部知识进不去”，RAG（检索增强生成）因此成了应用工程岗面试的钉子户。RAG 的核心思路是，不把所有知识塞进模型权重，而是在生成前先从外部知识库里检索相关内容，然后把检索结果拼进 prompt，让模型参考着回答。
RAG 的完整链路可以拆成四段：切分、向量化、召回、重排。先说切分，也就是 chunking。绝大多数做 RAG 的团队都会在这一步翻车。Chunk 太小，比如 128 token，语义上下文不完整，召回结果碎片化；Chunk 太大，比如 2000 token，虽然上下文完整，但相关性被稀释，检索颗粒度太粗，而且塞进 prompt 后浪费大量窗口。常见选择是 256 到 512 token，同时加 20 到 50 token 的 overlap 来保留上下文边界信息。面试官如果问“overlap 干什么用”，答案是让断在中间的语义尽可能保留下边界信息，比如一句话被切成两半时还有一半缓存在下一块里。
向量化就是把 chunk 转成 embedding，用向量距离做语义召回。这里有个经验点：embedding 模型的选择比很多人想象的重要。通用 embedding 在专业领域可能效果很差，如果预算允许，最好用小规模的领域数据微调一个 embedding 模型，或者直接用混合检索，也就是 BM25 关键词检索和向量检索并行，用一个简单的 RRF（倒数排名融合）合并结果。尤其对专有名词和编号类查询，BM25 经常比向量还准。
重排是很多候选人会漏掉的环节。初召回 50 条往往有噪声，需要用一个 rerank 模型对候选结果重新打分，取 top 5 进 prompt。刚做 RAG 的人最容易犯的错误是“召回 top 10 全部塞进去”，结果上下文里一半是无关内容，模型不知道该信谁。我通常的建议是：向量召回 20 到 50 条，重排后精选 3 到 5 条，效果比直接拿 top 5 向量结果好非常多。
淘汰答法也很常见——把 RAG 理解成“检索到文本，然后拼进 prompt”。如果真这么简单，一个字符串拼接就能搞定，哪还需要专门优化。RAG 的难点在于切分策略、检索质量、重排精度和生成策略的联动。你如果能主动说出“我遇到检索质量差，最后把 chunk 粒度调细了 + 切入混合检索才救回来”，面试官会对你产生强烈的共鸣感。
4.2 第五问：幻觉是 bug 还是特性，工程上怎么缓解
幻觉这事，面试官几乎必问，但绝大多数人答不到点上。先说根因，模型预训练的目标是“最大化下一个 token 的概率”，本质上是在做一种“根据前文推测最合理延续”的统计游戏，它对“事实正确性”并不敏感。也就是说，模型天生就会自动补全，它没有能力判断哪些是“它不知道的”，它只会继续编。因此，幻觉不是模型 bug，而是生成机制自带的一种“副作用”，严格说更像是一种不必要的过度自信生成。
面试时你能说出“幻觉是机制带来的结果，不是模型故意撒谎”，就已经比很多人强了。接下来要能展开工程缓解手段。从应用效果排序，第一梯队是 RAG：给模型提供事实依据，让它“有据可依”，减少凭空编造。第二梯队是生成策略：调低温度，比如从默认 0.7 降到 0.2，让采样更保守；或者用自一致性方法，让模型生成多个回答，投票或聚类得出最稳定的结果。第三梯队是提示约束：在 prompt 里明确写“如果不知道，请直接回答不知道”，或者要求答案附上引用来源，让模型在生成时被“要求举证”。
但这里必须说一句大实话：RAG 不能把幻觉降为零。检索结果本身可能不相关、可能过期、可能夹带噪声，模型在参差信息里反而会生成更离谱的答案。这也是为什么我说“评估”在面试里这么重要。你可以给面试官一个完整点的方案：引入答案的“可验证性”，比如让模型生成回答时同时输出参考段落 ID，工程侧再去校验这个 ID 是否真的能支持回答中的关键事实。这一套组合拳能挡住大部分低质量幻觉。
还有一个加分细节：幻觉可以分为“内在幻觉”和“外在幻觉”。内在幻觉指答案和上下文事实矛盾，外在幻觉指答案包含上下文没有的信息但对整体回答没有明显破坏。二者对系统的影响不一样。能做出这种粒度区分的人，说明是真的分析过线上 badcase 分布。
4.3 第六问：长上下文与 KV Cache，为什么处理 100 页文档那么贵
长上下文已经成了各家模型的主打卖点，128K 甚至 1M 窗口满天飞。但面试官要是问你“长上下文为什么贵”，千万别只回答“序列长了计算量大”。这只是冰山一角。真正的瓶颈有两层：注意力计算复杂度和 KV Cache 显存占用。
标准自注意力的复杂度是 O(n²)，n 是序列长度。序列从 4K 涨到 32K，计算量直接涨 64 倍，这是最朴素的昂贵原因。所以高效注意力方案一直在做“不计算完整注意力矩阵”或者“降低矩阵规模”这两件事。FlashAttention 的核心思想不是近似，而是分块计算，避免把完整的 N×N 注意力矩阵写进显存，把中间结果留在 SRAM 里融合，IO 量大幅下降。能答出“FlashAttention 主要省的是显存读写而不是浮点计算”，面试官会认为你读过相关工程实现，而不是只看了标题。
KV Cache 则是另一个大头。推理时模型是逐 token 生成的，每生成一个新 token，都需要用到历史 token 的 K 和 V。为避免重复计算，推理框架会把这些 K/V 缓存下来。KV Cache 的显存占用和序列长度、层数、头数、每个头的维度呈线性关系。举个例子，假设 70B 模型有 80 层、80 个注意力头、头维度 128，半精度（每参数 2 字节），KV Cache 每个 token 的占用量是 80×80×128×2，约 1.6MB。处理 32K 长度，KV Cache 要 50GB 以上。这个数字一算出来，你就明白为什么长窗口推理经常“卡”在显存上而不是算力上。
PagedAttention 是 vLLM 里用的一种优化，思路是像操作系统管理内存分页一样管理 KV Cache，把连续的逻辑缓存分散到不连续的物理显存块里，从而显著减少显存碎片浪费，提高批处理吞吐。能讲到这里，已经超出大多数候选人的知识储备了。
我把第 4、5、6 题放在一个小节下，是因为它们在面试里经常被连环追问：先问长上下文瓶颈，再问 KV Cache，然后问“那长上下文能不能减少 RAG 的需求”，最后又绕回幻觉。如果你想用长上下文替代 RAG，你需要说明为什么不行——长上下文不等于高质量检索，模型对一万个 token 里埋在中间的那个关键信息并不敏感，注意力会被稀释，这在业内叫“lost in the middle”。这个细节说出来，整道题的层次就上去了。
5. 从微调到 Agent：工程与模型的交汇
5.1 第七问：提示工程、RAG、微调怎么选，LoRA 的原理是什么
这题是应用岗面试的高频关卡，也是最能拉开差距的地方。候选人最常见的错误是“遇到需求就微调”，一开口就是“行，我们微调一下模型”。实际上，微调是成本最高的方案，并且一旦模型版本升级，之前的微调工作可能全部作废。
我的决策顺序基本是：先提示工程，再上 RAG，最后才考虑微调。提示工程成本最低，改一段 prompt 就能上线，适合意图明确、规则性强的任务；RAG 适合知识密集型任务，比如企业知识库问答、客服辅助，它的优势是知识实时更新、可追溯来源；微调适合以下场景：一是输出格式高度固定，比如要把文书规范成特定 JSON 结构，二是领域术语和表达方式极其特殊，比如你看不懂的行业黑话，三是希望模型具备某种难以通过 prompt 描述的行为风格。
接下来 LoRA 就是必须讲清楚的细节。LoRA 的原理是冻结原模型权重，只在注意力层的权重矩阵旁边注入一个低秩矩阵。具体来说，把权重更新量 ΔW 近似分解成两个小矩阵 A×B 的乘积，A 和 B 的秩远小于原矩阵的维度。训练时只更新 A、B，原权重不动。这样需要训练的参数量大幅下降，70B 模型也可以在一两张消费级显卡上用低精度跑微调。QLoRA 更进一步，先把模型量化到 4bit，再插入 LoRA 适配器，显存占用比全参微调小一个数量级。rank 通常取 8 到 64，rank 越大，适配能力越强，但过拟合风险也越高。
面试官另一个高频追问是“LoRA 和全参微调效果差距大不大？”不少论文说在数据量不太大的情况下差距很小，但我的实际经验是，领域语言风格差异特别大时，LoRA 可能不够，得加上合适的 data 增强，甚至考虑全参微调一小段。面试里你可以补充一句“还需要看任务类型，分类生成类任务 LoRA 表现不错，但如果要求模型学会全新的长文本写作风格，效果会打折扣”，这比单纯背结论更有说服力。
5.2 第八问：Function Calling 与 Agent，如何让模型学会“办事”
Agent 已经成了 LLM 应用最热的方向，所以第八问几乎必考。面试官想看你是否理解“模型不是直接执行动作，而是决定调用哪个工具、传入什么参数”。这里的设计核心是 Function Calling。
它的操作并不复杂：定义一批工具，每个工具有名称、描述、参数 JSON Schema，然后把这些定义放进 prompt 送入模型。模型推理后输出一个结构化的调用请求，比如{"name": "search_product", "arguments": "{\"keyword\": \"xxx\"}"}，然后由程序执行这个函数，再把执行结果喂回模型继续生成。这就是一个最简 Agent 循环。
往深了说，就是 ReAct 模式：Thought（思考需要做什么）→ Action（调用工具）→ Observation（观察工具返回结果），循环直到给出最终答案。面试时如果面试官让你现场设计一个 Agent，你最好先定义清楚工具边界，因为工具太多或太模糊，模型会频繁调用错误工具。通常一个 Agent 的工具数量控制在 5 到 10 个比较合适，每个工具描述要写清楚“何时用、何时不用”，这是比模型能力更影响成功率的地方。
这里有一个价值很高的经验：工具调用的参数幻觉。模型可能调用搜索工具时生成一个不存在的商品 ID，或者把单位从“厘米”写成“米”。你以为模型理解了,其实它只是按概率在吐字符串。所以 Agent 系统里必须加“工具调用校验层”，比如枚举参数、类型校验、范围校验，甚至用一个小模型对参数做二次修正。面试时你加上这句话，面试官大概率会追问“你怎么做校验”，这就是你展示工程经验的机会。
Agent 还有一个绕不开的问题是评估。不能只看“任务最终完成率”，还要看“每一步是否过度调用工具”“是否绕了远路”“是否在工具失败时有兜底话术”。我建议按“任务成功率、平均步数、无效调用比例、错误回复率”四个指标构建评估集，每个指标都对应到一个明显的优化方向。如果一个 Agent 平均步数从 6 降到 4，但成功率没变，说明工具路由更准了。
6. 评估与收尾：把散落的考点串成一套答题体系
6.1 评估指标：BLEU/ROUGE 为什么不够用，LLM-as-Judge 有哪些坑
很多候选人在聊评估时只会说“人工看效果”“跑一下就知道了”，这在面试里几乎等于裸奔。系统化评估是 LLM 岗位的基本功，至少要知道三层。
第一层是传统指标，BLEU、ROUGE、METEOR。它们都是基于 n-gram 重叠计算的，适合机器翻译和摘要这种“参考答案接近”的场景。但开放生成任务的合法答案可能千差万别，一个短句改写就能让 BLEU 骤降，可人类评分不变。所以对 LLM 来说，这些指标已经不能作为主要评估手段，只能当作回归测试时的参考。
第二层是 PPL（困惑度）。预训练阶段衡量模型对语料建模的好坏，越低越好。但 PPL 低不等于生成质量高，它更偏向词汇概率分布，和“帮助性”“流畅性”“安全性”这些体感维度关系不大。面试时如果有人拿 PPL 当生成质量指标，通常会被追问到哑口无言。
第三层才是现在的核心：人工评估和 LLM-as-Judge。人工评估是当前最可靠的，但贵且慢。LLM-as-Judge 用 GPT-4 或自家模型当裁判，对回答打分。它的问题是存在多种偏差，比如“位置偏差”：裁判模型在比较两个回答时倾向于选排在前面的；还有“长度偏差”：长的回答经常被误以为信息更多；“自夸偏差”：裁判模型（尤其是 GPT 系列）倾向于给自己的输出更高分。缓解手段包括把两段回答随机交换位置多测几次、要求裁判先写理由再打分、多裁判投票，以及定期用人工校准样本监督裁判模型的打分稳定性。
一个合格的评估体系需要有分层结构：通用能力层（指令遵循、事实性、推理、安全性）+ 业务场景层（领域问答、工具调用、长文档摘要）+ 回归回归层（过去 badcase 是否复发）。能把这个体系结构讲清楚，面试官会更确信你有过真实项目经历。
6.2 自查清单：面试前最后一页的“八问速查表”
把上面 8 个问题的关键点整理成一张速查表，方便你在面试前十分钟扫一眼。
| 问题 | 关键关键词 | 进阶关键词 |
|---|---|---|
| Transformer | QKV、缩放因子、多头、残差、LayerNorm | Decoder-only、因果掩码 |
| Tokenizer | BPE、词表大小、未登录词 | 中文 token 膨胀、SentencePiece |
| 训练三阶段 | 预训练、SFT、RLHF | 目标差异、数据差异、DPO |
| RAG | 切分、向量化、召回、重排 | overlap、混合检索、RRF、rerank |
| 幻觉 | 机制性生成、知识截断 | 内在/外在幻觉、自一致性、引用校验 |
| 长上下文 | O(n²)、KV Cache、FlashAttention | PagedAttention、lost in the middle |
| 微调选型 | 提示工程 → RAG → 微调 | LoRA rank、QLoRA 4bit、成本对比 |
| Agent | Function Calling、ReAct 循环 | 工具边界、参数校验、评估指标 |
这 8 题看起来多，但它们的底层逻辑是一致的：模型能力是下限，数据和工程手段是上限。面试官通过这些问题，想确认的不外乎是你能不能“在真实系统里把一个 LLM 功能稳定跑起来”。所以我建议你在准备时不只背答案，而是每道题找一个小项目亲手验证一遍，哪怕只是一个 7B 模型跑 RAG，或者用现成框架跑一次 LoRA，记忆都会牢固得多。
最后再分享一个我自己面试别人时的个人体会：回答得“不太完美但思路在线”，远比“背得流利但经不起追问”更让我愿意给机会。你如果遇到不会的问题，不要愣住，尝试把思考路径讲出来，比如“我不确定这个细节，但根据我的理解应该是这样……”，面试官反而会觉得你有解决未知问题的潜力。面试是交流，不是审讯，放松把你知道的东西说清楚，这 8 个问题就没有那么可怕。
