一、为什么突然都在聊AI+数仓？
过去两年，大模型的风刮到了数据基础设施领域。从Text-to-SQL到AI辅助建模，从自动化ETL到智能数据治理，各大厂商和开源社区陆续推出一系列工具，试图用大模型改造传统数仓的工作方式。
这个方向的内在逻辑不难理解。传统数仓建设有几大痛点：建模周期长、数据清洗依赖人工规则、ETL链路出问题需要运维半夜爬起来定位。每个环节都存在大量重复性劳动，而这些恰好是大模型擅长的事情——理解自然语言、生成代码、识别模式规律。
但一个有意思的现象是：同样一套技术方案，有的公司用得比较顺畅，建模效率明显提升，数据质量问题大幅减少；有的公司投入了不少资源，折腾了大半年，最后得出的结论是"大模型没啥用"。相似的底层技术，结果差别很大。
这背后的原因在哪？结合我这几年的一线观察，我总结了四个层面的关键分水岭。
二、跑得通的公司，做对了什么？
1. 先把数据底子打扫干净
这是最基础、也最容易被忽视的一点。跑得通的公司，在引入AI之前，已经完成了数据标准化的基础工作——字段命名规范统一、数据字典完整、指标口径明确、元数据管理到位。大模型进来之后，有标准的元数据做上下文，不需要去"猜"某个字段的业务含义。
反过来，跑不通的公司往往是"数据裸奔"状态。同一个客户ID，CRM系统里叫customer_id，订单系统里叫user_no，日志系统里叫uid。大模型面对这种混乱的局面，别说生成准确的SQL，连理解都费劲。很多项目一上来就希望大模型"端到端"解决问题，结果数据质量不过关，大模型输出的东西也是错的，团队信心一下就被打没了。
一个判断标准：如果你现有的数仓连基本的指标口径都没有对齐，先别急着上AI。把标准定了，把字典建了，再谈大模型赋能。 |
2. 选对了切入点，从小场景开始跑
从我了解到的情况来看，跑得通的公司通常遵循"小切口、速赢"的策略。很多不会一上来就搞一个"企业级AI平台"，而是先挑一个高频、痛点明确、价值可量化的场景。
比如：
Text-to-SQL查询：让业务人员用自然语言查数，减少数据开发写SQL的重复需求
数据质量自动稽核：用大模型识别异常数据，补充人工校验规则的不足
元数据自动补充：根据表结构和业务上下文，自动生成字段描述和业务定义
这些场景的共同点是：边界清晰、见效快、业务方感知强。一旦跑通一个场景，团队信心建立，后续推进其他场景就容易得多。而一上来就想"用AI重构整个数仓体系"的公司，项目周期拖得太长，业务方耐心耗光，往往无疾而终。
3. 懂得"什么该交给AI，什么不该"
这是很多技术团队容易忽略的问题。大模型不是万能的，也不是所有任务都适合交给它。从我观察到的做法来看，跑得通的公司普遍建立了一套分层分工机制：
|
任务类型 |
处理方式 |
典型场景 |
|
简单、规则明确的 |
传统脚本/SQL 基础数据校验 |
固定报表查询 |
|
复杂、需要语义理解的 |
大模型处理 |
模糊查询转SQL、异常归因分析 |
|
高频且对延迟敏感的 |
轻量级模型或规则引擎 |
实时数据质量拦截 |
|
低频且对准确度要求高的 |
大模型+人工审核 |
复杂建模、数据口径映射 |
核心原则是：大模型只做"需要理解能力"的事情，不碰"可以用规则解决"的事情。这样做既能控制调用成本，又能保证效率和准确率的平衡。
三、跑不通的公司，踩了哪些坑？
坑一，数据没清干净就上AI
最典型的场景是：企业把全量业务数据直接丢给大模型，期望它自动完成清洗和治理。结果大模型面对各种不一致的字段、缺失的关联关系、混乱的编码体系，输出的数据质量大打折扣。
举个常见的例子：供应商名称这个字段，在不同业务系统里可能写成完全不同的格式——全称、简称、中英文混写、带标点不带标点。如果不在入库前做标准化映射，大模型花再多精力去"理解"这些变体，效果也不如先把数据洗干净再喂给模型。这背后是一个基本的顺序问题：AI不能替代数据治理，但它能加速已经标准化的数据治理流程。顺序反了，结果就是事倍功半。
坑二，一上来就搞"全场景覆盖"
这个问题在传统IT项目中就常见，到了AI时代被放大了。从我的经验来看，AI项目的不确定性比传统项目更高，因为你无法预判大模型在某个具体场景下的表现。场景越多，不确定性叠加，项目失败的几率也随之上升。
常见的情况是：公司成立AI+数据专项组，目标同时覆盖销售、运营、供应链、客服多个场景，预算和周期定得很高。结果几个月过去了，连第一个场景还没跑通——每个场景都需要不同的数据准备、不同的Prompt调优、不同的评估标准。资源有限却全面铺开，很容易每个场景都做不透。
一个务实的建议：如果团队还在探索阶段，先集中资源打穿一个场景，验证了价值再横向复制。 |
坑三，技术部门单干，业务部门不参与
大模型需要"学"业务知识。如果业务部门不参与需求定义、不提供高质量的业务语料、不参与结果评估，大模型生成的SQL和模型很可能跟实际业务需求对不上。
举个例子，"计算客户流失率"这个需求，不同部门的理解可能完全不同。销售部门认为"三个月未下单"就算流失，运营部门认为"六个月未登录"才算，财务部门可能按"账户余额为零"来定义。口径差异，大模型自己是"悟"不出来的。
坑四，忽视成本与效率的平衡
大模型的API调用成本因模型和厂商而异，按token计费的模式下，高频调用会产生一定的开销。如果所有数据操作都走大模型，月结时的费用可能会比较可观。
比如，日常的GMV查询、转化率报表这类高频查询，用大模型走一遍自然语言转SQL，延迟可能比直接跑一条预计算的SQL慢不少，调用成本也更高。把任务分层——高频、确定性高的走规则引擎或预计算，低频、模糊的走大模型——可能是更合理的做法。
四、优化方向，怎么从"跑不通"变成"跑得通"？
方向一，从高频痛点场景切入，快速验证
如果你的公司还在探索阶段，可以考虑从这些场景入手：
数据质量稽核：大模型识别异常数据的能力在一些场景下已经具备实用价值，落地门槛相对较低
元数据自动补全：基于表结构和字段名生成业务含义描述，能较快提升数据字典的覆盖率
自然语言查询（Text-to-SQL）：适用于报表需求频繁、数据开发资源紧张的团队
ETL脚本辅助生成：适合数据量大、重复性ETL任务多的场景
每个场景建议先做小范围POC验证，确认价值后再投入资源做生产化。
方向二，建立闭环验证机制
大模型输出结果建议配合人工确认机制：
项目初期：人工复核比例适当提高，重点关注大模型输出是否符合预期
稳定期：复核比例逐步降低，同时建立自动化监控基线
成熟期：通过bad case反向驱动模型和Prompt的持续优化
每次发现大模型输出有误，记录下来分析原因——是Prompt写得不够精准？是数据本身有问题？还是场景超出了模型的能力边界？这些积累会成为后续优化的重要基础。
方向三，数据安全底线不能破
数仓里存储着大量业务数据和用户信息，直接送到公有云大模型接口存在合规风险。在实际落地中，建议做到：
敏感字段（手机号、身份证、邮箱等）在输入大模型前进行脱敏处理
所有API调用留存审计日志
明确数据使用边界，不超出业务需要的范围
有条件的企业可优先考虑私有化部署方案
五、未来展望，AI+数仓会走向哪里？
从过去两年的行业实践来看，AI+数仓的发展有几个方向已经逐渐清晰：
第一，AI辅助能力会逐步融入数仓工具链。就像OLAP引擎成为数仓标配一样，AI辅助建模、智能数据质量稽核、自动化运维诊断等能力，在未来几年可能会成为数据平台的基础功能。企业需要思考的不是"要不要用"，而是"用在哪些环节最合适"。
第二，不同规模的模型会协同工作。大模型擅长复杂推理和语义理解，在需要"理解"的场景下优势明显。而小模型或规则引擎在处理高频、确定性任务时，在成本和响应速度上更具优势。两者配合使用，可能是更务实的方案。
第三，数据治理的重要性不会降低，反而会提升。AI越强，对数据质量的要求越高。一条不准确的数据口径，经过大模型处理后，可能产出一份看起来逻辑严谨但结论错误的报告。数据治理不是可以被AI替代的工作，而是需要和AI同步加强的基础工程。
第四，人机协同是现阶段较为可行的模式。短期内"AI替代数仓工程师"不太现实。更务实的路径是：AI处理重复性、规则清晰的常规任务，人工负责复杂决策、异常处理和效果兜底。从我接触到的案例来看，这个分工模式在成本、效率和质量三个维度上综合表现不错。
最后说句实在话：AI+数仓这件事没有捷径。先把数据管好，选对场景，边界划清楚，再让AI进来干活。按这个顺序走，大概率能跑通。反过来，跳过前两步直接上AI，十有八九要交学费。 来源（公众号）：华哥聊数据 |
