遥感模型交付往往只留下权重文件、README 和一段推理脚本。几个月后，团队很难回答它需要哪些波段、怎样归一化、输出类别的含义、适用的框架版本、模型与训练数据之间的关系。STAC Machine Learning Model（MLM）扩展把这些问题放进 STAC 文档：模型可以和影像、集合、资产一起被发现，但每个模型仍要有明确的输入、输出、artifact 与运行条件。

本文依据 STAC Extensions 的 MLM 官方规范仓库整理。规范是 Candidate 级别，字段与实现仍可能演进；目录记录能提高可发现性与可复现性，不能自动证明模型精度、许可或部署安全。

可核查事实

  • 官方 README 将该规范名称列为 Machine Learning Model，字段前缀为 mlm，schema identifier 为 https://stac-extensions.github.io/mlm/v1.5.3/schema.json，成熟度为 Candidate。

  • MLM 字段可用于 STAC Collection、Item Properties、Asset 和 Links；Catalog 本身不在该表的适用范围内。

  • 规范目标之一是建立可与关联 STAC dataset 一起搜索的 model collection。

  • 另一目标是记录部署 inference service 所需的 band、数据变量、hyperparameter、模型 artifact 位置与高层处理步骤。

  • README 列出的模型可检索信息包括 sensor band/climate variables 等 datacube dimensions、输入输出 resize/normalization、shape/data type/semantic interpretation、runtime environment、weights/code/architecture、训练数据引用和科学文献。

  • mlm:name、mlm:architecture、mlm:tasks、mlm:input 与 mlm:output 是 Item Properties 中标示为 REQUIRED 的字段。

  • mlm:framework_version 可记录训练框架版本，mlm:memory_size、mlm:batch_size_suggestion、mlm:accelerator 等字段可描述推理资源条件。

  • 规范偏向监督学习模型的元数据，但与监督学习相关的字段是可选的，其他任务可使用其需要的字段。

  • README 明确建议一个定义完善的 MLM STAC Item/Collection 几乎不应只声明 MLM 一个 extension，而应按需组合其他 STAC extensions；旧的 DLM 已重命名并重构为 MLM，ml-model 也有独立迁移说明。

这些事实让“模型目录”从文件清单变成接口合同：客户端不必猜测某个 .pt、.onnx 或 container 是否可用于当前影像，而可以先按输入、任务、运行条件和关联数据集筛选。

核心机制

模型发现与模型执行应分层。发现层回答“是否有一个模型看起来适合这个任务”：任务、名称、架构、输入波段和输出语义是否匹配。执行层回答“当前数据和环境能否正确运行它”：实际 collection/item、波段顺序、单位、空间分辨率、预处理、框架版本、权重散列、资源和许可是否满足。MLM 的价值是让前一层可被 STAC 查询并为后一层提供必要元数据，而不是把任何可搜索模型都当作可直接部署的模型。

输入输出元数据尤其不能省略。写“语义分割模型”不足以知道它期待 Sentinel-2 哪些 band、是 reflectance 还是缩放值、是否需 resize/normalization、输出类别是概率、logit 还是 label ID。对应地，mlm:output 应让下游知道每个 output 的形状、数据类型和语义解释，避免把概率栅格当分类结果或把 class ID 当连续值。

GIS 场景

以洪涝范围制图为例，数据平台可以把模型 Item 与其训练/评测相关的 STAC Collection 建立关联。分析人员先检索任务为 segmentation、输入含光学或 SAR 变量、覆盖适用区域和许可满足要求的候选模型。每个候选必须再与本次的影像时间、波段、分辨率、云/水面处理和投影规则逐项比对，不能因为任务名称相同就直接推理。

结果也要以资产形式入目录：输出 raster、矢量化边界、置信度层、推理日志和 provenance 分别说明。模型卡、阈值和已知失败场景应该被链接或写入合适的扩展字段。这样，后续用户能追溯“哪一次洪涝图由哪个模型、哪版权重、哪些输入和哪个参数生成”，而不是只拿到一个没有上下文的 GeoTIFF。

技术路径

先定义团队的最小模型注册包：STAC Item、权重/代码/container artifact、输入输出合同、运行环境、训练/验证数据链接、许可和版本。将 mlm:name、architecture、tasks、input、output 当作登记门槛；framework、framework_version、batch size、accelerator 和 memory 作为可运行性说明。对于敏感或受限模型，目录只公开可发现的摘要，artifact URL 与访问令牌由独立授权系统控制。

其次把预处理从隐藏脚本提升为元数据。记录 band 名称与顺序、单位、nodata、resize、normalization、tile overlap、CRS/scale 假设和后处理阈值。用固定 STAC Item 跑一次端到端验收：读取输入、执行变换、运行模型、验证输出 shape/data type、检查语义映射，再记录 artifact hash 和环境版本。

最后实施演进规则。规范版本、mlm schema、相关 STAC extensions 和字段迁移都写入 CI 校验；旧 DLM 或 ml-model 记录转换时保留原始 document 与映射报告。任何 schema 升级、权重替换、预处理调整或类别定义变化都产生新版本，不覆盖已发布的结果谱系。

风险边界

MLM metadata 可以描述模型，却不能代替针对目标区域、时相、传感器和人群的验证。Candidate 规范、Pydantic/PySTAC 实现与下游服务的支持程度也可能不同。模型 artifact 的 URL、checksum 和框架版本并不能自行解决供应链信任、访问授权或许可证冲突。模型目录还可能暴露训练数据、地理范围或敏感类别信息，发布前应检查公开字段与访问策略。

检查清单

  1. 每个模型 Item 至少填写名称、架构、任务、输入与输出合同，并声明对应的 mlm schema 版本。

  2. 记录 band、变量、单位、顺序、resize、normalization、shape、data type 和输出语义。

  3. 将权重、代码、container、训练/验证集合、文献与许可用可审计链接关联起来。

  4. 把 framework/version、资源、batch 建议和 accelerator 条件列为部署前检查，而非备注。

  5. 用固定 STAC Item 验证从输入读取到输出资产的全链路，并保存 artifact hash 与环境版本。

  6. 禁止仅声明 MLM；按数据、投影、资产和许可需要组合其他 STAC extensions。

  7. 对 DLM 或 ml-model 旧记录保留原文和迁移映射；权重或预处理变更生成新版本。

结论

可复用的遥感模型不只是一个权重文件，而是一份关于数据、变换、输出和运行条件的合同。用 STAC MLM 让模型与数据一起被发现，再用端到端验证确认它能在当前任务中正确执行，才能让 GeoAI 模型库从下载站变成可审计的生产资产。

参考来源

  1. STAC Machine Learning Model Extension Specification：https://github.com/stac-extensions/mlm