大模型面试8个核心问题：从Transformer到RAG的硬门槛解析-北京尧图网络

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 位置编码为什么不能直接用位置IDTransformer本身是置换不变的也就是说如果你把输入序列打乱注意力算出来的结果是一样的。但语言是有顺序的所以必须注入位置信息。最朴素的想法是直接给每个位置一个ID0, 1, 2, ...但这样有两个问题一是位置ID会随着序列长度增长而变得很大和词嵌入相加后会破坏词嵌入的尺度二是模型很难泛化到训练时没见过的长度。原始Transformer用的是正弦位置编码PE(pos, 2i) sin(pos / 10000^(2i/d_model)) PE(pos, 2i1) cos(pos / 10000^(2i/d_model))这个设计的好处是对于任意固定的偏移量kPE(posk)可以表示为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核心思想是常见的词保持完整罕见的词拆成更小的子词单元。这样既控制了词表大小又能处理任意文本。目前主流的三种方案是BPEByte 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的效率不能只看模型参数量。模型词表大小中文“你好世界”Token数英文“Hello world”Token数GPT-4~100k62LLaMA-232k82Qwen~150k22ChatGLM~130k23提示上表数据是我在实际项目中用各模型官方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等基准评估。模型维度最大长度多语言特点text-embedding-3-small15368191较好API调用方便但成本随规模增长text-embedding-3-large30728191较好效果更好成本更高BGE-large-zh1024512中文为主中文效果好可本地部署BGE-M310248192多语言支持稠密稀疏多向量检索GTE-large1024512英文为主英文效果好速度快E5-large-v21024512英文为主需要加“query:”和“passage:”前缀注意BGE-M3支持三种检索模式稠密、稀疏、多向量在实际使用中可以根据场景灵活切换。稠密向量适合语义匹配稀疏向量适合关键词匹配多向量适合细粒度匹配。这个设计在RAG场景下非常实用。4.3 Embedding的评估和调优实操评估Embedding模型不能只看MTEB排行榜因为排行榜上的任务和你的实际业务可能差别很大。我一般会做三件事第一构建一个小的评测集包含正例和负例用RecallK和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。这个阶段需要大量算力通常只有大公司或研究机构会做。预训练的关键参数包括学习率通常用warmupcosine衰减、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的对比ReActReasoning 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个问题过一遍基本就能对这个模型或者框架有比较全面的了解了。这个习惯帮我省了很多时间也让我在技术选型的时候更有底气。

大模型面试8个核心问题：从Transformer到RAG的硬门槛解析

相关推荐

金融科技多资产交易平台架构设计与实现

医学图像分割技术：U-Net架构与优化实践

Kinodynamic RRT*：带加速度约束的机器人平滑路径规划

更多资讯

Playwright端到端测试实战：从选型到稳定落地

MySQL索引失效的12种常见场景与优化方案

Python生产级算法工具箱：开箱即用的滑动中位数与哈希表实现

WMS系统解析：仓储管理的核心算法与实施策略

Linux下MongoDB定时备份方案：mongodump与crontab实战

可解释性安全强化学习：原理、技术与应用

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？