一家制造企业去年部署了大模型，内部试点时效果不错——问"本月华东区销售情况"，能自动拉数据、出图表、给分析。正式上线后，业务部门第一天就投诉："它告诉我华东区上月销售额 3200 万，但我们财务系统里是 2800 万。差 400 万。"
技术团队排查后发现：不是模型的问题。大模型调用的数据来自三个不同的业务系统，每个系统对"华东区"和"销售额"的定义都不一样。模型只是忠实地汇总了它能找到的数据——而这些数据本身口径就不统一。
类似的情况正在越来越多的企业上演。过去一年，大模型部署进入加速期，但很多团队发现，模型效果从"惊艳"到"翻车"往往只有一个环节的距离：数据。
AI 效果的上限，取决于数据质量
国际 AI 学者吴恩达（Andrew Ng）提出的 Data-Centric AI 理念，核心观点很直接：与持续优化模型相比，持续提升数据质量和数据治理能力，往往能获得更大的业务收益。
这个判断对企业的意义在于：如果数据本身存在问题，再好的模型也无法给出可靠的输出。而且大模型对数据质量的容错率比传统 BI 更低——传统报表出现一个数字偏差，可以人工核查、修正解释；但大模型输出的是一段完整的分析结论，一个数据错误就可能导致整体判断偏差，而业务人员往往难以逐句验证。
当企业的数据治理存在短板时，这些短板会在大模型场景下被集中放大。以下四个方面最为突出。
1. 数据质量问题：脏数据直接导致输出不可信
数据质量是大模型落地中最先暴露的问题，也最容易被误判为"模型不行"。
大模型的工作机制决定了它不会主动质疑数据的准确性。输入数据中存在的缺失字段、错误取值、重复记录，会被模型当作事实接受，并在此基础上生成流畅但可能错误的回答。传统 BI 报表中一个字段为空最多显示"null"，但在大模型的自然语言输出中，空值可能在上下文推理中被补全为一个不确定的数值，用户难以判断该数值的来源依据。
更隐蔽的问题是数据的一致性。当同一个业务指标在多个系统中存在不同数值时，模型可能在回答不同问题时引用不同来源的数据，导致前后输出矛盾。用户发现"同一个问题，问了两次答案不一样"，第一反应是模型不可靠，而根因是底层数据口径不统一。
问题排查同样消耗大量资源。一次数据质量问题导致的大模型输出错误，往往需要回溯多个数据源、对比多套口径、跨部门确认数据归属，排查周期可能长达数天。这意味着数据质量管理的缺失，在大模型时代会带来比传统场景更高的修复成本。
2. 数据标准缺失：大模型无法跨系统理解业务
如果数据质量是"数据准不准"的问题，数据标准就是"数据能不能被理解"的问题。
大模型需要理解不同业务系统中的数据含义才能给出可靠的回答。但在很多企业中，同一个业务概念在不同系统中使用了不同的字段名、编码规则和取值口径，这使得大模型难以建立跨系统的语义一致性。
举例来说，一个用户问"分析去年各产品线的毛利率"，大模型需要从多个系统中获取收入、成本、产品分类等数据。如果不同系统对"产品线"的划分逻辑不同——财务系统按核算科目分类、生产系统按工艺路线分类、销售系统按渠道分类——大模型就无法自动判断应该以哪个口径为准。它可能混合了不同系统的数据，输出一份看似完整但实际上口径混乱的分析。
数据标准的缺失不仅影响大模型的输出质量，还增加了持续的运维成本。每接入一个新的业务场景，治理团队需要额外梳理数据映射关系、编写清洗规则、处理口径差异。这些重复性工作占据的时间越长，团队能够投入到真正治理工作上的精力就越少。
3. 元数据割裂：训练数据变成黑箱
元数据是数据的"使用说明书"——它记录了数据从哪个系统来、经过了哪些加工、字段含义是什么。在企业级大模型部署中，元数据的完整性和可追溯性直接决定了数据治理团队对模型行为的掌控能力。
当大模型给出一个错误或不当的回答时，治理团队必须能够快速追溯到问题数据的源头。但在缺乏有效元数据管理的情况下，这个追溯过程效率很低。团队需要翻阅 ETL 脚本、询问开发人员、对比多套文档来定位数据来源，而熟悉历史系统的人可能已经调离岗位。追溯周期从"分钟级"延长到"天级"，治理团队被绑定在被动响应中。
另一个问题是训练数据的透明度。大模型的微调和 RAG（检索增强生成）往往依赖企业自己的数据，但如果这些数据的来源、加工过程和质量状况缺乏元数据记录，模型的行为就缺乏可解释性。当监管或审计要求说明"这个大模型的训练数据来源是什么"，企业可能无法给出完整的回答。
Data-Centric AI 理念强调的"系统性提升数据质量"，前提就是元数据管理——只有先搞清楚数据从哪来、经过了什么处理，才能有针对性地进行优化。没有元数据的治理是盲目的。
4. 安全合规：大模型场景下的数据泄露风险
大模型的数据安全问题相比传统信息系统有其特殊性。
首先，大模型对训练数据有记忆能力。如果原始数据中包含个人身份信息、商业秘密或敏感业务数据，这些信息可能在模型训练过程中被编码进模型参数，并在特定提示词下被提取出来。在传统 BI 系统中，敏感数据的访问可以通过权限控制精确到字段级别，但在大模型的自然语言交互中，权限和输出的边界更难被精细控制。
其次，大模型容易放大数据的流通范围。过去，包含敏感信息的数据库表只有少数授权人员可以查询；接入大模型后，任何有权限使用该模型的用户都可能通过自然语言提问触及这些数据。如果敏感数据没有经过预先的分类分级和脱敏处理，大模型的使用会显著扩大敏感信息的潜在暴露面。
数据安全合规的底线是：在数据进入大模型之前，必须完成分类分级、脱敏处理和权限管控。这不是大模型本身能解决的问题，而是数据治理体系必须覆盖的范围。
解法：从架构层面构建大模型的数据就绪体系
以上四个问题虽然表现不同，但解决路径指向同一个方向：需要在大模型接入之前，建立覆盖标准、质量、元数据和安全管理的数据治理体系。
从工程落地角度看，这四个维度构成了大模型场景下的"数据就绪"体系，它们之间存在明确的分层关系：
数据标准层提供统一的语义基础和口径定义，是上层质量管理和元数据管理的前提。统一核心业务实体的编码规则和口径定义，使大模型在跨系统查询时有统一的语义基础。
数据质量层建立在标准之上，通过完整性、准确性、一致性校验确保进入模型的数据可靠。关键是在接入环节建立质量基线，使校验规则在数据流转中自动执行，问题数据在源头被标记而非事后发现。
元数据管理层提供数据的来源追溯和血缘追踪能力。实现自动化的元数据采集和血缘追踪后，当大模型输出出现偏差时，可以快速追溯到问题数据的源头和加工链路，排查周期从"天级"缩短到"分钟级"。
数据安全层贯穿全局，在数据分类分级和脱敏处理的基础上实现细粒度的权限管控，确保敏感数据在大模型交互中的访问边界可控。
从架构设计角度看，企业应考虑将这四项能力嵌入数据集成和服务的流转链路中，使治理规则在数据流转时自动执行，而非依赖事后的人工排查。治理底座越牢固，大模型输出的可信度越高。
对于还不确定从哪个环节切入的团队，一个低成本的起步方式是先做数据质量评估，摸清数据现状，再根据结果确定治理优先级——标准混乱的从标准入手，质量问题突出的从质量基线入手，元数据缺失严重的先做元数据采集。
常见问题
Q1：已经在使用大模型了，还能回头补治理吗？
可以。建议先对当前大模型使用的核心数据域做一次质量评估，确定最突出的问题维度。增量的治理规则——如质量校验和元数据采集——可以在不中断大模型运行的情况下逐步建立。存量数据的标准化和清洗按优先级分批推进。
Q2：大模型项目要不要等治理做完再启动？
不需要。两者可以并行，但建议在模型正式面向业务用户开放之前，至少完成核心数据域的标准统一和质量基线建立。内测阶段可以先用受控数据集验证模型效果，治理工作同步推进。
Q3：怎么判断是模型能力问题还是数据质量问题？
一个简单的判断方法：选取一个已知数据质量的业务域做测试。如果在该域中模型输出准确度明显高于其他域，说明问题更可能出在数据而非模型。可以借助数据质量评估工具对输入数据做系统检测，将检测结果与模型输出效果做对照分析。
结语
大模型代表了企业 AI 应用的前沿方向，但它的效果并不完全取决于模型本身的能力。标准不统一、质量不可控、元数据不透明、安全不到位——这些问题在大模型时代会被快速放大。企业 AI 建设的瓶颈正在从模型能力转向数据能力，数据治理的成熟度直接决定了大模型能走多远。
