MiniMax 大模型开发二面

1. 你做过大模型数据处理的话，预训练数据清洗一般怎么做，去重、去噪、质量过滤分别解决什么问题？

预训练数据清洗本质上是在控制“数据量”和“数据质量”之间的平衡。去重主要解决模型反复记忆同一批内容，避免浪费训练 token，也减少 benchmark 污染。去噪主要是过滤乱码、模板页、广告页、低信息密度文本、机器生成垃圾内容，不然模型会学到很差的语言模式。质量过滤更偏向保留高价值内容，比如结构完整、语义通顺、知识密度高、代码块规范或者问答对明确的数据。

实际工程里一般不会只靠一个规则，而是多阶段处理：先做规则清洗，再做语言识别、长度过滤、内容打分，最后再结合 dedup 和采样策略。因为预训练效果很多时候不是“多喂就更强”，而是“喂进去的分布对不对”。

2. 如果训练出来的模型困惑度下降得很正常，但下游任务效果始终起不来，你会优先怀疑数据哪里有问题？

这种情况我第一反应不是模型没学会，而是学偏了。因为 perplexity 更多反映的是语言建模拟合程度，不一定等于任务能力。优先会怀疑几个方向：第一，数据分布和目标任务脱节，比如预训练语料里口水文太多，技术类、高质量 instruction-like 数据太少；第二，数据重复度高，模型只是记住常见模式但泛化弱；第三，清洗不够，噪声掩盖了真正有价值的模式；第四，存在严重的语种或领域配比失衡。

如果是已经能看出“loss 下降但能力没上来”，那就要尽快做切片评测，看不同领域、不同长度、不同任务模板下到底是哪一类数据在拖后腿，而不是只盯着总 loss。

3. 数据去重为什么会影响大模型效果？MinHash、SimHash、精确去重各自适合什么场景？

去重影响效果，是因为重复数据会让模型把大量算力花在重复记忆上，等于训练预算被浪费掉了。而且高重复数据还容易让模型看起来 loss 很好，但泛化不强。

精确去重适合处理完全一样的文本，比如 URL 相同、哈希相同的网页和文档。MinHash 更适合做近似文本去重，尤其是段落级、文档级内容高度相似但不完全一致的情况。SimHash 更偏轻量，适合大规模近似重复检测，但对局部改写、顺序变化比较敏感。实际中通常不会只选一个，而是先做精确去重，再做近似去重，把完全重复和高度重复都尽量压掉。

4. 预训练阶段怎么判断数据污染了评测集？如果 benchmark 被污染，你怎么重新评估模型真实能力？

判断 benchmark 污染，核心是看训练语料和测试集之间有没有高重合，尤其是题目原文、答案模板、标准解析这类高风险内容。一般会做 n-gram overlap、近似文本匹配、embedding 检索，有时候也会人工抽检高分异常样本。

如果 benchmark 被污染了，最稳的办法不是继续解释分数，而是换评测。可以重新构造一个更干净的 held-out 集，或者做时间切分，确保测试数据晚于训练语料。再进一步，最好加人工评测和真实业务集，因为很多公开 benchmark 本来就容易被互联网语料覆盖，单靠公开榜单已经不太能代表真实泛化能力了。

5. tokenizer 会怎么影响大模型训练和推理？BPE、SentencePiece、Unigram 这些方案你怎么理解？

tokenizer 会直接影响序列长度、词片分布、训练稳定性和推理成本。分得太碎，序列会变长，attention 开销上升；分得太粗，罕见词泛化会变差。它不是一个前处理小细节，而是会长期影响模型的表示能力。

BPE 的思路是从字符开始不断合并高频子串，简单高效，所以工程上用得很多。SentencePiece 更像一个完整框架，支持直接从原始文本训练，不依赖空格切词，对多语种很方便。Unigram 则是用概率模型去选子词集合，保留多种切分可能，理论上更灵活。大模型场景里，往往更关心 tokenizer 是否适配目标语种、代码、数字、特殊符号，而不是只看哪种算法名字更高级。

6. 中英文混合场景下，分词粒度不合适会带来哪些训练问题？你会怎么优化 tokenizer 设计？

中英文混合如果分词设计不好，常见问题就是英文词被切得过碎、中文数字和单位混在一起、代码标识符切分不稳定，最终会让模型对术语、变量名、公式、路径这些内容建模很差。尤其技术场景里，一个 package 名、函数名、错误码如果总被切烂，模型就不容易学会精确模式。

优化上，一般会从训练 tokenizer 的语料配比下手，让中英混合、代码、日志、数学表达式都充分参与词表学习。然后检查常见领域 token 的切分质量，必要时对特殊符号、URL、路径、代码标识符做规范化或预切分。词表大小也要平衡，不能一味做大。

7. 为什么有些模型扩到更大参数后收益开始变小？你怎么理解 scaling law 在工程上的指导意义？

参数变大但收益变小，说明已经不只是模型规模在限制性能了，数据质量、训练 token 数、优化策略、架构效率都可能成了瓶颈。也就是说，模型不是越大越好，而是要和数据量、算力预算、训练时长匹配。

scaling law 的工程意义不在于给一个绝对公式，而在于告诉你：不同资源约束下，最优解并不是永远堆参数。有时候补数据更有效，有时候延长训练更划算，有时候反而应该改架构或改分布。面试里如果说到这里，面试官通常会觉得你不是只会背“参数越大越强”。

8. 训练大模型时，学习率、warmup、batch size、gradient clipping 这几个超参，哪个最容易把训练搞崩，为什么？

最容易把训练搞崩的一般还是学习率和 warmup。因为大模型训练前期本来就很脆弱，如果学习率过大或者 warmup 太短，梯度更新会非常激进，很容易出现 loss spike、nan、参数震荡。batch size 更像是影响稳定性和泛化的平衡项，不一定一下就崩。gradient clipping 则更像保险丝，设得合理通常是帮忙兜底，不是主要灾源。

所以线上经验通常是：先把学习率曲线做稳，再看 batch 和 clipping。很多训练事故追根到底都是 scheduler 配置不合理。

9. 如果训练过程中出现 loss spike，你会怎么定位是数据问题、数值问题、优化器问题还是分布式通信问题？

先看 spike 是偶发还是持续。如果是偶发且和特定 batch 强相关，优先怀疑脏数据，比如超长样本、乱码、异常 token 分布或者损坏样本。若是逐步恶化，则要看数值稳定性，比如混精溢出、梯度爆炸、loss scaling 问题。再看 optimizer 状态是否异常，比如学习率切换点、weight decay 配置、恢复训练后状态不一致。

如果怀疑分布式通信，就看不同 rank 的 loss 是否突然分叉、梯度 norm 是否不一致、all-reduce 是否报错。真正定位时，最有效的不是猜，而是把触发 batch 抓出来复现，同时记录梯度范数、激活统计、optimizer step 信息。