面试官视角先说实话招LLM方向的工程师我看的并不是谁背的多。简历上写着熟悉ChatGPT、用过LangChain的不少可聊到模型怎么训练怎么推理很多人的知识是塌陷的。这个行业还在早期源码没烂大街商业产品迭代又太快光靠网上那几篇科普根本撑不住实操。我出题就8个不问偏、不问怪全是平时工作里躲不开的底层问题。你能答出原理、说出权衡、扛得住追问就过关。答不上的哪怕项目吹得天花乱坠我也只能淘汰。这8个问题覆盖了Transformer原理、预训练与微调、幻觉、RAG、分词、上下文窗口、评估、推理优化。看着基础但每个都能往深处问三层。下面我把问题拆开给你我期望的答案框架以及我真实面试中遇到过的错误答法。1. Transformer 为什么用自注意力而不是 RNN 或 CNN1.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本质上是一个词表加上一个切分算法。BPEByte 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就不远了。