《行业头部企业大模型应用路径深度分析》系列(二)把“自训大模型”的颗粒度拉清楚——5 档颗粒度 + 4 个独特约束

本篇导读

上一篇通过一个典型场景展开了构想中的头部企业在大模型应用上的困境:服务调用频次审计失真、Shadow AI 偏差、三个典型业务场景仅一个达到预期、自训底座边际效益持续低于外部基座模型版本更新的节奏。但是这些都是表层现象。

要把"该不该自训"这道命题拆解透,第一步是把"自训"的颗粒度分析清楚——在任何一个行业头部企业的董事会语境下被统一称作"自主训练大模型"的工作,实际上对应 5 类截然不同的工程动作。第二步是看清楚这道命题在OEM企业这种重工业、制造业语境下的 4 个独特约束——它跟互联网 / 金融 / 法律 / 教育行业不一样,但也不能把"我们行业特殊"当成绕开通用论证的万能护身符。

这两件事做完,这个话题才能聊得下去。

一、先把"自训"的颗粒度拉细

在分析框架展开之前，必须先分析一个比较模糊的语义。

在董事会与媒体语境下被统一称作"自主训练大模型"的工作，在实际工程层面对应 5 类颗粒度截然不同的工作类型，从投入规模由高到低排列如下：

这几件事的争议程度从上到下急剧下降。RAG(检索增强生成)/ OAG(本体增强生成)+ Agent 没人在反对,标配。LoRA 也没人在质疑。窄任务的 SFT 也在共识区间。

真正在 2026 年还有大争议、且与"行业大模型 / 企业大模型"叙事直接相关的,是:from-scratch、continued pretraining、行业或者公司层级的 SFT / RLHF。

业界绝大多数被宣传成"XX 行业大模型"的项目,真实量级是第 2 + 第 3——开源底座(LLaMA / Qwen / DeepSeek / Mistral) + 几十到几百 B token 的私有数据 continued pretraining + 几万到几百万示例 SFT,再加上一定程度的 RLHF。

少数有政府背景的项目可能会做到 from-scratch，但是目前尚无公开披露。极少数项目同时做完整 from-scratch + 持续后训练管线——那是 OpenAI / Anthropic / Google 级别的能力栈,任何不属于AI界T0层级的企业，哪怕是其他行业的头部企业都不在这个候选区间里。

但很多企业内部,其实根本不区分这几件事。

在给董事会的方案里,它们都叫"训自己的大模型"。

二、两类微调的财务账本必须先切清楚

在进入正文之前必须先把两类微调的财务账本切清楚——因为下面的论证只针对其中一类，对另一类毫无意见，混在一起谈会引发总师层级的误读。

A 类——CPT 全量参数级 continued pretraining 路径。 通过调整基座权重让模型"具备XX领域语感",目标是产出一个对外可宣传的"行业/企业大模型"。

这条路上的支出,是一笔持续折旧的组织负债——外界的基座模型每 18-24 个月一次的能力跃升会迫使企业刚训好的模型重训;在工程上,这是一场必须跟下一代前沿基座比泛化的赌注,结构性地难以建立长期优势。

本系列后续所有批判性论证,仅针对上面A这一类路径。

B 类——任务级特化训练与蒸馏。 目标明确、边界收敛。例如让一个 14B 小模型在合规内网或 offline 受限部署环境下,稳稳处理"维修工单结构化""SysML 语法一致性校验"等明确感知 / 分类任务。

B 类的账好算得多:训完即用,投入在本代任务周期里就摊掉了。它不用去跟下一代前沿基座比泛化能力——只要在那个受限环境里,把那点确定的活干稳,就够了。

B这一类属正当工程动作,完全不在本系列的讨论范围内。

实际操作中,很多企业的痛点也正出在这里——A 类和 B 类被混在一份立项书里送上董事会,算的也是一笔总账。真正出问题的是 A 类,但最后被 B 类那点确定性收益替它背了书。

而 B 类的确定性收益要真正成立,还有一个常被忽略的二阶约束——系统集成的生命周期,跟基座模型代际折旧周期的相对关系。

OEM类单位的 IT 系统迭代周期,通常按 3-5 年节奏推进(详见本篇第三节约束 3)。即便是一个 B 类窄任务模型,要真正部署到 PLM 涉密内网,所涉及的数据接口开发、密级网络合规审查、工程师培训、既有工业软件多级供应商版本冻结,整体集成周期可能长达 6-12 个月以上。

如果这个集成周期接近或超过前沿基座模型的迭代跃升节奏(6-9 个月),就会出现一种结构性的窘境:你的特化小模型刚刚上线,外部新一代基座模型可能已经在零样本/少样本能力上把它超越。

所以 B 类项目要想真正吃到确定性收益,必须严守一条工程纪律——把模型作为可解耦的微服务挂载:数据接口与服务契约(API 规范、Token 格式、本体接入点等)完全标准化,数据管线与底层模型解耦。

只有当系统的集成与合规生命周期,显著短于模型的代际折旧周期时,B 类项目的收益才真正落得住。

本系列前半程集中讨论 A 类——**"用自己的数据微调出一个'行业大模型',对一家头部企业来说到底值不值得?"** 后面几篇再接着讲怎么用好 AI(包括 B 类如何在工业认知系统里正确就位)。

三、为什么 2026 年是回答这道题的关键节点

因为三条线在 2026 年这一年交汇。

基础模型能力再破记录。 GPT o-series、Claude 4.7、Gemini 3、DeepSeek-V4-Pro(1.6T MoE / 49B 激活)已经把"通用专家级智能"逼到了几乎所有企业够不着的高度。

自训成本断崖式下行。 7B 模型 fine-tune 单次成本已经低到 $5 以下;70B continued pretraining 也降到几十万到几百万美金区间。

评估方法学开始成熟。 第三方独立 benchmark 体系大量出现——领域 eval 集、行业基准、对照测试方法,让"微调到底有没有效、强多少、在哪里弱"第一次有了客观尺子,而不是项目组自己评估自己。

第三条最关键。过去几年很多自训项目能一直"看起来很成功",靠的就是没有第三方尺子,只有自己出的 demo 和自己写的 benchmark。

三条线一交汇,问题的提法也跟着变了。以前是谁先训出来谁先进;现在是,谁先把 ROI、折旧、副作用、评估代价算清楚,谁才有资格上桌决策。

而这道题真正难在哪——航空航天行业有 4 个让答案完全不同于互联网 / 金融 / 医疗的独特约束。

四、航空航天的 4 个独特约束

我们并不是要把行业的特殊性夸大，而是要看清楚下面这 4 条之后再回头看 BloombergGPT 等等案例——才能判断它到底外推得动还是外推不动。

事先说明本系列边界——避免读者把不相关的话题代进来。

本系列是纯技术讨论。 不涉及任何监管 / 政策 / 行业准入这类话题。立场是:AI 大模型只是工程师的辅助工具,任何最终留在档案里需要评审、签字、负责的内容,都是工程师作为决策者亲自做的判断——被审计的是人,不是工具。

本系列讨论的是企业怎么把大模型用在研发、设计、生产、制造、运维这整套业务流程上,目的是提效、提质。 不讨论把 AI 嵌入到产品本身(飞控、FADEC、星载计算机、自动驾驶仪等)那种安全关键场景——那是另一个完全不同的话题,约束体系、工程方法学、风险模型都不一样。

下面 4 条约束讨论的全部是企业研发生产运维流程层面的纯技术工程内容。

约束 1:真正稀缺的不是数据量,是能完整体现工程决策的文本

先澄清一个常见误解。

航空航天的痛点不是物理存储意义上的"数据量小"。一个型号几十年研制累积的 CAE 仿真结果、风洞试验数据、试飞遥测时序,加起来达到百 TB 是非常正常的;某些大型主承包商内部数据资产已经到了 PB 级。

真正稀缺的不是 bytes。

是那些能完整体现工程决策过程的、可用于 LLM 训练的高密度文本——这种东西极少。

医疗、法律是专而深的领域——专业范围相对收敛，但单一专业内部的高语料密度文本 case 海量（一家三甲医院一年的电子病历、一家律所一年的判例评注，都是数十万到数百万级的自然语言样本）。所以 Med-PaLM、Harvey 这种"垂直 fine-tune"在数据规模上是说得通的——尽管它们最后也都被通用模型代际反超（后面会讲）。

而航空航天的工程逻辑样本是横向极宽 + 纵向极慢 + 闭环案例极少的复合稀缺：

• 横向：比如一个完整的航天 OEM 涉及空气动力学、结构力学、飞行控制、航电、推进、材料、维修性、人因工程、系统工程、构型管理、供应链协同、试验试飞……几十个并行子专业，每个都需要自己的 know-how，相应的高语料密度文本被切碎到几十个分子集
• 纵向：以 MBSE 为例，MBSE 的核心逻辑从 1990 年代 INCOSE 奠基至今没有本质变化，行业核心工程标准的条款年度增量很小，结构 / 气动 / 飞控的基础理论几十年没动——这意味着"用微调追上最新知识"这个常见动机在航空航天里几乎不成立
• 闭环案例:一家飞机 OEM 60 年能造多少个完整商用机型号?10 个?20 个?就算 100 个吧——和手机 6 个月一代、一年几十个 SKU 的迭代密度比起来,完整设计决策闭环的样本数是不够用来跑监督学习的。每个型号的核心架构权衡 / 排故直觉,往往断层在总师人脑与物理试验结果之间;真正能把那一手判断讲清楚的人,基本不会留下足够多的可训练文本。

很多真正关键的工程判断,最后甚至不在系统里。

是在总师办公室里的一句口头意见,一张白板上的草图,或者一次评审会上的脸色。

这些东西落不进语料库。

把这三重稀缺加在一起,任何一家航天 OEM 想用自己的数据训出"行业大模型",在统计学的最朴素意义上就站不住。

它能做的事,是把通用大模型已有的航空知识"组织得更适合自己用"——也就是后面会反复提到的工业认知系统外侧那一层。

但它没法"再造一个比通用模型更懂航空的模型"。

很多人在董事会上谈"数据是我们的护城河"的时候,讨论的其实根本不是同一种数据。

约束 2:非文本数据是真正的独家资产,但跟"航天大模型"叙事是两件事

航空航天的非文本数据——卫星图像、SAR 雷达、CFD 仿真、风洞数据、遥测时序、CAD B-rep——巨大且独特,这部分确实是通用大模型预训练分布外的。但这些数据的正确归宿是多模态领域底座(如 NASA Prithvi 那种 vision encoder),不是"航空航天 DeepSeek"那种语言模型。

很多"自训"叙事的混乱,恰恰起源于这一处:**把"我们有大量独家非文本数据"直接外推成"所以我们该有一个自己的DeepSeek大模型"**。

但凡在董事会汇报里见过几次"我们的卫星图像、风洞数据都是独家资产"和"所以我们要训自己的大模型"被连成一段话讲出来的人,大概都知道这两件事其实不在一个频道上。

约束 3：企业级 IT 系统迭代节奏 vs 基座模型代际节奏的错配

再次重申，本系列讨论的不是某个型号产品本身的智能化,而是企业把大模型用到研发、设计、生产、制造、运维这一整套业务流程里的路径。这一套企业级 IT 系统的建设和迭代节奏,受限于业务流程标准化周期、跨部门协同成本、与既有 PLM / MES / CAD / MBSE 工具栈的集成代价,通常按 3-5 年甚至更长的节奏迭代——一套企业级系统从立项、招标、开发、试运行、推广到稳定运行,3 年是快的。

而前沿基础模型的代际跃升节奏,在 2026 年是 **6-9 个月一代,每代能力提升 20-40%**。

这就是一组刚性的时间尺度错配。

你今天投入资源微调出的"企业自有大模型 v1",等按企业 IT 系统的节奏完成集成、上线、培训、推广时,前沿基础模型可能已经走过 3 到 5 代了。你的 v1 相对最新基座的"领先窗口"早已关闭。

要么接受被持续代际效能超越;要么按 6-9 个月节奏不停重训、重新集成——而后者意味着你的企业 IT 系统永远处在"在建状态",永远无法稳定运行。

这是把 AI 模型当成传统 IT 系统去管的玩家,最容易踩的一个时间尺度陷阱。

见过几个项目这么折腾下来——重训、重新集成、再重训——三年下来,真正稳定运行过的版本,一个都没有。

约束 4：工程数据格式的"分布外性"

CAD 的 B-rep / STEP(三维几何与标准交换格式)、CAE 的 NASTRAN bdf(有限元求解器输入卡)、PLM 的 OSLC(Open Services for Lifecycle Collaboration,产品生命周期协作开放标准)、MBSE 的 SysML v2(系统建模语言第二代)、ReqIF(需求交换格式)、Polarion(西门子需求 / 测试管理工具)——这些是通用大模型预训练语料里基本不存在的格式。

也是后面争论"应不应该自训"时,**唯一能站住脚的"独家数据"**。

但这个独家性留不了太久。

提供这些数据的工业软件厂家——西门子、达索、PTC、Autodesk——正在把这些格式的模态喂进各自工业软件所依赖的大模型里。最后大概率会变成:他们自己先把这些格式吃透,封进自家的产品 AI 助手里。

工业软件厂家比你更懂你自己的数据格式——这件事,很多企业最后会很尴尬地意识到。

把这 4 条放在一起就会发现:照抄互联网 / 金融 / 法律的答案,在航天这边不成立;但反过来,拿"我们行业特殊"当挡箭牌、绕过 BloombergGPT 那种代价惨痛的教训,同样不成立。

两头都堵着,这笔账真到董事会上,并不好讲圆。

下一篇预告

5 档颗粒度切清楚、4 个约束摆出来,这道题才聊得下去。

下一篇准备把它继续往下拆。

下一篇会顺着几位 AI 一线代表人物各自的研究路径——马斯克、Karpathy、Ilya、黄仁勋、Schulman、Olah——看看如果让他们各自的逻辑出发,这道题会被算成什么样。

到最后大概率会发现:很多人现在讨论的,其实根本不是同一个问题。

下一篇见。

《头部企业大模型应用路径深度分析》系列共 6 篇,本篇为系列(二)。