news 2026/10/31 17:48:15

每晚 1000 万条警报:望远镜的瓶颈已经变成算法

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
每晚 1000 万条警报:望远镜的瓶颈已经变成算法

📋 目录

  • 📊 先看一组让人失去感觉的数字
  • 🔬 Fengwu Sun 在硅谷 101 讲了什么
  • ⭐ 一个刚刚发生的真实案例:2026 ED138
  • 🔍 纠错:AI 在这件事上到底做了什么,没做什么
  • 🧪 中国团队在同一条赛道上:西湖大学 DREAMS
  • 💡 一个容易被忽略的转机:商业资本正在改变望远镜的研发节奏
  • 🏗️ 与领码 SPARK 融合平台的关系:数据洪水时代的三个设计选择
  • 📌 三条可以直接用的判断
  • 💬 想听听你的判断

📊 先看一组让人失去感觉的数字

先说结论:天文学是当下最迫切需要 AI 的领域之一——不是因为 AI 更聪明,而是因为数据量已经彻底越过了人类的处理上限。

先把 Rubin 天文台的官方数字摆出来。这些数字来自 Rubin 官方与 NOIRLab,不是二手转述:

项目数值
原始数据每晚约 20 TB
单张图像3200 万像素,每 40 秒一张,每张8 GB
事件警报每晚最多约 1000 万条
实时警报延迟60 秒
十年巡天原始数据60 PB
十年处理后数据总量约 500 PB
最终数据库(DR11)15 PB
十年累计天体约200 亿个星系、170 亿颗恒星、600 万条太阳系天体轨道

每晚 1000 万条警报是什么概念?就算把全世界所有天文学家和研究生加起来,每人每秒处理一条也追不上。而且每条警报都需要判断:这是真实天体、仪器瑕疵,还是已知目标的再次出现。

这台望远镜 2025 年 4 月首次成像,2026 年 6 月正式开跑十年巡天。换句话说,它刚刚开始生产数据,而数据管线的规模已经要靠 CERN 的软件来扛——Rubin 的数据目录系统直接借用了 ATLAS 实验的方案,因为两者面对的是同类问题:多站点、几十亿个对象、巨量数据。

全链路的自动化程度是这样的:

注意这条链上没有人在中间按按钮。7 秒传输、自动比对、自动发出警报、自动分类路由——人只在最后一步介入,而那一步已经是"从已经被筛过一遍的东西里挑出值得追的"。

对照企业里的现状:很多系统还在"数据进来 → 推给所有人 → 所有人自己筛"这一步上打转。Rubin 的做法是把"筛"这一步前置到算法层,人只在末端出现。

🔬 Fengwu Sun 在硅谷 101 讲了什么

在硅谷 2026 大会(Alignment 2026)上,西湖大学助理教授Fengwu Sun做了一场 Keynote,主题是 AI 如何改变天文学。他以詹姆斯·韦布空间望远镜(JWST)、Nancy Grace Roman 空间望远镜和 Vera Rubin 天文台为例,描述了一个共同困境:

新一代望远镜每天可能产生数 TB 乃至数十 TB 的数据,以及数百万条天文事件提醒,远远超出科学家人工处理的能力。

他给出的三个 AI 介入方向很具体:

方向AI 在做什么解决的问题
识别引力透镜从海量观测中识别透镜现象透镜是寻找系外行星、测量暗能量的重要手段,但人工在千万级星系样本里找几千个高质量透镜几乎不可能
寻找超新星在数据流中定位超新星等暂现源超新星是关键的距离标尺,漏掉就少了一批数据
降低图像噪声用自监督学习提亮图像发现更微弱的天体信号

他还提到一个更远的方向:AI 未来可能进一步参与望远镜的自主观测与任务规划——不是只处理已经拍下来的数据,而是决定下一拍拍哪里。

而他最值得被转述的一个判断是:天文学既迫切需要 AI,也可能成为 AI 研究的重要试验场。

理由很扎实:宇宙每天都在产生海量、真实且未经标注的新数据。这对 AI 来说是最稀缺的东西——真实分布的数据、不需要人工标注、且能持续产生。

⭐ 一个刚刚发生的真实案例:2026 ED138

就在 10 月 27 日,IAU 小行星中心(IAU MPC)宣布了一个新发现:Rubin 天文台发现首个矮行星候选体 2026 ED138。

这个案例值得完整拆开,因为它把"AI 找天体"的真实分工展示得非常清楚。

项目数值
发现者Matthew Holman(哈佛-史密森天体中心 CfA)
发现方式运行自己与 Kevin Napier 开发的搜索代码
关键日期2026 年 10 月 13 日,在此前已收集的 Rubin 数据中跑出
观测跨度3 月 4 日至 7 月 11 日,20 个夜晚,共 30 次观测
回溯数据DECam 归档图像经 Asteroid Institute 的 ADAM Precovery 服务回溯到2016 年
轨道拟合长度超过 10 年
当前距离约46 天文单位(冥王星平均约 40 au)
估计尺寸600 – 1500 公里(依据距离、亮度和估计反照率)
轨道倾角约 25°,属"热经典"型 TNO

Holman 说:“我的第一反应是又兴奋又不敢相信。这类天体非常罕见,所以我马上开始检查是不是我或者代码出了什么错。”

这段自述是整件事里最有价值的一句。它准确描述了人机分工的真实状态:算法给出候选,人类的第一反应是怀疑。这跟 10 月 13 日一位 DeepMind 科学家说的"AI 写代码能验证、写科学不能"是同一个问题的两面——但今天这个案例给出了更具体的答案。

🔍 纠错:AI 在这件事上到底做了什么,没做什么

网上关于"AI 发现新天体"的表述越来越顺口,但按招股书式的严谨要求,得把边界划清楚。

说法是否成立说明
“AI 发现了新天体”⚠️ 简化算法做的是"从数十亿次探测中归并出属于同一物体的那些";判断它是什么天体、是否够格叫矮行星,是人做的
“AI 找到了前五颗矮行星之外的第六颗”❌ 不成立ED138 是候选,需红外观测进一步约束尺寸才能确认
“Rubin 每天产生 20TB 数据”✅官方口径,每晚约 20TB 原始图像
“每晚 1000 万条警报”✅官方"每晚约 1000 万条"
“数据传到美国需要 7 秒”✅从智利山顶传到 SLAC 的美国数据设施
“十年产生 500 PB 数据”✅处理后总量(含模拟);原始数据是 60 PB
“人类已经看不过来”✅这是全部前提

两个特别值得说的技术细节:

第一,7 秒。每次曝光后 7 秒内,图像从智利山顶传到 SLAC 的美国数据设施,随即与参考图像比对、标出差异、发出警报。80 小时后,图像被镜像到法国和英国的数据设施。这是全链路自动化的——没有人在中间按按钮。

第二,那 30 次观测是怎么"攒"出来的。Holman 10 月 13 日跑代码时发现的,只是 Rubin 在 3 月到 7 月间拍到的一次。团队随后在 Rubin 的目录里翻出另外 20 次观测,又通过 DECam 的 2016 年归档图像把轨道追溯到十年以上。

这正是机器学习真正的价值所在:不是它"看懂了"一张图,而是它让"同一个物体在 30 个不同夜晚、30 张不同图像里出现"这件事能被自动归并出来。没有这个归并能力,人根本无从知道该去翻哪 30 张图。

🧪 中国团队在同一条赛道上:西湖大学 DREAMS

有意思的是,做这场演讲的西湖大学,恰好也在 10 月 27 日(同一天)发布了 DREAMS 巡天计划的首批数据。

项目数值
覆盖范围银河系中心附近约5 平方度
恒星数量近6000 万颗
观测频率分钟级(时间采样间隔约 1–2 分钟)
数据总量约2.5 TB,已通过国家天文科学数据中心免费开放
通道近红外 z 波段约 80%,可见光 r 波段约 20%
探测深度单次曝光极限流量约为以往同类巡天的1/5
观测期2025 年启动,计划持续至2028 年
首要科学目标微引力透镜搜寻地球至火星质量级别的流浪行星

首发数据只用了约 0.4% 的天区做试点搜寻,就发现了一批全新的短周期变星、两个恒星耀发事件,以及一个此前未知的短时标微引力透镜事件。

0.4% 的天区。这是"数据开放"这件事最有力的证据——剩下 99.6% 还在那儿。

而且这个比例背后是一个可以复制的做法:先做小范围试点搜寻,把方法验证了,再开放全量数据。0.4% 的天区找出的那批新短周期变星、两个耀发事件、一个未知微引力透镜事件,本身就是方法有效性的证明——这比"我们放了很多数据出来"这种表态有力得多。

而在另一条线上,同济大学等团队用机器学习框架CIGaRS处理 Ia 型超新星,把暗能量参数约束能力比主流方法提升了约4 倍。他们自己说:这对 LSST 每周 TB 级数据量的节奏来说,“几乎是必不可少的技术储备”。

这两件事放在一起,指向一个共同结论:AI 在天文学里的角色不是"提出理论",而是"把已经被拍下来的东西榨干"。望远镜拍到的每一个光子,早就躺在硬盘里了;真正的问题是没人来得及看。机器学习填的正是这个缺口。

💡 一个容易被忽略的转机:商业资本正在改变望远镜的研发节奏

Fengwu Sun 在演讲里还谈到了一个看起来不像是技术话题的变化,但它其实很关键:

随着商业资本进入太空观测领域,一些新望远镜项目开始借鉴科技创业公司的研发模式,希望通过更快的迭代和商业化供应链,降低天文观测的成本。

这件事为什么重要?因为它意味着望远镜本身正在变成一个可以迭代的产品,而不再是一个一次性的巨型工程。

传统大型天文台的建设周期是十年二十年,一旦建成,数据管线就是围绕"固定产出、固定处理方式"设计的。而如果新一代项目采用更快的迭代节奏,那么观测数据的多样性和格式变化频率都会上升——这会直接推高对灵活数据管线的要求。

传统模式商业化迭代模式对数据管线的影响
一次性建成,产出格式相对稳定持续迭代,仪器与格式都可能变接入层必须能容忍格式演进
数据量可预估数据量与产出节奏都可能变容量规划不能按固定配额
少数几个大型数据节点分散 + 商业供应链多方参与数据权利与协议复杂度上升

而这恰恰是本栏目的读者更熟悉的问题:当数据来源从"几个稳定的系统"变成"多个会变的供应商",接入层的设计目标就要从"能接进来"变成"能接进来并且能一直接下去"。

🏗️ 与领码 SPARK 融合平台的关系:数据洪水时代的三个设计选择

这一节说领码 SPARK 融合平台在这件事上的设计选择。

边界先说清:平台能让数据可接、可分流、可追溯。哪一类数据值得人看、哪一类交给机器,这个判断只能由业务方做。

其一:iPaaS 接入层的第一课,是"数据来得比人处理得快"

Rubin 的管线有一个关键设计:先分类,再分发。每晚 1000 万条警报不直接推给科学家,而是先经过一层叫"broker"的专门软件——这层软件本身就是基于机器学习分类算法的——把警报分类、评分,然后才路由给全球各地的科学团队。

这和很多企业现在做的事正好相反:数据一进来就推给所有人,然后让人自己筛。

对照一下就有数了:

做法结果
数据直接推给人,人自己筛人成了瓶颈,且所有人重复劳动
先用算法分流,只把值得看的给人人只处理有价值的部分

对应到企业:iPaaS 接入层要接进来的,不只是"数据源清单",还有"分流规则"。一条新的业务数据进来时,系统应该知道它是"直接给业务方看"、“先聚合再给”、“还是先过一道算法评分再给”。

需要记录为什么
数据来源与到达延迟决定这条数据能不能进实时决策
分流等级与规则版本决定谁在什么条件下会看到它
原始量与净量区分"数据洪水"和"有效信息"
丢弃/降采样策略明确"什么被扔掉了",避免不可追溯

判断标准:能不能回答"每一条到达的数据,最终被谁看到了、为什么是他"。

其二:治理中心要把"警报"当成一等公民指标

在 Rubin 那里,一个警报是一条待判断的候选。它有自己的生命周期:生成 → 分类 → 分配 → 观察 → 确认或否决。

企业里对应的是同一类东西,只是叫法不同——线索、异常、待办、风控告警。这类"候选"型数据的治理,比"记录"型数据难得多,因为它们数量巨大、且必须可追溯。

治理中心要管的:

需要记录用途
候选产生时间与来源复现一条告警的来龙去脉
评分与评分依据判断分流规则是否合理
处置状态与处置人区分"已确认"和"没人看"
误报率与漏报率误报太多 → 人会忽略全部告警
观察窗口与失效时间错过窗口的候选要能被标记出来

判断标准:能不能回答"上周产生的一百万条告警里,有多少被人看过、被确认过、有多少是误报"。最后一个数字最关键——误报率过高时,人会形成"忽略告警"的习惯,此后真问题也一起被忽略。

其三:全域守卫要管住"数据权利的分层"

Rubin 有一整套数据权利制度:美国和智利本地的专业天文学家自动获得官方发布数据的权利,其他人需要通过贡献申请。数据平台 Rubin Science Platform 向获授权者开放。

这说明连"谁能看到原始数据"都是一个需要认真设计的治理问题,不是默认全开。

对应到企业,全域守卫该做的是:

  • 按角色分层授予原始数据访问权(不是所有岗位都需要看到全部原始数据)
  • 记录每一次数据访问的来源与用途
  • 对高敏感数据集设置导出与二次分发的限制
  • 让"谁能看"和"谁能改"是两套独立的权限

其四:与 Dify 的分工

平台层负责数据接入、分流、归集、审计;具体的分析工作流、多轮 Agent 编排、Prompt 管理留给 Dify 这类应用层框架。

理由很直接:Rubin 的 broker 做的是"分流"和"初筛",不是"研究"。前者是平台该做的通用能力,后者是每个科学团队自己的方法论。把研究工作流塞进数据接入层,数据接入层就会被拖垮——这在处理每天 20TB 数据时是致命的。

📌 三条可以直接用的判断

#判断
1数据洪水场景下,先分类再分发比直接推给人是更优解——把人从"筛数据"里解放出来
2告警类数据一定要监控误报率,误报多了等于没有告警
3AI 处理真实海量数据时,人的第一反应应该是怀疑而不是采纳——这个习惯要写进流程

⚠️ 需要说明的取舍:本文引用的每晚 20 TB、3200 万像素、每 40 秒一张、每张 8 GB、每晚约 1000 万条警报、60 秒警报延迟、60 PB 原始、约 500 PB 处理后、15 PB DR11、200 亿星系、170 亿恒星、600 万条太阳系轨道、7 秒传输、80 小时镜像、ATLAS/CERN 软件借鉴均已核对至 Rubin 官方与 NOIRLab 官方材料。ED138 相关数据(10 月 13 日发现、3 月 4 日至 7 月 11 日、20 个夜晚、30 次观测、2016 年 DECam 回溯、10 年以上轨道、约 46 au、600–1500 公里、约 25° 倾角)均核对至 IAU MPC 公告与 NOIRLab 新闻稿。西湖大学 DREAMS 数据(5 平方度、近 6000 万颗恒星、分钟级、约 2.5 TB、z/r 波段 80%/20%、极限流量约为同类 1/5、0.4% 天区试点发现)核对至科技日报 10 月 27 日报道;CIGaRS 提升约 4 倍核对至中国经济网报道。本文明确不引用:Fengwu Sun 演讲中"数 TB 乃至数十 TB"与"数百万条天文事件提醒"的笼统表述(本文改用 Rubin 官方可核对的精确值);"AI 发现新天体"这类把发现归功于算法的表述(本文已作纠正);ED138 的"矮行星"定性(目前仅为候选,需红外观测确认尺寸);New Constructs 的"1500 亿美元公允价值"等与本文无关的估值结论。


💬 想听听你的判断

你们公司里,是不是也有一堆"告警"在每天产生?

请回答这个具体问题:上个月你们的系统产生了多少条告警,其中有多少条被人真正看过并处理了?如果这两个数字差得很远,评论区说说差多少——我猜误报率才是真正的问题所在,而不是告警不够多。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/31 17:46:33

SAP 悄悄挪了一条边界:ADT 3.62 之后,AI 能在 ABAP 里干多少真活?

这个月 SAP ABAP Development Tool 最新版本 3.62 发布了,其中一个引人注目的点就是其包含的 ABAP MCP Server 功能进一步得到增强。 本文给大家捋一捋。 这个 ADT 自带的 MCP Server 配置界面很简洁,在 MCP Server 面板启用 Server,这个 Server 运行在本地,需要指定一个…

作者头像 李华
网站建设 2026/10/31 17:43:52

2027年PMP什么时候考?官方节奏、机构排课信号与备考时间线

说明:本文仅基于公开信息对2027年PMP考期做推测性梳理,不推荐任何考试、培训机构或课程,也不构成报名、购课或备考决策建议。文中日期除2026年官方计划外均为推断,最终以PMI及中国国际人才交流基金会官方通知为准。一句话结论&…

作者头像 李华
网站建设 2026/10/31 17:42:36

从分散工具到统一工作台:体验 Tck 办公 AI

不知道大家有没有这种感受,现在办公里用到的 AI 能力越来越碎。写文档用一个,搜资料用另一个,整理会议纪要再换一个;遇到想查软件、排查电脑小问题,又要去别的地方找方案。来回切换账号、网页、工具,本身就…

作者头像 李华
网站建设 2026/10/31 17:42:27

Python城市交通流量预测平台:道路监控、数据查询与可视化分析

商品编号:000052商品编号:000052城市交通流量预测与可视化平台提供路段交通数据查询、流量监控、统计图表和短期预测分析,配套原项目模拟交通数据。技术栈采用Python 3.12、Flask、SQLAlchemy、PyMySQL、NumPy、Pandas、scikit-learn、Bootst…

作者头像 李华
网站建设 2026/10/31 17:41:44

AI新手必看:Prompt、Skills、MCP、Workflow、Agent核心概念解析

学习AI如同掌握一门新语言,Prompt、Agent、MCP、Skills、Workflow等概念繁多且易混淆。本文通过建立关系表,清晰解析了每个概念的核心作用与重点,帮助读者理解任务表达、能力封装、系统连接和执行组织等关键方面,为深入AI学习打下…

作者头像 李华
网站建设 2026/10/31 17:24:59

硬件I2C vs 软件I2C:嵌入式工程师的选型避坑指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华