★ FEATURED ARTICLE 最近半年陆陆续续面了几百个做大模型方向的候选人从刚毕业的校招生到手里一堆AB刊的资深工程师都有。一个很直观的感受简历上写得天花乱坠项目里全是套壳应用但问到原理层面就漏气的人占比相当高。LLM 面试其实从来不考什么偏题怪题面试官真正想看的是你对整套技术栈有没有建立起自己的理解体系——从词表怎么切到注意力怎么算到推理为什么吃显存到 Agent 为什么需要记忆这本来就是一条完整的链路。下面这 8 个问题是我个人的高频题目基本覆盖了 LLM 从训练到落地的核心环节。答不上来的人我确实会直接淘汰这不是残酷是这个岗位的基本门槛。1. 第1问Transformer的自注意力机制面试官在等你说出哪几个词1.1 为什么第一问永远是注意力我不在乎你能不能默写出 Attention Is All You Need 的公式我真正想听的是你有没有从直觉上理解它。几乎所有人都会写softmax(QK^T / sqrt(d_k))V但能讲清楚“除以根号 d_k 到底在解决什么问题”的人十个里面不超过三个。注意力机制的本质是让序列里的每个 token 去“看”其他所有 token然后决定从谁那里收集信息、收集多少。它不是搜索不是匹配而是一种加权求和。你可以把它想成开班会每个人发言之前先听别人说什么谁跟我的问题相关我就多听一点谁跟我没关系我就少听一点听完一圈之后综合所有人的观点再形成自己的结论。1.2 一个能拿高分的回答骨架我建议的回答路径是先讲目标再讲公式最后讲设计理由目标让每个位置能动态关注序列内其他位置从而捕捉长距离依赖解决 RNN 无法并行和长序列遗忘的问题。计算流程输入经过三个线性投影得到 Q、K、V用 Q 和 K 算相似度scale 后过 softmax 得到权重再对 V 做加权求和。为什么除以 sqrt(d_k)Q 和 K 的维度变大后点积的方差会变大softmax 会进入饱和区梯度趋近于零。除以 sqrt(d_k) 可以把点积方差拉回 1 附近让 softmax 保持有区分度。多头的意义每个头从不同子空间去建模关系有的头关注相邻词有的头关注语法结构有的头关注长距离语义。它们不是冗余是并行地看问题的不同角度。如果顺着这个骨架往下讲不需要背论文面试官已经能判断你是真懂还是背稿。1.3 追问链复杂度、多头、FlashAttention这里我必然会往下追一个问题自注意力的时间复杂度是多少如果只说 O(n²) 还不够我会追加问n 指什么回答“n 是序列长度因为 QK^T 要算所有 token 两两点积KV 也要存储”就能过及格线。再往下我会问工程化的问题序列变长之后怎么扛这里答“稀疏注意力、窗口注意力、FlashAttention”任一个都能加分。FlashAttention 的原理如果答上来是很大的亮点它不计算完整的注意力矩阵而是按分块的方式重算归一化统计量配合 kernel fusion把访问 HBM 的次数从 O(n²) 降到接近 O(n) 的量级。这个过程不用把整个矩阵存下来所以显存占用也大幅下降属于“用计算换显存”的典型。我的建议是 Q、K、V 的维度换算要会算多头前后拼接的逻辑要清楚head_dim 和头数的乘积为什么等于 hidden_size 也要讲明白。这题是热身题答得越稳后面越有信心。2. 为什么同一个“苹果”在不同模型里被切成三截Tokenization里的门道2.1 面试官用这道题考察什么很多候选人把 Tokenization 当成黑盒子这是大忌。tokenizer.encode和tokenizer.decode只要用错过一次就能体会到什么叫“差一个字符引发的灾难”。Tokenization 决定了训练语料的颗粒度、词表大小、序列长度进而决定了算力和显存的规划它根本不是小事。我面试时喜欢拿“我爱你”举例同一个句子在 GPT 系字节级 BPE 词表里可能被切成三个 token在中文原生 tokenizer 里可能被切成一整个 token在更极端的压缩词表里可能有不同的切法。这不是脑筋急转弯而是让你明白 token 不是“词”它是一段子词subword序列。2.2 BPE的合并逻辑BPE 的基本逻辑是先按字节或单字符初始化词表然后反复统计语料中相邻符号对的频次把最高频的组合合并成一个新符号直到词表达到目标大小。你可以理解为先拆到最小零件再根据共现频率把经常一起出现的零件焊成更大的零件。这个机制决定了两个特性一是未登录词可以被拆成字节级子词所以理论上没有真正的“OOV”二是词表大小和序列长度之间存在权衡——词表越大平均 token 长度越短但 embedding 矩阵也越大训练和推理的显存开销都会上升。2.3 中文编码的两个大坑坑一中文在字节级 BPE 下经常会被拆成多个字节 token如果词表不够包括常见中文字符一段中文文本的 token 数会比英文膨胀不少直接拉高推理成本。坑二使用模型时 tokenizer 和模型权重不匹配。有人拿 LLaMA 的 tokenizer 加载一个重训词表的中文模型结果生成出来全是乱码。这类事故在开源社区反复出现原因就是词表变了但有人没意识到。另一个细节是特殊 token 的处理bos、eos、pad、unk在训练和推理时必须语义一致。曾经有团队在合成数据里漏掉了eos导致模型生成永远不知道什么时候该停推理时不设max_new_tokens就可能无限写下去。这种 bug 排查起来非常痛苦。我也常会追问为什么很多模型用字节级 BPE答案是它能够保证任意输入都有无损表示覆盖所有 Unicode 字符就像一个通用底盘代价是压缩率和效率不如纯字符级词表。这个问题的核心考点是你能否把 tokenizer 选型、语料语言分布、序列长度预算、训练成本这四件事串起来考虑。3. RAG和长上下文怎么选这道题已经成了业务面试标配3.1 从业务场景切入现在几乎每个 LLM 落地项目都会碰到“知识库问答”这个需求。候选人通常都会说“我用了 RAG”但问到“你的 chunk 怎么切的、召回率怎么测的、和长上下文模型相比怎么比”一半人开始含糊其辞。RAG 的本质是外挂知识库把文档切块向量化建立索引用户提问时先做检索把相关片段拼进 prompt再让模型基于这些片段生成。这里的核心矛盾永远是我到底该相信检索到的片段还是相信模型记住的知识。把这个问题看清了才算是真正理解 RAG。3.2 检索质量的工程细节RAG 的效果上限其实是检索决定的生成模型只是把检索结果“翻译”成流畅的回答。我对候选人的要求是至少要脱口而出以下几件事chunk 怎么切固定长度切分简单但会把语义拦腰截断按段落和小标题切更自然但要设计 overlap。小模型做 embedding 时chunk 越大噪声越多chunk 越小上下文不足这本身是个调参过程。embedding 模型选型同一套中文数据用通用 embedding 和用领域微调过的 embedding召回差距可能非常大。上线前必须建一个自己的评测集测 top-k 召回率不能只看公开榜单。混合检索向量召回擅长语义相似BM25 擅长精确词匹配。两者结合通常比单用一种靠谱尤其当用户的问题包含代码函数名、商品型号、人名地名这类精确 token 时。重排召回 50 条但只送进 prompt 5 条时重排器是必不可少的漏斗。很多团队省掉这一层结果质量明显降档。这些细节只要展开讲一两个面试味道就完全不一样了。3.3 长上下文到底能不能替代RAG这是必追问。我的标准答案是看你的核心约束是延迟、成本、准确率还是新鲜度。维度RAG长上下文直接塞知识新鲜度实时更新索引即可需要重新训练或全量更新权重推理成本只送少量相关片段每轮都要处理全部 token延迟多一次检索整体可控序列越长首 token 越慢可解释性可以溯源到原文档难以定位生成依据幻觉控制强约束在检索片段内长文本里无关信息多更容易迷失系统复杂度需要维护索引、检索、评估链路架构简单但成本高长上下文模型的窗口再大也只是“能装下”不代表“能精准利用”。我见过太多号称 128K 窗口的模型在 100K 输入里取关键信息时效果比 4K 窗口加 RAG 还差因为注意力被平均稀释掉了。这种刻意踩坑之后我对“窗口越大越好”这个观念就非常警惕了。4. 微调调的不是“记忆”是“行为”LoRA与全参微调的取舍4.1 面试官最怕听到的答案我最怕候选人说“模型效果不好就微调一下”。这个思路既没讲清楚微调改了什么也没讲清楚为什么需要微调。微调改变的是模型的行为分布而不是塞进新知识。如果你想让模型知道 2026 年的新事件正确的路径是入库 RAG而不是微调。判断要不要微调我的原则是知识类需求比如“某个独家产品文档”——不要微调走 RAG。能力类需求比如“把所有口语回答改成书面合同条款风格”——适合微调。格式类需求比如“输出必须是 JSON且字段固定”——可以用微调来强化稳定性也可以靠 prompt 约束先在 prompt 层试。面试时能把这个分类讲清楚基本就能让面试官点头。4.2 LoRA为什么有效LoRA 的核心观点是预训练模型的权重矩阵在适配下游任务时并不需要全量改动只需要学一个低秩的增量。也就是说原始权重 W 保持冻结额外学一个 ΔW并且把 ΔW 分解成两个小矩阵 A 和 B 的乘积用一个小秩 r 去约束增量的表达能力。这个设计的精妙之处在于全参微调要保存完整的梯度、优化器状态和主权重显存压力巨大LoRA 只需要训练极小的 A/B 矩阵原始权重甚至可以用更低的精度加载。所以一张 24GB 的消费级显卡也能把 7B 模型微调跑起来这在全参微调时代是不可想象的。面试中我关心的是你有没有真的动过手rank 取多少、只调q_proj和v_proj还是全 attention 模块、学习率大概在什么量级、和全参微调相比最终效果差多少。如果你能说“我试过 rank16 效果最好rank64 反而差点原因可能是数据量不够导致过拟合”这就算是真的踩过坑。4.3 灾难性遗忘与数据配比另一个高频追问是微调会不会把模型原有的能力弄丢答案是会。所以现在靠谱的微调训练都要混入一定比例的原生通用数据比例通常在 10% 到 30%防止模型“偏科”到只认识你的业务数据。给个小技巧如果你在微调数据集上加上 5% 到 10% 的通用指令数据通常可以明显缓解客服场景中模型说话越来越机械、越来越模板化的问题。这个数字不是拍脑袋是真实验证过很多次的配比区间。5. 7B模型推理到底要多少显存一道应用题卡住八成人5.1 显存公式不会算部署就无从谈起这道题最爱出现在系统设计环节里目的很实际你说你上过生产环境那你知不知道一个 7B 模型放上服务要准备多大的显存我见过简历写了三年大模型部署经验的人支支吾吾说不出个所以然。推理显存主要包括三块模型权重、KV cache、中间激活。权重的计算最简单参数量乘以每个参数的字节数。FP16 精度下7B 模型大概就是 14GB。BF16 同理。如果做 INT8 量化可以压到 7GB 左右INT4 量化能到 3.5GB 上下但精度损失和某些算子不兼容的问题也要掂量。5.2 KV cache的具体算法KV cache 是面试中的加分点因为它是推理加速的核心。一次生成过程中每个历史 token 的 K 向量和 V 向量都会留存下来供后续 token 使用避免重复计算。它的显存占用大约等于2K和V x 层数 x KV头数 x head_dim x 序列长度 x 字节数。我给候选人常举的例子是 7B 模型32 层KV 头也有 32 个head_dim 128那每个 token 的 KV cache 就是2 x 32 x 32 x 128 x 2字节 512KB。如果序列长度 2048就需要 1GB4096 长度就是 2GB。这还没算激活。加上权重 14GB7B 模型即使用 FP16 也得准备 20GB 上下实际部署上 24GB 单卡是比较紧张但可以跑的配置。所以很多团队宁可量化成 INT4 也要把模型塞进单卡为的就是省下内存给 KV cache 和并发请求腾空间。KV cache 越大你能支持的并发 batch 越大单位 token 的推理成本越低。5.3 量化、vLLM与工程取舍再往下我会追问你怎么提高吞吐如果答“用 vLLM”我会继续问它做了什么。vLLM 的核心是 PagedAttention 和 continuous batching。PagedAttention 把 KV cache 按页管理解决显存碎片化问题continuous batching 允许一个请求生成完一个 token 就腾出位置给新请求而不是等整轮推理结束。这些机制听起来是“高并发优化”本质上是显存规划的极致压榨。候选人如果能说出“量化降低权重体积vLLM 解决 KV cache 管理动态 batch 能塞满算力”这一串面试效果就非常好。需要注意的是量化不是免费的GPTQ、AWQ 和 bitsandbytes 各自适合的硬件和精度损失不完全一样部署前必须拿自己的数据实测。6. 上下文窗口不是大就万事大吉位置编码与外推的底层逻辑6.1 从“句子顺序”说起注意力机制本身是不带顺序概念的。你把一句话里的词打乱顺序注意力计算的结果还是一样的意思却完全变了。所以模型必须把位置信息编码进去。早期 Transformer 用正弦余弦函数后来很多模型用可学习位置编码而现在大多数前沿模型用的是旋转位置编码也就是 RoPE。RoPE 的设计思路是用旋转矩阵去编码位置。每个 token 的 Q/K 向量在高维空间里按照位置角度做旋转两个 token 之间的相对位置体现在它们的夹角上。“相对位置”是关键因为你不能说一段文本里第 17 个词指的是绝对序号为 17 的词重点是它和周围词的距离。6.2 外推为什么这么难模型训练时只见过长度 4096你却在推理时给它一段 80000 长度的文本代价会急剧上升。原因是模型的注意力分布从未覆盖过这么远的距离它的泛化能力不是无限的。工程上常用的补救办法有三种位置插值把新位置按比例压回训练区间、NTK 外推改变旋转频率的缩放方式、YaRN结合分布特性和 NTK 的改进版。这些方法本质都是“让模型以为它在处理熟悉长度的文本实际上窗口已经被撑大了”。候选人不一定要讲出 NTK 的数学细节但你至少要知道不是模型说支持 128K你就能拿到完整的 128K 质量。窗口是一个“标称值”实际可用质量往往要打折扣。6.3 长上下文评测能信几分我面试时会问你凭什么判断一个 128K 模型是真的能处理 128K答案是长文本评测集。常见做法包括大海捞针测试、长文档问答、多文档摘要。大海捞针这种任务其实要求很低因为“找出一个隐藏事实”非常容易被注意力捕捉真正难的是把 100 页合同里的多个条款综合起来判断一件事是否合规这种需要跨分散区域推理的任务才是长上下文的试金石。所以我建议候选人去实测而不是只看宣传文案。我踩过的坑是某模型宣称 128K结果超过 64K 后它会把中间的段落直接“忘掉”定位事实变成 0 分。这种幻觉式的规格只会坑到自己。7. 大模型凭什么一本正经地胡说幻觉来源与评测体系7.1 先说幻觉是怎么来的幻觉是落地项目最大的隐性炸弹面试必问。绕开这个问题而只谈“模型很强”说明你对可靠性的理解还不够。幻觉来源通常有这么几类训练目标造成的模型学的是下一个 token 的概率不是事实数据库。它追求的是“流畅”不是“正确”。知识截断的副作用数据在不断增长而模型权重是固定的训练截止日期之后的信息模型天然没有但它会用自洽的方式编一个出来。上下文稀释长 prompt 中相关信息和大量无关信息混在一起时模型很难始终坚持相关片段。解码偏好采样参数调得太随机或者强约束输出格式时模型为了满足格式而牺牲事实。讲清楚“只要用上 LLM幻觉就是系统设计的一部分不是偶发 bug”这个观点本身就能拉开差距。7.2 怎么评测一个问答系统的可靠性很多候选人只在代码里打转忽略了评测设计。我常问你的 RAG 系统上线怎么判断效果好靠谱回答不是“人工抽了 100 条感觉不错”而是一套多层次的评测框架单点指标答案是否包含了关键实体是否和标准答案一致用 ROUGE、BLEU 这类做参考。忠实度评测生成的每一句话能否在检索到的文档里找到证据。找不到证据的话判定为幻觉。端到端评测从用户问题到系统回落的完整链路对比成功率、空答率、错答率。LLM-as-judge让一个更强的模型给答案打分但这个裁判自己也会误判需要拿人工标注结果做校准。要能说出“LLM 评测 LLM 是有偏的”这一点说明你真的做过评测设计而不是只是拿个现成脚本跑了跑。7.3 缓幻觉的三板斧把这些落到工程上通常有三件套可以做。第一是限制生成范围。RAG 场景里把 prompt 写成“只能依据提供的材料回答材料里没有就明确说明不知道”能把瞎编率显著压低。第二是解码参数调整。降低 temperature提高 top-p 的下限虽然会牺牲多样性和一部分创造性但可靠性明显变好。第三是答案后校验也是最容易被忽略的一步。生成之后用另一个 prompt 或规则去核验每句话的出处甚至直接把“找不到出处”的句子从最终答案里删掉。这个动作不加任何新模型只用现有链路效果却很好。8. Agent和“调接口的脚本”有什么区别记忆与工具的边界8.1 面试官在听你有没有自己的框架最近 Agent 概念被炒得厉害我面试时见到的候选人十个有九个说自己做过 Agent但真正问出一层就发现做的只是“套着 chat 模板调 Python 函数”。Agent 和普通脚本的区别不是能不能调用工具而是有没有决策环。我常用一句话切分尺度Agent 是一个自主循环——观察、思考、决定、行动、再观察。工具只是这个循环中的肌肉循环本身才是神经系统。如果只是用户问一句话调一个函数返回结果那和搜索引擎接口封装没有本质区别。8.2 ReAct循环与function calling面试中如果能画出 ReAct 的流程基本就赢了一半。核心路径是先把用户目标拆成当前需要执行的子任务选择合适工具给出工具调用参数拿到返回结果再判断任务是否完成没完成就继续循环。工程层面更常见的是 function calling。模型不是直接写自然语言回复而是输出一个结构化的 JSON 描述“我要调用哪个函数传什么参数”系统执行后把结果回填给模型。这里的难点有三个函数 schema 的设计参数定义得越精确模型越不容易填错。模糊的字段描述会把一次函数调用变成一场猜谜游戏。错误 recovery工具返回出错时如何让 Agent 重新规划而不是无限重试。成本控制一个复杂任务可能要调十几次工具每一轮都是新的 token 开销预算控制不好直接起火。如果你能把这些环节的取舍讲清楚说明你亲手搭过而不是只看了篇博客。8.3 Memory为什么这么难做Agent 的记忆分两层短期记忆是当前对话的上下文窗口长期记忆是把重要信息持久化比如存进向量库的对话摘要或用户画像。面试时我会追问长期记忆的写入策略是什么什么时候把一段上下文压缩成摘要摘要的失真怎么办这不是技术上做不出来而是召回时机、重写策略、记忆覆盖机制统统没有公开标准大家都是在试错。踩坑最多的是“记忆叠加”。你让 Agent 每次对话前把所有历史摘要全部塞进上下文很快上下文就会被无关记忆占满Agent 反而忘了当前用户真正想要什么。所以记忆系统必须要有筛选和遗忘机制和人类大脑一样能记住什么不够重要的是知道忘掉什么。9. 面试实战中的几个通用心法9.1 遇到不会的题别急着道歉在真实的面试里面试官并不期望你每个字都有标准答案。我们更看重你面对未知问题时的反应方式。遇到一道不会的题比较正常的表现是承认边界然后基于已有知识尝试拆解比如“这个机制我具体实现没细看但根据我理解的架构它应该和显存管理有关我会先查......”。这就够了。最怕的是假装会。我一听就知道你在编那道题下面再埋两个追问场面就很难收拾。宁可清楚地讲“这里我不知道”也比硬讲十分钟错误的结论要强得多。9.2 把思考过程亮出来同一个答案有人是背出来的有人是推出来的。我常故意把一个问题变形比如刚才说的“每 token KV cache 有多大”我把模型换成 64 层 8 个 KV 头就是想看你能不能现场算出来。这时候如果你不慌不忙地说“我按公式推一遍头数如果是 8那每层每个 token 只需要存 8 x head_dim x 2 乘 2...”就算结果算错我也愿意给机会。所以面试的时候不要只报结果要把推理路径说出来。面试官不是在检查作业是在和你做一次技术讨论。9.3 给面试官视角的观察作为面试官我也有自己的私心。我最喜欢的候选人有一个共性他们谈项目时会主动讲失败。不是“遇到什么问题我都顺利解决”而是“第一版检索召回率只有 0.35后来发现是 chunk 切分得太碎重新设计后升到 0.6”。这种项目复盘能力比任何技术名词都难培养。最后再分享一个小建议面试前把上面八条链路自己画一遍从“文本进来变成 token”到“token 进入注意力”到“KV cache 怎么存”到“生成结束怎么被后校验”这一条线画下来如果能不打磕绊基本上面试状态就不会差。LLM 没有太多需要背的八股真正要做的是一层层把黑盒子揭开看到里面的机制和代价。你掀得越深面试官对你的信任度就越高。
阅读完成 · 觉得有帮助？
