基于快手2025-2026年真实面经整理覆盖Transformer、RLHF/DPO/GRPO、SFT、RAG、推理优化、Agent训练、模型评估等核心领域。每题含口语化答案、代码示例和扩展提示面试前背熟这些就够了。题目1Transformer的Self-Attention为什么要除以根号d_k题目描述Transformer中的Scaled Dot-Product Attention计算公式为 Attention(Q,K,V) softmax(QK^T / √d_k)V为什么要除以√d_k答案要点这个问题其实是在问为什么不能让点积直接进softmax非要除个东西核心原因是防止softmax进入梯度饱和区。当d_k比较大的时候比如512Q和K的每个维度都是独立同分布、均值为0、方差为1的随机变量那它们的点积Q·K Σq_i·k_i的方差就是d_k。也就是说d_k越大点积的绝对值就越大分布越分散。大值经过softmax后会让概率分布极端集中在少数位置上接近one-hot梯度趋近于0模型学不动。除以√d_k就把方差重新拉到1附近softmax的输入落在梯度敏感的区域里训练更稳定。举个例子假设d_k512点积值大约在±25左右波动而除完√512≈22.6之后值落到±1附近softmax输出不再是极端分布。import numpy as np def scaled_dot_product(Q, K): d_k Q.shape[-1] # 方差随d_k增大而增大 scores np.dot(Q, K.T) print(fd_k{d_k}, scores variance ≈ {np.var(scores):.2f}) # 缩放后方差回到1附近 scaled scores / np.sqrt(d_k) print(fAfter scaling, variance ≈ {np.var(scaled):.2f}) return scaled扩展提示除了数值稳定性这个缩放还有一个解释保持概率分布的温度适中。实际上temperature参数也是调整这个softmax的温度底层原理是相通的。面试官可能追问Pre-Norm和Post-Norm的区别本质也是梯度稳定性的问题。题目2RLHF的训练流程是什么PPO在LLM训练中为什么比传统Policy Gradient更稳定题目描述RLHF基于人类反馈的强化学习是让大模型对齐人类偏好的核心方法。请简述RLHF的三个阶段并解释为什么用PPO而不是传统策略梯度。答案要点RLHF分为三个核心阶段第一阶段SFT监督微调——先收集高质量的指令数据对预训练模型做有监督微调让模型学会听懂人话具备初步的指令跟随能力。第二阶段训练Reward Model——收集人类偏好数据让标注员对模型输出排序ABC训练一个奖励模型来预测人类偏好。这个RM本质上是一个打分器给模型的输出打一个人类喜欢程度的分数。第三阶段PPO强化学习——冻结RM用PPO算法优化策略模型就是你正在训练的LLM让模型生成RM打高分的内容同时加一个KL散度惩罚防止模型跑偏得太远。那为什么用PPO而不是传统的Policy Gradient呢传统Policy Gradient每一步都需要新采一条完整轨迹方差大得惊人。PPO引入了重要性采样和clip裁剪先把旧策略拿出来采样一批数据然后用这批数据多次更新新策略每次更新如果新旧策略差异太大就用clip剪掉不让步子迈太大。# PPO的clip损失核心逻辑简化版 def ppo_clip_loss(prob_ratio, advantage, epsilon0.2): # prob_ratio πθ(a|s) / πold(a|s) # advantage 是优势函数表示这个动作比平均好多少 clipped torch.clamp(prob_ratio, 1-epsilon, 1epsilon) * advantage return -torch.min(prob_ratio * advantage, clipped).mean() # 取min的作用如果advantage0好动作概率提升不要太多 # 如果advantage0差动作概率降低不要太多扩展提示面试时一定要说清楚为什么RLHF里要加KL penalty——因为奖励模型不是完美的模型如果只追求高分容易过拟合到奖励模型上产生一些说不通但分数很高的胡话Reward Hacking。KL penalty就是让模型别离SFT版本太远兼顾了对齐和保留生成能力。题目3DPO和RLHF的核心区别是什么为什么DPO可以不需要Reward Model题目描述DPODirect Preference Optimization是近年来非常流行的对齐方法。它是怎么绕过Reward Model直接优化偏好的什么时候DPO效果不如RLHF答案要点DPO最妙的地方在于它发现RLHF里那个奖励函数其实可以隐式地表示为参考模型和目标模型的对数概率差。所以你根本不需要单独训一个Reward Model直接用偏好对chosen和rejected回答就能优化。核心公式是L_DPO -E[log σ(β * (log πθ(yw|x)/πref(yw|x) - log πθ(yl|x)/πref(yl|x)))]其中yw是偏好回答chosenyl是非偏好回答rejectedβ控制优化强度πref是SFT后冻结的参考模型。它的意思就是让当前模型相比于参考模型对chosen回答的生成概率比对rejected回答的生成概率更高。不需要奖励模型不需要PPO只需要成对的偏好数据。但DPO效果不如RLHF的场景也很明确当偏好数据质量不高时DPO直接优化概率差容易被噪声pair带偏当奖励信号来自可自动验证的任务如数学、代码时RLHF可以给每条回复独立打分DPO依赖成对比较后者浪费了绝对分数信息DPO的β是全局固定而RLHF的RM可以给不同输入不同量级的奖励更灵活# DPO loss的PyTorch实现简化版 def dpo_loss(chosen_logps, rejected_logps, ref_chosen_logps, ref_rejected_logps, beta0.1): # chosen_logps: 当前模型对偏好回答的log概率 # ref_chosen_logps: 参考模型对偏好回答的log概率 log_ratio_chosen chosen_logps - ref_chosen_logps # 当前模型相对参考的提升 log_ratio_rejected rejected_logps - ref_rejected_logps # 关键chosen相对于rejected的优势 logits beta * (log_ratio_chosen - log_ratio_rejected) loss -F.logsigmoid(logits).mean() return loss扩展提示快手面经里特别爱问DPO的数据来源和质量问题。记住一个关键点DPO的chosen/rejected最好来自上一版checkpoint的采样分布而不是直接用GPT-4的能力去蒸馏否则学到的不是你模型的能力边界。Rejection Sampling拒绝采样就是先让模型自己生成一堆候选然后过滤出好坏样本这样正负样本分布更贴近模型的真实能力。题目4GRPO的原理和DPO有什么区别题目描述GRPOGroup Relative Policy Optimization是DeepSeek-R1等推理模型中广泛使用的强化学习方法。它和DPO的核心区别是什么为什么要做组内归一化答案要点GRPO的思路和DPO完全不同。DPO依赖成对偏好数据chosen vs rejected而GRPO依赖组内相对优势——对同一个问题采样多个回答计算每组回答的reward然后在组内做归一化得到advantage优势分数再更新策略。流程大概是给你同一个prompt模型采样生成K个回答用规则或reward模型给这K个回答打分对这组分数做归一化减去均值除以标准差得到每个回答的advantage用advantage加权更新策略让分数高的回答概率上升分数低的下降为什么做组内归一化因为不同问题的reward标尺不一样。比如数学题有的题简单大家的reward都高有的题难大家都低。如果不做归一化模型只会知道这道题reward高那道题reward低但学不到在同一条题目下哪个答案更好。组内归一化让模型只关注同一问题内的相对好坏。# GRPO的核心组内归一化advantage def compute_group_advantage(rewards): # rewards: [batch_size, num_samples] 同一个prompt的多个回答 mean rewards.mean(dim-1, keepdimTrue) # 组内均值 std rewards.std(dim-1, keepdimTrue) 1e-8 # 组内标准差 advantages (rewards - mean) / std # 归一化 return advantagesDPO和GRPO的适用场景总结DPO工程更轻适合已有偏好对数据的场景如客服对话GRPO更适合可自动验证的任务数学、代码、推理因为reward可以自动计算。扩展提示快手的一面和二面都密集考察了DPO和GRPO的对比。有个容易被忽略的点DPO的关键是pair质量GRPO的关键是reward设计和采样质量。实际项目中常把两者结合——先DPO稳偏好再用GRPO在可验证任务上继续提升。题目5SFT后的模型怎么评估应该用什么数据集题目描述做完了SFT监督微调怎么评估模型微调得好不好该看哪些benchmark和指标答案要点这里有个坑不要只用GPT-4去做评测。GPT-4打分会引入额外偏差而且你并不知道它哪里判对了哪里判错了。更好的做法是多维度、多数据集的体系化评估。常用的评估维度分为几类通用能力——MMLU知识广度、C-Eval中文知识、GSM8K数学推理、BBHBig-Bench Hard复杂推理、HumanEval/MBPP代码能力。这些是行业标准benchmark面试官大概率会问。业务对齐能力——这是快手最看重的。你微调的模型用在什么业务场景就要定制对应评测集。比如做电商客服就看拒答准确率、意图召回率、槽位填充正确率、回复合规率。安全和稳定性——对抗样本测试、拒绝对比、格式一致性、幻觉率。不要迷信单个指标比如MMLU涨了0.5%但GSM8K掉了3%说明微调数据有偏。综合看win rate、指标变化、badcase分析。# 一个简洁的评测流程示例 def evaluate_model(model, test_cases, metrics[accuracy, fluency, safety]): results {} for split_name, cases in test_cases.items(): # 计算基础指标 acc compute_accuracy(model, cases) # 采样分析人工check samples random.sample(cases, min(100, len(cases))) win_rate human_gold_compare(model, samples) results[split_name] {acc: acc, win_rate: win_rate} return results还有一个要点SFT的评测集一定要和训练数据严格分离而且最好包含badcase分桶——即把线上不好的case按类型归类检索错、提示词错、模型能力不足、工具返回错分别看SFT在哪类上修好了、哪类上没修好。扩展提示快手面经里提到不要用GPT-4做评测的一个核心原因是你微调的模型可能在某些维度超过了GPT-4比如特定业务的domain knowledge这时候GPT-4的评分就不可靠。建议用人工规则的混合评估方案。题目6大模型推理加速有哪些实用方法如何减少推理延迟题目描述大模型部署时推理速度和显存占用是核心瓶颈。请介绍常用的推理加速方法包括KV Cache、量化、Continuous Batching等。答案要点大模型推理优化的技术栈很丰富按作用层面来分1. KV Cache键值缓存——这是Transformer自回归生成中最基础的优化。每次生成下一个token时之前的token的Key和Value矩阵不需要重新算缓存起来直接用就行。时间换空间显存占用增大但推理速度显著加快。2. 量化——将模型权重从FP16降到INT8或INT4用少量精度损失换取推理速度翻倍。主流方案有GPTQ后训练量化、AWQ激活感知量化、和LLM.int8()。量化后模型体积缩小显存占用剧减推理吞吐量大幅提升。3. Continuous Batching持续批处理——传统批处理要等整批都生成完了才释放资源持续批处理则随时有新请求进来就插入到batch里同时可以提前释放已经生成完的请求。vLLM就是基于这个思想做的吞吐量能提升数倍。4. FlashAttention——通过tiling分块减少对HBM高带宽内存的读写次数利用更快的SRAM做计算。不减少FLOPs但大幅降低了显存访问开销。5. Speculative Decoding推测解码——用一个小模型先快速生成一批候选token大模型只做一次验证。如果小模型猜对了就直接接受猜错了大模型纠正。在带宽受限的场景下效果显著。# vLLM推理示例简化 from vllm import LLM, SamplingParams llm LLM(modelqwen/Qwen2.5-7B, gpu_memory_utilization0.9, # 显存利用率 max_model_len4096) # 最大上下文长度 # 设置连续批处理vLLM自动做 sampling_params SamplingParams( temperature0.7, top_p0.9, max_tokens512 ) outputs llm.generate(prompts, sampling_params)扩展提示快手面经里特别问过LLM落地部署的实用trick。面试官更看重你区分什么时候该优化模型、什么时候该优化数据。很多业务问题是知识更新、格式不稳、证据引用错这些更适合通过RAG、结构化输出、后校验来解决而不是一上来就做模型量化或者蒸馏。题目7什么是多轮对话LLM它和普通文本生成模型的区别是什么题目描述快手面试真题。多轮对话LLM的核心挑战是什么如何处理超长上下文答案要点多轮对话LLM不是简单地做next token prediction它要在多轮交互里持续维护用户意图、对话状态、约束条件和安全边界。普通生成模型更关注单次输入到输出的流畅性对话模型还要考虑上下文一致性——用户前面说过的内容不能前后矛盾角色一致性——不要从客服突然变成闲聊拒答策略——什么时候该说我不知道什么时候该引导用户槽位维护——用户说换个红色的你得记得之前选了T恤不是裤子工具调用——查订单、查库存、更新物流核心难点在于历史信息并不等价于有效状态。用户前面说过的内容有的仍然有效比如我买的是XX型号有的已经被修正哦不是是YY型号有的是噪声。对话LLM必须学会根据当前轮次重新解释历史而不是把所有历史机械拼接。处理超长上下文的工程实践def process_long_context(dialog_turns, max_context_len4096): # 不要把全部历史都塞进去 # 而是维护一个结构化的对话状态 state { intent: None, # 当前用户意图 confirmed_slots: {}, # 已确认的信息 open_questions: [], # 未解决的问题 conflicts: [], # 矛盾信息 recent_turns: dialog_turns[-4:] # 只保留最近4轮原文 } # 早期内容做摘要或结构化存储 for role, text in dialog_turns[:-4]: if 尺寸 in text or 颜色 in text: state[confirmed_slots][product_attr] text if 不对 in text or 不是 in text: state[conflicts].append(text) return build_prompt(state)扩展提示这道题快手二面考过。面试官想听的不是用滑动窗口截断这种常规操作而是让你说出把上下文转成状态和有效上下文密度比长度更重要这个思路。题目8什么是Agentic Training工具返回的内容在训练时要不要mask掉题目描述快手面试真题。Agentic Training的训练流程是什么角色扮演场景中模型的对话历史很长如何处理训练时工具返回的observation要不要参与loss计算答案要点Agentic Training不是只训练模型回答问题而是训练模型在任务中进行规划、调用工具、观察结果、修正策略并最终输出。一条完整的训练轨迹长这样instruction → thought/action → observation → next action → final answer关键点在于让模型学会什么时候调用工具、调用哪个工具、参数怎么填、工具失败时怎么恢复。Agentic Training的难点不在格式而在轨迹质量。如果轨迹里有无效工具调用、重复调用或者错误观察模型会学到很差的策略。关于工具返回要不要mask的问题工具返回的内容本身不是模型要学习生成的而是环境反馈。所以在计算assistant的loss时应该mask掉tool observation。否则模型会被训练去背工具返回而不是学习如何基于工具结果做决策。def compute_agent_loss(logits, labels, attention_mask, tool_token_positions): tool_token_positions: 工具返回内容的位置这些不参与loss计算 loss_fct CrossEntropyLoss(reductionnone) loss loss_fct(logits.view(-1, logits.size(-1)), labels.view(-1)) # 创建mask: 工具返回位置不参与loss loss_mask torch.ones_like(labels, dtypetorch.bool) for pos in tool_token_positions: loss_mask[pos] False loss loss.view(labels.shape) * loss_mask return loss.sum() / loss_mask.sum()更常见的做法是用户输入、工具返回作为上下文参与attention模型能看到但不参与loss计算assistant的action、参数和final answer参与loss。扩展提示快手二面问了这道题面试官关心的深层问题是——你是否理解训练目标的设计原则。mask本身不是目的目的是只让模型学它应该学的东西。对话history、tool observation都是输入不是输出。题目9大模型RAG系统中文档应该如何切分embedding和检索策略怎么选题目描述RAGRetrieval-Augmented Generation是大模型落地最常用的框架之一。文档切分策略和检索策略直接决定了RAG的效果请分享你的最佳实践。答案要点文档类RAG最怕的是把一个完整的语义单元切碎。固定长度切分虽然简单但会把标题、定义、表格、条款和上下文关系切断导致召回片段看起来相关但证据不完整。切分策略的最佳实践按文档结构切分——利用标题层级、段落边界、条款编号、表格结构等自然边界语义切分——用embedding检测语义断裂点而不是机械按token数切重叠切分——片段之间保留一定的重叠内容避免边界信息丢失元数据附加——每个切分片段带上所属文档标题、章节编号、层级信息检索策略的选择Dense Retrieval稠密检索——用embedding模型做向量检索适合语义匹配。但要注意embedding模型和LLM的语言分布差异Sparse Retrieval稀疏检索——基于BM25/关键词匹配适合专有名词、代码、数字场景混合检索——两者结合再通过reranker排序。这是工业界最稳定的方案# 基于文档结构切分的示例 def semantic_chunking(doc): chunks [] for section in doc.sections: text section.title \n section.content # 保留元数据 metadata { source: doc.name, section: section.title, level: section.heading_level, } chunks.append({text: text, metadata: metadata}) return chunks # 检索时使用混合策略 def hybrid_retrieve(query, chunks, alpha0.5): dense_scores dense_retrieve(query, chunks) # 向量检索 sparse_scores bm25_retrieve(query, chunks) # 多种关键词检索 # 混合加权 combined alpha * dense_scores (1-alpha) * sparse_scores top_k combined.argsort()[-5:][::-1] return [chunks[i] for i in top_k]扩展提示快手一面问过为什么文档类RAG不一定要按固定长度分段。核心原因是业务场景下文档通常有天然结构合同条款、药品说明书、操作手册按结构切不仅召回质量更高而且返回给LLM的上下文本身就更完整。题目10大模型训练/推理时显存不够怎么办模型并行与显存优化题目描述从单卡跑不动7B模型到多卡训练70B模型有哪些显存优化的方法请从模型并行、ZeRO优化器、梯度检查点等角度完整介绍。答案要点显存优化是一个体系化的问题不是靠某一招解决的。我们先区分推理和训练两种场景推理场景的显存优化量化FP16→INT8/INT4模型体积直接减半或减到四分之一KV Cache优化用Multi-Query Attention或Grouped Query Attention减少KV head数量Memory Offload显存不够时可以部分挪到CPU内存训练/微调场景的显存占用训练占显存的大头不只是模型参数还有optimizer states优化器状态、gradients梯度、activations激活值。Adam优化器本身就占双倍参数空间一阶动量和二阶动量。主要的优化方法ZeRO优化器零冗余优化器——三阶段递进优化- Stage 1优化器状态分片优化器状态分布到各卡- Stage 2加上梯度分片- Stage 3加上参数分片每卡只存1/N的参数Gradient Checkpointing梯度检查点——前向传播时不保存所有中间激活值反向传播时重新计算。时间换空间用约20%的额外计算换回50-70%的显存。LoRA/QLoRA低秩适应微调——冻结原模型参数只训练少量低秩矩阵。QLoRA结合4-bit量化可以在单卡3090上微调7B-13B模型。混合精度训练FP16/BF16——用半精度存储大部分张量全精度只在需要时使用。# DeepSpeed ZeRO配置示例 deepspeed_config { zero_optimization: { stage: 2, # ZeRO Stage 2 offload_optimizer: { device: cpu, # 优化器状态卸载到CPU }, contiguous_gradients: True, }, fp16: { enabled: True, # 混合精度训练 }, gradient_accumulation_steps: 4, # 梯度累积 } # 单卡QLoRA微调7B模型示例 from transformers import AutoModelForCausalLM, BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B, quantization_configbnb_config # 4-bit量化 )扩展提示快手面经中这个问题的考察非常有层次。从简单到深入可能是显存不够→先量化/剪枝→再FSDP/ZeRO→再谈LoRA/QLoRA→最后谈分布式训练的策略选择。面试官想看你是否有系统的显存优化思维而不是只会一两招。总结以上10道题基本覆盖了快手大模型算法工程师面试的核心考点。从面试趋势来看快手非常关注应用的深度理解——不只会背公式还要知道DPO的数据从哪里来、beta参数怎么调、RAG切分为什么不能盲目按长度切。备考建议 重点准备DPO/GRPO细节快手最爱考、对话LLM的工程实践区别于纯研究、以及推理部署的实用trick。手撕代码方面Transformer的FFN手写、滑动窗口类题目出现频率较高。祝你面试顺利早日拿下快手Offer