1. 大模型岗位面试的真实筛选逻辑
面大模型方向的岗位，不管是算法、应用还是工程，面试官手里通常都有一套“硬门槛”问题。这套问题不是为了考你背了多少论文，而是快速判断三件事：你懂不懂底层原理、有没有真正跑过模型、遇到问题能不能自己定位。标题里说的“答不上来直接淘汰”，听起来夸张，但实际面试中确实存在几个关键问题，一旦回答得含糊，面试官基本会在心里给你打上“没实操过”的标签。
我参与过不少场大模型岗位的面试，也帮朋友做过模拟面。一个很明显的感受是：候选人之间的差距，往往不在“知不知道 Transformer”，而在“能不能把 Transformer 里的某个细节讲清楚，并且说清楚它为什么影响训练和推理”。比如同样问注意力机制，有人只能背出公式，有人能讲出为什么要除以根号 d_k、为什么用多头、为什么位置编码要那样设计。后者才是面试官想聊下去的人。
这篇文章围绕 LLM 面试中最常被追问的 8 个方向展开，包括 Transformer 结构、Tokenization、注意力计算、位置编码、训练与推理差异、Function Calling、模型评估以及工程落地中的常见坑。每个问题我都会按“面试官想听什么、你应该怎么答、答错会怎样”三个层次来拆。适合准备大模型算法岗、应用岗、Agent 开发岗的读者，也适合已经入行但想系统梳理知识体系的朋友。
需要提前说明的是，不同公司、不同岗位的侧重点不一样。做训练的人会被追问分布式和显存优化，做应用的人会被追问 Function Calling 和上下文管理，做 Agent 的人会被追问工具调用和容错。但下面这 8 个问题，基本覆盖了所有方向都会碰到的核心点。
2. 问题一：Transformer 为什么能取代 RNN
2.1 面试官真正想听的不是“并行计算”
很多人一被问到这个问题，第一反应就是“因为 Transformer 可以并行，RNN 必须串行”。这个答案不算错，但太浅了。面试官如果继续追问“那并行带来的代价是什么”，很多人就卡住了。
更完整的回答应该包含三层。第一层是计算模式：RNN 的隐藏状态依赖前一个时间步，天然无法并行；Transformer 用自注意力把任意两个位置直接连起来，训练时可以一次性算完整个序列。第二层是长距离依赖：RNN 在长序列上容易出现梯度消失或梯度爆炸，信息要经过很多步才能从位置 1 传到位置 100；Transformer 里任意两个位置的距离都是 1，路径更短。第三层是代价：自注意力的计算复杂度是 O(n²)，序列越长显存和计算量增长越快，这也是后来各种稀疏注意力、滑动窗口注意力出现的原因。
我一般会这样组织回答：先说 RNN 的串行瓶颈和长依赖问题，再说 Transformer 用注意力换并行和短路径，最后补一句“但这不是免费的，O(n²) 的复杂度在长文本场景下就是主要矛盾”。这样回答，面试官会觉得你不仅知道结论，还知道边界。
2.2 自注意力的计算过程要能手推
面试里经常让你在白板上写自注意力的计算步骤。标准流程是：输入序列经过三个线性变换得到 Q、K、V；用 Q 和 K 的转置做点积得到注意力分数；除以根号 d_k 做缩放；过 softmax 得到权重；最后用权重对 V 加权求和。
这里有几个细节容易被追问。第一，为什么要除以根号 d_k？因为 Q 和 K 的每个元素如果独立同分布、均值为 0、方差为 1，那么点积结果的方差会变成 d_k，维度越高点积值越大，softmax 之后会变得非常尖锐，梯度会很小。除以根号 d_k 就是把方差拉回 1 附近，让训练更稳定。第二，为什么要多头？单个注意力头只能学到一种关注模式，多头相当于让模型在不同子空间里分别关注不同关系，比如有的头关注语法依赖，有的头关注指代关系。第三，Q、K、V 分别代表什么？可以通俗理解为：Q 是“我在找什么”，K 是“我有什么标签”，V 是“我实际携带的信息”。
注意：面试时不要只背公式，最好能结合一个具体例子说明。比如“它”这个词在句子里要找指代对象，Q 就是“它”的查询向量，K 是前面每个词的标签向量，点积越大说明越可能是指代对象。
2.3 常见追问与避坑
面试官常追问的一个问题是：“既然自注意力这么强，为什么还要前馈网络？”答案是：自注意力本质上是线性加权求和，虽然有多头，但整体还是线性操作，表达能力有限。前馈网络引入非线性激活，让模型能拟合更复杂的函数。另一个追问是：“LayerNorm 放在前面还是后面有什么区别？”Pre-LN 训练更稳定，Post-LN 在原始 Transformer 里用得多，但深层网络容易不稳定。现在主流大模型基本都用 Pre-LN 或 RMSNorm。
踩过的坑：有人会把“并行”说成“Transformer 比 RNN 快”。这不准确。训练时 Transformer 确实更容易并行，但推理时自回归生成仍然是一个 token 一个 token 往外吐，并不比 RNN 快多少。面试官如果听到这种绝对化表述，可能会继续追问推理优化，比如 KV Cache，这时候要能接得住。
3. 问题二：Tokenization 到底在做什么
3.1 从“分词”到“子词”的演进逻辑
Tokenization 是很多人容易忽略的一环，但面试官很爱问，因为它直接关系到模型能不能处理未登录词、多语言和代码。最早的分词是按空格或标点切，词表爆炸且无法处理新词。后来出现字符级分词，词表小但序列太长。现在主流是子词分词，代表方法有 BPE、WordPiece 和 SentencePiece。
BPE 的思路是：从字符开始，不断把出现频率最高的相邻字符对合并成新的子词，直到达到目标词表大小。WordPiece 类似，但合并标准是似然增益而不是频率。SentencePiece 则把空格也当作普通字符处理，不依赖预分词，适合中文、日文等没有天然空格分隔的语言。
面试官想听的是：你为什么选这种分词方式？比如中文场景下，按字分词会导致序列过长，按词分词又受分词工具影响，子词分词能在词表大小和序列长度之间取得平衡。代码场景下，BPE 能把常见标识符拆成有意义的子词，比如getUserName可能被拆成get、User、Name，这样模型能学到组合规律。
3.2 词表大小与序列长度的权衡
词表大小是一个需要计算的参数。词表越大，每个 token 携带的信息越多，序列越短，但嵌入矩阵和输出层参数越多，softmax 计算量越大。词表越小，序列越长，注意力计算的 O(n²) 代价越高。常见大模型的词表在 3 万到 15 万之间，比如很多中文场景会用 5 万到 10 万的词表。
我实际做项目时，会先统计语料的字符分布和词频，然后跑几个不同词表大小的 BPE 训练，看压缩率。压缩率就是原始字符数除以 token 数，压缩率越高说明同样文本占用的 token 越少。但也不能只看压缩率，还要看下游任务效果。有时候压缩率高了，但罕见词被拆得太碎，反而影响语义。
提示：面试时如果被问到“中文分词用什么”，不要只说“用 jieba”。大模型时代更常见的答案是“用 SentencePiece 或 BPE 训练子词词表”，因为这样不依赖外部分词工具，且能统一处理多语言。
3.3 特殊 token 的作用
除了普通子词，词表里还有一批特殊 token，比如[CLS]、[SEP]、[PAD]、[UNK]、[BOS]、[EOS]。它们各自有明确用途：[CLS]在 BERT 里用于句子级分类，[SEP]分隔句子，[PAD]补齐批次长度，[UNK]表示未登录词，[BOS]和[EOS]标记生成开始和结束。
面试官可能会问：“如果[UNK]太多怎么办？”这说明词表覆盖不够，可以考虑扩大词表、换分词方法，或者在预处理时做归一化，比如统一大小写、处理特殊符号。另一个常见问题是：“为什么生成模型有时会重复输出？”可能和[EOS]学习不好有关，也可能和训练数据里的重复模式有关。
4. 问题三：位置编码为什么不能省
4.1 自注意力本身没有顺序概念
自注意力计算的是任意两个位置的相关性，如果把输入序列打乱，只要 Q、K、V 对应关系也打乱，注意力分数矩阵只是行列重排，模型本身感知不到顺序。所以必须显式注入位置信息，否则“猫追狗”和“狗追猫”在模型眼里可能是一样的。
最早的位置编码是正弦余弦函数，用不同频率的三角函数生成固定向量，直接加到词嵌入上。它的好处是不需要训练、可以外推到比训练更长的序列。后来出现可学习的位置嵌入，把位置当成词表里的 token 来学，效果在固定长度任务上不错，但外推能力差。现在主流大模型多用 RoPE 旋转位置编码，它通过旋转矩阵把位置信息编码进 Q 和 K 的点积里，既保留了相对位置关系，又有一定外推能力。
4.2 RoPE 的核心思想与面试答法
RoPE 的直观理解是：把每个位置的向量看成复数平面上的点，根据位置旋转一个角度。两个位置做点积时，结果只和它们的相对距离有关，和绝对位置无关。这样模型学到的就是相对位置关系，而不是死记某个绝对位置。
面试时如果被问到 RoPE，可以这样答：先讲绝对位置编码的局限，再讲相对位置编码的优势，然后说 RoPE 通过旋转操作把相对位置注入注意力计算，最后补一句“RoPE 的外推能力也不是无限的，超过训练长度太多仍然会退化，所以才有 NTK 插值、YaRN 这些扩展方法”。这样回答层次清楚，也显示你关注过后续进展。
4.3 长度外推的常见方案
实际部署中，训练长度往往小于推理长度。比如训练时用 4K 上下文，推理时想支持 32K，直接上会崩。常见方案有位置插值，把超出范围的位置映射回训练范围内；有 NTK-aware 插值，调整旋转频率的基数；还有 YaRN，结合频率缩放和注意力温度调整。这些方法的核心思路都是让模型在没见过的长度上仍然保持相对位置关系合理。
注意：面试时不要把这些方法说得太绝对。不同模型、不同数据分布下效果差异很大，最好说“常见做法是……具体选哪种要看评测结果”。
5. 问题四：训练和推理到底差在哪
5.1 训练时的并行与推理时的自回归
训练时，模型看到完整序列，可以一次性计算所有位置的注意力，用 teacher forcing 让每个位置预测下一个 token。推理时，模型只能一个 token 一个 token 生成，每生成一个新 token，都要把它拼到输入后面重新计算。如果每次都重算整个序列，计算量会非常大。
这就是 KV Cache 要解决的问题。KV Cache 把之前所有位置的 K 和 V 缓存下来，生成新 token 时只需要计算当前 token 的 Q、K、V，然后和缓存的 K、V 做注意力。这样每步计算量从 O(n²) 降到 O(n)，显存占用则随序列长度线性增长。
面试官常问：“KV Cache 占多少显存？”可以这样估算：假设层数 L、头数 H、头维度 d、序列长度 n、批次大小 b、精度 2 字节，那么 KV Cache 大小约为 2 × L × H × d × n × b × 2 字节。比如 L=32、H=32、d=128、n=4096、b=1，大约是 2 × 32 × 32 × 128 × 4096 × 2 字节，约 2GB。这个估算在面试里很加分。
5.2 显存都花在哪了
训练显存主要花在四块：模型参数、梯度、优化器状态、激活值。以 Adam 为例，每个参数需要保存一份参数、一份梯度、两份优化器状态，混合精度训练还要额外保存一份 FP32 主权重。粗略估算，全量微调时每 10 亿参数大约需要 16 到 20GB 显存。推理显存主要是模型参数和 KV Cache，量化后模型参数可以压到 4bit 甚至更低。
面试官如果问“怎么降低显存”，可以从几个方向答：量化、梯度检查点、LoRA 等参数高效微调、ZeRO 分布式优化、FlashAttention 减少注意力中间激活。每个方向都能展开聊，但不要一次性全倒出来，挑你最熟的讲深。
5.3 常见追问：为什么训练 loss 下降但推理效果差
这是典型的过拟合或数据泄露问题。可能原因包括：训练集和验证集分布不一致、数据里有重复样本、评估指标和业务目标不匹配、解码策略不合适。我遇到过一种情况是训练数据里问题和答案在同一个样本里挨得太近，模型学会了“抄答案”，推理时没有这个条件就崩了。排查时要先看数据，再看评估，最后才怀疑模型结构。
6. 问题五：Function Calling 是怎么实现的
6.1 从提示词到结构化输出
Function Calling 的本质是让模型输出结构化的工具调用请求，而不是自由文本。早期做法是在提示词里描述工具列表和输出格式，让模型按格式生成 JSON。但这种方式不稳定，模型可能输出多余文字、格式错误、参数缺失。后来模型厂商在训练阶段加入工具调用数据，让模型原生支持结构化输出。
典型流程是：用户提问，模型判断是否需要调用工具；如果需要，输出工具名和参数；系统执行工具，把结果返回给模型；模型结合结果生成最终回答。面试官想听的是你对这个链路的理解，以及异常情况怎么处理。
6.2 参数校验与容错设计
实际工程里，模型输出的参数不一定合法。比如工具要求date是YYYY-MM-DD格式，模型可能输出2024年1月1日。所以必须有参数校验层，做类型检查、格式转换、范围限制。如果校验失败，可以把错误信息返回给模型，让它重新生成，但要有重试次数上限，避免死循环。
另一个坑是工具描述写得太模糊。比如一个查询天气的工具，描述只写“查询天气”，模型可能不知道该传城市名还是城市代码。好的工具描述应该包含功能说明、参数含义、格式要求、示例。我一般会写清楚“city 参数传城市中文名，如‘北京’”，这样模型调用准确率会高很多。
6.3 多工具选择与并行调用
当工具有几十个时，模型可能选错工具。常见优化是给工具分组、加标签、在提示词里做粗筛。比如先让模型判断问题属于“查询类”还是“操作类”，再在对应组里选具体工具。并行调用则是模型一次输出多个工具调用请求，系统并发执行后合并结果。这要求模型能判断哪些调用之间没有依赖关系。
提示：面试时如果被问到“Function Calling 和 Agent 的关系”，可以说 Function Calling 是 Agent 的基础能力之一，Agent 还需要规划、记忆、反思等模块。不要把两者混为一谈。
7. 问题六：怎么评估一个大模型的好坏
7.1 自动指标与人工评估的取舍
自动指标常见的有困惑度、BLEU、ROUGE、BERTScore。困惑度衡量模型对文本的预测能力，越低越好，但它和生成质量不是线性关系。BLEU、ROUGE 基于 n-gram 重叠，适合翻译和摘要，但对开放式生成不敏感。BERTScore 用嵌入相似度，比 n-gram 更语义化，但计算成本高。
实际业务里，人工评估往往更可靠。可以设计评分维度，比如相关性、流畅性、事实准确性、安全性，每个维度 1 到 5 分，让标注人员盲评。为了降低成本，可以先用自动指标粗筛，再对关键样本人工精评。
7.2 领域评测集的构建
公开评测集如 MMLU、GSM8K、HumanEval 能反映通用能力，但和具体业务差距很大。我通常会从真实业务日志里采样，构建领域评测集。构建时要注意：问题要有代表性，答案要有唯一标准或明确评分规则，难度要分层。比如简单、中等、困难各占三分之一，这样能看出模型在不同难度下的表现。
面试官可能会问：“如果模型在公开评测集上分数很高，但业务效果差，怎么办？”答案通常是评测集和业务分布不匹配，需要重新构建评测集，或者检查数据泄露。也有可能是解码参数没调好，比如温度、top_p 设置不适合业务场景。
7.3 评估中的常见陷阱
第一个陷阱是数据泄露。训练数据里如果有评测集的原题，分数会虚高。第二个陷阱是评测集太小，方差大，换个随机种子结果就变。第三个陷阱是只看平均分，不看分布。比如模型在简单题上全对，难题上全错，平均分可能还行，但实际不可用。第四个陷阱是忽略推理成本，一个模型效果好但延迟高、价格贵，业务上未必划算。
8. 问题七：大模型工程落地有哪些坑
8.1 上下文管理与截断策略
大模型上下文有限，超出长度就要截断。常见策略有：保留系统提示和最近几轮对话，丢弃中间轮次；对历史对话做摘要，把摘要拼到提示里；用向量检索召回相关片段，而不是全量塞入。每种策略都有代价：截断可能丢信息，摘要可能失真，检索可能召回不相关的内容。
我实际做对话系统时，会先统计用户问题的平均轮次和 token 数，再决定策略。如果平均只有三五轮，直接保留全部；如果经常几十轮，就上摘要加检索。面试时如果能说出“先看数据分布再选策略”，会比直接说“用滑动窗口”更有说服力。
8.2 输出稳定性与格式控制
大模型输出不稳定是工程上的大麻烦。同样的输入，温度稍高一点，输出格式就变了。解决办法包括：降低温度、用 JSON Schema 约束输出、在提示词里给 few-shot 示例、后处理做格式修复。如果业务要求严格结构化，最好用支持结构化输出的接口，而不是靠提示词硬约束。
另一个坑是模型会“编造”不存在的字段。比如要求输出{"name": ..., "age": ...}，模型可能输出{"name": ..., "age": ..., "address": ...}。后处理时要严格按 schema 过滤，多余字段直接丢弃，缺失字段报错重试。
8.3 成本与延迟优化
成本主要来自 token 数和调用次数。优化方向有：压缩提示词、缓存常见问题的回答、用小模型做路由、对简单问题用规则处理。延迟优化包括：流式输出、批处理、KV Cache 复用、量化推理。实际项目里，我一般会先做一轮成本分析，看钱花在输入还是输出，再针对性优化。
注意：不要为了省钱牺牲效果。有些场景下，多花一点 token 换更准确的回答是值得的。面试时如果被问到“怎么降成本”，最好先问清楚业务对效果的容忍度。
9. 问题八：Agent 场景下的容错与可靠性
9.1 Agent 和普通对话的区别
普通对话是一问一答，Agent 需要多步规划、调用工具、根据结果调整策略。这就引入了新的失败模式：规划错误、工具调用失败、工具返回结果不符合预期、多步之后偏离目标。面试官问 Agent 容错，其实是在问你怎么设计一个“不会轻易崩”的系统。
常见设计包括：每一步都有校验，工具调用失败时重试或降级；设置最大步数，防止无限循环；关键步骤要求模型输出思考过程，便于排查；对高风险操作加人工确认。我做过的一个项目里，Agent 需要查询数据库并生成报告，我们加了“查询结果为空时不要编造，直接返回未找到”，效果立竿见影。
9.2 记忆与知识注入的边界
Agent 通常有短期记忆和长期记忆。短期记忆是当前对话上下文，长期记忆可以是向量数据库或结构化知识库。注入知识时要注意：检索到的内容可能过时、可能冲突、可能不相关。所以要有相关性打分和冲突检测。如果检索结果置信度低，宁可让模型说“我不确定”，也不要强行回答。
面试时如果被问到“怎么防止 Agent 被误导”，可以从数据源可信度、检索相关性阈值、输出前的事实校验三个层面答。不要只说“加提示词让模型小心”，那太单薄。
9.3 可观测性与日志设计
Agent 系统一定要有完善的日志。每次工具调用要记录输入、输出、耗时、状态；每次模型生成要记录提示词、输出、token 数；每个决策点要记录候选方案和选择理由。这样出问题时才能回放整个链路。我见过不少团队只记录最终回答，结果排查时完全不知道中间发生了什么。
日志设计还要考虑隐私和成本。敏感信息要脱敏，日志量太大要采样。面试时如果能提到“日志要能支撑回放和归因”，会显得你有工程思维。
10. 面试中的表达技巧与心态
10.1 不会的问题怎么答
面试中遇到不会的问题很正常。关键是不要瞎编，也不要直接说“不知道”。可以这样处理：先复述问题，确认理解无误；然后说“这个点我了解得不够深，但我可以从相关角度推测”；接着给出你的推理过程；最后补一句“如果是我做，我会先查文档或做实验验证”。这样即使答案不对，面试官也能看到你的思路。
我见过一些候选人，遇到不会的问题就沉默，或者强行扯到别的话题。这两种都很减分。更好的做法是展示你的学习能力和解决问题的路径。
10.2 项目经历怎么讲
讲项目时，不要只讲“我用了什么模型”，要讲“我遇到了什么问题、为什么选这个方案、效果如何、踩了什么坑”。比如“我们一开始用全量微调，显存不够，后来换成 LoRA，显存降到 1/4，效果只掉了 1 个点”。这种有对比、有数据的描述，比堆技术名词有说服力。
面试官如果追问细节，要能说出具体参数和实验过程。比如“LoRA 的 rank 我们试了 4、8、16，最后选 8，因为 16 提升不明显但显存多花 20%”。这种细节能证明你真的做过。
10.3 反问环节问什么
反问环节是展示你关注点的机会。可以问团队目前主要做什么方向、模型训练和推理的规模、评估体系怎么建、工程上最大的挑战是什么。不要一上来就问薪资和加班，那可以留到 HR 面。好的反问能让面试官觉得你对岗位有思考，而不是随便投的。
11. 最后的经验分享
准备大模型面试，背八股文只能解决一部分问题。真正拉开差距的是你有没有亲手跑过模型、调过参数、排查过问题。我建议至少做一遍完整流程：用开源模型做一次微调，部署一次推理服务，接一次 Function Calling，搭一个简单 Agent。过程中遇到的报错、显存不足、输出不稳定，都是面试时的真实素材。
另外，面试前可以针对目标岗位做定向准备。做训练的，重点看分布式、显存优化、数据配比；做应用的，重点看提示工程、Function Calling、评估；做 Agent 的，重点看规划、工具调用、容错。不要试图把所有方向都背一遍，那样反而容易在深度上露怯。
最后分享一个小技巧：面试时如果被问到开放性问题，可以先说“我分几个层面来看”，然后一层一层展开。这样既给自己争取了思考时间，也让回答显得有条理。面试官通常更在意你的思考过程，而不是标准答案。
