LLM 面试这两年已经卷出了新高度。以前问“Transformer 为什么用多头注意力”还能筛人现在这个问题已经算送分题了。真正能把候选人和候选人区分开的是看他能不能把“Transformer 能生成文字”这件看似魔法的事拆解成工程上可以预算、可以评测、可以兜底的具体系统。这篇文章我换个角度不列标准答案而是把 LLM 面试里最容易被问倒、也最见功底的 8 个问题背后的考察逻辑掰开揉碎地讲一遍。每个问题我都会说明为什么面试官爱问、你该怎么答才算有水平以及最常见的错误答案长什么样。内容主要面向正在准备大模型岗位面试的同学也适合带团队的兄弟拿来当内部考核的参考框架。1. 大模型的“幻觉”问题第一题背后的三重考察幻觉基本上是 LLM 面试的必问题大概率还排在第一个。面试官问“你怎么看待大模型的幻觉问题”不是想听你把“LLM 会一本正经地胡说八道”这个现象描述一遍而是要借这道题考察三件事你有没有真正理解 LLM 的原理本质你有没有实际处理过幻觉问题以及你有没有能力把“模型缺陷”转化成“工程上可修的 bug”。先说原理本质。幻觉的根源在于 LLM 的训练目标函数是“预测下一个 token”。模型在做的事是学习文本序列的统计分布规律而不是在数据库里做精确检索。这意味着模型在生成时本质上是在高维语义空间里沿着概率路径游走它没有“核实”这个动作也没有“查询记忆库”的机制。面试时你先把这个底层逻辑讲清楚就已经比 80% 的候选人强了——大部分人的回答停留在“模型训练数据不够好”或者“模型太大太复杂”这属于没抓到重点。接着往深里说。幻觉其实还分两种一种是事实性幻觉就是生成内容与客观事实不符另一种是忠实性幻觉就是生成内容与用户指令或给定上下文不一致。这两类幻觉的成因和解法很不一样。事实性幻觉更多和知识存储方式有关模型把事实压缩进参数里回忆时可能检索错键值忠实性幻觉则更多和指令遵循能力、注意力分配有关。面试官如果追问“你觉得哪种幻觉在业务里危害更大”你需要给出自己的判断和理由。关于治理方案我的建议是RAG、系统提示词、生成参数调节、推理时验证这四板斧都要心里有数但更重要的是你要能说清楚它们各自的边界。RAG 能把“知识外部化”但它解决不了模型不遵循检索内容的问题调低 temperature 能减少随机性但牺牲的是多样性和创造性系统提示词约束是一个软约束模型可能阳奉阴违。我自己的经验是金融和医疗场景里宁可叠加一道“生成结果校验层”让规则引擎先过一遍模型的输出也不要指望模型单凭自身能力就能不犯错。一个关键的错误示范是“幻觉可以用更好的数据来解决。”这句话暴露了几个问题——你忽视了评测数据本身的污染问题也忽视了模型容量对知识记忆极限的约束。数据可以缓解幻觉但无法根除因为参数化知识本质是有损压缩。你能把这个边界说清楚说明你对 LLM 的本质有敬畏心这在面试官眼里是很大的加分项。2. 上下文窗口的算力账单为什么新模型参数“变少”了“请解释一下上下文窗口对模型性能的影响”这道题的坑在于很多人把它当成纯概念题答。讲什么是 context window 很容易但面试官真正想考的是你知不知道窗口变大背后的代价是什么。先算算账。Transformer 自注意力机制的计算复杂度是 O(n²)这里的 n 是序列长度。把上下文长度从 4K 提到 32K字符串长度 8 倍注意力计算量就是整整 64 倍。这还没有算 KV Cache 的显存消耗。KV Cache 是推理时为了避免重复计算而缓存的历史 token 的 Key 和 Value一个 7B 模型在 4K 上下文下缓存占用的显存大约在几个 GB 量级换成 32K 就直接奔着几十 GB 去了一块 A100 的 80GB 显存可能还装不下中间状态。所以我们看到近一年的新模型有不少在做“参数减少但是上下文变长”的操作。这背后的逻辑是与其堆参数量换取容量不如优化结构换取“有效上下文长度”。比如 MQAMulti-Query Attention让多个头共享一组 Key 和 ValueCache 大小直接降好几倍滑动窗口注意力把注意力范围限制在局部窗口里还有稀疏注意力机制只让部分 token 对之间算注意力。面试时你把这几条讲出来面试官就知道你读过源码级别的资料而不是停留在 API 调用层。不过光讲原理还不够要命的问题是“上下文窗口大模型就一定用得越好吗”。答案显然是否定的。有一类退化问题叫注意力分散当输入特别长时模型对关键信息的注意力反而会被稀释。工程上有个著名的处理办法叫“Lost in the Middle”就是说模型对长文中间的内容记忆明显弱于开头和结尾。面试时你可以聊聊自己怎么应对这种情况分段检索、摘要压缩、锚点重复、关键信息前置这些都是实操中验证过的手段。最后给一句机灵但不油腻的总结性表达上下文窗口不是越大越好而是越大越贵、越大越难用。谁能把“大窗口”转化成“好效果”谁才是真的值这个价。这比单纯背“32K 窗口就是 32000 个 token”有用得多。3. “差不多”在工程里行不通评测指标怎么说到面试官心里评测问题是 LLM 面试里的分水岭。很多人背了一堆 Rouge、BLEU、Perplexity但一问“你们线上模型到底怎么评估的”就支支吾吾这基本就凉了。懂评测说明你是真的做过落地不是只会跑 demo。先澄清一个常见误区Perplexity困惑度几乎不能用来衡量生成质量它衡量的是模型对给定文本的“惊讶程度”训练集里见过的文本 PPL 就低但这和业务好不好没有直接关系。BLEU 和 ROUGE 这类基于 n-gram 重合度的指标适合翻译、摘要这种有固定参考答案的任务但在开放性问答场景里一塌糊涂——因为语义正确但用词不同的回答会被判低分。现在主流实践是把评测拆成三个层次。第一层是指标评测用规则和开源数据集做批量验证快但粗糙第二层是模型评测用 GPT-4 这类强模型当裁判也就是 LLM-as-a-Judge把“谁答得更好”变成打分题优势是灵活劣势是裁判模型自身有偏好偏差需要做一致性校验第三层是人工评测找真实用户做盲测对比最慢也最贵但最接近真实效果。面试时你应该主动提前两者的本质矛盾自动评测的覆盖率和人工评测的可信度之间的矛盾。我的习惯做法是先设计一套高质量的人工评测集比如 300 条典型业务问题80 分以上的问题标记为 P020 分以上的标记为 P1用这 300 条做回归基线然后把自动评测工具调成和人工评测相关度高的版本之后日常迭代就用自动评测来筛每周人工抽检一次。还有一个点几乎每次都会被问到你的评测集会不会被污染这个问题的深层意思是如果模型训练数据里包含了你的评测问题那分数再高也没有参考价值。应对方案包括定期从线上真实用户问题里采样构建评测集监控评测集的困惑度变化曲线新增不在公开语料里的对抗问题。能说出“评测集本身也要做数据版本管理”面试官会高看你一眼。4. 训练数据的三个坑清洗、配比与污染提到“数据”不要只回答“数据很重要”那就等于没答。大型语言模型的训练已经不是“喂得越多越好”的阶段了数据工程是个精细活面试官问这个问题是想看你对数据质量的判断力和对数据配比的理解。第一坑是清洗。公开爬取的语料里重复内容、低质量内容、机器生成垃圾文本的占比相当高一个去重不去干净的数据集会直接拖垮模型的下游表现。行业里通用的做法是“质量分层”把数据按质量分桶高质量桶做少量多轮的精细训练低质量桶做粗粒度的预训练填充两者比例通常做到 1:10 甚至更低。这个做法的原理是你得控制模型见到低质文本的次数否则注意力分布会被噪声带着跑。第二坑是配比。不同来源的数据代码、百科、论坛、书籍、多语种放到训练集里不是简单拼接。代码数据能显著提升模型的逻辑推理能力所以即使代码在真实语料里的占比不高训练时也要给它较大的权重多语种数据之间有“迁移学习效应”英语学好了其他语言的能力也会上来但各语种之间仍有数据量失衡的问题。面试时你可以说“配比的本质是拿训练预算在不同的能力维度上做投资组合配置你需要给每个能力维度定一个目标水平再倒推数据占比。”第三坑是污染。这不仅指评测集被混入训练数据还包括“知识截止日期”的实现。模型不知道今天是几月几号它训练时所学到的知识都定格在某个时间点除非你做了增量训练或用 RAG 补充时效性信息否则它面对新知识就是一定有边界的。数据切分时按时间分成 train 和 test能有效防止时间泄漏但行业中仍能看到不少模型在这个问题上翻车。说明一点这些都是基于行业常见实践的补充思路实际训练数据管线远比这个复杂。面试时你不用懂到能自己写分布式数据管道但能把“清洗、配比、污染”三条主线讲清楚已经展示了系统思维。5. 微调不是唯一解什么时候该选 RAG“你什么时候选择微调什么时候选择 RAG”这道题答得好不好基本能看出你有没有做过真实的业务决策。标准答案是“看场景”但面试官想听的是你判断的过程和依据。先说 RAG 的优势它把知识外挂出来更新知识只需要更新向量数据库不需要重新训练模型生成时带着检索到的上下文理论上可以减少幻觉同时它还能提供信息来源方便审计和溯源。这些特性决定了它特别适合知识库问答、客服助手、政策解读这类“答案需要不断更新、需要引用来源”的场景。微调的优势则在于它能改变模型的“行为方式”而不是“知识内容”。如果你希望模型输出固定格式的 JSON、用特定的语气回复、按照你公司的术语体系表达或者让模型掌握某个特定领域的“思维方式”微调是正解。但微调有两个硬伤成本高需要采集标注数据、消耗算力、做效果回归且更新知识必须重训或增量训练。第二个硬伤是“灾难性遗忘”微调过程中模型可能遗忘原本学好的能力需要用混合数据策略来对冲。所以扬长避短的常规判断是知识型需求用 RAG行为型需求用微调。但真正高阶的回答是把两者叠加起来用——用微调让模型学会“如何组织和表达”用 RAG 让模型获得“最新的内容”。比如一个金融投研助手先微调让模型学会用研报分析师的格式输出研判结构再在生成时用 RAG 拉取最新财报数据。这样既保证了表述的专业性也保证了数据的时效性。面试官还会追问成本问题。这时你可以算一笔账一次微调实验从数据标注到训练到评测短则一周长则一个月人力成本好几万RAG 的日常维护成本主要是数据管道和向量库的运维。所以我的原则是能用 prompt 解决的不做 RAG能用 RAG 解决的不做微调做微调前必须先跑通“即使微调也不能解决”的论证。这套“从省钱到花钱”的决策思路在面试里是很加分的选择题解题方式。6. 推理成本降不下来聊聊 KV Cache 和量化面试官问“怎么降低 LLM 推理成本”时80% 的候选人会回答“用更小的模型”或“用更好的显卡”。你要是也这么答基本就没了。这个问题考的是你有没有真正打开过推理引擎的引擎盖。核心成本杀手是 KV Cache 和注意力计算。一次生成过程中每产生一个新 token都要拿它之前的全部 token 的 Key 和 Value 去算注意力这个历史信息如果每次重算就是浪费。KV Cache 就是为了避免重复计算而做的缓存。但代价是显存上下文越长Cache 越大。有一次线上服务压测我把并发从 8 调到 16显存直接爆了就是因为 KV Cache 占据了大量显存比模型权重本身还大。所以“降本”的第一性原理是想办法让 KV Cache 变小、让注意力计算变快。具体手段有几条量化把 FP16 的权重和激活值压成 INT8 或 INT4显存占用直接砍 50% 到 75%代价是精度损失PagedAttention把 KV Cache 切成小块按需分配提升显存利用率这是 vLLM 的核心优化之一连续批处理把多个请求拼成一个 batch 一起推理让 GPU 的计算单元尽量不闲着这是吞吐量提升的关键还有投机采样、Expert Parallel 等更高阶的操作。注意面试官通常会追问“量化为什么可行”。这是要考你的数值计算功底。模型的权重分布大体上呈正态分布集中在零附近用低比特去近似高比特虽然对个别大权重有损失但从整体概率分布的角度模型的输出变化通常还在可接受范围。加上量化感知训练在训练时就模拟量化误差修正模型能在精度和速度之间取得不错的平衡。按我的实操经验INT8 量化在大部分业务场景下几乎无损INT4 则需要看任务敏感度客服闲聊随便用法律条款问答就得谨慎试。还有一个细节经常被忽视推理成本不光是服务器算力还有 token 数。同样的请求有的模型输出 200 token有的模型输出 500 token成本差 2.5 倍。面试时说出这一点说明你不光关心 GPU 利用率还关心产品策略。能用 prompt 约束模型“简洁回答”的就不要让它自由发挥。7. Agent 的“能力幻觉”与容错设计Agent 这个概念这两年被炒得火热面试必然会问。但面试官最烦的是听到候选人把 ReAct、Tool Calling、Multi-Agent 这些词念得飞起却答不上来“你做的 Agent 在什么场景下失败过”。我在做 Agent 落地时最大的教训是Agent 最大的风险不是模型能力不够而是模型会假装自己有某种能力。这个我称之为“能力幻觉”比一般的文本幻觉更隐蔽。比如模型在规划时生成一个工具调用计划但那个计划步骤之间根本逻辑不通或者它调用了某个工具但传入的参数是从上下文里编出来的并没有真正读取到对应字段。这类错误不会以“胡言乱语”的形式出现而是以“一本正经地做错事”的形式出现用户很难察觉危害反而更大。所以 Agent 的工程核心是容错设计而不是模型能力。我们实践出来的一套算是比较可靠的东西第一层是工具层校验。每个工具在调用前必须有入参 schema 校验格式不对直接拦截不让模型把脏数据发进真实系统。第二层是规划层约束。不搞全自由的 ReAct 循环而是给 Agent 预设好工作流模板模型只能在小范围内做决策不能自己天马行空地编排步骤。第三层是执行层观测。每一步工具调用都要有完整的日志和结果快照方便事后回溯。第四层是结果层回退。一旦某一步失敗系统要有预设的降级策略比如换一个更简单的模型重试或者直接切换人工介入。面试时你能讲出“我们让 Agent 做任务时失败了 27 次最后发现是参数生成环节的格式错误”这样的真实案例比讲一百句概念都管用。这体现的是你对“模型不可靠”这个前提的清醒认知以及你为这个前提设计了什么样的保护网。还有一个加分点是聊 Agent 的安全边界——为什么不能让模型直接调用删库、转账这类不可逆操作而是要走一层人工审批。这不是技术题但比技术题更能看出你有没有全局观。8. Token 免费幻觉坏了谁的生意商业化落地问题最后这个问题越来越多公司开始在面试里问“你怎么看大模型的商业模式”这不是考你商业头脑而是考你有没有认真算过账懂不懂“免费”和“便宜”背后的算力逻辑。先看一组很基本的成本结构一次模型请求的成本主要由 prompt token 数、输出 token 数和并发量决定。一次性让模型写一篇 500 字文案看起来花不了多少钱但在高并发业务里巨头一天要承受千万级请求累计 token 消耗就是天文数字。很多面向 C 端用户的产品用大模型做免费功能本质上是在赌用户不会狂刷一旦有人拿它来薅羊毛自动生成内容成本会瞬间击穿补贴预算。这里有一个值得展开的“Token 免费幻觉”有些服务打着“无限免费 token”的旗号吸引用户但真实情况往往是——免费版模型是轻量版长文任务被悄悄截断高峰期排队限流或者生成的回答质量不如付费版。也就是说市场没有免费的算力只有被分摊的算力和被降级的算力。面试时你把这个现象说透说明你对大模型行业的实际运转有观察而不只是一个 API 调用者。那么真正健康的商业化设计长什么样按我的经验要从三个维度同时设计一是计费模型to B 按 token 或按调用量计费to C 用订阅制用量封顶二是成本控制 prompt 侧压缩精简单词、精简模板、输出侧控长max_tokens 限制、内容摘要化、缓存侧复用相同请求的响应缓存命中直接在网关层拦截三是价值分层免费版给模型能力兜底付费版给专属模型、更强上下文、更高并发优先级。面试官想听的落点是“你怎么保证业务毛利”。你不要泛泛而谈“让用户付费”而要讲你算过的一次真实账平均一次咨询请求消耗 3000 token其中输入占 2500那么优化 prompt、缩短输入 30% 后成本降了 25%毛利率提高了几个点。有数字有手段有结果这就是工程化商业思维的表达方式。比张嘴说“我觉得未来要大模型赋能百业”不知道高到哪里去了。我个人面了这么多人一个很深的体会是LLM 面试最后拼的不是背书是“你有没有在真实系统里被大模型坑过又把它修好了”。一个能讲清楚自己如何在某个深夜排查 Agent 工具调用 bug 的候选人和一个能把概念倒背如流的候选人面试官心里的天平一定会往前者倾斜。所以如果你正在准备相关岗位与其把时间花在背问题上不如回去翻翻自己的项目里那些失败的瞬间那些才是面试现场最稀缺的弹药。