★ FEATURED ARTICLE 1. Transformer 基础题QKV 与 Tokenizer 背后的把关逻辑1.1 问题一Self-Attention 里为什么需要 Q、K、V 三个角色除以根号 d_k 又是为了什么面试现场最常出现的尴尬场面是候选人张口就背Attention(Q,K,V) softmax(QK^T / √d_k)V公式一个字母不差但当你追问为什么是除根号 d_k不是除 d_k也不是不除的时候对方开始支支吾吾。这个问题如果答不利索基本可以直接判定为背过八股但没真正理解 Transformer。先讲直觉。Q、K、V 三个角色可以类比成一个图书管理员在帮你找书的过程QQuery是你想要的书的主题KKey是每本书封面上写的标签VValue是书架上那本书的实际内容。你抱着查询目标 Q 去和每一本书的标签 K 做匹配匹配度越高就越多地从对应的书 V 里取出内容。Self-Attention 里每个 token 同时扮演三种角色它既要问别人谁和我相关也要回答别人我是谁最终把整个序列里所有相关信息按相关性加权聚合到自己身上。至于除以 √d_k这里有一个实打实的数学原因。假设 Q 和 K 里的每个分量是均值为 0、方差为 1 的独立随机变量那么它们做点积之后结果的方差会变成 d_k。d_k 越大点积的数值越大softmax 的输入分布在两端就被推得越远导致 softmax 进入到梯度极其平缓的区域反向传播时梯度趋近于零模型根本学不动。除以 √d_k 的本质是把点积结果的方差拉回 1 的量级让 softmax 的输入分布保持在一个梯度敏感的范围内。这是数值稳定性层面的设计不是随便拍脑袋选的系数。这个问题的加分项还在于能不能说清楚多头注意力。多个头本质上是多个并行的匹配器每个头被强制从不同的子空间去建模谁和谁相关有的头在学句法依赖有的头在学指代消解有的头在学语义相似度。面试官如果追问为什么需要多组 QKV 而不是一组更大的你要能点到单组注意力只能学习一种相关性模式而文本里的关系是多元的。淘汰级表现是只能默写公式说不出 QKV 的语义角色也解释不了缩放因子的意义。别小看这个问题我至少见过三分之一候选人在这一关就亮红灯了。1.2 问题二Tokenizer 只是分词吗BPE 和词表大小到底怎么影响模型能力很多候选人听到 Tokenizer 第一反应是这不就是个切词工具吗然后开始讲 jieba、讲空格切分。放在 LLM 语境下这种回答等于把送分题变成送命题。Tokenizer 直接决定模型能看到什么、每个 token 消耗多少上下文窗口、以及词表外词汇怎么处理它是整个模型能力链条的第一环。BPEByte Pair Encoding的核心逻辑不复杂初始时把文本拆成最小单元字符或字节然后反复统计相邻单元对的出现频率把最高频的相邻对合并成一个新单元一直合并到词表达到预设大小为止。这套算法最初是压缩领域的后来被 GPT 系列搬到语言模型里成了事实标准。字节级别的 BPE 还附带一个好处理论上任何 UTF-8 编码的文本都能被切分不会出现传统词表里没见过这个词就报 OOV的问题。但这里有个容易被忽略的坑token 数是按模型词表切出来的不是按词切出来的。同一个中文句子在不同 tokenizer 下的 token 数可能差很多。举个例子今天天气不错在部分中文语料优化的词表下可能切成三四个 token但在英文主导的词表下可能被切成六七个。而上下文窗口是按 token 计数的token 数直接决定了模型一次能读多少内容。很多做 RAG 的同学发现知识库文档老是塞不进上下文回头一查不是窗口太小是 tokenizer 对中文切得太碎。面试官常给的追问是为什么词表不是越大越好。答案是词表太大embedding 层和 LM head 的参数规模会爆炸词表大小乘以隐藏层维度两边都要存训练和推理的显存都扛不住词表太小每个 token 携带的信息量不足序列变长计算量上升。所以词表大小是一个参数效率 vs 序列长度的平衡主流模型大约在几十 k 到一百多 k 的量级。能聊到这一层才算真正理解了 Tokenizer 为什么值得被单独拎出来考。2. 预训练与位置编码理解模型如何学和记2.1 问题三为什么预训练一定用预测下一个 token而不是别的目标这个问题看似简单实际上是在考察候选人是否理解自回归语言模型的本质。如果你只回答因为 GPT 是自回归的所以预测下一个 token等于没说。要拆到概率建模那一层。语言模型做的事是估计一个句子的概率分布而联合概率可以按链式法则分解成条件概率的乘积p(x₁, x₂, ..., xₙ) ∏ p(xₜ | x₁, x₂, ..., xₜ₋₁)预测下一个 token就是直接对这个分解里的每个条件概率做最大似然估计。这里有个关键点条件概率的分解顺序是因果的——每个 token 只能看到它之前的内容看不到之后的内容。这不是偷懒而是为了让模型在生成时能逐 token 地采样生成 t 时刻的 token 只需要 t 时刻之前的信息生成的结果又追加进输入继续预测下一个。如果训练目标是预测中间被 mask 掉的 token类似 BERT 的做法模型天然就具备了双向信息这在分类任务上很好用但没法直接用来做自回归生成。更有意思的是世界知识从哪来这个问题。模型没有显式地存储任何知识库它只是在预测下一个 token 的任务里被迫把世界的规律压缩进了参数。比如要准确预测中国的首都是____后面的 token模型就必须在训练过程中记住这个事实。压缩即智能这句话在这个语境下是真实的预测得越准说明参数里隐含的世界模型越完整。进一步可以聊困惑度Perplexity。困惑度等于交叉熵损失的指数形式PPL exp(loss)它直观的含义是模型在每个位置上平均有多少个候选 token 感到困惑。PPL 在训练集上持续下降说明模型的预测分布越来越集中到真实答案上但如果 PPL 在验证集上回升那基本就是过拟合。这一问的淘汰点在于候选人把预测下一个 token当成一个操作细节而不是整个自回归范式的数学基础。2.2 问题四RoPE 为什么能取代绝对位置编码长上下文又靠它做了什么从早期的 Transformer 开始位置编码就是一个绕不开的话题。Self-Attention 本身是置换等变的——你把我打你和你打我的 token 顺序调换注意力计算的权重完全一样但语义完全相反。所以必须显式地把位置信息注入进去。最原始的 Transformer 用正弦函数生成绝对位置编码每个位置有一个独一无二的向量后来也有人直接让位置向量参与训练。这两种方式有一个共同毛病模型只能记住训练时见过的绝对位置模式一旦推理时的序列长度超过训练长度那些没见过的新位置对应的编码就变成模型从未学习过的输入效果断崖式下跌。这就是所谓的外推性差。RoPERotary Position Embedding思路完全不一样。它不是给 token 加一个位置向量而是对 Q 和 K 的向量做旋转操作——每个 token 按其绝对位置旋转一个角度再去做点积。这里有一个漂亮的数学性质旋转可分解两个 token 的 Q、K 做点积时结果只依赖于它们的相对位置差而不是各自的绝对位置。这一下就把相对位置关系内建到了注意力分数里模型对未见过的更长序列具备更好的泛化能力。面试官再往下追问往往会落到长上下文上。只说RoPE 支持长文本是不够的你应该能提到原始 RoPE 在超过训练长度后依然会退化所以要配合插值类方案比如 NTK-aware 缩放、YaRN 或者直接做长上下文继续预训练。这些方法的本质都是把旋转频率做调整让已有的位置编码模式摊开覆盖到更长的范围。这个问题的淘汰点是候选人只听说过 RoPE 这个名字不知道它解决的是绝对位置编码的外推缺陷也说不出旋转为什么能和相对位置产生联系。3. 推理效率的送命题KV Cache、解码策略与量化取舍3.1 问题五KV Cache 是什么为什么模型生成越来越慢却还要缓存这个问题在 LLM 推理岗面试里出现频率极高因为它直接关乎线上服务的吞吐和延迟。答不上来说明你根本没跑过真实的大模型推理服务。先说痛点。自回归生成是一个逐 token 的过程生成第 t 个 token 时模型要把前 t-1 个 token 的完整序列重新过一遍 Transformer。如果不加任何缓存每生成一个新 token 都要对前面所有 token 重新算一遍注意力计算量是序列长度的平方级。这在实际部署中是完全不可接受的。KV Cache 的优化思路非常直白注意力计算里每个 token 的 K键和 V值只和它自身有关和后面的 token 无关。所以前面 token 的 K、V 算过一次之后就可以缓存起来下次生成新 token 时只算新 token 的 K、V然后和缓存的 K、V 拼在一起做注意力。这里有一个关键细节缓存的是 K 和 V而不是 Q。因为新的 Q 每次都在变但前面 token 的 K、V 一旦算出来就不变了。所以缓存矩阵的形状大致是[batch_size, num_heads, seq_len, head_dim]K 和 V 各一份。但缓存带来了一个新问题推理越到后面越慢。新 token 的注意力计算必须和缓存里所有的 K、V 做矩阵乘所以序列越长单个 token 的延迟越高——生成阶段的时间复杂度是 O(序列长度) 的。很多人在本地跑模型时会发现刚开始出字飞快越出越慢就是 KV Cache 不断变长的直接后果。显存账本更应该算清楚。以 7B 参数的 LLaMA 结构为例40 层 Transformer32 个注意力头每个头的维度 128FP16 精度每元素 2 字节。每个 token 的 KV Cache 占用为2K 和 V× 40层× 32头× 128维度× 2 字节 655,360 字节 ≈ 0.625 MB当上下文长度到 4096 时单条序列的 KV Cache 要占约 2.5 GB。8 条序列并发就是 20 GB这个开销比模型权重本身还大。所以现在很多优化都是冲着压缩 KV Cache 去的GQA分组查询注意力、MQA多查询注意力、MLA多头潜在注意力都是让多个 Q 头共享同一组 K、V把缓存体积降一个数量级。能把这个显存账本当场算给面试官看这一题的印象分远超我调过 vLLM这种空话。3.2 追问延伸GQA、量化与本地部署时的实际取舍面试官通常不会只问你 KV Cache 是什么就放你走他会顺着推理效率继续往下探。几个最常见的追问方向第一个是 GQA 和 MHA 的对比。标准多头注意力MHA里每个头都有独立的 K、V缓存最大MQA 是让所有 Q 头共享一组 K、V缓存最小但表达能力下降GQA 是折中方案把 Q 头分成若干组组内共享 K、V。现在的开源模型比如 LLaMA 2/3、部分国产开源模型很多用 GQA就是为了在显存和效果之间取平衡。第二个是量化。面试里聊到 GGUF、GPTQ、AWQ 这些格式的时候核心要讲清楚量化是把权重从 FP16 压缩到 INT8/INT4模型文件变小推理时访存量减少单 batch 延迟下降代价是精度损失。但要注意量化主要省的是权重显存KV Cache 依然是 FP16 或 BF16 的所以大上下文场景下KV Cache 可能成为新的显存瓶颈。现在也有 KV Cache 量化的方案但属于进阶玩法能提到就已经超过大多数候选人了。第三个是解码策略。有候选人把温度temperature、top-p、top-k 和 KV Cache 混为一谈这属于概念不清。解码策略管的是下一个 token 怎么从概率分布里采样和注意力计算是否复用完全无关。好的回答方式是先讲清楚贪婪解码、随机采样、温度缩放各自解决什么问题再点一句解码策略影响生成质量KV Cache 影响生成速度两者是正交的。这一章我额外想提醒如果你是做本地部署、端侧推理方向的候选人最好真的在本地拿一个 GGUF 格式的小模型跑一遍观察不同上下文长度下每 token 生成延迟的变化。这段真实体感在面试里说出来比你背十篇博客都管用。4. 从 SFT 到 RLHF/DPO对齐能力是面试分水岭4.1 问题六SFT 之后为什么还要 RLHFDPO 又是怎么把 RLHF 变简单的对齐Alignment几乎是现在 LLM 岗位面试的必答区而且很多人在这里死得很难看。最典型的错误回答是RLHF 就是在人类反馈上做微调然后就开始讲怎么收集标注数据——这暴露了候选人完全没搞懂强化学习这个环节的必要性。先讲清楚 SFT 的局限。SFT监督微调做的事情是给模型一堆用户问——理想回答的样例让它模仿这些回答的分布。问题在于SFT 只能学到一个平均化的好回答它不理解什么回答更好也不会主动去优化好的方向。更麻烦的是SFT 数据里人的偏好并不充分同一个问题可能有多个合理的回答模型从中学到的是概率分布而不自觉地给那些看起来像训练数据的回答更高概率包括一些有毒或偏见的表述。RLHF基于人类反馈的强化学习的思路分三步。第一步还是 SFT得到一个会说人话的基础模型。第二步训练一个 Reward Model奖励模型给同一个 prompt 配上两个回答让人类标注哪个更好训练 RM 学会预测人类偏好的分数——这里通常用 Bradley-Terry 模型来建模成对比较的概率。第三步用强化学习经典实现是 PPO优化策略模型让模型在最大化奖励分数的同时不要离 SFT 模型太远。第三部里的 KL 惩罚往往是面试官追问的重点。如果只让模型最大化奖励它会迅速找到奖励模型的漏洞输出一些刷分但没人真喜欢的废话。所以目标函数里必须加一项和参考策略之间的 KL 散度约束像是给马戴上缰绳——让它往奖励高的方向跑但每一步都不能跑离原来的语言风格太远reward r_θ(x, y) - β · KL(π_φ(y|x) || π_ref(y|x))DPO 是这两年炙手可热的替代方案它的洞察非常巧妙既然 Bradley-Terry 偏好模型有解析解那完全可以把强化学习优化策略这件事改写成监督学习直接拟合偏好数据。DPO 不需要单独训练 Reward Model也不需要在线采样和 PPO 那一套复杂的强化学习流程它只用和 SFT 一样的训练方式在好回答 vs 差回答的成对数据上直接更新策略。效果上DPO 在很多场景和 RLHF 接近但工程复杂度低得多。这个问题的加分表现能画出 RLHF 的三段式流程能解释 PPO 目标函数里每一项的作用能对比 RLHF 和 DPO 各自在训练稳定性和数据需求上的差异。能做到这些说明你不仅用过而且想过为什么。4.2 面试常见误区把 RLHF 当成用反馈再做一次 SFT我面试时很喜欢用一句话来辨析概念SFT 学的是什么话像人话RLHF/DPO 学的是什么话是人喜欢的。这两个目标有本质差别。很多候选人把人类反馈理解成把标注好的好坏数据丢进去继续训练然后就开始讲数据清洗、讲标注规范——这些确实是工程环节但不是 RLHF 的核心机理。这里可以顺便接住热搜词里llm怎么数据标注这个话题。做对齐用的偏好数据标注规范和 SFT 数据完全不同SFT 数据只要回答正确、格式规范就行偏好数据必须成对出现而且两个回答之间要有可感知的质量差异否则标注员只能瞎猜RM 学到的是噪声。实际标注中最常见的问题是两个回答都好或者两个回答都差这类样本对训练几乎无益还会让偏好模型变得不确定。所以经验上做偏好数据标注时要设计明确的评价维度准确性、有帮助性、安全性、格式规范等并且保证同对两个回答的质量差足够明显。DPO 面试还经常有一个坑候选人答DPO 不需要人类反馈。这是错的——DPO 只是不需要奖励模型和强化学习循环它依然需要成对的偏好数据而这些数据依然来自人类标注或用强模型生成后用规则过滤。DPO 改变的是优化方式不是数据来源。能把这条边界划清楚面试官基本就能确认你真的理解 DPO 而不只是听过名词。5. RAG 与幻觉治理从检索到生成的全链路5.1 问题七RAG 为什么能缓解幻觉它和微调在什么场景该怎么选大模型应用岗面试几乎没有不聊 RAG 的。但很多候选人的回答就停在把知识库向量化然后查相似度拼到 prompt 里——这个回答太浅了。面试官真正想听的是你理解幻觉的根源是什么RAG 到底在哪一环缓解了它以及它什么时候失效。先理解幻觉根源。LLM 的所有知识都藏在参数里它的回答本质上是对参数化记忆的概率采样。当一个问题超出了它的参数记忆范围或者记忆本身是模糊的、矛盾的模型依然会给出一个听起来流畅的回答——这就是一本正经地胡说八道。幻觉本质上是生成式模型无法区分我知道和我不知道。RAG 缓解幻觉的机制是把答案的出处从参数记忆切换到外部检索结果。系统先从知识库里检索出相关片段喂给模型让模型基于这些片段做阅读理解式生成。模型的角色从回忆者变成转述者。如果检索到的内容里有明确的答案依据模型生成的内容就有事实锚点幻觉概率大幅下降就算模型不知道答案它也更倾向于说根据提供的内容无法回答而不是硬编。那 RAG 和微调怎么选这是面试官的经典追问。我的经验判断逻辑是这样的场景推荐方案原因知识快速更新、量大海量、需要引用来源RAG不重新训练随时增删文档可追溯改变模型的表达风格、输出格式、领域话术微调RAG 改不了行为习惯只能给上下文私有数据量小但要求模型内化到推理能力微调/RAG 混合单靠 RAG 模型不会想得像领域专家要求可解释、可审计、能指出答案来自哪一篇RAG微调的结果没法指向某个文档片段需要降低单次推理成本、简化系统架构微调RAG 每次都要检索大上下文链路更重一个更深刻的点是两者不互斥。RAG微调经常一起用微调负责把模型调教成会按某种格式输出、会用某种语气回答RAG 负责提供回答什么的事实素材。能把两者协同的逻辑讲清楚这一问基本就稳了。5.2 工程细节chunk 切分、混合检索、rerank 这些环节怎么串起来纸面上的 RAG 流程很简单工程上脏活累活全在细节里。这一小节我按个人实际做项目的经验把三个最容易翻车的环节讲透。第一个是切分Chunking。很多人无脑按固定字符数切块然后发现检索质量一塌糊涂。切分的核心矛盾是chunk 太小单块信息不完整检索到的片段缺少上下文chunk 太大一个块里混入多个主题向量表示被平均掉检索精度下降。我的经验是先按文档结构切标题、段落、表格保持语义完整性再用固定大小做兜底防止有的文档没有结构最后配合父块-子块策略——用小块做检索召回命中后把小块所在的更大父块一起送给模型这样既能精确定位又不丢失上下文。图片里的规则表格、PDF 里的多栏排版这些脏数据如果在切分前不处理后面所有环节都是白搭。第二个是检索Retrieval。纯向量检索embedding 相似度有两个天然缺陷对精确词匹配不敏感比如产品编号、人名、公式对语义接近但实际无关的内容容易误召回。可靠做法是混合检索传统 BM25 做词法匹配向量检索做语义匹配两者各自召回一批再用 RRFReciprocal Rank Fusion融合排序。这个组合在绝大多数知识库问答里的表现都优于单独任何一种。第三个是重排Rerank。向量检索返回的 top-k 是按向量相似度排的这个排序和文本是否真的回答了问题不是一回事。所以正规一点的 RAG 链路里先召回粗排的 top-50 或 top-100再过一个 reranker通常是一个 cross-encoder 模型把 query 和每个候选文档直接拼在一起编码打分取出 top-5 给大模型。多花一次模型推理的时间换来的是问答准确率的大幅提升。做 RAG 落地这一步建议直接加性价比非常高。面试时如果能说到这一层——从为什么 RAG 能缓解幻觉到chunk、混合检索、rerank 各自解决什么具体问题——你已经不是在背概念而是在分享真实系统的设计思路。6. Agent 可靠性与容错控制最后一道必问题6.1 问题八LLM Agent 的工具调用输出不稳定你是怎么在工程上兜底的Agent 是现在 LLM 应用最热的方向但面试问 Agent 极少问你会不会调 function calling而是问你的 Agent 出错的时候怎么办。看过真实系统的都知道Agent 的不可靠是常态而不是异常LLM 输出工具调用参数时可能漏字段、可能给错类型、可能编造一个根本不存在的参数名、可能一次要并行调五个工具但其中两个是幻觉出来的。更麻烦的是Agent 是串联执行的第一步错了后面每一步都在错误的基础上继续错误会被放大。这里正好接住热搜词里那条识的llm智能体自主容错控制:构建可靠ai系统的工程实践。我的理解是Agent 的容错不是事后补救而是一个必须前置设计的系统能力。如果只是一个try-except 包一层的做法线上的错误率会教你做人。可靠性的第一层是让模型不容易输出错。可用的手段包括工具调用的入参严格走 JSON Schema 约束返回错误时让模型自己修正后再试一次。现在不少开源框架支持对解码过程做约束——不是模型随意生成文本而是按预先定义的 JSON 结构逐 token 约束生成模型只能在你定义的字段名和类型范围内输出。这比生成了之后再 parse 一次靠谱得多。第二层是校验与重试机制。工具返回后要程序化校验结果是否符合预期字段是否齐全、数值是否在合理范围、外部 API 是否返回了业务错误。校验不过就进入重试逻辑重试要带上前一次的错误信息让模型复盘——比如提示它你刚才生成的参数 start_date 格式是 2024/1/1但要求的格式是 ISO 8601请重新生成。这一层的核心是把每一次失败变成下一次生成的上下文。第三层是流程级的自纠错闭环。Agent 跑完一个多步任务后应该有一个反思reflection步骤让模型总结自己做了什么、拿到什么结果、中间哪一步可能出错然后决定是直接交付还是再执行一轮修正。更严格的做法是引入状态机把 Agent 的每一步建模成明确的状态转移非法转移直接拦截。这些机制看着简单但面试时能画出完整的生成-校验-回退-重试链路的人百里挑一。6.2 三道防线的具体玩法结构化约束、校验重试、自纠错闭环展开说说实际落地的细节。因为这一问往往决定了高级岗和初级岗的区分度。结构化约束不做事后解析而是在生成时就把输出框死。实践中有两类手段一类是平台内置的 tool calling模型被训练成直接输出符合要求的 tool_call 结构另一类是开源框架里的约束解码模型每生成一个 token 都检查是否符合预先定义的 JSON Schema不合法就禁止生成。后者的优点是可控性强缺点是约束过死可能影响生成的多样性更适合工具调用这种字段少、结构固定的场景。校验重试要注意重试次数不是越多越好。我的经验是最多重试两轮。第一轮让模型根据报错重新生成第二次如果还失败大概率是这次任务本身超出了模型能力继续刷重试只会浪费时间。应该降级到 fallback 流程比如改用另一个更小但更稳定的模型、或者直接把这个任务标记为失败移交人工处理。记住你构建的是系统不是单模型的玩具可靠性来自流程设计。自纠错闭环的精髓在于让模型看到中间结果。很多 Agent 框架把工具调用封装成黑盒模型只拿到最终输出中间过程报错了它完全不知道。应该把中间的关键信息比如执行到哪一步、每一步的置信度、哪个参数被修正过都回馈给模型它才有机会在下一步做出正确决策。我在实际部署里还会给每一步加上时间预算和 token 预算防止 Agent 陷入死循环式的自我修正把上下文撑爆。这一题真正的送分点其实是主动说清楚你的 Agent 在哪些场景会失败。面试官问的不是完美方案而是你有没有见过失败、分析过失败。只要你能诚实地列举两三个容错场景并给出对应的防线设计这一关基本就到高分区了。7. 面试官视角的答题心法从背答案到讲清楚7.1 一个能救命的回答框架现象 → 原因 → 解决 → 边界讲完八个具体问题最后聊点场景化的软技能。我面试过太多候选人知识面是有的坏就坏在答题没有章法问一句答一个知识点挤牙膏一样。面试官无法判断你究竟是理解了还是背熟了。我推荐一个四段式回答框架基本适用于全部技术题现象 → 原因 → 解决 → 边界。以为什么生成越来越慢为例。现象模型刚开始出字很快后面越来越慢。原因KV Cache 越来越大每个新 token 都要和全部历史 K、V 做注意力计算。解决引入 GQA 减少缓存体积或者做上下文压缩。边界缓存增长的拦路人是注意力机制的线性复杂度所以根本解法是换注意力架构比如线性注意力。这个框架好在哪它让面试官看到你有一个完整的思维闭环你观察到了什么、怎么诊断、怎么解决、以及这个解决的天花板在哪。大多数候选人只讲到第二步原因是注意力二次复杂度然后停下来等下一个问题。多走哪怕一步所以 KV Cache 优化才有价值你的答案就已经赢过同场的七八个人了。反过来如果面试官抛出一个你没准备过的问题也可以用这个框架临时组织语言。先承认问题在你的知识盲区然后从现象层面复述一遍我理解你问的是……再给出你已知的部分和可能的分析方向。面试官通常更在意你的思考过程而非结论本身。7.2 动手验证清单哪些实验能在面试里成为你的加分证据回答题面之外还有一个隐性加分项你亲手做过什么。在 LLM 面试里空谈原理不如一句我自己跑过……有说服力。以下几类动手经验性价比最高在本地跑过一个量化后的开源模型GGUF 格式就能跑观察过不同上下文长度下的生成延迟。这能让你在聊 KV Cache、量化时言之有物。用框架搭过一个完整的 RAG 最小系统调过 chunk 大小对比过固定切分 vs 按结构切分的检索质量。这会让你对第 5 章的问题有亲身体感。给一个开源模型做过一次偏好数据标注哪怕只是几十对你也能真正理解两个回答差距不明显时标注有多痛苦以及 DPO 数据为什么难做。搭过一个带工具调用的 Agent demo故意让它出错给它录一段失败日志再设计重试逻辑。做过这个第 6 章你要讲容错控制就全是真实案例。最后分享一个我自己的习惯面试前先不看面经而是把每个问题当成我要给一个刚入门的同事讲明白来准备在心里默讲一遍卡住的地方就是你还没懂的地方。八道题覆盖了从 Transformer 原理到对齐、推理、RAG、Agent 的完整链路它们不是孤立的八块知识而是一条链——模型怎么训练、怎么对齐、怎么推理、怎么落地应用。能把这条链串起来讲清楚的人面试官自然能判断出你不是在背题而是真的在这个领域里做过事。祝各位面试顺利。
阅读完成 · 觉得有帮助？
