★ FEATURED ARTICLE 项目标题里那串长长的修饰词确实容易让人望而生畏但拆开看它其实就讲了一件事怎么把过去靠专家拍脑袋、翻文献、熬夜写报告的地质灾害防治流程用大语言模型重做一遍。地质灾害防治这个领域我断断续续接触了六七年。以前做一个县级的滑坡易发性分区光整理历史灾害点、提取地形因子、构造判断矩阵就得耗掉两三周中间还要反复跟地质专家核对打分逻辑。这两年大语言模型火起来之后我第一次尝试用它去解析灾害点档案里的文字描述十分钟整理出几百条结构化样本那个冲击感到现在还记得。这文章我就按自己实际走过的路子来写。如果你手里正好有地质灾害项目或者想用LLM改造其他传统评估流程应该能从中找到几条能直接用的思路。1. 为什么是LLM而不是更复杂的算法——重新审视地质灾害防治流程的瓶颈1.1 传统流程里最拖后腿的三个环节地质灾害评估这件事本身并不缺少数学模型。易发性分析有层次分析法、逻辑回归、随机森林、支持向量机风险评估有承灾体暴露度模型、易损性曲线灾后重建有物资调配优化算法。模型库相当齐全真正拖后腿的是模型前后那堆没法算法化的琐碎工作。第一个瓶颈是数据入口。地质灾害相关的基础资料遥感影像、DEM高程、地质图、降雨量、历史灾害点这些结构化数据还好处理真正麻烦的是那些非结构化文本。灾害点档案里密密麻麻写着“该处斜坡上部为第四系残坡积粉质粘土下部为强风化泥岩前缘见多处拉裂缝雨季有明显渗水”这种描述性文字要变成模型能用的特征变量过去只有靠技术人员一条条手工整理。一个县级项目动辄几百个灾害点光这一步就让人头大。第二个瓶颈是专家经验的表达。易发性分析里最常见的方法是层次分析法核心是让专家对坡度、岩性、植被覆盖这些因子两两打分构造判断矩阵。这个矩阵的质量直接决定了权重是否靠谱。但不同专家对同一组因子的重要性判断经常差异巨大而且解释不清为什么这么打分。最后的成果报告里只能写“依据专家经验”评审专家问一句“权重怎么来的、依据是什么”场面一度很尴尬。第三个瓶颈是成果产出的重复劳动。评估完成后要出文字报告一套标准模板区域概况、地质环境条件、灾害发育特征、易发性分区、防治建议。每个项目基本一样只是数据不同。这种报告我见过有同事连着一周每天加班到后半夜就是为了把几百分区的统计描述填到对应的模板段落里。1.2 LLM在这一流程里的真正定位大语言模型进场之后我反复试过各种用法的效果最后总结出它的定位其实非常清楚它不负责“算”它负责“读、写、整、问”。“读”是把非结构化文本变成结构化数据。几百条灾害点描述它能抽取出来岩性、坡度、变形迹象、地下水状况这些关键属性。“写”是自动填充报告模板的各个段落生成区域灾害发育特征描述。“整”是整合来自不同来源、不同精度的数据比如把历史灾点和降雨站点数据按空间位置关联起来生成综合评估所需的统一表格。“问”是辅助专家自查拿生成的风险结论向模型追问为什么这个区域划为高风险依据了哪些因子哪里数据不足这不是用LLM取代传统评价模型更不是让LLM去搞数值计算。我见过有些人尝试让LLM直接判断某个网格单元是否属于易发区这方向就错了。LLM的空间推理能力和数值稳定性都不足以支撑这种精细计算而且一旦出错很难排查。正确的做法是传统模型负责定量计算LLM负责围绕这些计算的输入准备、参数设定、结果解读和报告产出。一句话概括LLM干的是“数据进、报告出”这条流水线上那些过去靠人工的环节。2. 数据准备与知识库构建——LLM在地质灾害中的第一场硬仗2.1 评估需要哪些数据它们各自长什么样做任何地质灾害评估之前先把底数摸清楚。以滑坡易发性分析为例通常需要这六类数据地形数据主要是DEM用来提取坡度、坡向、曲率、地形湿度指数、地质数据岩性、地层、断层分布、气象数据多年降雨量、极端降雨频率、环境数据植被覆盖度、土地利用类型、灾害本底数据历史灾害点的位置、规模、成因类型、活动状态以及承灾体数据居民点、道路、耕地、工程设施分布。这些数据的格式非常不统一。DEM是栅格地质图是矢量多边形降雨数据可能是站点表历史灾害点经常是文字报表加坐标点。过去做数据融合要么靠GIS软件手工切片要么写Python脚本逐类处理。LLM能介入的地方在于数据描述文档的解析。我遇到过很典型的情况项目组收到一批某规划院的灾点卡片正反面扫描件上面手写加打印混合很多关键信息填得模棱两可。让实习生录入一天录几十条还要反复核对。用LLM做OCR后的文本抽取把“前缘见拉裂缝”“坡面有湿斑”“民房墙体开裂”这些描述统一映射成“前缘裂缝发育”“坡面渗水”“承灾体受损”等标准标签几百条记录一个晚上就能处理完格式统一、可直接入库。2.2 非结构化文本如何转成结构化训练样本这个过程我拆成三步操作每一步都有很明确的处理要点。第一步是设计抽取Schema。不要想到什么抽什么先跟地质专家确认哪些属性是后续建模真正要用的。常见的有灾害类型滑坡/崩塌/泥石流、规模等级、地层岩性、坡度范围、变形特征裂缝/下挫/鼓胀、诱发因素降雨/人类工程活动/地震、目前稳定状态稳定/基本稳定/不稳定。Schema要提前定义枚举值范围比如岩性这一项如果任由模型自由发挥可能会出现“粉质粘土”“粉质黏土”“黏性土”三种说法并存后面对不齐。第二步是写抽取提示词。提示词里要明确“你是地质灾害勘查数据处理助手请从以下灾害点描述文本中提取指定字段只输出JSON不要解释不要补全缺失字段填null。”然后把Schema的定义、枚举值列表、以及三五个示例放进去。我这里给出一个实测可用的模板框架extraction_prompt 你是地质灾害勘查数据处理助手。 请从下面的灾害点描述文本中提取指定信息输出JSON格式。 字段说明 - disaster_type: 灾害类型可选值[滑坡,崩塌,泥石流,地面塌陷] - scale: 规模等级可选值[小型,中型,大型,巨型] - lithology: 主要地层岩性请规范为地质用语 - slope_angle: 坡度输出数字单位度 - deformation: 变形特征可多选列表形式[裂缝,下挫,鼓胀,渗水,无] - trigger: 主要诱发因素可选值[降雨,人类工程活动,地震,重力,未知] - stability: 稳定状态可选值[稳定,基本稳定,不稳定,未知] 文本如下 {text} 只输出JSON不要输出其他内容。 response llm.chat(extraction_prompt.format(textrecord_text)) parsed json.loads(extract_json_block(response))第三步是结果校验。这一步绝对不能省。我现在的做法是抽取完之后跑一遍规则校验——岩性字段是否在标准地质词表里坡度值是否在0到90之间枚举类型是否合法。不合法的扔回给LLM二次修正还是不行就标记人工处理。实测下来这条流水线能把人工工作量压缩到原来的百分之十左右。2.3 用RAG架构把散落的知识组织成可检索的资产数据整理完还不算完。地质灾害项目有一个特点就是同一个区域内历年积累的勘查报告、科研论文、地方防治规划、灾情通报非常多。这些文档里面有大量宝贵信息——某段公路切坡后发生过几次小型崩塌、某沟谷在暴雨期反复出流、某区域的软土分布深度的实测记录。这些信息分散在不同格式的老文件里用的时候找不到不用的时候碍事。RAG检索增强生成解决的就是这个问题。把历史报告切片、向量化存进向量数据库检索时根据查询语义召回相关内容再交给LLM组织答案。我在工程实践里用这套架构做过一个“区域内灾害发育规律问答”工具输入“某流域过去十年泥石流暴发的时间特征”它能从历年降雨记录、灾害通报中挑出相关数据给出相对可靠的规律总结。构建这个知识库时有几个很容易踩的坑值得专门说一下。文本切片的长度直接影响检索质量。我试过固定每片500字也试过按段落切。地质灾害文档有个特点关键信息经常藏在表格和描述混合的段落里。比如一个勘查点记录前半段是岩性描述后半段是水文观测数据中间靠分号连着。固定长度切很容易把完整的记录从中间截断导致检索时发现不完整的内容。后来我改用按“灾害点记录”为粒度切一个记录就是一块保住了信息完整性。向量化的模型选择也不能随意。通用领域的向量模型对地质术语的理解有限测试时发现“残坡积物”和“崩坡积物”这两个概念在通用模型里距离很远但在实际工程里它们是经常并存的第四纪堆积物类型。后来换用针对科学文献训练的向量模型效果略有改善再配合关键词检索做混合召回才算达到可用的状态。3. 易发性分析中的LLM增强——从自动提取因子到智能辅助定权3.1 传统易发性分析的流程与局限先花点篇幅把易发性分析的原理讲清楚因为后面LLM介入的每个节点都与之相关。滑坡易发性分析的本质就是“过去发生灾害的地方有什么特征未来在相似特征的地方也可能发生”。基于这个假设技术流程分成四大步先确定评价单元要么用栅格单元要么用斜坡单元再在每个单元上提取一系列影响因子也就是变量然后通过某种方法确定各因子的权重最后把所有因子的加权结果汇总得到易发性指数并分级。因子提取这一步GIS软件可以完成大部分工作。坡度、坡向、曲率、地形湿度指数这些都能从DEM算出来岩性可以从地质图赋值距断层距离用缓冲区分析实现植被覆盖度用遥感指数反演。这一步本身技术成熟问题是成果数据的质量检查。我见过有项目在提取坡度时部分区域因为DEM原始数据有噪声出现明显异常大坡这种隐藏错误直到最后分区图出来才被发现返工成本很高。权重确定这一步是最有争议的。层次分析法靠专家打分优点是过程透明、可以解释缺点是不同的专家意见可能冲突逻辑回归和随机森林靠统计学习优点是客观缺点是因子间的物理机制不明容易出现“假相关”——比如某个因子在样本里碰巧和灾害分布相关但实际没有因果意义。这两种路线各有弊端LLM的介入思路是在两者之间找一个平衡。3.2 LLM辅助构造层次分析法的判断矩阵层次分析法的核心是判断矩阵。专家要回答“相对于影响滑坡易发性坡度和岩性哪个更重要重要多少”答案用1到9的标度表示。判断矩阵填完之后计算最大特征值对应的特征向量归一化就是各因子的权重再算一致性指标不合格要回头修改矩阵。过去这个过程最耗时的不是计算而是专家之间反复协调填矩阵。一个项目要评9个因子两两比较是36次判断每次都要讨论半天。而且填完之后若一致性检验过不了又要全体返工找哪两个判断不协调。用LLM辅助的做法是把因子的物理含义、区域内灾害与因子的统计关系、历史项目中的常见比选意见整理成一份上下文让LLM基于这些信息生成一版初始判断矩阵。我实测效果的一个例子是这样的。在模拟项目X中研究区是某西部山区典型灾种是降雨型浅层滑坡。我提供给LLM的关键背景包括该区域滑坡多发生在坡度为25到40度的地带岩性以易风化的砂泥岩互层为主灾害前兆与前期有效降雨量高度相关。LLM据此生成的判断矩阵给“坡度”“岩性”“降雨”赋予了较高权重而给“坡向”“曲率”较低权重这和该区域既有的专家判断基本一致。更重要的是LLM在输出矩阵的同时会附上理由说明比如“在坡度较陡的砂泥岩互层地带重力作用叠加风化作用显著降低了坡体稳定性因此坡度与岩性权重应高于地形湿度指数。”这些理由直接可以作为报告里的权重依据段落比过去评审时干巴巴一句“依据专家经验”有说服力得多。值得强调的是LLM生成的初始矩阵不是最终答案它是给专家一个讨论基础。我现在的标准流程是LLM生成初始矩阵专家审查并调整个别判断再进行一致性校验。结果发现专家审查一份矩阵的时间从过去半天缩短到半小时因为大部分判断已经是合理的专家只需要关注那些确实存在争议的少数项。3.3 自动化文本生成让易发性分区成果可直接应用权重确定之后GIS里把各因子加权叠加得到全区域的易发性指数栅格再按分位数或自然间断点法划为四级低易发、中易发、高易发、极高易发。这个步骤本身很快但接下来的报告撰写又是苦活。常规报告里对每个易发性分区要有一段特征描述包括分布范围、面积占比、典型灾害点数量、主要控制因子。这些描述过去要么从统计数据硬编要么技术人员手工总结。我用LLM自动化生成之后流程是先把分区统计表喂给模型再提供该区域的地质背景摘要让它按模板生成各分区的文字描述。这里有个关键技巧给LLM的结构化数据必须足够详细否则生成内容会流于空泛。我通常给每个分区提供以下数据面积、灾害点数量与密度、主要岩性组合、平均坡度、降雨区间、以及区内典型灾点的一些具体描述。数据充分时LLM生成的内容质量相当高。举一段示例“高易发区主要分布于该流域中上游面积约占全区30%区内密集发育砂泥岩互层边坡平均坡度32°历史灾害点密度是全区平均值的2.3倍典型灾点如某村滑坡即位于此类地层与坡度组合条件下因而该分区应作为群测群防的重点区域。”这种报告文字评审专家看了也会点头。还有一个附带的好处。用统计表驱动生成之后一旦我们修正了某个因子的权重导致分区边界变化重新运行生成脚本全新的分区描述马上就能产出不需要技术人员再去逐字修改。这种“改数据就能刷新报告”的体验在过去是想都不敢想的。4. 风险评估与灾后重建中的LLM落地实践4.1 从易发性到风险LLM动态整合承灾体信息易发性只回答“哪里容易发生灾害”风险评估还要回答“发生了会影响到什么”。两者的区别在于承灾体。一个有滑坡易发但荒无人烟的山区实际风险可能低于一个易发性中等但人口密集的城镇边缘地带。传统风险估算公式是风险 危险性 × 暴露性 × 脆弱性。危害性可以由易发性加上触发概率来估计暴露性和脆弱性涉及承灾体的空间位置、数量、类型和抗灾能力。这部分数据的获取同样有不少非结构化信息。村子里的房屋结构、年代、是否处于地质灾害隐患点影响范围、转移路线是否通畅这些信息分散在现场调查记录里。用LLM处理这些信息有一个非常实用的场景把现场调查记录自动解析成承灾体数据库。我参与过的一个模拟项目里现场调查员在移动端填写的记录很随意“某某组一户砖混结构平房房后边坡有两米高裂缝雨季屋内渗水”。这种记录包含承灾体位置、结构类型、风险信息但格式松散。用LLM按”建筑结构、建筑年代、与灾害体位置关系、现有防护措施、风险等级初判“五个字段抽取后几百条记录直接落库后续跟基础地理数据叠加就能在GIS里画出承灾体风险分布图。LLM还能动态更新风险评估。汛期之前拿到最新的降雨预报数据把高风险区域未来72小时的极端降雨概率、在册隐患点的稳定性现状、承灾体的转移准备情况整合起来用LLM生成一份“汛期风险动态提示”哪些隐患点在强降雨条件下需要重点防范哪些区域的居民需要提前做好转移准备。这种报告时效性要求高、信息维度多人员手工撰写通常要几个小时LLM在数据齐备的情况下十几分钟就能成稿而且可以每天滚动更新。4.2 灾后快速评估文本信息抽取与智能分诊灾害发生后的黄金24小时核心任务是快速判断“哪里灾情最重、哪里需要最先救援”。但信息来得混乱——电话报告、无人机影像快报、社交媒体上的现场照片描述、乡镇上报的初查统计格式各异且经常互相矛盾。LLM在这里的角色是做一个“灾情信息分诊器”。把所有渠道涌入的灾情文本按位置、灾种、规模、影响对象、紧迫程度五个维度抽取然后按预先定义的规则分诊排序。举个例子一条文本说“某村口上方山体滑塌约200方堵塞村道两户村民受影响”抽取后得到位置、估算方量、道路中断信息、影响户数系统自动判定为“中等级别响应需尽快疏通道路并评估两户是否需要转移”。这个分诊过程的关键在于判定规则要透明。我会把分诊规则写成显式逻辑LLM只负责抽取结构化和初步分级最终调度指令由规则引擎根据分级结果触发。比如灾情等级达到“特重大”才直接触发应急响应流程中等只推送预警给值班人员。这样既利用了LLM的语义理解能力又避免了模型在决策链路中引入不可控因素。无人机影像解译是另一个可以结合的环节。现成的目标检测模型可以从影像中识别出滑坡体、崩塌堆积物、受损房屋但检测结果只是带边界框的要素图层。这些要素对应的具体描述、可能导致的结果、需要采取的措施依然需要生成文本。我实践下来的方案是目标检测模型输出要素清单LLM把这些要素结合地名和周边承灾体信息生成灾情快报段落。快报可以直接发给前线指挥人员不用再人工写。4.3 灾后重建中的多技术融合与LLM辅助决策灾后重建不是简单“把坏掉的路修好”而是涉及到选址安全评估、重建优先级排序、建材与资金调配、居民安置方案等多个决策维度。数据更加复杂决策窗口相对宽松这给了LLM发挥比较大空间。选址安全评估是一个刚需。重建选址要避开原灾害影响范围、评价新址的易发性等级。这个过程的技术链路是候选地块提取 → 易发性信息叠加 → 周边灾害影响范围查询 → 生成评估意见。LLM在这里的作用是整合最后一步之前的检索结果把GIS的定量数据和区域地质背景知识结合起来输出一个包含风险判断和依据说明的评估意见草稿不建议在某地块布置集中安置点理由是它位于原滑坡堆积区前缘且该位置的历史灾点密度较高。工程师拿到草稿后结合现场情况复核即可。重建优先级排序可以用LLM做辅助。输入是各乡镇上报的受损清单、人口分布、设施重要程度学校、医院、主干道路优先输出是一个建议排序表同时附上排序理由。我做过一轮测试LLM给出的排序逻辑和一个有经验的规划人员手工排的结果重合度超过八成而耗时只有手工方式的零头。专家只需要审查那两成有争议的决策。多技术融合的最终落脚点是信息集成平台。我在项目的后期倾向于把所有数据接入一个统一接口LLM可以通过工具调用读取GIS服务的数据、查询数据库里的灾情记录、调用计算脚本分析易发性然后用对话的方式回答指挥人员的问题。“某区域的重建进度如何存在哪些风险点下周降雨对施工有什么影响”这种问题在过去要查多个系统、翻多份报告才能回答现在对话式助手直接把相关数据汇总起来回答给出的结论还可以追查到原始数据来源。5. 常见问题与排查技巧实录5.1 LLM输出“胡说八道”怎么办——幻觉治理的实用手段用到LLM的项目最怕的就是模型一本正经地说出错误结论尤其是在防灾这种涉及人身安全的领域。我在实践中摸索出了一套分层治理的办法。温度参数直接调低。做抽取和判断类任务时温度建议设置在0.1到0.2区间让模型输出更确定、更保守。生成报告描述时温度可以适度提高但也别超过0.5过高容易编造数据。结构化输出约束最关键。我前面提到过所有抽取任务都要限定输出JSON格式、枚举值范围这等于给模型的输出加上了一个“保险丝”。哪怕模型理解有偏差输出的范围也在可控之内畸形数据可以通过校验及时发现。最有效的一招是引用溯源。要求LLM在生成结论时给出依据来源“上述结论基于对某村滑坡点记录的分析该记录显示......”当内容能追溯到具体数据条目时人为编造的空间就小很多。这个方法在灾后快速评估场景里尤其重要指挥员看到结论时能直接知道背后的依据。RAG也能显著降低幻觉。凡是需要事实型回答的场景都先检索知识库再把检索到的内容作为上下文交给LLM。它只能基于检索到的材料组织答案知识库里没有的东西它没有足够空间瞎编。实测下来同一个模型在开放提问模式下的错误率远高于RAG模式下。5.2 数据稀疏区域的冷启动问题地质灾害数据分布极不均匀。有的县市资料齐全有的地方连一份完整的地质灾害普查报告都拿不出来。LLM在地形因子提取等数据丰富场景表现不错数据稀疏时效果会大打折扣。我的经验是分两手抓。一手抓“迁移外推”从地理环境相近、资料完善的邻区把灾害发育规律、易发性因子分布特征作为知识迁移过来让LLM在生成评估结论时参考这些“相似案例”。注意这只是一个参考方向最终结论必须结合当地实际的有限数据进行校准不能让外推知识反客为主。另一手抓“专家兜底”数据严重不足时把LLM的角色从“自动判断”降级为“助手整理”。它负责把零散的信息整理成结构化清单标注出哪些数据缺失、哪些存在矛盾交给专家组人工作出判断。这种模式下LLM不是替代人而是帮人把决策需要的材料准备得更清晰。5.3 数字计算的结果不对——明确分工才能根治必须反复强调大语言模型本质上是语言模型它的内部表征并不适合做多位数精确计算、大矩阵特征值求解、空间栅格分析。如果指望它直接算出坡度权重合成后的易发性指数结果一定令人失望。正确的分工方式是LLM负责生成计算所需的输入文件与参数传统计算工具负责实际计算。比如LLM输出层次分析法的判断矩阵然后调用科学计算库去计算权重和一致性比率LLM提取灾害点坐标然后由GIS做核密度分析或近邻分析LLM生成报告中的描述性文字其中涉及的面积、占比、统计量全部来自预先计算好的统计表。一句话文字归LLM数字归计算工具。5.4 算力与成本的工程化考量大语言模型的调用成本在项目级应用中是一个绕不开的话题。跑一整个县级的风险评估光灾点文本抽取就有几十万token的输入如果全部用付费商业接口费用不小。实际操作中的省钱策略有几条。优先用小模型处理简单任务。灾点文本抽取这类任务规模较小的开源模型微调后完全能胜任成本只有大模型的一个零头。复杂任务再用大模型也不迟。层级化调用先小模型跑一遍置信度低的样本才升级到大模型二次处理。批量缓存同一批文本的特征相似时可以合并成较长的上下文一次处理减少重复调用。开源模型的选择也要考虑部署环境。很多地质灾害管理单位的机房只有普通的GPU服务器跑得动7B到13B量级的开源模型再大的模型推理延迟就接受不了了。我测试过几个开源模型在地质文本抽取任务上的表现确实有差距但通过提示词优化和Schema约束可以达到接近大型商业模型的使用水平。关键是评估清楚每类任务的底线质量要求再选择对应的模型。最后再分享几条个人经验先交代一句上面提到的所有具体方法都是我在模拟项目和实际生产中反复验证过的但我并不主张一套方案包打天下。地质灾害的空间差异性太大某区域的规律搬到另一个区域水土不服的情况非常常见。LLM在这里更像是把“适配”这个过程的效率提升了它并不能消除对当地地质背景理解的需求。我实际操作中最大的体会是引入LLM后的流程改造有一个节奏问题。不要想着一步到位全流程自动化。最稳妥的做法是先从单个耗时最长的环节入手比如文本结构化抽取跑顺了、效果稳定了再扩展到权重辅助生成最后才是灾后重建这类复杂决策场景。每一步都让使用人员亲眼看到效率提升项目推动起来阻力就小。还有一个很多技术人容易忽略的点LLM产出的成果必须有人的审核节点。我的标准是LLM做初稿、人做复核、复核结果再反馈回系统作为优化样本。这样一个循环下来模型会越来越贴合本地的数据特征和表达习惯形成正向迭代。不建立这个反馈闭环模型的输出质量很容易在某个水平上停滞。最后想说的是技术工具本身的价值最终还是取决于用的人对这个行业的理解深度。LLM在灾害防治这条赛道上前景广阔但前提是我们始终记住最终目标是什么让风险识别更及时、让决策依据更扎实、让有限的防治资源花在最需要的地方。顺着这个目标走多尝试、多验证、多复盘自然能走出一条合适的路。
阅读完成 · 觉得有帮助？
