一、先看一个真实查询录屏

在数简的虚拟星座模块里,现在可以这样提问:

没有卫星编号,没有轨道参数,没有查询表单。用户只需要说出业务需求,系统理解意图、调用能力、返回结果。

这是数简在「遥感综合应用」平台中落地的虚拟星座智能体。本文从技术视角拆解它的实现逻辑,并再次验证底层平台对数据标准化处理的重要性，在遥感空间大数据领域，自然语言能跑通，靠的不只是大模型。

二、要解决的问题:数据获取之前的"三个不知道"

遥感卫星数量持续增长,卫星已成为自然资源、水利、应急、农业、保险金融等领域的重要数据来源。但很多业务场景中,用户不想被动等待卫星数据商的数据下发,那么就需要提出三个更前置的问题:

1. 目标区域什么时候有卫星经过?(过境窗口)
2. 哪颗卫星能拍到、能覆盖多大范围?(成像能力)
3. 库里有没有已经拍好的影像?(存量数据)

过去这三个问题要靠专业人员借助卫星轨道、任务规划和影像目录等专业系统查询判断。卫星资源越丰富,这种依赖专业人员的模式越成为应用门槛——汛期监测、灾害应急等对时效性要求高的业务,还容易因为查询滞后造成重复采购和数据利用率不高。

数简的虚拟星座模块就是针对这一环节的卫星数据统筹获取规划工具:轨道动态仿真、过境成像预测、已有影像检索三项能力集成在同一平台。而智能体的加入,把这三项能力从"专业操作"变成了"自然语言入口"。

需要先明确一下边界:虚拟星座做的是成像规划——"哪颗卫星什么时候能拍到目标区域、覆盖效果如何";它不涉及卫星测控("卫星怎么飞、指令怎么执行"),这是两个不同的专业领域。

三、虚拟星座三项基础能力

3.1 轨道动态仿真:看得见卫星怎么飞

基于 TLE(两行轨道根数)数据计算轨道,在三维地球环境中动态展示卫星运行轨迹,支持多星同屏、时间轴任意倍速、卫星详情联动(星下点经纬度、轨道高度、飞行速度实时更新)。

技术要点:TLE 解析 + SGP4 轨道递推,前端三维渲染与后端轨道计算的时间同步。

3.2 过境成像预测:哪些卫星什么时候怎么拍

用户指定目标区域(AOI)和时间范围,系统预测未来卫星飞越目标区域的时间,并计算每次过境的覆盖范围和覆盖率。

技术要点:轨道预报与 AOI 多边形的求交计算;多星并行预测;覆盖率聚合统计。查询结果与三维地球双向联动——点表格定位地球,点地球选中表格。

查询太湖流域过境卫星

3.3 影像检索:找得到已经拥有的数据

按时间、数据来源、空间范围、分辨率、传感器、云量等条件查询库内已有影像元数据,支持按天/按月聚合、覆盖量统计(按卫星维度的覆盖百分比和景数)、覆盖/漏洞/影像范围三种导出。

这一项解决的是"我们以前有没有拍过"——如果库内已有满足要求的历史影像,就无需重复规划获取。

查询山东在库已有影像

四、关键问题:大模型为什么能"听懂"?

这是本文想重点讨论的部分。

把大模型接到遥感平台上,行话叫"接入智能体"。但实际做起来会发现一个反直觉的现象:智能体能不能准确响应,瓶颈往往不在模型,而在数据。

我们在另一篇文章里提出过一个判断:AI 在时空领域的价值上限,不取决于模型参数量,而取决于它调用的数据是否完整、准确、可理解。大模型本质上是"用数据的",不是"修数据的"。底层元数据口径混乱、字段含义不一致,模型再强也只能一本正经地给出错误答案——这不是技术能力问题,是信息论层面的约束。

我们先来看一段用自然语言查询山东省在库影像的视频——

用自然语言查询卫星的场景,正好可以拆开看这个约束如何起作用。当用户说"查询近三年山东省的高分卫星影像",模型需要完成四步:

① 意图理解:"高分卫星"指的是哪些卫星?→ 需要卫星元数据有统一的口径定义
② 能力路由:这是影像检索,不是过境预测 → 需要平台能力有清晰的接口划分
③ 参数映射:"近三年"→ 起止时间;"山东省"→ 行政区边界;隐含条件→低云量优先
④ 结构化执行:生成检索请求,调用影像检索 API,渲染结果

这四步里,只有 ① 的一部分和 ③ 的语义理解是模型的能力,其余全部依赖底层数据平台的治理水平:

• 数据全域一致性:不同卫星、不同传感器的元数据字段口径统一。"高分"能被准确映射到具体的卫星/传感器约束,前提是卫星库里的分类体系是一致的、无歧义的。
• 全链路标准化:影像入库规范统一,检索接口的行为才可预测。模型生成的查询参数,才能稳定命中正确的数据。
• API 自动化生成:智能体调用的过境预测、影像检索能力,是平台依托底层能力自动生成的标准 API,随数据更新实时同步——而不是手工维护的一堆接口。模型调用能力像打开水龙头,而不是适配各种异构管道。
• 元数据智能化:字段描述、接口说明以 AI 可读的文档形态存在。模型不仅拿到数据,还能"看懂"每个字段的业务含义,这是把"高分卫星"这种自然表达准确翻译成查询条件的基础。

所以一个实用的结论是:想让大模型在遥感平台上工作,先要回答"数据对 AI 是否友好"。这也是我们坚持"底座优先、智赋上层"路线的原因——智能体是水面上的部分,水面下是数据治理、标准化和 API 体系。

反过来讲,底座治理到位之后,自然语言入口的收益才真正释放:业务人员不必先学卫星参数和系统操作,水利人员直接问"未来一周什么时候能监测这个流域",保险人员直接问"灾害发生后有没有最新影像"。使用方式从"先学会怎么操作,再去找数据"变成"直接说我要什么,系统帮我查"。

自然语言交互不替代原有专业能力，是在这些专业能力之上,增加了一个更简单的使用入口。

五、几个典型场景下的用法

卫星中心 / 遥感应用中心 / 测绘院:既可接入自有卫星轨道数据,也可汇聚外部卫星资源,在统一环境中做轨道展示、过境预测和覆盖分析,综合判断"自己的星什么时候能拍、外部卫星什么时候能拍",从单一卫星资源管理走向多源协同规划。查询结果可与已有影像目录对接,与存量数据资产统一呈现。

智慧水利:汛期之前,直接查询"未来7天覆盖重点河段的卫星过境窗口",提前形成监测计划,而不是等到业务发生再临时找数据。

应急与灾害监测:灾害发生后快速判断"现在有没有数据、未来48小时什么时候还能覆盖",已有数据检索 + 过境预测组合使用,尽快确定数据获取路径。

保险金融:农险核验等场景查询"这个县最近30天有哪些可用影像,优先高分辨率低云量",缺少历史数据时再追问"未来几天什么时候还能获取这个区域的影像"。

商业遥感企业:一方面统筹自有与外部卫星资源、提升运营效率;另一方面可将成像规划模块配套到客户的数据服务体系中,让购买卫星数据或长期订阅的组织客户自行查询过境窗口、检索已有数据、用自然语言提出数据需求。

六、从单点查询到全流程自动化:成果直接被业务系统调用

最后说一个容易混淆的范围问题:虚拟星座智能体解决的是数据获取环节——知道"什么时候有星、哪颗能拍、库里有什么"。

它是数简遥感综合应用数据流水线的"第一公里"。在此之后,整条链路可以全程无人值守地跑完,一直到成果被业务系统直接调用:

自然语言入口(虚拟星座智能体)
   │  "未来7天覆盖重点河段的过境窗口" → 确定数据获取计划
   ▼
数据获取/接入
   │  窗口命中,数据进入平台(Web/FTP/SCP/软链接多通道接入)
   ▼
自动化生产线 ──────── 无人值守
   │  原始包自动处理:解压→校正→融合→匀光匀色→镶嵌裁剪,直到标准正射影像
   ▼
统一汇聚管理
   │  PB 级数据统一存放,入库即编目,可查可看
   ▼
自动化处理分析 ────── 无人值守
   │  几十种算法开箱即用:水体提取/变化检测/目标识别等按流程自动执行
   ▼
成果输出
   │  解译成果自动生成,支持人工在线核验编辑(仅关键节点需要人)
   ▼
成果被调用 ←──────── 终点不是"生成成果",而是"成果进入业务"
      · 一键推送业务系统,成果直接进入业务流程
      · 通过 Access Key 以标准 API 对外提供,客户业务系统按需调用

支撑这条流水线的核心是流程编排能力:以可视化方式把"生产→管理→解译→输出"各环节编排为自动化流程,支持定时任务、失败重试、全程日志;外部系统也可以通过流程接口触发整条流水线——卫星数据一到,后续生产、解译、成果推送自动运转,不需要人守在每个环节中间。

这条链路里人的角色也变了:人管节点,不盯执行。数据质检规则、算法选择、成果核验这些关键节点由人确认;中间的批量处理、接口调用、成果分发全部自动完成。这正是第四节那套逻辑的延伸——底座把数据、接口、流程治理规范之后,自动化才有落脚点。

对高频监测业务(汛期、灾害、农业、保险核验),这套全流程自动化模式意味着:业务人员从"等数据、催处理、要成果"变成"无感获取决策洞察"——过境窗口确定之后,从数据获取到成果进入业务系统的整个过程无需人工介入;打开业务系统时,可用的成果已经在那里了。

需要说明范围:以上自动化能力属于数简遥感综合应用平台的完整方案,不在虚拟星座模块本身范围内。虚拟星座负责的是链路起点——用自然语言把"什么时候获取、获取什么"规划清楚;起点之后的自动运转,由平台完整方案承接。

FAQ

Q1:自然语言查询的准确率如何保证?靠 prompt 还是有别的机制?

Prompt 只是最后一层。准确率的主要支撑是底层数据治理:卫星/传感器元数据口径统一(数据全域一致性)、影像入库规范统一(全链路标准化)、检索能力是平台自动生成的标准 API、字段含义以 AI 可读文档输出(元数据智能化)。模型在结构化、语义清晰的数据上做参数映射,出错空间才小。

Q2:智能体支持哪些类型的自然语言问题?

目前覆盖两类:过境/成像类("明天谁过境北京""未来7天哪个过境窗口能覆盖某水库")和影像检索类("近三年山东的高分影像""最近30天这个县可用的低云量影像")。两类可以组合追问,先查存量、再问未来。

Q3:这与卫星测控系统是什么关系?

没有重叠。测控解决"卫星怎么飞、指令怎么执行";虚拟星座解决"哪颗卫星什么时候能拍到目标区域、覆盖效果如何、库里有没有现成数据"。前者面向卫星运行管理,后者面向数据获取规划。

Q4:虚拟星座智能体是独立产品还是平台模块?

它既可以作为独立模块快速嵌入客户已有系统,也是数简遥感综合应用平台的一部分。对于已建数据管理系统的客户,可与现有影像目录对接,无需迁移原有数据。

Q5:不是遥感专业人员,查询时需要注意什么表达方式?

按业务语言直接说即可——区域(行政区名或描述)、时间范围、关心的卫星或数据类型(可省略)。系统负责把业务表达翻译成查询参数。表达越接近真实业务需求(如"汛期监测重点河段"),返回的窗口建议越贴合使用场景。

Q6:查询到过境窗口之后,数据的处理和成果交付还要人工跟进吗?

不需要逐环节跟进。数简遥感综合应用平台提供全流程自动化能力:数据接入后由自动化生产线处理为标准产品,汇聚入库后按编排好的流程自动执行解译算法,成果一键推送业务系统或通过 API 供业务系统直接调用。人在其中的角色是"管节点"——质检规则、算法选择、成果核验等关键节点确认,中间过程无人值守。这部分属于平台完整方案,不在虚拟星座模块范围内。