最近这大半年我参与了不少算法工程师和LLM应用工程师的面试，也帮朋友模拟过不少大模型岗位的面试。一个很直观的感受是：简历里人人都会写LLM，真到现场能把基础原理讲透的人却不多。很多候选人一上来能背概念，再往深了问一层就卡住。这类情况多了之后，我发现有些问题几乎成了面试里的“一票否决项”——基础不牢，后面项目经验讲得再花哨，也很难让人放心把人招进来。这篇文章就把我自己面试时必问的8个LLM问题整理出来，每个都附上回答思路、靠谱的答法、加分项和容易翻车的点。不管你要准备面试，还是当面试官，这套清单都可以直接拿去用。
1. Transformer架构与Self-Attention原理
1.1 面试官到底在考什么
面试官问这个问题的目的，不是让你背“Attention Is All You Need”那篇论文的标题。真正想确认的是：你是否清楚Transformer在解决什么问题、和上一代序列模型相比区别在哪、Self-Attention里面的细节计算你是否真的理解。大部分人能回答“Transformer有Encoder和Decoder”“用了注意力机制”就停了，但“关键在哪”完全说不出来。
一个明显的加分回答框架是先给背景。RNN/LSTM是逐步处理序列的，步数一长信息就开始衰减，而且串行计算导致训练很难并行化。Transformer把所有Token同时放进模型，通过自注意力直接计算任意两个位置的相关性，一举解决长距离依赖和并行计算两个瓶颈。能补一句“长距离依赖从RNN里的逐步传递变成了一次信息路由问题”，这句话很能体现理解深度。
1.2 Self-Attention的计算细节
Self-Attention把每个Token转换出三组向量：查询Q、键K、值V。口语化理解是：Q是“我想找什么”，K是“我的标签”，V是“我能给的内容”。注意力分数等于Q和K做点积，再除以根号d_k做缩放，然后过Softmax变成权重，最后去加权V。
这里有两个高频追问。为什么要缩放？因为点积结果会随维度增长而方差变大，不缩放的话，Softmax会进入饱和区，梯度极小，训练效果很差。除以根号d_k之后，方差能保持稳定，梯度就可以正常传播。多头注意力在干嘛？大致是把信息分成多个子空间，让每个头关注不同的关系模式，最后拼接。面试时能提到“多头计算本质上是多组轻量级子空间投影”就够了，不用把论文公式背下来。
我还经常追一句：“Self-Attention的复杂度是多少？”标准答案是O(n²)，n是序列长度。能接下去说你了解FlashAttention、稀疏注意力这类优化的，说明你真的关注过长文本落地。大多数候选人卡在这一步，后面的项目经验讲得再花哨也会打折扣。
1.3 最常见的翻车点
我统计了一下，面试中翻车主要在三处。第一，把QKV背成“查询、关键字、值”就停了，完全不知道里面数学关系的意义。第二，分不清Attention Mask和Padding Mask，训练时因果语言模型需要把未来Token遮住，这是Masked Self-Attention；Padding出来的无效位置也要忽略，两者不要混为一谈。第三，提到位置编码只会说“加了一个Position Embedding”，答不出为什么需要它。自注意力本身对顺序不敏感，把“我爱你”三个Token打乱，权重计算结构是一模一样的，必须靠位置编码注入顺序信息。连这个都说不清，面试官很难相信你后续能独立处理长文本工程。
我在实际面试中还有一个判断技巧：如果候选人在介绍Transformer时能主动说一句“指的是Encoder部分还是Decoder部分”，说明他对不同结构变体心里有数。只会笼统地讲“Transformer就是一堆注意力层堆叠”，大概率是背的速成笔记。
2. Tokenization与上下文窗口
2.1 模型读取的不是文字而是数字下标
几乎所有LLM都不是按“字符”或“词”直接处理文本的。以BPE这类子词算法为例，文本先被切成一串Token，再映射成词表里的整数下标，模型真正处理的是一串下标对应的Embedding向量。
我在真实项目里遇到过很典型的例子：“unhappiness”如果词表里没有整个词，会被切成子词“un”和“happiness”，也可能切得更细，具体取决于预训练阶段学到的合并规则。中文里，一个汉字通常对应一个Token，但“你好”可能是一个Token也可能被切成两个，完全看分词器怎么训练。
面试题里围绕这个点会有几个变化题型，最好都准备到：
- Token和“词”“字”的区别：Token是算法切出来的最小单元，不一定等于语义词；
- 词表大小为什么敏感：词表太大，Embedding层参数量惊人，训练和部署都不方便；词表太小，一个词会被切得很碎，序列变长，计算量也涨；
- 在API接口有Token数限制的情况下，为什么“统计字数”不等于“统计Token数”。英文大约1个Token对应0.7到1个词，中文一个汉字常常1个Token，但只是粗略经验，和具体分词器强相关。
2.2 上下文窗口不是想填就能填满
上下文窗口指模型一次最多能“看到”的Token数量。面算法岗的候选人不能只背“我的模型上下文长度是128K”，要能说出限制背后的原因。
第一个原因是训练长度限制。模型在预训练时见过的最大序列长度就是它的舒适区，超过之后，位置编码不具备良好的外推能力，生成质量会明显下降。第二个原因是显存成本。运行时每个Token都会缓存的KV Cache，长度一旦翻倍，显存占用接近线性增长，长上下文推理对资源要求极高。第三个原因是注意力分配问题。即使能硬塞进去，模型对中间部分内容的利用也往往不充分，学术界说的“Lost in the Middle”就是指回答只看开头和结尾、忽略中间细节。
所以工程落地常用手段包括：截断或摘要压缩历史、滑动窗口只保留最近N轮、用向量数据库做外挂记忆而不是把全部内容塞给模型、在长上下文场景做压力测试而不是只看官方参数。能答到这个程度，面试官基本默认你做过真实项目，而不是只会调API。
2.3 面试里针对上下文窗口的区别提问
常见的追问还有“位置编码怎么区分新位置”，这是一个比较细的点。你可以说训练时常见的做法是绝对位置编码加上可学习的Embedding，而像RoPE这种旋转位置编码被越来越多模型采用，因为它能让模型更好地外推。这属于锦上添花的回答，但如果前面几题都不熟，不建议硬扯。先把主问题讲好，把翻车点避掉，得分已经很稳。
3. 预训练、微调与对齐：三个阶段到底在干什么
3.1 预训练是在压缩世界知识
一句话概括预训练：用海量文本，以“预测下一个Token”为目标，训练模型把语言规律和知识学到参数里。我更愿意用“信息压缩”来描述这个过程。参数只有几百B，训练数据是几个T的Token，模型必须把数据里重复出现的模式抽象进参数，这种压缩本身就是知识的沉淀。
这里有个经典问题：“为什么预测下一个Token这么简单的目标最终能产生各种能力？”我从几个方面回答：数据如果包含代码、科学文献、对话等多样化内容，预测任务就迫使模型在每个位置都建立足够复杂的表征来降低损失，因此学到了通用表示；在规模达到一定量级后，一些推理类能力会以涌现的方式出现。学术界对“涌现是不是真实性质”还有争议，但能力确实和规模强相关。面试时能主动提到这种争议性，反而比盲目下结论更像业内人士。
顺带提醒一个措辞细节：中文环境里“LLM”这个简称有时会产生歧义，有人指大语言模型，有人指特定模型系列。面试时如果拿不准，可以先反问确认对方指的是哪一种，这种沟通习惯在真实协作中很加分。
3.2 微调和对齐解决的是“会”还是“听话”
预训练模型的目标是续写，不是回答问题。你问“今天天气怎么样”，预训练模型可能继续写“天气是指一定区域内……”这样一段科普文字，而不是像对话一样给出面向用户的回答。所以要经过指令微调，让模型学习“问题—回答”这种交互格式；再经过对齐，让它学会更有用、更安全、更符合人类偏好的话术。
面试时建议把两者关系讲清楚：SFT解决的是“学会形式和技能”，对齐解决的是“学会价值取向和交互偏好”。顺带说一下RLHF大致流程：先训练一个奖励模型模拟人类偏好，再用强化学习让策略模型去最大化这个奖励，同时加一个KL惩罚，防止模型偏离初始分布太远而开始胡说八道。
如果面试官追问DPO，你可以说它绕过了显式奖励模型和复杂强化学习流程，直接利用偏好数据更新策略，工程实践更简单，很多开源后续工作就是靠DPO这类方法继续对齐的。这已经很够用了。
3.3 面试里容易暴露的误区
最常见的错误说法是“预训练模型什么都知道，微调之后性能一定变差”。实际情况是，如果微调数据质量差，模型确实会退化，这是灾难性遗忘；但如果数据质量高，微调可以让模型在特定领域表现更好。候选人要能区分“能力被覆盖”和“权重漂移”，并主动提到学习率要设低、数据要去重、微调少量Epoch，这些都是实操里总结出来的细节，很加印象分。
我还习惯追问“一个领域问答模型应该先预训练再微调，还是直接在基座模型微调”，答案是不要轻易做领域预训练，成本高、易遗忘，通常做法是在通用基座上做指令微调。能说出这个判断逻辑的人，说明他真的权衡过训练成本。
4. Prompt Engineering与In-Context Learning
4.1 Few-Shot怎么撑起上下文学习
给几个示例，模型就能照着格式和逻辑做类似任务，这种能力是GPT-3时代被大规模验证过的。面试里说它原理时，不要只说“模型见多识广”，可以从工程视角展开：示例实际上给模型提供了输出格式锚点、任务边界和推理路径。
举个例子，我想让模型把客服对话分类成“投诉/咨询/售后”，给它两个带分类标签的样本后，它输出的格式基本就会稳定在这几个类别里。零样本、单样本、少样本这三种方式常考。零样本完全靠指令理解，单样本给一个不可多得的格式示范，少样本进一步稳定输出格式和内容风格。从工程角度看，不是示例越多越好，和任务无关的样本反而会分散注意力。
4.2 实用提示工程设计：Chain-of-Thought与角色设定
我的建议是面试时别说“我擅长写Prompt”就结束，要拆出方法论：
- 指令明确化：把期望拆成步骤、输入、输出格式、约束条件；
- 角色与目标：设定角色不是玄学，而是为输出风格、知识背景和审查标准提供一个先验；
- 证据先行：让模型先提取相关内容再下结论，减少幻觉；
- 思维链：复杂数学和逻辑问题鼓励模型分步推理，单步输出容易出错，给足中间步骤后准确率能明显提升；
- 结构化输出：要求JSON格式时，一定要给Schema示例，否则会得到随意的键名。
面试官还会问一个高频题：“思维链为什么有效？”合理的工程解释是：它将隐式的多步推理显式地卸载到文本生成过程中，每一步只解决一个小问题，出错风险被分解；同时，模型在生成中间步骤时也相当于拿到了更多局部监督信号。学术界对确切原因尚无定论，你承认这一点，再给工程解释，比硬背一个结论要可信得多。
这里也可以顺带提一句：“Chain-of-Thought不是所有情况下都好的，简单任务强行要求分步反而会降低效率，还增加Token消耗。”这个点考官不一定会追问，但主动说出来，会让他觉得你真正调过。
4.3 真实Prompt调优的经验
我在调客服机器人的时候发现，Prompt里加“如果信息不足，明确说不知道，不要编造”比加“要诚实”更有效，因为前者给了具体行为路径。另一个心得是正反示例组合效果最好，不要只写正确示例，也要给一个错误示例，让模型直观看到什么不该做。指令最好放在系统提示词的开始和结尾，因为模型对开头和末尾的内容记忆更清晰，中间部分容易被长上下文的“Lost in the Middle”现象稀释。
5. RAG还是微调？知识更新与外部连接
5.1 RAG完整链路
RAG是全行业目前最常被问到的架构问题。完整链路绝不只是“搜一下资料再去生成”一句话，至少包含四块内容：文档清洗与切分、向量化与存储、检索与重排、生成与引用。
文档清洗与切分这一步最容易被忽视。Chunk太小导致检索噪声大、语义断裂，Chunk太大会让上下文被无关内容挤爆，常规的做法是按段落和语义边界切分，大小从256到1024个Token之间调。向量化阶段要用适合业务的Embedding模型，向量库需要支持元数据过滤。检索阶段除了普通向量相似度检索，还要考虑BM25关键词检索、混合检索和Rerank模型精排，我常用的配置是“BM25+向量双路召回，再交给Rerank模型精排”。生成阶段要把检索到的内容以清晰的分隔符拼进Prompt，同时明确要求“回答优先基于给定材料，材料不足就承认”。
面试官通常会追问“为什么直接向量检索效果不行”。核心原因是语义相似度和事实相关性不是一回事。“猫的尾巴有什么作用”和“狗的尾巴有什么作用”语义相似度很高，但前者不能回答后者的问题。混合检索加Rerank就是为了缓解这类语义陷阱。能把这层讲清楚，说明你不只是看过一篇RAG入门文章。
5.2 知识边界与数据新鲜度问题
模型的知识有截止日期，微调并不能每次遇到新知识就更新一遍。RAG最大的价值是以相对较低的成本，让模型掌握最新、最具体、最私域的内容。内部知识一旦固化在参数里，更新反而非常麻烦，所以行业里才说“模型不是数据库”。
面试时如果被问到“构建一个基于公司内部文件的问答系统，应该用RAG还是微调”，标准思考框架是这样的：
- 需要引用来源、信息实时变化、数据量大但不需要改变模型行为，优先RAG；
- 需要改变输出风格、遵守特定格式规范、掌握特定领域的推理习惯，比如把客服话术从三段式改成简洁式，优先微调；
- 更优做法往往是两者结合：用RAG解决知识检索，用少量微调调整表达方式和交互风格。
5.3 一个经常被忽略的坑
我在真实项目里发现，很多RAG链路从头到尾没有评估环节，上线效果完全靠感觉。面试里如果能主动提到“RAG效果怎么评估”，是非常高级的加分项。至少要说明：检索质量用命中率和MRR来衡量，生成结果要做事实忠实度检查。实操上，光调Chunk大小就能拉开好几个点的效果差距，这个细节一旦说出来，面试官就知道你真跑过数据。
6. 幻觉与不确定性表达
6.1 为什么幻觉必然存在
核心原因是：模型学的是参数化的“文本概率分布”，不是经过验证的事实数据库。它的内部知识是模糊统计模式，不存在真正去数据库查证这一步。加上训练目标是预测下一个Token，模型天然倾向于生成通顺的内容，而通顺不等同于真实。所以面试回答里有一句话非常吃香：“大模型没有‘真相’按钮”。
再往深说，幻觉的产生和数据质量、模型容量、解码策略、提示词引导都有关系。数据里本身有错误信息，模型就容易记住错误规律；模型容量有限，为了把庞大数据压进去只能做近似，必然产生混淆；采样温度过高，随机性变大；Prompt约束不足，模型没有边界感。回答时分清这几个层次，比单纯说“因为它是概率模型”要丰满得多。
6.2 工程侧减少幻觉的手段
这个问题最好由浅入深层层递进。Prompt侧：明确约束答案范围，让模型只基于给定材料回答，禁止做外部知识推理。检索增强：强事实型问题先召回再回答，把正确答案直接塞进上下文，减少模型自由发挥空间。解码侧：降低Temperature，改成更确定性的采样策略，同时增加重复惩罚。模型侧：微调时混入大量“我不知道”类型的样本，让模型学会诚实放弃。系统侧：增加后置校验，比如用另一个模型对回答做真实性评分、引用溯源或关键词匹配。
面试必问的口头禅“如果模型不知道答案怎么办”，其实是一个产品设计问题。答“让它说不知道”只能算及格，能说清楚“不知道之后触发搜索、转人工、给兜底话术”才能拿高分。
6.3 让模型“承认不知道”的实操
我在实际产品里的做法是，System Prompt里明确写“你若没有把握，必须在回答末尾用<UNKNOWN>标签标记”，后处理流程检测到这个标签就自动转去RAG或人工。后来换了方案，让模型输出一个置信度分数加简短理由。分数和真实正确率虽然不完美对齐，但至少能画一条阈值曲线来做筛选。这个做法比单纯让模型说“不知道”可落地得多，面试时讲出来会让考官眼前一亮。
7. LoRA与参数高效微调
7.1 为什么全量微调不是首选
微调一个70B甚至更大模型的开销，不是小团队能轻易承受的。全参数更新时，优化器状态、梯度、中间激活都会占用大量显存，训练一次几十万的账单都算正常。更麻烦的是，部署不同模型变体需要保留整套完整权重，存储成本直接翻好几倍。
LoRA这类参数高效微调方法，冻结原模型参数，只训练注入的低秩矩阵，训练显存占用大幅下降，产出的是一个小残差文件，部署时可以合并回原权重，也可以单独加载。面试里能一句话说清低秩分解：权重更新ΔW理论上可能是满秩的，但实际有效变化往往分布在低维子空间，所以用两个小矩阵A和B相乘来近似ΔW。秩r代表我们允许用多少自由度去表达更新，r设大了效果好但训得慢，r设小了省资源但可能欠拟合。
7.2 LoRA的工程细节
实操中要回答清楚作用目标、缩放公式和秩选择。通常加到注意力层的Q/K/V/O投影矩阵上，也可以往FFN部分加，取决于想让模型学会什么。输出侧的缩放公式大致是output = origin + alpha / r * BA * input，alpha是缩放系数，r是秩。秩的选择一般从8到64之间尝试，我自己的经验是序列到序列或代码任务用小秩就够用，对话风格类任务可以稍微大一点。
面试如果继续追问“为什么微调会影响模型能力”，可以说LoRA不是往参数海洋里塞新知识，而是在已有表示上做局部“重新路由”，让模型更愿意调用已经具备但平时不优先使用的知识。这个角度说明你真的用过，而不是只在论文里看过。
还有一个非常实用的心得：LoRA微调后模型格式崩掉，很多时候不是秩设错，而是训练数据里的对话格式和推理时不一致。指令微调的数据一定要保持System、User、Assistant的角色标签结构与最终使用场景完全一致，这一点很多入门教程都不提，面试里主动说出来很有价值。
7.3 训练和评估坑点
LoRA训练中常见的学习率选择是标准Adam时的1e-4到2e-4左右，比全量微调大一点没关系，因为更新范围极其有限。数据量方面，几百上千条高质量样本往往就能看到明显效果，加更多噪声数据反而会拖垮效果。评估时要做泛化测试，不只是训练集上的指标，因为LoRA非常容易过拟合到训练数据的格式和词面风格，一旦过拟合，真实场景的表现会明显下降。
8. LLM Agent与多步骤任务规划
8.1 纯对话模型到Agent的质变
现在面试越来越爱问Agent，核心点在于让模型“调用工具、读取结果、再决策”的循环。单轮对话只需要生成文本，Agent则需要模型具备Function Calling能力，输出结构化意图，比如JSON格式的“tool: search, params: {...}”；需要把工具执行结果再次喂回模型；需要在多轮循环中保持上下文和状态，记录已完成步骤；还要判断继续还是终止，不能无限循环。
口语化理解是：模型不再是“一张嘴”，而是“一个带手带脚的大脑”。面试时先用这个类比开个场，再展开工程细节，会让回答更生动。
8.2 规划、记忆、行动三大件
我通常把Agent拆成规划、记忆、行动三块。规划：把目标拆成子任务，可能借助ReAct这样的模式，让模型交替进行推理和行动。记忆：短期记忆在上下文窗口里，长期记忆进向量库或配置文件，逻辑和前面讲的RAG完全相通。行动：通过函数调用或代码解释器执行，行动结果要能被验证，能进入下一轮推理。
面试官更进一步会问：“你的Agent卡在错误行为里怎么办？”这其实对应了当前行业里“自主容错控制”这个热点。回答思路是：设置最大迭代数和超时阈值，防止死循环；对工具输入输出做Schema校验，错误立即截断；引入“观察—反思”机制，每次行动后让模型总结当前进度，发现偏离就回退；完不成的任务要有明确降级策略，回退到人工处理。能说出这四条，基本就是高级以上水平。
8.3 怎么回答才能体现高级水平
刚入行的候选人喜欢背“ReAct就是Reasoning加Acting”，但要拿到更高评价，主动提到这四个词就对了：可靠性、可观测性、评估闭环、成本控制。
可靠性要求每一步工具的返回都有校验，Agent不是越复杂越好。可观测性要求所有行动都有日志、Trace和成本统计，否则生产环境根本没法维护。评估闭环要给Agent建一个任务级评测集，把多步成功率作为指标，而不是只看单轮回答准不准。成本控制更现实，一次任务可能发起十几次模型调用，Token消耗非常恐怖，一定要做缓存、重试和截断。这些点每一条都是我在真实系统里踩坑踩出来的，比单纯复述论文摘要更能说服面试官。
8.4 不同岗位侧重点不同
由于我的团队既有算法岗又有应用工程岗，面试侧重点有明显差别。算法岗多谈模型本身的Function Calling原理、训练数据怎么构造，以及工具调用能力不足时怎么办；应用工程岗多谈RAG、工具调用框架、容错机制和评测体系。面试官最怕的是候选人对于Agent只停留在“让它自己规划任务”的浪漫幻想里，一聊到错误处理、成本、评估就语塞。这部分在高级和资深岗位面试里几乎必然出现，提前准备好会有非常大的优势。
我个人准备面试时有一个很笨但很有效的方法：把每个问题用自己的话讲给一个不懂技术的人听一遍。能讲明白，才是真明白。上面这8个问题，说是“答不上来直接淘汰”也不夸张，因为它们恰好把基础知识、工程落地、系统设计三个层次都覆盖了。如果你能完整讲透，已经能超过绝大多数候选人。最后再分享一个面试细节：回答时不要一上来就背定义，先花十秒说清楚“这个问题放在实际场景里解决的是什么”，面试官通常更愿意听你从需求倒推到原理，而不是听完一个背熟的答案。祝准备顺利。
