大模型面试高频八问：从注意力机制到Agent记忆的完整技术链路解析

最近半年陆陆续续面了几百个做大模型方向的候选人，从刚毕业的校招生到手里一堆A+B刊的资深工程师都有。一个很直观的感受：简历上写得天花乱坠，项目里全是套壳应用，但问到原理层面就漏气的人，占比相当高。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

这是必追问。我的标准答案是：看你的核心约束是延迟、成本、准确率，还是新鲜度。

长上下文模型的窗口再大，也只是“能装下”，不代表“能精准利用”。我见过太多号称 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 模块、学习率大概在什么量级、和全参微调相比最终效果差多少。如果你能说“我试过 rank=16 效果最好，rank=64 反而差点，原因可能是数据量不够导致过拟合”，这就算是真的踩过坑。

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 使用，避免重复计算。它的显存占用大约等于：2（K和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，就需要 1GB；4096 长度就是 2GB。这还没算激活。加上权重 14GB，7B 模型即使用 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 没有太多需要背的八股，真正要做的是一层层把黑盒子揭开，看到里面的机制和代价。你掀得越深，面试官对你的信任度就越高。