AI’s Latest Rocket Ship Is an Old School, 28-Year-Old Data Company。这个英文标题放在新闻里意思是AI 这轮最被资本看好的不一定是成立两三年的大模型新贵反而可能是一家已经做了 28 年数据生意、看起来并不新潮的老公司。很多人第一反应是“老公司蹭上 AI 概念”但我更愿意把它当成一个工程现象来看大模型的技术门槛正在快速降低真正供不应求的是干净、稳定、合法且能持续更新的数据以及把数据送进模型的那条管道。老派数据公司不缺算法明星但它有几十年的数据资产、客户关系和业务语义这些东西正好是 AI 落地的底座。这篇内容不聊股价也不猜测具体标的。对普通技术团队来说更值得研究的是另一个问题当一家积累了几十年的数据公司被 AI 重新推到台前它的哪些能力可以复制哪些坑不值得踩。我会按实际落地顺序拆先讲数据为什么成了 AI 的瓶颈再讲数据工程各环节怎么判断质量然后给一套小团队能上手的数据底座方案最后讲模型效果不好时怎么从数据侧排查以及什么时候不该学老公司搭重平台。1. 为什么 AI 越火老牌数据公司越值钱1.1 大模型不缺参数缺的是有授权、能持续更新的数据过去两年模型侧的迭代速度非常快。开源模型越出越多指令微调、量化部署、Agent 编排这些东西也越来越成熟。团队想用一个强大的基础模型已经没有太高的门槛真正难的是让模型理解“你的数据”。这里的难点主要在两层第一层是数据授权。企业数据不是拿来就能用的。用户隐私、内部报表、医疗记录、金融流水每一类都要先确认能不能入库、能不能用于训练、能不能对外开放。很多 AI 项目的起步工作不是写代码而是梳理数据权限。第二层是数据更新频率。大模型的训练语料再大也不可能知道你们公司上周刚发生的事。要想让 AI 在业务里真正有用必须把企业业务系统的数据持续同步给模型或者通过检索增强的方式把最新数据喂进去。这需要数据管道、增量同步、质量监控和版本回溯缺一个都不行。老牌数据公司正好同时满足这两个条件。它经营了几十年手里的数据不是“硬盘里堆着的一堆文件”而是已经跑过授权、清洗、建模、报表发布流程的规范化数据资产。这些东西在大模型出现之前叫“数据仓库”在大模型时代变成了“上下文”。所以AI 越火这类数据公司越容易被重新定价。不是因为它突然掌握了什么黑科技而是因为过去几十年它在最枯燥的数据治理环节上投入太多而这些积累现在成了稀缺资源。1.2 老派数据公司真正的壁垒业务语义和数据管线很多人以为老派数据公司值钱是因为“存了很多数据”。这个理解不完整。数据存量只是基础真正值钱的是业务语义。举个例子。一家做供应链管理的老公司它的数据库里可能存着几十个业务表采购单、供应商、库存、物流、退货。表面看这就是几组字段但如果这家公司做了二十年这些字段背后藏着大量业务规则哪些供应商是备用供应商哪些库存状态意味着风险哪些退款原因属于异常甚至不同年份的字段口径有什么变化。这些规则通常不会写进模型论文里而是沉淀在数据字典、ETL 脚本、报表口径和一线业务人员的经验里。大模型如果要处理企业问题缺失的往往就是这个“业务语义层”。让大模型直接读原始数据库它只能理解字段名理解不了公司的业务上下文。所以现在很多团队在做 AI 知识库时不直接灌数据库而是先整理业务口径、字段说明、使用规则和常见问答再把这些内容做成向量索引或提示词上下文。老牌数据公司最擅长做的就是这个。它不需要从零发明只需要把几十年的数据字典、客户使用场景和业务规则结构化再包一层大模型接口。这也是为什么“老”在这里不是劣势反而是某种先发优势。1.3 从“故事”回到工程数据资产重新被定价市场怎么给这类公司估值不是技术博主能判断的事也不构成任何操作建议。但有一点值得技术团队关注数据资产正在被重新当作核心资产来看待。前几年大家谈数据中台很多公司搭了一堆平台最后变成“中台空转”。原因不是数据中台没用而是当时的业务侧没有足够强的消耗场景。模型不复杂报表跑得动自然没人关心数据质量。现在不一样了AI 应用对数据的需求是实时的、多轮次的、需要返工的。数据质量稍微差一点模型输出就会变得不可信。所以这轮 AI 热潮给技术团队提出一个非常现实的要求把数据资产的盘点、授权、清洗、质量基线、更新频率和血缘关系当成基础设施来建设。这不是老公司的专利而是所有想认真落地 AI 的团队都绕不开的功课。2. AI 项目真正卡脖子的数据工程环节2.1 从原始数据到模型输出中间隔着多层工程很多第一次做 AI 项目的团队会默认“数据到位后直接丢给大模型”。这在实际落地时很难走通。完整的链路通常长这样原始数据采集 → 数据清洗 → 结构化转换 → 数据质量校验 → 特征提取或文本分块 → 向量化或建模 → 模型推理 → 输出校验 → 日志回流 → 持续更新。老牌数据公司的强项集中在前半段它知道怎么从 ERP、CRM、财务系统、日志文件里把数据抽出来怎么在清洗时处理乱码和缺失值怎么建立一张宽表让业务指标口径统一。这些工作看起来不性感但如果没有做后面所有环节都会不停返工。我在实际项目里见过太多类似问题业务同事说“数据都导出来了”结果一看几十个 Excel 表字段名相同但含义不同建模同事说“模型效果不好”最后发现训练集和线上实时数据的字段分布差异巨大。这些问题不是模型能修的只能靠数据工程一层层修。2.2 数据质量不会直接报错但模型会替你“报错”代码写错了会有异常依赖装不上会有报错但数据质量差不会马上红牌警告。它通常会变成另一种表现模型输出内容奇怪、回答不一致、偶尔答非所问、同样的提问过两天结果明显漂移。判断数据质量不能只看“能不能跑”要有一套可量化的维度。下面是我常用的几个维度数据质量维度判断标准常见表现完整性关键字段缺失率是否异常主键、时间戳、业务字段是否为空模型输入特征大量缺失回答内容跳变准确性抽样核对数据是否与真实业务一致报表和数据库对不上模型引用错误信息一致性同一业务在不同表、不同系统中的口径是否一致join 后数据量暴增或缩水统计结果冲突时效性数据是否在预期时间范围内更新模型回答用了过期数据业务判断滞后唯一性同一实体是否有多条重复记录用户数、订单量等统计被放大合规性数据是否有授权、脱敏、隐私保护数据不能入库或使用甚至引发合规问题这六个维度不需要一次性全部做到完美但至少要明确“当前数据在哪几个维度上可用在哪几个维度上不可用”。否则模型上线后出了问题很难定位是模型问题还是数据问题。2.3 小团队怎么先估算数据工程的资源成本数据工程的资源成本没有统一答案因为团队规模、数据量、网络环境和业务复杂度都不一样。但可以按数据规模先做一个粗略判断数据规模存储侧重处理侧重是否适合先试大模型几千行 CSV本地或对象存储基本不用做复杂处理可以直接做概念验证百万级订单流水需要考虑分区和索引需要清洗、去重、聚合可以先跑小样本再逐步扩展TB 级日志需要考虑冷热分层和压缩需要任务调度、增量处理、质量监控一定要先治理再谈训练或知识库这里最容易犯的错误是“为了上项目先搭个大平台”。如果数据量只有几千行直接用本地 Python 脚本处理就行没必要引入一套分布式计算框架。反之如果数据量已经到 TB 级还要用 Excel 手动清洗那就不是效率问题而是根本做不完。合理做法是先看数据量级再决定用什么工具而不是反过来。3. 先搭一套能跑的数据底座再考虑大模型3.1 最小可用数据管道的组件和流程对普通团队来说不一定要复制老牌公司几十年的重型架构但可以搭一套最小可用数据管道。一般包含这几块数据源数据库、日志文件、接口、对象存储中的原始数据。存储层本地磁盘、OSS/S3/MinIO放原始数据和加工后数据。加工层用 Python、SQL 或轻量计算引擎做清洗和聚合。调度层定时任务或工作流编排工具负责驱动管道运行。质量检查层记录每个表的行数、更新时间、缺失率、重复率生成质检报告。元数据登记层用一张表记录数据字典、字段口径、负责人和更新频率。小规模场景不需要把所有组件一次性上齐。我建议从一条最核心的数据链路开始比如“业务表 → 清洗脚本 → 结果表 → 质检报告 → 业务查询”。先跑通再加调度最后再补血缘和权限。3.2 接入大模型前强制做三层检查把数据管道搭好之后不要急着接大模型。先做三层强制检查每一层都有明确的判断标准。第一层权限与合规检查。确认数据来源是否合法是否经过授权是否包含个人敏感信息是否做了脱敏。只要有一项不确定就不要进入下一层。这一层不过关后续所有技术能力都没有意义。第二层可检索性检查。文本类数据是否做了分块结构化数据是否能按关键字段过滤查询接口是否能返回结果。如果数据在管道里只是“存起来了”但模型无法检索到那等于没有。第三层数据基线检查。抽样看数据分布记录空值率、重复率、时间范围、主键唯一性保存一份基线报告。下次再跑只要基线出现明显变化就能快速发现问题。下面是通用的检查清单格式可以按自己的项目改字段检查项判断标准结果数据源授权已确认可合法使用是 / 否敏感信息已脱敏或不能明文入库是 / 否字段缺失率关键字段缺失率低于预期基线是 / 否重复记录主键唯一性满足业务要求是 / 否时间范围数据覆盖预期区间是 / 否更新频率定时任务可以稳定产出最新数据是 / 否这层检查不会占用太多时间但能避免绝大多数“模型效果差”的排障次数。3.3 一个轻量数据质检脚本的示例下面给一个非常简单的数据质量检查示例目的是让团队先建立“量化数据质量”的习惯。真实环境里可以根据自己的库和字段改造。import pandas as pd def quality_report(df, required_cols, date_colNone): report {} # 缺失率 for col in required_cols: missing_rate df[col].isna().mean() report[f{col}_missing_rate] round(missing_rate, 4) # 重复率 report[duplicated_rate] round(df.duplicated().mean(), 4) # 行数和时间范围 report[row_count] len(df) if date_col: report[min_date] str(df[date_col].min()) report[max_date] str(df[date_col].max()) return report这个脚本是示例不是生产级方案。真实场景里还要考虑数据量过大时的分片处理、告警通知、结果入库和调度触发。但先跑通一个最小版本比一开始就追求完整架构更重要。4. 模型效果不对时先按数据链路排查4.1 先查数据再查特征最后才动模型模型效果差时很多人第一反应是换模型、调参数、换提示词。这个顺序在大多数情况下是错的。我会优先按下面的顺序查先看输入样本。确认模型拿到的数据长什么样有没有空值、乱码、截断、错误标签。再看标注质量。如果是微调场景标注不一致会让模型学错方向。再看数据分布。训练集、验证集、线上数据是否来自同一分布。再看数据泄露。时间序列任务里未来信息有没有被提前混进训练集。再看特征统计。数值特征是否有极端值文本特征是否有异常长度。最后才看超参数和模型结构。为什么把模型放在最后因为模型问题往往会在训练阶段直接暴露出来比如 loss 不收敛、显存溢出、输出格式错误。而数据问题非常隐蔽模型可以正常训练、正常推理但结果就是不对。如果不先查数据改再多超参数都是在错误地基上打补丁。4.2 老数据项目最常见的四个坑老数据项目不是没有坑反而是坑比较典型。最常见的是这四个。第一个坑是数据孤岛。多个业务系统各自维护一套数据字段名一样但含义不同比如“客户”在一个系统里是公司主体在另一个系统里是联系人。合并之后统计口径完全对不上。解决办法是先做字段级映射和数据字典再进入后续加工。第二个坑是历史数据缺失。很多团队做 AI 时才发现早期业务系统没有埋点关键行为数据从第一天就没记录。这时再怎么清洗也补不回来。合理做法是在有限数据上做小范围验证同时尽快补上新的埋点和日志采集不要等数据完整再开工。第三个坑是只收集不治理。数据管道天天在跑文件越堆越多但没有人维护数据字典、负责人和更新状态。三个月后连自己都搞不清某个表是哪天生成的、能不能用。解决办法是每天或每周输出一份质检报告把异常暴露出来。第四个坑是口径修改没有记录。业务规则变了字段含义变了但历史数据没有打版本标记导致模型训练时把不同口径的数据混在一起。解决思路是给数据和报表加版本号修改口径时保留历史版本。4.3 上线后的数据回流与重训闭环模型上线不是终点。如果数据不回流模型会随着业务变化逐渐失效。常见做法是让线上推理日志进入存储层再定期分析用户反馈、指标变化和数据分布变化。具体来说可以做一个简单的反馈闭环记录用户提问、模型回答、用户反馈和耗时。按天或按周统计回答满意度、拒答率、错误率。当某类问题的错误率明显升高时定位到对应的输入数据和上下文片段。修复数据质量问题或补充新的业务知识。定期触发模型评估或重训。这个过程不一定要很自动化但至少应该有一个可见的循环流程。老牌数据公司之所以能持续服务客户这么久靠的也不是一次性交付而是不断根据业务变化调整数据和模型。对普通团队来说哪怕先用一个手动表格记录模型反馈也比“上线后不管”要好得多。5. 老数据资产接入大模型边界与适用情况5.1 老不等于旧关键是数据能不能被模型调用很多人一听到“28 年历史的数据公司”会下意识觉得技术栈很旧。但“数据老”和“技术旧”是两回事。老牌数据公司可能用了很多传统数据库和报表工具但这不代表它不能接入新模型关键是中间有没有一层“接口”。这层接口可以是检索增强生成让模型在回答前先从一个检索系统里拿相关片段也可以是结构化查询让模型通过工具调用数据库接口还可以是知识库把企业文档和业务规则切块后做向量化索引。老系统不需要推倒重来只需要在它的上层增加一个可以被模型调用的能力。反过来如果老系统里的数据本身就混乱字段口径不一致、权限不清、更新不及时那即使加了接口也没有用。所以接入大模型之前先把数据和系统之间的边界梳理清楚比选模型更重要。5.2 轻量方案和重型平台怎么选不是每个团队都需要复制老牌公司的数据架构。不同场景适合不同方案。场景更推荐的做法说明一次性的数据洞察本地 Python CSV不需要引入调度和数仓持续更新的业务报表对象存储 定时脚本 简单质检可以逐步迭代知识库问答文档分块 向量检索 大模型接口重点在分块策略和权限控制企业级 AI 应用数据管道 元数据 权限管理 质量监控 日志回流需要系统性建设这个表格的本质是数据规模小、任务简单时不要盲目上重平台数据规模大、要长期维护、要保证稳定产出时再考虑重一点的架构。老牌数据公司能跑几十年不是因为平台足够重而是因为数据治理和业务口径始终被当成核心任务。5.3 落到团队日常的三条建议如果只记三条我建议记住这几条。第一先做数据资产盘点再讨论用什么模型。把团队里有多少表、字段含义是什么、更新频率如何、谁负责维护先梳理成文档。这一步不花哨但能避免后面所有环节踩坑。第二先跑通一条端到端的数据链路再扩展批量。不要一次性把十几条业务线都接入大模型。先用一个业务场景从数据接入到模型输出完整走一遍确认每一步都有日志和校验再逐步扩大范围。第三把数据质量指标和模型效果指标绑定。比如“回答里引用错误数据次数”“因数据缺失导致无法回答的比例”“数据更新延迟对结果的影响”。只有绑定了这两个指标后续优化才有方向。最后想说的是这一轮 AI 工具更新确实很快但每次项目卡住最后大概率还是数据问题。与其追新模型不如先把数据授权、字段口径、质量基线和回流闭环想清楚。老牌数据公司能被重新关注并不是因为技术多前沿而是它用几十年证明了一件事数据能被稳定、重复、合规地使用才是真正的壁垒。