从语义底座到可执行想定：本体为什么重新变热，以及它如何让模型写出可信的作战想定

从语义底座到可执行想定：本体为什么重新变热，以及它如何让模型写出可信的作战想定

一个越来越常见的场景：大模型生成了一份 AFSIM 想定，mission 跑通了，事件文件出来了，指标也算完了。客户现场突然有人问了一句——这型拦截弹凭什么能在 200 公里外被这部雷达稳定跟踪？全场沉默。

问题不在模型不够聪明。真正缺的是一套可判定的规范：什么东西存在、什么组合允许、哪个数字必须有出处。这套规范有个被反复误读的名字，叫本体。

2025 年前后，"本体"这个词突然密集出现在技术圈和企业软件发布会上。它不是新概念，也热过不止一次。这一轮有什么不同，它跟作战想定生成到底是什么关系，正是本文要接下来讲清楚的两件事。

---

一、本体是什么

本体（Ontology）借自哲学里关于"存在之为存在"的学问。1993 年 Gruber 给出的工程定义流传最广：本体是对一种概念化的显式规范；后来学界补上"形式化"与"共享"两个限定。

定义里最容易被跳过的一半，是"哪些组合不被允许"。很多人把本体理解成概念清单或分类树，那是术语表，不是本体。一个能工作的本体，分量在约束与公理：它不仅能描述"驱逐舰装备了相控阵雷达"，还能推出"因此具备中程区域防空能力"，并且能判定"给一艘没有数据链的舰分配协同交战任务"是不合法的。

工程讨论里大量的争执，源于把下面五层东西都叫"本体"：

层次	回答的问题	能否推理	军事领域的例子
术语表	有哪些词，怎么叫	否	装备型号与代号对照
分类法	谁是谁的上位	仅继承	平台 → 空中平台 → 固定翼
数据模式 schema	数据长什么样	否	‎platform_type 里能写 ‎sensor 块
‎本体 ontology	概念与关系的语义及约束	‎是	协同交战要求参与方具备数据链
知识图谱	具体事实是什么	部分	某舰装备某雷达、隶属某编队

图1.五层辨析

这张表最重要的是第三行和第四行的区别，它直接决定了本文后面的一切结论：AFSIM 的 SDL 是一套 schema，不是本体。

schema 告诉你在 platform_type 块里可以写一个 sensor 子块、里面可以有 maximum_range 这个键。它不会告诉你雷达的最大探测距离必须与天线孔径、发射功率、目标 RCS 自洽，也不会告诉你没有数据链的两个平台不能做协同目标分配。语法有界不等于语义正确——这正是大模型直接生成想定时最容易翻车的地方：它写出来的东西能跑通，然后在评审会上被一句追问问倒。

二、为什么它在 2025 年前后重新变热

先泼一盆冷水。这不是第一次热潮：2000 年代初的语义网浪潮、2012 年 Google 知识图谱带动的产业热情、2018 年前后金融与医疗的图谱建设高峰，都退过。退的原因如下：

失败原因	具体表现
建模成本压在人工上	中型领域本体要几个专家干半年
缺少杀手级应用	建完图谱，最大用途是给领导做关系图大屏
推理规模化困难	实验室跑得动，生产规模一上量就超时
与业务系统脱节	图谱是图谱，业务流程是业务流程

这一轮有四点不同，前两点是动机，后两点是成本。

其一，大模型落地真实地撞上了"没有语义层"这堵墙。 向量检索能召回语义相近的文本块，但不理解实体之间的关系，无法跨文档多跳推理，更回答不了"这批语料整体上在讲什么"这类全局问题。GraphRAG 一类方案是对症的，但它有个隐性缺陷：schema 多由模型自己从文本归纳，换一次提示词、换一次模型版本，抽出来的实体类型就不一样。问题于是绕回来了——需要一个预先定义、能约束抽取过程的稳定 schema。有引述 Gartner 2025 年数据的行业材料称，引入知识图谱后大模型回答准确率提升 54.2%（该数字出自厂商引用而非独立审计，不宜直接当结论）。学术界的表述更克制也更可信：2025 年一篇 LLM 驱动知识图谱构建的综述指出，工程实践多数落到混合路线——手工定义 4 到 8 个顶层实体类型，子类型与关系标签交给模型在边界内自由发现。

其二，Palantir 把这个词做成了生意。 2023 年 AIP 推出后，"Ontology"成为其技术叙事的核心，增长曲线也确实陡：营收从 2023 年的 22.3 亿美元升至 2025 年的 44.8 亿美元，净利润从 2.1 亿美元升至 16.3 亿美元；2025 年第二季度首次单季营收超 10 亿美元，美国商业业务同比增长 93%。它的落地方式是三层架构——语义层（对象、属性、链接）、动力层（实体间的动态过程）、动态决策层（规则、模型与模拟推演集成，并把结果写回业务系统）。

这里必须做一个澄清：Palantir 的 ontology 是产品概念，不是学术本体。它不要求 OWL、不做描述逻辑推理，本质是把"数据 + 对象 + 规则 + 动作 + 权限"打包成一个可运行的操作层。但对军事仿真而言，它有两条比"本体"这个词本身更值得借鉴：一是语义层必须绑定可执行动作，只能被查询而不能驱动流程的语义层会退化成词典；二是权限与治理是语义层的内置组件，不是外挂——这在高密级场景里是硬约束。

图2.语义层的位置

其三，大模型反过来把本体构建的成本打下来了。 这是与上轮热潮最本质的差异。过去瓶颈是"专家手工建模"，现在这条链被拆成"模型起草 + 专家审核"。近两年的一批工作已验证可行性：SPIRES 从自然语言生成候选公理、Ontogenia 用元认知提示边生成边自纠、CQbyCQ 把能力问题直接翻译成 OWL 合规 schema、NeOn-GPT 与 DRAGON-AI 做端到端提示驱动构建。方法论由此从"专家手工"转向"能力问题驱动 + 模型起草 + 专家在关键检查点审核"，人力投入大约能压一个量级。

其四，高后果场景对可信与可审计的刚性需求。 大模型在医疗、司法、作战决策这类领域最大的障碍不是不够聪明，而是无法保证不出错，且出错后无法解释。本体在这里提供的东西是 RAG 给不了的——形式化的验收器：模型输出转成逻辑形式，推理机查本体一致性，检出违例并自然语言化后回灌模型修正，迭代到通过。这个回路的价值不在"模型变准了"，而在"错误变成可被机器检出、可被文字解释、可被记录的东西"。Semantic Web Journal 2025 年的一项研究进一步指出，带公理的深度语义优于仅用图结构的检索：本体推理得到更精确的实体集合，直接贡献准确率。

四根支柱里，前两根是动机，后两根是成本。动机端与成本端同时成立，才是这一轮与上一轮的本质区别。

三、军事体系仿真：本体解决的是"可判定、可追溯、可复用"

体系仿真的瓶颈常被误解为算力。其实不是。并行计算、构造仿真、蒙特卡洛批量跑，十年前就不是主要障碍。真正的瓶颈在两头——想定的生产和结果的解释。

想定空间是高维稀疏的组合空间。以一个反介入/区域拒止场景下的巡航导弹集群突击为例，光是可枚举的维度就有：来袭弹群规模与批次间隔、弹道高度与地形跟随策略、突防方向组合、护航与干扰配置、预警体系的节点布置与开机策略、拦截弹类型与携载量、火力分配规则、交战距离门限、通信链路可用性、气象与电磁环境。每个维度取几个水平，组合数轻易上万。人工能覆盖的是其中几十个点，而且选点受经验和习惯牵引，系统性偏差不可避免。

这就是为什么"大样本实验设计"在这个领域迟迟做不起来——不是算法不支持，是想定这个"实验材料"的生产能力跟不上实验设计的需求。五个具体痛点如下：

痛点	现状	本体能给的	本体给不了的
想定生产效率	一版可用想定动辄数十小时	基线 + 结构化差异，变体生成变成填槽	作战创意本身
C2 与仿真互操作	需专职人员在两个系统间搬运信息	统一概念层，机器可转换	组织层面的数据烟囱
指标与想定脱钩	结论说不清由哪个参数导致	MOE→MOP→想定要素→事件字段的溯源链	指标本身的合理性
知识不可机读	参数躺在 PDF 和专家脑子里	参数库 + 条令规则形式化	来源可信度治理
跨平台重复建模	同一设想在各平台各写一遍	中立项表示 + 双向映射	抽象层级差异的信息损耗

第二个痛点的分量常被低估。北约 MSG-048 技术活动的经验记录得很直白：要让作战 C2 系统与仿真系统联动，必须在信息回路上额外放一个人，把 C2 的信息搬进仿真、再把仿真的态势搬回 C2；在大规模演习里，配备懂行的专职人员来做这件事成了一项主要开销。这个"人工翻译岗"，本质上就是语义层缺失的代价。

这里有一个重要的提醒：不要从零建模。 军事领域是少有的已有成熟语义标准的领域。JC3IEDM 定义了 C2 系统间交换信息的核心数据元素；MSDL（Military Scenario Definition Language）是 SISO 2008 年通过的想定初始化标准，其定位——创建一种独立于具体仿真器的军事想定格式，减少把同一个想定人工复制到多个仿真格式的成本与错误，这正是我们今天要做的事，二十年前就有人在做；C-BML 负责作战任务与报告的数字化交换；2014 年两者合并为 C2SIM，被北约采纳为 STANAG 4856，且本身就是本体驱动的，含三层结构：Core（Who/What/When/Where）、SMX（标准军事扩展）、LOX（陆上作战扩展，作为其他军种扩展的样板）。

"核心 + 标准扩展 + 领域扩展"这个三层范式是可以直接抄的。正确姿势是把 C2SIM 的 Core/SMX 作为中间层，向上接顶层本体，向下补两块它不覆盖、而想定生成最需要的东西：装备性能与传感器物理层、仿真器绑定层。切忌造一套大而全的"军事万能本体"。

落到具体增益，六项里有三项最关键：

1）语义锚定。 让模型直接写 SDL，它面对的是近乎自由的字符空间——关键字有限，但关键字内部的取值开放。本体把"写什么"改造成"填槽 + 选关系"：属性取值域来自装备参数库与物理包线，量纲被强制绑定，候选实体是可枚举的、有参数来源的那几十个型号。这里有个常被混淆的点：约束解码与本体约束不是一回事。约束解码保证输出是合法 JSON、字段齐全；本体保证这个 JSON 里"驱逐舰挂载反舰导弹"语义上成立、数量在携带能力内、与作战任务匹配。前者解决语法，后者解决语义。

2）中间表示。 这是本文最主张的一条工程原则：不要让模型直接吐 SDL，让它产出中间表示（Scenario IR），再由渲染器转成脚本。三个理由——文本无法结构化校验，实例图可以；同一 IR 可渲染到不同仿真目标，SDL 一生成就锁死在 AFSIM 上；想定的修改在 IR 层是"改了哪个实体的哪个属性"，可以做语义 diff，在文本层是"第 437 行变了"，人和机器都看不出语义。换句话说，AFSIM 想定文本是渲染产物，不是知识资产。把资产沉淀在文本层，等于把知识锁死在一个会演进的语法里。

3）指标溯源。 效能评估的链条本该是四段的：MOE（体系层任务达成度）→ MOP（系统层探测概率、拦截窗口、命中概率）→ 想定要素（装备型号、部署几何、规则参数）→ 事件输出字段（探测、发射、命中、毁伤事件流）。现实里这四段经常断开，结果是评估报告只能给结论、不能给解释。把指标定义成一类特殊实体、显式声明它依赖哪些 MOP、由哪些想定要素驱动、从哪些事件字段采集，四段就焊上了：任何一个 MOE 数值都能往下钻到"是因为这部雷达的首次发现距离太短"，再追到"想定里它的部署位置在山谷后面"。这是评估结论能被质疑而不倒的前提。

四、让模型产出 AFSIM 想定：分四层，别让它直接写脚本

AFSIM 由美空军研究实验室主导，2019 年起以开源形式发布，已有 275 个以上政府、行业与学术组织加入社区，支持从战术级到战役级、从水下到太空含电子战的多域建模。想定侧有三个结构特征，决定了它与本体天然契合：

1）声明式、片段式。 想定由纯文本 SDL 描述，靠 include 组织成文件树。想定不是程序，是配置——这一点是关键，因为配置可以被渲染，程序不能。

2）类型—实例二层。platform_type 定义类型模板（可继承），platform 定义具体实例并挂上位置、阵营、指挥链。这个结构与本体的术语层/断言层二分几乎一一对应。

3）组件可插拔。 一个平台的探测、武器、通信、运动、行为逻辑分别由 sensor、weapon、comm、mover、processor/script 等组件拼装。组件化正好对应本体里的能力组合关系。

三个特征共同决定了可行性，也共同决定了难点：语法有界好办、类型实例分离好办，但组件参数之间存在物理耦合、且大量参数有隐含默认值——这导致"生成出来能跑"不等于"跑出来的结论可信"。

图3.四层架构

四层架构的职责与常见坑如下：

层	职责	常见坑
资产层	领域本体、装备参数库、条令规则库、历史想定库、AFSIM 组件能力表（含版本标签）	参数来源混杂、无版本管理，后面全部失效
中间表示层	把作战意图实例化为 Scenario IR，每个节点带来源标注	IR 设计得比本体还复杂，喧宾夺主
校验层	三级校验（本体一致性／领域规则／目标可执行性）+ 违例修复回路	规则写成硬编码，无法随本体演进
渲染与回归层	IR→SDL 文件集；批量运行、事件回收、指标计算、失败诊断回灌	只跑一次就交差，没有回归基线

流程串起来是：作战意图（自然语言）+ 约束（可用装备、地理范围、时间窗）+ 指标需求 → 实例化 → 三级校验、违例自然语言化后回灌修复（≤N 轮）→ 人工闸门 → 渲染想定文件集 → 批量运行、事件回收、指标计算、异常样本回流。

设计上最重要的一个取舍：人工闸门放在 IR 层，而不是 SDL 层。放在 SDL 层，专家审的是语法；放在 IR 层，专家审的是语义。这也是本体在大模型时代被低估的一项价值——它不只是给机器用的，它是让人类保有最终否决权的界面。

图4.A2/AD 走查

下面用一个例子进行贯穿说明。

1）输入意图："红方以 24 枚巡航导弹分三批、间隔 8 分钟，从东南方向低空突防袭击蓝方某沿海要地；蓝方由两艘驱逐舰与一部地面预警雷达组成防空体系，配备中程与近程拦截弹；关注要地被突防比例与拦截弹消耗。"

2）实例化后得到一张 IR 图：批次节点（数量、发射时间、引用航路）、平台节点（型号、挂载数量与类型、传感器、数据链、位置）、指挥关系边、任务节点（防空任务与交战规则）、观测配置（采集哪些事件、绑定到哪些指标），每个节点带来源标注。

3）校验会挑出三类真实会遇到的问题：挂载冲突（一批 8 枚，但发射平台单架只能带 6 枚，硬违例，回灌修复为分两架或调整编成）；预警覆盖缺口（低空突防叠加地面雷达视距限制，拦截窗口不足以完成两次射击，软违例，提示专家是否增设前哨雷达或调整航路）；版本取值不合法（所选交战规则取值不在该版本允许枚举内，硬违例，按版本标签替换）。

4）渲染时，IR 节点与 SDL 产物一一对应：类型引用 → 类型库中的类型定义块；平台实例及其位置、挂载 → 平台库中的实例块；指挥关系边 → 平台上的指挥链声明；任务与交战规则 → 行为逻辑块或脚本变量；观测配置 → event_output / csv_event_output 输出配置项；时间窗 → 起止时间声明。

值得注意的是，整个过程中模型一次都没有"写 SDL"。它做的是实例化与填空，脚本由渲染器产出。

几个关键工程决策的取舍：

决策点	选项	建议与理由
直出 SDL vs 出 IR	直出／IR 中转	‎IR 中转。直出是短期演示的捷径、长期工程的技术债
本体自建 vs 复用	全自建／全复用 C2SIM／混合	‎混合。核心层复用 C2SIM Core+SMX，领域层与仿真绑定层自建
人在回路位置	审最终文本／审 IR／只审意图	‎三道闸门：意图确认 → IR 确认 → 运行前确认，早拦截最便宜
知识注入方式	微调／RAG／两者	‎RAG 优先，谨慎微调。装备知识更新频繁，且 RAG 天然带来源标注

五、三条冷静的判断

第一，约束解码不等于本体约束。 现在最普遍的误解是做了前者以为做了后者。做一次自查：如果你的系统能阻止模型输出格式错误，但阻止不了"给潜艇装空空弹"这类语义错误，那么约束层只做了一半。

第二，别承诺"万种想定"。 近期有团队宣称 AI 能在 48 秒内重构出上万种作战想定，把传统指挥员 48 小时的编排压缩到秒级。产能提升我不怀疑，该追问的是：这一万种在参数空间里是不是一万个不同的点？ 大模型的生成有强烈的分布偏好，它倾向于生成"训练语料里最像想定的想定"。不做覆盖度度量，一万种可能是同一百种的重复采样。建议对外承诺的是可追溯性与可复现性，不是数量。产能指标容易讲故事，也最容易误导决策。

第三，风险最高的不是技术，是参数来源治理和本体资产的可持续维护。 技术实现有公开路径可循——C2SIM 有标准、神经符号回路有原型、渲染层是工程活；参数治理和资产维护没有现成答案，靠制度与投入。多数本体项目的死亡不是因为设计错了，而是因为建完之后没人养。

顺带说一句现状判断，可能不太中听：国内外公开工作普遍停在"能跑通演示"的阶段。演示证明的是可行性，不是可用性。目前几乎无人公布"人工 / 大模型直出 / 本体约束"三组对照的实验数据，也没有面向军事想定生成的本体评测基准。这既是差距，也是机会——建基准本身就是有价值的研究产出。

---

结语

大模型进入作战仿真，最先被看见的是产能：写得快、写得全、能一次给你几十个变体。但产能不是这个领域最稀缺的东西。

最稀缺的是：一份想定能不能说清它为什么这样、改了什么、指标怎么来的、数据从哪来。本体在这轮热潮里的角色，已经从"给机器读的知识"变成"给机器写的规范"。在一个错误的结论要付出真实代价的领域，这才是它值得被认真对待的理由。