这两年我在企业里做大模型落地的项目比较多一个感受越来越强烈大模型本身已经不是瓶颈瓶颈在数据。经常遇到的情况是业务方兴冲冲拉了几张表过来说要微调模型、要建知识库结果我一打开数据文件心里就凉了半截——光日期格式就有四种同一个客户名称在一张表里能出现六个写法有的字段一半以上是空的。这种脏数据直接喂给大模型效果可想而知。后来我们慢慢摸索出一套从脏数据到 AI-ready 数据底座的工程化方法一共五步每一步都有明确的动作和验收标准。这篇文章就把这套实践完整整理出来适合正在做企业大模型私有化部署、RAG 知识库、微调训练但被数据问题卡住的数据工程师和算法工程师参考。1. 企业数据为什么“喂不饱”大模型先看清四个典型病灶很多团队把精力全放在模型选型和 prompt 调优上数据问题往往被归咎为“数据很脏清洗一下就行”。但真到动手的时候才发现清洗不是最难的最难的是说不清楚企业数据到底有什么、在哪、谁负责、质量怎么样。这里有四个典型病灶几乎每家企业都能对号入座。1.1 数据资产像“黑洞”你知道数据存在但不知道有多少大企业通常有几十套业务系统CRM、ERP、呼叫中心、工单系统、财务系统、自研的运营后台。每套系统都有自己的数据库甚至同一套系统在不同时期用了不同的数据库实例。平时各系统各跑各的没人有全局视图。我见过一家零售企业IT 部门给出的数据资产清单只有 20 张核心表但实际排查下来光 MySQL 实例就有十多个还有一批 Oracle 老库和 ClickHouse 分析库真正有价值的数据资产超过 400 张表。为什么差距这么大因为很多数据藏在“无人认领”的临时表、日志表、备份库里连业务负责人都不一定知道这些表是干什么用的。这个问题的本质是没有盘点就没有边界。不知道数据资产边界后面所有清洗、标注、治理都是空中楼阁。1.2 数据脏在四个地方缺失、重复、口径不一、格式混乱缺什么最典型的是关键字段缺失。用户表里手机号缺失率 30%订单表里区域字段 40% 为空。缺失不是最可怕的最可怕的是你不知道为什么缺失——是采集时没拿到还是业务上本来就不该有两种情况的处理方式完全不同。重复也很普遍。我见过同一批客户数据从不同系统导出后 join 出来 120 万行去重后只剩 68 万行。重复的根源往往在于没有统一的主数据管理同一个实体在多个系统里被重复创建ID 体系互不打通。口径不一属于最隐蔽的脏。同样是“销售额”财务系统里是含税口径业务系统里是不含税口径同样是“用户活跃”A 系统按登录次数定义B 系统按在线时长定义。这些字段名一样语义却不一致模型学到的就是错乱的关系。格式混乱是最直观的脏。日期有2024/01/05、2024-01-05、2024.01.05、20240105四种写法手机号有的带国家码、有的不带金额有的存元、有的存万元、有的存分。这些格式问题看起来简单但量一上来就是灾难。1.3 直接拿脏数据喂模型的三个后果幻觉、偏见、知识陈旧脏数据进模型最直接的表现是幻觉变多。我排查过几个 RAG 问答项目的 badcase根因几乎都是知识库里的文档本身互相矛盾——两篇文档对同一政策条款的表述不一致检索出来之后模型就“自由发挥”了。第二个后果是数据偏见被放大。如果训练数据里某个城市、某个品类的样本占比过高模型会把这些局部规律当成全局规律。比如客服语料里退款类问题占了 70%模型就很容易把所有用户意图都往退款上归类。第三个后果是知识陈旧。很多企业的数据底座是一次性导出的之后业务系统继续跑数据底座纹丝不动。模型回答问题用的永远是三个月前的数据这在营销、供应链场景里基本等于废数据。这四个病灶叠加才是“喂不饱”的真正含义——不是数据量不够而是数据质量不够、组织不够、更新不够。2. AI-ready 数据到底是个什么标准先定义再动手“AI-ready”这个词这两年被讲得很多但我发现多数人对它的理解停留在“数据很干净”这个层面。实际上干净只是基础AI-ready 是一套复合标准。2.1 我用的定义干净、可理解、可溯源、可迭代干净好理解就是没有缺失、重复、格式混乱的问题。但只做到干净是远远不够的。可理解是指数据里每个字段的含义要有明确说明。模型或人看到field_0237这种字段名时根本不知道它代表什么更别说做特征筛选。我们内部要求每张表、每个字段都要有字典级说明至少要回答三个问题这个字段是什么、取值来自哪里、单位是什么。可溯源是指每条数据都知道它从哪来。如果模型训练完发现某类数据有问题你得能快速定位到源头表和业务系统不然排查一次 badcase 要花两周。可迭代是指数据底座要能持续更新。业务在跑数据在变底座也要跟着变。我们后面第五步会详细讲版本和更新机制这里先记住一个结论一次性的数据治理不叫底座只有能持续更新的才叫底座。2.2 别把“看着能用”当成“模型能用”一个反例我常拿一个案例跟团队讲某业务方给了一份“很干净”的客服对话数据说可以拿去微调。我看了一眼每一行都是标准的“问题—答案”对格式漂亮没有空值。但真拿去训练效果极其拉胯。为什么因为这批数据有一个致命问题只有“最终答案”没有“推理过程”。客服在对话里可能经过了好几轮确认才给出答案但这份数据把中间过程全删了只剩最后一轮。模型学到的不是完整的服务逻辑而是“用户一问、客服一答”的简单映射遇到复杂问题就崩。这就是典型的“看着能用其实不能用”。AI-ready 的数据要能支撑模型的推理逻辑而不是表面上的格式工整。2.3 一张评估维度表把 AI-ready 拆成可量化的指标为了让团队在一个频道上工作我们后来把 AI-ready 拆成了五个可打分维度维度含义典型问题完整性必需字段缺失率以及缺失原因是否明确用户表手机号缺失 30%一致性同一实体在不同表/系统中的定义是否统一销售额含税不含税混用多样性覆盖的业务场景、时段、用户群是否足够丰富客服语料退款类占 70%时效性数据是否跟业务系统保持同步更新知识库三个月没更新可溯源性每行数据是否能追溯到源头系统与加工过程数据无法定位来自哪张表每个维度打分 0-5任何一项低于 3 分的数据集不允许进入模型训练或 RAG 检索流程。这套打分表执行了小半年最大的好处是业务方和数据团队不再凭感觉争论“这数据能不能用”而是在指标上对齐。3. 第一步盘清数据家底——从资产清单到接入策略第一步不做清洗也不做结构化先回答一个问题我们到底有什么数据这一步看起来最不“技术”但恰恰是整个数据底座项目里投入产出比最高的一步。数据资产盘不清后面每一步都会返工。3.1 先做一张数据资产地图我们实操时用一张表把所有数据资产列出来字段包括系统名称、数据库类型、库表名、表中文含义、行数预估、更新频率、负责人、敏感等级、是否已接入底座。表先列出来再逐项填写。这里有两个容易被忽略的细节。一个是“负责人”必须落实到人不能写部门。部门在协作时永远会互相推只有具体到人才能推动。另一个是“敏感等级”要提前打标。后面做清洗、脱敏、权限控制都要依赖这个分级。敏感等级至少分三档公开信息、内部信息、受限信息含个人隐私、财务数据、商业秘密。一线排查时我强烈建议直接连到各个数据库上看 information_schema 或等价元数据比让业务方填 Excel 可靠得多。业务方填的清单往往只覆盖他们常用的表而那些“冷门但有价值”的表恰恰需要直接从元数据层扫出来。3.2 分级筛选不是所有数据都该进底座家底盘出来之后你会发现数据量远远超出预期。全量接入不现实也没必要。我们按三层分级来决定哪些数据进底座第一层是“必须进”直接服务业务决策和高频问答的数据。比如客户信息、产品信息、订单明细、知识库文档、工单和客服记录。这些是 RAG 和微调的主力数据优先接入。第二层是“可以进”分析型数据、历史归档数据、低频参考数据。这些数据价值真实存在但模型用到的频率低可以按需分批接入不用一次性全量。第三层是“不进”临时表、日志表、备份表、测试数据。这些表要么质量极差要么包含大量无用信息接入后只会增加清洗和检索的噪音。别舍不得大概率它们只会拖慢整个流程。三级分完数据底座的范围一下子就从 400 张表缩小到 60 张表。范围可控工作量和风险都大幅下降。3.3 接入策略全量增量批式流式接入方式要提前设计不是一次性导一份全量数据就完事。我们用的是“全量初始化 增量更新”的组合首次接入跑全量建立基线之后按业务系统的更新频率同步增量数据。增量同步的关键是确定数据变更的判据。有些系统有updated_at字段可以直接用来做增量抽取没有时间戳字段的老系统就只能对比主键和关键字段的哈希值来判断哪些记录变了。这一步看似是“脏活”但决定了数据底座能不能持续而不只是一次性快照。对于实时性要求高的场景比如在线客服助手需要读取当天新产生的工单可以考虑用变更数据捕获CDC方式监听数据库日志把增量实时推到消息队列。大多数企业其实用不到这一步批式增量每天或每小时一次已经足够。4. 第二步脏数据清洗与标准化——比 Excel 删重更系统的一组动作数据资产确定、接入通道建好后才真正开始碰“脏数据”。这一步有四个标准动作缺失值处理、去重归并、格式与口径归一化、脱敏与合规。每一条都有自己的坑一个一个说。4.1 缺失值处理先分原因再填空空值处理最忌讳一刀切。我们的流程是每个关键字段的缺失率超过 5% 就要单独拉出来分析原因再决定处理策略。如果缺失是因为采集环节没拿到就需要回源补采或者用业务规则推算。比如订单表里的区域字段为空可以通过用户表的收货地址反填。如果缺失是因为业务上本就不适用则保留缺失标记不强行填补。比如个人用户和企业用户的纳税人识别号字段前者大量为空是正常现象填补反而是造假。如果缺失属于偶发可以考虑用默认值或者模型预测补齐。但预测补的值一定要打标让下游知道这是“推断值”而不是“原始值”避免模型把推断结果当成事实学习。4.2 去重归并统一实体而不是简单删行去重绝不只是按某几个字段排重那么简单。真正的难点在于把不同系统里同一个实体的记录归并起来。举个例子一张客户表里有这些写法XX科技股份有限公司、XX科技公司、XX科技(股份)有限公司、XX科技、xxkj、XX科技有限公司。肉眼能看出这是同一家公司但 SQL 去重做不到。我们的处理方式是先做字段级归一化把全角半角、括号类型、公司后缀等统一再结合统一社会信用代码、工商注册号这类强标识做主键映射。没有强标识的才用名称相似度地址信息做候选匹配。这个过程需要业务专家介入确认不能让算法单独拍板否则会把不是一家的归并在一起。这套归并做完之后要输出一份“实体主数据表”所有下游业务都通过主数据 ID 引用实体。有了这张表后续 join、检索、训练的数据一致性就有了根基。4.3 格式归一化与口径拉齐定标准、写规则、验证结果格式归一化要先定一套企业级标准而不是每个项目各定各的。日期统一为YYYY-MM-DD金额统一为“元”并保留两位小数手机号统一为不含国家码的 11 位证件号统一大写并去除分隔符。确定标准后清洗规则的执行要可重复、可审计。我最推荐的方式是写 Python 或 SQL 脚本而不是在 Excel 里手工改。举个例子一段日期归一化的 Python 代码可以写成import pandas as pd def normalize_date(value): if pd.isna(value): return None value str(value).strip() for fmt in (%Y-%m-%d, %Y/%m/%d, %Y.%m.%d, %Y%m%d): try: return pd.to_datetime(value, formatfmt).strftime(%Y-%m-%d) except ValueError: continue return None # 无法解析的单独标记交给人工处理 df[date_clean] df[date_raw].apply(normalize_date)这段代码还有一个重要细节解析不了的日期不要直接丢弃而是标记出来走人工复核。因为日期解析失败往往意味着数据有隐藏问题直接丢掉会掩盖根因。再说口径拉齐。字段语义不一致的问题不是数据清洗脚本能解决的必须做“口径映射表”明确每一个字段在企业内的标准定义。我们举过例子“销售额”在财务口径和业务口径不一样建表时就分两个字段存sales_amount_tax_incl和sales_amount_tax_excl而不是都叫sales_amount。这样模型训练时不会学到错误的等价关系。4.4 脱敏与合规处理在清洗环节就同步做脱敏放在清洗环节做是因为后面所有数据都会进入模型训练或检索链路源头上不处理后面很难补救。我们的标准做法是根据资产盘点阶段的敏感等级对受限信息做动态脱敏。姓名、手机号、证件号、银行卡号等个人敏感信息要么整体替换为合成数据要么做格式保持掩码比如手机号保留前 3 后 4 位中间用星号表示。这里要特别提醒一点脱敏不能只在导出时做一次要在数据底座内部就落地。因为训练环境和推理环境访问的数据底座的同一份数据如果底座内部不脱敏任何环节的人都能看到原始敏感信息合规风险非常大。配置权限和脱敏策略在第五步会讲到但脱敏动作必须在清洗阶段就执行。5. 第三步把数据切成模型能吃的形状——结构化、切片与样本增强清洗干净只是“原料合格”离“模型能吃”还有一道工序就是把原始数据加工成模型可以高效利用的结构。这里分三类数据分别处理结构化表格数据、非结构化文档、以及用于微调的指令样本。5.1 非结构化数据先结构化解析、版式还原、表格重建企业里大量知识沉淀在 PDF、Word、扫描件里。这些数据直接丢给模型做 RAG检索质量会非常差因为模型读到的是一团乱码或没有层级结构的纯文本。我们的处理链路是先做 OCR对扫描件再做版式解析把标题、段落、表格、页眉页脚识别出来最后输出为带结构的 Markdown 或 HTML 文本。现在开源工具已经比较成熟文档解析的效果比两年前好了一个量级但 PDF 里复杂表格的识别仍然需要人工抽检。这里有一个容易被忽略的点页眉页脚、页码、水印必须在结构化阶段就剔除。不然检索时很容易把页码或“内部资料”水印当作正文内容召回问答效果非常怪异。结构化之后每份文档建议保留三段信息正文内容、元数据标题、作者、日期、来源、分类、以及原文的引用标识。引用标识很重要因为 RAG 回答需要附上来源否则用户没法核验答案。5.2 RAG 场景的切片策略按语义切而不是按字数硬切RAG 项目里切片Chunking是所有环节中最容易被低估的技术点。很多人图省事直接按固定字符数切比如每 500 字一刀。这种硬切法会把一个完整的知识点拦腰截断检索时召回的片段语义不完整模型只能根据残缺信息作答。我们实践下来比较稳的策略是先按文档结构切以标题和段落为边界再对每个候选片段做语义完整性检查如果长度合理且表达独立意思就保留如果段落太长超过模型上下文窗口再在段落内按语义边界二次切分。切片参数要跟着模型的上下文长度走。现在主流模型的上下文窗口普遍在 8K-128K但 RAG 检索更好用的还是几个较小的片段而不是一大块。我们常用的默认值是 500-800 字左右一个块相邻块保留少量重叠20-50 字避免边界处信息被切断。切片后还要做一步去重多份文档里经常出现高度重复的段落比如同一制度的不同版本这些重复片段如果不处理检索时会被反复召回干扰模型判断。5.3 指令样本构造让模型知道“怎么用”这份数据微调或 few-shot 场景下数据需要加工成“输入-输出”对的形式。这个环节直接决定了模型的指令遵循能力。指令样本有三种常见来源真实的业务日志如客服对话、由专家编写的问答对、以及根据现有文档生成的问答对。这里有一个原则性建议优先用真实业务日志因为它们包含真实场景中的噪声和用户表达模型见过的说法越丰富上线后的泛化效果越好专家编写的问答对质量高但数量往往不够适合做补充AI 生成的问答对要经过人工审核才能进入数据集。指令样本的格式需要统一我们用的模板大致是{instruction: 根据产品文档回答用户问题, input: XX产品的保修期是多久, output: 根据产品保修政策XX产品的保修期为自签收之日起12个月。}输出里要尽量包含推理过程和依据来源不要只给结论。这样模型学到的不是死记硬背而是“引用依据来作答”的能力。6. 第四步质量评估与标注闭环——把 AI-ready 从口号变成质检线数据加工完了还不能直接进模型。我们在模型训练和 RAG 检索之前设了一道“质检线”用指标打分和人工抽检双轨并行不达标的数据一律回流重做。这一步看起来增加了工作量但它能拦下大量会在 later 阶段放大成 badcase 的数据问题。6.1 质量打分怎么做规则检查抽样复核量化评分规则检查的事情交给脚本效率高也稳定。我们在流水线里内置了几类检查规则必填字段空值率、重复记录率、日期字段格式合法率、金额字段是否越界、关键字段的取值是否在合法枚举范围内。每一项都能自动算出不合规比例。规则能发现格式和完整性问题但语义层面的质量要靠抽样复核。我们会按比例随机抽样本比如数据总量超过 10 万条就抽 1000 条由标注人员和业务专家一起评估这条数据的意思是否完整、是否准确、是否存在误导性表达。最后把规则检查结果和抽样复核结果汇总成一张质量评分表沿用第二部分定义的五个维度完整性、一致性、多样性、时效性、可溯源性逐项打分。任何一项低于 3 分的数据集不允许进入下一步。6.2 标注闭环不合格数据的回流、修正、再评估质检一定会发现不合格数据关键是不能“开一张罚单就结束”必须把不合格数据送回上游修正再重新评估。我们设计的回流流程是质检环节发现的问题数据按问题类型打标缺失、重复、语义错误、格式错误、口径冲突自动生成工单返回给对应负责人。负责人修正后数据重新进入清洗和质检流水线评分通过后才能进入数据集。这里最大的坑是回流过程没有版本控制。第一次清洗出 100 条问题数据修正后重新跑一遍流水线结果又发现 50 条新的问题数据如果版本管理混乱你会分不清当前数据集到底包含哪些修正。所以从数据底座建设的第零天就要记住每一个数据集版本都要能回放“上一版是什么、这一版改了什么”。6.3 模型辅助检查用大模型检查大模型的数据最近一年我们尝试了一个很有用的方法用大模型来辅助做数据质量检查。比如让模型判断两条客服记录是不是同一个问题或者判断一段文档的语义是否完整。对文本类数据这种辅助检查节省了大量人力。具体做法是构造一个检查 prompt把待检查数据喂给模型输出结构化结果例如{data_id: 12345, issue: 文档语义不完整包含未解析的表格, confidence: 0.87}但要强调模型辅助检查只能做粗筛不能做最终裁决关键数据仍然需要人工复核。原因是模型的判断本身可能出错如果直接按模型结果决定删不删数据会把模型的偏好引入数据底座后续模型训练时这种偏好会被进一步放大。7. 第五步把数据底座运营起来——版本、血缘、更新与安全到这一步很多团队会觉得“数据终于弄干净了”然后停下来。实际上脏数据清洗只是一次性动作AI-ready 数据底座是要长期运营的基础设施。最后这一步是把底座从“项目”变成“运营体系”的关键。7.1 数据集版本管理训练数据也要有 Git训练集、评测集、RAG 知识库都应该像代码一样管版本。每次数据变更不管是大规模清洗还是小修补都要生成新的数据集版本记录变更时间、变更人、变更内容。为什么这么重要因为模型训练过程本身就有随机性同样的代码用不同版本的数据训练效果可能差异很大。没有版本管理你就无法回答“当前效果最好的模型是用哪个版本的数据训的”这个问题。我见过不止一个团队模型效果突然变差排查三天最后发现是数据源被悄悄替换了。轻量级的做法是用现成的版本管理仓库来存数据文件的快照和变更描述更规范的做法是引入专门的数据集版本管理工具跟训练任务绑定。不管用什么工具核心原则只有一条任何一份进入模型的数据都能追溯到确切的版本号。7.2 数据血缘出问题能快速定位源头数据血缘解决的是“这条数据从哪来、经过了哪些加工”的问题。当模型出现幻觉或输出错误内容时能够从一条问题输出反推到具体是哪条训练/检索数据导致的。在数据底座建设阶段血缘不需要做到工具级的花哨可视化关键是记录三层信息数据来自哪个系统哪张表、经过了哪些清洗和转换脚本脚本版本、最终进入了哪个数据集版本。操作层可以用自动化的方式打标签每张表、每个脚本都带上版本号数据流经每个环节时自动记录。出问题时反查链路像查日志一样一路回溯即可。7.3 持续更新与权限管控底座要“活”但不能“乱”更新机制在第一步接入策略里就定了现在要把它制度化。我推荐按数据更新的紧急程度分三类实时更新如在线客服知识库、每日批更新如订单数据、按周或按月更新如政策文档、产品手册。每类数据都要有明确的更新负责人和更新 SLA。权限管控这块容易被当成“运维小事”。实际上数据底座里存储了大量脱敏后的数据、业务核心指标、知识库内容如果权限不控好内部人员可以随意导出合规风险非常高。我们的权限模型是按数据集的敏感等级划分访问层级训练任务和检索服务只能通过服务账号访问经授权的数据集个人不允许直接连库查数据。8. 工具链与团队配置我实际用的组合与踩过的坑最后分享一下支撑这套流程的工具组合和团队配置顺便聊几个印象深刻的坑。工具不追求大而全以轻量、可控、能跑起来为原则。8.1 从轻量组合起步不必一上来就买平台我们第一套组合很朴素Python Pandas 做清洗和加工SQL 做数据探查Airflow 或简单的定时任务做调度向量数据库做 RAG 检索的存储。这套组合完全开源、成本可控足够支撑几十万到几百万量级的数据底座。当数据量和复杂度上来了再考虑引入更重的平台能力比如数据质量管理、血缘可视化、训练数据版本管理等功能模块。但我不建议项目起步阶段就直接上重型数据平台——流程还没跑通之前重平台的配置成本会吃掉你本来就不多的精力。选型时有一个关键判断标准工具能不能被代码化描述。凡是只能通过界面操作、没有办法用配置来复现的工具都不要选。数据底座的每一步应该能通过脚本或配置文件重现而不是依赖某个人记得在界面上点了什么。8.2 团队配置业务专家和数据工程师缺一不可五步工程化做下来最耗时不是写代码而是跟业务对口径。所以团队里绝对不能只有数据工程师和算法工程师必须有业务专家全程参与。业务专家主要干三件事口径校准比如“销售额”含税不含税、归并结果的确认比如两家公司是不是同一家、以及指令样本的编写与审核。没有业务专家清洗出来的数据很可能“技术上很干净、业务上不能用”。数据工程师负责数据接入、清洗、调度等工程实现。算法工程师负责定义模型需要什么形态的数据并参与质量评估。这么小的团队3-5人就能跑通前面说的五步方法论不需要等组织层面搭完一堆平台再开工。8.3 几个让我印象深刻的坑第一个坑是清洗规则没有版本管理。早期我们改清洗脚本直接用线上文件改改完就跑结果跑出来的数据结果没留底。后来发现某版数据有问题想对比修改前后差异完全无从查起。现在我们的所有清洗脚本都进版本库跑批结果也带版本号绝不会再犯。第二个坑是只重视训练集忽略了评测集。有一次微调完模型业务方反馈效果挺好我们就直接部署了。结果线上评测跑分的时候发现完全不是一回事后来才发现评测集是从训练集里随机抽的数据分布完全一致等于开卷考试。从那以后我们要求评测集必须来自不同时间段、不同用户群的数据确保模型是真的泛化了。第三个坑是切片的“理想化”。我们早期做 RAG 的时候设计了非常复杂的切片策略结果上线后检索延迟高得离谱一问 5 秒。后来把策略简化先按段落切、再按长度微调延迟压回 800ms 以内。这个教训是数据加工服务于应用指标不能只顾数据侧的完美忽略了模型侧的时延和成本约束。第四个坑是脱敏策略过度导致合成数据比例太高。为了合规我们把客户名称、联系方式全替换成合成数据结果模型训练出来之后对真实的业务命名风格完全不敏感。后来调整策略保留格式特征、替换具体敏感值效果才正常。脱敏必须平衡合规性和数据真实性这条边界需要用实际效果来校准。我个人这套实践做了两年最大的体会是大模型项目能不能成七分在数据、两分在工程、一分才在模型。五步方法论的每一步都不算高深难的是把它坚持做成一个持续运营的体系。如果你现在正被“数据喂不饱模型”的问题困扰建议不要急着换更强的模型先停下来照着这五步把数据底座老老实实搭一遍大概率比你想象的更管用。 
长河君 · 2026/10/26 20:10:52 · 阅读 1.2k 从脏数据到AI-ready数据底座：企业大模型落地的五步工程法
这两年我在企业里做大模型落地的项目比较多一个感受越来越强烈大模型本身已经不是瓶颈瓶颈在数据。经常遇到的情况是业务方兴冲冲拉了几张表过来说要微调模型、要建知识库结果我一打开数据文件心里就凉了半截——光日期格式就有四种同一个客户名称在一张表里能出现六个写法有的字段一半以上是空的。这种脏数据直接喂给大模型效果可想而知。后来我们慢慢摸索出一套从脏数据到 AI-ready 数据底座的工程化方法一共五步每一步都有明确的动作和验收标准。这篇文章就把这套实践完整整理出来适合正在做企业大模型私有化部署、RAG 知识库、微调训练但被数据问题卡住的数据工程师和算法工程师参考。1. 企业数据为什么“喂不饱”大模型先看清四个典型病灶很多团队把精力全放在模型选型和 prompt 调优上数据问题往往被归咎为“数据很脏清洗一下就行”。但真到动手的时候才发现清洗不是最难的最难的是说不清楚企业数据到底有什么、在哪、谁负责、质量怎么样。这里有四个典型病灶几乎每家企业都能对号入座。1.1 数据资产像“黑洞”你知道数据存在但不知道有多少大企业通常有几十套业务系统CRM、ERP、呼叫中心、工单系统、财务系统、自研的运营后台。每套系统都有自己的数据库甚至同一套系统在不同时期用了不同的数据库实例。平时各系统各跑各的没人有全局视图。我见过一家零售企业IT 部门给出的数据资产清单只有 20 张核心表但实际排查下来光 MySQL 实例就有十多个还有一批 Oracle 老库和 ClickHouse 分析库真正有价值的数据资产超过 400 张表。为什么差距这么大因为很多数据藏在“无人认领”的临时表、日志表、备份库里连业务负责人都不一定知道这些表是干什么用的。这个问题的本质是没有盘点就没有边界。不知道数据资产边界后面所有清洗、标注、治理都是空中楼阁。1.2 数据脏在四个地方缺失、重复、口径不一、格式混乱缺什么最典型的是关键字段缺失。用户表里手机号缺失率 30%订单表里区域字段 40% 为空。缺失不是最可怕的最可怕的是你不知道为什么缺失——是采集时没拿到还是业务上本来就不该有两种情况的处理方式完全不同。重复也很普遍。我见过同一批客户数据从不同系统导出后 join 出来 120 万行去重后只剩 68 万行。重复的根源往往在于没有统一的主数据管理同一个实体在多个系统里被重复创建ID 体系互不打通。口径不一属于最隐蔽的脏。同样是“销售额”财务系统里是含税口径业务系统里是不含税口径同样是“用户活跃”A 系统按登录次数定义B 系统按在线时长定义。这些字段名一样语义却不一致模型学到的就是错乱的关系。格式混乱是最直观的脏。日期有2024/01/05、2024-01-05、2024.01.05、20240105四种写法手机号有的带国家码、有的不带金额有的存元、有的存万元、有的存分。这些格式问题看起来简单但量一上来就是灾难。1.3 直接拿脏数据喂模型的三个后果幻觉、偏见、知识陈旧脏数据进模型最直接的表现是幻觉变多。我排查过几个 RAG 问答项目的 badcase根因几乎都是知识库里的文档本身互相矛盾——两篇文档对同一政策条款的表述不一致检索出来之后模型就“自由发挥”了。第二个后果是数据偏见被放大。如果训练数据里某个城市、某个品类的样本占比过高模型会把这些局部规律当成全局规律。比如客服语料里退款类问题占了 70%模型就很容易把所有用户意图都往退款上归类。第三个后果是知识陈旧。很多企业的数据底座是一次性导出的之后业务系统继续跑数据底座纹丝不动。模型回答问题用的永远是三个月前的数据这在营销、供应链场景里基本等于废数据。这四个病灶叠加才是“喂不饱”的真正含义——不是数据量不够而是数据质量不够、组织不够、更新不够。2. AI-ready 数据到底是个什么标准先定义再动手“AI-ready”这个词这两年被讲得很多但我发现多数人对它的理解停留在“数据很干净”这个层面。实际上干净只是基础AI-ready 是一套复合标准。2.1 我用的定义干净、可理解、可溯源、可迭代干净好理解就是没有缺失、重复、格式混乱的问题。但只做到干净是远远不够的。可理解是指数据里每个字段的含义要有明确说明。模型或人看到field_0237这种字段名时根本不知道它代表什么更别说做特征筛选。我们内部要求每张表、每个字段都要有字典级说明至少要回答三个问题这个字段是什么、取值来自哪里、单位是什么。可溯源是指每条数据都知道它从哪来。如果模型训练完发现某类数据有问题你得能快速定位到源头表和业务系统不然排查一次 badcase 要花两周。可迭代是指数据底座要能持续更新。业务在跑数据在变底座也要跟着变。我们后面第五步会详细讲版本和更新机制这里先记住一个结论一次性的数据治理不叫底座只有能持续更新的才叫底座。2.2 别把“看着能用”当成“模型能用”一个反例我常拿一个案例跟团队讲某业务方给了一份“很干净”的客服对话数据说可以拿去微调。我看了一眼每一行都是标准的“问题—答案”对格式漂亮没有空值。但真拿去训练效果极其拉胯。为什么因为这批数据有一个致命问题只有“最终答案”没有“推理过程”。客服在对话里可能经过了好几轮确认才给出答案但这份数据把中间过程全删了只剩最后一轮。模型学到的不是完整的服务逻辑而是“用户一问、客服一答”的简单映射遇到复杂问题就崩。这就是典型的“看着能用其实不能用”。AI-ready 的数据要能支撑模型的推理逻辑而不是表面上的格式工整。2.3 一张评估维度表把 AI-ready 拆成可量化的指标为了让团队在一个频道上工作我们后来把 AI-ready 拆成了五个可打分维度维度含义典型问题完整性必需字段缺失率以及缺失原因是否明确用户表手机号缺失 30%一致性同一实体在不同表/系统中的定义是否统一销售额含税不含税混用多样性覆盖的业务场景、时段、用户群是否足够丰富客服语料退款类占 70%时效性数据是否跟业务系统保持同步更新知识库三个月没更新可溯源性每行数据是否能追溯到源头系统与加工过程数据无法定位来自哪张表每个维度打分 0-5任何一项低于 3 分的数据集不允许进入模型训练或 RAG 检索流程。这套打分表执行了小半年最大的好处是业务方和数据团队不再凭感觉争论“这数据能不能用”而是在指标上对齐。3. 第一步盘清数据家底——从资产清单到接入策略第一步不做清洗也不做结构化先回答一个问题我们到底有什么数据这一步看起来最不“技术”但恰恰是整个数据底座项目里投入产出比最高的一步。数据资产盘不清后面每一步都会返工。3.1 先做一张数据资产地图我们实操时用一张表把所有数据资产列出来字段包括系统名称、数据库类型、库表名、表中文含义、行数预估、更新频率、负责人、敏感等级、是否已接入底座。表先列出来再逐项填写。这里有两个容易被忽略的细节。一个是“负责人”必须落实到人不能写部门。部门在协作时永远会互相推只有具体到人才能推动。另一个是“敏感等级”要提前打标。后面做清洗、脱敏、权限控制都要依赖这个分级。敏感等级至少分三档公开信息、内部信息、受限信息含个人隐私、财务数据、商业秘密。一线排查时我强烈建议直接连到各个数据库上看 information_schema 或等价元数据比让业务方填 Excel 可靠得多。业务方填的清单往往只覆盖他们常用的表而那些“冷门但有价值”的表恰恰需要直接从元数据层扫出来。3.2 分级筛选不是所有数据都该进底座家底盘出来之后你会发现数据量远远超出预期。全量接入不现实也没必要。我们按三层分级来决定哪些数据进底座第一层是“必须进”直接服务业务决策和高频问答的数据。比如客户信息、产品信息、订单明细、知识库文档、工单和客服记录。这些是 RAG 和微调的主力数据优先接入。第二层是“可以进”分析型数据、历史归档数据、低频参考数据。这些数据价值真实存在但模型用到的频率低可以按需分批接入不用一次性全量。第三层是“不进”临时表、日志表、备份表、测试数据。这些表要么质量极差要么包含大量无用信息接入后只会增加清洗和检索的噪音。别舍不得大概率它们只会拖慢整个流程。三级分完数据底座的范围一下子就从 400 张表缩小到 60 张表。范围可控工作量和风险都大幅下降。3.3 接入策略全量增量批式流式接入方式要提前设计不是一次性导一份全量数据就完事。我们用的是“全量初始化 增量更新”的组合首次接入跑全量建立基线之后按业务系统的更新频率同步增量数据。增量同步的关键是确定数据变更的判据。有些系统有updated_at字段可以直接用来做增量抽取没有时间戳字段的老系统就只能对比主键和关键字段的哈希值来判断哪些记录变了。这一步看似是“脏活”但决定了数据底座能不能持续而不只是一次性快照。对于实时性要求高的场景比如在线客服助手需要读取当天新产生的工单可以考虑用变更数据捕获CDC方式监听数据库日志把增量实时推到消息队列。大多数企业其实用不到这一步批式增量每天或每小时一次已经足够。4. 第二步脏数据清洗与标准化——比 Excel 删重更系统的一组动作数据资产确定、接入通道建好后才真正开始碰“脏数据”。这一步有四个标准动作缺失值处理、去重归并、格式与口径归一化、脱敏与合规。每一条都有自己的坑一个一个说。4.1 缺失值处理先分原因再填空空值处理最忌讳一刀切。我们的流程是每个关键字段的缺失率超过 5% 就要单独拉出来分析原因再决定处理策略。如果缺失是因为采集环节没拿到就需要回源补采或者用业务规则推算。比如订单表里的区域字段为空可以通过用户表的收货地址反填。如果缺失是因为业务上本就不适用则保留缺失标记不强行填补。比如个人用户和企业用户的纳税人识别号字段前者大量为空是正常现象填补反而是造假。如果缺失属于偶发可以考虑用默认值或者模型预测补齐。但预测补的值一定要打标让下游知道这是“推断值”而不是“原始值”避免模型把推断结果当成事实学习。4.2 去重归并统一实体而不是简单删行去重绝不只是按某几个字段排重那么简单。真正的难点在于把不同系统里同一个实体的记录归并起来。举个例子一张客户表里有这些写法XX科技股份有限公司、XX科技公司、XX科技(股份)有限公司、XX科技、xxkj、XX科技有限公司。肉眼能看出这是同一家公司但 SQL 去重做不到。我们的处理方式是先做字段级归一化把全角半角、括号类型、公司后缀等统一再结合统一社会信用代码、工商注册号这类强标识做主键映射。没有强标识的才用名称相似度地址信息做候选匹配。这个过程需要业务专家介入确认不能让算法单独拍板否则会把不是一家的归并在一起。这套归并做完之后要输出一份“实体主数据表”所有下游业务都通过主数据 ID 引用实体。有了这张表后续 join、检索、训练的数据一致性就有了根基。4.3 格式归一化与口径拉齐定标准、写规则、验证结果格式归一化要先定一套企业级标准而不是每个项目各定各的。日期统一为YYYY-MM-DD金额统一为“元”并保留两位小数手机号统一为不含国家码的 11 位证件号统一大写并去除分隔符。确定标准后清洗规则的执行要可重复、可审计。我最推荐的方式是写 Python 或 SQL 脚本而不是在 Excel 里手工改。举个例子一段日期归一化的 Python 代码可以写成import pandas as pd def normalize_date(value): if pd.isna(value): return None value str(value).strip() for fmt in (%Y-%m-%d, %Y/%m/%d, %Y.%m.%d, %Y%m%d): try: return pd.to_datetime(value, formatfmt).strftime(%Y-%m-%d) except ValueError: continue return None # 无法解析的单独标记交给人工处理 df[date_clean] df[date_raw].apply(normalize_date)这段代码还有一个重要细节解析不了的日期不要直接丢弃而是标记出来走人工复核。因为日期解析失败往往意味着数据有隐藏问题直接丢掉会掩盖根因。再说口径拉齐。字段语义不一致的问题不是数据清洗脚本能解决的必须做“口径映射表”明确每一个字段在企业内的标准定义。我们举过例子“销售额”在财务口径和业务口径不一样建表时就分两个字段存sales_amount_tax_incl和sales_amount_tax_excl而不是都叫sales_amount。这样模型训练时不会学到错误的等价关系。4.4 脱敏与合规处理在清洗环节就同步做脱敏放在清洗环节做是因为后面所有数据都会进入模型训练或检索链路源头上不处理后面很难补救。我们的标准做法是根据资产盘点阶段的敏感等级对受限信息做动态脱敏。姓名、手机号、证件号、银行卡号等个人敏感信息要么整体替换为合成数据要么做格式保持掩码比如手机号保留前 3 后 4 位中间用星号表示。这里要特别提醒一点脱敏不能只在导出时做一次要在数据底座内部就落地。因为训练环境和推理环境访问的数据底座的同一份数据如果底座内部不脱敏任何环节的人都能看到原始敏感信息合规风险非常大。配置权限和脱敏策略在第五步会讲到但脱敏动作必须在清洗阶段就执行。5. 第三步把数据切成模型能吃的形状——结构化、切片与样本增强清洗干净只是“原料合格”离“模型能吃”还有一道工序就是把原始数据加工成模型可以高效利用的结构。这里分三类数据分别处理结构化表格数据、非结构化文档、以及用于微调的指令样本。5.1 非结构化数据先结构化解析、版式还原、表格重建企业里大量知识沉淀在 PDF、Word、扫描件里。这些数据直接丢给模型做 RAG检索质量会非常差因为模型读到的是一团乱码或没有层级结构的纯文本。我们的处理链路是先做 OCR对扫描件再做版式解析把标题、段落、表格、页眉页脚识别出来最后输出为带结构的 Markdown 或 HTML 文本。现在开源工具已经比较成熟文档解析的效果比两年前好了一个量级但 PDF 里复杂表格的识别仍然需要人工抽检。这里有一个容易被忽略的点页眉页脚、页码、水印必须在结构化阶段就剔除。不然检索时很容易把页码或“内部资料”水印当作正文内容召回问答效果非常怪异。结构化之后每份文档建议保留三段信息正文内容、元数据标题、作者、日期、来源、分类、以及原文的引用标识。引用标识很重要因为 RAG 回答需要附上来源否则用户没法核验答案。5.2 RAG 场景的切片策略按语义切而不是按字数硬切RAG 项目里切片Chunking是所有环节中最容易被低估的技术点。很多人图省事直接按固定字符数切比如每 500 字一刀。这种硬切法会把一个完整的知识点拦腰截断检索时召回的片段语义不完整模型只能根据残缺信息作答。我们实践下来比较稳的策略是先按文档结构切以标题和段落为边界再对每个候选片段做语义完整性检查如果长度合理且表达独立意思就保留如果段落太长超过模型上下文窗口再在段落内按语义边界二次切分。切片参数要跟着模型的上下文长度走。现在主流模型的上下文窗口普遍在 8K-128K但 RAG 检索更好用的还是几个较小的片段而不是一大块。我们常用的默认值是 500-800 字左右一个块相邻块保留少量重叠20-50 字避免边界处信息被切断。切片后还要做一步去重多份文档里经常出现高度重复的段落比如同一制度的不同版本这些重复片段如果不处理检索时会被反复召回干扰模型判断。5.3 指令样本构造让模型知道“怎么用”这份数据微调或 few-shot 场景下数据需要加工成“输入-输出”对的形式。这个环节直接决定了模型的指令遵循能力。指令样本有三种常见来源真实的业务日志如客服对话、由专家编写的问答对、以及根据现有文档生成的问答对。这里有一个原则性建议优先用真实业务日志因为它们包含真实场景中的噪声和用户表达模型见过的说法越丰富上线后的泛化效果越好专家编写的问答对质量高但数量往往不够适合做补充AI 生成的问答对要经过人工审核才能进入数据集。指令样本的格式需要统一我们用的模板大致是{instruction: 根据产品文档回答用户问题, input: XX产品的保修期是多久, output: 根据产品保修政策XX产品的保修期为自签收之日起12个月。}输出里要尽量包含推理过程和依据来源不要只给结论。这样模型学到的不是死记硬背而是“引用依据来作答”的能力。6. 第四步质量评估与标注闭环——把 AI-ready 从口号变成质检线数据加工完了还不能直接进模型。我们在模型训练和 RAG 检索之前设了一道“质检线”用指标打分和人工抽检双轨并行不达标的数据一律回流重做。这一步看起来增加了工作量但它能拦下大量会在 later 阶段放大成 badcase 的数据问题。6.1 质量打分怎么做规则检查抽样复核量化评分规则检查的事情交给脚本效率高也稳定。我们在流水线里内置了几类检查规则必填字段空值率、重复记录率、日期字段格式合法率、金额字段是否越界、关键字段的取值是否在合法枚举范围内。每一项都能自动算出不合规比例。规则能发现格式和完整性问题但语义层面的质量要靠抽样复核。我们会按比例随机抽样本比如数据总量超过 10 万条就抽 1000 条由标注人员和业务专家一起评估这条数据的意思是否完整、是否准确、是否存在误导性表达。最后把规则检查结果和抽样复核结果汇总成一张质量评分表沿用第二部分定义的五个维度完整性、一致性、多样性、时效性、可溯源性逐项打分。任何一项低于 3 分的数据集不允许进入下一步。6.2 标注闭环不合格数据的回流、修正、再评估质检一定会发现不合格数据关键是不能“开一张罚单就结束”必须把不合格数据送回上游修正再重新评估。我们设计的回流流程是质检环节发现的问题数据按问题类型打标缺失、重复、语义错误、格式错误、口径冲突自动生成工单返回给对应负责人。负责人修正后数据重新进入清洗和质检流水线评分通过后才能进入数据集。这里最大的坑是回流过程没有版本控制。第一次清洗出 100 条问题数据修正后重新跑一遍流水线结果又发现 50 条新的问题数据如果版本管理混乱你会分不清当前数据集到底包含哪些修正。所以从数据底座建设的第零天就要记住每一个数据集版本都要能回放“上一版是什么、这一版改了什么”。6.3 模型辅助检查用大模型检查大模型的数据最近一年我们尝试了一个很有用的方法用大模型来辅助做数据质量检查。比如让模型判断两条客服记录是不是同一个问题或者判断一段文档的语义是否完整。对文本类数据这种辅助检查节省了大量人力。具体做法是构造一个检查 prompt把待检查数据喂给模型输出结构化结果例如{data_id: 12345, issue: 文档语义不完整包含未解析的表格, confidence: 0.87}但要强调模型辅助检查只能做粗筛不能做最终裁决关键数据仍然需要人工复核。原因是模型的判断本身可能出错如果直接按模型结果决定删不删数据会把模型的偏好引入数据底座后续模型训练时这种偏好会被进一步放大。7. 第五步把数据底座运营起来——版本、血缘、更新与安全到这一步很多团队会觉得“数据终于弄干净了”然后停下来。实际上脏数据清洗只是一次性动作AI-ready 数据底座是要长期运营的基础设施。最后这一步是把底座从“项目”变成“运营体系”的关键。7.1 数据集版本管理训练数据也要有 Git训练集、评测集、RAG 知识库都应该像代码一样管版本。每次数据变更不管是大规模清洗还是小修补都要生成新的数据集版本记录变更时间、变更人、变更内容。为什么这么重要因为模型训练过程本身就有随机性同样的代码用不同版本的数据训练效果可能差异很大。没有版本管理你就无法回答“当前效果最好的模型是用哪个版本的数据训的”这个问题。我见过不止一个团队模型效果突然变差排查三天最后发现是数据源被悄悄替换了。轻量级的做法是用现成的版本管理仓库来存数据文件的快照和变更描述更规范的做法是引入专门的数据集版本管理工具跟训练任务绑定。不管用什么工具核心原则只有一条任何一份进入模型的数据都能追溯到确切的版本号。7.2 数据血缘出问题能快速定位源头数据血缘解决的是“这条数据从哪来、经过了哪些加工”的问题。当模型出现幻觉或输出错误内容时能够从一条问题输出反推到具体是哪条训练/检索数据导致的。在数据底座建设阶段血缘不需要做到工具级的花哨可视化关键是记录三层信息数据来自哪个系统哪张表、经过了哪些清洗和转换脚本脚本版本、最终进入了哪个数据集版本。操作层可以用自动化的方式打标签每张表、每个脚本都带上版本号数据流经每个环节时自动记录。出问题时反查链路像查日志一样一路回溯即可。7.3 持续更新与权限管控底座要“活”但不能“乱”更新机制在第一步接入策略里就定了现在要把它制度化。我推荐按数据更新的紧急程度分三类实时更新如在线客服知识库、每日批更新如订单数据、按周或按月更新如政策文档、产品手册。每类数据都要有明确的更新负责人和更新 SLA。权限管控这块容易被当成“运维小事”。实际上数据底座里存储了大量脱敏后的数据、业务核心指标、知识库内容如果权限不控好内部人员可以随意导出合规风险非常高。我们的权限模型是按数据集的敏感等级划分访问层级训练任务和检索服务只能通过服务账号访问经授权的数据集个人不允许直接连库查数据。8. 工具链与团队配置我实际用的组合与踩过的坑最后分享一下支撑这套流程的工具组合和团队配置顺便聊几个印象深刻的坑。工具不追求大而全以轻量、可控、能跑起来为原则。8.1 从轻量组合起步不必一上来就买平台我们第一套组合很朴素Python Pandas 做清洗和加工SQL 做数据探查Airflow 或简单的定时任务做调度向量数据库做 RAG 检索的存储。这套组合完全开源、成本可控足够支撑几十万到几百万量级的数据底座。当数据量和复杂度上来了再考虑引入更重的平台能力比如数据质量管理、血缘可视化、训练数据版本管理等功能模块。但我不建议项目起步阶段就直接上重型数据平台——流程还没跑通之前重平台的配置成本会吃掉你本来就不多的精力。选型时有一个关键判断标准工具能不能被代码化描述。凡是只能通过界面操作、没有办法用配置来复现的工具都不要选。数据底座的每一步应该能通过脚本或配置文件重现而不是依赖某个人记得在界面上点了什么。8.2 团队配置业务专家和数据工程师缺一不可五步工程化做下来最耗时不是写代码而是跟业务对口径。所以团队里绝对不能只有数据工程师和算法工程师必须有业务专家全程参与。业务专家主要干三件事口径校准比如“销售额”含税不含税、归并结果的确认比如两家公司是不是同一家、以及指令样本的编写与审核。没有业务专家清洗出来的数据很可能“技术上很干净、业务上不能用”。数据工程师负责数据接入、清洗、调度等工程实现。算法工程师负责定义模型需要什么形态的数据并参与质量评估。这么小的团队3-5人就能跑通前面说的五步方法论不需要等组织层面搭完一堆平台再开工。8.3 几个让我印象深刻的坑第一个坑是清洗规则没有版本管理。早期我们改清洗脚本直接用线上文件改改完就跑结果跑出来的数据结果没留底。后来发现某版数据有问题想对比修改前后差异完全无从查起。现在我们的所有清洗脚本都进版本库跑批结果也带版本号绝不会再犯。第二个坑是只重视训练集忽略了评测集。有一次微调完模型业务方反馈效果挺好我们就直接部署了。结果线上评测跑分的时候发现完全不是一回事后来才发现评测集是从训练集里随机抽的数据分布完全一致等于开卷考试。从那以后我们要求评测集必须来自不同时间段、不同用户群的数据确保模型是真的泛化了。第三个坑是切片的“理想化”。我们早期做 RAG 的时候设计了非常复杂的切片策略结果上线后检索延迟高得离谱一问 5 秒。后来把策略简化先按段落切、再按长度微调延迟压回 800ms 以内。这个教训是数据加工服务于应用指标不能只顾数据侧的完美忽略了模型侧的时延和成本约束。第四个坑是脱敏策略过度导致合成数据比例太高。为了合规我们把客户名称、联系方式全替换成合成数据结果模型训练出来之后对真实的业务命名风格完全不敏感。后来调整策略保留格式特征、替换具体敏感值效果才正常。脱敏必须平衡合规性和数据真实性这条边界需要用实际效果来校准。我个人这套实践做了两年最大的体会是大模型项目能不能成七分在数据、两分在工程、一分才在模型。五步方法论的每一步都不算高深难的是把它坚持做成一个持续运营的体系。如果你现在正被“数据喂不饱模型”的问题困扰建议不要急着换更强的模型先停下来照着这五步把数据底座老老实实搭一遍大概率比你想象的更管用。