1. 为什么这几个问题年年必考，答不上来真的会挂
这几年我陆续面过不少候选人也帮团队做过技术面试，发现一个很有意思的现象：LLM岗位的面试题翻来覆去核心就那么几类，但每年挂在同样问题上的人依然很多。有人简历上写“精通大模型微调”，结果连tokenizer的基本逻辑都讲不透；有人项目里做了RAG，却说不出为什么召回用向量检索而不是关键词匹配。你要是去问面试官，他们其实不指望你背出什么冷门论文，他们就想确认一件事：这个人是真的动手做过，还是只跑通了别人的demo。
这篇文章把我认为最核心的8个LLM面试问题逐一拆开，讲清楚每个问题背后的考察意图、完整的回答思路、容易踩的坑，以及我在实际项目里积累的经验。这里说的“答不上来直接淘汰”，并不是说你必须一字不差背出标准答案，而是说这些问题覆盖了LLM从原理到工程落地的关键链路，任何一个断掉都意味着你没法独立搞定真实业务。适合准备大模型算法岗、应用开发岗面试的同学，也适合刚入门想建立知识框架的读者。
面试官问问题的时候，心里其实都有一张“能力地图”：你对token和注意力机制的理解，代表你有没有吃透底层原理；你对RAG和微调边界的判断，代表你有没有真正的方案选型经验；你如何聊幻觉和Agent，代表你有没有踩过生产环境的坑。接下来我按从原理到应用再到评估的顺序，把这8个问题逐个过一遍。
2. 第1-2题：Tokenizer和Self-Attention，底层原理是分水岭
2.1 必问题一：什么是token？为什么LLM不按字符处理文本？
这是LLM面试里最基础却也最能拉开差距的问题。很多人能说出“token是分词后的单元”，但面试官追问一句“为什么要用token而不是按字切？”就卡住了。
回答这个问题，我的建议分三层来讲。第一层先说定义：token是模型处理文本的最小单元，它可以是完整的英文单词（比如“apple”）、中文里的一个汉字，也可以是子词片段（比如“unhappiness”会被拆成“un”“happiness”或更细粒度）。第二层说原因：如果按单个字符处理，模型的输入序列会变得非常长，而Transformer的显存占用和计算开销随序列长度呈二次增长，字符级建模在效率上完全不可行。如果按整词处理，词汇表会爆炸，而且无法处理未登录词。所以现代LLM普遍用Byte Pair Encoding这样的子词算法，在词表和序列长度之间取折中。第三层最好能带一个具体例子，比如“我喜欢大模型”这句话，按字符切是6个token，按常用中文tokenizer可能也是6个左右，但同样这句话翻译成英文按子词切可能又有不同分法。这样展示你是真用过，不是背概念。
我踩过的坑是在早期项目里直接拿Python的len()去截断文本，导致线上报错。后来才想明白，对于中文，一个汉字往往就是一个token，但英文一个单词可能切成2-3个token，所以同样128个token的上下文窗口，英文实际能装下的“字数”比中文少很多。这个差异在设计prompt长度时要格外注意。
2.2 必问题二：Transformer的self-attention到底在算什么？
这个问题考察的是你对模型结构的真实理解。完整的回答应该包含这几点：QKV分别是什么、注意力分数怎么算、为什么除以sqrt(d_k)、softmax的作用。
我一般推荐用一句话总结核心逻辑：对序列里的每个token，我们让它去和其他所有token做相似度计算，然后按相似度加权汇总其他token的信息。展开说就是，每个token通过三个不同的权重矩阵映射出query、key、value三个向量，query代表“我想找什么”，key代表“我有什么可以被匹配的标签”，value代表“我实际携带的内容”。计算时用query和所有key做点积得到分数，点积结果越大说明越相关，然后除以sqrt(d_k)做缩放，防止点积过大导致softmax梯度消失，最后softmax归一化成权重，再对value加权求和。
面试官如果继续追问“为什么要多头注意力”，可以从多角度回答：单头注意力只能学一种关系模式，多头让模型同时关注不同距离、不同语义维度上的依赖关系，比如一个头关注语法结构，另一个头关注指代关系。也可以说多头相当于多个“子空间”的集成，增强了表达力。这里我补充一个实操体会：在项目里看attention可视化时，不同头的关注模式差异确实很明显，有的头几乎只关注句法邻近词，有的头能跨长距离捕捉指代。
回答这个问题时最容易犯的错是只背公式不解释直觉。面试官想知道的是你能否把这个机制讲给产品经理听，所以尽量用“找相关信息”这种生活化类比来辅助说明。
3. 第3-4题：KV Cache和RAG，工程视角的分界线
3.1 必问题三：为什么需要KV Cache？它到底省了什么？
这个问题非常考察工程实践能力。很多人听过这个词但说不清它解决什么问题。回答逻辑是：自回归生成时，每生成一个新token，都需要拿当前token的query去和之前所有token的key做注意力计算。如果没有缓存，每次生成都要重新计算所有历史token的QKV，计算量随序列长度递增，生成速度会慢到不可用。
KV Cache就是把历史token的K和V向量缓存下来，生成新token时只算当前token的Q，然后用它去和缓存的K做匹配、对缓存的V做加权求和，这样省掉了历史token的重复计算。面试官大概率会追问KV Cache的内存占用问题，这就要提到它的大致计算公式：2（K和V两个矩阵）乘以层数乘以注意力头数乘以序列长度乘以头维度乘以精度字节数。以7B模型和常见配置来算，8K上下文时KV Cache可能占用几个GB显存，这也是为什么长上下文推理这么吃显存的原因。
我实际项目里遇到过显存爆炸的问题，后来是通过切换成8位KV Cache量化才撑住。这类经验在面试里提一嘴，效果比背公式好得多。另外要能说出KV Cache是典型的以空间换时间策略，这是面试官想听到的工程权衡思维。
3.2 必问题四：RAG和微调都在解决什么问题？什么时候选RAG？
这个问题是我面试别人时最喜欢问的，因为它直接反映候选人有没有做方案选型的能力。回答的关键是不能二选一，而是要说清楚两者本质不同：微调是改变模型本身的参数和行为模式，让模型“学会”某种能力或风格；RAG不改模型参数，而是从外部检索相关信息拼进上下文，让模型“看到”需要的信息再生成。
具体选型逻辑我总结成一句话：知识密集、需要高频更新、要求可追溯的场景优先RAG；行为风格、输出格式、领域技能需要固化到模型里的场景才考虑微调。比如做一个企业知识库问答，文档每周都在更新，你去微调一次模型成本极高，而RAG只需要重新索引文档，成本几乎为零。反过来，如果希望模型永远用特定格式输出JSON并遵循特定术语，微调的效果远比在prompt里反复强调要稳定。
实际业务里RAG和微调不是互斥的。我做过的项目里，先用微调让模型学会客服口吻和常见的意图判断，再挂上RAG让它回答知识库里的具体问题。给面试官讲清楚这种“微调固化能力、RAG注入知识”的组合拳，会明显拉开你和其他候选人的差距。另外要能说出RAG的关键环节——文档切分策略、向量模型选择、检索排序、上下文压缩——这些细节才是体现你做过真实项目的证据。
4. 第5-6题：幻觉和Agent，生产环境是照妖镜
4.1 必问题五：大模型为什么会产生幻觉？有哪些缓解手段？
面试官问这个问题的潜台词是：你敢不敢把模型放到生产环境，有没有处理过它“一本正经胡说八道”的情况。回答分两部分：先说原因，再说解决手段。
原因层面至少要覆盖三点：第一，模型训练目标是预测下一个token，而不是判别事实真伪，本质上它是一个“文本续写器”；第二，训练数据里本身含有错误信息或过时信息，模型会把噪声当作规律记下来；第三，解码策略比如temperature比较高的采样会增加输出的随机性，更容易胡编。有时模型确实“不知道答案”，但它的训练目标不允许它停下来，于是只能编一个看起来合理的答案。
缓解手段要分场景讲。最常用的兜底方案是RAG，用检索到的真实知识约束生成，这也是目前业界落地最广的方案。还可以在prompt层面约束，比如明确告诉模型“没有充足信息就承认不知道”，配合低temperature设置。更工程化的手段是置信度阈值：让模型在回答时同时输出一个“确定程度”，低于阈值就拒绝回答或转人工。我实际做过的一个知识问答项目里，把“不确定时承认不知道”写进system prompt后，幻觉率下降了大约30%，当然这是在问题的知识确有可能覆盖不到的情况下。另外还有事后检测方向，比如让另一个模型对回答做事实核查，代价偏高但效果直接。
这个问题要避免的答案是只背“幻觉是因为模型在编故事”这种浅层理解。能给出量化的缓解效果和改进路径，才是面试官想要的。
4.2 必问题六：什么是Agent？LLM怎么调用工具？
Agent是这两年面试高频区，但也是重灾区——很多人把“在prompt里让模型输出JSON再执行函数”就当成了Agent。面试官真正想听到的是你对“模型-工具-环境”闭环的理解。
一个合格的回答结构是这样的：Agent的核心是让LLM从“文本生成器”变成“决策者”，它通过感知用户请求、拆解任务、调用工具、观察结果、调整方案来完成一个多步骤目标。关键设计点是让模型具备使用工具的能力，最常见的方式是function calling或tool calling：系统把可用工具的描述、参数结构通过API传给模型，模型在生成时决定“我要调用哪个工具、传什么参数”，然后外部的执行器真正去调用这个工具，把结果返回给模型，模型再基于结果决定下一步动作。
面试官大概率会追问“Agent的规划能力从哪来”，这里可以深入讲：Agent的规划能力在模型层面来自它训练时积累的代码、逻辑推理数据，在工程层面来自我们的ReAct循环（思考-行动-观察），你把大任务拆成多轮小任务，每轮都让模型基于当前观察做决策。没有工程框架支撑，模型自己规划长任务很容易迷失，所以要做任务拆解、状态记忆、循环上限控制这些工程兜底。
我强烈建议在回答里加入一个你做过的具体Agent案例，比如“让LLM在知识库系统里自主完成多轮数据库查询和报表生成”。没有真实项目的候选人，在这个问题上基本一聊就露馅。我给面试者的建议是：哪怕是自己写个demo在小场景里跑通，也比只谈概念好得多。
5. 第7-8题：长文本和评估体系，拉开高手和普通人的差距
5.1 必问题七：上下文窗口越长越好吗？长文本带来的问题怎么处理？
这个问题的陷阱在于，很多人会直接回答“越长越好”。有经验的面试官想听的是“不要盲目追求长上下文”的工程判断。
回答先说结论：长上下文会带来三个维度的代价。第一是显存和计算开销显著上升，前面讲KV Cache时提过占用随序列长度增长，长文本推理时即使有缓存，生成阶段的显存压力和延迟也不可忽视，极端情况下甚至会OOM。第二是“迷失在中间”问题，模型对长上下文中间的注意力分配不如开头和结尾，导致关键信息如果落在中部可能被忽略。第三是数据量问题，长文本训练数据的稀缺和构造难度天然限制了模型在超长序列上的表现。
工程上处理长文本有几个思路：最常用的是先做相关片段检索而不是把全文都塞进去，这本质上是RAG的思路；其次是做上下文压缩，比如先让模型对长文本分段生成摘要，再把摘要拼进去；再往后才是用支持更长窗口的模型。这里能体现经验的是，当模型突然“忘记”了上下文前面内容时，先排查是不是上下文被超长截断或摘要丢失成了信息瓶颈，再考虑升级模型。
我建议回答时主动给一个实际场景，比如处理一本几十万字的合同或论文，你会怎么做。能讲清楚“检索-切分-摘要-在线问答”的组合方案，远比报一个“这个模型支持200K上下文”来得有说服力。
5.2 必问题八：怎么评估一个LLM的效果？只看跑分可以吗？
评估问题是区分“调包侠”和真正做过项目的人的最有效问题。很多人只会说“用BLEU、ROUGE看指标”，但实际业务里这些指标和用户真实体验往往对不上。
回答的思路应该分层：先说基准测试的作用和局限。MMLU、HumanEval、GSM8K这些公开benchmark适合横向对比模型基础能力，但问题在于测试集可能出现在模型训练数据里，也就是数据污染，而且评测任务和你的真实业务场景差距很大，分数高不代表你的场景好用。再说针对自己业务场景的评估体系才是最关键的，具体做法是构建一个“黄金评测集”：从真实用户问题里挑出几百条有代表性的case，覆盖典型场景、边界情况、困难case，标注好标准答案或评分维度。然后对模型的回答从正确性、完整性、格式合规、语气一致性等维度打分，人工评和LLM-as-judge自动评结合。这个集子做出来后，每次换模型、改prompt、调RAG参数，都拿它跑回归，比什么都直观。
我在项目里的实操经验是：第一，评估集一定要包含“无标准答案的主观题”，让两个模型结果做对比排序；第二，绝不能只看平均分，要按错误类型分类看，比如“漏答”“事实错误”“过时信息”分别统计，这样定位问题才能精准；第三，LLM-as-judge有评分偏差，要用规则约束评分维度，必要时抽样让人复核。这些细节讲出来，面试官基本就会认定你是真正搭建过评估体系的人。
6. 面试表达里的三个隐藏考点
很多技术扎实的人挂在表达方式上，这很可惜。结合我面试别人的经历，分享三个隐藏考点。
第一，回答要分层。面试官问原理题时，先给一句话核心结论，再展开细节，最后落地到项目案例。这种“结论先行”的表达方式，和你在工作中给团队讲方案是一样的逻辑。我有一次面试一个候选人，他技术深度确实不错，但每次回答都从最底层细节开始讲，讲了半天面试官还在猜他要表达什么，最后评价大打折扣。
第二，不会的问题要会“诚实+靠近”。没人能做到所有问题都对答如流，但优秀的候选人会在说“这部分我没有实际做过”的同时，立刻补充“但基于我对相关部分的了解，我的推测是……”。关键是不能空口瞎猜，而是要把问题拉回到你熟悉的邻近领域，展示你的思考框架。
第三，每一个项目经历都要能说出“为什么”和“踩了什么坑”。面试官最烦的项目描述是“我用LangChain搭了一个RAG系统”，没有任何取舍思考。反过来，如果你说“我一开始用固定大小切分文档，发现效果不稳定，后来改成按标题层级做结构化切分，命中率提升了15%”，这才是活生生的经验证明。
我个人在实际面试中的体感是：前三题筛基础，中间三题筛经验，最后两题筛判断力。你能答到哪一层，基本决定了你在团队里能做多核心的事。把这8个问题吃透，再去翻一翻自己项目里那些当初没想明白的细节，面试状态会完全不一样。
