带过一大批做 LLM 相关岗位的候选人之后我越来越确认一个判断面试里最致命的通常不是算法细节答不上来而是对 LLM 的工作方式有一种“理所当然”的错误预设。这 8 个问题看似基础却在技术面试里扮演着分水岭角色答不上来后面聊到多深的架构方案都容易崩。这篇文章适合正准备 LLM 应用开发、强化学习、推理优化、Agent 工程岗位面试的人也适合团队里负责技术招聘的同学用来校准自己的考核维度。我不会只列“标准答案”每个问题都会拆清楚面试官到底在考察什么、最常见的错误回答长什么样、以及怎样组织回答才能证明你不是背过面经。1. 这 8 个问题的筛选逻辑先搞清楚我在面试里想看到什么把问题抛给候选人之前我先说一句我的真实感受。很多刷了大量论文的人会把 LLM 面试理解成“知识量竞赛”谁背的注意力公式多、谁读的论文新谁就赢。但从一个需要实际交付结果的团队视角看我更在意的是候选人有没有建立起一套稳定的心智模型——就是当他面对一个没见过的模型行为时能不能从第一性原理出发推理出可能的原因和可行的实验路径。所以这 8 个问题都围绕同一个底层能力设计能不能把论文里的 explainability 和实际系统里的 failure mode 联系起来。举个例子我问 tokenization 不是为了考“BPE 是什么”而是想确认候选人遇到生僻词、乱码、越权提示词注入时能不能立刻意识到问题可能出在 token 层面。我问上下文长度也不是让候选人报“Llama 上下文是 128k”这种参数而是想知道他有没有亲手处理过“信息明明在上下文里模型却无视它”的现象。我对不同级别候选人的预期也不同。初中级候选人能把概念讲清楚、能说出常见踩坑点就算合格高级候选人必须能从模型的训练目标、数据分布、推理时资源约束这几个维度展开权衡带团队的人则需要给出可执行的验证方案而不是只描述现象。下面这 8 个问题每一个都是先听后辨候选人回答时暴露出来的思维方式往往比答案本身更能决定去留。2. 临界问题一Token 不是单词也不会像人一样“看”文本——Tokenizer 的底层陷阱2.1 面试里最常见的回答误区我几乎每周都会听到这样的开场白“LLM 会先把一句话切成单词然后做 embedding”。这个回答前半部分就有问题绝大多数现代 LLM 用的根本不是按单词切而是按 subword 切也就是把一个词拆成若干个 token 片段。更关键的是很多人把 tokenizer 理解成“字典查询”好像切完 token 之后模型就自然“读懂”了每个词。实际上 tokenizer 只是把文本映射成离散 id 序列模型看到的是一串没有语义的整数语义完全靠后续的 embedding 和注意力机制慢慢学习。真到了现场我一般会追问一个具体场景为什么中文 LLM 处理英文人名时会突然变慢原因是中英文混合文本经过某些中英混合 tokenizer 时英文人名会被切成一长串字符级 token序列长度瞬间膨胀推理速度和成本都会翻倍。这个问题看起来很小但在真实 RAG 管道里很多用户提问一旦含有大量专有名词请求就莫名超时你查遍下游服务都找不到原因最后发现是 tokenizer 把序列拉长了。2.2 候选人如果答得好应该触及哪三条主线第一要说出 tokenizer 有三种主流方案基于字符、基于单词、基于子词BPE、WordPiece、Unigram。现代模型几乎都选子词因为它能在固定词表大小下覆盖开放词汇同时避免单词级词表过大导致的 embedding 矩阵爆炸。Tokenizer 类型典型问题为什么现代 LLM 基本不用字符级序列太长信息密度低训练和推理成本极高单词级词表爆炸无法处理 OOV专有名词、新词会全部变成 unknown子词级需要设计合并规则平衡词汇覆盖和序列长度第二要提到 byte-level 和 Unicode 规范化的意义。很多新模型用 byte-level BPE把文本先转成 UTF-8 字节流再切分这样可以处理任意语言的原始字节避免未登录词。候选人如果能解释清楚“为什么同一个中文汉字在不同模型里的 token 数不同”说明他真的观察过。第三要能结合应用层谈影响。例如做敏感词过滤时按字符匹配没问题但做模型输入截断时若直接按字符数截断极有可能截出来半个 token系统提示词长度也别按“字数”估算而应直接调用 tokenizer 的计数接口。能说出这些细节证明候选人不是只在论文里见过 tokenizer。提示回答时即使记不住 BPE 的完整合并公式也要先讲出“频繁共现的子词片段会被合并成新 token”这一直觉然后把话题引向自己实际处理过的案例。面试官通常更愿意顺着案例追问而不是继续为难你背公式。3. 临界问题二上下文不等于记忆更不等于能力——长文本里的“大海捞针”困境3.1 为什么模型有 128k 上下文却记不住 128k 里的内容这个问题我会从一句面试回答讲起。有人被问“上下文长度变长模型的记忆力会变好吗”时直接回答“会因为能放进去的内容更多了”。这句话只答对了一半而且容易暴露出没看过实测数据。今天很多长上下文模型训练时已经能处理 128k 甚至更长的序列但是在 128k 长文档里做信息定位时准确率往往随着文本长度上升而显著下降尤其是需要引用文档中部信息时。业内通常把这个问题称作“lost in the middle”。原因是注意力分布会被靠近开头和结尾的内容吸引模型对中间段落关注度偏低。这个现象背后是训练数据分布和位置编码相互作用的产物模型不一定真的“忘记”了中间内容而是在生成时没有分配足够的注意力权重给它们。候选人如果能提到这一点我会立刻觉得他在真实场景里做过长文本实验。3.2 一个合格的面试回答应该怎么组织我建议候选人把答案拆成三个层次现象层、机制层、工程层。现象层先承认事实上下文长度是一个有效容量不等于全部内容都会被同等利用拿长文档做问答中段召回的失败率明显高于首尾。机制层可以说一说位置编码的相对位置、注意力窗口、以及训练时长文本样本比例偏差这几条只要讲出逻辑关系就够。工程层则要落到实际手段上做长文本应用时不能无脑把整份文档塞进 prompt而是先用摘要或检索定位到相关段落再截取局部上下文输入模型。这里有个容易加分的操作细节在做“大海捞针”测试时并不是把一句话随机插到长文本任意位置就能测出来还要控制系统提示词、查询目标和插入风格的干扰如果候选人不光知道这个测试还能解释测试失真场景那他大概率真的调过模型。贴近真实生产的做法是对自己的业务文档分布做抽样压力测试而不是只跑公开的合成数据。3.3 面试官接下来会怎么追问如果前面的回答到位我通常会追问“你上一个项目的上下文窗口用到多少有没有因为窗口变大而放松 prompt 结构设计”这是一个典型的陷阱窗口变大不代表可以把整本手册倒进去。稳健的做法依然是控制关键指令在上下文头部、把需要模型推理的参考材料放到尾部附近、需要精确引用的信息尽量让检索模块先定位好。这些操作背后其实都是对注意力分布的尊重。4. 临界问题三RAG 和微调不是替代关系——更多时候是嵌套关系4.1 大多数人的错误是把两者放到对立面技术面试里我经常抛出这样一组问题要让模型回答企业内部私有文档里的问题你会选 RAG 还是微调很多候选人不假思索“选 RAG因为私有数据不适合微调会遗忘通用能力”。这个答案对了一部分但把问题简化成了二选一。真实项目里RAG 和微调解决的是两个不同维度的缺失RAG 解决的是“模型不知道这一段具体信息”微调解决的是“模型不知道应该以什么格式、什么语气、什么决策规则来回应”。举个实际例子你想让模型做客服它需要知道产品保修政策这是信息层面可以走 RAG但你还想让它遇到投诉时先安抚情绪、再给解决方案、最后上报高风险工单这是行为风格和任务结构层面RAG 很难稳定约束微调或提示词工程反而更直接。做 2B 或 7B 的小模型部署时你甚至可以考虑把高频固定知识微调进权重把低频变化知识放到向量库里检索让两套方案配合起来。4.2 RAG 更合适的判断标准我把适合上 RAG 的场景归纳成三条知识更新频繁今天上线明天就改微调跟不上的节奏。用户提问依赖具体上下文比如某个项目目录、某张报表、某个工单详情。模型需要给出可追溯来源RAG 可以把原文片段返回给用户做引用。反过来说有些场景用 RAG 很可能失败知识是高度规则化的比如审批流程、合规判断这种通过微调把决策边界焊进权重里更可靠或者你的检索质量本来就差chunk 切得一塌糊涂召回前十名里没有一个真正有用那 RAG 不仅不能缓解幻觉还会放大幻觉。4.3 考察的核心其实是“检索质量意识”我筛选候选人的关键点在于他会不会主动追问“我的检索效果怎么评估”。很多简历写着“搭建了 RAG 系统”问到召回策略、重排策略、chunk 大小如何选择时却支支吾吾。一个让我加分很多的回答是这样的先用人工标注一批 query-document 对分别评估检索阶段的 recallk 和生成阶段的答案正确率然后单独做消融确认错误到底是检索没找到还是模型没用上。所以如果你准备面试不要只会说“我用 faiss 建了向量库”。你要能讲清楚为什么选择某一个 embedding 模型、为什么按固定长度而不是语义边界切分、有没有做 query 改写、有没有混合关键词检索。能把 RAG 链路拆成“召回-排序-融合-生成”四段的人比只会贴架构图的人明显高一档。5. 临界问题四幻觉不是开关而是一个概率分布——复现和压制缺一不可5.1 说“用 prompt 让模型不要乱编”为什么是无效回答面试现场最让我皱眉的一句话是“我们加了提示词请基于给定的资料回答不要编造。”这不是不能用而是没有理解幻觉的产生机制。幻觉不只是模型“态度”问题更是解码时概率分布的固有性质。在缺少可靠证据、或者证据模棱两可时模型本来就会填充一个概率最大的文本片段这时候靠提示词改变不了分布只能改变表面措辞。我建议候选人把幻觉分成三类来谈事实性幻觉模型编造了不存在的事件或数字忠实性幻觉资料里明明没有模型自作主张补充逻辑性幻觉生成内容前后矛盾或推导不成立。不同类别的压制手段不同事实性幻觉多靠检索和知识库约束忠实性幻觉多靠 carefully crafted prompt 和输出结构限制逻辑性幻觉则可能要靠更强的基础模型或推理时方法。5.2 合格的工程方案会包含“检测—归因—熔断”真正在生产环境压幻觉单靠提示词远远不够需要一套闭环。候选人如果能说出下面这几种机制我就知道他有实战经验对生成的每个关键断言做归因查看它是否对应检索到的原文片段。用一个小模型或分类器判断当前回答是否存在证据不足。设定置信度阈值低置信度时让系统回答“依据不足”而不是硬编。对高风险领域比如医疗、金融强制输出引用编号没有引用就不给最终答案。5.3 怎么回答才算打到点子上我期待听到的回答结构是承认幻觉不可能被彻底根除然后马上给出“在什么样的边界内可以让它低到可接受”紧接着给出量化方式比如在 500 条测试集上把幻觉率从 12% 压到 3%并说明评测是人工判定的还是模型判定的。这是一个非常好的加分点因为把幻觉问题当成系统工程来处理而非停留在“模型会瞎说”的层面正是很多团队招聘时的硬性期望。面试时我还会追加一个问题“如果用户直接问模型不知道的私人信息你怎么做”参考思路不是让模型承认无知而是先判断问题类型再用检索、工具、或拒答策略分流。能主动设计这条路线的候选人通常已经具备独立搭建客服或问答系统的能力。6. 临界问题五评估 LLM 不是做一个 golden set 就结束——你必须能解释分数的波动6.1 为什么“准确率 90%”这个数字没有参考价值我问候选人“你怎么评估你的 LLM 应用效果”时最常见的回答是“标注了几百条数据准确率 90%。”如果我继续追问“这 90% 是怎么算的正负样本比例多少多人标注的一致性多少模型判分还是人工判分”很多人就开始含糊了。LLM 应用评估最大的难点不是搭建评测集而是你很难定义“标准答案”本身。开放生成任务里一句话可以有很多种正确表达把所有表达都枚举出来根本不现实。这道题我想看到的是评估分层意识。第一层是模型层评估拿公开 benchmark 衡量基础模型能力第二层是应用层评估针对你自己的任务定义指标第三层是在线评估看真实用户反馈、会话轮次、最终转化或工单解决率。不同层的指标不能互相替代比如模型在 MMLU 上分数高不代表你的客服机器人能解决用户投诉。6.2 推荐候选人掌握一套可落地的评测方案我会在面试反馈表里给“评估设计”这一项打高分的候选人通常都会谈到以下几点标注集规模不需要贪大但要分层抽样覆盖正常场景、边界场景和恶意输入。必须做标注一致性校验至少两个人标注后计算 Cohen‘s Kappa 或简单的一致率。生成结果要用多个维度评分相关性、忠实性、完整性、格式合规合成一个总分反而掩盖问题。使用 LLM-as-a-judge 时要注意偏好偏差同层级模型当评委往往偏向自己的风格。有一个细节非常体现功力评判模型和小模型之间的分歧往往是最值得抽出来人工复审的数据。如果候选人能说出“我们每周会针对 judge 分歧做一次错误分析再更新 prompt”说明他是真的把评估当成闭环驱动手段而不是完成交付后补个指标。6.3 别只谈准确率最好谈离线到在线的回归我最终的判断依据不仅看他如何做离线评测还看他是否理解线上指标和离线指标之间的漂移。很多团队辛辛苦苦把离线准确率做到 95%一上线就被真实 prompt 打穿因为线上输入的分布远比人工构造的测试集复杂。优秀的回答会提到小流量灰度、用户反馈回流、badcase 自动采集再持续回归到离线评测集里。当候选人能把“离线评测、线上观测、badcase 回流”串成一条闭环我基本可以确定他能独当一面。7. 临界问题六LLM 应用的稳定性不只是“不报错”——你要能管控 Agent 的状态与失控7.1 为什么 Agent 类项目会在面试里被单独拎出来问这两年 LLM 面试的热度明显从单轮问答转向 Agent 工程。过去大家关注的是 prompt 写得好不好现在关注的是一个能调用工具、多轮迭代、记忆上下文的 Agent为什么会陷入死循环为什么会重复调用某接口为什么一个简单任务走到了完全无关的路径上这些问题背后其实是统一的状态管理问题——模型每一步生成的结果都作为下一轮的输入一旦中间某一步产生偏差后续所有步骤都会被放大。候选人回答这个问题时如果只说“我们用了 ReAct 框架”我会认为他停留在概念层。真正做过 Agent 项目的人应该知道Agent 系统至少有四个关键控制点任务规划层大模型决策下一步做什么、工具调用层参数是否符合工具 schema、记忆管理层哪些历史信息该保留、终止条件层什么时候停止迭代。每一层都可能出问题面试官想看到的是你如何对每一层做约束。7.2 我期待听到的具体工程手段在这个问题上候选人如果能提到下面这些词我会特别关注上下文相关细节工具调用做 schema 校验模型输出必须经过结构化解析失败就重新提示模型而不是直接透传给后端服务。循环检测记录工具调用序列如果模型重复执行同一操作超过 N 次强制切换策略或终止。外部状态尽量收敛到有限状态机不要让模型完全自由决策模型只负责语义理解和局部决策整体流程交给固定编排。关键动作加人工确认高影响操作不能无条件执行。7.3 从稳定性延伸到“防火墙”意识这一题还有一个考察暗线对 LLM 安全边界是否敏感。比如用户诱导 Agent 输出系统内部 prompt、或者通过工具接口注入恶意指令这类攻击在真实环境里非常常见。候选人不需要能给出全套安全架构但至少要意识到 LLM 应用不能裸奔输入侧要过滤输出侧要脱敏工具调用权限要最小化。如果候选人还能结合自己做过的 AI 应用聊到数据隐私、权限收敛、操作审计那这个面试表现就可以进入下一轮了。8. 临界问题七成本和延迟的背后不只是“换小模型”——你要有全链路预算意识8.1 只回答“换小模型”是最典型的落选答案当被问到“线上 LLM 服务延迟太高、成本太贵你怎么办”时很多候选人脱口而出“换更小的模型”。这个方向不算错但它没有体现出工程权衡。真实系统的成本来自四个方面模型推理、检索链路、外部工具调用、以及因为重试和错误分支造成的额外开销。只优化模型大小往往只解决其中一个环节。我见过一个场景业务方要求延迟低于 800ms团队一开始把模型从 70B 换成 7B确实省了钱但准确率下降后用户问题经常要二次追问整体交互轮次变多最终用户体验反而更差。反而是在 prompt 和检索上优化让 70B 模型少看无用内容延迟和成本同时降下来。所以面试回答的起点应该是“先量化瓶颈在哪里”而不是盲目换件。8.2 合格回答里应该出现的关键手段以下手段不用全说但至少要有两三个并能讲清楚为什么适用Prompt 压缩把历史对话做摘要把长文档做关键信息抽取控制输入 token 数。语义缓存命中缓存直接返回结果这是成本优化里见效最快的一条路。模型路由简单问题走小模型复杂问题走大模型本质上是把计算资源分配给最难的任务。批处理与投机采样离线任务用 batch 接口在线任务用 speculative decoding 来降低延迟。上下文窗口分级没必要一上来就开 128k很多场景 8k 足够省下的 KV cache 内存非常可观。如果候选人能进一步解释 KV cache 对成本的影响我会非常满意。长上下文推理之所以贵很大程度是每多加一个 token 都要保存对应的 K 和 V内存占用不是线性增长而是和序列长度直接挂钩。能在回答里自发提到这一点的人说明他真正算过线上服务的资源账单。8.3 回答这道题时别掉进“纯优化陷阱”另一个常见问题是候选人把所有优化方案都抛出来却不说取舍。比如既要低延迟又要高准确率既要本地部署又要支持超长上下文这在工程上往往不可兼得。我欣赏的回答是先问清楚约束条件这个场景是同步还是异步准确率要求多高预算上限是多少然后根据约束选择方案。面试官考验的其实是决策能力而不是信息量。9. 临界问题八把 LLM 放进生产环境之前你必须先明确三件非做不可的事9.1 第一件事输入输出边界要变成强制约束而不是靠自觉最后一个问题我几乎必问“如果明天要把你这个 LLM 应用上线你最先补齐的三件事是什么”这个问题开放性很强适合判断候选人有没有真正上线过系统。我听到过很多泛泛而谈的答案比如“优化 prompt”“多做测试”。但我要的是边界意识。第一件应该做的事情是把输入输出的格式和约束固定下来。LLM 生成结果必须经过结构化解析模型输出 JSON 时要先做语法校验失败时要有重试或修复机制不能把一个解析不了的字符串直接丢给前端。同样用户输入不能无限长该截断要截断该提示要提示。许多线上崩溃其实跟模型无关只是程序没有处理好模型偶尔输出 format error 的情况。9.2 第二件事可观测性不是加日志而是能定位到“是哪一轮、哪个环节”出了问题上线前要有完整的链路追踪从用户原始输入开始记录 prompt 拼接后的样子、检索到的文档片段、模型返回的原始输出、后处理解析的结果。每个环节都打上 trace_id才能保证出问题时你可以快速复现。很多团队说“我们加了日志”但日志只记录了模型的最终输出prompt 模板一旦变动线上表现就无从比较这会让问题排查变成猜谜游戏。候选人如果主动谈到 prompt 版本管理我会格外加分。prompt 在线上是会迭代的应该当成代码来管理每次修改有 diff有生效时间有对应的离线评测结果。没有这套机制你根本无法判断线上指标波动是模型升级引起的还是 prompt 改动引起的更别提回滚了。9.3 第三件事自动回退与降级策略要提前设计而不是等故障发生LLM 服务再稳定也会出现模型供应商限流、网络抖动、返回超时甚至某一类请求触发内容安全拦截。生产系统必须预设降级路径正常情况下直接调用大模型被限流后切换备用的同能力服务仍然失败则降级到规则引擎或人工客服。这个降级顺序要提前和业务方确认好不能等到线上报警了才拉起一个电话会议。我遇到过比较优秀的候选人会继续补一句“降级后还要记录降级率如果一天内降级比例超过某个阈值要触发自动告警而不是默默牺牲回答质量。”这样的回答表明他把 LLM 当作一个依赖外部条件的组件而不是神坛上的万能引擎。9.4 这道题暗含的特质你更看重“功能完成”还是“系统可靠”面试官往往不会等到这个问题才决定结果它更像一个验证性提问。前面几个问题答得再好如果这里谈不出具体的上线清单我会怀疑候选人参与过的项目是否只停留在 demo 阶段。LLM 应用开发和传统后端开发一样都建立在工程纪律之上。能稳定交付的人一定会在第一时间谈边界、追踪、降级这三件事而不是急着介绍模型选型。这道题答得好面试基本可以进入后续薪酬讨论答不出来很可能就被放到 waitlist 甚至直接淘汰。10. 从面试官视角补充的淘汰红线与追问技巧10.1 哪些回答会让我直接给出否定评价回答内容的丰富度很重要但有些红线一旦触及基本很难翻盘。第一类红线上文提过二选一思维把 RAG 与微调、效果与成本、小模型与大模型对立起来。真实系统里所有方案都是组合拳只会做单选题的人很难应对生产环境的多因素权衡。第二类红线是只背结论不背推导。比如能说出“长上下文有 lost in the middle”但追问“你怎么验证这句话在你的业务场景里成不成立”时回答变成沉默。这不是知识量问题而是缺乏实验精神。面试官不想招一个只能复读论文结论的人想招的是一个能自行设计验证流程、在数据面前修正判断的人。第三类红线是忽略失败场景。整场面试只讲顺利的路径从不提系统崩溃、数据污染、prompt 被攻击、模型随机性导致的结果抖动。一个没经历过失败的候选人上线后大概率会被真实流量教育。10.2 候选人反过来判断面试官水平的两个问题面试是双向选择我也建议候选人反问时观察对方水平。你可以问“你们当前生产环境里离线评测和线上反馈的一致性大概是多少”如果面试官能给你具体数字和案例说明团队真的有评测闭环如果只会说“我们效果很好”你要多留个心眼。另一个问题是“你怎么治理长尾 badcase是靠定期人工 review 还是系统自动聚类”这个问题能反映团队对 LLM 应用工程质量的态度。10.3 我个人在反复面试后的一点体会从面试官的角度我发现能把以上 8 个问题串成一条逻辑线的人通常具备一种共性能力他们不把 LLM 当成神秘的智能体而是当成一个有概率行为的软件组件。凡是有了这种认识的人后续磨合成本极低分配复杂任务时也更放心。反过来知识面很宽但逻辑线混乱的候选人即使手握多篇论文真正落地时也容易处处踩雷。比起多背一个面试题我更建议准备者把精力放在补全自己的“决策链路”上遇到一个模型问题你怎么判断它的影响范围、怎么设计实验、怎么选择止损手段、怎么通过数据验证判断。这套链路一旦建立你不仅能应对这 8 个问题还能在真正进入团队后省下大量试错时间。对于已经在做 LLM 应用的人也可以拿这套链路去检查手头项目相信我你大概率会发现自己还有至少两三个环节是裸奔的。