企业官网建设流程全解析

1. 面试官为什么盯着这 8 个问题不放

这几年我以面试官身份面过上百个 LLM 方向的候选人，简历一个比一个漂亮——"精通大模型""熟悉 Transformer 架构""有 RAG 落地经验"写满一整页。但很多时候，前三个问题问完，我心里基本已经有答案了。不是因为他答错了哪个知识点，而是因为他全程在背概念、贴术语，却说不清最简单问题背后的"为什么"。

这 8 个问题，是我在实际面试中沉淀下来的一套"筛人漏斗"。它们不偏不怪，全是 LLM 领域绕不开的底层问题，覆盖了四个层面：模型结构、训练对齐、推理部署、应用工程。面试官问这些问题，本质上是在做一个分层筛选。

1.1 一套题筛三类候选人

第一类，只调过 API 的"使用者"。这类人熟悉 prompt，会调 OpenAI 或者国产大模型的接口，聊起产品功能头头是道，但模型内部到底发生了什么，一概不知。问 self-attention 的 QKV 是什么，他能把公式默写出来，但问"为什么要除 sqrt(d_k)"就卡住。

第二类，读了不少论文但没动过手的"理论派"。概念能背、公式能抄，但一问到"SFT 数据怎么标注""部署时 KV cache 占多少显存""GGUF 的 Q4_K_M 和 Q5_K_M 实际差多少"就露馅。这类人最可惜，花了大量时间刷面经，却缺少把知识落地的路径。

第三类，真正做过项目的"工程实践者"。跑过训练、调过推理、修过线上 bug，能把原理和工程串成一条线。比如聊量化，他能从权重分布讲到实际部署时选哪一档量化位数的取舍。绝大多数 LLM 岗位，哪怕初级岗，要的都是这种人。

1.2 八道题的分布逻辑与淘汰信号

我把这 8 个问题按面试中习惯的提问顺序列成一张表，每个问题对应一个明确的考察信号，你对照一下就明白自己卡在哪层：

说白了，答不上来直接淘汰，不是因为这些问题本身有多难，而是它们在面试官心中对应着一个朴素的判断：一个连自己天天在用的工具的最基本原理都讲不清楚的人，很难让人相信他能解决未知的问题。下面我把这 8 个问题逐个拆开，每个问题都会给出面试官的真实意图、能过关的回答思路，以及我见过的高频翻车点。

2. 前两题：Transformer 内部机制，一开口就知道你真懂还是背过

2.1 问题一：self-attention 是怎么计算的？为什么它能取代 RNN？

这道题几乎是 LLM 面试的"开场白"。答得好不好，直接决定面试官后面是用初级难度还是高级难度和你聊。

先说考察点。面试官不想听你把 QKV 公式默写一遍，而是想知道：你真的理解 Query、Key、Value 各自是干什么的，为什么 softmax 之后要加权求和，以及 attention 相比 RNN 的本质优势是什么。

一个能过关的回答，我建议按下面这个顺序展开。

第一，用直觉解释 QKV。Query 是"你想找什么"，Key 是"每个 token 的标签"，Value 是"每个 token 携带的内容"。计算过程就是拿 Query 去和所有 Key 做匹配打分，然后把所有 Value 按匹配度加权汇总。我面试时常打的一个比方是：这就跟去档案室查资料一样——你要查"今年营收"（Query），档案袋标签就是 Key，档案内容就是 Value，最后挑出最相关的几份内容抄下来组合成答案。

第二，给出公式并解释每个部件。score = softmax(QK^T / sqrt(d_k)) · V。为什么除以 sqrt(d_k)？因为 Q 和 K 的维度越高，点积结果的方差就越大，softmax 会直接进入梯度极小的饱和区。除以 sqrt(d_k) 是为了把方差拉回可控范围，让 softmax 的梯度能正常流动。这是非常经典的追问点，能主动讲出来很加分。

第三，说复杂度。self-attention 的时间和空间复杂度都是 O(n²)，这是后面几乎所有长上下文优化问题的出发点。先把这个锚点立住，后续聊稀疏注意力、滑动窗口、位置插值时才有参照系。

第四，对比 RNN。RNN 的信息传递是串行的，要理解一个远处的词，信息得一步一步传过来，好比传话游戏，传着传着就失真了。attention 则直接建立任意两个 token 之间的依赖关系，信息一步到位。这是它能成为大模型核心的根本原因——你不需要沿着时间步一步步走，而是可以"跳着看"。

这道题最常见的翻车现场有两个。一个是把 attention 说成"加权平均"，这没错，但漏掉了关键点：权重不是手工设计的，而是每个 token 作为 Query，动态和所有 Key 算出来的。另一个是死记 softmax 之前的缩放，一问"不除会怎样"就答不上来。这两个坑几乎能筛掉一半背公式的候选人。

2.2 问题二：为什么需要多头注意力？现在主流模型在结构上改了什么？

这道题是问题一的自然延伸。如果候选人能答出多头，我通常紧接着追问：那你知道现在 LLaMA、Qwen 这些主流模型，在原始 Transformer 结构上做了哪些改进吗？这一问能筛掉一大批只读过《Attention Is All You Need》原文的人。

多头注意力的核心动机是"一种注意力分布不够用"。单头注意力把所有信息都塞进一个分布里，但一个句子里词与词之间，可能同时存在语法依赖、语义关联、指代关系等多种不同类型的关联。多头就是让模型用多组 QKV 并行计算，每组学一个子空间里的注意力模式，相当于多个专家从不同角度观察同一个句子，最后把结果拼起来。原始论文里有可视化证明，8 个头各自关注的是不同类型的模式，比如有的头关注语法关系，有的头关注指代关系。

至于现代模型的结构改进，我建议至少答出三点：

• RMSNorm 替代 LayerNorm。LayerNorm 要做均值减法再除方差，RMSNorm 发现均值减法的收益有限，干脆只保留"除以 RMS"这一步，省掉一部分计算，训练还更稳定。现在主流开源模型基本都用 RMSNorm。
• RoPE 旋转位置编码。这个在问题五详细说，先记住它是把位置信息以旋转矩阵的形式编码进 Q 和 K，让注意力分数天然依赖相对位置，外推能力更好。
• GQA（分组查询注意力）替代 MHA。标准多头注意力每个头都有自己的 K、V，推理时缓存压力大。GQA 让一组头共享同一份 K、V，只对 Q 保持多头，显存占用大幅下降，效果损失却很小。LLaMA 2/3、Qwen 等模型都在用。

这道题有个很大的加分项：能把 GQA 和推理时的 KV cache 联动起来讲。GQA 之所以流行，不只是训练效率问题，更重要的是它直接砍掉了推理时 KV cache 的显存占用。能说出这一层，说明你不是孤立地背知识点，而是把模型结构和推理工程串在了一起，面试官对你的印象会立刻不一样。

3. 中间三题：训练、对齐与 Tokenizer，考你是不是真做过模型

3.1 问题三：预训练、SFT、RLHF/DPO 分别在做什么？为什么不能只做 SFT？

先说结论：这三者解决的是不同层次的问题，缺一不可。

预训练是"学知识"。在海量文本上做下一个 token 预测，让模型学到语言结构、世界知识和常识。这个阶段数据量最大，动辄上万亿 token，算力消耗最高，产出的基座模型"什么都会一点，但不太会听话"。

SFT 是"学规矩"。用人工标注的"指令-期望回答"数据，教模型听懂人类指令、按要求的格式回答。它解决的是"行为对齐"问题：基座模型很会续写，但不会聊天，SFT 让它学会对话的格式和套路。

这里必然要聊到数据标注。面试官如果问"SFT 数据怎么标注"，他其实在考察你有没有真正组织过数据生产。我做过 LLM 数据标注相关的项目，实话实说，这个环节的坑比训练本身多得多。不是写几万条"问题-答案"就完事，核心指标是覆盖度和质量：

• 覆盖度：指令类型要广，包括问答、改写、总结、抽取、多轮对话、拒绝回答等，不能只堆同一种形式。
• 质量：一条坏数据对模型行为的影响比想象中大，漏标、错标、前后矛盾的标注都会让模型学到错误模式。
• 去重：重复数据过多会导致模型对某些表达过拟合，表现为"只会一种说法"。
• 抽检：要有人工质检环节，定期抽样看标注一致性，不一致率超过阈值就得返工。

RLHF 是"学偏好"。SFT 只告诉模型"什么是好的回答"，但没说"哪些回答更受人类喜欢"。RLHF 的思路是：先训练一个奖励模型，专门给回答打分，再用强化学习（PPO）让模型朝高奖励方向优化，于是回答更符合人类偏好——更有帮助、更诚实、更安全。

DPO 是 RLHF 的简化版。它不需要单独训练奖励模型，也不需要 PPO 那套复杂的采样和策略更新，直接用偏好数据（同一 prompt 下一条好回答、一条坏回答）计算 loss，引导模型学会偏好好回答。实现简单、训练稳定，现在很多开源项目都用 DPO 做对齐。

面试官为什么爱问这个问题？因为它直接暴露你是"调 API 的"还是"做过对齐的"。只调 API 的人能说出 SFT 和 RLHF 的名字，但说不清 PPO 里为什么需要奖励模型、DPO 为什么能省掉奖励模型。真做过的人能讲清楚自己踩过的坑——偏好数据怎么构造、reward hacking 怎么处理、DPO 的 β 参数调大调小有什么影响。

我见过最典型的翻车点，是把 SFT 和 RLHF 混为一谈，说"RLHF 就是给 SFT 数据加偏好打分"。实际上二者的数据形态完全不同：SFT 需要的是完整的指令-回答对，RLHF/DPO 需要的是同一 prompt 下的多个回答及好坏排序。连数据长什么样都说不清，基本可以确定没亲手做过。

3.2 问题四：Tokenizer 是干什么的？为什么"strawberry 里有几个 r"这种问题 LLM 会答错？

Tokenizer 是把文本切成 token 的组件，它决定了模型"看到的"输入单位。主流方案是 BPE（字节对编码），逻辑说起来很直白：从单字符级别的词汇表出发，反复合并语料里出现频率最高的相邻 token 对，最终形成一个固定大小的词汇表，常见规模在 32k 到 100k 之间。

BPE 的价值在于平衡了词汇表大小和序列长度。如果只用单字，序列会过长，计算量爆炸；如果直接用整词，词汇表会大到不可控，而且永远漏掉新词。BPE 用子词表示，既压缩了序列长度，又能通过子词拼接覆盖没有见过的新词。

这道题面试官真正想听的是两件事：一是 BPE 的合并逻辑，二是 tokenization 对模型能力的实际影响。后者有个绝佳的案例——"strawberry 里有几个 r"。很多 LLM 答错，不是推理能力差，而是 strawberry 会被 tokenizer 切成类似 ["st", "raw", "berry"] 这样的子词，模型根本"看不见"完整的字母串，自然数不清其中有几个 r。换句话说，模型处理的是 token 序列，不是字符序列。这个例子只要能自己讲出来，面试官就知道你对 tokenizer 的理解不只是名词层面。

再补一个加分点：中文场景下的 token 效率。英文一个单词通常占 1 个 token，中文一个汉字也差不多 1 个 token，但中文信息的"密度"更高。同样表达一段话，中文消耗的 token 数往往比英文更少。这在按 token 计费、上下文窗口受限的真实场景里非常关键。如果面试官追问"为什么有些模型中文效果差"，可以从三个角度回答：中文语料在预训练数据里的占比、中文分词的质量、tokenizer 词表对中文字符的覆盖设计。

3.3 问题五：位置编码有什么用？RoPE 为什么成了主流？

如果 self-attention 不知道词的位置，那"猫追狗"和"狗追猫"在计算注意力时是完全对称的——attention 本身对输入顺序不敏感，它只计算 token 两两之间的关系，不关心先后顺序。位置编码的任务，就是把顺序信息注入模型。

早期的 Transformer 用绝对位置编码，正弦余弦函数或者可学习的嵌入向量，给每个位置一个固定"标号"。缺点是外推能力差：训练时最长见过 2048 个位置，推理时给它 3000 个 token，后面 900 多个位置的编码是它从没见过的，效果直接崩掉。

RoPE 的思路完全不同。它把位置信息"旋转"进 Q 和 K 的向量里，两个向量各自旋转，再算点积时，结果里就天然带上了相对位置信息——两个 token 离得越远，旋转角度差越大，点积结果的变化也越大。这样做的好处是模型学到的是相对位置关系，而不是绝对位置标号，天然更容易推广到更长序列。现在 LLaMA、Qwen、DeepSeek 这些主流模型基本都用 RoPE 或它的变体。

如果答到这里，还能主动补一句"长上下文场景下会配合位置插值或者 NTK-aware scaling，调整 RoPE 的旋转频率，让模型在更长序列上保持稳定"，那这道题基本满分。这个细节很能说明你实际跑过长文本实验，而不只是看了几篇博客。

4. 第六题：推理优化与部署，纯理论选手在这里原形毕露

前五题答得再好，只能证明你"懂模型"。第六题开始，面试官要考的是"你能不能把模型跑起来、跑得快、跑得稳"。这一题的高频追问组合是：KV Cache 是什么？量化原理是什么？GGUF 是什么？vLLM 为什么快？端侧部署要注意什么？四连问下来，工程底子基本摸清。

4.1 KV Cache：为什么只缓存 K 和 V，不缓存 Q？

LLM 推理是逐 token 生成的：每生成一个新 token，都要拿这个 token 的 Query 去和前面所有 token 的 Key、Value 算注意力。注意一个关键事实：前面 token 的输入没有变化，所以它们算出来的 K、V 也不会变化。于是完全可以把之前算好的 K、V 缓存起来，每次只算新 token 的 Q，再拿它去和缓存的 K 做点积，这就是 KV Cache。

为什么不缓存 Q？因为 Q 只在生成当前 token 时用一次，用完就不会再有人拿它去和别的 K 做点积了。这个细节我几乎每次都会追问，很多候选人能答出"有 KV Cache 这个东西"，但说不清为什么只缓存 K 和 V。说不清，就说明没自己推过推理过程。

KV Cache 是显存大户。一个 7B 模型，粗略估算每个 token 的 KV cache 大小大约是：2（K 和 V 两份）× 层数 × 注意力头数 × 每个头维度 × 2 字节。跑起来你会发现，几千 token 的上下文就能吃掉几个 GB 显存。这也是 GQA 存在的关键原因——共享 K、V 的头直接让缓存量降到原来的几分之一。这两点能连起来讲，面试官会明显对你更感兴趣。

4.2 量化与 GGUF：端侧部署的甜点位

量化的本质，是用更少的比特表示模型权重。FP16 下每个权重占 2 字节，量化到 INT8 是 1 字节，INT4 是 0.5 字节，模型体积直接减半甚至减到四分之一。为什么可行？因为神经网络权重的分布比较集中，里面大量低阶精度信息对最终推理结果并不关键，冗余是可以被压缩的。

实现上分两大类：训练后量化（PTQ，代表是 GPTQ、AWQ）和量化感知训练（QAT，效果更好但成本更高）。按对象分，可以只量化权重（weight-only），也可以连激活值一起量化。GGUF 是 llama.cpp 生态的模型格式，专门为 CPU 和端侧部署设计，常见的 Q4_K_M、Q5_K_M 就表示 4-bit 或 5-bit 量化配合特定的分布优化策略。现在很多人拿安卓手机跑本地大模型，用的就是 GGUF 格式加 llama.cpp 的安卓端封装，8GB 内存左右的手机已经能流畅跑 7B 级别的 Q4 量化模型。这是很典型的端侧 LLM 落地场景，聊到这里面试官一般会追问你实际跑过没有、效果如何。

4.3 vLLM 加速背后的两个关键设计

vLLM 为什么比传统推理快那么多？核心是两件事：continuous batching（连续批处理）和 PagedAttention。

传统推理是等一个 batch 全部生成完再换下一批，等待期间 GPU 大量闲置。vLLM 换了个思路：每生成完一个 token，就把对应的序列移出 batch，同时塞进新请求，让 GPU 始终处于满载状态。这个思路看起来简单，但对调度器的要求极高。

PagedAttention 则借鉴了操作系统虚拟内存的思想，把 KV cache 切成固定大小的块，按需分配，不像传统方式那样预分配一整块连续显存。这样几乎消除了显存碎片和浪费，相同显存下能容纳更多并发请求。这两个概念能讲清楚，说明你真的部署过、对比过吞吐，而不是只会调个 API 接口。

4.4 部署中我踩过的两个典型坑

第一个坑：量化位数不是越低越好。Q4 以下（比如 Q2、Q3）的模型，在复杂推理任务上能明显感觉到"智商下降"，回答变得机械、丢细节。我在实际项目里对比过，Q4_K_M 基本是体积、速度和质量的甜点位，再低就得认真评估任务能不能接受。面试时能主动说出这一步取舍，比背一百个量化名词都管用。

第二个坑：KV cache 大小直接决定并发上限。线上服务如果只按模型显存规划而忽略 KV cache，请求一多就开始 OOM，表现为"响应越来越慢甚至直接崩溃"。我习惯在部署前先用压测脚本测出"最大并发 × 上下文长度"的安全组合，给线上留足余量。

5. 最后两题：RAG 与微调的选型、幻觉与评估，考你有没有真实战

5.1 问题七：什么场景用 RAG，什么场景用微调？两者怎么配合？

这道题没有标准答案，面试官想听的是你的决策框架和踩坑经验。一个稳妥的回答框架是"按需求类型分"：

• 需要不断更新的知识、需要引用来源、需要低成本起步 → 选 RAG。企业内部文档问答、客服助手、政策法规问答都是典型场景，知识库经常变，微调跟不上，RAG 改个索引就能更新。
• 需要改变模型的"行为方式"、语气风格、输出格式、特定领域表达 → 选微调。比如让模型从通用助手变成固定格式的客服话术，或者按特定 JSON 结构输出。
• 更常见的是混合方案：RAG 负责提供事实，微调负责规范行为和格式。比如先用 LoRA 微调让模型学会"只根据提供的资料回答，不知道就拒绝"，再挂 RAG 拉取最新资料。

接下来面试官大概率会追问 RAG 的工程细节，重点在三个环节：切分（chunking）、检索（retrieval）、重排（rerank）。

切分不是按字数硬切，要考虑语义完整性。我常用的做法是按 Markdown 标题、段落结构切，相邻 chunk 之间留一定重叠，避免语义被切裂。检索不能只靠向量相似度，实际项目里 BM25 关键词检索和向量检索结合的混合检索效果好得多——向量检索对专有名词、精确 ID 的召回经常不如关键词。重排则是用一个小而强的模型对上一步召回的候选做精细排序，通常能把最终回答质量提升一大截。

这道题的另一个加分点是"诚实地说出 RAG 的难点"。我碰到的真实难点包括：chunk 切裂导致信息丢失、检索召回率上不去导致模型瞎编、用户提问方式和库内文档表述差异太大。解决思路没有银弹，只能靠调切分策略、加查询改写（把用户问题改写成更适合检索的表达）、加 rerank、加 fallback 兜底。能把这些问题讲具体，说明你真的搭过 RAG，而不是只在博客里看过架构图。

5.2 问题八：幻觉怎么缓解？怎么评估 LLM 系统？Agent 怎么保证可靠性？

这是压轴题，考察的是系统思维。我把三个紧密相关的点放在一起讲，因为它们在真实项目里是连成一体的：你做 RAG 是为了缓解幻觉，缓解得好不好需要评估，评估发现线上问题后要能靠工程手段兜底。

先说幻觉。幻觉的根源在训练目标：LLM 学的是"最可能的下一个 token"，不是"事实正确"。训练数据里的噪声、知识截止时间、解码时的随机采样都会放大幻觉。缓解手段分三层：

• 输入侧：用 RAG 把相关事实塞进上下文，让模型"有据可依"。这是最有效的一层。
• 生成侧：要求答案附引用来源、降低 temperature、增加自我检查——让模型生成完后自己审一遍有没有和上下文矛盾的地方。
• 工程侧：对关键场景做约束解码或规则校验。比如数字、日期、代码，必须通过程序校验后才能输出。

我的个人经验是：别指望单靠提示词解决幻觉，RAG 加引用校验是最实用的组合。面试中把这个组合讲出来，比空谈"用更好的模型"实在得多。

再讲评估。评估 LLM 系统不能只看几个 demo 跑通就完事。实用的做法是搭一个带 golden answer 的评测集：准备几十到上百条典型问题和标准答案，每次改动系统后批量跑一遍，用自动化指标（答案相似度、关键信息命中率、引用正确率）做回归对比。常见 benchmark 可以用 lm-evaluation-harness 这类工具跑，但它只能说明通用能力，不能替代你自己的业务评测集。

这里要提醒一个很多团队都会踩的坑：用"LLM 当裁判"（LLM-as-judge）很方便，但它有自己的偏好偏差——比如更喜欢更长更详细的回答、更倾向于排在前面的选项。用 LLM 判分时，要控制回答长度变量、打乱选项顺序，并且定期抽样人工复核。能讲出这个坑，说明你真的评估过模型，而不是跑了个脚本就算完。

最后是 Agent 可靠性。现在面试越来越爱聊 Agent 和 function calling，因为这类系统最容易暴露工程问题。一个可靠的 Agent 系统至少要处理这些情况：工具调用失败（网络异常、超时、参数非法）如何重试？模型输出的工具参数不符合 schema 怎么办？多轮调用陷入死循环怎么打断？多个 Agent 之间出现竞争或重复执行怎么协调？这些统称为容错控制——Agent 不是"能调工具就行"，而是"调工具出错时系统不会崩、能优雅降级"。

我在实际项目里通常会做三件看起来很笨但非常有效的事：

1. 给每个工具调用加超时和重试上限，重试用指数退避，避免故障时雪崩。
2. 对模型输出的工具参数做 schema 校验，不合法就让模型重新生成，或者走人工兜底流程。
3. 设置最大迭代轮数，防止 Agent 在同一个问题上空转消耗 token。

这三件事不需要多高深的技术，但能让系统稳定性上一个台阶。面试时能把"容错"落到这种具体操作上，比空谈"我们用 LangChain 搭了多智能体"一定更有说服力。

6. 回答问题的通用方法论，以及我的几句大实话

6.1 答题的四段式框架

无论碰到哪一题，一个高质量的面试回答通常遵循四段式：定义问题——一句话说清楚这道题在问什么；讲原理——把核心机制讲透，公式或类比选一个；联系工程——这东西在真实项目里怎么用、有什么坑；给出权衡——如果让你来设计或选型，你会怎么取舍。

四段走完，哪怕细节上有一点错误，面试官也会留下"思维能力在线"的印象。反过来，只背概念、不给工程联系，是最减分的答法。比如问题一，一个候选人如果能从注意力机制讲到"实际部署时 attention 计算需要多少显存"，这就不只是在回答问题，而是在展示自己的整个知识网络。

6.2 遇到不会的题怎么办

我的建议是直接说"这部分我还没有实际踩过坑，但从原理上推测……"，然后从第一性原理推一遍。面试官不要求你什么都会，但很反感不懂装懂。我印象很深的一次，一个候选人对量化一知半解，硬说"INT8 就是每个数字除以 255"，被追问"那权重分布和激活分布不一样怎么处理"后当场卡住。其实他只要诚实说"我只用过现成量化工具，还没深入研究过原理"，再聊聊实际使用体验，这道题反而不会扣太多分。

6.3 准备建议：先跑起来一个模型，比什么都强

说实话，这 8 个问题里的每一个，都能靠读博客和背面经混个脸熟，但真正能让答案"有灵魂"的，是你亲手把模型跑起来的经历。

我的建议很朴素：找一台普通电脑，下载一个 GGUF 格式的开源模型本地跑起来，感受一下量化和上下文长度的实际表现；用 LoRA 微调一个小模型，完整跑一遍 SFT 数据标注和训练流程，LLM Studio 这类工具就够用；最后用主流框架独立搭一个带 RAG 和工具调用的对话系统，把超时、重试、schema 校验、兜底逻辑都写上。这三件事做完，你再去面试，这些问题的答案会从你嘴里自然地流出来——因为那不再是你背的，而是你做过、踩过、修过的。

我个人这些年面试下来最大的感受是：LLM 领域没有"面试题海"，翻来覆去考的就是几个底层原理加工程常识。能过关的候选人，不一定是最聪明的，但一定是真动过手的。面经能给你框架，但给不了你在调试日志里泡出来的那种笃定。如果你正打算面 LLM 方向的岗位，别急着刷题，先跑起来一个模型，边跑边理解，比什么都强。