大模型面试高频8问：从自注意力到RAG的底层原理与工程实战

前阵子面一位背景很漂亮的候选人，项目经历里写着“基于开源模型做了智能客服”“微调过 7B 模型”，技术名词背得滚瓜烂熟。面试进行到第十分钟，我问了一个看起来最基础的问题：Transformer 的自注意力机制，到底解决了什么？他愣了几秒，然后开始背公式，公式也是对的，但问到“为什么要除以根号 d”时，他答不上来。

这类场景今年我见过太多。简历光鲜的人很多，但对底层原理有真正理解的人比例并不高。LLM 岗位的面试，不管你是面算法、应用还是工程方向，大概率都会从基础问题问起。不是面试官故意出难题，而是因为大模型项目的落地方案往往不是在“用哪个新模型”上拉开差距，而是在模型理解、数据意识、工程落地这几个环节里拉开差距。

这篇文章要说的 8 个问题，是我在实际面试和复盘里筛选出来的高频淘汰题。它们不一定最偏门，但几乎覆盖了大模型从业者必须具备的四层能力：模型原理、训练认知、数据敏感度、系统落地。每个问题我都会拆解“面试官想听什么”“多数人会答错什么”“怎么答才能过关”，并在关键地方补充我在真实项目中踩过的坑。

1. 面试官到底想从这 8 个问题里看到什么

先说一个反直觉的观察：很多能跑通代码的候选人，其实没有真正理解模型内部在做什么。调 API、跑框架很容易，市面上开源工具已经把推理、微调的复杂度封装得很好了，但这恰恰导致一批人停留在“会用”的层面。

面试官问原理，不是考记忆力，而是想听你怎么解释设计动机。比如“多头注意力为什么有效”，你不能只说“可以关注不同子空间”，要能继续说“多头是多个子空间并行，每个头可以学到不同的位置组合模式；但这不代表头越多越好，头数太多、每个头的维度太小时，信息会被切碎，实际效果反而变差。”

所以，原理题真正的评判标准是：能不能把“设计动机—数学表达—工程代价”三者讲成一个完整故事。能讲清楚的人，通常也具备解决训练异常、推理异常、效果不佳这类工程问题的能力。说不清楚的人，一到线上环境就很容易被模型反馈牵着鼻子走，出了问题只知道换 prompt，或者换模型。

我把这 8 个问题按能力维度做了一个分类，方便你对照定位自己的薄弱点：

表格不是标准答案，但覆盖面是我见过的真实岗位 JD 交集。下面逐步展开。

2. 前两问：架构与注意力机制——送分题也是淘汰题

2.1 第一个问题：Transformer 自注意力到底解决了什么

面试通常这样开场：“聊聊 Transformer 的注意力机制吧，为什么现在的大模型基本都是这个结构？”

好的回答从这里开始：RNN/LSTM 处理序列时是按顺序读入的，当前时刻的输出依赖上一时刻的隐状态，这种方式有两个先天问题。一是不能并行，长序列训练非常慢；二是长距离依赖会有信息衰减，即使 LSTM 加了门控，也只是缓解，没有根治。而自注意力机制可以让序列里任意两个位置直接建立关联，不再依赖一条线性的信息传导链。

然后是关键的二阶表达：Transformer 对每个 token 学习三组向量，Query、Key、Value。Query 可以理解成“我在找什么”，Key 是“我能提供什么标签”，Value 是“我真正携带的内容”。注意力分数计算的是 Query 和 Key 的相似度，再用 softmax 归一化成权重，最后对所有位置的 Value 做加权求和，得到这个 token 融合全局信息后的新表示。

公式是Attention(Q,K,V) = softmax(Q * K^T / sqrt(d_k)) * V。

我在面试里要求候选人用自己的话说出“为什么要除以 sqrt(d_k)”。常见错误答案是“因为公式里这么写的”或者“为了让数值便于计算”。更准确的原因：当 d_k 较大时，点积的方差会变大，导致 softmax 的输入落在饱和区，梯度很小。除以 sqrt(d_k) 是为了把方差重新拉到 1 附近，让 softmax 对输入变化更敏感，这样模型更好训练。能答到这一层，才算真的懂了这个公式。

再用一个生活化类比帮助理解：RNN 像流水线上只有一个工位，包裹一个接一个传下来，工位只能记住上一个包裹的状态，前面的包裹信息传到这里已经模糊了。自注意力机制像所有包裹文件摊在会议桌上，每份文件都可以直接查看其他文件的关键词和内容，然后决定优先参考谁。代价也很直接：会议桌上所有人的两两组合都要算一遍，复杂度是 O(n²)，序列长度一万时，要计算一亿对关系。这也是为什么后来会有 FlashAttention 这类 IO 感知优化、稀疏注意力、局部窗口注意力这些工程改进。

接着面试官可能追问多头注意力。合格的回答不只是“让模型关注多个子空间”。我更愿意听到：多头其实就是多套 QKV 投影并行计算，彼此参数独立，让模型可以同时关注“两个词是否是同类型实体”“它们在句法上有无主谓关系”等不同角度的相关性；最后再拼回一起重新融合。需要注意，多头数量不是越多越好，头数增加会让单头维度变低，信息碎片化，训练不稳定。实践中 7B 级模型常见 32 头、头维度 128 的组合，这些都是设计者在并行度、表达容量和收敛稳定性之间做权衡的结果。

2.2 第二个问题：位置编码与 RoPE，答到什么程度才算过关

Transformer 结构本身是“无序的”，自注意力不看输入顺序，两个 token 交换位置后计算结果是完全一样的。所以模型必须把位置信息注入进去。标准问题就是：“Transformer 怎么理解词的先后顺序？”

初级回答：加一个 embedding 到输入里。接着问“那用什么 embedding？”就卡住了。合格回答要区分绝对位置编码、相对位置编码和旋转位置编码。

绝对位置编码的代表是 Transformer 原版的正弦位置编码和 BERT 式可学习位置向量。绝对位置编码的问题是把“位置 i”当成一个绝对标签，模型很难泛化到未见过的位置。相对位置编码则把关注点放在两个 token 之间的相对距离，例如 T5 的 relative bias，ALiBi 直接按距离衰减注意力分数。而如今大模型最常用的 RoPE（旋转位置编码），是让 Query 和 Key 在二维平面上做一个旋转操作，旋转的角度和两个 token 的位置差相关，从而让注意力天然依赖相对距离。实现层面不需要真的构造旋转矩阵，一般是预计算 cos、sin 表，用复数乘法或分段旋转近似实现，这也是 llama.cpp、mlx 这些推理框架里反复出现的那段代码。

RoPE 更重要的一个考点是外推。模型只在训练长度的窗口里见过位置信息，推理时输入超过这个长度，位置系数就会落在训练范围之外，直接导致注意力分数异常。业界有几种处理思路：位置插值把超出部分的坐标压缩回去；NTK-aware 方法通过调整 base 频率让位置编码在更长范围“近似有效”；YaRN 又做了更精细的频率策略。我在实际项目中会补一句：这些方法能帮我们延长“应急”窗口，但不代表长文本质量就跟短文本一样好。生产建议是优先让模型工作在训练区间附近，真正超长场景用检索和摘要切碎，而不是无限扩窗口。这样回答会让面试官觉得你不只懂模型，还有部署的尺度感。

3. 中间三问：训练链路、数据与采样——从“报菜名”到“讲明白为什么”

3.1 第三个问题：预训练、SFT、RLHF 每一步在解决什么

几乎没有人不会说这三个名词，但很多人只能讲“预训练之后 SFT，SFT 之后 RLHF”。这个答案只能拿 50 分。正确打开方式是把每一步的目标、数据形态和要解决的问题说清楚。

预训练用大规模语料做自监督的 next-token 预测，是模型语言能力、知识储备的主要来源。它的输出分布本质是“人写的字长什么样”，而不是“人想要的回答是什么样”。所以预训练模型可能知识丰富，但不一定听指令，还可能输出不合适的内容。把它比作一个人，预训练阶段他读了很多书，学到了语言和世界常识，但还没学会在什么场合该说什么话。

SFT 要在有监督的“指令—回答”数据上继续训练，让模型学会指令理解、格式遵循、任务规范。它对数据质量的要求远高于数据总量。我有一次处理客服数据集，只做了一次简单去重，就去掉了近 60% 的重复和低质量样本，一次性把自动评测相关指标提升了一块，这是数据噪声对 SFT 影响的典型例子。SFT 的本质仍然是交叉熵损失，但它的作用不是“续写训练”，而是把模型带进一个更符合产品需求的行为区域。

RLHF 再把目标从“像人写的”推向“符合人类偏好”。偏好标注员选出更合适的回答，奖励模型学习“好”与“坏”，再用 PPO 等算法让主模型不断提高奖励分。关键理解：RLHF 并不增长知识，而是调整输出分布，让模型更倾向说出被认可的话，降低不受欢迎的内容。近几年 DPO 等方法不单独训练奖励模型，直接基于偏好排序做隐式奖励，训练更稳定，但核心思路仍是“偏好对齐”。

如果被追问“为什么不能跳过 SFT 直接 RLHF”，要能说出来：RLHF 的搜索空间太大，奖励模型给出的梯度信号噪音不小，如果模型还不会遵循指令就上 RLHF，很容易在低效空间里打转。SFT 相当于先给模型一个“有基本规矩的起点”，把答案落到可优化的附近区域；RLHF 则负责在这个区域里找到更优的表达。

3.2 第四个问题：数据标注与指令数据，质量红线在哪

这个问题出现的概率比我预想的高太多，几乎人手一个“用开源模型做了 XX”的项目，但被问到“你微调用的数据怎么来的？”就沉默了。所以“数据怎么来、怎么做标注”是我认为 8 个问题中最容易被低估的一个。

如果只看数据量，方向就错了。我在真实项目里的体感是：高质量的 2000 条指令，往往好过拼接出来的 20 万条模板式数据。模板化数据会导致两个问题，一是模型学到的改写规律非常浅层，二是新场景一多，模型性能立刻塌方。面试官想听的是你对“数据构造—数据清洗—数据校验”全流程的认识。

构造指令数据常用三条路径：第一条，从客服日志、论坛、工单里提取真实用户问题，人工写规范回答；第二条，用已有模型生成指令，再通过规则和人工筛选，保证多样性和难度分布；第三条，从公开数据集清洗转换到目标格式。比较忌讳的是只报“用了公开数据集”这种口径，因为没有体现数据跟业务场景的匹配逻辑。

数据标注要有可执行的质量流程。常用方案是“规则预标注 + 双人标注 + 仲裁”：预先把明显错误、重复问题过滤掉；标注任务里每个样本由两个人独立标注，不一致的进第三轮仲裁；同时定期抽检一致性，比如十个样本同标注比例要超过 90%。指令数据的多样性，除了任务类型（问答、摘要、改写、分类、抽取），还要控制问题长度、回答长度、提问口吻、专有名词的分布，让模型见到的输入空间足够宽，而不是只在大而全的通用数据里打转。

还有一个常被忽略的点：微调数据的配比。训练集不能只有指令数据，最好保留一部分正常语料、错误纠正样本和领域特有术语解释，防止模型在微调阶段发生灾难性遗忘。这些细节说出来，面试官会立刻认为你有真正的一线经验，而不是只跑过笔记本上的 demo。

3.3 第五个问题：temperature、top-p、top-k，采样参数背后的逻辑

第五个问题一般会用一个实际场景引出：“同一个模型，同样的 prompt，为什么参数不同结果差别这么大？线上应该怎么调？”

回答要先给出最核心的逻辑：模型最终输出 token 的概率分布来自softmax(logits / temperature)。temperature 降低，token 之间的概率差被放大，高概率 token 被选中的概率更大，输出更确定；temperature 升高，概率分布被压平，低概率词也有机会被采样，输出更多样。temperature 设为 0 时，理论上是贪心，永远选 argmax；但由于浮点精度和批量推理环境等因素，生产上不能完全保证每次一致。想严格控制一致性，需要固定随机种子并简化输入环境。

top-k 是从候选列表中截取概率最高的 K 个 token，再做采样。它的优点是上限可控，缺点是如果某个位置概率分布很平，K 取太小会丢掉合理候选；如果很尖，K 取太大又等于没截。top-p 用累计概率阈值来动态截断，候选集合随分布集中程度变化，比 top-k 更柔性。实际场景经常二者一起用，比如先 top-k 粗过滤，再 top-p 做二次截断。

线上调参还有一个容易被忽略的原则：参数是给“任务类型”服务的，不是给“个人口味”服务的。客服场景追求稳定，temperature 通常取 0.1 到 0.3，并且配合较强的输出约束；创意写作可以放到 0.8 到 1.0，让表达有更大变化空间；需要事实准确的知识问答，推荐 temperature 偏低，但更重要的是结合检索证据，而不是靠调高 temperature 去赌正确答案。能把采样参数和任务风险挂钩，面试官会认为你有真实的产品判断。

4. 后两问：上下文窗口、幻觉与评估，区分“调包”和“调模型”

4.1 第六个问题：上下文窗口与超长文本，怎么答才有工程感

这类问题通常以故障形式出现：“模型上下文窗口只有 8K，用户传了一份 20K 的 PDF，问什么都是答非所问，怎么办？”很多候选人会脱口而出“把窗口调大”。这种回答不仅说明没有工程经验，也没理解上下文窗口限制的本质。

先回答限制来源：自注意力计算量随序列长度平方增长，模型训练时见过的最大长度有限；推理时，每个 token 的 KV 缓存都要占显存，长度翻倍显存接近翻倍。所以上下文窗口不是“想设多大就能设多大”。如今长上下文模型越来越多，但“支持长上下文”和“长上下文理解得好”是两件事。有研究指出模型对长文本中段信息容易遗忘，也就是所谓 Lost in the Middle。因此在做长文本产品时，我默认不会把全文塞给模型。

工程路径通常是一个组合方案：第一，做段落切分和检索，只取与用户问题最相关的片段；第二，对超长文档先做分层摘要，再用摘要加关键段落回答；第三，利用重排序模型把相关片段按相关性排序，将最相关的三到五块拼入上下文。有一个经验细节：多数情况下，把最重要信息放在 prompt 开头和结尾效果更好，这跟注意力分布在两端更强的现象有关。处理流式长文档时还可以用增量式摘要，而不是非得一次性读完。

能把这些路径说出来，比背“支持 128K 上下文”要有说服力得多。因为后者体现的是堆参数，前者体现的是设计系统的能力。

4.2 第七个问题：幻觉从哪来，生产环境下怎么控

幻觉几乎是所有 LLM 应用都绕不开的问题。面试官问“模型开始瞎编了怎么办”，如果回答“加 prompt 说不要乱编”，那就只能得零分。

先讲来源：LLM 本身是概率模型，优化目标是输出“看起来合理的下一词”，不是“真值数据库查询”；训练语料里本身存在错误和偏见；解码时模型偏好高频和流畅的表达，导致事实性错误被掩盖；还有一类是上下文相关性幻觉，比如明明材料里没有这个信息，模型会把相近元素融合编造出来。

所以解决方案也必须分层。第一层是数据与检索：做 RAG，把可验证的知识源接入，并要求模型在回答中引用证据；对检索到的片段做 rerank，提高上下文中有用信息占比。第二层是输出约束：设置系统提示词限定知识范围，规定“不知道就用不知道”，对结构化任务强制输出 JSON schema；必要时用少量示例固定回答边界。第三层是部署策略：对高风险场景可以用多次采样一致性比对，结果不一致则触发人工或兜底流程。第四层是评测闭环：给团队建一个幻觉评测集，里面有真实示例、错误示例、边界示例，每次模型升级都跑一遍，设定“可接受幻觉率”指标的上限，超过就不允许发布。

评估本身也很关键。大家常说的 BLEU、ROUGE 只能反映表面相似度，对事实性判断没什么用；ROUGE 分数高也可能是一句通顺的谎言。现在团队普遍会用“LLM as judge”做自动评估，但一定要防偏置：让裁判模型先看证据再看回答，把回答拆分成可判定的原子事实，逐条打勾，最后抽样给人工复核一致性。没有评测闭环的优化，本质上都是碰运气，这句话我建议直接写进你的项目复盘里。

5. 压轴一问：推理成本、RAG 与智能体韧性，从模型到系统

5.1 第八个问题（上）：模型推理太慢、太贵，怎么优化

面到后半场，面试官一般会从“效果”切换到“成本”。“模型效果还行，老板嫌贵，线上并发上不去，你怎么办？”这个问题能直接拉开普通候选人和资深候选人的差距。

你得有一个比较完整的推理优化清单，从内存、计算到调度。先说最基础的内存：模型权重显存，对于一个 7B 参数模型，FP16 格式大约是 14GB，INT8 降到 7GB，INT4 约 3.5GB。量化（PTQ、QAT、GPTQ、AWQ、GGUF 等）就是在精度和显存、速度之间做取舍。不少端侧场景，比如手机本地跑 GGUF 格式模型，就是靠量化把模型压进有限内存，顺便获得隐私保护和离线能力。要强调的是，量化不是简单的“精度换速度”，对 7B 以下小模型要谨慎，量化后能力下降可能很明显；7B 以上配合校准数据做敏感度量化，效果会更稳。

再说算力和批处理。推理服务不是一次只处理一个请求，而是不断把新请求合并进一个 batch。continuous batching 是主流方案，动态地让一个 batch 里的请求在不同时刻结束、新请求插队进来，最大程度吃满 GPU。vLLM 的 PagedAttention 则把 KV cache 切成小块按需分配，解决显存碎片和超额预留问题。投机采样也叫 speculative decoding，用一个小模型先产出候选 token，再由大模型一次性验证，让平均耗时接近小模型吞吐，但效果因任务而异，验证接受率低时反而更慢。

最后要有成本账。回答这类问题一定要带指标：延迟 P95、吞吐 tokens/s、每百万 token 成本、显存占用。比如先估算单卡能同时服务多少路请求，再推算还需要多少副本；如果批处理已经把 GPU 利用率打满，再优化算法层反而低效，不如做路由层把简单问题分流给小模型。这个层次体现出你不只是一个会用模型的人，而是能做成本决策的人。

5.2 第八个问题（下）：RAG 与智能体容错控制，不能只会调 API

如果说推理优化看系统观，那么 RAG 和 Agent 看的就是“把模型放到真实业务里扛折腾”的工程能力。RAG 现在被问得非常多，但很多人只会答“检索增强生成”，给不出一个落地的流程。

合格的 RAG 回答应该按链路拆：文档加载、分块、向量化（embedding 模型选择）、向量检索、重排序、拼接 prompt、生成。在项目里，检索质量往往比生成模型本身更重要：如果一个不相关片段进入上下文，再强的模型也会被带偏。分块上，推荐按文档结构（标题、段落）切割，而不是按固定字符硬切；块大小根据任务调，问答类任务 300 到 500 字左右比较常见，过长会稀释注意力。也要处理表格、图片这类非纯文本内容，不能只把原始文本塞进去。这些细节说出来，才算真正亲手跑过 RAG。

Agent 方面，面试官想知道你有没有让模型自主使用工具的能力，以及出了错怎么办。Tool calling 有两种落地形态：一是模型输出结构化 JSON，指定函数名和参数，由代码调度；二是基于提示词的“思考-行动-观察”循环。前者更适合生产，因为可控性和可观测性更强。

容错和自主控制是我特别想强调的部分，也是现在业内人士非常关注的“可靠 AI 系统”核心。设计时要加入：参数 schema 校验、工具返回结果类型检查、超时重试、最大步数限制，以及“计划-执行-验证-反馈”的闭环。比如模型调用天气工具返回一个异常值，代码应该能识别格式不对，触发二次调用或转人工，而不是让模型继续推理。同时要有全链路日志，记录“模型说了什么、调了哪个工具、返回了什么、下一步为什么这样决策”，方便排查问题根因。

落地时我建议从“人在环路”开始：先让 Agent 给建议、人类确认关键动作，跑稳后再逐步放开权限。这个分寸感是很多面试者缺的，因为他们可能只在 demo 里看过 Agent，没有经历过线上事故。安全第一不是一句口号，在智能体场景里，它就是对你兜底设计、状态管理和失败恢复能力的直接考验。

6. 给正在准备面试的人：把 8 问变成一套应答方法

6.1 结构化表达的“三段式”

看过很多候选人，知识量其实够，临场表达却一团糟。其实面试没有一个标准答案的时候，最能拉开差距的是表达结构。我的建议是：一句话定论 + 分层拆解 + 案例收尾。

举一个例子。被问到“你项目里为什么用 RAG？”不要一上来就“因为微调成本高”。应该说：“我们主要想解决知识更新和答案溯源两个问题，因此选了 RAG。具体做法是先对内部文档做结构化切分，建索引，检索后用重排把 Top3 片段喂给模型；上线后幻觉率明显下降，也有了引用依据。它带来的额外成本是检索链路变复杂，所以我们加了相关性阈值，低于阈值直接回答不知道。”你看，这就是定论、分层、业务的组合。任何一道原理题都能用这框架讲。

6.2 最容易踩的五个坑

我按面试记录总结五个高频翻车点。如果你的时间有限，先避开它们。

第一，把 RLHF 等同于 PPO。RLHF 是一套“训练奖励模型再优化策略”的方法族，PPO 只是其中一个常用优化器；现在很多团队用的是 DPO，不单独训练 reward 模型。

第二，提到量化只会说“PTQ、QAT”缩写，却讲不出你选哪一个、为什么。真正的区别是是否需要重新训练，以及精度损失分布，能用一句话讲清 trade-off 才算懂。

第三，回答“上下文不够怎么办”只想到“换更长窗口的模型”，没有提代价，比如中段遗忘、显存膨胀、推理延迟上升。面试官更希望听到组合方案，而不是单点替换。

第四，碰到“模型胡说八道”类问题，张口就答“加 system prompt”。这个动作只是表面，真正要做的是 RAG、输出约束、评测闭环、人工兜底四件事的排列组合。

第五，把“调 API”包装成“部署过模型”。如果你本来就是在 API 基础上做工程，就诚实说清楚；你可以突出自己的 Prompt 设计、评估、工具调用能力，这本身也很有价值。一旦夸大，被追问细节就很容易露馅。

6.3 如果只剩三天准备，我建议只做三件事

先去本地把一个开源小模型跑通，命令行里调整 temperature、top-p、top-k，亲眼看同样的 prompt 输出如何变化。这个练习能一次打通原理题的“手感”。

再手写或仿写一个最小 RAG：加载几份本地文档，切分、向量化、检索、重排，最后让模型基于检索内容回答，并观察“故意塞入错误片段时模型会不会被带偏”。这会让你对链路里每个环节的理解远超看一百篇教程。

最后，把上面 8 个问题写成自己的答案稿，每道题写 200 到 300 字，逼自己不要抄教程，用“遇到过什么问题、怎么解决、为什么这么选”的逻辑去写。写不出来的地方，恰恰就是你要补的短板。

我自己带过几轮候选人，也面过不少团队，一个真实的体会是：面试挂了不可怕，可怕的是挂在哪一道题上都不知道。如果你能沿着这 8 个问题做一次系统性复盘，大概率能避开大多数候选人的翻车点。面试到最后，比的不只是谁知道的模型多，而是谁对模型的理解更接近“可落地”的状态。