系列说明
这是《行业头部企业大模型应用路径深度分析》系列的第一篇。本系列计划一共 6 篇，围绕"头部企业是否应该用自己的数据微调出一个'行业大模型'"这一战略命题，做一次完整的技术与治理拆解。
系列的核心命题是:在 2026 年这个时间节点,对于绝大多数严肃考虑"自训大模型"的头部企业而言,正确的工业 AI 路径并不是用自有数据 + 开源底座蒸馏出一个减配版的行业 LLM,而是构建一套以前沿通用底座为引擎、外侧由工程本体、领域算子、工具链、校验层组成的工业认知系统。
本系列将依次展开：
（一）本篇：训了大半年、用了小半年——头部企业自训大模型的年中工况复盘 （二）颗粒度与独特约束：把"自训大模型"5 档颗粒度切清楚 （三）5 条独立理论线索 + 4 个追问的交叉验证 （四）四种"应该自训"立论的技术可行性论证 （五）以 Boeing 和 Airbus 为参照——工业认知系统的工程范式 （六·终篇）反共识结论与战略重定向
本文设定：时间点 = 2026 年 5 月底（Q2 末 / 年中复盘窗口期），本文中所提及的模型名（Claude 4.7 / GPT-5 / Gemini 3 / DeepSeek-V4-Pro 1.6T MoE / Llama-4 / Qwen3 等）都反映该时间点的可观察前沿状态，并作为论证基础。具体型号若与读者所处时间点的真实状态有出入，请以"前沿基座大模型 6–9 个月一代"这条节奏为准——结论不受影响。
一、典型场景的构造
为了讨论一个普遍存在的工程治理问题，我们先构造这样一个典型场景。
假设 2026 年 5 月底，某头部航天企业（业内对应运载火箭主承包商 / 卫星总体所 / 深空探测器研制单位 / 商业航天主力玩家这类形态）正面对一组并不轻松的年中复盘数据。这家企业过去 12 个月所经历的技术路径，在全球多家头部 OEM 内部都能找到对应版本：
去年下半年起，这家企业动员了内部多家分公司、组织上百名工程师，以企业自有数据对某主流开源基础模型的小尺寸版本进行了一轮 post-training + LoRA + SFT。该轮训练未触及全量参数，亦非从零开始预训练；算力一部分自云厂商租赁、一部分由企业新采购的本地集群提供；底座选型、数据管线、训练代码、评测脚本均按内部立项规范配齐。这一阶段工作在工程颗粒度上对应 LoRA / SFT / post-training 这一档轻量微调路径。
2025 年底的企业年终汇报中，该项工作的内部口径被定为"取得阶段性成果，初步验证了大模型 + 企业数据微调路线的可行性"，并列入 2026 年重点立项清单。Q1 企业沿此口径继续追加投入：启动多模态特化训练的第一批数据准备，开展"思维链" SFT 的实验性论证，并向董事会承诺在 H2 交付"v2 版本"。
二、服务调用频次审计与 Shadow AI 偏差
我们继续补充这个场景的构造：
2026年Q1 起，企业同步启动了一项被董事会持续关注的工作——v1 实际使用率追踪。每月拉取服务调用频次与吞吐审计数据,统计各部门调用规模、各业务场景日均请求量、请求量低活区间;AI 工作周报里柱状图、折线图、热力图配齐。
数字倒是一路在涨。
然而进入 H1 中段，技术管理层逐步意识到该项使用率追踪机制存在一个根本性的指标盲区：服务调用频次审计无法回答研发人员是否真实采用了企业自训底座、抑或在受控边界外通过其他通道独立完成了任务处理。服务吞吐数据仅反映自训底座的被调用频次，并不反映其被调用的真实必要性——调用量上升可能来自模型效能改善，也可能仅源于内网默认配置以及外部模型在企业网络中的受限访问。在 v1 表现偏离预期的工况下，研发人员是否通过个人终端、外部备用通道完成关键任务，并不会反映在内网审计报表中。
该现象在企业 IT 治理领域有一个标准术语:Shadow AI(影子 AI,类比 Shadow IT)。这种由内网硬性捆绑带来的表面上的数据繁荣,在数字化转型中表现为一种尴尬的"逆向选择":
服务频次审计报表上那些漂亮、高频的 Token 吞吐量，拆开看，大量消耗在撰写行政周报、格式化请示、润色发言稿等常规的行政与事务性工作上；而真正到了型号构型优化、试验故障定位等复杂的跨学科研制工况，研发人员因不满内网底座的逻辑退化，正在悄悄通过个人手机、平板等受控隔离边界外的通道，把 Prompt 喂给外面的通用模型。
这就导致了数字化治理中最不愿见到的指标失真:审计数字既高估了自训底座对核心研发效能的实际贡献,又掩盖了外部前沿底座在各业务线上的真实渗透率。 两笔账目同向叠加,让 AI 工作周报里的折线图,彻底变成了无法指导技术纠偏的数字游戏。
在这家企业内部,甚至形成了一种很微妙的双轨状态——内网模型负责合规和留痕,外网模型负责真正解决问题。这件事在工程师之间是公开的默契,在汇报里却从来不提。
与此同时,外部基础底座的代际跃升并未因企业内部立项节奏而放缓。Claude 4.5 → 4.7、Gemini 2.5 → 3、GPT-4o → GPT-5、DeepSeek-V3 → V4,每个 6–9 个月周期内能力指标整体提升 20–40%。
结果就是,自训底座这半年吃力挪动的每一点性能增量,在外部底座每半年一次的"代际自然增长"面前,被直接无情抹平。不需要公司操心,对方自己每天都在涨。
于是出现了一两条不同的曲线:自己训的模型想往上走,走得极其吃力;外面不用公司操心的模型,每天都在代际自然增长。
参与项目的研发人员在 v1 上线初期即已观察到这一现象：在部分标准格式的文本处理工况中，自训底座对企业内部术语与文档结构的拟合度优于通用底座；但在另一些工况中，通用底座辅以适当 prompt 工程已可达成同等或更优表现，叠加多智能体编排与算子调用后效能进一步领先。由于缺乏白盒化的第三方基准评估框架，自训底座的实际技术增量在工程界一直处于无法被严密证伪的状态——年终汇报中的"正向评价"在更大程度上是组织氛围的产物，而非严格技术评估的结果。
进入指标对照之前，必须先把两类性质截然不同的微调动作解耦。第一类是继续预训练(CPT)路径,试图通过改动基础模型权重让它"学会"航天工程知识,最终做出一个通用型的行业/企业大模型——这条路上的支出,在资产管理上属于持续折旧的组织负债,6 至 9 个月即面临技术贬值。第二类是特定任务蒸馏（SFT）路径，目标极其明确，例如仅在物理隔离的内网中跑"维修工单结构化"——这类工作在研发投入上属于当期摊销的确定性工具，在当前任务周期内即可完成价值收回。本文及本系列后续所有批判性论证，仅针对前者。
三、年中工况复盘的三场景指标对照
到了 2026 年 5 月底，这套微调方案在历经小半年的生产实景运行后，第一手指标对照数据开始显形，底座能力在三个典型工况下呈现出清晰的分化：
场景一：维修工单结构化（达到预期）。这类任务属于相对封闭、格式高度受限的标准格式的文本处理工况。自训底座 v1 表现稳定，输出规范性明显优于通用底座外挂检索（RAG）的组合，指标领先 8–12 个百分点。 场景二：设计评审辅助（出现偏离）。在初期双方打平，但随着外侧多智能体编排（Agent）与工具链的持续迭代，通用引擎在最近 8 周内完成效能反超，拉开了约 5% 的效能增量。 场景三：故障诊断思路推理（差距持续扩大）。这类工况对跨学科长链推理要求最高，v1 自上线起效能表现即低于对照组，在外部基座每 6 至 9 个月一代的自然增长节奏面前，其长链推理的边际劣势正在随时间推移而持续拉大。
在三个场景指标对照的基础上,叠加 4 月底某主流基础模型公司完成新一代基座发布的事实——v1 相对最新基座的整体能力差距,由年初的"约略相当"演化为"显著落后于一线"。
这件事,v1 项目组里的人其实早就知道。
只是大家都在等一个体面的时间点把它讲出来。年中复盘窗口期,就是这个时间点。
这一阶段性评估结果直接引发了企业技术管理层对"继续预训练自训行业大模型(CPT 全量参数级)"这一战略路线的根本性反思。AI 总师在撰写下半年立项建议书时，面临一个底层的技术治理判定：当前微调路径，究竟是在沉淀核心技术资产，还是在积累不可观测的 IT 负债。
四、决策点摆开
随之而来的是一组刚性的决策点：年中复盘的内部交代如何形成；已向董事会承诺的 v2 版本是否按原计划推进；已投入的算力、人力、半成品 v1 模型如何在不浪费的前提下完成路径转向；年底前需要呈报的"企业大模型路线进展"如何在新的判定下重新表述；若中止后续投入，前期沉没成本如何在董事会层面完成说明。
若按原计划在 H2 继续加码,企业内部面对的工程难点更为集中。
多模态特化训练。 选择该方向的工程动因是双重的:一方面对应大模型整体演进的多模态趋势,另一方面卫星图、CAD、CFD 仿真、吹风数据、试验照片与视频等非文本工程数据确实属于企业的独家资产。
推理范式特化。 通过 SFT 与受控 RLHF,使模型在工程标准解读、MBSE 功能分配、维修排故等任务上贴近企业内部认可的专家推理路径。
数据可训练性的真实瓶颈。 将几十年积累的、跨越纸质档案到当前信息化系统的设计文档、试验数据、质量管理体系文件、维修工单清洗为可训练高质量语料的工程量,要么需要超过项目预算的人力投入,要么质量难以保障。而以质量难以保障的语料执行模型参数拟合,v1 版本本身已构成前车之鉴。
算力一部分已租赁、一部分已采购到位， H2 阶段的后续投入应当配置到何处？
更深一层的管理阻尼在于考核机制。主导大模型立项的技术负责人，多为过去十几年负责信息化与数字化转型的资深工程师。他们对传统的专家系统、规则分类非常熟悉，面对 2026 年的大模型引擎时，其惯性思维往往是：**"把企业所有的流程管理文件和规章规程喂给大模型，试图让它学会如何跑业务流程"**。
在传统的组织考核框架里,这是一条极易跑通且风险最低的路线:用了多少算力、拟合了多少参数、重训了几个版本,这些指标可以直接翻译成"可量化的数字化技改成果"呈报董事会。相比之下,去打通跨部门的工业软件接口、去清洗底层 CAD / CAE 数据、去构建白盒工程本体——工作太脏、太慢、太难出 Demo。这种内部考核可见度的错配,才是导致企业资源天然流向自训行业大模型这一"IT 折旧负债项"的隐性根源。
真正让很多技术负责人焦虑的,其实不是模型不够强,而是越来越难证明"这个模型必须是企业自己训的"。
没人敢明确反对。
但也没人真的相信。
会议室里没有掌声，也没有质询。决策卡在某种集体性的迟疑里——所有人都心知肚明 v1 的真实工况，但谁也不愿意第一个把它说破。
在年中复盘窗口期，CEO 层面需要回答的是：H2 阶段的预算配置应如何拍板；董事会再次询问"企业自训底座在多大程度上替代了外部模型"时，企业层面如何提供具有说服力的应答——回答的口径不应再是服务调用频次数据，而应是"在哪些业务场景上企业构建出了通用底座 + 工具链路径所无法替代的工程价值"。
CTO 层面需要回答的是：如何向 CEO 解释"过去一年算力与人力投入下，v1 仅在三个典型业务场景中的一个达到预期、且 H1 服务吞吐审计无法回答研发人员真实采用率"这一事实，以及如何对 H2 路径作出技术治理上的重新判定。
AI 总师层面需要回答的是：如何对"企业大模型应用"这一命题进行底层重整——使其既不再退化为"低代码 / RAG / 知识图谱 + 大模型"这一类将新技术套入既有信息化框架的形式主义路径，也不再固化为"模型上线 → 强制内网默认 → 服务报表漂亮"这一类无法证伪自身价值的闭环。
这一组决策点——v2 是否按原计划训、训的方向是什么、若停下来路径如何转向、已投入资源如何消化、"企业大模型应用"这一底层命题是否需要从头重整——并非这一家头部企业的独有命题。
它的对应版本可以是欧美航空航天巨头的（Boeing / Airbus / Lockheed Martin / Northrop Grumman / Raytheon / SpaceX），也可以是亚洲与新兴航空航天工业体内任何一家做大型客机、运载火箭、卫星、无人机、航发的型号研制单位与制造商。只要这家公司曾经认真做过或正在做"用我们自己的数据，在开源基座上做一次完整 continued pretraining + SFT，希望得到一个'企业大模型'乃至'行业大模型'"——它就在面对同一道题。
特别是商用飞机、大型运载火箭、能源、钢铁这种赛道的头部企业——这类企业天然会觉得"我最了解行业，我训出来的，就是整个行业大模型"。这个心理预设是这场迷茫的一部分根源。
大多数企业在立项阶段都低估了这道题的颗粒度，也低估了路径选错的代价。
五、三个具有代表性的失败案例作为参照
先看三个具有代表性的失败案例作为参照基础。
BloombergGPT(2023):彭博社执行过一次较为完整的尝试——以 50.6B 参数 + 709B tokens 训练语料库(其中约 363B 来自 Bloomberg 自 2007 年起累积的独家金融语料,覆盖财经网页内容、第三方新闻、SEC 申报文件、企业新闻稿与彭博自营财经稿件;实际训练投喂了语料库的约 80%,即 569B tokens,因验证损失停滞而提前止训),按公开估算投入 10M 区间的训练成本,完成了 BloombergGPT 的训练。
结果数据是:独立研究(皇后大学与摩根大通 AI 研究团队,arxiv 2305.05862)显示,OpenAI 的 GPT-4 在未接触任何 Bloomberg 内部数据的前提下,在 ConvFinQA 金融问答数据集上 zero-shot 准确率达到 76.48%,在 FinQA 上达到 68.79%;而 BloombergGPT 在 ConvFinQA 上仅为 43.41%(BloombergGPT 在 FinQA 上未给出公开成绩)——通用基座在该垂直领域上表现出更强的泛化推演能力。这件事的含义其实很直白:在大模型代际跃升的常态下,最先进的通用基座在垂直领域上的零样本能力,可能已经反过来高于以独家数据特化训练的同代模型。这就意味着,"我们的私有数据 + 我们的微调",并不会自动变成谁也碰不到的技术壁垒。
这一判断在过去三年间已经成为多数严肃考虑"自训行业大模型"的董事会层面的标准技术警示。
IBM Watson @ MD 安德森癌症中心（2012-2017）：IBM 用 Watson Health 与全球顶级癌症研究机构 MD 安德森癌症中心合作，总项目成本约 6200 万美金（原始合同 240 万美金、续约 12 次、IBM 合同费 3920 万美金 + PwC 项目支持 2300 万美金），目标是用 AI 辅助癌症诊断与治疗方案。结果是项目 2016 年 9 月在仍处于开发阶段时被叫停,2017 年 2 月经独立审计报告公开披露后正式终止——系统从未走出 MD 安德森本部、从未指导过任何社区患者的诊疗。
Watson 真正失败的地方,其实不是模型。
是整个医疗 workflow 根本接不进去——数据、临床流程、医生信任,每一层都对不上。"用领域独家数据 + 自建专用 AI"在系统集成层面有多难,Watson 是头一个把这件事写在桌面上的。
Babylon Health（2013-2023）：英国 AI 驱动的数字健康独角兽,2021 年 10 月通过 SPAC 在纽交所上市时估值峰值 42 亿美金,核心产品是用自有数据训练的 AI 症状评估 chatbot,与英国 NHS 深度合作部署。2023 年 8 月申请 Chapter 7 破产,UK 业务被 eMed 以约 50 万英镑($620,000)收购——估值蒸发 99.99%。
2022 年净亏损 10 亿、与 MindMaze 的 take-private 在 2023-08 崩盘、SPAC 上市后股价从 $272(1-for-25 反向并股调整后峰值,2021 年 10 月)跌至破产后 OTC 几近归零,18 个月公开交易期内市值蒸发逾 99%。
Babylon 最后真正的问题,可能根本不是模型。
而是整个医疗系统,并不愿意按一家 AI 公司想象的方式来运转。"用我们的独家健康数据训出的 AI 比通用医疗系统更准"——这个故事讲得动听,但没有人愿意按它的剧本演下去。
把这三个案例并排起来看，彭博社、IBM 医疗、Babylon Health——三个完全不同行业、横跨 2013-2024 整整 11 年的尝试，每一家都是以"我们有最独家的数据 + 最强的工程团队 + 充足的资金"姿态进场，每一家最终都没能形成可持续的产品/商业护城河。
彭博社、IBM 医疗和 Babylon 的百亿代价汇成一句话:在通用大模型时代,企业用自有数据 + 开源底座微调出来的行业/企业大模型,很难自动成为技术护城河。
最后真正留下来的,往往不是模型本身。
而是谁已经把模型嵌进了自己的工作流、工程系统和组织流程里。
但仍然有一种声音坚持:"我们这个行业不一样。我们的数据更稀缺、知识更专精、模态更独特。我们是这个行业的头部企业，我们应该有自己的大模型。"
这套立论在真实的研发账本上到底能不能算得过账,大模型在航天型号研制里的合理位置究竟在哪,需要回到系统工程的技术范式里去重新对齐。这正是这个连载系列接下来要拆开看的硬核内容。
系列推进大纲
本篇先把一个构想中的头部企业过去一年在自训大模型路径上的工况摆开:审计失真、Shadow AI 静默替代、自训底座边际效益被通用基座代际增长覆盖、三个典型场景里只有一个达到预期。
这些可能还都只是表面。
在接下来的系列(二)里,我们会直接切进"自主训练大模型"这句行业漂亮话底下的 5 档工程颗粒度,顺便把以传统航天行业味代表的4 个刚性技术约束聊透。
下期见。
《行业头部企业大模型应用路径深度分析》系列共 6 篇，本篇为系列（一）。
