大语言模型在大气科学中的应用：从数据准备到业务实战

在气象台和科研院所混了这些年我明显感觉到大语言模型这股风已经吹到了大气科学门口。很多人一听“AI大模型”就以为是搞深度学习那帮人的事实际上大语言模型擅长的文本理解、知识检索、代码生成、结构化解译恰好戳中了我们日常工作中的一堆痛点——从读文献、写预警、查规范到调试模式、清洗观测数据处处都有它能搭把手的地方。这篇文章我就结合自己的实践聊聊“AI大语言模型”在大气科学领域到底能做些什么哪些是真能落地的哪些又是想当然的坑。先说清楚这篇文章不是要给大模型“贴金”也不是让你放弃动力学和数值模式去跟风。我把它定位成一套“工作流改造”的经验用LLM处理气象数据前的准备、几类高价值场景的具体做法、LLM和数值模式怎么协同、以及我对幻觉和物理一致性这些边界问题的真实感受。如果你是有一定经验的气象从业者、环境科学研究者或者正处于想引入AI又不知道从何下手的阶段这篇内容应该能帮你少走不少弯路。1. 大语言模型在大气科学里的三个切入层次1.1 我为什么觉得“LLM气象”不是蹭热点接触大语言模型之前我先入为主地认为这东西就是个“高级聊天机器人”对讲究定量计算和物理规律的气象业务来说顶多帮我写写周报。真正改变我看法的是一次实测我把一份某次强对流过程的天气公报原文和对应的高空、地面观测数据丢给它让它帮我做“信息完整性核查”它居然能指出公报里缺少了对流有效位能的分析、云图演变描述和地面风场辐合线的对应关系。后来我才想明白气象工作里有很大一部分并非纯粹的数值计算而是“把非结构化信息整理成结构化知识”的过程。预报员读雷达回波、看数值模式输出、写服务材料、回复决策咨询每一环都在做信息提取、上下文理解和语义判断。而大模型最擅长的恰恰就是这些。它不是来替代WRF或者ECMWF模式的而是来重构我们和气象数据之间的交互界面。1.2 三个层次的定位我把“AI大语言模型”在大气科学的应用粗分为三层这样不用一上来就纠结算法细节。第一层是知识语言层解决“查得慢、读不完、写不好”的问题。比如把散落的技术规范、行业标准、历史个例总结整理成检索库让模型帮忙解读雷达产品定义、冰雹指标的阈值或者把一段生涩的英文论文译成中文并标注气象术语的规范译法。这一层技术门槛最低普通业务人员也能用上。第二层是数据治理层解决“脏数据、乱格式、难质控”的问题。气象观测数据经常来自不同设备、不同单位格式五花八门缺测、异常值混在其中。LLM可以做模式识别和规则生成辅助完成数据清洗、单位统一、站点信息匹配等操作。这一层需要一定的数据工程基础但见效很快。第三层是智能体协同层解决“软件操作复杂、流程串联断点多”的问题。比如构建一个气象数据分析Agent它自己会读API文档、拼接数据接口、按你的指令生成POD脚本或Python脚本去绘图、统计、输出结论。这一层也是目前我最看好的方向不过坑也最多后面我会专门讲。这三层不是非此即彼的关系。我个人的建议是从第一层开始找信心在第二层建立工程习惯等你对模型的“脾气”摸熟了再去碰第三层。2. 把气象数据喂给大模型准备工作里的那些坑很多人兴冲冲把NetCDF文件路径丢给大模型问它“帮我分析一下温度场”结果模型要么答非所问要么编一堆假结果。原因很简单大模型不认识NetCDF二进制也没法直接“看见”GRIB网格。你要做的是把气象数据转译成它能理解的语言。2.1 从NetCDF/GRIB到文本解码与切片的工程细节第一步是解码。我常用Python生态里的xarray和cfgrib打开数据再转成pandas DataFrame最后根据需求采样并序列化成文本。这里要特别注意两个问题。第一个是数据规模。一个全球再分析场的单时次数据轻松上百MB就算转成CSV也是几十万行远超模型的上下文窗口。正确的做法不是“扔全部数据”而是“按需切片”。我通常会先用xarray对经纬度范围做区域裁剪再对时间做降采样只保留目标变量和目标层。第二个问题是坐标信息不能丢。气象数据的价值在空间和时间属性光给一串数值没有任何意义。喂给模型前我会明确地写出“站点某某站经度xx纬度xx时间2024-07-15 12:00 UTC变量2m温度单位K”这样的前缀。模型只有拿到完整维度信息才可能在回答中进行有意义的空间对比和趋势判断。下面是我常用的一种序列化格式这里用的是简化示例实际业务里我会把多时次拼成一个列表import xarray as xr import pandas as pd ds xr.open_dataset(sample_sfc.nc) # 区域裁剪与时间降采样 region ds.sel(latslice(20, 40), lonslice(100, 120)) df region[[t2m, u10, v10]].isel(timeslice(0, 48, 6)).to_dataframe().reset_index() # 序列化为带上下文的文本块 lines [] for _, row in df.iterrows(): lines.append( ftime{row[time]} lat{row[lat]:.1f} lon{row[lon]:.1f} ft2m{row[t2m] - 273.15:.1f}C u10{row[u10]:.1f}m/s v10{row[v10]:.1f}m/s ) text_prompt \n.join(lines[:200]) print(text_prompt[:500])2.2 说清上下文气象提示词的结构化写法和LLM打交道最核心的一个理念就是它并不“知道”你的数据它只是在做模式补全。因此你的提示词必须尽量封闭减少它自由发挥的空间。我总结了一个四段式结构效果比较稳定角色设定告诉模型“你是一名有十年经验的中尺度气象分析师”数据字典逐个变量说明单位、含义、数据频率任务目标明确要做什么比如“请判断这12小时内是否有锋面过境并给出依据”输出约束规定输出格式比如“只输出以下JSON{是否过境是/否依据...建议...}”。你别小看“输出约束”这一步。气象业务中经常需要直接对接下游系统能稳定输出结构化JSON比你对话里写得漂亮要重要得多。我甚至会把JSON Schema直接粘进提示词让模型严格按字段返回这样后续写自动化管道时就省去了大量解析工作。2.3 模型选型轻量级还是大参数现在可选的模型很多从开源到商用都有。我的经验是不要在“哪个模型最强”上花太多时间而是看你部署条件。如果你是业务内网环境数据不能出域那就得用私有化部署的轻量模型。这种情况下我建议选指令跟随能力较好、上下文长度在32K以上的开源模型并配合一个好的提示词模板。别贪“聪明”因为气象领域术语多通用模型的预训练数据里这部分占比很低指望它“无师自通”是不现实的。如果数据敏感度不高可以直接用商用大模型的API效果通常更好特别是在长文本归纳、英文文献理解上。但要注意观测数据属于敏感业务数据任何场景下都不建议把原始分钟级观测、GPS探空数据直接外发。我通常会在本地先把数据做统计摘要如区域平均、极值、标准差把“特征值”而不是“原始值”交给模型处理。3. 几个立刻能落地的场景从预警文本到数据质控这一章是全文的实践核心我挑了四个我自己在真实业务或科研里跑通过的方向每个都说清楚“怎么做”和“为什么这样做”。3.1 预警与公报文本的草拟与校核写预警提示、决策服务材料是很多预报员的日常工作但也是比较耗时费神的环节。引入LLM之后我的做法是让它先“写初稿”我们再“做校核”。具体流程是这样的我先给模型一段实况描述比如“某站过去1小时降水量达到47毫米雷达回波强度55dBZ出现在该站西南方向20公里处并缓慢向东北移动”再给它本地阈值规则要求它生成一份包含影响区域、防御指南的暴雨预警草稿。实测下来模型对“影响区域”“防范措施”这类框架性内容写得很完整甚至给出的防御建议比某些模板还具体。但涉及关键数值比如雨强等级、回波移速外推它可能会想当然所以我的铁律是模型负责结构和措辞人类负责数字和结论。草稿生成的最高价值是让预报员从空白页面前解放出来把精力放在判断和核对上。我还做过一个反向应用把一份已经写好的预警材料交给模型让它“基于我提供的实况数据检查有没有描述过度、时间表述含糊、防御建议与预警等级不匹配的问题”这种“AI挑刺”模式在审核环节里相当管用。3.2 站点观测数据的智能质控数据质控看起来跟大模型八竿子打不着实际却是LLM最有用的领域之一。原因在于很多“脏数据”问题其实是有规律的像是气压缺测被填成-9999、风向风速单位混用、降水记录出现“连续多时次完全相同的小数”。传统质控规则能抓一部分但面对新设备、新格式时规则维护成本很高。我尝试用LLM做“零样本异常识别”把某个站点的24小时观测序列转成文本让模型判断哪些时次的数据“可疑”并解释原因。它不需要预先“见过”这个站的数据仅凭常识和统计直觉就能发现一些规则难以覆盖的问题比如“温度在2小时内从-5℃跳到12℃又跳回来日较差异常偏大”或者“降水为0但相对湿度连续12小时保持100%且能见度极低”这类矛盾组合。当然LLM的作用定位为“筛选候选”不是“拍板结论”。我会把模型标出的可疑样本统一输出为待核验列表再结合邻站对比和气候极值库做二次判断。这样做的好处是查全率明显提升业务人员不用再对着海量曲线人眼找茬。3.3 论文与方法文档的快速解析科研人员读文献的时间成本很高特别是碰到方法部分写得不清楚的文章。我发现LLM特别适合做“文档结构拆解”比如把一篇关于雷达定量降水估测的论文解析成数据来源、算法流程、关键参数、检验指标、局限与改进方向。具体操作时我通常把PDF转成文本后分段喂给模型要求它先“提取方法流程术语表”再“把算法步骤写成伪代码”。这样基本上读完几十篇文献的功夫就能攒出一份可直接对照的方法清单再回头查阅原文细节就很方便。这个方法也适用于技术规范类文档。比如某个型号自动气象站的维护手册有几百页直接问人效率低但把它丢进检索增强生成RAG的索引里业务人员用自然语言提问“XX传感器零点漂移怎么校准”就能快速定位相关章节和操作步骤。3.4 日常科研代码的辅助生成做气象数据分析的都知道写脚本这件事本身不难但很琐碎读取GRIB、插值到规则网格、计算散度涡度、画填色图……每一步都可以通过LLM来提效。我的工作流很简单先描述任务最好带上变量名和坐标信息让模型生成可运行的Python代码。比如我想画一张500hPa位势高度场叠加风场就直接说“请读取这份grib文件中的gh和u/v分量用cartopy投影绘制北半球中纬度区域填色为位势高度风羽显示每5个格点”。模型生成的代码第一次大概率能跑通跑不通也无所谓把报错信息原样贴回去让它修就行。需要注意的坑是别让模型碰你没仔细读过的科学计算核心。像涡度计算、对流有效位能CAPE的公式、坐标转换这类我都是自己写好后让模型“润色”或“封装”绝不让它独立生成。模型很容易在公式细节上出错比如把纬度的cos因子漏掉或者把单位搞错。4. LLM和数值模式不是替代是接口很多人会问大语言模型是不是以后能直接替代数值预报模式我的回答很明确短期内不可能也不应该。模式的物理框架、资料同化、集合扰动这些核心机制是LLM不具备的。但LLM完全可以作为模式和用户之间的“接口层”把我们与模式的交互变得更容易。4.1 用LLM生成WRF等模式的配置初稿做过中尺度模拟的人都知道WRF的namelist配置极其繁琐几十个参数每个都影响积分稳定性和物理过程选择。不同研究目标比如理想个例模拟还是真实天气模拟关注对流还是边界层对应的配置差异很大。我尝试把“某个个例、某段时间、关心什么物理过程、用哪套再分析资料做驱动”等信息提供给LLM让它给出namelist初稿。模型基于它训练过的WRF用户手册和社区讨论能给出相当合理的参数组合比如微物理方案推荐Thompson或Morrison、积云参数化在网格距小于4km时关闭等等。但namelist的坑也不少。模型可能给出过时的参数名或者在不该用嵌套的地方建议开嵌套。所以我把它当作一个“经验丰富但偶尔记混的老同事”用它生成初稿后再对照官方用户指南逐项检查。4.2 集合预报结果的解释助手集合预报的输出是一堆成员业务人员平时看的是概率图、面条图。非专业人士面对“30%概率降水”这种表达很容易误解。LLM在这里可以扮演“翻译官”角色我把集合预报的箱线统计和关键概率输出给它让它生成面向决策者的解释文本。比如我提供“某区域未来24小时超过10mm降水概率为40%其中20%成员预报超过25mm控制预报仅为12mm”模型会生成一段“降水不确定性较高建议关注局地强降水可能并留意极端成员对交通和低洼地区的影响”这样的文字。这种内容生成对模型来说毫无压力但对非气象背景的应急管理人员来说价值非常大。4.3 AI Agent与气象数据服务API的衔接这是我自己觉得最“未来感”的一块也是目前投入精力最多的方向。所谓Agent就是让大模型不仅会聊天还能调用工具查API、运行脚本、生成图表。我搭过一个简单的数据分析Agent思路是这样给模型一批预设工具函数包括“读取站点资料”“计算区域平均”“调用绘图接口”“发送结果摘要”然后用户用自然语言描述任务。模型先做“意图解析”将任务拆解成多个子步骤再逐个调用对应的函数接口最终汇总出结论。一开始遇到的困难是模型经常“擅自”调用工具或者在一个步骤失败后不回头找原因而是编造一个结果。后来我加了一条Agent运行约束每个工具调用的返回值必须记录到“执行上下文”中任何步骤失败都要将报错信息返回给模型并明确要求“基于报错修改计划重新执行”。这之后整个流程的可靠度提升了不少。需要注意的是Agent的自动化程度越高对气象业务输出的物理校验要求就越高。我的习惯是Agent只生成图表和文本摘要所有涉及结论性的数字或预警级别判定都必须在管道里设置硬校验而不是指望模型“自己发现自己错了”。5. 踩过的坑和边界气象数据不吃“幻觉”这一套大语言模型的通病是“幻觉”——它会在信息不足时编造看似合理的答案。在通用问答场景里幻觉顶多是闹笑话但在气象领域一个编造的降水极值可能导致错误的决策。我踩过几次雷这里把最关键的几个问题摊开讲。5.1 物理一致性是死线有一回我让模型根据某站逐小时温度序列判断“今日是否有冷空气过程”。它给出了“是”的结论理由是“温度从18℃降至8℃降温幅度大”。实际上那个站位于山区模型完全没有考虑地形高度的影响。单纯看温度变化夏季午后到夜间的降温也可能超过10℃这跟冷空气毫无关系。这个例子说明大模型在作答时不会自动带上物理常识除非你强制要求它“先列出可能的物理解释再做判别”。所以我后来在设计提示词时都会加一句“请严格基于提供的数据和物理规律推理避免纯粹统计联想”。但即便如此LLM对复杂地形、海陆差异、局地环流的理解仍然非常粗浅凡涉及物理机理判断的环节我都坚持人工复核。5.2 时空连续性上下文管理大气变量在时间和空间上都有很强的连续性前一时刻的状态对后一时刻有约束。但LLM的对话式处理天然是“按需取用”的如果你希望它理解趋势就必须主动提供多时次数据让它看到演化过程。比如判断“是否出现逆温层”只给单个时次的探空廓线很难让模型形成正确的垂直结构概念。我的做法是把多个高度层上的温度、露点按“从地面到高空”的顺序排列并标注高度层间距模型才能理解逆温的厚度和强度。简而言之一句话你想让模型看见什么样的上下文就得先在数据侧努力构造这种上下文。5.3 极值样本与回归风险气象数据里最需要关注的就是极端事件。但大模型是基于常见模式训练的对于“历史罕见的暴雨”“百年一遇的高温”它的训练语料里可能根本找不到足够的高质量样本因此它生成的“合理”描述往往在极端情况下是偏保守的。我做过一个测试给模型一组沿海台站的极端风速序列让它判断“是否有台风影响”。模型给出的结论偏“温和”因为它把数值和常见的强对流过程混淆了。后来我改成给它提供“该站历史最大风速记录”和“当前风速占历史极值的比例”模型才给出更准确的判别。关键不是让模型“更聪明”而是把我们行业里的“参照系”喂给模型。5.4 可复现性和版本管理最后一条经验也是我觉得很多AI应用翻车的根源大模型的输出是不稳定的同一段输入今天和明天的结果可能不一样。对科研和业务来说这很致命。你无法向别人证明“上个月的结论”是怎么来的。我的解决办法有两种。一是每个气象AI分析任务都在本地保存完整的“输入数据版本摘要 提示词 模型版本 输出结果”四元组至少保证可以追溯。二是对确定性要求较高的任务如数据质控和格式转换优先使用本地部署的小模型并固定解码参数尽量保证输出稳定。归根结底大模型在气象业务里应该被当成“辅助决策工具”而不是“可靠数据源”。6. 实操层面的几点体会如果你看到这里说明你确实想在“AI大语言模型大气科学”这件事上动真格的了。那我最后分享几条个人经验。第一别从“做一个大而全的气象AI系统”开始。我见过不少同行一上来就想搭一个能自动分析回报的Agent结果几个月过去还在折腾架构。更务实的路线是挑一个频率高、耗时多、反馈清晰的小任务比如“日报摘要生成”或“雷达回波txt转结构化表格”先跑通一个完整闭环再逐步扩展。第二把提示词当成代码来维护。我的提示词都放在版本控制里改一个措辞就提交一次后面才能比较究竟哪个表述对结果影响更大。你会惊讶地发现很多时候不是模型能力不够而是你的提示词里少说了几个关键限定词。第三数据的“口径描述”比算法更重要。无论是做RAG还是微调都要让模型清楚地知道数据从哪里来、单位是什么、时间标准是UTC还是北京时、经纬度坐标是WGS84还是CGCS2000。这些看似琐碎的元信息直接决定了模型输出的可信度。第四永远给模型留一条“我不知道”的退路。我在提示词里经常加一句“如果提供的数据不足以得出结论请明确说明缺少哪些信息而不是猜测”。这一条能显著减少幻觉也会让模型反馈出很多业务系统里被忽略的数据缺口。最后说句真心话我在这个方向折腾大半年最大的收获不是某个具体功能上线而是改变了和气象数据打交道的方式。以前遇到一个不清楚的格式、一段晦涩的方法描述我的第一反应是去翻书、问人、试错现在我会自然地想“能不能让LLM先帮我拆解一遍我再判断”。这种“人做判断、AI做跑腿”的协作模式恐怕才是“AI大语言模型”真正能在大气科学领域持续创造价值的地方。