kimi模型梳理

话题： 聊一下模型训练数据生产产线成熟度， 合营/自营/采购 体量+比例+人员配置 这些信息。 详细提纲如下，提纲内容较多，如果专家只能聊部分的话请专家在提纲内标黄可聊部分

题纲：题纲较多详见文档

TQ：
1. 大模型训练数据生产为例，目前数据自有正式员工、自营/内包团队、BPO、领域专家以及第三方供应商大致分别承担多少，内部自建产线和外部生产的比例大概是什么水平？
2. 如果从“产线成熟度”评价，目前公司整体已经做到什么程度？目前哪些环节已经比较成熟和平台化，哪些环节仍明显依赖人工或项目经理协调？

tq回复：
TQ1

按产出 token 口径：

- 内部正式员工 25‑30%：做规划、规则、平台、质量管控，不做体力标注
- 自营 / 内包 5‑10%：只做高价值 SFT、Agent 精细样本
- BPO 第三方 30‑35%：通用改写、初筛校验，交付后内部二次复核
- 领域专家 5‑10%：垂域命题、正确性评审，不做海量标注
- 外购数据集 20‑25%：语料采购，全部再经过内部清洗加工

产线比例：自建产线 60‑65%（含大量模型合成数据）；外部 BPO + 外购 35‑40%。预训练外购占比更高，微调数据以自建合成为主。

TQ2

整体成熟度：半成熟。预训练数据处理平台化程度高；SFT/Agent/RL 对齐有底座，但核心设计与质量闭环仍高度依赖人，尚未实现全自动数据工厂。

成熟平台化环节：

1. 原始数据入库、清洗、去重、大规模批处理流水线
2. 模型合成数据批量生成与初筛
3. 标注任务管理平台，对接外部 BPO
4. 自动化评测做样本粗过滤

强依赖人工 / 项目经理环节：

1. 新任务的数据 schema、标注标准定义
2. 高垂域样本事实正确性终审，自动化无法杜绝幻觉漏判
3. BPO 规范对齐、bad‑case 复盘迭代
4. RL 奖励任务集构造
5. 模型 bad‑case 反向的数据挖掘闭环

履历：
专家2024年1月至今，任职于北京月之暗面科技有限公司，担任研发经理，负责公司大语言模型训练与工程化落地的技术工作，参与模型架构设计、分布式训练框架优化及推理服务性能调优等核心环节。熟悉大规模预训练流程，在长文本处理效率提升与计算资源利用率优化方面积累了较多工程经验。参与模型效果评估体系建设，跟进训练数据质量把控与模型迭代验证工作。协调算法团队与工程团队在模型部署过程中的技术对齐，处理线上服务稳定性相关事务。关注模型架构创新与训练效率提升的前沿方向，持续跟进混合专家模型、注意力机制优化等新技术在实际业务中的应用评估。参与开源模型版本发布相关的技术准备工作，支持对外技术文档的编写与维护。

访谈背景 专家：月之暗面研发经理，2024‑01 至今，负责大模型训练工程、评估体系、训练数据质量把控； ⚠️重要提示：下文带【推演预估】的数字为基于行业对标、业务体量的外部研究推演，仅用于 VC 尽调内部推演，非企业官方真实披露数据，不可对外作为事实引用；其余定性、比例判断为专家访谈口径。统计口径以 token 产出作为比例基准，包含模型合成数据（归属自建产线）。 前置基准：token 产出占比 内部正式员工 25‑30%；自营 / 内包 5‑10%；BPO 30‑35%；领域专家 5‑10%；外购数据集 20‑25%；自建产线 60‑65%（含合成数据），外部 35‑40%；预训练外购占比更高，微调、RL 数据以自建、合成为主。

1. 数据生产组织用工模式，各主体承担环节

【可聊】 用工模式分为五类：自有正式员工、自营 / 内包团队、BPO 外包、领域专家、第三方数据集供应商；无自营数据子公司、独立标注基地实体；额外重要模式：模型合成数据流水线（归属自建产线，不靠人力标注）。

  1. 自有正式员工（token 产出 25‑30%） 承担：数据源规划、任务设计、数据 Schema 定义、数据工程流水线开发、数据平台开发、合成数据流水线、质量管理体系、Environment/Verifier 框架开发、模型侧数据策略、供应商标准制定、Bad‑case 分析、样本终审；不承担大规模体力标注生产。 覆盖环节：任务设计、质量审核、Environment/Verifier 建设、平台开发、专家管理规则制定。
  2. 自营 / 内包团队（token 产出 5‑10%） 项目制内包人力，无独立法人主体；只承接高价值 SFT、Agent 精细轨迹样本生产、重点样本复审。 覆盖环节：数据生产、质量复审；不做顶层任务设计、平台开发、框架级 Verifier 开发。
  3. BPO 商业流程外包（token 产出 30‑35%） 承接通用改写、普通 SFT 标注、基础事实初筛；输出物必须经过内部二次复核；不承接 Coding、Work‑Agentic 核心生产，最多做简单初筛。 覆盖环节：数据生产、初级质检；不参与任务设计、标准制定、Verifier 开发。
  4. 领域专家（token 产出 5‑10%） 外部签约专家，覆盖代码、数理、科研、法律等垂域；负责命题、参考答案生成、高难度样本正确性评审；不做海量批量标注。 覆盖环节：任务命题、质量审核。
  5. 第三方数据供应商（token 产出 20‑25%） 提供原始预训练语料、授权垂域数据集；采购数据不会直接入训，全部流入内部清洗去重流水线。 覆盖环节：原始数据供给，不参与标注、任务设计。

额外模式：模型合成数据，由内部平台驱动生成，属于自建产线，是 SFT/Agent 数据重要来源，大幅降低人力依赖。

2. 内部正式员工规模、团队职能、汇报、和训练团队分工

【可聊；精确人头涉密，【推演预估】：整体数据中心全职能全职 HC：80‑120 人】 数据相关正式员工归属研发体系下的数据中心，向数据方向负责人汇报；模型训练团队是平行二级单元。

内部职能小组【推演预估 HC 拆分】：

  • 数据工程：原始语料清洗、去重、批处理流水线；20‑25
  • 数据平台 + 合成数据平台开发：20‑25
  • 数据运营 / 项目运营、专家运营：项目排期、供应商对接、任务落地、外部专家准入分发；12‑18
  • 任务设计、模型侧数据策略：SFT、RL、Agent 的 Schema、Prompt 范式设计；根据模型 Bad‑case，定义需要补充的数据类型；10‑15
  • 质量管理：质量 SOP、抽样复审、Bad‑case 汇总；8‑12
  • Environment/Verifier 小组：Agent 任务环境、校验器框架开发；12‑18

【推演预估】其中直接聚焦 Work/Agentic、Coding 方向全职：35‑50 HC，占整个数据中心接近一半。

分工边界：

  • 数据中心：定义需要什么数据，完成生产、校验、输出版本化数据集；
  • 模型训练团队：接收数据集，执行预训练 / SFT/RL 训练，反馈模型效果 Bad‑case 回传给数据团队；双方固定机制对齐迭代。

3. 自营数据生产实体（子公司、标注基地等）

【可聊】 不存在数据子公司、线下标注基地、独立运营中心这类自营法人实体【推演预估】对应实体 HC=0。 内包只是项目制人力外包，不属于独立实体；任务、质量标准、验收全部由内部数据团队直接管控。因此本问题中地域、实体人员规模等细粒度信息不适用。

4. BPO 组织模式、站点、人员结构、管理机制

【可聊；供应商名称、站点人头涉密，【推演预估】整体稳定服务 BPO 折算等效 FTE：120‑180 FTE；Work/Agentic、Coding 相关 BPO 仅做初筛，折算 FTE：5‑10 FTE】 采用多家 BPO 并行合作，无独占大型线下站点，以远程人力为主。

  • BPO 主要承接通用 SFT、文本改写、基础事实初筛；Work/Agentic、Coding 高复杂度任务几乎不交由 BPO 生产，仅参与极少量初筛。
  • 业务标准、任务定义、质量 SOP 由内部数据 & 质量团队输出；采购团队负责商务合同结算；内部设有 Vendor 对接小组【推演预估全职 3‑5 人】，负责产能管理、质量复盘、Bad‑case 对齐；BPO 产出必须内部二次质检。
  • BPO 内部的 Reviewer、Team Lead 只做初级质检，最终质量把关归属我方内部。

5. 领域专家招募渠道、分领域情况、内部负责团队

【可聊；各领域专家绝对数量涉密，【推演预估】总活跃可调用外部专家折算等效 FTE：40‑70 FTE，仅为等效全职，专家多为兼职】 招募渠道组合：第三方专家平台、猎头、高校科研合作、行业顾问、供应商专家池；没有自建独立专家 SaaS 平台。

领域分层定性 +【推演预估等效 FTE】：

  • Coding、SE：15‑22 FTE，可稳定调用专家池相对充足；
  • Math/Science：8‑12 FTE，供给充足；
  • Computer‑Use/Office Work：7‑11 FTE，大量复用 Coding 与办公方向专家；
  • Research/Data‑Science：6‑9 FTE；
  • Finance：3‑5 FTE，合格专家供给稀缺；
  • Legal：2‑4 FTE，供给稀缺；
  • Medical：1‑3 FTE，供给短板，以小批量高质量产出为主。

专家不做海量标注，聚焦命题、任务设计、高难度样本评审。 专家的准入考核 (Qualification)、任务分发、质量管理由内部专家运营小组【推演预估全职 4‑6 人】负责；结算协同采购团队完成。

6. 人员口径互斥性、重复统计风险、workforce 统计口径、稳定 / 峰值人力

【可聊；总人数涉密，【推演预估】去重后等效 FTE 口径】

  1. 口径原则上互斥：正式员工、内包、BPO、签约外部专家、第三方数据集供应商做标签区分统计。
  2. 潜在重叠风险：部分 BPO 供应商会复用自身专家池人员，如果不打标签，会出现 BPO 人力与领域专家统计混淆；内部统计通过唯一 ID 标签规避重复。同一个外部专家可承接多个项目，但专家池做唯一身份管理。
  3. 合理 workforce 统计口径（规避重复计算）： ①内部全职数据正式员工；②项目制内包人力；③BPO 有效产出人力（剔除供应商管理层）；④活跃签约外部领域专家；排除只输出原始语料、不做标注生产的数据集供应商。

【推演预估】

稳定日常总等效 FTE ≈ 260‑405 峰值（项目冲刺，临时扩 BPO + 临时邀约专家）总等效 FTE：380‑550

稳定生产人员：日常持续投入产线的有效人力；峰值可调用：可临时扩容 BPO + 临时邀约专家。

7. 按训练阶段拆分生产模式、占比、过去一年变化

【可聊，token 产出区间占比】

表格

数据类型内部正式员工自营 / 内包BPO领域专家第三方外购备注
Pre‑training / 持续预训练 20‑25% <5% 5‑10% <5% 60‑70% 外购原始语料占大头，全部内部清洗过滤
SFT 25‑30% 10‑15% 30‑35% 5‑10% 10‑15% 合成数据占比高；BPO 承担通用样本
Preference/DPO / Reward Model 30‑35% 10‑15% 25‑30% 15‑20% <5% 垂域对比样本高度依赖专家评审
RL/Agentic 40‑50% 15‑20% <10% 25‑30% <5% BPO 占比极低；大量使用模型合成数据
Eval / Benchmark 40‑50% 10‑15% 10‑15% 25‑35% <5% 评测集重质量，专家命题终审
Safety / Red‑Team 35‑45% 10‑15% 20‑25% 20‑30% <5% 内部定风险策略，专家构造高危 Case

过去一年变化：

  1. 预训练：外购原始语料占比小幅下降，内部筛选清洗权重提升；
  2. SFT、RL‑Agentic：模型合成数据占比持续提升，降低纯人力标注依赖；Agentic 方向领域专家占比提升；
  3. BPO 进一步收缩到通用简单样本；高价值 Coding、Agentic 向内部、内包、专家倾斜。

8. 各训练阶段实际产量、稳定周产能

【可聊定性；绝对条数、Pair、Task 数量涉密不可披露】

  1. SFT：周产量跟随模型迭代节奏波动；理论稳定产能显著高于实际产出；瓶颈是高质量任务设计，不是标注人力。
  2. Preference/DPO、Reward Model：约束来自高质量对比样本构造，不是标注吞吐量。
  3. RL/Agentic：统计单位不能简单用 “条数”，核心单位是 Task、Environment、Verifier、Rollout/Trajectory；瓶颈是 Task 设计、Environment&Verifier 开发，不是模型 Rollout 算力。
  4. Eval/Benchmark：追求质量而非规模，小批量定向产出，非匀速大规模生产。
  5. Safety/Red‑Team：跟随模型版本迭代定向构造，无固定周产量。

共性现象：多数场景真实周产量跑不满理论稳定产能，约束来自高质量数据定义环节，而非人力上限。

9. RL/Agentic（Harbor‑task 完整任务包）产能、单 Task 耗时、各阶段人力时间分配

【可聊定性；每周 Task 绝对数量涉密】 完整 Task：Instruction、Environment、Initial‑State、Verifier/Test/Rubric。

  1. RL‑Agentic Task 属于高成本低吞吐对象；理论稳定产能高于实际交付，实际交付受限于 Environment、Verifier 开发，经常跑不满上限。
  2. 单 Task 人工耗时差异巨大：Office‑Use 简单任务成本低；复杂软件工程、金融仿真 Task 耗时成倍增加。
  3. 各阶段人力时间相对占比：
  • Task 创意 & 任务设计：25‑30%
  • Environment 环境搭建：30‑35%（最大耗时环节）
  • Verifier/Test 校验器编写：20‑25%
  • Reference/Gold 样例构建：5‑10%
  • Review & 多轮复审验收：10‑15%

核心卡点：Environment 与 Verifier 合计占用超过一半人力。

10. RL‑Agentic Task：Rollout 生成、淘汰率、入训 Trajectory 产能

【可聊定性；绝对数值涉密】

  1. 开发验证阶段：单个 Task 会多次运行模型 Rollout，用来调试 Environment、Verifier 正确性。
  2. 训练阶段：每个 Task 采样多条 Rollout 轨迹。
  3. 淘汰过滤：经过 Verifier 校验、去重、异常过滤、质量打分，相当一部分 Rollout 会被淘汰，无法进入训练集。

关键认知：Task 交付产能 ≠ 最终入训 Trajectory 产能；经常出现 Task 供给充足，但有效入训轨迹成为瓶颈，根源在于质量过滤淘汰。

11. RL‑Agentic 按领域拆分产能、人员、产线成熟度

【可聊定性；Task 绝对数值涉密，【推演预估】各领域参与人力（内部 HC + 外部专家等效 FTE，不含 BPO）】

表格

领域专职内部 HC【推演预估】外部专家等效 FTE【推演预估】备注
Coding/SE 12‑18 15‑22 规模化产线
Computer‑Use/Office Work 8‑12 7‑11 规模化产线
Math‑Science 5‑8 8‑12 规模化产线
Data‑Science/Research 4‑7 6‑9 中等吞吐
Finance 2‑4 3‑5 试产小批量
Legal 2‑3 2‑4 试产小批量
Medical 1‑2 1‑3 试产小批量
  1. 已形成规模化稳定产线：Coding、Math‑Science、Computer‑Use/Office‑Work。沉淀可复用 Environment 模板库，专家供给相对充足，可以持续产出 Task。
  2. 试产 / 小规模建设阶段：Finance、Legal、Medical。约束：合格领域专家稀缺；Environment/Verifier 构建成本高；只能小批量产出高质量样本。
  3. 中间状态：Research、Data‑Science，可以产出，但任务复杂度高，整体吞吐有限。

是否规模化，核心约束两点：①稳定合格领域专家供给；②可复用 Environment、Verifier 模板沉淀。

12. Work/Agentic、Coding 生产模式、人员角色、产能瓶颈

【可聊定性；产量绝对数值涉密，【推演预估】等效 FTE，包含内部 + 内包 + 专家；BPO 占比极低忽略不计】

BPO 在这两块占比极低，仅少量辅助初筛；主力是内部正式员工 + 内包 + 外部领域专家。

角色分为 Task Design、Environment/Verifier 开发、Task Production、Reviewer/QM。

【推演预估】Coding 方向总等效 FTE：30‑45

  • Task Design：8‑12
  • Environment/Verifier 开发：10‑15（最大人力消耗点）
  • Task Production：7‑11
  • Reviewer/QM：5‑7

【推演预估】Work/Agentic（Computer‑Use Office）总等效 FTE：20‑32

  • Task Design：5‑8
  • Environment/Verifier 开发：7‑11
  • Task Production：4‑7
  • Reviewer/QM：4‑6

当前真实产能瓶颈：Task Design、Environment/Verifier 开发能力，其次是高难度样本 Reviewer/QM 专家资源；模型 Rollout 算力不是主要瓶颈。

13. 产线成熟度、平台化现状、成熟环节、依赖人工环节

【可聊】 整体成熟度：半成熟。 拥有统一的数据生产、任务管理、评测流水线平台；但是 RL/Agentic 的 Environment、Verifier 大量依赖代码开发，没有做到可视化拖拽配置；Agent 部分流程还需要跨工具操作，尚未实现 100% 全链路单平台闭环。

✅平台化成熟环节：

  1. 预训练原始数据入库、清洗、去重大规模批处理；
  2. 模型合成数据批量生成、自动初筛；
  3. 普通 SFT 标注任务管理、BPO 任务下发、数据集版本管理；
  4. 自动化评测粗过滤、基础质量指标监控。

⚠️高度依赖人工 / 项目经理协调：

  1. 新任务 Schema、RL‑Agentic Task 任务定义；
  2. Environment、Verifier 代码开发；
  3. 高垂域 Coding/Legal/Medical 样本事实正确性终审；
  4. BPO、外部专家的规范对齐、Bad‑case 复盘迭代；
  5. RL 奖励任务集构造；
  6. 模型 Bad‑case 反向挖掘，定义新增数据方向；
  7. Agent 多环节跨工具项目协同，需要 PM 对齐任务、工程、专家。

14. 过去一年投入方向、变化、未来一年重点扩张

【可聊定性；预算、人头增量涉密】 过去一年主要投入方向：

  1. 补强Environment/Verifier 团队，补齐 RL‑Agentic 核心短板；
  2. 扩充 Coding、Work‑Agentic 方向任务设计与质量专家；
  3. 重点建设模型合成数据流水线，降低纯人力标注依赖；
  4. 迭代统一数据生产平台，补齐 Agent 相关能力；
  5. 将 BPO 业务收缩聚焦到通用简单样本，高价值任务不再交给 BPO；
  6. 扩充 STEM、代码方向外部垂域专家池。

变化特征：人力向 Agentic、Coding 等高复杂度数据倾斜；合成数据在 SFT/RL 占比显著提升；对传统体力标注人力依赖下降。

未来一年重点扩张：

  1. 持续强化 Environment/Verifier 工程能力，沉淀更多可复用模板；
  2. 扩充金融、法律等垂域稳定专家供给；
  3. 升级自动化合成、自动校验能力，降低人工负担；
  4. 完善 Agentic 完整 Task 在平台内部闭环能力，减少跨工具操作。

15. 长期能力边界；哪些必须内部；高专业度数据演进路线

【可聊，专家判断】

必须牢牢掌握在公司内部的核心能力

  1. 顶层数据策略：模型迭代需要什么数据、数据 Schema、任务目标定义；
  2. 完整质量标准体系、Bad‑case 闭环迭代机制；
  3. Environment/Verifier 底层框架与核心架构能力；
  4. 数据平台、模型合成流水线开发维护；
  5. 数据集版本最终验收、入训准入把关。

适合外部弹性扩充的能力

  1. 通用样本改写、基础初筛（BPO）；
  2. 垂域专家做命题、样例产出、正确性评审（外部专家池弹性调用）；
  3. 原始语料采购（第三方数据集供应商）。

Coding、Work‑Agentic、Legal 等高专业度 RL 数据演进判断

不会走向全部内部自建大包大揽，也不会全盘外包。最终是「内部核心团队 + 外部专家产能」合营模式： 内部守住 Task 设计范式、Environment/Verifier 底层框架、整套质量标准；具体行业实例、具体 Task 生产、样例生成、评审，大量借助外部专家弹性产能。 底层框架底座内部化，但行业实例化 Task 可以外部产出；顶层 Task Design 策略、校验框架不会外包出去。 目前公司已经朝着该合营方向演进。

posted on 2026-09-02 18:12  limingqi  阅读(13)  评论(0)    收藏  举报

导航