企业官网建设流程全解析

最近这半年，我作为一面面试官筛了差不多 200 份 LLM 方向的简历，也面了近百个候选人。一个特别明显的感受是：这个岗位的简历越来越漂亮，但面试通过率并没有跟着涨，反而在快速下降。原因很简单，LLM 相关的知识体系铺得又宽又深，很多人简历上写满了微调、RAG、Agent，但是只要往底层多问两层，就立刻露馅。

这里说的露馅，不是那种"知识点没背熟"的程度，而是从根本概念上就理解偏了。所以我干脆在面试流程里固定了 8 道题，作为所有 LLM 相关岗位的第一轮技术关卡。这 8 题覆盖面不算广，但每道题都能精准拆掉一层包装。答不出来，确实直接淘汰，因为后面组内其他面试官也没有必要继续面了。

这篇文章就把这 8 道题全部展开，每一道题下面我会说清楚面试官在考察什么、合格的回答路径是什么、常见翻车现场是什么样的，以及作为求职者你该怎么在短时间内把答案组织得既有深度又有工程味。

1. 这 8 个问题凭什么"一票淘汰"？先看面试官的出题逻辑

很多人以为淘汰是因为题目太难，或者候选人某个知识点没碰到。实际不是。我在设计这套题目的时候，核心原则只有一个：每个问题都必须指向一个从事 LLM 相关工作的人每天都要用到的核心能力。答不上来，意味着这个候选人在真实工作中会遇到无法绕开的障碍。

1.1 每道题对应的是哪一类核心能力

你可以在心里把 LLM 相关岗位的工作内容切成六块：模型理解、训练原理、生成调控、工程落地、效果评估、外部交互。这 8 道题刚好是这六块里最容易被"背下来"也最容易被"问穿"的代表。

一眼就能看出来，这 8 题没有任何一题是"背下来就能过"的。比如 Token 那道题，候选人背下"字节对编码"几个字没有用，面试官会一直追到你说清楚"为什么英文里一个词常常是 1 个 token，而中文里一个词可能是 2-3 个 token"为止。

1.2 "答不出"和"答得不好"是两种淘汰

你要分清一件事：面试官能接受"答得不够深入"，但不能接受"完全没有方向"。以我个人的执行标准来说：

• 答不出核心定义：比如你说不出注意力机制里 Q、K、V 各自的作用，直接淘汰，因为你没法跟团队成员讨论模型结构。
• 答不出工程权衡：比如你只知道 RAG 和微调的定义，说不清它们适用的业务场景，淘汰，因为你在真实项目中会选错方案。
• 只能背教材、不能举例：比如问你在生产环境里怎么治重复生成，你只能背出 top_p、temperature 是超参数，但说不出调参的顺序和理由，同样淘汰。

这背后有个很简单的逻辑：LLM 岗位招的不是"知道 LLM"的人，而是能基于 LLM 做工程决策的人。知识可以被查资料补上，但思维方式和理解深度，很难在短期培训里修复。

2. 第一梯队：分词与注意力，两题就能筛掉一半候选者

我把这两道题放在面试最开始。原因很现实：分词和注意力机制是整个 LLM 大厦的地基。如果地基理解歪了，后面问训练、问生成都是空中楼阁。

2.1 Tokenization 题：一开口就知道你是背过还是真正用过

题目一般是这样的："你用过 GPT 系模型的话应该知道，同样的语义，中文消耗的 token 通常比英文多。为什么？"

这道题淘汰率之高，超出很多人的想象。因为我听到的标准答案里，十个有七个是"因为中文分词难、词表有限"，然后就没有然后了。这句话没错，但没有答到点子上。

面试官真正想听的逻辑链条是这样的：

第一层：当前主流 LLM 的 tokenizer 用的是Byte-level BPE（字节级字节对编码）或类似算法，WordPiece、SentencePiece 也可以算一个家族。它处理的粒度不是"词"也不是"字"，而是"字节"。

第二层：英文单词本身空格分隔，加上 BPE 会把高频子词（比如 "ing"、"tion"、"ed"）合并成独立 token，所以常见的英文单词往往被切成 1-2 个 token。Long 一个词就是一个 token，National 切成 "Nation" + "al" 两个 token。

第三层：中文没有天然空格边界，BPE 只能从字符/字节层面统计共现频率。常用中文字符（"的""了""我"）可能会形成独立 token，但更多情况是一个中文词"苹果"会被切为 2 到 3 个 token（比如 token 序列可能是 "苹" + "果" 或 "苹果" 被模型单独列为一个 token，取决于词表里是否合并成功）。整体上，表达同样语义，中文消耗的 token 数量大概是英文的 1.5 到 2 倍。

到这里还没完。真正让你在面试里加分的是第四层：工程影响意识。你要能补一句"所以中文场景的推理成本更高，latency 更长，给用户限流和计费的时候要考虑这个系数；用 Embedding 做检索的时候，中文文档的向量维度开销同样更大"。

加分的进阶答案：提一下 BPE 对生僻字的处理（最终兜底会退化为单字节甚至 Unicode 编码，导致生僻字 token 很长），以及"一个 token 不等于一个词"这个反直觉结论。能谈到这些，说明你真处理过 token 层面的数据问题，而不是只会用框架。

2.2 自注意力机制：两轮追问就暴露你理解的是公式还是本质

这道题的出题方式通常是递给候选人一块白板或者让他打开在线画图工具："讲讲 Transformer 里的 Self-Attention 到底做什么，为什么它取代了 RNN。"

淘汰率最高的是那种开始背公式：Q 乘 K 的转置，除以根号 d，softmax，再乘 V。公式确实写对了，但这只是第一层。关键看追问。

第一追：为什么 RNN 做不了长序列？你要说出两点——顺序计算导致并行性差，以及长距离依赖的信息会经过很多步传递后衰减（梯度消失/爆炸的变体）。注意力机制直接把任意两个位置的信息交互路径缩短为一步，所以它可以在一次前向计算里让"第 100 个词"直接看到"第 1 个词"。

第二追：为什么要除以根号 d？这是很多人在面试里卡住的地方。正确答案是：当维度 d 增大时，Q 和 K 的点积值域会变大，softmax 输入过大导致梯度极小，学习困难。除以根号 d 是一种 scale 操作，让点积结果保持在一个稳定的数值范围内。

第三追：Q、K、V 到底是做什么的？这里有个很好的生活化类比：你可以把 Q 理解为"我在找什么"，K 是"我手里有什么标签"，V 是"我实际能提供什么内容"。注意力分数的本质是算"当前这个位置对其他位置的需求匹配度"，匹配度高的位置，它的 V 会被加权更多。能把这个类比讲清楚，面试官基本就确认你是真理解，而不是死记公式。

再加一层工程加分项：如果你还能主动说出"实际推理的时候我们做 KV Cache，把历史 token 的 K 和 V 存下来复用，避免每次重新计算"，那就更好了。因为这证明你不仅理解注意力，还理解它在大模型推理服务里的性能瓶颈。

3. 第二梯队：解码策略与 RLHF，实战派和理论派的试金石

过了架构题，面试进入第二个区段。这两道题的核心作用是区分"调包侠"和"能自己解决问题的人"。因为你在真实项目里一定会遇到生成质量差、模型不听话的问题，面试官需要确认你有能力独立排查。

3.1 解码参数与重复生成：把排查过程讲出来才算答对

实际问题是这样描述的："你的模型上线之后，用户反馈它经常说重复的话，或者生成内容开始胡言乱语。你怎么办？"

这道题的答案可以按"从现象到根因"的链路来组织。一次合格的回答应该包含以下步骤：

第一步，先判断是数据问题还是解码问题。你要能说：如果模型在长文本生成后段开始整句整句重复，大概率是解码策略的问题；如果模型从第一句开始就前言不搭后语，那可能是训练数据污染、指令跟随没学好，甚至上下文超过了窗口。先把范围收窄到"重复"这个具体症状，再往解码方向排查。

第二步，讲清楚解码参数的影响逻辑：

• temperature控制概率分布的锐化程度。温度低，采样偏向高概率 token，输出更稳定但更容易陷入重复循环；温度高，输出多样但风险是逻辑断裂。出现重复时，一种常见做法是适当提高 temperature，减少模型反复选择同一条高概率路径。
• top-k限制候选集合大小。过小会加剧重复，因为高概率选项就那么几个，翻来覆去都是它们。
• top-p（nucleus sampling）按累计概率截断候选集。比 top-k 更动态，是更推荐优先调整的参数。
• repetition_penalty / no_repeat_ngram_size是直接惩罚重复的手段。前者对重复出现的 token 打分降权，后者从根源上禁止指定 n-gram 重复出现。

第三步，说出你的调参顺序。以我的经验，顺序应该是：先开 no_repeat_ngram_size（比如 3-4）压制局部重复，再微调 top-p（0.9 到 0.95 区间），然后才调 temperature。如果还不行，再考虑 repetition_penalty（1.0 到 1.2 之间谨慎调）。不要一上来就三个参数一起乱动，否则你根本不知道是谁起的效果。

第四步，加分项：从解码问题跳出来，提到"如果模型抽风式地生成无意义内容，先检查是不是 prompt 里的指令和上下文冲突了，或者是不是上下文被截断导致模型只看到残句"。这个判断能力，是实战派才会有的直觉。

3.2 RLHF 三阶段：别把"人类反馈"四个字当答案

这道题的连环追问是面试里现场感最强的部分，因为几乎人人都能说出"RLHF 就是通过人类反馈来优化模型"，但几乎人人都说不清三个阶段具体做什么。

完整链路是这样的：

阶段一：SFT 监督微调。用人工编写的高质量指令-回答数据对模型做微调，让模型先学会"像人一样答题"的基本格式和能力。很多候选人会跳过这一步，直接从"人类反馈"说起，这是错误的。没有 SFT，RLHF 的基础行为模式就是乱的。

阶段二：Reward Model 训练。让同一个模型对同一问题的多个回答排序（或打分），训练一个 RM 来预测人类偏好。这个 RM 本质上是把"人类偏好"从隐性的变成了可计算的目标函数。面试官在这里会追一句："RM 的输入输出是什么？" 答案：输入是 prompt + 若干个候选回答，输出是每个回答的评分。

阶段三：PPO 强化学习。用 RM 的评分作为 reward，通过 PPO 算法继续更新模型的策略。但这里有一个核心矛盾：如果模型只是为了拿到高 RM 分数而大幅修改输出，它会在文本表面上"讨好" RM，但本质上是偏离了自身语言能力。所以引入KL 散度惩罚，限制新模型和 SFT 模型的输出分布不要偏离太远。

面试里最加分的表达是，你在讲完这三步之后，补一句"PPO 其实很不稳定，对超参数敏感，训练成本也高，所以现在工业界对 DPO（Direct Preference Optimization）这类免强化学习的方法也越来越关注"。这会让面试官觉得你既懂经典方案，又保持对新技术动向的敏感。

这道题最后还有一个隐藏加分点：能说出"整个 RLHF 真正难的不是模型部分，而是数据生产管线——怎么让标注员稳定输出高质量偏好排序，怎么控制标注一致性"。因为在实际训练中，数据质量对 RLHF 效果的影响往往大于算法本身。你能主动把话题引到这里，就说明你不是纸上谈兵。

4. 第三梯队：RAG、上下文窗口与评估，工程落地的分水岭

进入到这个区段，面试官开始真正筛选"能用 LLM 干活的人"。前面那些题考的是你会不会做决断，这几道题考的是你在真实业务里做不做得出合理决定。

4.1 RAG 与微调的选型逻辑：别把两者背成竞争对手

问题表述通常是这样的："业务方想让你做一个企业知识库问答助手。有人建议微调，有人建议 RAG。你怎么做决策？"

先说一个最容易翻车的回答：谁的本质都是"给模型更多知识"。这句话是错的。RAG 做的是检索外挂，它没有改变模型参数；微调则是永久地把偏好、格式、能力写进模型参数里。两者解决的不是同一类问题。

我给你一套我在项目里常用的决策框架：

优先考虑 RAG 的场景：

• 知识库的内容可能频繁更新（比如组织架构调整、产品文档迭代）
• 需要回答的依据可追溯、可引用，用户看到答案之后最好能跳回原文
• 冷门知识/长尾实体占比高，模型训练数据里大概率没有
• 你不想承担高额的微调训练和反复验证成本，想快速上线

优先考虑微调的场景：

• 你需要模型学会特定的输出格式（比如固定 JSON Schema、特定行业话术风格）
• 你需要模型的行为改变（比如从啰嗦的口吻变成简洁的口吻，或者总是先给出结论）
• 你的任务有大量高质量局部数据，且数据分布相对稳定（不是天天变）
• 推理时你不想每次检索数据库、不想增加查询延迟

最让面试官满意的是你说出"两者不互斥"：很多真实项目是先用 RAG 把上游知识取出来，然后再用一个微调过的生成器把答案整理成符合业务格式要求的结果。RAG 负责知识，微调负责表达，两者配合。

最后别忘了讲一个自己的失败教训，哪怕很简短。比如"我在某个项目里最开始想用微调硬塞知识，结果模型对停更前的新内容学得特别好，但旧知识出现了灾难性遗忘，后来改成只对格式做微调、用 RAG 做知识来源才解决了问题"。这一句，比上面所有理论加起来都能证明你的工程能力。

4.2 上下文窗口与评估体系：长度和度量都远没有直觉那么简单

这两题我放到一起写，因为它们在面试里经常连着出现，而且共同点是都考验"反直觉"的意识。

上下文窗口这道题，陷阱在"越长越好"。你要能一口气说出几个长上下文带来的真实问题：

• 注意力分散：当上下文有 100K token，模型真正处理问题时，并不会雨露均沾地去读每一个字。大部分位置的信息会被稀释，真正关键的内容往往得不到足够注意力权重。业界把这个现象叫"lost in the middle"，也有点像"大海捞针"测试暴露的问题——你把一句关键信息放在长文档中间，模型很容易漏掉。
• 位置编码外推：模型训练时见过的上下文长度是有上限的。直接推理超长输入，位置编码本身就可能失效，模型表现不是逐步下降，而是断崖式崩溃。解决办法包括外推位置编码（比如 RoPE 的缩放）、滑动窗口局部注意力、或者提前在更长的序列上做继续预训练。
• 成本爆炸：自注意力的计算量随序列长度近似平方增长，更长的上下文不仅是 token 成本，更是 GPU 显存占用的灾难。工程上要对超长文本做切片、摘要、段落召回，而不是一股脑全塞进去。

评估体系这道题的作答思路，要体现"多维度"而不是"单指标"。面试官想听的是你有一个成体系的评估方案，而不是一句"我们看 BLEU"。

一个合格的评估思路是这样的：

第一层，模型能力基准。用公开基准（如 MMLU、GSM8K、MT-Bench、Chatbot Arena）做横向对比，判断模型与行业水平的差距。但你要主动说明：这些基准和你真实业务之间的分布差异可能很大，公开基准高分不等于线上效果好。

第二层，业务任务评估。构造与目标场景高度一致的评测集（最好几百条以上），人工标注正确答案或评分标准。然后跑批量推理，看任务级准确率、格式正确率、拒答率、幻觉率。

第三层，在线指标。A/B 测试对比新旧版本，看用户留存、点赞点踩、回答被采纳率。这一步能捕捉到离线评估里发现不了的"风格类"问题，比如语气、简洁度。

第四层，持续更新机制。评测集不能是一潭死水，要定期加入线上失败案例、用户反馈修正后的样本。如果面试时你还能提一句"我们每两次模型迭代就 review 一次评测集，把线上 bad case 回流进去"，这就齐活了。

5. 压轴题：Agent 与工具调用，答好这题 Offer 到手一半

最近半年，Agent 相关的问题在面试中比重涨得非常快。因为它把 LLM 从"文本生成器"推向了"执行者"，这也是整个行业最热的方向。这道题的变体很多，比如"怎么让模型调用外部 API""讲一下你现在理解的 Agent 架构""ReAct 是什么"。

5.1 从"生成"到"行动"：ReAct 范式怎么讲才显功力

ReAct 的全称是 Reason + Act，核心思路是让模型在思考、行动、观察之间循环，而不是一次性地吐出一段文本。具体来说，模型会输出一段推理（Thought），然后决定要不要调用某个工具（Action），工具返回结果之后模型再基于观察（Observation）继续推理。

在面试里把这个概念讲出来不够，你要回答"为什么需要这样设计"。答案要点是：语言模型的下一步生成是概率性的，中间任何一个环节出错，都需要后续步骤纠错，如果模型一次性输出最终答案，它没有机会修正自己的中间结论；ReAct 把过程切碎，每走一步都有工具反馈作为新的上下文，这就在结构上给了模型自我纠错的空间。

如果面试官追问 Function Calling 的实现原理，你可以这样答：从工程角度看，本质是模型输出结构化的"函数调用意图"，包括函数名和参数 JSON，然后系统侧根据这个输出去执行真实函数，把返回值还原为文本再拼进对话上下文。这里面有一个关键设计是"工具描述 schema"要写得很清楚——模型通过工具名称和参数描述来决定是否调用以及怎么调用。所以一个 Agent 系统的上限，很多时候取决于你有没有把工具说明写得足够准确。

5.2 面试官最想听的"Agent 陷阱"：记忆、容错与成本

好的 Agent 答案，一定要包含"坑"的意识。我问过的候选人里，能答到这一层的很少，但每一个答到的最后都拿到了 offer。

第一个坑是记忆管理。Agent 的每一次交互都往上下文里加内容，很快就撞上上下文窗口上限。你需要设计"摘要历史 + 剔除噪声 + 关键信息持久化"的三级记忆机制。比如超过一定轮次后，先把早期对话压缩成摘要；当用户重新问旧话题时，再去外部记忆库检索。

第二个坑是容错与防循环。Agent 调用外部工具可能失败，返回错误格式，或者模型自己反复调用同一个工具而不推进任务。工程上必须做：函数调用的重试次数上限、错误信息的结构化返回、单任务最大迭代步数（相当于给 Agent 加一个 step limit）、甚至异常时人工回退机制。没有这层设计，Agent 系统上线就是个事故源。

第三个坑是成本失控。一次 Agent 会话可能要外呼好几个工具、产生大量中间 token，比普通对话贵一个数量级。你需要有 token 用量预算、工具调用次数的监控告警，以及"小模型先决策、大模型再兜底"的降本措施。

能把这三点主动讲出来，面试官几乎可以确定你在真实项目里设计过 Agent，而不只是看过几篇博客。

6. 我亲测有效的应答框架与复习清单

最后这一段，是我作为面试官很小的一点私心：很多人其实有能力，只是临场组织答案的方式太混乱，导致没被看见。如果你正在准备 LLM 面试，下面这个答题框架和复习路线值得参考。

6.1 30 秒内组织答案的 PRE 结构

遇到任何一道技术题，不要直接张嘴就答。先在脑子里花 10 秒定义问题的边界，然后用"Position（结论）— Reason（原因）— Example（例子/工程实证）"的三段式组织回答。

举个例：被问到"为什么中文 token 消耗更多"，你的结构是这样的：

Position：因为主流 tokenizer 基于字节级 BPE，中文缺乏天然分词边界，导致语义密度相同时中文字符需要更多 token 编码。 Reason：BPE 是从字节序列里统计高频片段，英文的词间空格给了天然的切分单元；中文只能从字和词组统计共现，很多常用词没有完全合并成单一 token。 Example：我们做过统计，同样一万字的中英文产品文档，中文 token 消耗是英文的 1.8 倍左右，推理延迟也因此显著增加，后来我们在定价和限流方案里专门加了这个系数。

这个框架的好处是：即使你不是完全确定答案，也能让面试官一眼看到你的思维链路在哪里断的，至少证明你有清晰的逻辑骨架。

6.2 最后再说说复习优先级

如果你只有两周时间，我建议把精力砸在下面这个顺序上：

1. 先把 Transformer 架构的每一步彻底搞懂（包括 QKV、位置编码、LayerNorm、残差连接），这是所有追问的原点。
2. 再把手上的开源模型（比如 Qwen、Llama 系）用 vLLM 或 llama.cpp 本地跑起来，切到中文场景实测一下 token、解码参数、幻觉问题。
3. 然后选一个自己最熟悉的大模型 API，从零写一个带 Function Calling 的小工具调用 Demo，把 ReAct 循环跑通。
4. 最后，把 RAG 和微调各完整做一个小实验，记录在什么情况下哪个方案更有效。

面试官不会要求你什么都会，但一定要求你"真的亲手做过"。哪怕你的实验非常小，项目非常粗，只要你在回答里能连续讲出"我当时怎么做的、遇到了什么问题、为什么这么调"，通过率就会远超平均水平。

这 8 道题不要求你答得尽善尽美，但要求你能证明自己是一个在大模型领域里"摸爬滚打过的工程师"，而不是一个"看过很多文章的产品经理"。把上面的每一条都过一遍，到面试现场你至少不会在第一轮就被人连根问穿。