带过一大批做 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 矩阵爆炸。

第二，要提到 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 对，分别评估检索阶段的 recall@k 和生成阶段的答案正确率，然后单独做消融，确认错误到底是检索没找到还是模型没用上。

所以如果你准备面试，不要只会说“我用 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 应用的人，也可以拿这套链路去检查手头项目，相信我，你大概率会发现自己还有至少两三个环节是裸奔的。