企业官网建设流程全解析

面试官视角先说实话：招LLM方向的工程师，我看的并不是谁背的多。简历上写着熟悉ChatGPT、用过LangChain的不少，可聊到模型怎么训练怎么推理，很多人的知识是塌陷的。这个行业还在早期，源码没烂大街，商业产品迭代又太快，光靠网上那几篇科普根本撑不住实操。我出题就8个，不问偏、不问怪，全是平时工作里躲不开的底层问题。你能答出原理、说出权衡、扛得住追问，就过关。答不上的，哪怕项目吹得天花乱坠，我也只能淘汰。

这8个问题覆盖了Transformer原理、预训练与微调、幻觉、RAG、分词、上下文窗口、评估、推理优化。看着基础，但每个都能往深处问三层。下面我把问题拆开，给你我期望的答案框架，以及我真实面试中遇到过的错误答法。

1. Transformer 为什么用自注意力，而不是 RNN 或 CNN？

1.1 这道题在考察什么

这题排第一，因为它决定后续所有问题能不能聊下去。Transformer是现在所有主流LLM的底座，不懂自注意力机制，后面的位置编码、KV Cache、稀疏注意力都是空中楼阁。面试官想通过这题看你是否真的理解序列建模的本质，而不是只背了结构图。

1.2 核心解答思路

先讲RNN的痛点：RNN按时间步逐个处理token，当前隐状态依赖上一步输出，所以天然是串行的。训练时面对长序列，梯度在反向传播中容易消失或爆炸，即便有LSTM、GRU缓解，也还是难以捕获超长距离依赖。这种顺序处理的方式同时限制了计算并行度，GPU大规模并行能力发挥不出来。

CNN在NLP里做过尝试，卷积核能捕捉局部区域，多个卷积层堆叠后能扩大感受野。但CNN的感受野跟层数成正比，想关联相距很远的token，需要堆非常多卷积层，而且卷积的局部归纳偏置并不天然适合全局依赖建模。你可以把卷积看成“局部加权求和”，自注意力则是“全局加权求和”。

自注意力真正的优势是两个维度的：第一是计算可并行，每个token的query会跟序列里所有token的key做匹配，这个矩阵运算天然适合GPU并行；第二是每一步都能直接看到序列里的所有位置，路径长度最短，理论上不存在RNN那样长距离依赖的瓶颈。用生活类比就是，RNN像一个人依次读一个很长的字条，读到现在只能记着前面；自注意力像把字条摊开在桌上，同时看所有字，而且用笔标注重点词之间的关系。

然后要提一下复杂度：自注意力时间复杂度O(n²)，n是序列长度，这也是后续一切优化手段的出发点。能主动提到这一点，说明你对Transformer的代价心里有数。

1.3 常见错误与加分细节

候选人喜欢说“自注意力能处理长距离依赖”，这没错，但不够。我会追问“为什么RNN不能长距离？”，有人回答“因为梯度消失”，这算说得过去，但更完整的答案是：RNN的结构限制导致信息压缩到固定维度隐状态，随着步长增加，较早信息要么被“稀释”，要么在梯度回传中衰减。自注意力则没有这个问题，因为每个点都能直达所有点。

加分项是提一嘴“全局建模”和“局部建模”的trade-off。比如大模型后续的发展有很多混合模型，在局部窗口用卷积或滑动注意力，在全局用少量全局token，本质就是想兼顾自注意力的全局能力和O(n²)的代价。这能体现你对模型演进趋势有通盘理解。

2. 预训练和微调到底差在哪？

2.1 先别急着答“一个是通用一个是垂直”

我问过不少人，回答“预训练就是在大数据上训练，微调就是拿小数据训练”，这个答案太表面了。预训练和微调的差异，不只是在数据量上，更在训练目标、角色定位、工程链路上完全不同。

2.2 核心解答思路

预训练阶段，模型在亿级甚至万亿级token上学习语言的一般规律，目标通常是“根据前文预测下一个token”，这是自监督学习，不需要人工标注。这个阶段模型学到的是知识、语法、常识、推理的底座。可以类比成一个人从小到大的通识教育，学的是海量的基础学科，不针对任何具体职业。

微调阶段是在预训练基础上，用一批特定任务的有监督数据（指令、对话、领域问答）继续训练。模型被“调制”成符合特定助手风格、特定领域表达习惯、特定工具调用格式。这个过程不是重新学会语言，而是“定向调整行为”。

更关键的是要说出预训练和微调在技术手段上的不同：

• 预训练通常用更大的批量、更大的学习率、更长的训练步数，需要分布式训练，动辄几千张卡。
• 微调往往使用较小的学习率，通过低秩适配（LoRA）这类参数高效微调技术，只更新一小部分参数，就能让模型学会新任务。
• 微调数据质量要求远比预训练高，一条有毒的微调样本就可能让模型输出风格崩坏，所以数据清洗和规则过滤是微调的日常。

2.3 面试官追问点

我会顺着问：微调之后模型会不会“忘记”原来学到的能力？这就是灾难性遗忘。你如果知道用LoRA、用混合训练数据、用回放通用数据来缓解遗忘，说明你真做过微调。还有时候面试官会问“微调和RLHF什么关系”，你需要简单说明RLHF是用人类反馈来对齐模型价值观，和普通SFT（监督微调）不同，它是通过奖励模型加强化学习来优化策略，本质上也是让模型行为符合期望，但路径不一样。

3. 模型幻觉能彻底消灭吗？

3.1 为什么LLM会一本正经地胡说

幻觉问题现在人尽皆知，但很多人把它归咎于“模型太笨”。实际上幻觉是很多因素叠加的：训练数据本身存在矛盾或错误，模型只能学到统计相关性；生成阶段又是采样式解码，每次都有随机性；再加上模型不是知识库，它内部保存的是参数化的概率，不是可靠的事实记录。说白了，模型像一个“看过海量书的记忆混合体”，它输出内容时并不是查表，而是根据概率联想，联想错了就幻觉。

3.2 回答结构化

我会期待候选人先给幻觉分类。通常分两类：一类是“事实性幻觉”，比如问“某公司成立于哪年”，模型给一个完全不存在的年份；另一类是“逻辑不一致幻觉”，比如前后回答矛盾，或者推导过程跳步。能分类，说明你不是人云亦云。

再问怎么降低。常用的手段其实是组合拳：

• 检索增强（RAG）：先检索外部知识库，把相关文本拼进上下文，再让模型基于给定材料回答。模型有了“参考资料”，胡编的概率大幅下降。
• 更好的解码策略：比如降低温度、或用约束解码，让模型尽量走高概率路径而不是天马行空。
• 对齐训练：用偏好数据告诉模型“知道就说知道，不知道就说不知道”，引导模型输出不确定性的表达。
• 自洽性检查：同一问题多次采样，如果答案众数一致性高，可信度就高；多次结果差很远，很可能在瞎编。

3.3 加分观点

面试官最后会问“能100%消灭幻觉吗？”正确答案是“不能”。因为模型学的是概率分布，只要有采样，就有随机性；即使去掉采样，数据里没有的知识也永远无法凭空生成。所以工程上我们做的是“让幻觉发生在不重要的地方、并让幻觉可以被识别”。如果你能提到通过外部工具验证、或通过置信度阈值卡控来降低幻觉风险，那会是很大的加分项。

4. RAG 的完整链路和难点

4.1 别只说“向量检索”

太多人一聊RAG就讲“把文档切成chunk，用embedding转向量，存到向量库，查询时算相似度。”这种流水账说明你只跑过demo。真正的RAG面试题，会追问切块的依据、embedding模型的选择、检索后的精排、以及上下文拼接的策略。

4.2 核心解答思路

RAG的整体目标：给模型注入不在参数里的知识。整体链路分四个环节：知识库处理、召回、重排、生成。

知识库处理：先清洗文档，把PDF、网页、结构化表格统一转成纯文本；然后切块，切块不是简单按字数切，而是尽量保留语义完整。比如一段代码、一份合同条款、一组QA对，都应该作为整体切块。块太小，上下文切断，模型看到的是半截话；块太大，检索噪声增加，还会挤占上下文空间。常用策略是“按语义边界切块”，比如标题、段落空行，再配合同级块重叠，确保边界不丢失上下文。

召回：将query转成向量后到向量库做相似度搜索。这里要知道两种检索的对比：向量检索擅长理解语义，“今天天气咋样”和“今天适不适合出门”能匹配上；稀疏检索（BM25）擅长关键词精确匹配，能让“API密钥”这种专有名词不被语义漂移冲掉。生产系统里最稳的是混合检索，把向量检索和BM25的结果合并后再重排。

重排：向量召回通常是top100，但给模型的上下文只有几K甚至几百token，所以必须压缩。用重排模型（cross-encoder）对query和每个候选逐对打分，效果比向量相似度准，因为向量相似度是粗粒度双塔编码，而cross-encoder能真正做token级的交互。代价是速度慢，所以只对top50-100做重排，而不是全库做。

生成：把检索到的内容拼接进系统提示词，在模板中标明“以下为参考资料，如果资料中没有答案，请说不知道”。同时要注意溯源，让模型在回答里带上引用编号。这样用户能验证答案，幻觉也会被抑制。

4.3 容易翻车的地方

说是RAG，实际上检索质量和生成质量都要调。很多人忽略query改写，因为用户的问题往往是口语化的、缺失上下文的，直接拿原文去检索效果不好。你如果有经验，知道先让LLM改写查词或生成子问题，再去做检索，效果会明显提升。另外就是评估：RAG效果不能凭感觉，要构建测试集，统计召回率、命中率、答案命中率，逐项调优。能说到这一点，说明你有线上思维。

5. Tokenization 为什么是中文 LLM 的分水岭？

5.1 一个看似底层实则致命的问题

现在很多开源模型的词典是英文优先的，中文token覆盖不够细，导致同一段中文被切得七零八落，模型需要更长序列才能理解同一个字词组合。这一题能考出你对数据预处理的理解深度。

5.2 核心解答思路

Tokenizer本质上是一个词表加上一个切分算法。BPE（Byte Pair Encoding）是最常用的算法：先把文本拆成字节级，然后不断合并出现频率最高的相邻字符对，直到达到目标词表大小。这样高频词（“的”、“是”）对应单个token，低频组合词会被拆成子词。

为什么中文难？因为中文不像英文天然有空格分词。一个汉字单独成字，但单词往往是两个或三个字的组合，用BPE又很容易把常用字组合合并成token，可具体哪些组合该进词表，取决于训练语料。如果语料里中文占比少，BERT这类基于子词的tokenizer就会把“智能”切成“智”和“能”两个token，模型要多算两步才能理解。

回答时要点出token数量对成本的影响：如果同样一段中文在某个模型里被切成500个token，在另一个中文优化模型里切成300个token，那么后者的上下文容量和推理速度都会更好，长文本场景下差距尤其明显。这也是为什么很多中文开源模型会内置中文词表，甚至用更大的词表容量。

5.3 实战注意项

面试时会问：新增一个领域术语怎么处理？比如“RAG”这种词，如果不进词表，会被切成“R”、“AG”，不仅浪费序列长度，还可能导致语义不稳定。解决方法是扩词表，把高频领域词直接加进去，并在预训练或继续预训练阶段让模型重新适配新token的嵌入向量。但要注意，随意扩词表会让模型原本学好的token嵌入分布被打乱，需要额外训练来平稳嵌入。这个细节能说出口，面试官基本就知道你真的碰过语料。

6. 上下文窗口不够用，怎么解？

6.1 所有RAG、Agent场景都躲不开的问题

上下文窗口是现在LLM应用的紧箍咒。模型一次最多只处理几千到几百万token，但真实业务里的资料往往远超这个量，而且即使窗口够大，注意力计算也是平方级增长，速度慢、显存爆。面试官想看你是否理解窗口限制的本质，以及工程上如何软性扩展。

6.2 常规解法清单

先回答最基础的——按需注入，而不是全量注入。RAG就是一种“选择性看资料”的方式。如果你的系统是问答场景，你不需要把整个知识库塞进窗口，你只需要检索出相关的段落放进去。用一句话解释“长文本问题本质是信息选择和信息压缩问题”。

再扩展一些：

• 上下文压缩：让模型先对长文档做摘要，再把摘要送进主模型。这个方式适合离线处理，但会丢失细节。
• 滑动窗口：类似载入最近N个token的历史，能让模型在长时间对话中保持部分记忆，但中间信息会丢。
• 分层摘要：把长文档按章节递归摘要成树状结构，使用时根据query从树节点中检索最相关的摘要。这是LangChain里MapReduce的变体。
• 位置编码外推：比如调整RoPE的base，让模型能泛化到比训练更长的位置，但这只是缓解，并不能让模型真正理解更长期的信息。

更高层的思路是“让模型具备记忆工具”，比如把历史对话浓缩成可检索的笔记，Agent需要时再读取，而不是把所有历史都放一起。这个答案能体现出你不是只会喂提示词。

6.3 核心权衡

我面试时会更看重候选人能否说出“窗口大并不等于好用”这句话。窗口再大，模型对远处的注意力依然会被稀释，而且推理时KV Cache会占据大量显存，成本飙升。所以你给出的方案必须考虑业务场景中“需要”的上下文长度，而不是盲目追求“能支持”的长度。

7. 怎么评估一个 LLM 效果？

7.1 题目陷阱：没人只看准确率

我被问过很多次“你评估模型用什么指标”，开口就是BLEU、ROUGE之类的，这两个是机器翻译和摘要时代的老指标，对LLM生成式回答的评估能力有限。真正面试时要呈现的是一个完整的评估体系。

7.2 三层评估框架

第一层是自动指标，适用于有标准答案的场景。比如分类任务看准确率、召回率；选择题看正确率；摘要任务可以保留ROUGE作为参考。但你要主动说明自动指标的局限性：参考答案不唯一，语义正确但措辞不同的回答会被误判为错误。

第二层是模型评估（LLM as Judge），用更强的模型（比如GPT-4或自家最厉害的内部模型）来给回答打分。这个方案能做复杂质量维度评估，比如相关性、完整性、恶意性。但有一个坑：裁判模型本身有偏好误差，比如倾向于给更长的回答或看起来更“正式”的回答打高分。工程上要设计评分rubric，对裁判模型做校准。

第三层是人工评估，这是最可信的。流程是建立多维度的打分板，比如“指令遵循度”“事实正确性”“风格符合度”“有用性”，让标注员打分。人工评估成本高，所以通常只用于小样本、高风险的case，比如模型上线前抽样200条做终检。

要加分，还可以提“线上评估”：把新模型放在小流量上，和线上旧模型做A/B对比，收集用户反馈、兜底拦截率、重回答率。这类指标能真实反映产品体验。

7.3 面试中常见的漏洞

只讲Metrics，不讲评估数据怎么来；只做单样本评估，不知道什么是方差和显著性。我会追问“两个模型一个BLEU高，一个人工分高，你信哪个？”正确答案是“信人工分，因为BLEU不适合生成式任务，但如果业务是翻译，BLEU仍然有参考价值”。重点是说清楚评估目标依赖任务类型和资源预算，不能一刀切。

8. LLM 推理速度慢，有哪些优化手段？

8.1 为什么推理是另一座山

训练时你可以堆卡、可以等，但推理是线上实时交互，用户等不了两分钟。而且要明白“推理慢”不只是模型参数大导致的，有些瓶颈来自内存带宽、KV Cache占用、显存碎片、batch size太小。面试官想看你能不能结构化地拆解优化手段。

8.2 四个维度拆解

算法层：把推理中重复计算的注意力和FFN中间结果缓存下来。这里面最经典的是KV Cache，推理每个token时只需要计算当前token的query，而历史key和value是重复使用的。如果你答不出“KV Cache”，那这个面试基本就凉了。进一步可以提“GQA（分组查询注意力）”，通过让一组query共享同一个key/value头，大幅减少缓存量和访存，这是Llama 2/3在用的方案。

硬件层：量化，把FP16权重压缩成INT8甚至INT4，推理速度可以提升2-4倍，显存占用同步下降。量化有训练后量化和量化感知训练两种，工程上常用训练后量化配合校准集，避免重新训练的成本。GPU算子融合也很重要，把多个小算子合并成一个，减少rank调度开销和显存读写。

工程层：动态batch，把同时到达的请求合并成一个batch，能显著提升吞吐。但batch不是越大越好，单请求的KV Cache长度不同，GPU算力分配不均匀，需要做粒度更细的调度。再比如投机采样（Speculative Decoding），用一个小模型先草拟多个token，再由大模型验证，因为验证可以并行，所以能提升单序列生成速度。

服务架构层：把模型切分到多张卡，用张量并行；或者对超大模型用多卡流水线并行。这部分更偏Serving框架的选型了，比如vLLM的PagedAttention模块，它能像虚拟内存一样分页管理KV Cache，极大提高显存利用率和并发能力。

8.3 终极答案：你会给一个业务配什么方案

面试官最后会追问：“我们的产品响应需要500ms内，用34B模型，怎么配？”正确思路不是背方案，而是评估模型本身和业务需求是否匹配——先试量化后的模型速度，再测动态batch吞吐，再看是否需要蒸馏到7B级别。优化永远是为了满足SLA，不是单纯追求指标。这就回到了工程决策力。

9. 面试官不会写进招聘JD的三个“隐藏压轴”

9.1 遇到跨领域问题，你会怎么组装方案？

这8个问题答完，通常还有自由提问环节。我会非常喜欢问：“现在要把一个1200页的行业合规手册做成一个内部问答机器人，你的完整技术方案是什么？”这题没有标准答案，但我期望听到的链路是：

• 先做文档清洗，把PDF、图表、扫描件转成可检索文本；
• 切块时保留条款编号和引用关系；
• 用混合检索+重排，把相关条款找到；
• 生成时让模型只能引用检索到的条款，并标注来源；
• 配置一个兜底策略：如果检索置信度低，宁可回答“资料未覆盖”，也不要瞎编；
• 最后建一套评估集，包含常见问题、易混淆问题、超出范围问题，定期回归。

能这样条理清晰地说出来，基本就是我要的人。

9.2 Agent 工具调用，你会怎么设计？

现在越来越多的岗位要求Agent经验。问“让LLM使用工具和外部API，你的流程设计是什么？”关键在于：

• 定义清晰的工具schema，包括参数名、类型、枚举值，最好有提示词里的few-shot例子；
• 让模型在需要时输出一个结构化JSON调用来调用工具，而不是自然语言命令；
• 工具返回结果后要重新拼接成模型能理解的上下文，并再次让模型判断是继续调用还是直接回答；
• 处理工具调用失败的情况，比如超时、返回异常，模型要能重试或者说出“当前服务不可用”。

不要直接甩一个LangChain自动Agent完事，面试官想听的是你如何控制不确定性。

9.3 模型是“概率系统”，你的产品怎么保持稳定？

我会经常问：“你的应用要正式上线，模型输出不稳定怎么解决？”最佳回答包含：

• 输入层面：把用户输入归一化，比如改写、去噪、校验敏感词；
• 输出层面：用解码参数固定seed，或对核心场景用低温采样、约束解码；
• 业务层面：对模型关键输出做规则校验，比如数值格式、JSON结构，不合法就重答；
• 提示词层面：模板版本化，每次改动都做回归测试；
• 兜底层面：准备一个简单的规则机器人，模型不可用时至少能给用户一个体面的错误页面。

用“概率系统”的思路去设计产品的稳定度，而不是把模型当确定性API，这是高级工程师和调包侠的本质区别。

10. 一点私货：我选择候选人的标准

写了这么多，最后分享一个我在实际招聘中的体会。这些“必问8题”与其说是考知识点，不如说是在考“你是不是有真正动手做过”。因为我发现，凡是完整做过一个LLM项目的人，即使有些原理讲得磕磕绊绊，也能在追问下用例子和权衡来弥补；而只刷过面试题的人，往往能背出漂亮的定义，但一问“你当时为什么选这个方案”“参数是怎么调的”，立刻就开始含糊其辞。

说实话，LLM这行现在没有什么“标准答案”。同一个问题，不同场景的最优解可能完全不同。面试官要的不是一台复读机，而是一个能在不确定的环境里做决策、能快速学习新工具的人。所以如果你正在准备这类面试，我的建议是：与其背那8个问题的标准答案，不如自己亲手跑一遍微调、RAG、评测和推理优化，把每一步踩过的坑记下来。拿着这些经历去面试，比背一万道八股都有说服力。

最后一个更实用的小技巧：面试总结时，不要说“我对LLM很感兴趣”，要说“我做过某件事、遇到了什么问题、通过什么方法解决、结果怎么样”。用项目故事串起你掌握的技术点，让我在十几分钟内相信“交给你的活你是真能落地的人”。做到这一点，基本上离offer就不远了。