一篇文章讲清楚 Kimi K1.5 到 K3 的大模型数据处理技术

Liao Jiayi Liao Jiayi

最近几天深入阅读了 Kimi K1.5/K2/K3 的 Tech Report，里面涉及到不少关于 LLM Data 的数据处理技术，做个总结。

主要来自 Kimi Tech Report。K1.5 做的会比较详细一些，K2 和 K3 更多也是从 K1.5 的 Data 上拓展而来。（内容太多，总结了 3 天，并且也把 Kimi 参考的开源项目思路也过了一遍）

Pretraining Data

K1.5

English and Chinese Textual Data:

  1. Rule-based filtering：基于规则把各种数据给滤掉
  2. FastText-based classification: 专门 train 了 FastText model 来做分类和内容质量（FastText 是 CPU 推理，主要做粗筛，介于规则和 LLM 之间，是一个轻量的监督分类模型，最后 output 是 各个标签的概率，这里重新训练，把高/低质量训进 FastText，还是利用他的分类能力），这里也是参考了 DataComp-LM（同样是训练 FastText，里面介绍了相关的方法论）
  3. Embedding-based similarity analysis: 用 document embedding 来做 doc-level similarity，删除掉相似的 doc（参考 BGE-M3, https://huggingface.co/BAAI/bge-m3）
    • BGE-M3 是 BAAI 开源的文本 embedding model，M3 表示 Multi-Linguality：多语言，支持 100 多种语言及跨语言检索。Multi-Functionality：同时支持 dense、sparse、multi-vector 三种检索方式。Multi-Granularity：支持句子、段落和长文档，最长 8192 tokens。这里和 MinHashLSH(n-gram 做多个 hash 取最小值，然后 band 分成 N 组做去重) 相比，会更好一点，因为覆盖了语义重复的问题。
  4. LLM-based quality assessment: （可以参考 FineWeb）用 LLM 来给 doc 在 coherence,informativeness,potential educational value 等多个层面打分；
    • FineWeb 也是蒸馏 Lllma-3-70B-Instruct 打分(0~5) 的模式，蒸馏出一个小模型来打分，主要是连贯性、信息量、潜在教育价值；(有个开源模型：HuggingFaceFW/fineweb-edu-classifier)

Code Data

  1. 纯代码处理（参考 BigCode，涉及规则清洗、垃圾数据删除等）；这里参考 BigCode 的 Pipeline，另外做了 “编程语言重采样”，保证语言均衡；
    1. 编程语言识别（用了 go-enry, https://github.com/go-enry/go-enry ），重点保留 32 种 language
    2. 规则清洗（一系列的过滤规则，如一行非常非常长等）
    3. 近重复代码删除（MinHashLSH, 5-gram 和 Jaccard 0.7 阈值）
    4. 安全、隐私和 benchmark 去污染
  2. Text-Code Interleave 数据：主要指文字和代码交替出现的情况，常见如“技术文档和教程”，用 embedding retrieval 的方式来召回高质量样本，同时保证多样性；（说明需要常态化维护一个向量数据库），这里还有一个作用是给算法团队提供一个训练数据的补充，决定如何召回一些数据；

Math & Reasoning Data （处理方法参考 OpenWebMath）

OpenWebMath(https://huggingface.co/datasets/open-web-math/open-web-math) 的处理方法：

  1. 高召回数学粗筛，crawl 2000 亿个 HTML，简单的数学符合判断入库
  2. 保留公式的 HTML 解析
  3. Filter: FastText 确认是英文，MathScore(用 LaTeX 正样本和随机非数学网页负样本训的，开源 FastText MathScore, https://huggingface.co/kenhktsui/math-fasttext-classifier ) 判断是否为数学内容，KenLM（开源ProofPile 上训练的 KenLM，约 1.53 GB） 判断文本是否高质量
  4. 用 text-dedup 的 SimHash 实现，以 0.7 为阈值删除网页近重复内容

Kimi 的主要处理思想：

  1. 用 FastText Model 移除掉无关信息
  2. 用 fine-tune 的 model 清洗剩余数据，只留高质量数据

Knowledge Data

  1. 专用的 academic OCR(Kimi 内部模型），针对公式和特殊符号优化
  2. 内部 LM 多维标注：标注 OCR 质量、教育价值、文档类型等(可以参考 FineWeb)
  3. OCR 阈值过滤：滤掉常见的 OCR 错误
  4. 教育价值排序：优先高教学价值
  5. 文档类型做隔离实验： 测量不同子集对知识获取的贡献，对高价值子集 upsample，同时保留其他类型以维持泛化。

Caption Data

  • 开源中英文 image-text，如 LAION-5B（CLIP 判断 similarity，500 亿候选对洗出来 60 亿对）、DataComp（一系列过滤规则，其中有一个图像分布过滤，是用 FAISS 做了 10w 个 cluster 然后找贴近 ImageNet 的高质量分布数据）：严控合成 caption 比例以降低幻觉；去重（hash/emb 去重）；保证图文相关；变化分辨率；

Image-Text interleaving data

  • MMC4(不相信网页的 DOM，直接调 CLIP 算相似度来匹配出图片-句子数据集）、OBELICS(保留DOM顺序，清洗出文本-图片）、教材、网页、tutorial，加合成数据：标准过滤/去重之外，对图文重新排序，保证原始知识顺序（ 这里用 LLM 改写来保证顺序）；支持多图与长上下文
  • 这里的 Image-Text 交错数据，一定程度上恢复了 Caption Data 对 text 能力的影响；（比如 cat-图片 这种 caption data 是损伤了语言能力）

OCR Data

  • 开源+内部，多语言、密集排版、网页、手写、图表、几何图、Mermaid、场景文字：旋转、形变、颜色、噪声增强；参考 OCR2.0 扩展到广义视觉文字理解(OCR2.0 相比文字识别增加了公式、乐谱、图形等)；

Multi-Modal Knowledge Data

  • 教材、论文、几何、互联网图文：taxonomy 平衡；layout parser + OCR；额外抽取图中纯文本，避免只学 OCR shortcut（指的是直接从图里找答案）;
  • 这里有个问题是，如何让图文保序？
    1. 利用 DOM 结构
    2. 图文 emb 匹配
    3. 图注和引用
    4. 排序后做规则检查，要严格禁止序列的内部 shuffle；

General QA Data

  • grounding、表格/图表 QA(（这里大量使用开源数据集和内部 QA）)、Web agent、一般 QA：scoring model(难度等信息) + 人工细分类(人为设计 taxonomy)，平衡难度和多样性;
  • 后续这些 QA 数据也在 Kimi-VL 中提到，
    • Cooldown：将学术视觉/视觉语言数据过滤、改写为 QA；QA 只占较低比例，避免模型过拟合固定的问答模式。
    • Instruction tuning：人工构建 seed data，训练 seed model；对多样 prompts 生成多个回答，再由人工排序并润色最优回答。
    • 可验证推理任务：使用规则或模型 verifier 做 rejection sampling，扩充 SFT 数据。

K2

K2 的主题是 Improving Token Utility with Rephrasing，在大规模的数据被学习之后，高质量数据变成了下一步要重点挖掘的地方，其中最重要的就是以 high-quality data 为种子去合成更多的高质量数据。

Knowledge Data Rephrasing

  • Style and Perspective-Diverse Prompting: 通过各种 prompt 手段来重写；（Inspired by WRAP，一种 prompt 的 best-practice）
  • Chunk-wise autogressive generation: 对于长文本，分成多个 chunk进行重写，最后拼接；
  • Fidelity verification: 比较原文和 rephrasing 之后的内容一致性；如何比较的？
    • LLM-as-a-judge(Kimi 可能用的是这个)
    • 现成的开源 model(如 MiniCheck、AlignScore、DeBERTa-v3-large-mnli)，大致原理都是 doc->claim 的映射，然后用 claim 去调用模型做比较（是否一致，是否信息缺失）
    • Embedding similarity，如 BGE-M3 这种

Kimi 这边给出的，关于高质量数据训练多个 epoch 的结论：

  1. 对于高质量数据，只训练一个 epoch 是不够的;
  2. 通过 rephrasing 合成多条数据，会有小量的提升; image

Math Data Rephrasing

参考 SwallowMath 项目:

  1. FineMath-4 + 数学网页
  2. Llama-3.3-70B-Instruct 改写
  3. 过滤、上下文补全、整理推导等(较低的 temperature=0.2 为了让改写相对稳定、忠于原文，减少自由发挥。)
  4. 保存成数学文本

除此之外，Kimi Report 里提到的：

  1. 对高质量数学文档改写成 learning-note 风格，使隐含推导、定义关系和学习结构更显式。
  2. 将其他语言的高质量数学内容翻译为英文，扩大英文数学训练数据的知识覆盖。

K3

K3 关于数据的部分比较少，主要有以下几个关键点：

  • 对于 Long Context 进一步做合成，同时通过排列、拼接多模态文档和子任务，合成需要获取 long context 才能解决的问题，避免模型陷入到对短窗口的 context 的 hack；
  • 明显扩大了 Code 里的 multimodal data，比如 SVG、3D Assets、Game、CAD 等数据；这部分数据是如何获取的？（爬虫以及开源数据集）

注：我发现很多不好弄的数据，淘宝上都能轻松找到。

SFT/RL Data

K1.5 的 CoT 生成（类似 deepseek-r1）: 如何构建 SFT 数据（For RL CoT），这里和 deepseek-r1 的工作是类似的:

  1. 从 RL prompt 里挑一点数据，注重多样性
  2. 精心设计 prompt 引导 model 产出 cot(plan-eval-reflect-explore)
  3. 筛选并验证(reject sampling)
  4. SFT 训进模型里
Solve the following problem carefully.


Your solution should demonstrate:


- Planning: identify a promising strategy before carrying it out.
- Exploration: consider alternative approaches when appropriate.
- Evaluation: check important intermediate claims and calculations.
- Reflection: if an approach produces a contradiction or dead end,
  identify the mistake and revise the approach.
- Verification: independently verify the final result.


Do not assume the answer in advance.
Conclude with a clearly formatted final answer.


Problem:
{question}

K3 的 RL 初始化

  • K3 用前代 Kimi 的 domain-specialized models 合成轨迹，经多阶段验证和 human-in-the-loop annotation；统一序列化为 XTML chat template。覆盖重点从普通指令扩大到长程 agent：自适应推理、精确 tool call、持续执行和错误恢复。

对于其他类型 Data

Vision 数据：

  • real-world data: 包括图像理解、location 理解、感知和简单的多模态推理能力；
  • synthetic data：指定场景的 vision reasoning，如空间理解，几何形状和物体交互；
  • text-rendered data: 把 text document 转成图片，增强 text 在 image 里的理解；

Code verifier 数据

对 Web 编程题缺少测试用例的问题，K1.5 使用 CYaRon：

  1. 基础模型根据题面和 CYaRon 用法生成 50 个测试用例。
  2. 每个测试用例随机运行 10 份 ground-truth submissions。
  3. 至少 7/10 输出一致才认为该 case 有效。
  4. 至少 9/10 submission 通过全部选中 cases，题目才进入 RL 训练集。

Agentic Data(很重要，单独讲)

RL 环境构建

这里要重点看看 K3 里的 Unified White-Box RL Environment。

4.2.1 Unified White-Box RL Environment
Training with a single fixed agent harness can cause a model to overfit to a particular tool schema, system prompt, context
management mechanism, or interaction protocol. To address this, we develop a unified white-box RL environment
that represents an agent harness as a collection of configurable, composable modules, including tool interfaces, system
prompts, context management strategies, skills, memories, subagents, and other components. Composing these modules
through configuration, the environment can instantiate mainstream harnesses such as Kimi Code [57], Claude Code [15],
Codex [20], OpenClaw [87], and Hermes [45], as well as entirely new ones. During RL training, we dynamically construct different harness configurations for different task groups, exposing Kimi K3 to diverse combinations of these
modules rather than the conventions of any single harness. The same abstraction also readily supports RL across various
task domains, providing a scalable foundation for training more general-purpose agents.
  • 底层环境：从 K8s 过渡到 AgentENV（rust 写的），不用 k8s 的原因是因为 agent 可能也需要自建 docker，AgentENV 更加灵活一些；
  • 环境配置：可能是从下面知识图谱，Agent 去发现环境的时候，也会把环境的配置给生成出来，作为 RL 环境构建的重要参考
AgentENV

考虑到大部分公司还在使用 Docker 做 RL 环境，所以详细看了看 AgentENV，以及为什么 Kimi 要自研 VM 来解决 RL Env 的问题。Docker 本身存在的几个问题：

  • 启动开销：容器冷启动秒级，RL 的 Task 都要新环境，快照恢复时间累积起来很长；（AgentENV 变成 ms 级别的启动时间）
  • 空闲浪费：agentic rollout 大部分时间都在等模型，docker 空闲占内存；（AgentENV 可以暂停并且大量超卖资源）
  • fork 语义：如果 RL 要从中间轨迹 fork 出多个状态分叉（如 best-of-n 场景），docker 功能不支持；（AgentENV 支持了 snapshot + fork）

两者可以是互相替代关系，但是底层原理不同：

  • Docker: dockerd/containerd 管理镜像/生命周期/调度，使用 Linux Namespace + Cgroup(约束资源)，共享宿主机内核
  • AgentENV: 编排层(rust) -> Firecracker microVM(KVM) -> 每个 sandbox 都可以有自己的内核（可以理解为完整的 OS）

注：关于 RL Environment 的抽象可以看 primeintellect 的 EnvironmentHub（把 RL Env 都做了统一抽象）里的 wiki-search(https://app.primeintellect.ai/dashboard/environments/primeintellect/wiki-search):

  • tool
  • verifier
  • dataset(很多 RL Environment 自带了 bench，但是可以不用，上游构造数据，只用 env 的 tool 和 verifier 可能就够了)

数据分类

RL 里很重要的是数据分类，会直接控制 RL 的训练方向。

K1.5

只有简单的 tagging system，根据 domain 和 rule-based 规则进行分类，并且在不同类别上的数据进行采样。其中参考了 From Quantity to Quality: Boosting LLM Performance with Self-Guided Data Selection for Instruction Tuning 和 What Makes Good Data for Alignment? A Comprehensive Study of Automatic Data Selection in Instruction Tuning。

K2: 更加注重 Agent 轨迹数据
  1. Tool Repository: 从 Github 收集 3000+ MCP tools，再从知识图谱树的方式，递归到各个子类的 domain，再继续合成 20000+ tools。（引用 WizardLM 的 Evol-Instruct）
    • WizardLM Evol-Instruct: 一种 prompt 的演化方法，WizardLM 原始实验从 Alpaca 的约 52K instructions 出发，执行四轮 evolution。每轮为每条 instruction 等概率选择六种操作之一：五种 depth operator 和一种 breadth operator，最后得到约 250K instructions，再从中采样 70K 训练 WizardLM（可以用来做 tool 的知识图谱了）
  2. Agent diversification： 组合不同 system prompts 与工具集合，生成数千个不同角色/能力的 agents。
  3. Rubric-based tasks： 为每个 agent 生成从简单到复杂的任务，并附成功条件、预期工具模式和评估检查点。
  4. Multi-turn user simulation： LLM 生成人设、沟通风格和偏好，模拟自然多轮用户。
  5. Stateful tool simulator： 工具模拟器维护世界状态；每次调用后更新状态，并注入成功、部分失败、边界条件等受控随机性。
  6. Trajectory filtering： 让 agent 实际完成任务，由 LLM judge 按 rubric 判断，只保留成功轨迹，相当于大规模 rejection sampling。
  7. 真实执行补强： 对 Code/SWE 使用真实代码和开发沙箱、真实单测 pass rate，弥补模拟器 fidelity 不足。

上面流程相关的几个点：

  1. t-SNE: 用来检查收集和合成出来的 tool 是否足够多样、是否覆盖不同功能领域。可能是把 tool 的格式序列化成文本，然后一个 UMap 降维到 2 维空间来观察分布情况（一是分类是否合理，因为 tool 本身就是文本，二是看合成的 tool 是否重复度太高了）
  2. ACEBench 应该给了 kimi 分类树的灵感，ACE 里有 8 个 domain，68 个 sub-domain；

image

K3: 在 K2 的基础上做了知识图谱，以更广泛更深的思路来拓展 Agent 的应用场景
  1. 从预定义粗粒度 seed nodes 开始建立 hierarchical DAG。
    • 总数有多少？从 Report 里看，概念非常细，上千甚至上万都是有可能的
  2. 每个 node 分配 agent，多次 Web search 探索概念。
  3. 新增节点前先在现有图中查等价/相关概念，复用节点并减少重复。
    • 如何判断重复？比如 RoPE 和 Rotary Position Embedding
  4. 边始终由粗概念指向细概念；直到 agent 判断概念足够 atomic 才停止分支扩张。
    • 如何判断足够 atomic?
  5. 按目标领域/任务分布采样不同层级或相关节点组合。
  6. 将节点关键词和祖先上下文组合成 Web query，检索公开真实材料。
  7. synthesis agent 基于材料生成不同任务类型。有 4 个任务类型：
    • Knowledge / Coding / Debugging / Vision / Agentic search

image

可能要问的工程问题？

1. 如何大规模做去重？

一般从成本和性能考虑，两个层面，粗筛和细筛，比如：

  1. 粗筛：MinHashLSH，具体方案：Spark, 借用 object store,
    • 切成 n-gram -> 对 doc 所有 n-gram 做 hash (多个 hash 函数，常见如 128) ，保留 minHash -> 128d 切成多个 band(如 16)，每个 band 算一个固定 hash -> 两个文档有一个 band 相同，就认为有可能重复
  2. 细筛：Embedding 召回，具体方案：Kmeans, Embedding Cluster, Spark,
    • 这里一般的手段是，采样用 Kmeans 算 centroids 然后遍历数据分配到不同的 cluster，再到 cluster 内部进一步做分类和 embedding similarity 计算；（多步算 kmeans 的方法再看一看）
    • 如果有常驻服务，可以直接写到 embedding 集群 + 构建索引，然后调用服务来去重；

这块看了下，如果仔细研究还非常复杂（性能和准确性的 trade-off），要单独写篇 blog 讲一下。

2. 如何控制 Prompt 的难度？

采用一个较小的 SFT Model，rollout 10 次（temperature 设高一点），用 pass rate 来判断难度。

3. 如何避免 reward hacking（通过不合理的 reasoning 产生了正确答案）？

  1. 排除容易蒙对的答案，比如选择题，true/false 等；
  2. 没有 CoT 的情况下让模型猜答案，N=8 能过滤掉 easy-to-hack 的 prompt； 注：实际上需要有更好的手段来检测 reasoning 是否合理；

关于 reward hacking 的问题：

  • K2: 主要是增加混合规则验证（1. 软件任务用代码执行 2. 语义理解用 LLM-as-a-judge 3. 没有标准答案的依赖 K2 critic）
    • K2 critic model，主要是用于没有标准答案的分数对比，这里应该是利用开源的 preference dataset 和 human-in-the-loop 的方法训的一个 critic model；几个评价维度可以参考一下：

image

  • K3 主要专注 Agent，所以更多是在 sandbox 里做验证