1. 模型底层认知问题——这两问答不好第一轮就会被挂1.1 为什么需要Q、K、V注意力矩阵为什么不能省面试问到LLM十个有九个会先拿Transformer的self-attention开刀。你要是只回答“Q是查询K是键V是值”那基本等于没说。面试官真正想听的是为什么非得搞出三个向量直接拿输入向量互相点乘不行吗这里的关键在于解耦。Q、K、V的拆分让模型可以同时表达“我要找什么”和“我找到之后怎么用”。打个生活化的比方你去图书馆查资料K是书架上的标签分类Q是你手里的检索单V才是被抽出来具体阅读的那本书。如果只有标签和书混在一起你找书时还得把每本打开看一遍计算量直接爆炸而且信息之间互相干扰。从矩阵运算的角度看Attention(Q,K,V)softmax(QK^T/√d)V。Q和K的乘积算的是两两之间的相关性分数除以√d是为了防止点积过大把softmax推向饱和区。这一步看着简单但有个隐藏考点如果√d不除训练初期梯度会非常不稳定模型很难收敛。实测中把缩放因子删掉小模型还能勉强跑起来参数量一上去loss直接震荡给你看。还有个容易被追问的点为什么用点积而不是加性注意力很多答得好的候选人会提到点积在GPU上可以用高度优化的矩阵乘法实现吃满并行计算加性注意力在隐层维度很大时精度差不多但速度差出好几倍。实际部署LLM时推理速度就是钱所以工程侧几乎全部选择缩放点积注意力。你要是能顺带说出“这就是为什么MLA、GQA这些变体都在减少KV缓存上做文章”面试官基本就会点头了。多提一句80/20法则面试答这个题80%的分数来自你把“解耦”和“缩放”两个点讲透剩下20%才是花式扩展。别一上来就把FlashAttention、稀疏注意力全倒出来那是第二步的事。1.2 Tokenizer与数据标注别小看输入侧的脏活累活第二个高频题是Tokenizer。很少有人在面试前认真准备这个因为网上的教程都在讲Transformer、讲微调没人告诉你“为什么同一个prompt换个分词方式效果差一大截”。但这恰恰是面试官区分“背过八股”和“真正处理过数据”的试金石。Tokenizer的核心工作是文本到id的映射。最常用的BPEByte Pair Encoding算法本质上是一个贪心合并的过程先按单字符拆开统计最常出现的相邻字符对合并然后重复。中文场景下BPE有个著名的大坑它会倾向于把高频汉字单独拆开把低频词合并成整词。结果就是“苹果”可能被分成“苹”“果”也可能被整体编码完全取决于语料统计。这就导致同一个词在不同上下文里token数量不一样模型感知到的“语义单位”跟人类预期完全不符。这里有个真实的工程教训我处理过一批中文法律文书直接用通用中文tokenizer一段500字的合同被切出700多个token而同一段内容切换到针对法律语料增量训练过词表的模型只有450个token。前者不仅推理变慢关键条款的注意力权重还会被割裂导致摘要漏掉重要信息。所以做中文LLM应用第一件事永远是先统计你的业务语料在不同tokenizer下的切分情况而不是急着选模型。关于数据标注这个更考验实操理解。面试官常问“你如何为SFT构造指令数据”。很多人上来就说“找几个人写prompt和回答就行”这种答案直接暴露了没做过真实项目。实际流程里要处理的是指令的多样性分布、回答的格式一致性、难例的挖掘、以及标注一致性的判重。一个能用的SFT数据集至少要经过三轮回标Kappa系数低于0.7的数据基本都要清洗掉。举个例子你让标注员写“总结这段对话”十个标注员会写出十种格式有的用列表有的用段落有的加了开场白。模型学完这种数据上线后输出格式会五花八门解析脚本直接崩溃。我个人的经验是先把回答格式用few-shot示例固定死再让标注员照着填内容。格式统一之后再用规则脚本做一遍自动校验过滤掉空回答、超长回答、包含敏感词的样本。这个流程看着繁琐但能让你后面微调省下大量擦屁股的时间。面试时说得出这个尺度感比背一百个BPE公式都管用。2. 从训练到部署的核心权衡——这两问最考验工程功底2.1 显存与KV Cache面试官真正想听什么“我要部署一个7B模型需要多少显存”这个问题看起来是算术题实际上是个陷阱题。如果你只回答“7B参数乘2字节就是14GB”那面试官会直接给你贴一个“没上手部署过”的标签。真正部署过的人都知道显存占用的大头是激活值和KV Cache而不是参数本身。先说参数的显存7B模型用FP16存储裸参数占14GB。如果用INT8量化占7GBINT4量化约3.5GB。但这是静态的加载完就固定不变。真正动态膨胀的是KV Cache——每生成一个token都要把当前层的K和V缓存下来供后续token计算注意力时使用。这个缓存的大小怎么算公式是KV Cache显存 2K和V两组× 层数 × 头数 × 每头维度 × 序列长度 × 精度字节数。举个具体例子7B模型常见配置是32层、32头、128维每头在4096序列长度、FP16精度下单条请求的KV Cache就是2×32×32×128×4096×2字节算出来约2GB。如果并发32路请求光KV Cache就吃掉64GB比模型本身大得多。很多面试者不知道的是KV Cache就是推理引擎里最烧钱的部分所以现在大家都在搞GQA分组查询注意力和MLA多头潜在注意力。GQA让多个查询头共享一组K和V缓存直接缩到原来的1/8MLA把KV压缩成低秩形式进一步减少缓存。你如果能从“显存计算”聊到“所以DeepSeek用MLA就是为了省缓存从而降低推理成本”面试官眼前会一亮。实操层面还有一个容易被忽略的点显存占用不等于模型文件大小加缓存。PyTorch的CUDA context本身会预留几百MB甚至几GB碎片化也可能让你明明算着够用的显存OOM。我上线过一个量化模型算下来15GB就够结果实际跑批处理时峰值显存冲到19GB就是因为激活值峰值和KV Cache峰值叠加了。后来我干脆在服务启动时先把max_memory锁在可用显存的90%给CUDA context和激活值留出余量。面试时把这类细节讲出来比背公式有说服力得多。2.2 量化与本地运行GGUF、INT8/INT4的能力损失在哪里“你本地跑过模型吗”现在很多面试官会追着问这句因为本地部署已经成了工程能力的分水岭。这里的考点不只是“你会不会用llama.cpp”而是“你知不知道量化损失了什么”。GGUF格式本质上是把模型权重打包成一个单一文件内置了分词器和元信息配合llama.cpp这类CPU亲和性高的推理引擎可以做到纯CPU跑起来。ChatGPT问世之后社区涌现了一堆安卓端GGUF运行工具一些开源项目甚至能在骁龙芯片上跑7B模型速度大概每秒8-12个token虽然不快但已经具备实用价值。面试聊到这块时你要主动区分一个概念GGUF是存储格式量化和反量化是计算过程两者不等价。很多人误以为GGUF就是INT4这是一个非常典型的认知错误。量化的真实能力损耗看评测数据才直观。拿7B模型为例INT8量化几乎无损困惑度只掉不到0.1INT4量化会让在复杂推理任务上的得分下降5%-10%特别是在数学和代码这类需要精确计算的任务上。注意这里的“精确计算”指的是模型内部的数值精度不是指它能做对数学题。INT4的误差会在多层传播中累积生成长文本时更容易出现语义漂移开头还在讨论方案结尾就跑题了。怎么在质量与显存之间做权衡我的经验是按任务性质选精度。简单抽取、摘要类任务INT4完全够用但如果要做Agent规划、代码补全至少上INT8或FP16。还有一种折中方案模型主体保持INT8最后两层保留FP16这样推理质量能拉回来不少显存增加却只有几个GB。我在项目里用这个方案跑过一个7B模型的代码生成任务HumanEval通过率比纯INT4高出约3个百分点代价仅仅是显存多占2.1GB。另外安卓本地跑模型这件事核心限制不只是算力还有内存带宽。LLM推理是memory-bound任务每生成一个token都要把整个权重过一遍所以token生成速度取决于内存带宽而不是GPU算力。这也是为什么同一台设备上7B模型的速度差不多由内存规格决定而不是CPU型号。能把内存带宽这个点讲清楚说明你真的调过本地推理而不只是装过一次demo。3. 训练、对齐与评测问题——这两问决定你懂不懂“打磨模型”3.1 SFT、RLHF、DPO到底怎么选“微调”在简历上出现频率极高但面试官只要追问“为什么用DPO而不是RLHF”就能筛掉一大半人。这不怪你网上教程大多只教跑脚本不教背后的权衡逻辑。先说三者关系。SFT是监督微调让模型学会“模仿”高质量回答的格式和风格RLHF是把“人类偏好”信号通过奖励模型反馈给策略模型用强化学习优化DPO是2023年才出来的方法核心思想很直接不需要单独的奖励模型和采样循环直接用偏好数据对来优化策略。用一句话概括SFT学“怎么答”RLHF学“答什么更好”DPO用隐式奖励替代显式奖励来达到RLHF的效果。选型的关键在于你的数据规模和训练资源。如果你手里只有几千条SFT数据老老实实做SFT就行不要碰RLHF。我见过不少团队拿着5000条数据就上PPO结果奖励模型先崩了策略模型越训越差最后效果还不如微调前。RLHF的工程门槛在于需要四个模型策略、参考、奖励、价值的稳定配合任何一环的学习率设置不当都会导致训练崩溃。DPO只需要两份数据被接受的回答和被拒绝的回答和一个当前策略模型加一个冻结参考模型显存占用直降一半收敛稳定性大幅提升。从数据需求来看RLHF需要一组偏好标注排序ABC而DPO只需要成对偏好A优于B。这个差异在真实项目里非常大让标注员给五个回答排顺序和两个回答里选一个前者的标注一致性低、耗时长、费用高。所以我的建议是中小团队、预算有限、数据规模在几万对以内优先DPO只有当你面临的是极其复杂的对齐场景比如多目标权衡、安全约束才需要RLHF的灵活性。有个实操细节值得在面试时主动分享DPO训练时β超参控制对偏好差异的敏感度。β太大会让模型过度追求偏好差异频繁生成重复句式β太小则模型几乎不改变行为。我试过一组对比β从0.1升到0.5时回答长度平均增长12%但多样性指标下降8%。所以这个参数不是随便抄个0.1就完事的要结合你的评估集去调。还要提醒一个容易踩的坑DPO要求偏好数据中“被拒绝回答”必须来自当前模型或非常接近当前模型的分布。如果你用GPT-4生成被拒绝回答再用小模型去DPO效果会非常差。因为模型会拼命往GPT-4风格上靠反而丢失自己的知识表达能力。标准做法是先让模型自己采样多个回答再用GPT-4或人工选出优劣对。这个细节在面试里说出来会让人觉得你真的是做过对齐训练的。3.2 PPL、ROUGE、Benchmark评测指标别只会背定义评测问题是面试官最爱用来压轴的一个领域。因为“模型效果好不好”是所有项目的最终交付标准而你如果只会说“看BLEU、ROUGE、PPL”那说明你连评测的坑都没踩过。先理清这些指标各自的适用范围。PPL困惑度衡量模型对文本的预测概率数值越低说明模型越“自信”但它只刻画语言流畅度不刻画事实正确性。一个模型可能PPL很低但它每句话都是语法通顺的胡说八道。ROUGE和BLEU都是基于n-gram重叠的指标适合摘要、翻译这类有固定参考答案的任务但对开放域问答完全无效——两个意思一致但措辞不同的回答ROUGE可能打0分。Benchmark则是用标准化数据集衡量模型在特定任务上的表现比如MMLU测知识广度、GSM8K测数学推理、HumanEval测代码生成。实战中真正的第一条原则永远不要只用一个指标。我做过一个客服意图识别模型ROUGE分数很高但线上使用时用户根本不会按标准句式提问。后来我加了人工抽测发现模型对“退钱”和“退款”这类同义表达识别能力极弱。ROUGE只看字面重叠无法捕捉语义等价。从此我们组的评测体系固定为“自动指标规则校验人工抽测”三层缺一不可。第二条原则评测集必须贴近真实分布。很多团队贪方便直接跑MMLU、C-Eval这些公开benchmark分数出来挺好看上线后效果却稀烂。原因就是公开benchmark和你的业务场景分布不一致。正确做法是先洗一批线上真实请求按意图分层抽样配上人工标注的标准答复再混合少量公开benchmark组成一个“业务通用”混合评测集。比例我常用7:3业务7通用3。还有个小技巧评测时一定要记录逐样本结果不要只记平均分。平均分容易被极端样本拉高或拉低。我之前优化一版模型整体PPL下降了0.5看起来很漂亮结果按类别一拆发现所有提升都来自高频类别低频类别的效果反而下降了。这种问题只看平均分根本发现不了。面试聊到这里的时候你可以把这个案例讲出来比背指标定义有冲击力得多。4. 智能体与工程可靠性问题——这两问决定你能走多远4.1 Agent的容错控制怎么设计才不会失控现在面试越来越爱问Agent因为大模型应用已经从前期的聊天机器人转向了能自己规划、调用工具、执行任务的智能体。热门搜索词里就有“智能体自主容错控制”这确实是构建可靠AI系统绕不开的工程难题。先说清楚为什么Agent容易失控。模型在单轮对话里表现好不代表它能在多轮自回归中保持稳定。Agent的基本模式是ReAct模型自己“思考”下一步然后“执行”一个工具调用观察结果再“思考”。这个循环每跑一轮就多一次出错的机会而且错误会累积放大。第一轮决策偏了后续所有步骤都基于错误前提越滚越偏。工程上怎么控制最核心的手段是加约束层而不是指望模型自觉。我的做法是把Agent流程做成“有限状态机”而不是完全自由规划定义好状态集合比如初始、信息收集、工具调用、结果验证、最终回答模型只能在当前状态允许的动作里选择不能随意跳转。这相当于给模型画了一条赛道它可以跑得快但不能下道。第二个手段是超时和轮次上限。Agent里最常见的问题是进入死循环模型反复调用同一个工具拿不到新信息。我的项目里设置了两个硬指标单工具调用超时15秒整轮Agent循环最多8次。超过后强制转入“兜底回答”分支告诉用户“当前无法完成该操作”而不是让模型无限转圈。下线时计数器归零发现有一类问题反复超时就说明工具接口或提示词需要优化。第三个手段是输出校验。每次工具调用的结果不能直接回到模型上下文要先过一层规则校验过滤掉空结果、异常报错、超大文本。我踩过一次很深的坑一个搜索工具返回了10万字的内容Agent把这10万字全部纳入上下文直接把上下文窗口撑爆整个会话崩溃。后来的方案是把工具返回内容截断到5000字符以内同时保留摘要信息模型只需要关注关键部分。面试时被问“你如何防止Agent幻觉”别只说“用RAG”这种标准答案。你可以拆解成三层第一层是工具返回数据的数据溯源每条返回带来源ID回答时要求模型引用来源第二层是自一致性检查让模型在回答前先“复述一遍关键数据”确保上下文里的信息被正确理解第三层是置信度判断当模型自身概率偏低时主动输出“不确定”而不是强行给结论。这三层结合才算一个完整的容错设计。4.2 Function Calling与Tool Use从Demo到生产环境的距离最后一个高频问题是Function Calling。在面试中问这个基本就是为了分辨你是“调过API的选手”还是“做过生产级系统的工程师”。Function Calling的原理并不复杂模型不是直接生成“调用某个函数”的指令而是输出一段结构化JSON里面包含函数名和参数。然后你的代码层解析这段JSON执行对应的函数。整个过程看起来简单但生产环境的坑一个比一个深。第一个坑是参数校验。模型生成的JSON字段名和类型可能跟你的函数签名不一致。比如你的函数接收“keyword”参数模型输出的是“query”。这种情况在GPT-3.5时代很常见现在的模型好了很多但仍不能完全信任。我在生产环境里加了JSON Schema校验层字段名不符、类型错误、必要参数缺失的调用直接驳回让模型重新生成。实测下来调用成功率从92%提到了99.2%。第二个坑是并发和依赖。一个真实业务场景Agent可能需要先查天气再根据天气决定是否调用“订机票”函数这两个调用之间有依赖关系。如果你的工具执行层是纯异步并行执行就可能出现“机票订好了却发现天气是台风天”的尴尬。我的做法是为有依赖关系的工具建立一个DAG有向无环图执行器每轮Agent循环生成一个或多个候选调用执行器先检查前置条件满足才执行不满足就暂存等待。这个方案上线后复杂任务的完成率提高了18%。第三个坑是错误反馈。很多人的Function Calling失败后就直接返回“调用失败”给模型模型接到这个信息后容易胡言乱语。正确做法是把异常信息结构化后回传告诉模型“调用失败原因是参数missing请检查”并附上重试建议。这相当于把调试环境交给模型让它能自我修正。我在实践中发现模型能基于错误信息自己调整参数重试重试成功率约70%。面试时如果能再补充一个细节会特别加分Function Calling的系统提示词里应该把工具描述写得像“API文档里的简介”而不是“教科书里的定义”。描述要包含这个工具在什么场景下用、参数的含义和格式、常见的坑。模型读提示词和你读API文档是一样的描述越贴近真实使用方式越容易选对工具。我曾经对比过两组提示词一组用技术文档风格另一组用场景化描述后者工具选择准确率高出11个百分点。最后一个小技巧Function Calling的输出不要直接给用户看。用户在界面上只需要看到业务结果——比如“已帮你预订了明天下午3点的会议室”而不是看到模型的JSON输出。前端呈现与后端执行解耦是智能体工程化的基础设计逻辑。面试时说到这一层说明你真的想过用户体验而不只是跑通demo。我在实际面试候选人的过程中发现一个规律能把这8个问题回答到“有工程细节、有踩坑数据、有取舍逻辑”程度的人入职后基本都能在两周内上手项目。反而是那种知识面广但每块都是背定义的人遇到线上问题就抓瞎。所以准备面试与其花时间背诵几十个术语不如亲手部署一次模型、微调一个数据集、把一个Agent跑出问题再修好。这种真实经验带来的手感是任何面试攻略都给不了你的。 
长河君 · 2026/10/26 14:19:40 · 阅读 1.2k 大模型面试8大核心问题：从注意力机制到智能体工程实践
1. 模型底层认知问题——这两问答不好第一轮就会被挂1.1 为什么需要Q、K、V注意力矩阵为什么不能省面试问到LLM十个有九个会先拿Transformer的self-attention开刀。你要是只回答“Q是查询K是键V是值”那基本等于没说。面试官真正想听的是为什么非得搞出三个向量直接拿输入向量互相点乘不行吗这里的关键在于解耦。Q、K、V的拆分让模型可以同时表达“我要找什么”和“我找到之后怎么用”。打个生活化的比方你去图书馆查资料K是书架上的标签分类Q是你手里的检索单V才是被抽出来具体阅读的那本书。如果只有标签和书混在一起你找书时还得把每本打开看一遍计算量直接爆炸而且信息之间互相干扰。从矩阵运算的角度看Attention(Q,K,V)softmax(QK^T/√d)V。Q和K的乘积算的是两两之间的相关性分数除以√d是为了防止点积过大把softmax推向饱和区。这一步看着简单但有个隐藏考点如果√d不除训练初期梯度会非常不稳定模型很难收敛。实测中把缩放因子删掉小模型还能勉强跑起来参数量一上去loss直接震荡给你看。还有个容易被追问的点为什么用点积而不是加性注意力很多答得好的候选人会提到点积在GPU上可以用高度优化的矩阵乘法实现吃满并行计算加性注意力在隐层维度很大时精度差不多但速度差出好几倍。实际部署LLM时推理速度就是钱所以工程侧几乎全部选择缩放点积注意力。你要是能顺带说出“这就是为什么MLA、GQA这些变体都在减少KV缓存上做文章”面试官基本就会点头了。多提一句80/20法则面试答这个题80%的分数来自你把“解耦”和“缩放”两个点讲透剩下20%才是花式扩展。别一上来就把FlashAttention、稀疏注意力全倒出来那是第二步的事。1.2 Tokenizer与数据标注别小看输入侧的脏活累活第二个高频题是Tokenizer。很少有人在面试前认真准备这个因为网上的教程都在讲Transformer、讲微调没人告诉你“为什么同一个prompt换个分词方式效果差一大截”。但这恰恰是面试官区分“背过八股”和“真正处理过数据”的试金石。Tokenizer的核心工作是文本到id的映射。最常用的BPEByte Pair Encoding算法本质上是一个贪心合并的过程先按单字符拆开统计最常出现的相邻字符对合并然后重复。中文场景下BPE有个著名的大坑它会倾向于把高频汉字单独拆开把低频词合并成整词。结果就是“苹果”可能被分成“苹”“果”也可能被整体编码完全取决于语料统计。这就导致同一个词在不同上下文里token数量不一样模型感知到的“语义单位”跟人类预期完全不符。这里有个真实的工程教训我处理过一批中文法律文书直接用通用中文tokenizer一段500字的合同被切出700多个token而同一段内容切换到针对法律语料增量训练过词表的模型只有450个token。前者不仅推理变慢关键条款的注意力权重还会被割裂导致摘要漏掉重要信息。所以做中文LLM应用第一件事永远是先统计你的业务语料在不同tokenizer下的切分情况而不是急着选模型。关于数据标注这个更考验实操理解。面试官常问“你如何为SFT构造指令数据”。很多人上来就说“找几个人写prompt和回答就行”这种答案直接暴露了没做过真实项目。实际流程里要处理的是指令的多样性分布、回答的格式一致性、难例的挖掘、以及标注一致性的判重。一个能用的SFT数据集至少要经过三轮回标Kappa系数低于0.7的数据基本都要清洗掉。举个例子你让标注员写“总结这段对话”十个标注员会写出十种格式有的用列表有的用段落有的加了开场白。模型学完这种数据上线后输出格式会五花八门解析脚本直接崩溃。我个人的经验是先把回答格式用few-shot示例固定死再让标注员照着填内容。格式统一之后再用规则脚本做一遍自动校验过滤掉空回答、超长回答、包含敏感词的样本。这个流程看着繁琐但能让你后面微调省下大量擦屁股的时间。面试时说得出这个尺度感比背一百个BPE公式都管用。2. 从训练到部署的核心权衡——这两问最考验工程功底2.1 显存与KV Cache面试官真正想听什么“我要部署一个7B模型需要多少显存”这个问题看起来是算术题实际上是个陷阱题。如果你只回答“7B参数乘2字节就是14GB”那面试官会直接给你贴一个“没上手部署过”的标签。真正部署过的人都知道显存占用的大头是激活值和KV Cache而不是参数本身。先说参数的显存7B模型用FP16存储裸参数占14GB。如果用INT8量化占7GBINT4量化约3.5GB。但这是静态的加载完就固定不变。真正动态膨胀的是KV Cache——每生成一个token都要把当前层的K和V缓存下来供后续token计算注意力时使用。这个缓存的大小怎么算公式是KV Cache显存 2K和V两组× 层数 × 头数 × 每头维度 × 序列长度 × 精度字节数。举个具体例子7B模型常见配置是32层、32头、128维每头在4096序列长度、FP16精度下单条请求的KV Cache就是2×32×32×128×4096×2字节算出来约2GB。如果并发32路请求光KV Cache就吃掉64GB比模型本身大得多。很多面试者不知道的是KV Cache就是推理引擎里最烧钱的部分所以现在大家都在搞GQA分组查询注意力和MLA多头潜在注意力。GQA让多个查询头共享一组K和V缓存直接缩到原来的1/8MLA把KV压缩成低秩形式进一步减少缓存。你如果能从“显存计算”聊到“所以DeepSeek用MLA就是为了省缓存从而降低推理成本”面试官眼前会一亮。实操层面还有一个容易被忽略的点显存占用不等于模型文件大小加缓存。PyTorch的CUDA context本身会预留几百MB甚至几GB碎片化也可能让你明明算着够用的显存OOM。我上线过一个量化模型算下来15GB就够结果实际跑批处理时峰值显存冲到19GB就是因为激活值峰值和KV Cache峰值叠加了。后来我干脆在服务启动时先把max_memory锁在可用显存的90%给CUDA context和激活值留出余量。面试时把这类细节讲出来比背公式有说服力得多。2.2 量化与本地运行GGUF、INT8/INT4的能力损失在哪里“你本地跑过模型吗”现在很多面试官会追着问这句因为本地部署已经成了工程能力的分水岭。这里的考点不只是“你会不会用llama.cpp”而是“你知不知道量化损失了什么”。GGUF格式本质上是把模型权重打包成一个单一文件内置了分词器和元信息配合llama.cpp这类CPU亲和性高的推理引擎可以做到纯CPU跑起来。ChatGPT问世之后社区涌现了一堆安卓端GGUF运行工具一些开源项目甚至能在骁龙芯片上跑7B模型速度大概每秒8-12个token虽然不快但已经具备实用价值。面试聊到这块时你要主动区分一个概念GGUF是存储格式量化和反量化是计算过程两者不等价。很多人误以为GGUF就是INT4这是一个非常典型的认知错误。量化的真实能力损耗看评测数据才直观。拿7B模型为例INT8量化几乎无损困惑度只掉不到0.1INT4量化会让在复杂推理任务上的得分下降5%-10%特别是在数学和代码这类需要精确计算的任务上。注意这里的“精确计算”指的是模型内部的数值精度不是指它能做对数学题。INT4的误差会在多层传播中累积生成长文本时更容易出现语义漂移开头还在讨论方案结尾就跑题了。怎么在质量与显存之间做权衡我的经验是按任务性质选精度。简单抽取、摘要类任务INT4完全够用但如果要做Agent规划、代码补全至少上INT8或FP16。还有一种折中方案模型主体保持INT8最后两层保留FP16这样推理质量能拉回来不少显存增加却只有几个GB。我在项目里用这个方案跑过一个7B模型的代码生成任务HumanEval通过率比纯INT4高出约3个百分点代价仅仅是显存多占2.1GB。另外安卓本地跑模型这件事核心限制不只是算力还有内存带宽。LLM推理是memory-bound任务每生成一个token都要把整个权重过一遍所以token生成速度取决于内存带宽而不是GPU算力。这也是为什么同一台设备上7B模型的速度差不多由内存规格决定而不是CPU型号。能把内存带宽这个点讲清楚说明你真的调过本地推理而不只是装过一次demo。3. 训练、对齐与评测问题——这两问决定你懂不懂“打磨模型”3.1 SFT、RLHF、DPO到底怎么选“微调”在简历上出现频率极高但面试官只要追问“为什么用DPO而不是RLHF”就能筛掉一大半人。这不怪你网上教程大多只教跑脚本不教背后的权衡逻辑。先说三者关系。SFT是监督微调让模型学会“模仿”高质量回答的格式和风格RLHF是把“人类偏好”信号通过奖励模型反馈给策略模型用强化学习优化DPO是2023年才出来的方法核心思想很直接不需要单独的奖励模型和采样循环直接用偏好数据对来优化策略。用一句话概括SFT学“怎么答”RLHF学“答什么更好”DPO用隐式奖励替代显式奖励来达到RLHF的效果。选型的关键在于你的数据规模和训练资源。如果你手里只有几千条SFT数据老老实实做SFT就行不要碰RLHF。我见过不少团队拿着5000条数据就上PPO结果奖励模型先崩了策略模型越训越差最后效果还不如微调前。RLHF的工程门槛在于需要四个模型策略、参考、奖励、价值的稳定配合任何一环的学习率设置不当都会导致训练崩溃。DPO只需要两份数据被接受的回答和被拒绝的回答和一个当前策略模型加一个冻结参考模型显存占用直降一半收敛稳定性大幅提升。从数据需求来看RLHF需要一组偏好标注排序ABC而DPO只需要成对偏好A优于B。这个差异在真实项目里非常大让标注员给五个回答排顺序和两个回答里选一个前者的标注一致性低、耗时长、费用高。所以我的建议是中小团队、预算有限、数据规模在几万对以内优先DPO只有当你面临的是极其复杂的对齐场景比如多目标权衡、安全约束才需要RLHF的灵活性。有个实操细节值得在面试时主动分享DPO训练时β超参控制对偏好差异的敏感度。β太大会让模型过度追求偏好差异频繁生成重复句式β太小则模型几乎不改变行为。我试过一组对比β从0.1升到0.5时回答长度平均增长12%但多样性指标下降8%。所以这个参数不是随便抄个0.1就完事的要结合你的评估集去调。还要提醒一个容易踩的坑DPO要求偏好数据中“被拒绝回答”必须来自当前模型或非常接近当前模型的分布。如果你用GPT-4生成被拒绝回答再用小模型去DPO效果会非常差。因为模型会拼命往GPT-4风格上靠反而丢失自己的知识表达能力。标准做法是先让模型自己采样多个回答再用GPT-4或人工选出优劣对。这个细节在面试里说出来会让人觉得你真的是做过对齐训练的。3.2 PPL、ROUGE、Benchmark评测指标别只会背定义评测问题是面试官最爱用来压轴的一个领域。因为“模型效果好不好”是所有项目的最终交付标准而你如果只会说“看BLEU、ROUGE、PPL”那说明你连评测的坑都没踩过。先理清这些指标各自的适用范围。PPL困惑度衡量模型对文本的预测概率数值越低说明模型越“自信”但它只刻画语言流畅度不刻画事实正确性。一个模型可能PPL很低但它每句话都是语法通顺的胡说八道。ROUGE和BLEU都是基于n-gram重叠的指标适合摘要、翻译这类有固定参考答案的任务但对开放域问答完全无效——两个意思一致但措辞不同的回答ROUGE可能打0分。Benchmark则是用标准化数据集衡量模型在特定任务上的表现比如MMLU测知识广度、GSM8K测数学推理、HumanEval测代码生成。实战中真正的第一条原则永远不要只用一个指标。我做过一个客服意图识别模型ROUGE分数很高但线上使用时用户根本不会按标准句式提问。后来我加了人工抽测发现模型对“退钱”和“退款”这类同义表达识别能力极弱。ROUGE只看字面重叠无法捕捉语义等价。从此我们组的评测体系固定为“自动指标规则校验人工抽测”三层缺一不可。第二条原则评测集必须贴近真实分布。很多团队贪方便直接跑MMLU、C-Eval这些公开benchmark分数出来挺好看上线后效果却稀烂。原因就是公开benchmark和你的业务场景分布不一致。正确做法是先洗一批线上真实请求按意图分层抽样配上人工标注的标准答复再混合少量公开benchmark组成一个“业务通用”混合评测集。比例我常用7:3业务7通用3。还有个小技巧评测时一定要记录逐样本结果不要只记平均分。平均分容易被极端样本拉高或拉低。我之前优化一版模型整体PPL下降了0.5看起来很漂亮结果按类别一拆发现所有提升都来自高频类别低频类别的效果反而下降了。这种问题只看平均分根本发现不了。面试聊到这里的时候你可以把这个案例讲出来比背指标定义有冲击力得多。4. 智能体与工程可靠性问题——这两问决定你能走多远4.1 Agent的容错控制怎么设计才不会失控现在面试越来越爱问Agent因为大模型应用已经从前期的聊天机器人转向了能自己规划、调用工具、执行任务的智能体。热门搜索词里就有“智能体自主容错控制”这确实是构建可靠AI系统绕不开的工程难题。先说清楚为什么Agent容易失控。模型在单轮对话里表现好不代表它能在多轮自回归中保持稳定。Agent的基本模式是ReAct模型自己“思考”下一步然后“执行”一个工具调用观察结果再“思考”。这个循环每跑一轮就多一次出错的机会而且错误会累积放大。第一轮决策偏了后续所有步骤都基于错误前提越滚越偏。工程上怎么控制最核心的手段是加约束层而不是指望模型自觉。我的做法是把Agent流程做成“有限状态机”而不是完全自由规划定义好状态集合比如初始、信息收集、工具调用、结果验证、最终回答模型只能在当前状态允许的动作里选择不能随意跳转。这相当于给模型画了一条赛道它可以跑得快但不能下道。第二个手段是超时和轮次上限。Agent里最常见的问题是进入死循环模型反复调用同一个工具拿不到新信息。我的项目里设置了两个硬指标单工具调用超时15秒整轮Agent循环最多8次。超过后强制转入“兜底回答”分支告诉用户“当前无法完成该操作”而不是让模型无限转圈。下线时计数器归零发现有一类问题反复超时就说明工具接口或提示词需要优化。第三个手段是输出校验。每次工具调用的结果不能直接回到模型上下文要先过一层规则校验过滤掉空结果、异常报错、超大文本。我踩过一次很深的坑一个搜索工具返回了10万字的内容Agent把这10万字全部纳入上下文直接把上下文窗口撑爆整个会话崩溃。后来的方案是把工具返回内容截断到5000字符以内同时保留摘要信息模型只需要关注关键部分。面试时被问“你如何防止Agent幻觉”别只说“用RAG”这种标准答案。你可以拆解成三层第一层是工具返回数据的数据溯源每条返回带来源ID回答时要求模型引用来源第二层是自一致性检查让模型在回答前先“复述一遍关键数据”确保上下文里的信息被正确理解第三层是置信度判断当模型自身概率偏低时主动输出“不确定”而不是强行给结论。这三层结合才算一个完整的容错设计。4.2 Function Calling与Tool Use从Demo到生产环境的距离最后一个高频问题是Function Calling。在面试中问这个基本就是为了分辨你是“调过API的选手”还是“做过生产级系统的工程师”。Function Calling的原理并不复杂模型不是直接生成“调用某个函数”的指令而是输出一段结构化JSON里面包含函数名和参数。然后你的代码层解析这段JSON执行对应的函数。整个过程看起来简单但生产环境的坑一个比一个深。第一个坑是参数校验。模型生成的JSON字段名和类型可能跟你的函数签名不一致。比如你的函数接收“keyword”参数模型输出的是“query”。这种情况在GPT-3.5时代很常见现在的模型好了很多但仍不能完全信任。我在生产环境里加了JSON Schema校验层字段名不符、类型错误、必要参数缺失的调用直接驳回让模型重新生成。实测下来调用成功率从92%提到了99.2%。第二个坑是并发和依赖。一个真实业务场景Agent可能需要先查天气再根据天气决定是否调用“订机票”函数这两个调用之间有依赖关系。如果你的工具执行层是纯异步并行执行就可能出现“机票订好了却发现天气是台风天”的尴尬。我的做法是为有依赖关系的工具建立一个DAG有向无环图执行器每轮Agent循环生成一个或多个候选调用执行器先检查前置条件满足才执行不满足就暂存等待。这个方案上线后复杂任务的完成率提高了18%。第三个坑是错误反馈。很多人的Function Calling失败后就直接返回“调用失败”给模型模型接到这个信息后容易胡言乱语。正确做法是把异常信息结构化后回传告诉模型“调用失败原因是参数missing请检查”并附上重试建议。这相当于把调试环境交给模型让它能自我修正。我在实践中发现模型能基于错误信息自己调整参数重试重试成功率约70%。面试时如果能再补充一个细节会特别加分Function Calling的系统提示词里应该把工具描述写得像“API文档里的简介”而不是“教科书里的定义”。描述要包含这个工具在什么场景下用、参数的含义和格式、常见的坑。模型读提示词和你读API文档是一样的描述越贴近真实使用方式越容易选对工具。我曾经对比过两组提示词一组用技术文档风格另一组用场景化描述后者工具选择准确率高出11个百分点。最后一个小技巧Function Calling的输出不要直接给用户看。用户在界面上只需要看到业务结果——比如“已帮你预订了明天下午3点的会议室”而不是看到模型的JSON输出。前端呈现与后端执行解耦是智能体工程化的基础设计逻辑。面试时说到这一层说明你真的想过用户体验而不只是跑通demo。我在实际面试候选人的过程中发现一个规律能把这8个问题回答到“有工程细节、有踩坑数据、有取舍逻辑”程度的人入职后基本都能在两周内上手项目。反而是那种知识面广但每块都是背定义的人遇到线上问题就抓瞎。所以准备面试与其花时间背诵几十个术语不如亲手部署一次模型、微调一个数据集、把一个Agent跑出问题再修好。这种真实经验带来的手感是任何面试攻略都给不了你的。