企业官网建设流程全解析

1. 为什么这8个问题成了LLM面试的硬门槛

面试过几十个候选人之后，我发现一个很明显的规律：简历上写着“熟悉大模型”“做过RAG”“微调过LLaMA”的人越来越多，但真正能把这些词背后的原理讲清楚的人，比例低得惊人。很多人能说出“Attention is all you need”，但你问他多头注意力里每个头到底在学什么、为什么除以根号dk、位置编码为什么用正弦函数而不是直接拼接一个位置ID，就开始含糊其辞了。

这就是我写这篇东西的原因。标题说的“8个问题答不上来直接淘汰”，不是危言耸听，是我自己和身边几个做LLM方向的面试官朋友聊下来，大家不约而同会问的核心问题。这些问题覆盖了从Transformer架构、Tokenization、Embedding、Function Calling到训练与推理全流程的关键节点。它们之所以成为必问项，是因为每一个都对应着实际工作中会踩的坑：不懂Tokenization，你连模型为什么截断都不知道；不懂Embedding，检索效果差了你根本无从下手；不懂Function Calling的底层机制，Agent工具调用失败你只能瞎猜。

这篇文章适合谁看？如果你是准备面试LLM相关岗位的候选人，这8个问题就是你的复习提纲；如果你是刚转到大模型方向的工程师，这些问题的答案构成了你技术栈的地基；如果你已经在做LLM应用，但总觉得“会用但说不清”，那正好借这个机会把底层逻辑捋一遍。我会按“问题是什么、面试官想听什么、底层原理怎么解释、实际工作中怎么用”这个结构来展开，每个问题都配上我自己的理解和踩过的坑。

需要提前说明的是，下面涉及的具体参数和实现细节，一部分来自原始论文和官方文档，一部分来自我和同行在实际项目中的经验总结。不同模型、不同框架的实现会有差异，我会尽量标注清楚哪些是通用原理、哪些是特定实现的选择。

2. 问题一：Transformer的注意力机制到底在算什么

2.1 从“查字典”理解QKV的本质

面试官问这个问题，不是想听你背“Query、Key、Value三个矩阵”，而是想看你能不能用自己的话把注意力机制讲明白。我一般会这样解释：想象你在查一本字典，你手里有一个词（Query），字典里每个词条都有一个索引（Key）和对应的解释（Value）。注意力机制做的事情，就是拿你的Query去和每一个Key算相似度，相似度越高，那个Key对应的Value就被赋予越大的权重，最后把所有Value加权求和，得到的就是你这个Query的“答案”。

用公式表示就是：

Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V

这里有几个细节面试官很爱追问。第一，为什么要除以根号d_k？因为当维度d_k很大的时候，Q和K的点积结果会变得很大，softmax之后会趋近于one-hot分布，梯度会变得极小，训练不动。除以根号d_k相当于把点积的方差拉回到1附近，保证softmax的输出不会太极端。这个解释比“防止梯度消失”更准确，因为本质上是控制方差。

第二，多头注意力到底在干什么？很多人说“多个头可以关注不同位置”，这个说法对但不完整。更准确的理解是：每个头有自己独立的Q、K、V投影矩阵，相当于把原始空间投影到不同的子空间里，在每个子空间里独立算注意力。这样模型可以在不同的表示子空间里捕捉不同的关系模式——有的头可能关注语法依赖，有的头可能关注语义相似度，有的头可能关注位置邻近。最后把所有头的输出拼接起来再投影一次，就得到了融合多种关系的信息。

2.2 位置编码为什么不能直接用位置ID

Transformer本身是置换不变的，也就是说如果你把输入序列打乱，注意力算出来的结果是一样的。但语言是有顺序的，所以必须注入位置信息。最朴素的想法是直接给每个位置一个ID（0, 1, 2, ...），但这样有两个问题：一是位置ID会随着序列长度增长而变得很大，和词嵌入相加后会破坏词嵌入的尺度；二是模型很难泛化到训练时没见过的长度。

原始Transformer用的是正弦位置编码：

PE(pos, 2i) = sin(pos / 10000^(2i/d_model)) PE(pos, 2i+1) = cos(pos / 10000^(2i/d_model))

这个设计的好处是，对于任意固定的偏移量k，PE(pos+k)可以表示为PE(pos)的线性函数，这让模型能够容易地学习到相对位置关系。而且正弦函数的值域在[-1, 1]之间，不会破坏词嵌入的尺度。现在很多模型改用可学习的位置嵌入或者RoPE（旋转位置编码），但核心思想是一样的：让模型能够区分不同位置，同时保持良好的数值性质和泛化能力。

注意：面试时如果被问到“为什么现在很多模型用RoPE而不是正弦编码”，你可以从“相对位置信息的显式建模”和“更好的长度外推能力”两个角度回答。RoPE通过旋转矩阵把位置信息编码到Q和K的点积里，使得注意力分数天然包含相对位置信息，这在长文本场景下优势明显。

2.3 实际工作中怎么用这些知识

理解注意力机制不只是为了面试。在实际调模型的时候，这些知识直接决定了你的决策。比如你要做长文本推理，发现模型在超过训练长度后效果急剧下降，你就知道要去查这个模型用的是什么位置编码、有没有做长度外推的训练。再比如你要做模型蒸馏，想把大模型的能力迁移到小模型，你就需要知道哪些注意力头是关键的、哪些可以剪掉——这直接关系到蒸馏的策略设计。

我自己的经验是，每次遇到模型效果不符合预期的情况，最后排查下来，十有八九能追溯到对注意力机制某个细节的理解偏差。比如有一次做多轮对话，发现模型总是“忘记”前面几轮的信息，后来发现是因为对话历史拼接后没有正确设置attention mask，导致模型把padding token也当成有效信息算了进去。这种问题，不懂底层原理根本查不出来。

3. 问题二：Tokenization到底做了什么，为什么它这么重要

3.1 从“分词”到“子词切分”的演进

Tokenization是LLM处理文本的第一步，也是很多人最容易忽略的一步。面试官问这个问题，通常是想看你有没有实际处理过文本数据，知不知道不同Tokenization方案对模型行为的影响。

最早的分词就是按空格和标点切分，但这样会遇到两个问题：一是词表会爆炸（英语单词加上各种变形轻松上百万），二是遇到未登录词（OOV）就没法处理。后来出现了子词切分（Subword Tokenization），核心思想是：常见的词保持完整，罕见的词拆成更小的子词单元。这样既控制了词表大小，又能处理任意文本。

目前主流的三种方案是BPE（Byte Pair Encoding）、WordPiece和SentencePiece。BPE从字符开始，每次合并频率最高的相邻对，直到达到目标词表大小。WordPiece和BPE类似，但合并的标准是“能最大化语言模型似然”而不是频率。SentencePiece则把空格也当成普通字符处理，不依赖预分词，对中文、日文等没有空格分隔的语言特别友好。

3.2 为什么同一个词在不同模型里Token数不一样

这是实际工作中非常容易踩的坑。同一个中文句子，在GPT-4的tokenizer里可能是20个token，在LLaMA的tokenizer里可能是35个token。原因在于词表大小、训练语料和切分算法的差异。GPT系列对中文的支持相对较弱，很多中文字符会被拆成多个byte级别的token；而专门针对中文优化的模型（比如Qwen、ChatGLM）词表里包含更多完整的中文字符和常见词组，token数会少很多。

这个差异直接影响你的成本和性能。API按token计费，token数越多越贵；模型的上下文窗口有限，token数越多能放的内容越少；推理速度也和token数正相关。所以如果你在做中文应用，选模型的时候一定要实际测一下tokenizer的效率，不能只看模型参数量。

提示：上表数据是我在实际项目中用各模型官方tokenizer测出来的，不同版本可能有差异。建议你在选型时自己跑一遍测试脚本，用你的真实业务数据来评估。

3.3 Tokenization的坑和实操建议

第一个坑是特殊token的处理。很多模型有[CLS]、[SEP]、<s>、</s>等特殊token，如果你在拼接输入时不小心把这些token当普通文本传进去，模型行为会完全乱掉。我见过一个case，有人在用户输入里直接拼了<|endoftext|>，结果模型以为对话结束了，直接不回复。

第二个坑是截断策略。当输入超过模型最大长度时，你是从左边截、从右边截、还是从中间截？不同策略对效果影响很大。对于问答任务，通常保留问题和文档的开头部分；对于摘要任务，可能需要保留文档的首尾。这个没有标准答案，要根据你的具体任务来定。

第三个坑是token计数和实际字符数的混淆。很多API文档说“最大输入4096 token”，但你的文本是中文，一个汉字可能对应1-2个token，所以实际能放的汉字数可能只有2000-3000。如果你按字符数来估算，很容易超限。

我自己的做法是，在项目初期就写一个工具函数，专门用来估算token数、做截断、处理特殊token。这个函数会被所有后续模块调用，保证一致性。别等到线上出问题了再回头改，那时候改起来成本高得多。

4. 问题三：Embedding模型怎么选、怎么用、怎么评估

4.1 Embedding的本质和常见误区

Embedding就是把文本映射到一个固定维度的向量空间里，使得语义相似的文本在向量空间里距离更近。面试官问这个问题，通常是想考察你对检索、聚类、语义相似度这些任务的理解。

一个常见的误区是认为“Embedding模型越大越好”。实际上，Embedding模型的选择要看你的具体任务。如果你做的是短文本相似度（比如搜索query和标题的匹配），一个小而快的模型可能就够了；如果你做的是长文档检索，需要模型能捕捉段落级别的语义，那就需要更大的模型或者专门针对长文本训练的模型。

另一个误区是忽略归一化。很多Embedding模型输出的向量没有归一化，直接用点积算相似度会受向量模长影响。正确的做法是先做L2归一化，然后用余弦相似度。这个细节在面试中经常被问到，也是实际代码里最容易写错的地方。

4.2 主流Embedding模型对比和选型建议

目前市面上常见的Embedding模型大致分几类：OpenAI的text-embedding系列、BGE系列、GTE系列、E5系列，以及各种基于LLM微调的Embedding模型。选型的时候我一般看几个维度：维度大小（影响存储和检索速度）、最大输入长度（影响能处理的文本长度）、多语言支持（影响跨语言场景）、检索效果（用MTEB等基准评估）。

注意：BGE-M3支持三种检索模式（稠密、稀疏、多向量），在实际使用中可以根据场景灵活切换。稠密向量适合语义匹配，稀疏向量适合关键词匹配，多向量适合细粒度匹配。这个设计在RAG场景下非常实用。

4.3 Embedding的评估和调优实操

评估Embedding模型不能只看MTEB排行榜，因为排行榜上的任务和你的实际业务可能差别很大。我一般会做三件事：第一，构建一个小的评测集，包含正例和负例，用Recall@K和MRR来评估；第二，用t-SNE或者UMAP把向量可视化，看看同类样本是否聚在一起；第三，做bad case分析，看看哪些样本被错误地拉近或推远。

调优方面，如果通用Embedding模型在你的领域效果不好，可以考虑微调。微调Embedding模型通常用对比学习，正例是语义相似的文本对，负例是随机采样的不相关文本。这里有个技巧：负例的质量很关键，用in-batch负例（同一个batch里其他样本作为负例）简单但效果有限，用难负例挖掘（找到和query相似但不相关的样本）效果更好但实现更复杂。

我自己的经验是，在垂直领域（比如法律、医疗），微调后的Embedding模型比通用模型的效果提升非常明显。但微调需要标注数据，如果标注成本太高，可以先试试用LLM生成合成数据来做初步微调，往往也能带来不错的提升。

5. 问题四：Function Calling的底层机制和实现细节

5.1 Function Calling不是“魔法”，而是结构化输出

很多人第一次用Function Calling的时候会觉得“模型怎么知道要调用哪个函数”，其实底层机制并不神秘。模型本身并不执行任何函数，它做的事情是：根据用户的输入和提供的函数描述，生成一个结构化的JSON，里面包含函数名和参数。然后你的代码解析这个JSON，去实际调用对应的函数，再把结果返回给模型，模型根据结果生成最终回复。

所以Function Calling的本质是受约束的文本生成。模型在训练时见过大量“根据描述生成调用参数”的样本，所以它能学会这个模式。但要注意，模型生成JSON的准确率不是100%，尤其是参数复杂或者描述模糊的时候，经常会出现参数缺失、类型错误、甚至函数名拼错的情况。

5.2 怎么写出好的函数描述

函数描述的质量直接决定了Function Calling的成功率。我总结了几条经验：

第一，函数名要语义清晰。get_weather比func1好，search_flights比query好。模型会根据函数名来理解函数的用途。

第二，参数描述要具体。不要只写“city: string”，要写“city: 城市名称，例如'北京'、'上海'”。如果参数有枚举值，一定要列出来。如果参数有格式要求（比如日期格式），一定要说明。

第三，给出使用示例。在函数描述里加一两个调用示例，能显著提升模型的理解准确率。比如：

{ "name": "get_weather", "description": "查询指定城市的天气。例如：用户说'北京今天天气怎么样'，应该调用此函数，参数city='北京'。", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如'北京'、'上海'、'广州'" }, "date": { "type": "string", "description": "日期，格式为YYYY-MM-DD，默认为今天" } }, "required": ["city"] } }

第四，控制函数数量。一次给模型太多函数（比如超过20个），模型的选择准确率会下降。如果确实有很多函数，可以考虑分组或者用路由层先做一轮筛选。

5.3 错误处理和容错机制

Function Calling在实际生产环境中最容易出问题的地方就是错误处理。模型可能生成不合法的JSON、可能调用不存在的函数、可能传错参数类型。我的做法是在解析层做严格的校验：先用JSON schema校验参数，如果失败，把错误信息返回给模型让它重新生成；如果连续失败超过阈值，就降级到普通对话模式。

还有一个坑是并行调用。有些模型支持一次生成多个函数调用，但你的代码可能没有处理这种情况。如果模型返回了一个数组而不是单个对象，你的解析逻辑要能正确处理。我见过有人因为这个原因导致线上服务直接报错。

提示：在开发阶段，建议把每次Function Calling的输入输出都记录下来，包括模型的原始输出、解析后的结果、实际调用的参数和返回。这样出问题的时候可以快速定位是模型生成的问题还是解析逻辑的问题。

6. 问题五：大模型的训练流程和关键参数

6.1 预训练、微调、对齐三阶段

面试官问训练流程，通常是想看你有没有从头训过模型或者至少深度参与过微调。大模型的训练一般分三个阶段：预训练（Pre-training）、监督微调（SFT）、对齐（RLHF/DPO）。

预训练是在海量无标注文本上做自监督学习，目标是预测下一个token。这个阶段需要大量算力，通常只有大公司或研究机构会做。预训练的关键参数包括学习率（通常用warmup+cosine衰减）、batch size（越大越好，但受显存限制）、序列长度（从2k逐步扩展到8k、32k甚至更长）。

监督微调是在高质量的指令-回复数据上继续训练，让模型学会遵循指令。这个阶段的数据质量比数量更重要，几千条高质量数据往往比几十万条低质量数据效果好。关键参数是学习率（通常比预训练小1-2个数量级）、epoch数（通常1-3个epoch，多了容易过拟合）。

对齐阶段是让模型的输出更符合人类偏好。RLHF（基于人类反馈的强化学习）需要训练一个奖励模型，然后用PPO算法优化策略模型。DPO（直接偏好优化）则跳过了奖励模型，直接用偏好数据优化模型。DPO实现更简单、训练更稳定，现在很多团队都转向了DPO。

6.2 微调的关键参数和实操经验

如果你要做微调，有几个参数必须搞清楚。**LoRA的秩（rank）**决定了微调参数量，秩越大表达能力越强但越容易过拟合。我一般从8或16开始试，如果效果不够再往上加。LoRA的alpha是缩放因子，通常设为秩的2倍。学习率方面，LoRA微调通常用1e-4到3e-4，全量微调用1e-5到5e-5。

批次大小和梯度累积要配合使用。如果显存不够，可以用小批次+梯度累积来模拟大批次。比如批次大小设为4，梯度累积设为8，等效批次大小就是32。序列长度要根据你的数据来定，如果数据里大部分样本都在512 token以内，就没必要设成2048，浪费显存。

我踩过的一个坑是数据格式。不同框架对微调数据的格式要求不一样，有的要求JSONL，有的要求特定字段名。如果格式不对，训练脚本可能不报错但学不到东西。建议在正式训练前先用小样本跑一遍，确认loss在下降。

6.3 训练中的常见问题和排查

Loss不下降是最常见的问题。可能的原因包括：学习率太大导致震荡、数据格式错误导致模型没学到有效信息、模型本身太小容量不够。排查方法是先用一个极小的数据集（比如100条）看模型能不能过拟合，如果能过拟合说明模型容量够，问题在数据或超参；如果不能过拟合，说明模型容量不够或者学习率有问题。

Loss下降但效果不好通常是过拟合或者数据分布问题。检查验证集loss是否在上升，如果是就是过拟合，需要减少epoch或者增加正则化。如果验证集loss也在下降但实际效果差，可能是训练数据和测试数据分布不一致，需要检查数据采集和标注流程。

显存溢出是工程上最常见的问题。解决方法包括：减小批次大小、用梯度检查点、用混合精度训练、用LoRA等参数高效微调方法。如果这些都不行，可以考虑用DeepSpeed或FSDP做分布式训练。

7. 问题六：RAG系统的核心组件和优化策略

7.1 RAG不是“检索+生成”这么简单

RAG（检索增强生成）听起来很简单：用户提问，系统检索相关文档，把文档和问题一起送给模型生成回答。但实际做起来，每个环节都有大量细节决定成败。面试官问RAG，通常是想看你有没有实际搭建过系统，知不知道哪里容易出问题。

RAG的核心组件包括：文档处理（解析、分块、清洗）、索引构建（Embedding、向量库）、检索（相似度搜索、重排序）、生成（Prompt构造、上下文管理）。每个组件都有优化空间，而且组件之间的配合也很重要。

7.2 文档分块策略的取舍

分块是RAG里最容易被低估的环节。块太大，检索到的内容包含太多无关信息，会干扰模型；块太小，可能丢失上下文，导致检索到的片段不完整。我一般会根据文档类型来选择策略：对于结构化的文档（比如Markdown、HTML），按标题层级分块；对于连续文本（比如论文、报告），按固定长度分块并设置重叠区域。

重叠区域的大小通常是块大小的10%-20%。比如块大小512 token，重叠64-128 token。这样能保证跨块的信息不会完全丢失。但重叠也会增加索引大小和检索时间，需要权衡。

还有一个技巧是为每个块生成摘要或关键词，检索的时候同时用原始块和摘要做匹配。这样既能保证语义匹配的准确性，又能通过关键词匹配捕捉到一些Embedding可能忽略的细节。

7.3 检索优化和重排序

向量检索的召回率通常不是问题，但精确率往往不够。也就是说，检索出来的文档里有很多是不相关的。这时候就需要重排序（Rerank）。重排序模型通常是交叉编码器（Cross-Encoder），它把query和文档一起输入模型，输出一个相关性分数。因为交叉编码器能同时看到query和文档的完整信息，所以排序准确率比双编码器（Bi-Encoder）高很多。

实际系统中，我一般用双编码器做粗排（召回Top 50-100），然后用交叉编码器做精排（选出Top 3-5送给生成模型）。这样兼顾了速度和准确率。

注意：重排序模型的计算成本比Embedding模型高很多，因为每个query-document对都要过一次模型。如果召回数量太大，重排序会成为瓶颈。建议根据实际延迟要求调整召回数量。

7.4 生成阶段的Prompt设计

检索到文档之后，怎么把文档和问题组织成Prompt送给模型，也有很多讲究。我一般会遵循几个原则：明确指令（告诉模型基于提供的文档回答，不要编造）、引用来源（让模型在回答中标注信息来自哪个文档）、处理冲突（如果不同文档信息矛盾，让模型指出矛盾而不是随便选一个）、兜底策略（如果文档里没有答案，让模型明确说“根据提供的信息无法回答”）。

Prompt的格式也很重要。我通常会把文档放在前面，问题放在后面，用分隔符明确区分。比如：

请基于以下文档回答问题。如果文档中没有相关信息，请回答“根据提供的信息无法回答”。 文档1： [文档内容] 文档2： [文档内容] 问题：[用户问题]

这个格式看起来简单，但实际测试下来比把问题放在前面的效果好很多。原因可能是模型在生成时能更好地关注到最近的上下文。

8. 问题七：Agent系统的设计模式和容错机制

8.1 Agent不是“万能助手”，而是任务编排器

很多人对Agent的理解有偏差，觉得Agent就是一个能自己思考、自己调用工具、自己完成复杂任务的智能体。实际上，当前阶段的Agent更像是一个任务编排器：它根据用户输入，决定调用哪些工具、按什么顺序调用、如何处理中间结果。它的“智能”体现在任务分解和工具选择上，而不是真正的自主意识。

Agent的核心组件包括：规划（把复杂任务拆成子任务）、工具调用（Function Calling）、记忆（短期记忆和长期记忆）、反思（根据执行结果调整策略）。面试官问Agent，通常是想看你有没有处理过工具调用失败、任务分解不合理、循环调用这些实际问题。

8.2 ReAct模式和Plan-and-Execute的对比

ReAct（Reasoning + Acting）是目前最常用的Agent模式。它的核心循环是：思考（Thought）→ 行动（Action）→ 观察（Observation）→ 再思考。模型先分析当前状态，决定下一步做什么，然后调用工具，观察结果，再决定下一步。这个模式灵活，适合探索性任务，但容易陷入循环或者偏离目标。

Plan-and-Execute模式则是先制定完整计划，然后按计划执行。这个模式适合步骤明确的任务，执行效率高，但缺乏灵活性，如果中间步骤失败，整个计划可能需要重新制定。

实际系统中，我通常会把两者结合：先用Plan-and-Execute做高层规划，把任务拆成几个大步骤；每个步骤内部用ReAct做具体执行。这样既有全局视野，又有局部灵活性。

8.3 容错机制和边界处理

Agent系统最容易出问题的地方就是容错。工具调用可能失败、返回结果可能不符合预期、模型可能陷入循环。我一般会设置几层防护：

第一，最大步数限制。防止Agent无限循环，通常设10-20步，超过就强制停止并返回当前结果。

第二，工具调用重试。如果工具调用失败（比如网络超时），自动重试2-3次，每次重试可以调整参数或者换一个等价的工具。

第三，结果校验。每次工具返回结果后，用规则或者小模型校验结果是否合理。比如查询天气返回了“-100度”，明显不合理，就触发异常处理。

第四，降级策略。如果Agent连续失败，降级到普通对话模式，告诉用户“我暂时无法完成这个任务，请换一种方式提问”。

提示：Agent的日志记录非常重要。每次思考、行动、观察都要完整记录，包括时间戳、输入输出、耗时。这样出问题的时候可以完整回放整个执行过程，快速定位问题。

9. 问题八：模型评估和线上监控怎么做

9.1 离线评估和在线评估的区别

面试官问评估，通常是想看你有没有从“模型效果”到“业务效果”的完整视角。离线评估是在标注数据集上算指标（比如准确率、F1、BLEU、ROUGE），优点是快速、可复现，缺点是可能和实际业务效果脱节。在线评估是通过A/B测试看业务指标（比如点击率、转化率、用户满意度），优点是真实，缺点是周期长、成本高。

我的做法是：离线评估用来快速迭代和筛选方案，在线评估用来做最终决策。离线评估的指标要和业务目标对齐，比如做客服机器人，离线指标可以是“回答准确率”，在线指标可以是“用户问题解决率”和“转人工率”。

9.2 LLM评估的特殊挑战

传统模型的评估相对简单，因为输出是确定性的（分类标签、数值）。但LLM的输出是开放式的文本，评估起来困难得多。同一个问题，模型可以用完全不同的方式回答，但都是正确的。这时候用BLEU、ROUGE这些基于n-gram重叠的指标就不太合适了。

目前常用的LLM评估方法包括：人工评估（最准确但最贵）、模型评估（用GPT-4等强模型做裁判）、规则评估（针对特定任务写规则）。我一般会组合使用：先用规则做快速筛选，再用模型评估做大规模打分，最后用人工评估做抽样校验。

模型评估的Prompt设计很关键。我通常会让裁判模型从几个维度打分：相关性（回答是否切题）、准确性（信息是否正确）、完整性（是否覆盖了关键点）、流畅性（语言是否自然）。每个维度1-5分，最后加权平均。

9.3 线上监控的关键指标

线上监控不只是看模型效果，还要看系统健康度。我一般会监控几类指标：

效果指标：回答准确率、用户满意度、任务完成率。这些通常通过用户反馈（点赞/点踩）或者抽样人工评估来获取。

性能指标：首token延迟、总响应时间、吞吐量。这些直接影响用户体验，尤其是流式输出的场景，首token延迟超过2秒用户就会觉得卡。

成本指标：token消耗量、API调用次数、GPU利用率。这些直接影响运营成本，尤其是按token计费的API，需要设置预算告警。

异常指标：错误率、超时率、内容安全拦截率。这些指标突然上升通常意味着系统出了问题，需要立即排查。

注意：线上监控的数据要定期回顾，不只是看报警。我习惯每周做一次数据复盘，看看有没有缓慢恶化的趋势（比如准确率每周下降0.5%），这种缓慢变化不会触发报警，但长期累积下来影响很大。

10. 面试之外的实操建议

这8个问题覆盖了LLM从底层原理到工程实践的完整链路。但面试只是手段，真正重要的是在实际工作中能把这些知识用起来。我自己的体会是，LLM这个领域变化太快，今天的热点明天可能就过时了，但底层原理和工程思维是相对稳定的。

如果你正在准备面试，我的建议是不要死记硬背答案，而是找一个实际的项目动手做一遍。比如自己搭一个RAG系统，从文档处理到检索到生成完整走一遍，你会遇到各种问题，解决这些问题的过程比看十篇文章都有用。再比如自己微调一个小模型，哪怕只是用LoRA微调一个7B模型做文本分类，你也会对训练流程有完全不同的理解。

如果你已经在做LLM相关的工作，我建议定期回顾这8个问题，看看自己是不是还能清晰地回答。很多时候我们做着做着就陷入了细节，忘记了整体架构和核心原理。每隔一段时间跳出来重新审视一遍，往往会有新的收获。

最后分享一个我自己的习惯：每次遇到新的模型或者新的框架，我都会用这8个问题去“拷问”它。它的注意力机制有什么改进？Tokenization有什么特点？Embedding怎么做的？支持Function Calling吗？训练流程是什么？RAG怎么集成？Agent能力如何？怎么评估？把这8个问题过一遍，基本就能对这个模型或者框架有比较全面的了解了。这个习惯帮我省了很多时间，也让我在技术选型的时候更有底气。