AI应用的燃料是数据：从老牌数据公司重估看数据基建价值

AI 最新的火箭飞船是一家老派的、28 岁的数据公司。第一次看到这句话时我脑中出现的不是兴奋而是一个反直觉的问题一家接近 30 岁的企业凭什么在 AI 时代被重新定义成“火箭飞船”过去几年AI 叙事的主角一直是新模型、新算力、新融资纪录。突然冒出一个“老牌数据公司”很多人会本能地怀疑是不是又一个蹭 AI 热点的老玩家但当我把这个问题拆开看会发现真正值得关注的不是某家公司本身而是整个行业正在发生的供需错位模型越来越多企业能稳定使用的数据却越来越少。AI 把聚光灯从模型层拉回到了数据层而数据层的老兵理所当然会被重新估值。这篇文章不打算复述任何股价或新闻而是想把它当作一个行业信号来拆解28 年意味着什么数据公司在 AI 时代真正值钱的是哪些能力我们自己做 AI 项目时能从中借鉴什么1. “火箭飞船”这个标签为什么落在一家老派数据公司头上1.1 年轻行业里的反常现象AI 行业给人的印象始终是“新”的新模型、新框架、新团队。创业公司动辄讲“从零重构”大厂争着发布下一代算法。在这样的话语体系里“28 岁的老数据公司”就像一个异类。但这个反常恰恰说明AI 落地已经进入一个新的阶段。前几年大家默认 AI 应用跑不起来是因为模型不够聪明。于是不断换更大模型、更精细的 Prompt。等模型能力上来了才发现真正拦住项目的不是模型而是数据。数据散落在多个系统里口径不一致权限混乱更新不及时。没有这些前置条件再强的模型也只能生成“看起来合理但无法信任”的结果。老牌数据公司做的事恰好就是这些“不性感”的活数据集成、清洗、建模、质量管理、元数据管理、报表口径统一。过去这些能力被当成企业 IT 的辅助模块现在却成了 AI 能否真正落地的分水岭。1.2 重估的底层信号模型不缺数据基建缺我最近的体感是模型能力的商品化比想象中更快。各家 API 的调用门槛越来越低参数、Prompt 技巧、微调方法也在快速扩散。三个工程师跑通一个复杂问答系统可能只需要几天。但要把这个系统放进真实业务让它处理真实的销售数据、供应链数据、客户服务记录问题会立刻暴露字段缺失模型不知道该读哪一列。同一份数据在不同系统里口径完全不同。权限没有打通能查的数据只有一半。数据源更新延迟AI 给出的结论已经过期。这些问题不是模型层能解决的。它们需要一套长期建设的数据基础设施。而老牌数据公司最擅长的就是这种基础设施。所以重估的逻辑其实很朴素不是老公司突然变酷了而是 AI 让行业终于意识到数据基建比模型本身更稀缺。1.3 我的第一个判断它被重估不是因为它最懂 AI而是因为 AI 终于需要懂数据的人很多人把这个现象解释成“老公司押中了 AI”。我不太同意。更准确的说法是AI 发展得越快市场对“高质量、可治理、可追溯的数据”的需求就越明确。老牌数据公司不一定比创业团队更懂大模型但它们有一套几十年积累下来的数据生产链路怎么连接系统、怎么处理脏数据、怎么让业务人员信任一个数字、怎么满足审计要求。这些能力过去被低估是因为数据工作在企业里不是增长引擎而是成本中心。现在不同了。AI 让数据从“记录价值”变成“生产资料”数据质量直接决定 AI 产出质量。火箭要起飞靠的从来不是外壳好看而是燃料质量。对 AI 来说数据就是燃料。2. 28 年沉淀下来的不是数据而是“把数据变成决策材料”的能力2.1 拆开老牌数据公司的资产包一提到“数据公司”很多人第一反应是“它们手里有很多数据”。这个理解太窄了。真正有价值的不是静态数据而是围绕数据形成的一整套工程能力。我习惯把它拆成四块连接与集成能力能接入各种各样的数据源从传统数据库到 SaaS 系统从结构化表到非结构化文档。清洗与建模能力能处理重复、缺失、错误格式并把业务口径固化成可复用的数据模型。质量与血缘能力能追踪数据从哪来、经过哪些转换、最终被谁使用。交付与运维能力能稳定地产出报表、接口、数据集并保证性能和安全。这些能力看起来不花哨但每一条都是在大量真实业务里打磨出来的。数据源换一个版本、字段名调整一次、业务规则发生变化都需要对应的工程机制去承受。这些东西很难在短期内补上因为它拼的不是算法而是经验。2.2 为什么在生成式 AI 时代反而变得稀缺生成式 AI 的典型工作方式是让模型基于一段上下文生成内容。企业想让它回答“上季度哪个区域销量下滑最快”模型需要先拿到准确、完整、口径统一的数据。今天的现实是大部分企业的知识资产都是散乱的。文档存在网盘里表格在不同同事手里数据库权限只开放了部分人。即使有人做了一次整理下一次数据更新后又会回到混乱状态。向量数据库曾经被寄予厚望但实践下来它解决的只是“存储和检索”这一小段。真正的难点是如何决定哪些文档该进入向量库如何保证文档之间的关系正确数据更新后如何让 AI 立刻感知多个文档说法冲突时以哪个为准这些问题的答案恰好属于传统数据工程的范畴。老数据公司之所以稀缺因为它们把“让数据可信”这件事做得足够深。这不是大模型 prompt 能替代的。2.3 企业客户为什么更容易买账还有一个实际原因采购和信任。大模型应用第一次走进企业时CTO 通常会问三个问题结果错了谁负责数据放在哪里能不能审计这些问题的答案光靠模型层很难回答。老牌数据公司的优势在于它们有成熟的交付流程、服务协议、权限体系、审计日志。企业客户更愿意和一家“出了问题能找到人、出过事故也有追溯记录”的供应商合作而不是被一个漂亮的 demo 绑死。尤其在金融、医疗、制造这类强合规行业稳定比新颖重要可追溯比智能重要。这也是老牌数据公司能被重新看上的重要原因。注意这并不意味着老牌公司一定比新公司好。它的优势有严格边界只有在“数据治理、审计合规、复杂集成”这些场景里老经验才真正值钱。3. 从这类公司身上可以提炼出四个 AI 落地模块我不建议直接把老牌数据公司当成采购清单里的必选项。更实际的做法是把它们的方法论拆成四个模块迁移到自己的 AI 项目里。这四件事做完AI 应用的可信度和可维护性会有明显提升。3.1 数据契约先约定字段、口径、语义再谈 AI很多 AI 项目失败的根源是人和模型都搞不清楚某个字段到底代表什么。数据契约是解决这个问题的接口。它不等同于表结构而是对数据集的一套详细承诺这个字段的含义是什么更新频率是多少取值范围是什么由谁负责维护。一种常见写法是dataset: sales_order version: 1.4 owner:>{ request_id: a1b2c3, timestamp: 2026-01-15T10:30:00Z, user: ops_analyst, query: 上季度华东区销量下滑原因, retrieved_chunks: [ {source: warehouse.sales_order, table: monthly_agg, time: 2025-12}, {source: knowledge_base/campaign_notes.md, page: 3} ], model_input_tokens: 4200, model_output: ... }有了血缘AI 就不再是一个黑盒而是一条可以审计的数据流水线。3.3 权限与合规上下文不是越多越好很多团队犯过一个错为了让 AI 回答更聪明把大量数据一次性塞进上下文结果出现越权数据泄露。权限控制是 AI 落地的底线。老牌数据公司在这件事上的方法论值得直接借用行级权限不同角色只能看到自己范围内的数据。列级脱敏身份证、手机号、邮箱等敏感字段在进入模型前自动脱敏。文档可见性企业知识库必须按部门标签控制检索范围。查询审计每次 AI 请求的数据访问记录都要保留至少 90 天。不要先做完 AI 功能再补权限。那样往往只能做表面控制真正的问题藏在检索链路里。3.4 面向任务的上下文供给把知识组织成检索友好的形态很多团队以为只要把文档丢进向量库AI 就能变聪明。实际上上下文供给是一套独立的工程。我建议按任务类型设计上下文组织方式任务类型推荐上下文策略典型工具业务问答先定位指标口径再读取明细表数据目录 指标库文档问答分层切片先给目录再取章节文档解析 向量检索数据报告生成数据血缘先行再让模型生成结论ETL 血缘追踪客服辅助历史工单 政策规则混合召回知识库 混合检索这里的关键是先确定模型“需要什么上下文”再设计数据接入方式不要反过来。3.5 把它们连成一条 AI 就绪流水线四个模块组合起来就是一条可以复用的 AI 数据流水线数据契约 → 数据血缘 → 权限控制 → 检索与上下文构建 → 模型生成 → 结果评估 → 反馈回流每一环节都可以单独验证。数据契约有没有覆盖所有字段血缘能不能回答“这个数字从哪里来”权限是否在检索层和模型输入层都生效了检索结果有没有把过期文档过滤掉把这些做完AI 应用才算真正进入“可治理”的状态。4. 老牌数据公司不是万能钥匙先判断边界说完了价值必须说边界。老牌数据公司被重估不代表它适合所有场景。4.1 适合有真实业务存量、需要治理、要求审计合规的场景你已经积累了多年业务数据但质量参差不齐。业务主管需要 AI 帮助分析但每个结论都要能解释依据。行业有明确合规要求比如金融、医疗、政务。系统复杂数据分散在多个旧平台里需要长期集成。要让 AI 深入核心业务流程而不是只做辅助问答。这些场景下老数据公司的工程方法和客户服务能力是真优势。4.2 不适合冷启动、快速试错、纯生成式创新项目如果项目数据几乎为零模型没有可用的上下文老数据公司能帮上的忙非常有限。比如一个全新产品没有历史交易和用户行为数据平台再强也没有原料。如果团队只是要做两三天一个 demo用来验证 idea那么直接用轻量工具更高效。老牌产品的部署、配置、权限体系反而会成为负担。如果是纯创意生成、营销文案、图像设计数据公司不是首选。4.3 落地前置条件数据协议、API、部署位置、成本模型无论选哪家公司都要先确认四件事数据接口是否足够开放能否拿到 API、批量导出、自定义连接。是否支持私有化或混合部署数据是否会离开你的云环境。是否支持常用数据源尤其是你们自己的核心系统。成本是否可预测是按调用量、按数据量还是按年费。这些前置条件不过关后面的 POC 大概率会跑偏。4.4 如何做一个 90 天的试用评估我更建议用 90 天分阶段验证而不是只看演示第 1-30 天选定一个真实业务场景。不要选“做智能客服”这种宽泛问题要选“根据近 3 个月销售数据回答业绩归因”这种可验证问题。第 31-60 天用真实数据跑 POC。记录 AI 的回答准确率、人工修正率、平均响应时间以及权限、血缘、日志能否满足内部要求。第 61-90 天评估扩展性。增加第二条业务线、第三类数据源看看系统是否会因为数据量增大而失控运维成本是否还在可接受范围。90 天结束时如果结论需要大量人工兜底说明数据基础还没达到生产可用标准。5. AI 效果不理想时别只调 prompt先按这条链路排查数据问题AI 应用上线后最常遇到的问题是“效果不稳定”。很多人第一时间改 prompt、调 temperature但真正的问题往往在数据链路里。5.1 五层排查链路我建议按下面五层逐层检查每层确认没问题再进入下一层排查层级检查内容常见问题表现第 1 层输入数据源、文件格式、字段映射、编码数据源连不上字段对不上第 2 层数据质量重复、缺失、口径、时区、单位汇总数字总是偏大或偏小第 3 层检索切片、向量化、召回、排序、过滤回答引用了错误文档第 4 层模型上下文长度、指令冲突、思考深度回答含糊、逻辑混乱第 5 层评估指标定义、标注样本、反馈闭环效果忽好忽坏无法复制先确定是哪一层坏了再决定修哪里。5.2 一个典型现象AI 的解释看起来合理但关键数字总是偏我之前遇到过类似的场景AI 可以流畅解释“为什么华东区销量下降”但每次给出的“华东区销量”和报表系统对不上。一开始团队怀疑是 prompt 问题反复调整措辞无效。后来查下来问题出在数据源报表系统里的“华东区”包含五个省份而 AI 接入的数据源只包含了三个省份。同一个省份在不同表里的行政区编码不一致有一份用的是旧编码。数据更新有 24 小时延迟导致引用的是前一天的数据。这些问题没有一项是靠调 prompt 能解决的。只有把数据口径统一、过滤条件补全、更新延迟标注清楚答案才会稳定。这个案例说明AI 输出的“流畅性”很容易骗人。真正需要验证的是它背后的数据链路是否可信。提醒每轮排查都要用同一组测试问题记录前后结果不要凭感觉判断。没有基线样本集的排查大概率是重复试错。5.3 用日志和可观测性证明问题到底在哪一层优秀的团队会把 AI 应用当成一个可观测系统来建设。至少要对每一次请求记录用户提问、数据查询语句、检索片段、token 消耗、模型输出、用户反馈。同时维护一组“基线问题集”每次改动后都跑一遍比较各项指标。一旦指标有异常就能通过日志快速定位到具体环节而不是靠开会猜测。6. 判断一家数据公司是不是真的“火箭飞船”看三个硬指标最后回到一个更实际的问题如果我要选一家数据公司作为 AI 基础设施的合作伙伴怎么判断它不是只是蹭概念6.1 数据资产密度不是“有数据”而是能持续治理真正值钱的数据公司不只是拥有存量数据而是有持续更新和治理数据的能力。看它有多少数据源连接器数据模型的复用度以及元数据管理是否完整。如果一家公司只能给你一个“数据湖”却说不清水质、血缘、责任方那它对 AI 的帮助有限。6.2 工程开放度能不能被你的 AI 流程调用老公司经常被诟病封闭。如果它只提供界面操作不提供 API、SDK 和数据导出能力就很难作为 AI 基础设施。判断标准很简单你的工程师能不能在两天内把这个公司的数据接进自己的数据管线如果能它才具备成为“基础设施”的条件。6.3 迭代速度有没有把 AI 工具吸收进自己的工作流一个真正的信号是这家公司是否用 AI 改造了自己的产品和服务流程。看它是否在核心产品里提供 AI 能力而不是仅仅在官网加一个“AI 助手”入口。看它是否在持续更新数据模型、自动化程度是否提升、交付周期是否缩短。迭代速度慢的老公司就算今天被高看一眼也可能在被市场选中后跟不上用户需求。6.4 同时警惕两个信号第一个信号用 AI 做大词包装但核心体验没有任何变化。打开产品还是一样的表结构、一样的报表界面只是多了一个聊天框。第二个信号过度强调模型能力却回避数据治理问题。这样的产品可能在 demao 上很惊艳一旦接入真实数据很快就会露出短板。判断标准不复杂AI 是否真的解决了“更快拿到可信数据”和“让复杂数据可理解”这两个关键问题。写在最后“AI 最新的火箭飞船是一家老派的、28 岁的数据公司。”这句话真正值得记住的不是哪家公司又涨了多少而是 AI 落地的支点正在回归数据工程。过去几年我们习惯了“新模型 新世界”的叙事。但今天能稳定跑起来的 AI 应用往往靠的是一堆不性感的底层工作清洗、治理、血缘、权限、评估、反馈。一个 28 岁的数据公司被重新审视说明行业终于明白火箭起飞靠燃料AI 的燃料是数据。如果你正在做 AI 项目我的建议很直接先别急着追新工具先把你自己的数据基建补牢。数据契约、血缘、权限、检索评估这四件事只要做好一件AI 应用的可信度就能上一个台阶。真正的火箭飞船从来不是某一款模型而是一条能把数据持续变成决策材料的流水线。