行业大模型训练实战：Continued Pre-Training全流程指南

从去年开始我陆续帮几家不同行业的企业做过把通用大模型训练成行业模型的落地项目接触得越多越发现一个普遍误区很多人把行业模型等同于微调拿几万条问答数据跑一遍 SFT就对外宣称我们有行业大模型了。可一旦放到真实生产环境里效果往往撑不住——问深一点就露馅要么一本正经地编造工艺参数要么把内部业务术语理解得南辕北辙。真正要改变模型的知识底座让它长在某个行业的数据之上技术路径叫 Continued Pre-Training也就是常说的 CPT、领域自适应预训练或增量预训练。这篇文章我把整个实操过程完整梳理一遍重点覆盖数据怎么准备、基座怎么选、参数怎么配、效果怎么评估以及不同行业在项目立项上的关键差异。这篇实战指南适合三类人一类是企业的算法负责人正在评估到底要不要做 CPT一类是已经决定做、但不知道从哪一步入手的工程师还有一类是负责模型项目立项、需要写商业计划书的人。互联网和制造企业对行业模型的诉求差异极大后面我会单独用一个章节对比这两种项目的侧重点方便大家对号入座。1. 为什么要做 Continued Pre-Training行业模型的真正瓶颈1.1 通用模型很强通用本身就是问题通用大模型的知识来源是互联网上大规模的公开数据优势是覆盖面广缺点是每个行业都只是浅尝辄止。拿制造业来说通用模型可能知道什么是注塑机、什么是 PLC 控制器但当你问它某型号注塑机在 PC 料生产场景下的炮筒温度推荐区间是多少它大概率开始流畅地编造一个看起来合理的数字。这种幻觉不是靠提示词能解决的因为模型根本没有见过这类语料它在训练阶段就没学过这些知识再会推理也无从推起。互联网行业的情况类似。通用模型懂用户增长的概念但未必懂某家公司特有的业务术语、内部产品命名、数据指标口径更不用说过去几年沉淀的运营经验都散落在内部的工单、邮件、产品文档里。这些私有知识才是行业模型的价值所在。基座模型知道的只是通用的行业常识而企业真正想要的是自家公司的行业知识这两者之间隔着一条数据鸿沟。CPT 就是用来填这道鸿沟的。1.2 CPT、SFT、RAG 到底差在哪很多团队把 CPT、SFT、RAG 混为一谈实际上三个东西解决的问题完全不同选错方案会浪费大量预算。RAG 是外挂知识库把检索到的文本拼到 prompt 里让模型参考。优势是灵活、不需要训练、更新知识只需更新索引缺点是它改变不了模型本身的能力边界遇到需要多步推理或者知识深度整合的场景效果会打折扣。SFT 是教模型说话的格式用指令-回答对让模型学会某种行为方式和表达结构比如学会客服话术、学会写 SQL。但 SFT 的知识增量非常有限几万条数据能改变的权重很浅它本质上是风格对齐不是知识注入。CPT 是让模型真正读一遍行业语料用自回归语言建模的方式继续训练让模型把行业词汇、概念、事实性知识内化进参数里。这个过程改变的是模型的知识底座而不是表面的话术风格。所以一个很实用的判断标准是目标是让模型说行业话SFT 就够目标是让模型懂行业事必须上 CPT。至于 RAG那是在模型本身已经够懂的基础上给它配一个随时更新的记忆外挂三者不是互斥关系很多成熟项目是 CPT 打底、SFT 对齐、RAG 做实时知识补充各管一段。1.3 什么样的问题值得上 CPT不是所有企业都需要 CPT。我见过一些团队明明用 RAG 加提示词就能覆盖的场景非要上 CPT结果花了大几十万算力钱线上效果提升不明显。判断是否需要 CPT一般看三个条件。第一个条件行业有大量非公开的、高质量的文档或日志语料。如果没有数据CPT 就是无米之炊再强的算力也白搭。第二个条件业务场景对专业知识的准确度和深度要求高通用模型的能力明显不够用而且这种差距不是靠检索补充能拉平的。第三个条件这些知识是长期有效的不是那种今天写完明天就过期的临时信息。如果只是内部知识库问答RAG 是性价比最高的方案如果只是让模型按照固定格式输出SFT 就够了。CPT 是一种很重的方案牵涉数据、算力、训练和评估全链路立项前一定要想清楚投入产出比。2. 训练前的三个关键动作语料、基座与算力2.1 行业语料的来源与清洗数据是 CPT 的灵魂也是最大的工程瓶颈。先看数据从哪来。制造业的典型来源包括设备运行日志、PLC 报警记录、工艺参数表、质检报告、维修工单、SOP 工艺文档、产品规格书、历史故障案例库。这些数据往往散落在 MES、ERP、PLM 系统里需要和各系统负责人协调导出有些数据甚至还在纸质文档或老工程师的脑子里需要先做数字化整理。互联网行业的来源则包括内部产品文档、技术方案、故障复盘记录、客服对话、用户反馈、运营周报、代码仓库里的 readme 和注释。这里面要特别注意脱敏用户隐私和商业机密必须先处理干净这一步做不好后续合规风险非常大。数据量级上我的经验是 CPT 的语料至少要有 1B token 以上才有明显效果理想是 5B 到 50B。很多人问能不能用几百万条文本凑合算一下就知道了中文平均每个 token 大概是 1.5 到 2 个字1B token 大约是 2 亿字。一个小型企业文档库可能只有几十万到几百万字远远不够需要想办法补充公开行业语料、行业标准、论文、专利等公开来源。制造业可以补充国标、行标文档和产品说明书互联网行业可以补充技术博客、开源文档、行业报告前提同样是确认版权和合规边界。清洗环节有几个容易踩的坑去重比过滤更重要。互联网公开数据源的数据重复率不算低但内部文档里模板化内容更严重比如同一份周报格式反复出现、同一个故障案例被复制进多份工单。训练时重复数据会造成严重的过拟合和 loss 震荡。我习惯用 MinHash LSH 做大规模近似去重字符级的精确去重只是第一步对长文本还要做子串级去重。过滤低质量内容时不要只看长度。短文本不一定质量低比如设备报警记录本身就很短却是非常有价值的行业语料反过来很多爬下来的技术文章关键词堆砌严重看着很长实际没多少信息量需要按打分模型或规则过滤。数据格式统一非常关键。行业文档经常有大量表格、图片、特殊符号纯文本化之后要处理成 markdown 或结构化文本否则模型会学到大量乱码和无效格式符号。我通常会写一套预处理脚本把表格转成管道符分隔的文本把图片转成占位符说明把公式转成纯文本描述。2.2 基座模型选型与开源协议CPT 的前提是有一个可商用的大模型底座。选型时我一般看四点开放协议、中文能力、上下文长度、社区生态。目前国内团队可选的开源模型主要有 Qwen 系列、DeepSeek 系列等选型时务必逐条核对开源许可证商用授权边界一定要确认清楚尤其是金融、医疗这些强监管行业授权问题不能含糊。另一个容易被忽视的细节是 tokenizer。行业词汇的切分质量会直接影响训练效率。制造业里大量专业术语是组合词比如热固性塑料“注塑成型参数”如果 tokenizer 把这些专业词切成好几段等于每个词要花更多 step 才能学好浪费算力。做 CPT 之前建议先跑一遍分词统计如果行业词汇的分词碎片化严重要考虑扩展词表并重训 embedding 层。扩展词表需要新增 embedding 参数训练成本会增加一些但对行业词汇的学习效率提升非常明显这笔投入值得花。2.3 算力评估与训练框架算力这块要讲实际。一个 14B 参数的模型用 DeepSpeed ZeRO-3 做 100B token 的 CPT以 8 卡 A100 80G 为例理论吞吐大概能做到每卡 30 到 50 TFLOPs 的利用率实际训练时间通常是几百小时到上千小时。这个成本要提前和预算方对齐不要等到训练跑到一半才发现算力不够用。我的建议是先用小规模数据比如 1 到 5B token做一轮验证训练确认效果方向对了再放大数据量。不要一上来就吃满全部预算做 CPT 要留出至少 30% 的预算空间给数据迭代和踩坑修复。训练框架方面DeepSpeed 和 Megatron-LM 是两种主流选择前者上手快、社区活跃后者在超大模型场景下流水线并行效率更高。无论选哪个断点续训、混合精度、数据并行这些能力都是必须的。工程上还有一个容易忽略的点训练监控。loss 曲线、梯度范数、吞吐量、学习率曲线都要有可视化面板。我见过不止一个团队训练跑了一周一查 log 发现第二天就开始 loss 发散白白烧了五天算力。监控面板的搭建成本很低但能省下的钱远超想象。3. CPT 训练配置与核心环节实现3.1 数据配比通用数据不能丢CPT 最常见的错误就是拿纯行业数据训练。模型确实能快速吸收行业知识但很快也会把通用能力忘掉这叫灾难性遗忘。最直接的后果是模型写行业内容时语言质量和逻辑能力明显退化甚至出现连基本常识都答错的情况。这就好比一个人猛补专业课把基础课全忘光了。我的经验配比是行业语料占 60% 到 80%通用语料占 20% 到 40%。通用语料可以复用基座模型训练时用过的公开数据集的一部分也可以从网上采集高质量通用文本。这里的关键逻辑是模型需要复习通用知识同时学习行业知识两类数据要在同一个 batch 里混合而不是分阶段训练。分阶段训练我试过行业阶段会把通用阶段学到的语义结构覆盖掉混合训练明显更稳。具体到 batch 构造我会在每次采样时按比例从行业池和通用池里取数据而不是先拼好一个固定顺序的混合数据集。这样每个 batch 里的数据分布都相对均匀避免模型在某一段时间内只看到行业数据、下一段时间又只看到通用数据造成 loss 波动。3.2 关键超参数配置CPT 的超参数和从头预训练有很大差异这里把我实践下来比较稳的一套配置列出来。学习率方面从头预训练常用 3e-4 甚至更高CPT 建议 1e-5 到 3e-5。学习率过大会直接破坏原有模型权重过小则行业知识学不进去。我一般用 2e-5 起步跑几百步看 loss 下降速度再决定调整方向。批量大小方面在 DeepSpeed ZeRO 下global batch size 建议 512 到 2048 samplessequence length 用 4096。batch size 太小会导致 loss 震荡明显太大则收敛速度变慢且显存压力大。学习率调度推荐 WSDWarmup-Stable-Decay策略先用 warmup 让训练稳定然后保持较长一段稳定期最后衰减。相比 cosine 调度WSD 的好处是可以在稳定期随时评估 checkpoint根据效果决定继续训练还是停止灵活性高很多。权重衰减通常设 0.1和从头预训练保持一致。混合精度首选 bf16fp16 容易出现 loss 溢出尤其在大规模分布式训练时。梯度裁剪 max grad norm 设 1.0这个值基本能应对大部分异常情况。下面是我常用的一个训练配置示例基于 HuggingFace 生态 DeepSpeed# 以 Qwen2.5-14B 为基座做 CPT 的示例启动命令 deepspeed --num_gpus8 run_clm.py \ --model_name_or_path Qwen/Qwen2.5-14B \ --train_file ./data/domain_mixed.jsonl \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 16 \ --global_batch_size 512 \ --block_size 4096 \ --learning_rate 2e-5 \ --lr_scheduler_type ws d \ --warmup_steps 200 \ --weight_decay 0.1 \ --bf16 True \ --max_grad_norm 1.0 \ --max_steps 50000 \ --save_steps 500 \ --logging_steps 10 \ --deepspeed ds_config.json注意gradient_accumulation_steps 和 per_device_batch_size 的乘积再乘以卡数等于 global batch size这个换算关系要算清楚否则你以为自己在用 512 的 batch实际可能只是 64。3.3 训练稳定性检查与止损策略训练过程中要看几个关键指标。loss 曲线正常情况下应该平滑下降出现台阶说明某个数据分布切换了出现尖峰说明数据里有异常样本或者学习率过大。梯度范数如果长时间异常巨大基本是数据里混入了异常长文本要及时定位到具体样本并剔除。吞吐量要实时记录如果突然掉一半检查数据加载和通信瓶颈很多时候是 DataLoader 的 num_workers 设置不合理导致的。止损策略上我每 1 到 2 小时保存一次 checkpoint并且设置一个硬性规则如果 loss 连续 500 步不降反升先暂停训练排查原因后再决定是回滚 checkpoint 还是调整参数继续。之前遇到过一回训练中断 6 小时才发现幸好有检查点回滚后损失不算太大。这类事故在 CPT 项目里特别常见因为训练数据量巨大单个坏样本的影响在早期不明显积累到后期才会爆发。4. 评估体系怎么证明行业模型真的行业4.1 通用能力不塌方检测CPT 之后第一件事不是急着看行业能力而是测通用能力有没有严重退化。这一步很多人会跳过结果模型上线后用户反馈怎么变笨了。我会跑一组通用 benchmarkMMLU、C-Eval、CMMLU和基座模型做对比。退化幅度控制在 2 到 3 个百分点以内是可以接受的如果超过 5 个点说明数据配比或者学习率有问题需要回炉重调。这里有个实操细节CPT 过程中会产出多个 checkpoint不要只在训练结束时做一次评估。我建议每训练 5B 到 10B token 就挑一个 checkpoint 做完整评估记录通用能力和行业能力的变化曲线。这样你能清楚地看到训练到多少步时通用能力开始下滑行业能力是否还在涨据此决定是继续训练还是立即停止。如果行业能力已经趋平、通用能力开始下降那这个点就是最优 checkpoint。4.2 行业能力验证任务集构建与人工评测行业能力评估是核心我建议团队自建行业评测集至少包含三类。第一类是知识问答从行业文档里抽事实性问题答案必须可查证比如某材料的耐温等级是多少。第二类是任务型题目针对具体业务场景的推理题、判断题比如根据设备报警代码判断可能故障原因。第三类是真实样例回放从线上日志里抽一批真实输入人工标注标准答案这部分最能反映模型实际部署后的表现。评测时同时看自动指标和人工指标。自动指标用 BLEU、ROUGE、准确率等适合快速批量对比人工指标看专业内容的准确性、逻辑一致性、无幻觉比例。行业模型的评测必须有人工参与因为行业知识的对错不是文本匹配能判断的。哪怕是对同一道知识题资深工程师和刚入行的标注员的判断也可能不同所以人工评测尽量邀请业务侧的专业人员参与至少覆盖一小部分关键题目。4.3 用 PPRM 模型做自动化评估与数据筛选最近圈里讨论比较多的 PPRM 模型这里展开说一下。PPRM 通常指 Process Preference Reward Model也就是过程偏好奖励模型。它和普通奖励模型不一样普通奖励模型只给模型的最终输出打一个整体分属于结果导向PPRM 会沿着模型的推理过程逐步打分能够定位到具体哪一步出现事实偏差或者逻辑断裂。在 CPT 项目的评估环节PPRM 有两个很实用的用途。第一个用途是 checkpoint 筛选。训练过程中会产出很多 checkpoint逐个跑人工评测成本太高可以先用 PPRM 对每个 checkpoint 的输出批量打分挑出得分最高的几个再做人工确认。第二个用途是错误定位。把同一个评测集跑一遍按 PPRM 的分步骤得分做错误分析会发现模型在某一类多步推理问题上失分最多这直接为下一轮训练数据补充指明了方向。从我的测试经验看PPRM 在评估行业推理类问题上的可靠性明显高于普通结果打分模型原因是制造业和互联网业务场景里很多问题本身就是多步推理答案对不对往往取决于中间步骤是否合理只看最终结果很容易漏掉蒙对答案但过程错误的情况。当然 PPRM 的部署也有成本它本身是一个需要额外训练的模型适合数据规模较大、评估频率高的团队。如果只是做一两轮 CPT 验证先用人工评测加普通指标就够了。5. 互联网行业 vs 制造企业行业模型项目的侧重点差异5.1 互联网行业的模型项目侧重点互联网公司做行业模型通常瞄准用户面场景比如智能客服、内容生成、运营分析、营销文案。这类项目有几个鲜明特点。数据丰富但噪声大。用户产生的文本量级非常大包括客服对话、评论、需求反馈但口语化严重、错别字多、上下文碎片化清洗和标注成本很高。迭代速度要求高。互联网业务以周为单位迭代模型训练和上线节奏必须跟上业务所以更强调高效的数据管线以及训练-评估-上线的自动化流程最好做到模型更新像发版本一样频繁。效果评估贴近业务指标。除了模型本身的准确率更要看线下效果是否转化到业务数字上比如客服场景的对话解决率、回复采纳率、人工介入率这些才是业务方真正关心的。互联网项目在技术上可以走得比较激进。用户反馈闭环快模型上线后能迅速收集到真实数据形成数据-训练-优化的飞轮所以可以接受一些小范围的模型错误只要整体效果提升就有价值。这种情况下CPT 的目标通常是让模型更懂这家公司的产品和用户而不是追求所有行业通吃。5.2 制造业的模型项目侧重点制造业做行业模型的诉求完全不同核心场景是工艺知识问答、设备故障诊断、质量异常分析、操作规范生成。这些场景有几个特点决定了项目做法的差异。数据准确性和安全性要求极高。工艺参数错一次可能导致整批产品报废甚至引发安全事故。所以模型上线前必须经过严格的专业审核绝不能出现编造参数的情况。数据来源碎片化严重。工艺文档、设备日志、质检记录分布在不同的系统里格式五花八门很多甚至是纸质文档扫描件需要先做 OCR 和结构化整理这一步的工作量经常被低估。项目周期长、预算重。不像互联网一个季度就能看到效果制造业模型项目往往要经历数据治理、模型训练、试点验证、系统集成多个阶段每个阶段都需要和业务侧反复确认。落地的 ROI 计算非常关键制造业企业做技术投入最关心的是能不能降本增效。制造业项目的技术在选型上会更偏保守。比如对幻觉的容忍度极低所以经常会配合 RAG 做知识来源溯源模型输出必须能指出依据哪份文档的哪一条规则又比如对部署环境的要求高很多制造企业要求私有化部署数据不能出园区这对模型量化和推理优化提出了额外要求。5.3 商业计划书视角两者的评估指标与叙事逻辑差异如果把模型项目写成商业计划书互联网和制造行业的侧重完全不同这一点我在帮几个团队梳理 BP 时感受特别深。互联网行业的商业计划书更强调用户和增长。叙事逻辑通常是市场规模有多大、痛点有多痛、我们的模型能怎样提升现有业务流程的效率、早期用户从哪里来、后期靠什么变现。评估指标偏重 DAU/MAU、用户留存、转化率、客单价、毛利率。风险部分关注模型竞争加剧、数据合规、同质化问题。这类 BP 写得更性感讲想象空间用有限的验证数据讲一个足够大的故事路演时满屏都是增长曲线。互联网投资人能接受早期亏损因为逻辑是先占住场景后续变现路径多。制造业的商业计划书完全是另一个路数。制造业决策人更愿意看到项目的投资回报周期是多长、产线生产效率能提升多少、废品率能降低几个百分点、设备停机时间能缩短多少小时、现有生产系统怎么对接、现场操作人员需要怎样的培训。评估指标是良品率、OEE设备综合效率、MTTR平均修复时间、人工成本节约额。叙事逻辑必须落到省了多少钱、赚了多少钱这个层面而且要有试点数据支撑不能只是理论测算。商业计划书里有两个容易犯的错误。一是不管什么行业都套用我们做的是大模型平台这种宽泛叙事这种描述很难获得制造业决策者的信任他们会觉得你不懂行业。二是只讲模型技术指标比如我们模型准确率 95%但不讲业务指标和落地路径。我印象很深的一个制造业客户对方高管在汇报时直接问这个模型上线之后我的班组长要花多少时间学这个问题其实暴露了很多 AI 项目在制造业落地的核心障碍——再好的模型如果现场人员用不起来ROI 就是零。6. 常见问题与排查技巧实录6.1 灾难性遗忘症状是 CPT 之后通用能力明显下降常识问答反而变差。原因主要是通用语料占比太少或者学习率设置过高。解决思路是保证混合训练把通用数据比例提高到 40% 甚至 50%同时把学习率降到 1e-5 级别。如果遗忘已经发生可以尝试在通用数据上做一轮轻量回补训练或者直接回滚到遗忘开始前的 checkpoint。6.2 训练 loss 不降或震荡可能的原因很多数据重复度高、学习率不合适、batch size 太小、数据质量有问题。我的排查顺序是先看训练数据里有没有异常 token 或乱码样本再查 loss 尖峰是否对应某个特定数据切片最后调整学习率和 batch size。数据去重这一步不要省MinHash 跑一轮不算贵但能避免后期大量返工。6.3 行业知识注入效果不明显原因通常是数据量不够或者清洗不彻底行业语料中真正的知识点密度太低。经验是 CPT 的训练数据要经过知识密度筛选只保留包含实质性专业信息的文本而不是把整个文档库不分青红皂白全扔进去。另外检查行业词汇的分词效果如果碎片化严重考虑扩展词表。6.4 常见问题速查表把上面遇到的问题整理成一张表方便团队在实施过程中快速对照。现象可能原因首要检查项解决建议通用能力大幅下降通用数据占比过低 / 学习率过高通用数据配比、学习率曲线通用数据提到 40%-50%学习率降到 1e-5loss 持续震荡数据重复度高 / batch 太小 / 有异常样本去重率、数据样本检查跑 MinHash 去重增大 global batch size行业知识没学进去语料知识密度低 / 分词碎片化词表覆盖度、知识型文本占比做知识密度筛选扩展行业词表训练中途 loss 发散学习率过大 / 梯度异常梯度范数、学习率曲线降低学习率检查异常 batch回滚 checkpoint模型输出混入乱码数据清洗不彻底预处理脚本输出样本加强格式统一过滤特殊字符样本模型能说行业话但事实常错数据量不足 / 评测体系缺失行业评测集构建情况扩充语料构建可查证的知识问答评测集多步推理经常出错模型对过程性知识理解不足PPRM 分步骤得分补充带推理过程的语料用过程奖励模型定位错误步骤上线后业务指标没提升技术效果好但场景不匹配业务指标定义和埋点让业务方参与评测集构建对准真实业务场景7. 多轮迭代与项目节奏控制7.1 第一轮先跑通第二轮再提效果CPT 项目常见的失败方式不是技术上出了问题而是项目节奏没控制好。很多团队第一轮就想把所有行业知识全部注入模型数据收集花了一个月清洗花了一个月训练花了一个月最后评估不达标整个团队都很沮丧。实际上更稳妥的方式是分轮迭代第一轮用少量的、高质量的核心语料比如 1 到 5B token目标是把整套训练评估流程跑通得到一个可用但不完美的行业模型尽早让业务方看到效果。第二轮再扩大数据规模针对第一轮评测暴露的问题定向补充数据目标是把覆盖度和准确度提上去。这个节奏的好处是每轮都有明确的交付物风险可控也方便向管理层汇报阶段性成果。7.2 评测集跟着业务一起迭代评测集不是建一次就完事的。第一轮评测集可能要业务方投入大量精力去标注但后续每轮训练都需要更新评测集把新发现的问题场景加进去。我的习惯是维护一个问题案例池每次上线后收集到的模型错误案例、用户投诉、业务方反馈都沉淀到这个池子里定期转成评测题加入评测集。这样过几轮之后评测集的质量会越来越高模型的评估分数和真实业务效果之间的相关性也会越来越强。评测集是模型质量的标尺标尺不准后面所有优化都是在盲调。7.3 训练-评估-上线的自动化闭环当项目进入常态化迭代阶段后建议把 CPT 的流程做成半自动闭环。数据侧新语料经过清洗、去重、知识密度筛选后自动进入数据池训练侧配置好启动参数后自动跑训练并在关键节点保存 checkpoint评估侧自动触发通用 benchmark 和行业评测任务生成对比报告上线侧达到预设标准的 checkpoint 自动推送到推理环境。这个闭环建好之后模型可以按周甚至按天迭代业务方的需求能更快落地。当然自动化的前提是前面的评估体系足够可靠否则机器会把坏模型自动推到线上反而造成事故。结尾与个人体会最后分享一点个人感受。CPT 这个技术本身并不神秘本质上还是自回归语言建模难点在工程化和数据治理。做了这么多项目之后我最大的体会是行业模型的成败七成在数据两成在评估真正花在训练参数上的心思其实只有一成。很多团队把大量精力花在调 loss 曲线、刷 benchmark 分数上却忽略了最基础的数据质量问题和评测体系的搭建方向就偏了。另外有个很实用的建议不要一开始就追求全行业万能模型。先选一个最小的、业务价值最明确的场景做闭环比如制造业先做工艺知识问答互联网先做客服助手。一条链路跑通之后再逐步扩展到更多场景。这样既控制预算又能在每个阶段拿出可验证的业务价值后续再申请资源也更有底气。从我接触过的案例来看凡是走小场景闭环再扩展路线的团队最后都走得更远凡是起手就想做一个宏大平台的大多在数据阶段就卡住了。再补充一个小技巧关于数据清洗之后的验收。不要只盯着清洗脚本的统计指标一定要随机抽几百条清洗后的样本人工过一遍看看格式是否统一、内容是否完整、有没有引入新的乱码。这个检查每次都要做别嫌烦数据清洗的错误只有人眼最可靠模型训练一旦开始污染的数据会在模型参数里留下持久的痕迹后期想清掉代价极高。如果大家在企业里做 CPT 遇到具体问题按这篇文章的顺序排查一遍大部分问题都能定位到源头。数据治理的细节还有很多等后面有空再单独写一篇实战记录把去重、知识密度筛选和词表扩展的具体做法展开细聊。