企业要不要拿自己的数据微调一个＂行业大模型＂?|(上篇)微调的目的是什么?值不值?开源模型 + Agent 够不够?训完会不会变弱智?

我们做了一场严肃的多 agent 二元辩论：6 位顶级 AI 专家（Elon Musk / Andrej Karpathy / Ilya Sutskever / Jensen Huang / John Schulman / Chris Olah）的 AI 分身从技术、经济、可解释性视角拆解，3 个支持自训立场的角色（航空航天 CEO / 数据主权专家 / 成功案例研究员）从战略视角应辩，1 个独立 critic 魔鬼代言人全程反驳。复盘 BloombergGPT、IBM Watson、Babylon Health 三个百亿级失败，深扒 NASA-IBM Prithvi、Med-PaLM 2、Lockheed Astris AI、Anduril Maven 四个真正落地的案例——给你一份可以直接拿到下个季度战略会上用的决策框架。

一、"今年到底还要不要继续微调/训练自己的大模型？"

在一个平行宇宙里的 2026 年：

某火箭制造商在前一年的下半年，动员了公司内的好几家分公司，组织了上百号工程师，用自己积累的数据，对一款主流开源基础模型的小尺寸版本做了一轮 post-training + LoRA + SFT —— 没动全量参数，更不是从零开始训练。算力一部分是去年从云厂商租的，一部分是公司新采购、即将到位的本地集群。底座、数据 pipeline、训练代码、评测脚本——能想到的都搭起来了。

一句话概括 2025 年的工作就是"轻量级微调一个别人开源的模型"，对应的是工程上的 LoRA / SFT / post-training 这一档颗粒度。

年底的公司年终汇报上，这件事的口径是"取得阶段性成果，初步验证了大模型 + 公司数据微调路线的可行性"。台下点头，台上鼓掌，PPT 翻完，列入下一年度重点立项清单。

但参与项目的工程师都心里有数——真的好用吗？在内部一些场景上"看起来比通用模型更懂我们公司的术语和文档结构"，但在另一些场景上"通用模型加点 prompt 反而更好"，如果加上点 Agent + skill，那效果就更好了。没有一个第三方可信的 benchmark 能下定论说自己训的模型真的更强。年终汇报的"正向评价"更多是组织氛围的产物，不是技术评估的结果。

时间到了 2026 年的 Q1，决策点摆在了公司面前。还要不要继续？训了大半年，停下来怎么交代算力沉没成本，怎么交代几百号人投入的人力账，怎么交代向董事会承诺过的"我们也要有自己的航天大模型"？ 但如果继续训，问题更棘手：

• 一方面想加码做多模态微调——不仅因为 AI 界大模型的进化趋势是多模态，还因为卫星图、CAD、CFD 仿真、风洞数据、飞行试验照片视频，这些非文本数据是真正的独家资产
• 另一方面又想训自己的"思维链" ——通过 SFT / 部分 RLHF，让模型在理解行业核心工程标准、理解 MBSE 功能分配、解维修排故时按公司内部认可的"专家推理路径"思考
• 但真正的瓶颈卡在数据上：要把几十年积累的，从纸质文件时代开始遗留的，到现在半吊子信息化系统里的设计文档、试验数据、质量管理体系文件、维修工单清洗成可训练的高质量语料，要么投入超过整个项目预算的人力去做，要么质量难以保障——而拿"质量难以保障的数据"去微调训练，已经训出来一次的版本可以作为前车之鉴。

当然了，全量参数全精度训练不在任何一个候选方案里，那是 GPT / Claude / Gemini 这种基础模型公司一年烧几十亿美金做的事。

但是，算力一部分租了，一部分买了，钱已经花出去了。问题不是"要不要做 AI"——这个判断早做完了。问题是"今年这笔继续投入到底应该往哪儿走"。

更微妙的一层是：主导这些事的公司 AI 总师、AI 工程师、大模型总师等等，背景是过去十几年做信息化、做数字化转型的老兵。他们对传统 AI 范式很熟——决策树、规则推理、专家系统、深度学习简单分类，他们能讲一整天；但面对 2026 年的大模型，他能想到的就是让大模型去用做流程管理的数据去训练，让大模型"学会"各个业务部门的流程。

会议室里没人反对，也没人觉得这真的能解决问题。有点迷茫。

如果你是这家公司的 CEO，你会拍板继续投这笔钱吗？

如果你是这家公司的 CTO，你会怎么向 CEO 解释"我们的微调到底产出了什么"？

如果你是这家公司的 AI 总师，你怎么定义"我们应该怎么对待大模型"这件事，让它不再是"低代码 / RAG / 知识图谱 + 大模型"那种把新工具塞进旧框架的糊弄方案？

这道题——还要不要继续微调训练自己的大模型？继续训的方向是什么？停下来又往哪儿转？——不仅仅是这一家火箭制造商面对的题。

它的对应版本可以是欧美航空航天巨头的（Boeing / Airbus / Lockheed Martin / Northrop Grumman / Raytheon / SpaceX），也可以是亚洲与新兴航空航天工业体内任何一家做大型客机、运载火箭、卫星、无人机、航发的型号研制单位与制造商。只要这家公司曾经认真做过或正在做"用我们自己的数据，在开源基座上做一次完整 continued pretraining + SFT，希望得到一个'企业大模型'乃至'行业大模型'"——它就在面对同一道题。

特别是商用飞机、大型运载火箭、能源、钢铁这种赛道的头部企业——这类企业天然会觉得"我最了解行业，我训出来的，就是整个行业大模型"。这个心理预设是这场迷茫的一部分根源。

几乎所有的玩家都低估了这道题的颗粒度，也低估了答错的代价。

先把答错的代价放出来作为基调：2023 年夏天，彭博社（Bloomberg）真的尝试过一次。他们用 50B 参数 + 711B tokens（其中 369B 是 Bloomberg 自 2007 年起独家积累的金融语料：财报、市场分析、SEC 文件、内部通讯），烧了大约 1000 万美金，训出了 BloombergGPT。

结果是什么？Queen's University 的独立研究发现，OpenAI 的 GPT-4 在没有读过任何 Bloomberg 数据的情况下，在 FinQA 金融问答数据集上 zero-shot 准确率达到 68.79%，反过来超过了 BloombergGPT。这个案例被总结成一句话：「最聪明的通用前沿模型，在专业领域里反而比专门训出来的模型更强。你以为很值钱的私有数据，在大模型时代可能没你想的那么有用。」

这句话不是营销文案，是过去三年贴在每一个考虑"自训行业大模型"董事会墙上的警告。

而 BloombergGPT 不是孤例 ——同期还有两个被广泛复盘的"用独家数据建领域专用 AI"百亿级失败案例，从更早的 AI 时代就给出了同方向的警告：

IBM Watson @ MD 安德森癌症中心：2013-2017 年间，IBM 用 Watson Health 与全球顶级癌症研究机构 MD 安德森癌症中心合作，投入约 6200 万美金，目标是用 AI 辅助癌症诊断与治疗方案。结果是项目在 2017 年正式终止——0 个真实患者从这个 Watson 系统的诊断中获益。失败根因不是技术不够强，是"用领域独家数据建专用 AI"在数据集成、临床流程对接、医生信任建立这三个工程层面同时崩盘。一家拥有 IBM 资源 + MD 安德森数据 + 五年时间的组合，仍然没能让自训领域 AI 真正进入临床使用。

Babylon Health：英国 AI 驱动的数字健康独角兽，估值峰值 42 亿美金，核心产品是用自有数据训练的 AI 症状评估 chatbot，与英国 NHS 深度合作部署。2023 年破产，被 eMed 以约 50 万英镑收购——估值蒸发 99.99%。失败根因是 AI 误诊率长期居高不下、医生群体抵制、监管认可受阻、商业模式无法跑通。"用我们的独家健康数据训出的 AI 比通用医疗系统更准"——这个叙事讲了 8 年，最后被市场用 99.99% 的估值跌幅否决。

三个案例放在一起的共同信号：BloombergGPT（金融，2023）、IBM Watson MDACC（医疗诊断，2013-2017）、Babylon Health（数字健康，2013-2023）——三个完全不同行业、横跨 2013-2024 整整 11 年的尝试，每一家都是以"我们有最独家的数据 + 最强的工程团队 + 充足的资金"姿态进场，每一家都在 18-48 个月内撞上同一面墙——用独家数据自建的领域 AI，在真实使用场景里不如通用 AI 系统 + 完整工程集成好用。这不是某一家的偶然失误，是路径本身的结构性错配。

但仍然有一种声音坚持："航空航天行业不一样。我们的数据更稀缺、知识更专精、模态更独特。我们应该有自己的大模型。"

这个声音对吗？

接下来的近两万字，我们让 6 位顶级 AI 专家的 AI 分身 + 3 个支持自训立场的角色（CEO / 数据主权专家 / 成功案例研究员）+ 1 个独立 critic 一起辩论这件事，最后由主持人合成判决。

二、先把"自训"这个词的颗粒度拉细

辩论之前，必须先解决一个语义雾霾。

公众号文章里、董事会里、媒体头条里说的"自主训练大模型"，其实是 5 件完全不同的事，从最贵到最便宜排列大致是：

这 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"。

为什么 2026 年是回答这道题的关键节点？三条线在这一年交汇：

1. 基础模型能力：GPT o-series、Claude 4.7、Gemini 3、DeepSeek-V4-Pro（1.6T MoE / 49B 激活）已经把"通用专家级智能"逼到了几乎所有企业够不着的高度
2. 自训成本：7B 模型 fine-tune 单次 < $5；70B continued pretraining 已降至几十万到几百万美金区间
3. 评估方法学成熟度：第三方独立 benchmark 体系开始大量出现（领域 eval 集、行业基准、对照测试方法），让"微调到底有没有效、强多少、在哪里弱"第一次有了客观尺子，而不是 owner 自己 benchmark 自己

这三条线交汇，意味着"要不要自训"这个问题从过去的"技术上可行就做"变成了"必须算清楚 ROI / 折旧 / 副作用 / 评估代价 才能决策"。

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

三、航空航天的 3 个独特约束

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

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

1. 本文是纯技术讨论，不涉及任何监管 / 政策 / 行业准入这类话题——所以下面没有讨论"AI 在工程档案审计里能不能用"。本文持的立场是：AI 大模型只是工程师的辅助工具，任何最终留在档案里需要评审、签字、负责的内容，都是工程师作为决策者亲自做的判断——被审计的是人，不是工具。
2. 本文讨论的是企业的研发、设计、生产、制造、运维这一整套业务流程上的大模型应用，目的是提效、提质。不讨论把 AI 嵌入到产品本身（飞控、FADEC、星载计算机、自动驾驶仪等）那种安全关键场景——那是另一个完全不同的话题，约束体系、工程方法学、风险模型都不一样。

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

约束 1：专业极其多 + 知识迭代极慢 + 历史案例极少 —— 三重数据稀缺。

这是航空航天和医疗法律最本质的区别。

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

而航空航天是横向极宽 + 纵向极慢 + 样本极少的复合稀缺：

• 横向：一个完整的航天 OEM 涉及空气动力学、结构力学、飞行控制、航电、推进、材料、维修性、人因工程、系统工程、构型管理、供应链协同、试验试飞……几十个并行子专业，每个都需要自己的 know-how。
• 纵向：以 MBSE 为例，MBSE 的核心逻辑从 1990 年代 INCOSE 奠基至今没有本质变化，行业核心工程标准的条款年度增量很小，结构 / 气动 / 飞控的基础理论几十年没动。这意味着"用微调追上最新知识"这个常见动机在航空航天里几乎不成立。
• 样本：一家飞机 OEM 60 年能造多少个商用机型号？10 个？20 个？就算 100 个吧，和手机 6 个月一代、一年几十个 SKU 的样本规模比起来，连个零头都算不上。

这三重稀缺意味着：任何一家航空航天 OEM 想用自己的数据训出"行业大模型"，从样本量这个最朴素的统计学角度，都不构成有效的监督学习问题。它能做的是把通用大模型已有的航空知识"组织得更适合自己用"，但不能"再造一个比通用模型更懂航空的模型"。

约束 1.5：非文本数据是真正的独家资产，但跟"航空大模型"叙事是两件事。

航空航天的非文本数据——卫星图像、SAR 雷达、CFD 仿真、风洞数据、遥测时序、CAD B-rep——巨大且独特，这部分确实是通用大模型预训练分布外的。但这些数据的正确归宿是多模态领域底座（如 NASA Prithvi 那种 vision encoder），不是"航空航天 Deepseek"那种语言模型。常被混在"自训"叙事里的，恰恰是这个混淆。

约束 2：企业级 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 系统的传统玩家最容易踩的一个时间尺度陷阱。

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

CAD 的 B-rep / STEP、CAE 的 NASTRAN bdf、PLM 的 OSLC、MBSE 的 SysML v2、ReqIF、Polarion——这些是通用大模型预训练语料里基本不存在的格式。也是后面争论"应不应该自训"时唯一能站住脚的"独家数据"。而提供这些数据的设计工具的厂家也正努力把这些格式的模态加入到各自工业软件所依赖的大模型里。很难想象一个软件的用户对软件数据格式的理解能超过软件的开发者。

把这 3 条放在一起，意味着任何一个航空航天企业讨论"要不要自训大模型"时，不能照抄互联网 / 金融 / 法律的答案，但也不能用"我们行业特殊"作为绕过 BloombergGPT 教训的免死金牌。

接下来辩论开始，有请我们各位专家的 AI 分身。

四、六位顶级专家轮流登场

为了让这场辩论有客观的力量，我们把 6 位真正在前沿做 AI 大模型的人的公开观点整理出来——他们从不同角度回答同一个问题。先把每个人是谁、为什么他对这件事有发言权说清楚，再听他怎么说。注意：这 6 位中只有 1 位（Elon Musk）真正在做航空航天和AI，但其他 5 位的判断恰好构成本辩论最强的技术论据来源。

4.1 Elon Musk：第一性原理 ——「你要的是拥有一个模型，还是让 AI 创造价值？」

他是谁：xAI 创始人兼 CEO（2026 年 Grok 5 已发布、xAI 估值进入千亿美金级）；同时是 SpaceX CEO（猎鹰 9 号、星舰 Starship、星链 Starlink 的实际指挥者）、Tesla CEO（FSD 自动驾驶的工业 AI 实践者）。这意味着 Musk 是唯一一位同时在做大模型公司、航空航天实体、以及大规模工业 AI 落地的科技巨头 CEO——他对"航空航天企业要不要自训大模型"这件事，比任何一位纯 AI 研究员都有更完整的工程实践视角。Musk 公开拥抱"第一性原理思维"作为决策方法论，他在过去 20 年用这套方法把 SpaceX 火箭单位载荷成本降了 90%、把 Tesla 推上全球电动车销量榜首。

他对这件事会怎么说：

"先问一个根本问题——你要的到底是什么？是'拥有一个属于我们公司的微调模型'这个资产，还是'让 AI 在航空航天研制中创造价值'这个结果？这两件事经常被混为一谈，但它们差着十万八千里。"

"航空航天制造商真正稀缺的不是'通用智能'，那是 OpenAI / Anthropic / Google / DeepSeek 已经替全人类造出来的东西。真正稀缺的是'航空航天研制领域的专有知识结构和工程约束'。 这部分东西，基础模型公司永远不会有，也永远训不出来。所以正确的姿势是——用最强的开源或商用基础模型做底座，把你的稀缺资源（领域数据、专家经验、SysML/MBSE 模型、试验结果）全部投入到 RAG、Agent 编排、工具链集成、Skills 封装 这几个层面上。这是杠杆最大的地方。"

"post-training（包括 LoRA、SFT、RLHF）在某些窄任务上有意义，但它从来不应该是你的主战略叙事——你不会因为'我们也微调了一个模型'就在工程价值上比对手强，你会因为'我们把基础模型 + Agent + 工具链装进了真实的航空航天研制工作流'才比对手强。"

"把上百人、半年时间、整年算力，投到一个'用自己数据微调出'我们的行业大模型'的叙事项目上——除非有强制性的合规或产业政策要求（出口管制、密级数据、本国主权底座要求等）让你必须把模型权重控制在企业 boundary 内，否则纯从工程理性看——这是把美元当干草烧。"

Musk 这一组视角的判决，对应到那家火箭制造商，是非常直接的：你已经做了一轮 LoRA + SFT + post-training，效果不置可否。问问自己，你微调出的那个小尺寸模型，"创造的价值"用任何方式量化，是不是真的高于"把这一年算力 + 人力 + 工程师注意力投在 RAG / Agent / 工具链 / 评估体系"上？ 如果答案是"不确定"——那默认就是"不"。第一性原理不允许你用"沉没成本"压住"边际投入"的判断。

4.2 Karpathy / Ilya：「the data is the model」

他们是谁：

• Andrej Karpathy —— 前 OpenAI 创始团队成员、前 Tesla AI 总监（领导 Tesla FSD 视觉感知团队 5 年），2024 年创立 Eureka Labs 投身 AI 教育；他在 YouTube 上"从零搭建 LLM"系列讲座是过去三年深度学习教育圈最广被传播的一手资料；他对"SFT 本质上是 behavior cloning（行为克隆）"的论述被业界视为微调认识论的圣经
• Ilya Sutskever —— OpenAI 联合创始人、前首席科学家，2024 年离开 OpenAI 创立 SSI（Safe Superintelligence）；深度学习核心理论奠基人之一（AlexNet 共同作者、Seq2Seq 架构提出者、AlphaGo 团队顾问）；scaling law 与 emergence 理论的主要倡导者

为什么他们的视角对本话题最相关：Karpathy 在 Tesla 真正做过"用海量私有数据微调网络"的工业实践，Ilya 在 OpenAI 真正做过"如何用预训练 + 后训练造出 GPT 系列"——他们不是隔靴搔痒的评论员，是一手做过的人。

他们会怎么说：

Karpathy 把它说穿："SFT 本质上是 behavior cloning。模型学的是'在这种输入下，标注者会怎么回答'。" Ilya 关于 scaling 与 emergence 的观点也指向同一方向：模型的上限由数据决定，不由你叫它什么名字决定。

把这条原理代入航空航天场景，第一个问题是：你要训进去的"独家数据"，标注本身有客观正确性吗？

这才是问题的关键。一个航空航天企业过去 30 年的设计文档、需求分解、功能分配、架构权衡——这些 MBSE 核心活动的产物，绝大部分是工程妥协、组织博弈、时间压力下的"够用就行"，而不是"理论最优"。换句话说，这些数据里没有"做对了 vs 做错了"的客观 ground truth——产品通过了最终验收、能交付、能投入使用，那个功能分配就被默认成"对的"。

如果你把这种数据当成监督信号去训模型，模型学到的不是 MBSE 方法论的上限，是"这家公司历史上是怎么妥协的"——这是技术上一个非常严重的问题，叫负向迁移（negative transfer）。而且因为评估指标本身也来自同一批数据，这种退化在 benchmark 上还看不出来。

用一句最锋利的话压缩：训得再好，也超不过当初决定型号架构的那群工程师的水平。

而这群工程师的水平 ≠ MBSE 方法论的上限——他们做的决策本来就不是为了"理论最优"，是为了"项目能往前推"。

Karpathy 这一组视角的判决：你的数据决定了模型的上限。如果你的数据上限是历史决策的平均水平，再多算力也救不了你。

4.3 Jensen Huang 黄仁勋：「build on top, not from scratch」

他是谁：NVIDIA 创始人兼 CEO，2026 年 NVIDIA 是全球 AI 算力底座的实际定义者，市值长期保持在 4 万亿美金级别。Jensen 看遍了过去 5 年所有真正在用 NVIDIA 集群做 AI 的客户——OpenAI、Anthropic、Google、Meta、xAI、DeepSeek、所有美国和中国头部车厂、所有美国和中国头部银行、绝大多数财富 500 强。他对"哪种企业自训路线烧得起、哪种烧不起、哪种烧了也白烧"有最完整的横向数据。他在 GTC 大会和多次行业演讲中反复倡导的"build on top, not from scratch"，是对成千上万真实客户决策案例的归纳，不是空话。

他会怎么说：对绝大多数企业而言，正确的姿势是"build on top, not from scratch"，而且这个 top 应该是 API 层和 agent 层，不是模型权重层。

把这话翻译到 2026 年的实证上，最有冲击力的数据是 Med-PaLM 2 的折旧曲线。

Google 在 PaLM 2 基座上做医学领域微调 + ensemble refinement 提示策略，做出 Med-PaLM 2，在 MedQA / USMLE 风格题目上达到 86.5%，首次让模型在执业医生考试上超过及格线，临床医生在 8/9 个评估维度上偏好 Med-PaLM 2 的回答。这看起来是垂直微调的胜利。

但接下来发生的事更说明问题。微软研究院发表了一项研究："Can Generalist Foundation Models Outcompete Special Purpose Tuning?"——答案是：可以。GPT-4 base + 一个叫 Medprompt 的高级提示工程方案（zero-shot/5-shot prompt + GPT-4 自生成 chain-of-thought + 最近邻 5-shot response scoring），不仅几乎追平 Med-PaLM 2，还在 MMLU Professional Medicine 之外的多项测试上显著超越。研究人员发现 GPT-4 自己生成的 CoT prompt 比 Med-PaLM 2 的"专家手工"prompt 表现还要好。

Google 的反应更值得品味——它直接放弃在 PaLM 2 上继续投入，改在新一代 Gemini 基座上重做医学版（Med-Gemini，MedQA 91.1%，比 Med-PaLM 2 高 4.6%）。

前一代领域微调模型被下一代通用基座超越的速度，大约 18-24 个月。

Google 有 Anthropic / OpenAI 都没有的医学数据访问权限、有顶级研究团队、有任意算力，做出来的 Med-PaLM 2 优势窗口期也就一年多。把这个折旧曲线放到航空航天场景：

每做一次基座级别的 continued pretraining，都在签下一份"6-9 个月就贬值到零"的工程承诺。

要么你接受这种贬值并不断重训（这就回到了"跟训练曲线赛跑"的不可持续状态），要么你冻结在某个特化版上并眼看着它被开源底座追上（这种情况下你的微调投入彻底浪费）。

Jensen 这一组视角的判决：从经济周期看，自训权重的 ROI 在 2026-2028 是结构性为负的。模型权重层的折旧速度太快，任何沉淀都会被下一代基座抹平。

4.4 John Schulman：「Alignment Tax —— 你失去的能力你看不到」

他是谁：RLHF（基于人类反馈的强化学习）的主要奠基人之一——他在 OpenAI 主导了 ChatGPT 的后训练管线，发明了 PPO（Proximal Policy Optimization）和 TRPO 算法（这两个算法是过去 8 年所有 RL 工作的事实标准）。2024 年从 OpenAI 转到 Anthropic 加入 Claude 团队。今天全球能在台面上谈"如何在不损害基础能力前提下做后训练"这个问题的人，全球可能不超过 50 个，Schulman 是其中之一。他在 OpenAI 内部直接对 GPT-3.5 / GPT-4 / o-series 的后训练管线负过责，知道每一种"加 SFT / 加 RLHF / 加 DPO"动作对模型的真实代价。

他会怎么说：这一圈做后训练的人，会从工程现实给出一个被反复观察到的现象——alignment tax（对齐税）：

任何形式的后训练（SFT / RLHF / DPO）都会以某种方式损害基础模型在训练分布之外的能力。

具体表现：模型在被微调的目标任务上变好，但在通用推理、创造性问题求解、长链推理、罕见情境处理上，会出现不同程度的能力衰减。

最致命的一点：这个衰减经常是不可观测的。你的 eval 集覆盖不到，但在真实场景里会撞上。

Anthropic 和 OpenAI 内部都为此付出过巨大代价——这也是为什么这两家公司投入了远超外界想象的资源在"如何在后训练中保住基础能力"上。这是一个前沿研究问题，不是一个工程标准操作。

放到航空航天场景，这意味着两个连环坏消息：

坏消息 1：飞机研制是一个跨学科、长链推理的任务——它需要从材料、热力学、控制理论、人因工程、维修性、典型工程案例等大量看似不相关的领域中提取信息并综合。基础模型之所以好用，恰恰是因为它的"知识图谱"非常宽。后训练做得好，这个宽度被局部加深；后训练做得差，这个宽度被切碎。

坏消息 2（更狠）：要做得好，需要 OpenAI / Anthropic 级别的 alignment science 团队和内部 eval 体系。一家航空航天企业要复刻这套基础设施，代价远超训练本身。 而且——

评估这种负向迁移的能力，本身就是一项前沿研究能力。一家航空航天企业不具备这种能力，意味着即使微调出问题也发现不了。

Schulman 这一组视角的判决：不仅自训可能引入负向迁移，更严重的是你没有能力发现它发生了。这比 BloombergGPT 那种"看得见的失败"还要坏——它是看不见的失败。

4.5 Chris Olah：「可解释性债务 —— 在工程师作为决策者评估 AI 可信度时分量最重」

他是谁：Anthropic 可解释性研究负责人，mechanistic interpretability（机制可解释性）这一研究方向的奠基人之一。在 OpenAI 和 Google Brain 期间领导过 distill.pub（业界最高水准的神经网络可视化与解释期刊），过去 6 年关于"如何打开神经网络黑盒"的工作奠定了整个"可解释 AI"研究范式。Anthropic 之所以在所有大模型公司中对'微调到底对模型做了什么'这件事最有发言权，根源就在 Olah 团队的可解释性研究。 他的视角对任何一个"工程师必须评估 AI 工具输出能不能信"的工程组织，都是分量最重的。

他会怎么说：可解释性团队和更广泛的 mechanistic interpretability 圈，过去几年的核心结论之一是：我们目前没有任何可靠方法直接打开模型权重，验证一次微调到底改变了模型的哪些内部回路。 SFT 和 RLHF 会修改模型权重，但修改的位置、修改的语义内容、修改对其他能力的副作用，在 2026 年仍然是不可解释的——这是当前 AI 研究最前沿的开放问题之一。

这里要单独承认一个反论：可解释性这件事，在 2025-2026 年正在被两套模型外部方法学大幅缓解——

• Harness engineering（评估框架工程化）：通过外部行为追踪、对照测试、轨迹记录、能力探针等手段，在不打开权重的情况下"间接观测"模型的能力边界、失效模式、行为漂移。Anthropic Evals、OpenAI simple-evals、Inspect AI 这一类框架已经把"评估一个 LLM 在某个能力维度上有多可靠"做到了实用级
• Ontology（本体 / 领域知识图谱约束）：通过把领域概念、关系、约束规则结构化成本体或知识图谱，作为模型输出的语义骨架强制约束，让 AI 输出从"自由文本"变成"可结构化、可对照、可追溯的概念组合"

这两套外部方法学的成熟，意味着工程师作为决策者，面对一个原始前沿基座的输出时，已经有相当成熟的工具来评估"这个建议有多可信、它在什么情况下不可信" —— 不需要打开模型黑盒。

但——这正是 Olah 论证最锋利的地方——这套外部方法学是按"原始前沿基座的已知能力分布"建立和持续校准的。当你把基座换成"自己微调过的特化版"时：

• harness 能不能抓到你微调引入的隐性能力衰减？它的探针可能恰好不覆盖你被切碎的那些维度
• ontology 能不能约束住你微调引入的领域偏见？约束生效的前提是模型对 ontology 概念有原始基座那种正确语义对齐——而你微调可能恰好把那个对齐打乱了
• 你要重建这套外部观测体系来匹配你的特化基座，工作量和不确定性比基座微调本身还大

把这个事实放进工程师评估 AI 工具可信度的实际场景，对比就出来了：

结论非常反直觉：

企业自训出的特化模型，在工程师作为决策者评估"AI 输出能不能信"这个最实际的工程问题面前，反而比原始基座更难被有效使用。

为什么？原始基座 + 行业 harness + 领域 ontology 是一套被全球工程社区共同打磨、持续迭代的可观测体系。你的特化版把这套体系自己废掉了，还要从头自建一套——而你的工程师团队既没有 Anthropic 那种 alignment science 团队，也没有几年时间去重新校准。这就是 Olah 视角下的"可解释性债务"——它不是"模型能不能解释"的债，是"工程师能不能信任工具输出"的债。

这一债务还有复利效应。假设 2027 年你用自训基座生成了 3000 份运维工单建议、500 份设计评审意见、200 份技术方案草稿。2030 年发现该基座有一个隐性失效模式（外部调查发现，或下一代评测基准升级后暴露）。你需要追溯并重新审查所有用过这个工具的工程决策——而那些决策当年可能基于的是工程师"过度信任了一个看不清边界的工具" —— 这是任何严重工业系统集成事故的核心教训"系统集成 + 透明度 + 培训"三重红线在 AI 时代的 fan-out。

Olah 这一组视角的判决：工程师作为决策者评估 AI 工具可信度这个语境下，可解释性债务的成本可能远超自训带来的能力增益。Harness + ontology 这套外部方法学解决了原始基座的可信度评估，但对自训基座反而失效——你不仅要重训模型，还要重建整套外部观测体系。自训不是把"能力账"算正了就行，还得算"债务账"——而后者目前没有人能算清楚。

4.6 综合判决：五条独立线索收敛同一判断

把上面 6 位专家（其中 Karpathy / Ilya 合算一组"预训练范式"代表）的视角放在一起：

五条独立线索从五个完全不同方向（工程战略 / 数据本质 / 经济周期 / 后训练副作用 / 可解释性）收敛到同一个判断：在 2026 年这个时间点，对一家航空航天企业的研发-设计-生产-制造-运维大模型应用而言，对一个基础大模型做用自己数据的 continued pretraining + SFT + RLHF，收益不确定、代价大、可解释性债务高、经济周期上结构性贬值，且和"开源模型 + RAG + Agent + 工具调用 + 人类决策节点"路径相比是次优解。

但这只是"反对微调"一方的论证。辩论的另一边——成功案例研究员、数据主权专家、CEO——还没出场。下面让他们说话。

4.7 本文讨论的"微调"到底是什么颗粒度

进入下半场前必须把命题边界再画清楚一次。本文从这里开始所有"自训 / 训自己的大模型 / 行业大模型 / 微调"的讨论，指的都是下面这个颗粒度区间：

在某个开源基础模型（LLaMA / Qwen / DeepSeek / Mistral 等）的某一个尺寸版本（小尺寸为主，部分场景用到中等尺寸）上，用企业自己的数据做 LoRA / SFT / post-training，可能加一定规模的受控 continued pretraining，可能加一些 DPO / RLHF 任务对齐。

而不在本文讨论范围之内的有两类：

• From-scratch 从零造一个基础大模型：这件事在航空航天行业已经几乎没有争议（别做）—— 全球能做这件事的不超过 10 家公司（OpenAI / Anthropic / Google / Meta / xAI / DeepSeek / Mistral 等基础模型公司），任何一家航空航天 OEM 都不在那张名单上，也都没在讨论这件事
• 全量参数全精度的 continued pretraining：算力账单几千万美金起步、需要专门的对齐研究团队保住基础能力——也不在任何一家航空航天 OEM 的实际可选项里

行业里所有被打包宣传成"XX 行业大模型 / XX 企业大模型"的项目，真实工程量级 99% 落在上面那个橙色区间 —— 小尺寸开源底座 + LoRA / SFT / post-training，少数加受控规模的 continued pretraining。这才是真正在被董事会讨论、被立项书写、被算力预算消化、且在 2025-2026 这个节点上真正有争议的颗粒度。

重要的一点：上面 6 位顶级专家收敛出的 5 条论证（第一性原理 / 数据决定上限 / 折旧周期 / Alignment Tax / 可解释性债务），对小尺寸模型 + LoRA / SFT / post-training 同样成立——只是数量级不同。LoRA 比全量微调温和，alignment tax 小一些，可解释性债务也轻一些；但这些问题的方向是一样的。换句话说，"我们做的只是 LoRA / SFT，不是从头训"不能成为绕开这 5 条论证的免责声明——它只能让你少踩一些坑，不能让你免踩。

所以辩论的下半场核心问题是 4 个追问——它们是任何一家航空航天 / 制造企业在 Q1 决策"今年到底还要不要继续微调"时必须直面的：

追问 1：微调的目的到底是什么？追问 2：值不值？追问 3：开源模型 + 行业知识库 + 工具调用 + Agent + Skills 的组合，能不能就够满足要求？追问 4：费心训了半天，就算某项能力满足要求了，其他能力会不会变弱智？

把上半场 6 位顶级专家的论证 + 下半场即将出场的辩论另一边的论证，全部用这 4 个追问的尺子过一遍，每一问的答案都不令人舒服。

追问 1：微调的目的到底是什么？

业界对"什么时候微调有正向价值"有一个相对成熟的拆解——5 类目的，每一类在航空航天微调场景下都需要打个问号：

5 类放在一起看，在"还没确认基础模型 + Agent + Skills 能力边界"的阶段，几乎找不到一个非微调不可的目的。文章开头那家火箭制造商在 2025 H2 投入的微调项目，如果回到立项时把目的逐项拆开问"为什么不用 RAG / 不用 Agent / 不用 Skills"——大概率没有一条扛得住盘问。

追问 2：值不值？

用 5 年 TCO 的视角对比两条路径：

路径 A 比路径 B 贵 2-3 倍，且产出更易折旧、更难审计。 不是"值不值"——是"为什么要选贵的还差的那条"。

追问 3：开源模型 + 知识 + 工具 + agent + skill 能不能就够满足？

这是 4 个追问中最关键的一个——也是绝大多数"微调项目"立项时被刻意回避的一个。

正确的回答顺序不是先问"我们能不能做出一个微调模型"，而是先问"通用基础模型 + 完整的工具链 + 完整的 Agent 编排 + 完整的领域 Skills + 完整的 RAG 知识库 + 完整的人类决策节点 这一整套组合，对我们这个具体业务场景，到底能做到多好？"

而这个问题在 99% 的项目里没有被认真回答过。原因很简单——回答它需要先把"完整的工具链 + Agent 编排 + 领域 Skills + RAG 知识库 + 评估体系"建起来，工作量远大于"立个项跑微调"。所以项目通常直接跳过这一步，去做"看起来更主动、更有里子"的微调。

但这一跳过本身就否决了微调的合理性——你都没有验证过通用模型组合达不到要求，你怎么证明微调是必要的？

工业代码补全领域 ACM FSE 2025 的硬核研究给出过精确数字：当训练数据规模超过 90K 文件后，fine-tuning 的边际收益急剧下降到 0.35%；而 RAG 在同一个 scale 上仍然有 2.26% 的持续收益。这意味着在大规模领域数据上，RAG 的可扩展性结构性优于 fine-tuning。 航空航天企业的设计文档、试验数据、维修工单的规模，远超 90K 文件这个临界点——把它们建成高质量 RAG 知识库 + 工具调用接口的 ROI，远高于把它们训进权重。

回到那家火箭制造商：如果你把过去一年那笔训练投入，全部投在 RAG 知识库 + 工具调用接口 + Agent 编排 + 评估体系 + 工程师培训 上——你今天看到的 AI 价值会比微调出来的"效果不置可否的模型"高一个数量级。

追问 4：费心训了半天，其他能力会不会变弱智？

会。而且通常你看不到。

这就是 John Schulman 反复警告的 alignment tax——任何形式的后训练（continued pretraining / SFT / RLHF / DPO）都会以某种方式损害基础模型在训练分布之外的能力。具体表现：

• 在你训的目标任务上，模型确实变好了（这是你 PPT 上能展示的部分）
• 但在通用推理、创造性问题求解、长链推理、罕见情境处理上，模型出现了能力衰减
• 这个衰减你的 benchmark 看不出来，因为你的 eval 集恰好不覆盖那些衰减的维度
• 在真实使用中会撞上——但他们撞上时通常不会归因于"模型被微调过"，会归因于"模型不行"

放到航空研制这种跨学科、长链推理的场景下尤其致命——你需要从材料、热力学、控制理论、人因工程、维修性、典型工程案例等多个看似不相关的领域抽取信息并综合。基础模型好用恰恰因为它的"知识图谱"非常宽。后训练做得好，宽度被局部加深；做得差，宽度被切碎。

而且——评估这种"被切碎"本身就是一项前沿研究能力。Anthropic 和 OpenAI 投入了远超外界想象的资源在"如何在后训练中保住基础能力"上，你不具备这个能力，意味着即使微调出问题也发现不了。

回到那家火箭制造商：2025 微调出的模型——在没有训过的那些场景上，它现在比通用基座弱多少？你测过吗？测得出来吗？测不出来，是因为没问题，还是因为你没有能力测出问题？

四个追问问完，下半场辩论的基调就定下来了——支持微调一方需要解决的不是"我们能不能做出来"，是"我们做这件事的目的、性价比、不可替代性、副作用风险，是不是都站得住脚"。下面看支持方怎么回答。

顺便堵一个常见退路：「小尺寸 / 低精度」不改变结论

在董事会上经常听到的一种缓兵之计是 ——「我们不做大模型微调，我们只做'小尺寸 + 低精度'的轻量微调，门槛低、投入少、风险可控」。这话听起来温和，但在技术上几乎没有降低任何核心难度。逐条拆开：

• "小尺寸"（7B-13B 量级）的能力天花板被基座决定。拿 7B 开源底座做领域微调，训出来的能力上限是 7B 基座的能力上限。而 2026 年这个时间点，7B 级别开源基座（Qwen3-7B / Llama-4-8B 这一类）在通用推理、复杂工程问题求解上，和 Claude Opus 4.7 / GPT-5 之间还有显著差距。微调之后得到的是"在航空格式上对齐得很好但通用推理仍然差一截的小模型"——工程师真正需要它的时候（分析复杂耦合气动弹性、综合多份典型工程案例做权衡），还是不如直接调最强 API。

• "低精度"（W4A8 / INT4 量化）是部署优化技术，不是训练替代。量化是把训好的权重从 FP16 / BF16 压到 INT4 / INT8 以减少推理显存和提升吞吐——它是后处理，不会让你"训出"一个新模型。把"训自有模型"和"低精度推理"混在一起讨论，在术语上就是错的。

• 如果你的真实意思是"用低精度训练（QLoRA 一类）来降低训练门槛"——那这是 PEFT（parameter-efficient fine-tuning）的范畴，工程门槛确实低（单机几张卡就能跑），但 PEFT 训出来的本质是给基座加一个小 adapter，它的能力增益就是上面说的那些有限的格式对齐、风格对齐，不会让基座产生根本性能力提升。把 PEFT 产物包装成"行业大模型"，会严重高估它的实际价值。

结论：「小尺寸 / 低精度 / PEFT」是工程上更便宜的方案，不是论证上更安全的方案。前面 6 位顶级专家的 AI 分身关于 alignment tax、可解释性债务、折旧、负向迁移、评估能力缺失的论证——对小尺寸 + LoRA / PEFT 全部成立，只是数量级不同。"我们做的只是 LoRA"不能让你绕过这些论证。

五、辩论的另一边：什么时候自训"真的"有意义？

主张"应该自训"的论证可以分成三条独立支线，分别由成功案例研究员、数据主权专家、CEO 提出。我们逐条审视。

5.1-5.3 三条"应该自训"支线 —— 一句话概括 ，下篇展开

主张"应该自训"的三条支线，论证强度都没有强到足以推翻上半场 6 位专家的判决。本上篇专注"减配版微调到底值不值"这一个核心问题，这三条支线的详尽展开放在下篇"如何用 AI"里：

支线 ① — 成功案例研究员说"应该做'航天 Prithvi'式的多模态领域底座"，核心案例是 NASA-IBM 的 Prithvi-EO-2.0（600M 参数地理空间基础模型）。但这是另一个独立命题 —— Prithvi 是 vision encoder（视觉模型），不是用自己数据微调一个 LLM 减配版；且其 80% 红利来自政府 + 学术 + 算力三方联盟（NASA + IBM + Jülich），民营 OEM 单干路径不存在。"多模态领域底座"是另一个轴，下篇展开。

支线 ② — 数据主权专家说"高密级 / 高敏感工程数据场景下，必须把模型权重控制在企业 boundary 内"——这部分是真的；但"必须 boundary 内"和"必须自己微调一个减配版"差三个数量级，Scale AI 的 Donovan（开源 LLaMA 3 底座 + 内网 SFT + DoD eval）就是教科书反例：boundary 内 ≠ 自己 from-scratch ≠ 必须微调。"密级 boundary 内 RAG + 受控 LoRA"也是下篇话题。

支线 ③ — CEO说"自训能力 = 可分拆估值资产 + AI 主权 multiple premium"——但 multiple premium 在公开市场无任何上市公司可验证（Boeing GenAI Academy 没让 BA 股价摆脱已有运营负担，Lockheed 股价由主力产品驱动不是 AI 叙事）；分拆 IPO 路径在防务 AI 领域 N=0。这条线本质是商业叙事，不是技术决策——本文不展开。

三条支线共同的元结论：它们要么不是本文命题（支线 ①/②），要么没有公开实证支撑（支线 ③）。接下来的论证（5.4-5.7）将真正围绕"减配版微调值不值"这个核心命题展开。

5.4 全行业头部 OEM 的真实选择

辩论双方的论证看完了。现在看一组没有在直接辩论但分量最重的证据——全行业头部 OEM 在 2025-2026 年实际选择了什么路线。

这张表的真正信号：放眼 2025-2026 年，没有任何一家头部航空航天 OEM 公开宣布过用自己数据微调出一个"航空大模型 / 行业大模型"。所有公开案例要么是通用 API + RAG + Agent（Boeing/Airbus/Lockheed 内部生产力工具栈），要么是分布外多模态领域底座（NASA Prithvi 是 vision encoder 不是 LLM），要么是任务数据闭环 + 应用集成（Anduril Maven）。没有一家把"微调一个文本基础大模型"当成战略叙事来做。

而 SpaceX 这一行是整张表里分量最重的反证——它直接把"为什么不做'航天大模型'"这件事的论证强度提到了天花板：

• 要做"航天大模型"，需要的三个要素是什么？答案是——（1）一家有顶级 LLM 训练能力的 AI 公司，（2）一家有最独家航天工程数据的航天 OEM，（3）能拉通这两家、统一战略意志的决策者。
• 过去 30 年的全球航天工业里，唯一一家同时具备这三个要素的，就是 Musk 体系——xAI（Grok 5 是 2026 年前沿基座之一）+ SpaceX（Falcon 9 / Starship / Starlink 是全球最完整的航天数据闭环）+ Musk 本人（一个人同时是 xAI CEO 和 SpaceX CEO，调度上不存在任何组织摩擦）。
• 如果"用航天数据微调出一个航天大模型"在工程上、商业上、战略上是一件值得做的事——SpaceX + xAI 是全球唯一一家在做且必然在做的玩家。
• 但 2026 年这个节点，公开信息里没有任何'SpaceX 用自家数据微调 Grok 做航天大模型'的项目存在。Musk 在 4.1 节那段第一性原理论述（"你要的是拥有模型，还是让 AI 创造价值？"）不是嘴上说说——他自己的两家公司就在按这个判断执行：SpaceX 把稀缺资源全部投在 RAG / Agent / 工具链 / 工程系统集成上，把 LLM 能力交给 xAI 在前沿基座层面统一推进。这是工程理性的最干净示范。

放在一起看，这种"全行业的沉默 + 最有能力做的人偏偏不做"，在情报学里叫最强一致性证据（strongest converging evidence）——比任何单一公司的反例都强。Northrop AI 首席架构师 Dadson 那句"AI 不能像 garnish 一样撒在上面"是把行业内严肃的判断说穿了：AI 应该是子系统 / 组件，不是叙事；要的是被 operationalized 进研制流程，不是被打包成"我们也有大模型"的董事会 PPT。

4 个真正落地的案例—— 深扒下来的反向启示

这 4 个案例放在一起看的真正信号，恰好是对"自训行业大模型"叙事的反向论证——它们每一个都"真正落地、真正产生了价值、真正被工程团队和军方/医疗机构使用"，但没有一个是"用独家文本数据自训一个领域大语言模型"那条路：

① NASA-IBM Prithvi-EO-2.0：落地路径是"政府数据方（NASA）+ IBM 算法方 + 德国 Jülich 算力方"三方联盟做的 600M 参数地理空间 vision encoder——注意：是视觉模型（vision encoder），不是 LLM。它解决的是卫星栅格图像处理这种通用模型预训练分布外的真稀缺模态问题——和"用我们的工程文档自训一个航空大语言模型"是两件完全不同的事。落地的前提条件极其苛刻——数据 + 算法 + 算力三方联盟，不是任何单一企业能凑齐的。对航空航天 OEM 的启示：如果你真的有"卫星图像 / SAR / CFD / 风洞"这种分布外多模态数据，正确路径是组建联盟做 vision encoder，不是包装成"我们的航天大模型"去训文本 LLM。

② Med-PaLM 2 → Med-Gemini： 4.3 节 Jensen Huang 视角已深扒——Google 顶级研究团队 + 独家医学数据访问权限 + 任意算力做出来的 Med-PaLM 2，优势窗口期只有 18 个月就被 GPT-4 + Medprompt 提示工程方案追平，Google 自己也直接放弃 PaLM 2 改在新一代 Gemini 基座上重做（Med-Gemini，MedQA 91.1%，比 Med-PaLM 2 高 4.6%）。对航空航天 OEM 的启示：垂直微调出的"医疗大模型"被通用基座反超只用了 18 个月——你的"航空大模型"凭什么撑得更久？

③ Lockheed Martin Astris AI：2024-12 成立的 Lockheed 子公司，2025 年通过 Genesis 平台构建了 16,000+ AI Agents，75,000 员工使用 Navigator secure chat。但 Astris 本质是 MLOps 平台 + Agent 工厂 + 安全聊天工具，不是基座模型——它做的是"用通用基础模型 + 任务编排 + 工具集成 + 工程系统集成"，不是"用 Lockheed 内部国防数据训出一个国防行业大模型"。这恰恰是黄仁勋的"build on top, not from scratch"在全球最大防务承包商身上的工业实证。对航空航天 OEM 的启示：你应该建的是 Astris 那种"Agent 工厂 + 工具链平台"，不是"行业大模型"。

④ Anduril + Palantir Maven Smart System：Maven 合同上限已提至 13 亿美金（覆盖至 2029），集成 LLM 后目标识别速率达到 5,000 targets/day，2026-09 成为美军正式 program of record。但 Maven 做的是 "任务数据闭环 + 集成式 LLM + Agent 工具调用 + 实时态势感知"——它是把通用 LLM 嵌入到一套真实的军事任务流程里，不是 from-scratch 训一个"军事行业大模型"。Maven 的 13 亿美金合同没有花在"训自己的国防 LLM"，而是花在"如何把通用 LLM + 多源传感器 + 任务系统拉通成一个能在真实战场上用的 Agent 闭环"。对航空航天 OEM 的启示：把钱花在"任务数据闭环 + 工具集成 + Agent 编排"，比花在"自训权重"高 1-2 个数量级 ROI。

4 个案例的共同特征：每一个都是特化的非 LLM 自训路径——多模态 vision encoder（Prithvi）、垂直微调被通用模型追平的负面教材（Med-PaLM 2）、Agent 工厂 + MLOps 平台（Astris）、任务闭环 + 集成式 LLM（Maven）。没有一个是"用独家文本数据自训一个'XX 行业大语言模型'"那条叙事。

深扒下来的最锋利结论：摘要承诺"深扒 4 个落地案例"，深扒之后的真正发现是——真正落地、真正创造价值、真正被严肃工程组织采用的 AI 路径，从来不是被宣传成"我们的行业大模型"的那条。这条结论比 BloombergGPT/IBM Watson/Babylon Health 三个失败案例的反向论证更狠——失败案例只能告诉你"什么是错的"，而 4 个落地案例同时告诉你"什么才是真的对的"。

5.5 「行业大模型」的自我标签陷阱

在结束辩论之前必须单独讲一个陷阱——它没有出现在任何一个 R1 角色的发言里，但它是商用飞机、大型运载火箭、能源、钢铁这种"一国一头部"赛道里最容易让人入坑的认知陷阱。

陷阱的形式：当一家企业在自己国家 / 地区是该领域唯一或极少数的头部企业时（任何国家的商用大客机研制单位、运载火箭主承包商、卫星总体所），它会天然认为：「我用我自己的数据微调出来的模型，对外口径上就可以叫'XX 行业大模型'。因为放眼整个国家就我们这一家在做这件事——我是行业，我训出来的就是行业的。」

为什么这是陷阱：

第一，"行业大模型"在大模型语境下是一个有特定含义的术语——它指那种在该行业的客观 benchmark 上、在多家从业方都认可的评估上、显著超过通用基础模型的模型。BloombergGPT 没做到，所以它没成为"金融大模型"，只成了"Bloomberg 自己用过一次的尝试"。Med-PaLM 2 严格意义上做到了一年（USMLE 86.5% 首次过及格线），但 18 个月后就被 GPT-4 + Medprompt 追平、被 Med-Gemini 反超——它是不是"医疗大模型"现在已经不再有人争论。

把"我训出来的"等同于"行业的"，是混淆了主体身份（我是行业代表）和模型属性（模型在该行业表现卓越）这两件完全不同的事。前者是市场地位，后者是技术性能——一国一头部企业容易拿前者推出后者，但这个推论在技术上不成立。

第二，这个陷阱有非常强的内部叙事强化效应：

• 项目立项时，"我们要做行业大模型"比"我们要做内部 RAG 系统"更容易拿到预算
• 项目执行时，"行业大模型"的口径让团队不敢承认"其实通用模型 + Agent 已经够用"，因为承认就是项目失败
• 项目交付时，由于本国本地区没有第二家可比对照，团队自己 benchmark 自己 = 没有外部验证——评估能力本身就被 owner 把住了
• 即使最终模型并不比通用模型 + RAG 强，由于"我们就是行业、模型就是我们做的"，对外口径仍然成立——自我标签的循环就这样闭合了

第三，这种陷阱在客观技术验证下立刻露馅：把同一组航空航天专业问题（行业核心工程标准解读、SysML v2 语法生成、维修工单结构化、典型故障诊断思路、试验报告抽取……）同时丢给「自训的行业大模型」和「最强通用基础模型 + 你自己组织好的 RAG 检索 + Agent 工具调用」对比——绝大多数情况下后者赢，且差距还在持续拉大。行业第三方 benchmark 体系出现的本质意义就是把这种自我标签的封闭循环打开——有了客观尺子，"行业大模型"就不再是 PR 用语，是技术指标。

第四，目的之问无法回避——"我们到底是为了什么训这个模型？"

• 如果是为了内部生产力：通用 API + RAG + Agent + 工程系统集成是更高 ROI 的路径
• 如果是为了密级 / 高敏感数据 boundary 内的部署：boundary 内的开源底座 + 窄任务 SFT 是务实路径，且不需要"行业大模型"叙事
• 如果是为了真正的多模态科学突破：那做的是 Prithvi 那种 vision encoder，不是文本 LLM——这种东西甚至不该叫"航空大模型"
• 如果是为了对外宣传 + 战略叙事 + 拿政府订单：那这是公关问题，不是技术问题——而把公关问题包装成技术项目去烧 5000 万美金，是航空航天这种工程严肃行业最不该犯的一类错误

这第四点是辩论里没人愿意明说但却最准的一刀：很多"行业大模型"项目的真实驱动力，不是工程价值，是组织叙事 + 个人 KPI + 战略包装。承认这一点不丢人——但不承认才是真正的风险。

6 位 AI 顶级专家的 AI 分身的论证（第一性原理 / 数据决定上限 / 折旧周期 / Alignment Tax / 可解释性债务）放在"行业大模型"陷阱面前，整体效果是：即使把"我们就是行业"这个身份溢价考虑进来，技术上、经济上、合规上自训仍然是负 ROI。一国一头部的市场地位救不了一个被通用模型 + Agent 持续超越的内部尝试。

5.6 你的对手不是 GPT-4，是「GPT-5 + Agent 集群 + 工具调用 + 写代码」

讨论"自训的行业大模型 vs 通用大模型"时，绝大多数人脑子里想的对照基线是错的。

错误的对照基线：「我自己微调的 70B 行业模型 vs 别人家的 GPT-4 通用模型」

正确的对照基线：「我自己微调的 70B 行业模型 vs（最强通用基础模型 + 整套 Agent 集群 + 我自己的工程工具调用 + 高质量 RAG 检索 + 写代码能力 + 人类专家最终决策节点）」

后者每一项都在持续加速，而你的微调模型一旦冻结就开始贬值。我们一项一项看：

关键结论：你不是在和一个静态的通用模型比，你是在和一个加速进化的通用模型 + Agent 集群 + 工具调用生态比。这场比赛结构性不可赢——因为对方的边际投入是几十家世界顶尖 AI 公司分摊的，而你的边际投入是你一家公司扛的。

放到一个最简单的折旧曲线上看：

• 你今天投 5000 万美金做出"行业大模型 v1.0"——12 个月后通用模型迭代一次，你的 v1.0 在大部分任务上打不过对方
• 你为了不被反超，投 3000 万美金做 v2.0——12 个月后再被反超
• 5 年下来你烧了 1.5-2 亿美金，每一代版本的"领先时间窗"都在缩短
• 而那 1.5-2 亿美金如果投在 RAG / Agent / 工具集成 / 工程师培训 / 评估体系建设上——这些资产是不会被通用模型代际反超的，因为它们恰好是通用模型不会替你做的事

这才是辩论里被低估最严重的一条算账逻辑——自训的所有投入都被"对方持续进化"折旧；非自训的所有投入都在你的工程系统里沉淀。

5.7 三个能力短板：训练已经不是难点了，难的在别处

很多支持自训的论证有一个共同的隐含假设——"我们公司是有能力做好这件事的，只要预算够、算力够、人够"。但 2026 年的真实工程现实是：训练这个动作本身已经不是难点了——HuggingFace、LLaMA-Factory、Axolotl 这些框架已经把训练变成了配置文件级别的操作。任何一家有十几个 ML 工程师的企业，都能在几周内跑通一个 LoRA / SFT 的 pipeline。

真正决定"训得好不好"的是另外三个能力——而这三个能力航空航天企业普遍缺位：

短板 1 — 评估能力，而不是训练能力

你训出来一个微调模型之后，如何判断它到底好了还是坏了，在哪些维度上好了，在哪些维度上偷偷坏了？ 要回答这个，需要建一套领域 eval 体系——这本身就是前沿研究工作。Anthropic 和 OpenAI 内部为此有专门的 alignment science 团队、数百人规模的标注团队、跨数十个领域的 eval 集、持续运行的 regression testing 基础设施。复刻这套基础设施的 1/10，投入就已经超过训练本身。

更深的一层：在工程严肃性这种最终标准下，"如何评估一个模型够好了"本身就是开放问题。你拿什么 ground truth？历史决策？那是你自己反驳过的"妥协数据"。Nastran/Patran 计算结果？那不需要 LLM。资深工程师判断？那这些人的时间是企业最稀缺的资源。评估能力缺失的真实后果是——即使你训出了一个模型，也没法可靠判断它该不该用、用在哪里、用到什么程度。这比"训不出来"更糟——是"训出来一个用起来不放心的东西"。

短板 2 — 数据工程能力，而不是数据本身

"我们有 30 年数据"和"我们有能用来训模型的数据"之间，隔着一支数据工程团队 6-12 个月的全职工作量。

预训练 / 微调需要的不是原始数据库，而是经过 去重、清洗、格式标准化、质量评分、安全过滤、prompt-completion 对构造、多样性平衡 的训练语料。OpenAI 训 GPT-4 前数据团队就已经是百人级。

航空航天企业把现有 MBSE 数据、试验报告、设计文档、质量管理体系文件转成可用语料的难点很具体：文档格式异构（PDF 扫描件、Word 嵌入式公式、CAD 设计文件、Nastran 输入卡、各种内部格式）；涉密分级标注（哪些可以进训练集、哪些不能——是组织流程问题，在大型企业是慢动作）；质量评分（谁来判断哪份是高质量训练数据——又回到短板 1）；多样性（数据高度集中在少数型号，直接训会严重过拟合到这些型号特定决策路径）。

更刺手的是：做完这一切之后，你得到的训练语料从 tokens 数量上看，很可能不足以支撑一次有效的 continued pretraining——领域语料如果只有几百 M 到几 G tokens，在和基座原始语料数十 T tokens 的对比下，影响极其稀薄，训出来的模型和原始基座的差异可能小到 eval 不出来。

短板 3 — 工程迭代速度，而不是单次训练

一个有用的领域模型不是训一次的事，是持续迭代的工程。前沿基座 6-9 个月一代，你的领域模型要保持相对优势，每一代基座更新都要重新做一遍 continued pretraining + SFT + eval。

头部 AI 公司能跟上这个节奏，是因为训练-评估-部署 pipeline 是高度自动化、内部代码沉淀深、团队全职 on-call 的。航空航天企业作为以"型号研制周期"为基本时间尺度的组织，节奏是按年甚至按数年算的——一个项目从立项到出成果，在大型 OEM 内部很难走得比 12-18 个月更快。

这意味着：即使你做出领域模型 v1，等 v2 迭代出来，前沿基座可能已经走过 2-3 代，v1 相对最新基座的优势已经不存在了。这是组织节奏 vs 技术迭代节奏的根本错配——不是给研究中心多招几个人能解决的。把一家航空航天企业改造成能按 6 个月节奏迭代 AI 模型的组织，本身比训模型这件事难得多。

三个短板放在一起，得到的真实判决是非常硬的：

航空航天企业有能力训出一个"看起来像那么回事"的领域模型；但没有能力训出一个"真正比直接用前沿 API + RAG + Agent 更好用"的领域模型。这两者的差别，在没有严肃 eval 的情况下从外面看不出来，从 demo 里也看不出来——只在真实工程使用半年之后才会显现。而到那时，投入已经沉没。

这恰好解释了文章开头那家火箭制造商在 2025 年下半年微调结束、年终汇报时的"叙事 vs 现实张力"——大家都说"取得阶段性成果"，但工程师都心里有数"真的好用吗？"。叙事在 demo 阶段是稳的，现实要到使用半年后才显形。这是 2026 决策"是否继续"时必须直面的真相。

六、95/5 法则：为什么"该不该微调"有清楚的答案

把上面的辩论汇总，对"用自己数据 post-training / SFT / CPT 一个基础模型的减配版本，到底值不值得"这个核心命题，给出最直接的答案：

2026 年这个时间节点，95% 以上的航空航天企业不该继续微调，5% 的特定企业必须微调——但 5% 内的"微调"几乎从来不是"对外宣称的'行业大模型'"那种叙事，而是"合规约束下被迫做的 boundary 内窄任务 SFT"或"分布外模态领域底座"——而这两条路径属于另一个话题，不在本上篇范围。

95% 的归宿是哪里？

通用 API（Claude 4.7 / GPT o-series / Gemini 3 / DeepSeek-V4-Pro）+ 高质量 RAG 知识库 + Agent 编排 + 工具调用接口 + Skills 封装 + 工程师培训 + 评估体系。Boeing 的 GenAI Academy（8000 人 / 2,600 super users）+ Lockheed 的 Genesis 平台（16,000+ Agents）+ Airbus Skywise（数据平台 + 140+ 航空公司）—— 这就是头部行业玩家在 2025-2026 实际选的路。

5% 的"必须微调"在哪里？

两条窄通道：① 出口管制 / 密级数据触发的 boundary 内必需场景（如 Scale AI Donovan 模式：开源 LLaMA 3 + 内网 SFT + DoD 评测）；② 分布外多模态科学数据的领域底座（如 NASA-IBM Prithvi-EO-2.0 这种 vision encoder）。这两条都属于"另一个话题"——下篇会展开"如果你是那 5%，正确的工程量级和路径应该是什么"。

注意：完整的 2x2 决策矩阵（数据敏感度 × 任务复杂度的 6 格映射）和分支决策树（5 个 yes/no 节点）放在下篇——本上篇专注回答"值不值得继续微调"这一个问题。

七、反共识结论：95/5 法则——你不属于那 5%

辩论走完了。让我们把结论摆出来。

反共识不在"应该 / 不应该自训"这个二元答案上。反共识在四层更深的地方：

第一层反共识：反"我有独家数据所以我应该自训"

BloombergGPT 已经替全行业交了 1000 万美金的学费——独家不等于稀缺，稀缺不等于该自训。彭博的金融语料数据质量、规模、标注一致性，几乎全面好于一家航空航天 OEM 能动用的研制语料（金融数据有结构化、有客观市场反馈、有时间序列 ground truth；航空航天工程 MBSE 数据连"对错"的客观标准都没有）。Bloomberg 都没赢，你赢的概率只会更低。

第二层反共识：反"通用模型有专业盲区所以我应该自训"

通用 LLM 在被询问 Boeing 787 钛合金紧固件表面处理时同时违反 3 项行业核心工程标准——这是真实发生过的案例。但它的解药是 RAG + 行业第三方 benchmark eval 闸门，不是把数据训进权重。原因前面 Olah 视角已经说穿了：权重是黑盒，检索层是白盒，工程师评估 AI 输出可信度时后者天然占优。

第三层反共识：反"全行业都在做所以我应该跟上"

全行业头部都没在做。 Boeing / Airbus / Lockheed / Northrop 在 2025-2026 都没有公开宣布过用自己数据微调出"航空基座大模型"或"行业大模型"。Boeing Space Mission Systems 的"自建模型"案例是 COTS 硬件 + 卫星遥测自然语言报告——部署侧的工程创新，不是模型能力侧的研究。Lockheed Astris AI 是 MLOps 平台 + Agent 工厂，不是行业大模型。

第四层反共识：反"我是行业 = 我训出的就是行业大模型"

这是商用飞机、大型运载火箭、能源、钢铁这种"一国一头部"赛道里最危险的认知错位——把"主体身份是行业代表"等同于"我训出的模型就是行业大模型"。前者是市场地位，后者是技术性能；前者是 PR 用语，后者是 benchmark 数字。两者在大模型语境下没有任何逻辑关系。

BloombergGPT 也是金融行业的代表性公司之一，它训出的 50B 模型没有成为"金融大模型"。Med-PaLM 2 是 Google 这种顶级研究机构 + 顶级医学合作伙伴的产物，它做了 18 个月的"医疗大模型"，然后被 GPT-4 + Medprompt 追平、被 Med-Gemini 超越。

一国一头部企业的市场地位救不了一个被通用模型 + Agent 持续超越的内部尝试。 把"我们是行业"推论出"我们的模型就是行业的"，是把组织叙事当成了技术真理——而航空航天这种工程严肃行业最不该犯的就是这类错误。

辩论走到这里，结论已经摆在台面上。

2026 年这个时间节点，95% 以上的航空航天企业不应用自己的数据微调出一个所谓的"行业大模型 / 企业大模型"。剩余 5% 例外的"应该自训"场景，正确的工程量级是 boundary 内的 LoRA / 窄任务 SFT / 受控的 continued pretraining，几乎从来不是"对外宣称是行业大模型"那种叙事；唯一存在的 from-scratch 合法窗口（分布外多模态科学数据），24-36 个月内也会被通用多模态模型部分吞噬。

那 5% 是哪 5%？两条窄通道：

通道 A：高密级数据 boundary 必需通道——你的训练语料触及高密级 / 高敏感工程数据 + 数据规模 ≥10B tokens + 公司有持续 ≥3 年的专门 AI MLOps 预算（年 ≥$20M）。即便如此，正确量级是"开源底座 + boundary 内 continued pretraining + LoRA per 机型"，不是 from-scratch。Scale AI 的 Donovan 路线是教科书答案。

满足这一通道的企业全球可能不超过 20 家：Lockheed / Northrop / RTX / Boeing Defense / 部分国家级航天工业集团 + 个别国家级研究机构。

通道 B：分布外模态通道——你做的不是"航空大语言模型"，是"卫星图像 / SAR / CFD / 风洞 / B-rep" 这种通用模型预训练分布外的多模态领域底座，且能找到"数据方 + 算法方 + 算力方"三方联盟（如 NASA + IBM + Jülich 模板）。即便如此，两条预警：（1）真实部署的 Prithvi-EO-2.0 是 600M 参数（BERT-large 量级），不是 50B+ 大模型——不要被"航天 AlphaFold"叙事误导成"必须做大模型"；（2）通用多模态模型每 12-18 个月吃掉一块模态护城河，这条护城河的有效期可能比 36 个月还短。

如果你既不在通道 A，也不在通道 B——你不属于那 5%。

八、关于"模型供应链自主性"的精确表达

这是辩论里被讨论得最不充分、却对很多企业（尤其是有战略产业 / 国家级订单背景的航空航天企业）最重要的一个角度。

错误表达："模型供应链自主 = 能从头训一个基座 / 必须自己微调一个版本"正确表达："模型供应链自主 = 在主用前沿模型不可用时有一个够用的本地开源基座作为 fallback，并且 Agent 栈、工具栈、领域适配栈能无缝切换底座"

这两件事的工程含义完全不同：

• 前者要求企业自己持续做 continued pretraining + 完整后训练管线 —— 代价巨大、收益可疑、被代际碾压、可解释性债务高
• 后者只要求应用层架构具备底座无关性（model-agnostic），并维持对主流开源底座（如 LLaMA / Mistral / DeepSeek / Qwen 中至少一两家）的部署和评测能力

2026 年市场上已经有多家世界级开源底座（LLaMA、Mistral、DeepSeek-V4 等），各自适配不同的算力栈和合规辖区——你的"自主性底座"已经被开源生态替你准备好了。再去自己微调一遍它们之中任何一个，等于在它已经做过的事上再做一次，且做得通常不如人家好——还要承担 alignment tax + 可解释性债务的全部成本。

真正的战略储备是 model-agnostic agent 架构——同一套 Agent 栈可以同时挂载多个不同底座（前沿闭源 + 主流开源），定期跑标准 benchmark 做对照评测，真到 fallback 时切换底座即可。这和"投入精力探索能力边界"完全不冲突——它们是同一件事。

把"模型供应链自主"从"能不能训"重定向到"能不能切"，是过去三年全球企业 AI 应用圈最重要的认知升级之一。航空航天行业是相对滞后的少数几个行业。

九、一句话收尾

辩论走到这里。把所有维度——预训练理论、后训练工程、模型经济学、可解释性债务、合规边界、行业实践——叠在一起后，能给航空航天 CTO / CEO 带回会议室的最锋利一句话是：

用自己的数据训得再好，也超不过当初决定型号架构的那群工程师的水平。

这句话不是在贬低自训，是在精确定位它的边界：

• 你训的模型不会比你的数据上限更聪明；
• 你的数据上限不会比当年做出这些决策的工程师更聪明；
• 那群工程师的智慧不在数据里，在他们当年面对约束时做出权衡的那个时刻——而这个时刻不是任何后训练能复刻的。

正确的 AI 路径不是把那群工程师的"历史妥协"训进权重里，是把今天和明天那群工程师的"决策链条"用 AI 拉长——让一个资深工程师能同时驾驭十倍于过去的设计空间和验证强度，让一个初级工程师能在与 Agent 协作中加速成长为资深工程师。

不要试图自己造发动机，要造世界上最好用的飞机。

AI 基座是发动机，2026 年的市场上有 OpenAI / Anthropic / Google / DeepSeek 几家在替全人类造，谁造得好你买谁的，明年换一家更好的也行。真正属于你的飞机，是领域应用——是 RAG + Agent + 工具调用 + 工程系统集成 + 人类工程师决策节点 这一整套工程。这才是你的护城河，这才是你的下一个 30 年。

最后留下两句话给所有正面对"今年到底还要不要继续微调"决策点的航空航天企业 CTO / CEO：

航空航天企业的优势不在模型层，在系统集成层和领域知识层 —— 把全部精力压在优势上，远比花精力补短板更划算。

训了和没训之间的差别，在没有严肃 eval 的情况下从外面看不出来，从 demo 里也看不出来 —— 只在真实工程使用半年之后才会显现。而到那时，投入已经沉没。

记住这两句话——它们不是PPT上的修辞，是真实工程现实最锋利的两刃。

下篇预告

那么，剩下的 95% 的航空航天企业，应该怎么用 AI？

如果不再继续微调自己的大模型，那"最强基础模型 + Agent + 领域工具 + RAG + Skills + 人类决策节点"这一整套架构具体怎么搭？怎么和 PLM / MES / CAD / MBSE 系统集成？怎么把上千甚至上万名工程师培训起来？怎么把成果稳定落地到工程流程里？怎么算 ROI？已经投入的算力、人力、半成品微调模型，怎么转向不浪费？

还有那 5% 的"必须微调"企业——通道 A（合规必需）和通道 B（分布外多模态）的工程量级和正确路径，到底应该怎么走？2x2 决策矩阵（数据敏感度 × 任务复杂度的 6 格映射）和 5 步分支决策树，下篇一并给出。

下期见。

文末参考资料

本文所有数字、案例、引用可追溯。主要来源：

失败案例：BloombergGPT 论文（arxiv 2303.17564）、Wharton Ethan Mollick 公开评论；IBM Watson MDACC（多份公开复盘）；Babylon Health（路透社、英国 NHS 报告）。

成功案例：NASA-IBM Prithvi-EO-2.0（research.ibm.com / earthdata.nasa.gov / arxiv 2412.02732）；Med-PaLM 2 → Med-Gemini（cloud.google.com Health 系列发布）；Microsoft Medprompt 研究；Scale AI Donovan（scale.com/donovan/defense-llm）；Anduril + Palantir Maven Smart System（defensescoop.com / 福克斯防务）。

行业部署：Boeing Conversational AI / GenAI Academy（boeing.com / klover.ai）；Boeing Space Mission Systems AI Lab（spacenews.com）；Airbus + Palantir Skywise / Wayfinder（airbus.com / acubed.airbus.com）；Lockheed Martin Astris AI（news.lockheedmartin.com / astrisai.com / aerospaceamerica.aiaa.org）；Northrop Grumman AI Architect Dadson 公开发言（aviationweek.com）。

技术研究：ACM FSE 2025 工业代码补全 RAG vs Fine-tuning 对比；DeepSeek-V4 技术发布（deepseek.com 2026-04-24）；harness engineering 与 ontology 在 LLM 可信度评估上的应用（Anthropic Evals / OpenAI simple-evals / Inspect AI 公开文档）。

6 位 AI 专家观点综合自 Elon Musk / Andrej Karpathy / Ilya Sutskever / John Schulman / Jensen Huang / Chris Olah 的公开演讲、论文与采访。