分享者：陈强
现任职于某大型车企，硕士，毕业于华东师范大学，曾就职于 Intel、IBM、联想、爱奇艺等公司；有多年基于 Docker/Mesos/Kubernetes 的云容器研发经验，积累了丰富的生产实践经验，专注于云原生技术的研究。
在推进汽车制造大模型建设的过程中，多源异构数据的统一接入与治理是我们遇到的最基础、也最棘手的问题之一。起初我们以为只要打通接口、建个数据湖就能解决，但实际推进中发现，技术只是表层，背后是流程、标准、权责的深层协同问题。
首先面临的挑战是数据结构的高度碎片化。研发系统用的是结构化参数表，生产MES系统记录的是时序工艺数据，质量检测又有大量非结构化的图像和文本报告，而供应链数据又分散在多个ERP实例中，字段命名、单位制、时间戳格式都不统一。比如同一个“扭矩值”，在设计端是理论值，工艺端是设定值，产线采集的是实测值，三者在语义上有关联，但在系统中完全孤立。这种语义割裂使得大模型难以建立准确的上下文理解。
其次是系统年代跨度大，集成能力弱。一些老厂区的设备系统还是十几年前的定制化平台，只支持定时导出CSV或ODBC访问，不提供API，数据更新延迟严重。我们曾尝试通过ETL工具批量接入，但发现数据时效性差，且变更频繁，维护成本很高。更复杂的是，部分系统由供应商运维，数据访问权限不在主机厂手中，协调周期长，响应慢。
再者是数据责任主体不清晰。比如某车型配置数据，研发说归他们管，销售说以配置器为准，IT又说两个系统独立维护。一旦出现数据不一致，往往需要跨部门开会确认，治理效率低。我们在做数据血缘分析时，发现很多关键字段没有明确的源头定义，导致模型训练时特征来源不可信。
针对这些问题，我们采取了分阶段、分层级的治理策略。
第一种路径是主数据驱动的中心化治理。我们先梳理出18类核心主数据，如车型平台、零部件编码、工艺路线等，建立企业级主数据管理（MDM）系统，统一编码规则和语义定义。所有系统在对接时必须映射到主数据标准，否则不予接入。这种方式治理彻底，数据一致性高，适合对准确性要求高的场景，比如BOM生成、成本核算。但建设周期较长，初期需要大量人工清洗和对齐。
第二种是基于数据虚拟化的联邦接入模式。对于暂时无法改造的老旧系统，我们采用数据虚拟化中间件，在不迁移原始数据的前提下，通过适配器实时封装查询接口，对外提供统一视图。这样避免了大规模数据搬迁带来的风险，也减少了对业务系统的侵入。我们在整车故障分析场景中应用这种方式，实现了售后、质量、产线数据的联合查询。优势是见效快、灵活性高，但性能依赖网络和源系统稳定性，不适合高频训练场景。
第三种是分域建模+语义层抽象。我们将数据按业务域划分（如研发域、制造域、供应链域），在各域内先完成局部治理，再通过统一的语义层（Semantic Layer）进行跨域关联。语义层中定义公共维度、指标口径和关联规则，大模型通过语义层获取数据，无需直接接触底层异构源。这种方式平衡了治理成本与使用效率，我们在智能排产项目中验证了其可行性。但需要持续维护语义映射关系，对数据架构团队能力要求较高。
从实践来看，单一方案难以覆盖所有场景。我们现在采用的是“主数据+虚拟化+语义层”三位一体的混合架构：核心主数据集中管理，历史系统通过虚拟化接入，最终通过语义层对外服务。同时配套建立了数据治理委员会，由IT、业务、质量等部门共同参与，明确数据Owner机制，把数据质量纳入KPI考核。
给同行几点建议：一是不要追求一步到位的“大一统”，先聚焦高价值场景，做深做实几个关键数据链路；二是重视元数据管理，把字段来源、更新频率、业务含义都记录清楚，这是后续模型可解释性的基础；三是推动数据治理从“技术驱动”转向“业务驱动”，让业务部门真正参与到标准制定中来，才能形成持续治理的合力。
这个过程确实需要耐心，但每打通一个数据断点，模型的能力边界就拓展一分。我们也在不断学习和调整，欢迎更多同行交流，一起把汽车制造的数据底座打得更牢一些。
