1. 为什么这8个问题成了LLM岗位的硬门槛
面过LLM岗位的人大概都有这种体验：简历上写着“熟悉Transformer”“做过RAG项目”“微调过开源模型”，结果面试官第一个问题就把人问住了。不是问得多偏，而是问得太基础——基础到很多人以为自己会，实际上答不完整。
我参与过不少轮大模型方向的技术面试，也帮朋友做过模拟面。一个很明显的规律是：能把这8个问题答利索的人，不一定做过最炫的项目；但答不上来的人，基本在初筛阶段就被划掉了。原因很简单，LLM岗位现在不缺“调包侠”，缺的是真正理解模型内部在发生什么、知道工程边界在哪的人。面试官问这些问题，不是考记忆力，是在判断你有没有能力在模型出问题时定位到根因。
这8个问题大致覆盖了这几个方向：Transformer架构的核心机制、Tokenization的实际影响、注意力计算的复杂度、位置编码的演进、Function Calling的工程实现、模型幻觉的成因与缓解、上下文窗口的管理策略、以及微调与提示工程的取舍。每一个都不是孤立的知识点，而是串起来构成了一条“从输入文本到模型输出”的完整链路。你答得上一个，说明你懂一个环节；你能把几个串起来讲清楚，面试官才会认为你真的做过端到端的事情。
这篇文章我打算按面试的真实节奏来写，不是教科书式的知识点罗列，而是把每个问题拆成“面试官到底想听什么”“标准答案的骨架是什么”“哪些细节能加分”“哪些回答会直接减分”四个层面。中间会穿插我自己踩过的坑和带人时发现的常见误区。适合正在准备LLM岗位面试的人，也适合已经入行但想系统梳理一遍底层逻辑的工程师。
2. Transformer架构：面试官真正想确认的三件事
2.1 自注意力到底在算什么，别只背公式
几乎每场LLM面试都会从Transformer切入，但面试官问法差别很大。初级岗位可能直接问“Self-Attention的公式是什么”，高级岗位则会问“为什么Self-Attention比RNN更适合长序列建模”。这两种问法背后考察的深度完全不同。
先说公式层面。Self-Attention的核心计算是：
Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V这个公式很多人能默写，但面试官真正想确认的是你理解每一步在干什么。Q和K的点积是在计算“当前token和其他token的相关性分数”，除以sqrt(d_k)是为了防止点积结果过大导致softmax梯度消失，softmax把分数归一化成权重，最后用这些权重对V做加权求和。关键点在于：这个过程是并行的，每个token的位置输出可以同时计算，不依赖前一个时间步的结果。这正是Transformer比RNN快的原因，也是它能扩展到超长序列的基础。
面试官如果追问“为什么要除以sqrt(d_k)”，你要能说出：假设Q和K的每个分量都是独立同分布、均值0方差1的随机变量，那么它们的点积的方差就是d_k。当d_k很大时，点积的数值范围会很大，softmax的输出会趋近于one-hot，梯度会变得极小。除以sqrt(d_k)就是把方差拉回到1附近，保持梯度的稳定性。这个解释比单纯说“防止梯度消失”要具体得多，面试官一听就知道你是真理解而不是背的。
2.2 多头注意力不是简单的并行，而是子空间投影
Multi-Head Attention经常被误解成“把Self-Attention跑几遍然后拼起来”。这个理解不算错，但太浅了。面试官想听的是：多头机制让模型在不同的表示子空间里学习不同的注意力模式。
具体来说，假设模型维度是512，头数是8，那么每个头的维度就是64。输入经过线性变换后，被拆成8组Q、K、V，每组独立做注意力计算，最后把8个头的输出拼接起来再过一层线性变换。这样做的好处是：一个头可能关注语法依赖关系，另一个头可能关注语义相似度，还有一个头可能关注位置邻近性。如果只有一个头，这些模式会混在一起，模型很难同时学好。
我在实际调试模型时发现一个有意思的现象：某些头在训练后会变得“几乎不活跃”，注意力权重接近均匀分布。这说明模型自己学会了某些头不需要特别关注特定模式。面试时如果你能提到这一点，说明你不仅看过论文，还实际观察过模型行为，这是很强的加分项。
2.3 残差连接和LayerNorm的位置选择有讲究
Transformer的每个子层后面都有残差连接和LayerNorm，但这两者的顺序在不同变体里是不一样的。原始论文用的是Post-LN（先做Attention/FFN，再残差+LayerNorm），后来很多模型改成了Pre-LN（先LayerNorm，再做Attention/FFN，最后残差）。
这个区别在面试中经常被忽略，但它直接影响训练稳定性。Post-LN在深层模型中容易出现梯度消失，需要小心的学习率预热；Pre-LN则更稳定，但表达能力和最终性能可能略有差异。如果你面的是需要手写Transformer的岗位，面试官可能会让你解释为什么现在主流模型大多用Pre-LN或者RMSNorm。RMSNorm是LayerNorm的简化版，去掉了均值中心化，只做方差归一化，计算更快且效果相当。这些细节能答上来，说明你对架构演进有跟踪。
3. Tokenization：被低估的面试重灾区
3.1 BPE、WordPiece和SentencePiece的区别不只是算法
Tokenization看起来是个预处理步骤，但它在面试中的出现频率远超很多人的预期。原因很实际：Tokenization直接决定了模型的输入长度、词表大小、多语言能力和对未登录词的处理方式。面试官问这个问题，是在判断你有没有处理过真实数据。
BPE（Byte Pair Encoding）的核心思想是从字符级别开始，不断合并出现频率最高的相邻字符对，直到达到预设的词表大小。WordPiece和BPE类似，但合并的标准不是频率而是似然增益。SentencePiece则更进一步，它把空格也当作普通字符处理，不依赖预分词，因此对中文、日文等没有明显词边界的语言更友好。
面试中常见的追问是：“为什么GPT系列用BPE而BERT用WordPiece？”这个问题没有标准答案，但你可以从工程角度回答：BPE的实现更简单，合并规则更直观，适合大规模训练；WordPiece在相同词表大小下可能产生更少的token，对英文任务更高效。关键是要说明选择取决于具体场景，而不是哪个绝对更好。
3.2 中文Tokenization的坑比英文多得多
如果你面的是国内团队，中文Tokenization几乎必问。一个典型的坑是：很多开源模型的中文词表覆盖不足，导致一个常用汉字被拆成多个byte token。比如“你好”在某些模型里可能被编码成3到4个token，而英文的“hello”只有1个token。这直接导致中文输入的有效上下文长度缩水，推理成本上升。
我在实际项目中遇到过这种情况：同一个模型，英文输入2000 token能处理的内容，中文输入需要3500 token才能表达同样的信息量。解决办法通常是在微调时扩充中文词表，或者选择原生支持中文的模型。但扩充词表会改变embedding层的维度，需要重新训练或至少做embedding对齐，这是有成本的。面试时如果你能说出这个trade-off，面试官会认为你真正处理过中文场景。
另一个常见问题是特殊token的处理。比如padding token、CLS token、SEP token在不同模型里的定义和使用方式不同。如果你在面试中被问到“如何计算一个batch里不同长度序列的attention mask”，你要能说清楚padding位置的mask要设为负无穷，这样softmax之后权重为0，不会影响有效token的表示。
3.3 词表大小对模型性能的隐性影响
词表大小是一个需要权衡的参数。词表太小，常见词被拆成多个token，序列变长，计算量增加；词表太大，embedding矩阵参数量膨胀，低频词训练不充分，而且softmax层的计算量也会增加。
一般来说，英文模型的词表在3万到5万之间比较常见，多语言模型可能到10万以上。但词表大小不是越大越好，关键要看词频分布和语言覆盖。面试时如果被问到“给你一个垂直领域的数据集，你会怎么设计词表”，你可以从这几个角度回答：先统计领域内的高频词和专有名词，确保它们不被拆碎；保留通用词表的基础部分以维持泛化能力；对领域特有词做增量合并。这个回答既展示了技术理解，也展示了工程思维。
4. 位置编码：从正弦函数到RoPE的演进逻辑
4.1 为什么Self-Attention本身不知道顺序
Transformer的Self-Attention有一个根本性的特点：它对输入序列的顺序是不敏感的。也就是说，如果把“猫追狗”和“狗追猫”的token打乱顺序输入，在没有位置编码的情况下，注意力计算的结果是一样的。这显然不符合语言理解的需求。
位置编码就是用来解决这个问题的。原始Transformer用的是正弦位置编码，通过不同频率的sin和cos函数为每个位置生成一个唯一的向量，然后直接加到token的embedding上。这种编码的好处是不需要训练，可以外推到训练时没见过的长度；缺点是外推能力有限，而且在深层模型中位置信息容易衰减。
面试中如果问“正弦位置编码为什么能表示相对位置”，你要能解释：对于任意固定的偏移量k，位置p+k的编码可以表示为位置p编码的线性变换。这个性质使得模型能够学习到相对位置关系，而不仅仅是绝对位置。但实际中，这种线性关系在训练后是否被模型有效利用，是有争议的。
4.2 可学习位置编码的局限与RoPE的突破
可学习位置编码（如BERT使用的）把每个位置的embedding作为参数训练，优点是灵活，缺点是无法处理超过最大训练长度的序列。如果训练时最大长度是512，推理时来了一个600长度的输入，后面88个位置没有对应的embedding，只能截断或报错。
RoPE（Rotary Position Embedding）是目前主流大模型广泛采用的位置编码方案。它的核心思想不是“加”位置信息，而是通过旋转矩阵把位置信息“乘”进Q和K的表示里。具体来说，对于位置m的query向量和位置n的key向量，它们的点积会自然地包含一个与(m-n)相关的旋转角度。这意味着RoPE天然编码了相对位置信息，而且理论上可以外推到更长的序列。
我在实际使用中发现，RoPE的外推能力也不是无限的。当推理长度远超训练长度时，注意力分数会出现异常，模型输出质量明显下降。常见的缓解方法包括位置插值（把长序列的位置映射回训练时的范围）和NTK-aware缩放。面试时如果能提到这些工程技巧，说明你不只是知道RoPE的概念，还处理过实际的长文本问题。
4.3 ALiBi和其他轻量方案的取舍
ALiBi（Attention with Linear Biases）是另一种位置编码方案，它不修改embedding，而是在注意力分数上直接加一个与距离成正比的偏置项。距离越远，偏置越负，注意力权重越小。这种方案的优点是实现极简，外推能力好；缺点是它假设位置关系是单调递减的，对于某些需要长距离依赖的任务可能不够灵活。
面试中如果被问到“你会选哪种位置编码”，不要直接说“RoPE最好”。更好的回答是：看任务需求。如果是标准的大模型预训练，RoPE是目前的主流选择，生态支持好；如果推理时需要处理超长序列且不想做复杂的缩放，ALiBi可能更省事；如果是特定领域的短序列任务，可学习位置编码也够用。展示出你根据场景做选择的能力，比给出一个绝对答案更重要。
5. Function Calling：从Prompt技巧到工程协议
5.1 Function Calling不是简单的JSON输出
Function Calling是LLM应用开发中的核心能力，也是面试中区分“做过Demo”和“做过产品”的分水岭。很多人以为Function Calling就是让模型输出一段JSON，然后解析出来调用函数。这个理解太表面了。
真正的Function Calling涉及几个层面：模型需要理解用户的自然语言意图，判断是否需要调用工具，选择合适的工具，提取正确的参数，处理参数缺失或格式错误的情况，最后把工具返回的结果整合回自然语言回复。这是一个完整的闭环，任何一个环节出问题都会导致体验崩溃。
面试中常见的问题是：“如果模型输出的JSON格式不对怎么办？”初级回答是“用正则表达式提取”或“重试”。更好的回答是：在prompt中明确约束输出格式，使用JSON Schema做校验，如果校验失败则把错误信息反馈给模型让它重新生成。更工程化的做法是在解码阶段做约束，比如用语法引导的解码（grammar-constrained decoding）强制模型只能输出合法的JSON。这个回答能体现出你对生产环境可靠性的理解。
5.2 工具描述的设计比模型能力更关键
在实际项目中，Function Calling的成功率很大程度上取决于工具描述的质量。我见过太多团队把工具描述写得含糊不清，然后抱怨模型“太笨”。其实问题出在描述上。
一个好的工具描述应该包含：工具的功能一句话概括、每个参数的类型和含义、参数的取值范围或枚举值、什么情况下应该调用这个工具、什么情况下不应该调用。这些信息要写得像给一个新员工看的文档，而不是像给机器看的代码注释。模型对自然语言的理解能力很强，但它不会猜你的意图。
举个例子，如果你有一个查询天气的工具，描述里只写“获取天气信息”，模型可能在你问“今天适合穿什么”的时候不调用它。但如果你写“当用户询问天气、温度、是否下雨、穿衣建议时调用此工具”，模型的调用准确率会明显提升。面试时如果你能举出这种具体的优化案例，比空谈“优化prompt”有说服力得多。
5.3 多工具场景下的选择与编排
当系统里有几十个工具时，Function Calling的难度会指数级上升。模型需要在众多工具中选择正确的那个，还要处理工具之间的依赖关系。比如用户说“帮我订一张明天去北京的机票，然后预约一个接机服务”，这需要先调用航班查询工具，拿到结果后再调用接机预约工具，而且接机时间要依赖航班到达时间。
这种编排逻辑目前主要靠两种方式实现：一种是在prompt里写清楚工具之间的依赖关系和调用顺序；另一种是用外部的编排引擎（如状态机或工作流引擎）来管理。前者灵活但不可靠，后者可靠但需要额外开发。面试时如果被问到“如何保证多步工具调用的正确性”，你可以说：对于关键业务流程，不要完全依赖模型的自主编排，而是用代码定义好状态转移，模型只负责在每一步做局部决策。这个回答体现了你对可靠性的重视。
6. 幻觉问题：面试官想听的不是“用RAG”
6.1 幻觉的根源在训练目标和解码策略
“模型为什么会产生幻觉”是LLM面试的高频问题。很多人第一反应是“因为训练数据不够”或“因为模型不够大”。这些回答不算错，但没有触及本质。
幻觉的根本原因在于：语言模型的训练目标是最大化下一个token的似然概率，而不是保证事实正确性。模型学到的是“什么样的文本看起来合理”，而不是“什么是真的”。当模型遇到训练数据中少见或没有的情况时，它会根据学到的语言模式“编造”一个看起来合理的答案，而不是说“我不知道”。
另一个重要因素是解码策略。贪心解码（每次选概率最高的token）容易陷入重复和保守输出；束搜索（Beam Search）会探索多条路径，但可能选出整体概率高但事实错误的序列；采样（Sampling）增加了多样性，但也增加了随机性带来的错误。温度参数调高，幻觉概率通常上升；调低，输出变得保守但可能更准确。面试时如果你能把这些因素串起来讲，说明你对生成过程有完整的理解。
6.2 RAG不是万能药，检索质量决定上限
RAG（检索增强生成）被很多人当成解决幻觉的银弹。但实际上，RAG的效果高度依赖检索质量。如果检索到的文档不相关或包含错误信息，模型会基于错误信息生成更“自信”的错误答案，这比没有RAG更糟糕。
我在实际项目中的经验是：RAG系统的瓶颈通常在检索环节，而不是生成环节。向量检索的召回率、chunk的切分策略、embedding模型的选择、rerank的引入，每一个环节都会影响最终效果。面试时如果被问到“如何设计一个RAG系统”，不要只讲“把文档切块、向量化、检索、拼接prompt”这个流水线，而要讲清楚每个环节的取舍。比如chunk大小是固定长度还是按语义切分？embedding模型是用通用的还是领域微调的？检索后要不要做rerank？这些细节才是区分经验深浅的地方。
6.3 让模型说“不知道”比让它答对更难
一个反直觉的事实是：训练模型在不确定时输出“我不知道”比训练它答对问题更难。因为训练数据里几乎没有“我不知道”这种表达，模型没有学过在什么情况下应该拒绝回答。
常见的做法包括：在prompt里明确指示“如果信息不足，请回答不知道”；用RLHF训练模型校准置信度；在系统层面加一个置信度阈值，低于阈值时直接返回兜底话术。但这些方法都有局限。prompt指示容易被模型忽略，RLHF需要大量标注数据，置信度阈值很难设定得准确。
面试时如果被问到这个问题，你可以说：完全消除幻觉目前不现实，工程上的目标是“可控”。对于高风险场景，不要让模型直接输出最终答案，而是让模型输出结构化的信息，由外部系统做校验和兜底。这个思路比追求“零幻觉”更务实。
7. 上下文窗口：不是越大越好，而是越有效越好
7.1 长上下文的“迷失中间”现象
现在很多模型宣称支持128K甚至更长的上下文，但实际使用中你会发现，模型对上下文中间部分的信息利用率明显低于开头和结尾。这就是所谓的“Lost in the Middle”现象。
原因和注意力机制的特性有关。在长序列中，注意力权重容易集中在开头（如系统prompt）和结尾（如最近的对话），中间部分的信息被“淹没”。这不是模型容量不够，而是注意力分配的问题。面试时如果被问到“如何处理长文档问答”，你可以说：不要把所有内容一股脑塞进上下文，而是先用检索或摘要的方式筛选出最相关的片段，再送给模型。这比单纯扩大上下文窗口更有效。
7.2 上下文压缩的几种实用策略
在实际工程中，上下文管理是一个持续优化的过程。常见的策略包括：滑动窗口（只保留最近N轮对话）、摘要压缩（把历史对话总结成一段话）、关键信息提取（只保留实体和意图相关的信息）、分层记忆（短期记忆用完整对话，长期记忆用向量检索）。
每种策略都有代价。滑动窗口简单但会丢失早期信息；摘要压缩需要额外的模型调用，增加延迟和成本；关键信息提取需要设计抽取规则，可能漏掉重要细节；分层记忆架构复杂，调试难度高。面试时如果你能说出这些trade-off，并给出一个你实际用过的方案和效果，会非常有说服力。
7.3 位置编码外推与注意力稀疏化的工程取舍
从模型层面看，支持长上下文需要解决两个问题：位置编码的外推和注意力计算的复杂度。RoPE的位置插值和NTK缩放是常见的解决方案，但它们会改变注意力分布，可能影响短序列的性能。注意力稀疏化（如只计算局部窗口或固定模式的注意力）可以降低计算量，但会损失全局信息。
目前没有一个完美的方案，工程上通常是根据业务场景做取舍。如果业务主要是短对话，不需要折腾长上下文；如果是文档分析，可能需要结合检索和分块策略；如果是代码生成，长上下文的收益可能更明显，因为代码的依赖关系跨度大。面试时展示出你根据场景做技术选型的能力，比背诵某个方案的细节更重要。
8. 微调与提示工程：什么时候该动模型，什么时候不该
8.1 提示工程的边界在哪里
提示工程是成本最低的适配方式，但它有明确的边界。当任务需要模型掌握训练数据中不存在的新知识、新格式或新风格时，提示工程的天花板很快就到了。你可以通过few-shot示例让模型学会一个简单的分类任务，但你很难通过提示让模型学会一个它从未见过的专业术语体系。
面试中常见的问题是：“什么时候选择微调而不是提示工程？”一个实用的判断标准是：如果任务可以通过清晰的指令和少量示例描述清楚，优先用提示工程；如果任务需要模型内化大量领域知识、遵循复杂的输出格式、或者对延迟和成本有严格要求（微调后可以用更小的模型），则考虑微调。
8.2 LoRA和全量微调的选型逻辑
LoRA（Low-Rank Adaptation）是目前最流行的参数高效微调方法。它的核心思想是在预训练模型的权重矩阵旁边加一个低秩分解的旁路，只训练这个旁路，冻结原始权重。这样做的好处是显存占用小、训练速度快、可以快速切换不同任务的适配器。
但LoRA不是万能的。如果目标任务和预训练任务差异很大，或者需要模型学习全新的能力，LoRA的低秩假设可能不够用，全量微调或至少更大的秩可能更合适。面试时如果被问到“LoRA的秩怎么选”，你可以说：从8或16开始试，观察验证集效果，如果欠拟合就增大秩，如果过拟合就减小秩或增加dropout。关键是要有实验设计的思路，而不是给一个固定值。
8.3 数据质量比数据数量重要一个数量级
无论是微调还是提示工程，数据质量都是决定效果的核心因素。我见过太多团队花大量时间收集了几万条数据，结果效果还不如精心构造的几百条。低质量数据的典型特征包括：标注不一致、格式混乱、包含错误信息、覆盖不均衡。
一个实用的做法是：先人工构造100到200条高质量样本，用它们做few-shot或微调，观察效果。如果效果不错，再逐步扩充数据；如果效果不好，先检查数据质量而不是盲目增加数量。面试时如果你能分享这种“小步快跑”的数据迭代经验，比空谈“数据很重要”有说服力得多。
9. 面试中的表达策略：知道和讲清楚是两回事
9.1 用“问题-方案-取舍”的结构组织回答
技术面试中，面试官不仅看你知不知道答案，更看你有没有解决问题的思路。一个有效的表达结构是：先确认问题的边界和约束，再给出方案，最后说明取舍和适用场景。
比如被问到“如何优化LLM的推理速度”，不要直接说“用量化”。更好的回答是：先问清楚场景——是延迟敏感还是吞吐敏感？硬件是什么？模型规模多大？然后给出可能的方案：量化（INT8/INT4）、蒸馏（用小模型替代）、KV Cache优化、批处理、投机解码等。最后说明每个方案的代价：量化可能损失精度，蒸馏需要训练，KV Cache增加显存，批处理增加延迟。这种回答展示的是工程判断力，而不是知识点记忆。
9.2 不会的问题怎么处理
面试中遇到不会的问题是正常的，关键是怎么处理。最忌讳的是不懂装懂，编一个听起来合理但错误的答案。面试官通常对这个领域很熟，一眼就能看出来。
更好的做法是：坦诚说这个点我不太确定，但我可以从相关的角度分析一下。然后把你确定知道的部分讲清楚，把不确定的部分标记出来。比如被问到“FlashAttention的具体实现”，如果你没看过论文，可以说：我知道它主要是通过分块计算和重计算来减少显存访问，具体的内核实现我没有深入研究，但我理解它的目标是让注意力计算更适配GPU的存储层次。这种回答既诚实，又展示了你的知识迁移能力。
9.3 用实际案例替代抽象描述
面试中最有说服力的永远是具体案例。与其说“我熟悉RAG”，不如说“我做过一个法律文档问答系统，用了BGE的embedding模型，chunk大小设为512，重叠128，检索后加了cross-encoder做rerank，最终准确率从72%提升到89%”。具体的数字、工具名、参数和效果对比，能让面试官立刻判断出你的经验深度。
我在帮人做模拟面时，经常发现一个现象：很多人明明做过不错的项目，但讲出来平平无奇。问题通常出在只讲了“做了什么”，没讲“为什么这么做”和“遇到了什么问题”。面试官想听的是你的决策过程和踩坑经验，而不是项目说明书。
10. 几个容易被忽略但会直接减分的细节
10.1 混淆概念比不知道更致命
面试中有些错误是“不知道”，有些错误是“搞混了”。后者更致命，因为它说明你的知识体系有结构性缺陷。常见的混淆包括：把微调和RAG混为一谈、把Tokenization和Embedding混为一谈、把Transformer的Encoder和Decoder结构混为一谈、把模型幻觉和模型错误混为一谈。
避免这种错误的方法是在准备面试时画一张知识图谱，把相关概念的关系理清楚。比如RAG是在推理时引入外部知识，微调是在训练时改变模型参数，两者解决的是不同层面的问题，可以结合使用。这种清晰的概念边界，是面试官判断你是否“科班”的重要依据。
10.2 对最新进展一无所知
LLM领域变化很快，面试官通常会关注你有没有跟踪最新进展。不需要你读遍所有论文，但至少要知道主流模型的基本情况、常见工具链的更新、以及社区讨论的热点问题。
比如如果面试官提到“MoE架构”，你要知道它是什么、为什么能降低推理成本、有哪些代表模型。如果提到“Agent”，你要能说清楚Agent和普通Function Calling的区别、当前的主要挑战是什么。这些不需要你成为专家，但完全不知道会显得你和行业脱节。
10.3 忽视工程约束谈方案
很多候选人在面试时喜欢谈“理想方案”，但忽略了实际工程中的约束。比如被问到“如何部署一个LLM服务”，有人会大谈模型架构和算法优化，却不提显存限制、并发处理、监控告警、成本控制这些工程问题。
在实际工作中，工程约束往往比算法选择更能决定方案是否可行。面试时如果你能主动提到“这个方案在A100上可能可行，但在消费级显卡上需要做量化”或者“这个方案的延迟在200ms左右，如果业务要求100ms以内需要换思路”，面试官会认为你是一个有落地经验的人，而不是只会纸上谈兵。
准备LLM面试，本质上不是背八股文，而是系统梳理自己对整个技术栈的理解。这8个问题之所以成为必问，是因为它们覆盖了从模型原理到工程落地的关键节点。你不需要每个问题都答得完美，但至少要能在每个方向上说出自己的思考和经验。面试官要找的不是全知全能的人，而是遇到问题时知道从哪里入手、知道如何权衡、知道怎么验证的人。把这一点传递出去，比答对任何单个问题都重要。
