我做过不少次LLM方向的面试官也帮朋友做过模拟面试。有一个现象几乎每次都出现候选人简历写得很漂亮项目经历里全是“基于GPT-4搭建了智能问答系统”但只要往深处问一句“为什么这么做”就开始支支吾吾或者搬出一堆论文名词来掩盖理解的空缺。这个标题看着有点吓人但按现在的行情真不算夸张——LLM相关的岗位门槛这两年肉眼可见地在抬高面试官早就不满足于“你会不会调API”了而是想看你能不能把大模型当成一个可工程化的系统来理解和驾驭。这篇文章把我这些年筛选效果最好的8个LLM面试问题、参考答案框架、面试官的判断标准、常见翻车现场一次性整理出来。它适合正在准备LLM应用开发、算法工程、推理优化方向面试的人也适合团队里负责招人、想快速摸清候选人底细的工程师。不保证背完就能进大厂但我可以保证你把这些问题背后的逻辑真正想明白之后再遇到同类追问不会心虚。1. 面试官到底在筛什么先搞懂这8道题的底层逻辑很多人准备面试的方式是刷题、背答案这恰恰是最容易出局的准备方式。因为LLM这个领域更新太快今天的高频知识点三个月后就可能过时了面试官真正想看到的是你拆解未知问题的能力而不是复述已知答案的能力。1.1 三种LLM岗位考察重心完全不同同样的8个问题在不同岗位的面试里权重和追问方向都不一样。先搞清楚你面的是什么方向再决定回答时侧重哪里。LLM应用开发岗主要工作是调API、搭RAG、写Agent、做Prompt工程、建设评估体系。面试官重点看你是否理解模型的行为边界是否知道什么时候该用RAG、什么时候该微调、评估指标怎么定。LLM算法岗偏预训练、SFT、RLHF、对齐、数据配比。面试官会往数学和论文细节深挖比如损失函数、采样策略、训练稳定性。LLM推理与基础架构岗偏vLLM、TensorRT-LLM、量化、分布式推理、KV Cache优化。面试官更关心显存计算、吞吐率、延迟这些硬指标。你这篇文章如果只是背了答案却在面试里搞不清自己的岗位定位很容易在追问环节露馅。所以后面每个问题我都会尽量标注“这个答案主要能帮你过应用岗算法岗还要准备哪些延伸架构岗要往哪里深入”方便你对号入座。1.2 面试官判断“好答案”的三条标准我筛人有一套固定的心理打分逻辑倒不复杂就三条定义先行给你一个问题你能不能先花了10秒把概念界定清楚。比如问“什么是RAG”如果上来就巴拉巴拉讲论文流程不如先一句话定义“RAG是一种先用检索拿到外部知识再把它塞进上下文让模型据此生成的方案。”定义清楚说明你真懂自己在说什么。分层回答好答案通常分三层——先用直觉解释让面试官听懂再用机制细节证明你真懂最后用工程经验说明你实践过。只停留在第一层显得浅只倒术语又显得背稿。诚实暴露边界不会答不可怕可怕的是硬编。说“这块我没有亲自验证过按我的理解可能是……”这句话在面试里一点都不掉价反而能证明你有判断力。我见过一个候选人被问到“幻觉是怎么产生的”直接答“因为模型训练得不够好数据质量差”。这个回答错吗没说错但这就是典型的第一层答案。面试官只要追问一句“那如果给你完美的训练数据幻觉会消失吗”他就接不住了。我后面会专门拆这道题。1.3 为什么“会背文档”的候选人往往最先出局这几年有个明显的趋势背文档型候选人的存活率越来越低。原因不复杂——LLM领域的公开资料更新速度远超任何人的学习速度你背诵的版本可能已经是旧版本了。就说模型本身去年大家还在聊GPT-4为什么强今年讨论重点已经变成了长上下文、多模态、推理成本、Agent可靠性。面试官一天面好几个人大家都是背的同一份面经他早就听麻了。真正能区分人的是推理链路。比如问“为什么上下文窗口不能无限大”会背的人说“因为注意力是O(n²)的复杂度”但你再追问一句“那现在有了FlashAttention你把复杂度优化掉了是不是就能无限长了”很多人就卡住了。实际上计算复杂度只是其中一个瓶颈KV Cache显存占用、位置编码外推能力、长文本中的信息丢失每一个都限制着窗口长度。能把这几层串起来讲清楚才算是过了“理解关”。2. 原理层三连问幻觉、上下文窗口与temperature的“看似简单”这三个问题有个共同特点表面上都是只要你用过LLM就能聊两句的话题但大多数人的理解只停留在大白话层面一深问就散架。它们是面试里淘汰率最高的开场题。2.1 第一问为什么不学知识的模型会产生幻觉这道题的及格答案是LLM本质上是“下一个token预测器”它的优化目标是输出一段概率最高、语义上最连贯的文本而不是输出客观事实。所以当它遇到不确定的知识时最合理的策略是“编一个听起来合理的答案”因为从语言模型角度看流利的编造比诚实的“不知道”更像一段好文本。高分答案需要往前再推一步幻觉有三个独立的来源。第一个是训练数据本身就有错误、矛盾和过期信息模型只是忠实复读了它们第二个是注意力机制本质上是一种软性检索它会命中那些“统计上高频的模式”而不是“事实正确的条目”比如“某产品的创始人是谁”这种问题如果训练语料里存在多种说法模型可能把最高频的错配当成真值第三个是解码阶段的随机性温度调高以后低概率词也有机会被选中模型可能走向一条错误的生成路径。加分项是补一句工程处理我项目里缓解幻觉不是靠换更大的模型而是把RAG的召回结果作为事实锚点再在Prompt里强制要求“如果上下文里没有依据就回答不知道”同时在解码参数上把温度压低。实测下来凭空编造的case能减少一大半但完全消除是不可能的——因为模型的结构性行为就是“合理续写”你只能约束它不能根除它。这一问如果往算法岗延伸面试官会继续问“那为什么RLHF能减少幻觉”你要能接住“RLHF本质上是在教模型区分‘人类更喜欢的输出’它并不能直接修正事实错误”之类的判断。如果往架构岗延伸大概率会问“有没有办法在推理时做事实性约束”可以提解码时禁止词表、基于外部知识库的logit干预等方向。2.2 第二问上下文窗口为什么不是越大越好这道题考察的是你对LLM运行机制的理解而不只是记住几个数字。标准答案是自注意力机制的计算量随序列长度呈平方级增长序列越长相计算量越大。如果窗口从4K涨到32K意味着长度变到原来的8倍标准注意力计算的乘法和显存开销会变成原来的64倍左右。这个数字一出来就能解释为什么所有主流模型都在窗口长度上那么克制。但更深的答案是计算量只是第一层瓶颈KV Cache才是实际工程里最痛的约束。推理时每个token的K和V都要缓存下来供后续位置查询序列越长KV Cache占用显存越大。你可以算一笔账假设一个7B模型的KV Cache每个token要占几百KB具体看层数、头数和维度8K上下文时还好一旦到128K光缓存就能吃掉十几GB显存。这还没算上位置编码的外推问题——模型在预训练时见到的最长序列是有限的推理时突然给一个超长输入位置编码落入训练分布之外注意力分数就会退化输出质量反而下降。加分项是提两个现象一是“Lost in the Middle”模型对长文本开头和结尾的内容利用得很好对中间部分却经常忽略所以长上下文不等于长记忆二是工程上的常用解法比如滑动窗口注意力、稀疏注意力、位置编码外推方法像YaRN这类调整RoPE基频的方案、以及KV Cache量化。把这些点串起来说面试官就能确定你是真做过长文本项目而不是背了两篇文章标题。2.3 第三问temperature0就一定稳定吗这道题特别有意思因为它看起来是在考参数含义实际上在考你对“确定性”这个概念的理解是否成熟。基础层面的答案temperature控制的是softmax之后概率分布的平滑程度温度越高分布越平、越随机温度越低分布越尖、越接近贪婪解码。设为0时理论上每次都选最大概率那个token输出应该是确定的。但面试官只要接着问一句“那你线上把temperature设成0SLG会不会每次结果都一样”这道题就升级了。真正的答案是不会。原因有三个。第一采样环节里可能还有其他的随机因素比如top-p、top-k的随机性虽然温和但并非完全不存在。更关键的第二个原因是推理框架的浮点运算是非确定性的——GPU并行计算时浮点加法的顺序不同会导致细微误差这个误差在高维矩阵乘法里会被放大从而影响最终选中的token。第三个原因是服务端的批处理vLLM这类框架为了吞吐会把多个请求动态拼到一个batch里矩阵乘法的分块方式会随之变化数值结果就跟着变了。加分项是可以提一下“seed参数也不可靠”——你设了随机种子能让同一个进程里前后两次推理一致但换一台GPU、换一个CUDA版本、或者换一个推理框架结果就可能不一样了。这一问能答到这个程度面试官对你的工程素养基本会放心。最怕的回答是“我平时都设temperature0从来没出过问题”那说明你压根没做过线上对比测试。3. 应用层两连问RAG与微调的选择、评估指标怎么定过了原理层面试官会开始考察你的方案设计能力。这一层问的不是你会不会写代码而是你怎么把一个业务问题拆成技术方案再收敛成可度量的结果。3.1 第四问RAG和微调到底怎么选这一问是所有LLM应用工程师面试里出现频率最高的。面试官的真实动机是看你的需求拆解能力——很多候选人一上来就背书“RAG适合实时知识微调适合风格模仿”这句话是对的但太单薄。你要先明确这轮技术的目标是什么是要让模型学到新的知识还是要改变模型的输出行为和风格如果是让模型知道一个“知识库里的新事实”比如企业内部文档里的条款正确答案是RAG。因为微调本质上是在改变模型参数里的概率分布你很难精准控制它记住哪一条事实而且每更新一次知识就要重新训练一次成本高、周期长。RAG就灵活多了知识都放在向量库里文档更新后直接替换索引模型代码一行不用改。如果是让模型“总是用某种口吻说话”比如客服机器人必须按固定话术模板回复或者让模型输出严格的JSON结构方便下游解析这时候微调更合适。因为这类行为不是“知道什么”的问题而是“习惯怎么表达”的问题靠RAG每次往上下文里塞例子也行但会占用宝贵的上下文窗口且偶尔还是会跑偏。加分项是给出一个混合方案在真实项目里大多数情况是“微调管风格RAG管事实”。先用微调把模型的输出规范成你需要的格式、口吻和拒绝话术再用RAG把业务知识注入上下文让它在确定的事实范围内生成。如果面的是算法岗还可以补充一句“常见教训是RAG的召回质量还没调好就急着上微调结果问题出在检索环节模型反而被错误召回给带偏了”这句话一出来面试官就知道你是实打实踩过坑的人。这道题也有反面案例有人回答“直接用LangChain里的VectorStore文档切块塞进去就行”这暴露了致命的短板——他完全没考虑过召回率和检索质量的问题。知识库几千个切块文档Top-K召回回来的到底是不是真正相关的那个块事实上很多RAG项目效果差问题不在模型而在切块粒度、Embedding模型、索引策略和重排序。这些点如果你能主动讲出来会是大加分。3.2 第五问评估一个LLM应用该看什么指标这道题几乎能直接决定一个应用岗候选人能不能进入下一轮。因为LLM应用的落地难点不是“做出来”而是“说不清楚好还是不好”。如果面试者回答“看准确率”在这一问基本就凉了——LLM是生成式的输出是无限开放的句子用分类任务的准确率来衡量行不通如果说“看BLEU”也会被扣分因为BLEU适合机器翻译和摘要对开放式问答而言一个语义完全正确但用词不同的答案分数可能被压得很低。及格答案是先把评估拆成几个维度一是事实正确性生成的答案是否与公认事实一致二是答案相关性是否真的回答了用户的问题三是忠实度答案是否只基于给定的知识上下文有没有自己添油加醋四是召回质量检索回来的知识块是否真的包含了回答所需的答案。高分答案是给出工程化思路先找100个线上线下收集来的Badcase做人工标注把它们分门别类是答非所问还是编造事实还是检索失败然后针对每类设计评估手段。现在业界比较成熟的做法是LLM-as-judge让一个强模型当裁判对着Rubric打分再抽样让人类复核裁判模型的效果。但必须提一句裁判模型有自己的偏差比如偏好格式更漂亮的长答案比如在A/B对比里总是偏好第二份回答。所以评估器本身要定期用人工标注样本校验。这一问最值钱的输出是告诉面试官“评估体系是活的”。线上日志要持续回流每周从用户反馈里挖新的Badcase补充进评估集模型一更新、Prompt一调整立刻用这个集子回归测试。能把这条链路讲完整面试官就会认为你具备把一个Demo变成可维护系统的基本能力。4. 系统层两连问推理成本压半与Agent失控问到这一层说明前面的基础关已经过了。接下来面试官想掂量的是你有没有“系统级思维”——能不能站在成本、稳定性和可靠性的角度去看待LLM而不只是当成一个输入输出黑盒。4.1 第六问怎么把推理成本压到原来的一半这道题背后考察的是你的成本意识这可是LLM应用能否长期跑下去的核心竞争力。一个没有成本意识的候选人方案做得再漂亮架构师听了都会头疼。回答方向不止一个我会按从易到难、从实用到进阶的顺序给出一套比较完整的框架。首选方案是缓存。现在主流大模型API基本都支持Prompt Caching系统提示词、长文档、少样本示例这些反复出现的部分命中缓存后价格可以降到原来的十分之一左右。RAG类应用尤其适合因为你会把一大堆背景知识重复塞给模型把这一层缓存用好成本下降立竿见影。第二个方案是模型路由。不是所有用户请求都需要最强模型来处理。先用一个小模型或者规则判断请求的复杂度简单的任务比如“帮我翻译这句话”走小模型复杂的推理比如“分析这份合同的风险点”才路由到大模型。实测下来一个中低复杂度为主的业务用路由可以把大模型的调用量压掉一半还多成本自然就下来了。第三个方案是量化和蒸馏。如果模型是自部署的GGUF这类量化格式值得研究——它可以把一个70B的模型量化到INT4甚至更低精度在显存受限的机器上跑起来安卓本地跑小模型用的也是这套方案。量化之后单次推理的显存占用和计算量明显降低代价是效果会有轻微损失需要拿评估集验一下损失是否可接受。蒸馏是更彻底的路子用大模型当老师生成一批高质量数据训练一个小模型去模仿它长期来看单位成本能降一个数量级。这里还可以补充几个细节把max_tokens设到合理值避免模型大开大合地输出废话对历史多轮对话做压缩只保留最新几轮和前面的摘要既省Token又减少噪音能用批处理的任务就别走实时接口vLLM这类框架在batch场景下吞吐率会成倍提升。最后记得补一句省钱不是唯一目标要拉上延迟和质量一起权衡真实项目里往往是“把成本压到一半同时把质量损失控制在一个可接受的区间”。4.2 第七问Agent为什么会失控Agent是最近一两年的热门方向面试官问这道题一方面在看你对“工程可靠性”的理解另一方面也在看你有没有被媒体宣传带偏。上来先澄清概念与其直接给定义不如先分类——对话型Agent、工具调用型Agent、自主规划型Agent。面试里说的“失控”多半是后两类尤其是工具调用型。失控的表现形式很典型模型拿到工具返回结果后不断发起新调用进入死循环某一步工具返回了错误数据模型识别不出来还拿这个错误结果作为推理基础一路错到结尾上下文窗口被Agent的中间思考过程塞满重要信息反而被挤掉。这些现象的本质原因是LLM对“任务是否完成”没有天然的强感知。它靠概率判断下一个动作但“继续”这个动作往往在统计上比“到此为止”更像合理的下一步所以你不给它约束它就会合理地一直跑下去。高分的答案是给出一套工程化解法我一般按四层来讲工具层每个工具必须有结构化的返回协议和错误码模型不仅能拿到“结果”还能知道“这次调用是否成功”同时给每个工具设置最大调用次数和多步调用熔断。记忆层短期记忆和长期记忆分离上下文里只保留必要的任务上下文超长就做摘要压缩避免Agent在乱糟糟的历史里迷失。规划层不要完全指望模型自由发挥规划能力把复杂任务做成一个固定的DAG有向无环图让模型在每个节点上做有限选择而不是面对一张白纸。容错层每一步校验输出是否符合预期加全局超时和人工审查节点关键操作必须在指定权限范围内执行。最核心的一句话放在最后Agent本质上是一个概率性组件可靠的工程系统必须把它包裹在确定性的流程里——小步验证、及时失败、可观测、可回滚。这句话一出口面试官基本就认定你有过Agent落地的真实经验了因为很多翻车案例都是因为团队把Agent当成万能黑盒完全没做任何护栏。5. 第八问自注意力机制为什么最基础的问题反而淘汰率最高最后一个问题听起来最简单却是整个面试里暴露问题最彻底的一问。Transformer的自注意力机制是LLM的地基几乎所有高阶话题——长上下文、KV Cache、位置编码、稀疏注意力——都从这里长出来。面试官特别喜欢用这个问题开场因为它能快速区分“背过论文的”和“真正理解的”。5.1 通俗版一句话讲清楚每个token在干什么如果要用一句话向不懂技术的人解释自注意力我会说让序列里的每个词都主动去看一眼其他所有词判断谁的哪些信息对我有用然后把这些有用信息加权汇总进自己的表示。用个生活类比开会时每个人都要发言但发言内容不能闭着眼睛说得先快速听一遍其他人的发言评估“这句话跟我要说的内容沾不沾边”沾边就多参考一点不沾边就少参考一点。开完会每个人发言时脑子里已经综合了全场的信息。Token在自注意力里干的事就相当于开会时一边听一边判断一边更新自己的发言稿。这个通俗版的优点是让面试官知道你具备把复杂概念讲清楚的表达能力。但要拿高分光有通俗版远远不够必须接着上机制细节。5.2 进阶级QKV、缩放点积与softmax的完整链路进阶版本要能说清楚QKV三者的具体分工Q是Query代表“当前token在找什么”K是Key代表“当前token能给外界提供什么标签”V是Value代表“当前token实际携带的内容”。刚才的类比里Q就是“我在听的时候关注什么话题”K就是“我这句话的标题是什么”V才是“我这句话的正文”。自注意力的计算流程是先把每个token的输入向量分别乘上三个权重矩阵得到Q、K、V然后用Q去跟序列里所有token的K做点积再除以一个缩放系数得到注意力分数注意力分数过softmax归一化变成一组和为1的权重最后用这组权重对所有的V做加权求和得到当前token融合全局信息后的输出。整个过程可以并行计算这是Transformer能取代RNN的关键原因——你不需要像RNN那样逐个词往后扫描整个序列的依赖关系一次性算完训练时就能充分利用GPU大规模并行。5.3 加分项从自注意力讲到KV Cache的历史问题想答出区分度一定要主动把话题延伸到工程实现层面。面试官的追问设计通常在这里等着你既然整个序列的QKV一起算那到了推理阶段是不是每生成一个新token都需要把前面所有token的输入重新算一遍正确答案是不需要也不需要重新计算它们的QKV因为前面这些token的输入已经固定了它们的K和V不会再变了。于是推理框架里就有了KV Cache这个核心优化——把已经算好的K和V缓存下来每次只计算新token的Q然后拿它去跟缓存里的KV做注意力运算。所有主流推理引擎都在拼命优化KV Cache的显存占用和访存效率你前面聊过的长上下文、量化推理最后都会汇聚到这一层来。还有一个常见的加分追问为什么点积要除以根号d_k如果面试官不问你也可以主动提一句维度越大向量点积的绝对值越大softmax输入过大时概率分布会快速滑向极端接近one-hot这样注意力分数一旦算偏一点梯度就会接近消失训练就变得极不稳定。除一下根号d_k相当于把点积拉回到方差可控的区间这是保证Transformer训练稳定的一个很精巧的设计。能把这一问也接住面试官对你的印象会非常不错。6. 面试前夜突击一张自测表与三个真实翻车现场8个问题聊完了但我不建议你直接上考场。最后这part是我作为面试官和过来人想分享的准备方法和避坑心得重要程度不亚于答案本身。6.1 十分钟自测表八问逐项打分面试前一夜别再刷新题了把下面这张表拿出来自测一遍。打分标准很简单能用自己的话层层递进讲满三分钟并且能应对面试官的追问得5分能讲清楚直觉版本但细节模糊得3分只能背出一句定义得1分。总分低于30分建议再花一晚补补弱项。问题自评分自测时的关键标尺幻觉的产生机制/5能不能讲出三个独立的幻觉来源上下文窗口的边界/5能不能说出计算复杂度、KV Cache、位置编码三层限制temperature0的稳定性/5能不能讲出浮点与并行带来的非确定性RAG与微调的选择/5能不能给出“微调管风格RAG管事实”的混合策略LLM应用评估指标/5能不能讲出评估维度与LLM-as-judge的偏差推理成本压半/5能不能按缓存、路由、量化、蒸馏的顺序铺开Agent失控与防治/5能不能讲出工具层、记忆层、规划层、容错层自注意力机制/5能不能从生活话术讲到缩放点积再到KV Cache6.2 我见过的典型翻车现场翻车现场一把幻觉说成“模型太笨”。有个候选人很自信说幻觉就是模型智力不足等GPT-6出来就解决了。先不论对错这个回答完全暴露了他没有从机制层面思考问题——LLM的目标函数从来不是“求真”而是“求合理”下一代模型只会“更合理地编造”而不是“天然知道对错”。翻车现场二盲目鼓吹微调。还有一个候选人聊到RAG和微调时言必称“微调能解决一切”好像模型不够好就微调一下。面试官只要追问一句“你想让模型知道今天的新增知识微调需要多少数据、多少卡、多少时间线上的延迟和成本怎么控制”他就答不上来了。记住微调是成本最高、周期最慢的手段很多场景其实用RAG加更好的Prompt就能解决。翻车现场三讲不清评估。也有一个候选人感觉很可惜手搓过Demo还做过一个小型RAG项目聊技术细节都挺顺一谈到“你怎么知道你的改动让效果变好了”他只回了一句“问了几个朋友说感觉变聪明了”。没有评估体系的落地经验在面试官眼里就等于没有落地经验。6.3 最后一点个人建议带过的实习生和来请我帮忙模拟面试的朋友里最后拿到不错offer的不是那些回答最快最流利的人而是愿意说“这块我没验证过但按我的理解可能是这样”的人。LLM面试考的不是你记住了多少答案而是你在未知面前建立假设、验证假设的能力这一点装不出来只能靠平时做项目时多想一层“为什么”。如果你还有两三天时间我给你一个特别管用的练习方法把上面这8个问题分别讲给一个完全不懂技术的朋友听。什么时候你能让他听懂“为什么temperature0还是会变化”“RAG和微调到底差在哪”你就真正准备好了。这个方法的原理很简单——能讲给外行听的人一定已经把这个知识点拆解成了结构化的逻辑片段而结构化恰恰是面试里最稀缺的东西。