企业官网建设流程全解析

LLM 面试必问的 8 个问题，答不上来直接淘汰

上周帮团队面试一位简历上写着"精通 Transformer、熟悉 LLM 微调"的候选人，我问了一个很基础的问题："大模型推理时，KV Cache 到底缓存了什么？为什么缓存了它就能省这么多计算？"他沉默了半分钟，然后开始背自注意力公式。那一刻我知道，这位候选人大概率是背了八股文，但没真正动手跑过模型。

这不是个例。LLM 方向现在最不缺的就是简历，缺的是真懂原理、真能落地的工程师。我自己做了几年大模型应用层开发，也参与过不少招聘，逐渐总结出 8 个面试必问的问题——它们不是冷门偏题，而是分布在"架构理解、训练微调、推理部署、工程落地"这条主线上，任何一个答不上来，基本可以判断此人没有完整走通过一个大模型项目。这篇文章就是把这 8 个问题逐个拆开，讲清楚面试官到底在考察什么、什么样的回答能加分、哪些回答一听就是背书。适用对象包括准备大模型岗位面试的候选人、需要组建 LLM 团队的负责人，以及想系统补一遍大模型原理的开发者。

1. 面试开场三板斧：注意力、位置编码与 KV Cache

1.1 自注意力机制：面试官到底在听什么

第一个问题通常是热身："请解释一下大模型里的自注意力机制是怎么工作的。"很多人能背出 Q、K、V 三个矩阵，知道 Softmax(QK^T / √d) 这个公式，但面试官并不是为了听公式。

我更建议大家从这个角度回答：自注意力本质上是一种全局信息的加权汇聚机制。序列里每个 token 都生成 Query、Key、Value 三个向量，Query 负责向其他位置提问"你有哪些和我相关的信息"，Key 负责告诉别人"我这里有什么信息"，Value 是真正的信息体。Query 和 Key 做点积，得到一个相关性分数，经过 Softmax 归一化之后，就是每个 token 对当前位置的"信息贡献权重"，最后用这个权重把各个位置的 Value 加权求和。整个过程可以理解为：每个 token 都在开会，会前先拿出自己的"问题清单"（Q），参会的人报出自己的"目录"（K），主持人根据 Q 和 K 的匹配程度决定每个人的"发言时长"（注意力权重），然后按发言时长汇总所有人的"发言内容"（V）。

这里有个容易被忽略的细节：为什么要除以 √d？因为 QK^T 的结果会随着维度 d 的增大而变大，Softmax 在输入数值很大的时候梯度会变得非常小，除以 √d 本质上是把点积结果的方差拉回 1 的附近，避免 Softmax 进入饱和区。能主动讲出这个原因的人，说明他确实想过公式里的每个系数，而不是只背了一个式子。

1.2 位置编码：为什么绝对位置不够用，RoPE 到底在做什么

Transformer 本身是"无序"的——它把序列当成一个集合来处理，token 的顺序完全靠位置编码注入。早期方案是正弦位置编码，它把位置 m 映射到一个固定维度的向量；后来 BERT 用可学习的位置编码，把位置当成参数直接训练。这两个都属于绝对位置编码，问题是模型很难从中直接推理出两个 token 之间的相对距离关系，或者还得再学一层变换才能做到。

所以现在的 LLM 基本都转向了旋转位置编码（RoPE）。RoPE 的思路很有意思：不是把位置信息直接加到 token 向量上，而是把第 m 个位置的 Query 和 Key 向量各自旋转一个角度 mθ，然后做点积。旋转矩阵是正交的，两个向量各自旋转之后再做点积，结果恰好只跟它们的角度差有关。这不就天然带上了相对位置信息吗？而且旋转操作可以通过复数乘法高效实现，现代推理框架里对 RoPE 都有专门优化，计算开销很小。

面试里常见追问有两个。一是"正弦编码和 RoPE 的本质区别是什么"，可以答：正弦编码把位置信息作为"加法偏置"注入，RoPE 把位置信息作为"旋转变换"注入；前者是绝对位置直接编码，后者是让注意力分数天然依赖相对距离。二是"RoPE 有外推问题你了解吗"，这就引出了 NTK-aware 缩放和 YaRN 这类方法，具体我在第 5 节展开讲。

1.3 KV Cache：一道经典的显存估算题

第三个问题开始进入实战层面："推理时 KV Cache 是做什么的？"如果候选人能答出"Cached 的是一次性算完的 Key 和 Value"，这只是及格线。想加分，要说清楚为什么只有 KV 被缓存，Q 不缓存。

大模型推理分两个阶段。预填充（prefill）阶段是整段 prompt 一起输入，所有 token 的 Q、K、V 被并行算出来，K 和 V 一路往后层传递；解码（decode）阶段一次只生成一个 token，新 token 的 Q 需要和历史上所有 token 的 K 做注意力计算，如果每次生成都把历史 token 的 K、V 重新算一遍，计算量会随序列长度线性膨胀，根本跑不动。所以工程上的做法是：prefill 之后把每一步的 K、V 留在显存里，decode 阶段只计算新 token 的 K、V，和缓存的拼在一起用。Q 不缓存是因为每个新 token 都有自己的 Query，旧 token 的 Query 在生成当前 token 时已经被消费完了，没有复用价值。

面试官经常在这里追问一个具体的计算题："假设模型是 7B 参数、隐藏层维度 4096、层数 32，KV Cache 每个 token 要占多少显存？"计算方法是：每组注意力头有 Key 和 Value 两部分，所以每个 token 的 KV 大小等于 2 × 层数 × 隐藏维度 × 2 字节（半精度），也就是 2 × 32 × 4096 × 2 = 524288 字节，约 512KB。这个数看起来不大，但上下文一长就吓人了：1024 个 token 就要 512MB，128K 上下文直接奔着 64GB 去了。所以 KV Cache 的优化（GQA、MQA、量化缓存、分页注意力）成为了长上下文部署的核心战场，这也是面试官后面大概率会追加的追问方向。

2. 微调与对齐：背概念最容易翻车的地方

2.1 LoRA：低秩背后是"本质低秩"假设

问完基础架构，面试官会转到一个所有简历都会写的高频技能："你怎么微调大模型？LoRA 为什么有效？"如果你只答"LoRA 是用低秩矩阵近似权重更新量"，面试官基本不会满意，因为这个说法太正确也太空洞。

我给候选人建议的回答框架是分三层：

第一层，LoRA 冻结原始权重 W，训练时只学习一个低秩分解的增量 BA，最终权重等于 W + BA。A 是随机初始化的降维矩阵，B 是零初始化的升维矩阵，训练完了 BA 的秩不超过 r，但 W 本身是 d×d 的大矩阵。第二层，为什么可以用低秩？因为预训练模型的参数有一种"本质秩"很低的性质——虽然权重矩阵维度很大，但真正需要调整的方向集中在少数几个子空间里。换句话说，模型在大规模预训练后已经接近一个很好的解，微调只需要在一个很窄的方向上做局部修正，没必要去动整个高维空间。第三层，r 怎么选？这是一个工程问题，一般 8 到 64 之间都有人用。r 太小时表达能力不足，r 太大时低秩约束失去意义，训练和推理开销都会涨。我通常建议从小 r 开始试，比如 8，然后观察验证集上指标的变化，不够再加到 16、32。

还有一个高频追问："LoRA 的推理延迟会变大吗？"答案是不会——推理时可以直接把 BA 合并回 W 得到 W'，权重还是那个权重，延迟不变。但如果用了 LoRA 的变体（比如 AdaLoRA、DoRA），有些方案不能直接合并，部署时就得留个心眼。

2.2 RLHF 到 GRPO：对齐范式的演进逻辑

对齐问题也是必考项，尤其这两年 RLHF 已经从"要不要了解"变成了"必须能讲清楚"。被问到 RLHF 时，建议先给出整体链路：训练一个奖励模型来模拟人类偏好，再用强化学习让语言模型在这个奖励信号下产出更符合偏好的回答。奖励模型从人类对多个回答的排序中学习，语言模型把奖励模型的打分当作奖励信号，用 PPO 去优化。

但光讲 PPO 是不够的。面试官更想知道你是否理解这套范式的瓶颈。PPO 需要训练一个 Critic 模型估计状态价值函数，这在大模型场景下非常消耗显存和训练时间——语言模型本身已经是超大参数量，再跑一个完整的 Actor-Critic 循环，工程复杂度很高。所以后来出现了 DPO：直接跳过显式的奖励模型和强化学习，把偏好学习转化为一个简单的二分类损失，用人类偏好对直接优化策略。DPO 的数学推导有一点绕，核心是通过最优策略的封闭解，把奖励隐式地表达为策略的比值，从而省掉整个 RL 训练循环。

再后来就是当下热度极高的 GRPO，也是 DeepSeek 相关开源方案里带火的技术。GRPO 的核心改动是：不要 Critic 了，让每个 prompt 多次采样生成一组回答，用这组回答的相对表现作为基线来算优势。这样避免了训练一个大 Critic 模型，显存节省非常可观。被问到"GRPO 和 PPO 的区别"，能答出"GRPO 用组内相对优势替代价值函数估计"就拿到了关键分，再补充一句"代价是必须多次采样同一个 prompt，推理开销增加"就更完整了。

3. 幻觉与可靠性：五个连续追问怎么接住

3.1 幻觉的三个根源

幻觉问题几乎每场面试都会被问，因为它是制约大模型落地的最直接障碍。回答这个问题，关键是要分层——别把幻觉当成一个单一现象，要拆开讲。

根源之一是训练目标的缺陷。语言模型用最大似然估计训练，学的是"给定前文，下一个 token 的概率分布"。这个目标本身没有区分"事实正确"和"流畅合理"的能力。模型只是在拟合训练数据的分布，不是在做事实检索。你要它输出知识，它其实在做"根据统计规律续写最合适的句子"。

根源之二是知识表示的无序。一个大模型把海量文档压缩到几百亿参数里，远做不到逐字存储，只能以"语义近似"的方式记住信息。不同来源、不同质量、甚至互相冲突的知识会被折叠成同一个隐空间中的近似表示。当模型需要一个精确数字、一个具体日期时，它只能把最接近的表示"补全"出来，势必产生偏差。

根源之三是解码的随机性。采样温度、top-p 这些策略允许模型跳出最高概率路径，为的是生成多样性，但多样性顺便带来了事实漂移。开源小模型的幻觉率更高这一点，本质上也是前两个原因在小参数量下被放大了。

3.2 工程缓解：引用、约束解码与自省机制

面试官不想只听到"幻觉是老大难，暂无解"这种空话。面试中比较抢眼的回答是给出一个工程化的缓解清单，按成本从低到高排：

• 检索增强生成（RAG）：从外部知识库检索相关内容，塞进 prompt 里，把模型从"凭记忆回答"变成"根据给定材料回答"。这是当前落地最广的方案，但要注意：RAG 解决不了检索文档里本身没有答案的问题，也解决不了模型"不听话非要用内部知识瞎编"的问题。
• 约束解码：对解码过程做规则介入，限制输出只能从给定的候选集合里选。比如让模型从知识库候选中做选择题，或者要求回答中出现引用编号而不是给出具体事实。
• 自省与校验：让模型先给出答案，再对答案做第二轮自我评价，配合多轮投票。很多线上应用现在会对关键业务场景用"多个采样取多数投票，再加一个校验器判断答案和证据的一致性"。
• 数据层面：微调时给训练样本增加"我不知道"类回答，刻意教模型在不确定时不硬编。这个方法非常朴素，但实测能明显降低低置信场景的幻觉率。

这里可以提到一个面试加分点：与其说"让模型不产生幻觉"，不如说"让模型学会承认自己不知道"。工程上我们真正想落地的是可控的幻觉——在允许模型说"我不确定"和"根据文档回答"的范围内，让输出变成一个可验证的系统。面试官听到这种回答，会觉得你不是在看论文，而是在处理线上事故。

4. 推理优化与本地部署：一问到量化就露馅的人最多

4.1 量化：从 FP16 到 INT4 的误差控制

推理优化是面试中出现频率很高、但很多人答得最差的板块。我经常问："7B 模型 FP16 权重占多少显存？如果量化到 INT4 呢？"答案是：7B 参数乘以 2 字节约 14GB，量化到 4bit 后约 3.5GB——这也是本地能跑 7B 模型的门槛来源。

然后我会追问："量化的本质是什么？"想拿高分，必须要说出这是权重映射：把高精度浮点数的取值范围，映射到低精度整数的取值范围。比如 INT8 量化，就是把 FP16 的权重范围 [min, max] 线性缩放到 [-128, 127]，存的是整数，计算时再反缩放回浮点。这里的核心矛盾是缩放精度：全模型用同一个缩放因子（per-tensor），误差会很大；按 channel 或 group 分别缩放（per-channel/per-group），精度更高，但需要额外的量化参数存储。实际推理引擎里，group size 为 32 或 128 是常见的平衡点。

再深一层要能说出来：量化误差不完全体现在"权重变了多少"，而是体现在激活值范围的变化。权重离群值会主导缩放尺子的设定，导致大多数正常权重被压到很小的整数上，信息严重丢失。所以现在很多量化方案在做"离群值分解"，把少量离群权重单独抠出来用高精度存储，剩下的正常权重做量化。这也是 GGUF 这类格式在本地部署场景流行起来的原因——它把量化过程中的各类参数、特殊标记、词汇表、元数据都打包在一起，推理框架加载时能直接还原，不需要重新计算量化表。如果你用过 llama.cpp 这类工具，会发现同一个模型有 q4_0、q4_K_M、q8_0 等一堆变体，这就是量化方式与精度权衡的表层体现。

4.2 投机采样与 KV 缓存复用

投机采样（speculative decoding）是最近面试里越来越常出现的高级话题。它解决的是自回归解码"一次一个 token"的两大痛点：不能并行、无法充分利用 GPU 算力。思路相当反直觉：让一个更小的草稿模型先快速生成一串候选 token，再用大模型一次并行验证这些 token。大模型如果发现某个 token 不符合自己的分布，就从那里截断重来；如果全部符合，就一次性接受整串 token，相当于一次 decode 生成了多个 token。

讲出投机采样的基本机制不难，难的是讲出它的两个前提：一是草稿模型的分布要和大模型足够接近，否则拒绝率太高，白做；二是在线应用里大多数请求都受显存带宽限制而不是算力限制，这时候投机采样的收益会显著下降。有面试官还会追问："如果草稿模型每次都只输出一个 token，那和普通解码有什么区别？"答案是没区别，投机采样只有在草稿模型准确率高且接受时长、延迟足够的情况下才划算。能主动说出这些边界，比光背"深度猜测"四个字有说服力得多。

KV Cache 复用是另一个面试加分项。它的思路是：如果两个连续的用户请求属于同一场对话，前一轮已经算好的 KV 可以留着给后一轮继续用。多人共享上下文时，甚至可以做一个"前缀树"来缓存公共 prompt 部分的 KV。这些工程策略直接决定线上服务的成本，面试官非常看重候选人有没有这种"成本意识"。

5. 长上下文与 Attention 复杂度：一道必考的复杂度题

5.1 O(n²) 的瓶颈从哪来

"Transformer 处理长文本的瓶颈是什么？"这是标准复杂度题。答案是标准注意力机制的时间和空间复杂度都是 O(n²)，n 是序列长度。为什么？注意力矩阵的形状是 n×n，每个 token 要和所有 token 计算相关性分数，所以计算量和序列长度的平方成正比。序列从 4K 涨到 128K，长度扩大 32 倍，注意力计算量扩大约 1024 倍——这个增长速度会把显存和算力消耗得一干二净。

那么为什么长上下文还是越来越长？这里有两条路线。一条是近似注意力，比如稀疏注意力只让每个 token 关注局部窗口加少量全局 token，另一条是FlashAttention，它不改变注意力计算结果，而是通过分块计算和内核融合，避免把整个 n×n 注意力矩阵写入显存，从而把显存占用从 O(n²) 降到 O(n)，速度还更快。面试中被问到 FlashAttention，说出"它不近似，它是精确注意力"这句话就很关键，很多人想当然地把它归类为近似方法。

5.2 RoPE 外推、NTK-aware 与 YaRN 的逻辑

顺着长上下文再追问一个必然问题："模型训练时上下文是 4K，怎么用它支持 32K 甚至更长的推理？"单纯的 RoPE 位置编码在超出训练长度时会退化，因为模型没见过这么大的旋转角差，注意力分数分布会乱掉。

一个经典方案是NTK-aware 缩放。NTK 是神经正切核理论里的概念，应用到 RoPE 上做的事情是：把 RoPE 的旋转角基频按一定比例缩放，让"高频分量少缩放、低频分量多缩放"，也就是把位置编码的频段拉开，使得短距离关系尽量不变，长距离关系被"压缩"到模型熟悉的范围内。这样做的好处是模型不需要重新训练就能在一定范围内外推，坏处是超过某个倍率后依然会崩溃。

更进一步的是YaRN，它结合了 NTK 缩放和注意力温度的调整。逻辑很简单朴素：外推时注意力 Softmax 的熵会变化，可能导致模型变"迷糊"，所以通过重缩放注意力分数，把模型对"最近 token"和"较远 token"的敏感度校准到训练时的水平，再进行微调。面试能讲到这一层，说明你不是只会用"换了位置编码"来敷衍。

这里我把长上下文复杂度、位置编码和工程外推方案串起来了——这三者其实是面试官考察你"是否真正理解 Transformer 全链路"的组合拳。能一口气说清楚它们的关系，比单独背任何一题的效果都好。

6. 智能体应用与工程容错：LLM 落地时真正决定去留的最后一问

6.1 ReAct 模式与工具调用

最后一个环节很常见，尤其这两年："你们怎么用 LLM 做智能体？介绍一下 ReAct 之类的原理。"这题考察的不是你看过多少 Agent 框架，而是你是否理解 LLM 在工具调用场景下的本质。

ReAct 的核心是"推理和行动交替进行"。模型先思考当前任务需要什么（Thought），然后决定调用什么工具、传什么参数（Action），拿到工具返回的结果后继续思考（Observation），循环直到完成。翻译成人话：LLM 不再一次性吐完整答案，而是在每一步"小步快跑"，用外部工具的结果来校准下一步决策。这和直接问 LLM"今天北京天气怎么样"再让它凭记忆回答完全是两套逻辑——智能体要求模型具备很强的"遵循指令、格式化输出、根据外部反馈调整计划"的能力。

面试官追问的方向通常是"工具调用的可靠性怎么保障"。这里有个很容易踩到的雷：很多候选人说"我们用的是 function calling，模型会自己调用函数"。但真实线上环境里，模型返回的"API 调用结果"是一个字符串，它可能格式错误、参数缺失、幻觉出一个不存在的函数名。因此工业级实现必须加参数校验层和实施确定性逻辑：上一道 JSON Schema 校验，不合法就重新生成；再套一层"重试机制"，模型第一次调失败后把错误信息喂回去让它修正；再往上才是构建多步骤的"计划-执行-验证"循环。

6.2 容错控制与自修复循环

智能体这题的高分答案，是能讲出"容错控制"这个热搜词背后的工程本质。很多面试者只会在 demo 里演示"智能体帮我订了个机票"，但面试官真正关心的问题是：当模型调错了一个工具、下错了一个决策，系统能不能自己发现并纠正？企业级应用里，绝对不能让模型的一个幻觉动作直接触发真实世界的副作用，比如发邮件、转账、删库——这种场景需要对工具操作做权限分级，或者至少设一道审批确认。

我在实际项目中用过一个相对稳定的模式：

• 每个 Agent 步骤的输出严格走结构化 JSON，包括 thought、action、action_input，解析失败就触发重新生成，最多重试 2 次；
• 工具返回值统一加一个"可信度"字段，让模型在低可信度情况下明确输出"不确定"，而不是编一个答案；
• 核心业务链路中有一个中间校验器，负责检查 Agent 的决策是否触碰规则边界（比如金额上限、收件人黑名单），一旦触发就自动改走人工审批流程。

这套思路库可以应对大部分"模型不可靠"的现实。面试官听完会觉得：这个人不是只会调 API，而是真的在设计一套"可靠 AI 系统"。

其实这 8 个问题背后的思路是一样的：从 Transformer 原理到推理优化，从微调对齐到幻觉治理，从长上下文的复杂度到智能体的容错闭环，全部围绕着一个词——系统思考。面试官要的不是一个能背下所有论文结论的人，而是一个知道每个技术选型背后代价的人。我在实际招聘中发现，能把"为什么用 KV Cache 而不把整层状态都缓存"这类问题答到"因为 Q 没有复用价值"这个粒度的人，踩过的坑一定不少；反过来，那些把 LoRA 的 rank 说得头头是道却答不出"量化后离群值怎么办"的人，简历再漂亮也得打问号。准备 LLM 面试，与其刷一百道题，不如找个开源模型从训练到部署完整跑一遍，把显存、精度、延迟、cost 全都亲手测一回。到那时候，这些问题不用背也能答得上来。