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 显存可能还装不下中间状态。
所以我们看到近一年的新模型，有不少在做“参数减少但是上下文变长”的操作。这背后的逻辑是：与其堆参数量换取容量，不如优化结构换取“有效上下文长度”。比如 MQA（Multi-Query Attention）让多个头共享一组 Key 和 Value，Cache 大小直接降好几倍；滑动窗口注意力把注意力范围限制在局部窗口里；还有稀疏注意力机制，只让部分 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 分以上的问题标记为 P0，20 分以上的标记为 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 的候选人，和一个能把概念倒背如流的候选人，面试官心里的天平一定会往前者倾斜。所以如果你正在准备相关岗位，与其把时间花在背问题上，不如回去翻翻自己的项目里那些失败的瞬间，那些才是面试现场最稀缺的弹药。
