大语言模型在地质灾害防治中的实战应用：从数据抽取到风险评估-育师

项目标题里那串长长的修饰词确实容易让人望而生畏，但拆开看，它其实就讲了一件事：怎么把过去靠专家拍脑袋、翻文献、熬夜写报告的地质灾害防治流程，用大语言模型重做一遍。

地质灾害防治这个领域，我断断续续接触了六七年。以前做一个县级的滑坡易发性分区，光整理历史灾害点、提取地形因子、构造判断矩阵就得耗掉两三周，中间还要反复跟地质专家核对打分逻辑。这两年大语言模型火起来之后，我第一次尝试用它去解析灾害点档案里的文字描述，十分钟整理出几百条结构化样本，那个冲击感到现在还记得。

这文章我就按自己实际走过的路子来写。如果你手里正好有地质灾害项目，或者想用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(text=record_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约束，可以达到接近大型商业模型的使用水平。关键是评估清楚每类任务的底线质量要求，再选择对应的模型。