简介该PDF方案面向地质勘探研究人员、工程师及技术管理人员提供一套基于AI大模型的语料清洗与标注应用思路重点解决勘探数据质量不高、标注标准不统一等影响模型训练效果的问题。资源为单个PDF文件大小约940KB文档结构完整涵盖项目背景与目标、数据源选择与收集方法、清洗目的与筛选标准、噪声识别与去重算法、标注类别定义与工具平台、人员培训管理以及模型训练与应用建议等模块。目前已有79人学习下载。读者可依据文中具体流程掌握数据精度要求、相关性分析、常见噪声类型及识别算法、去重工具选择、地质层位/矿体特征/结构特征等标注类别的设定方式并了解初始标注、验证修正、最终审核的完整标注流程同时方案还提供了AI大模型用于地质预测、资源评估、自动化报告生成的场景建议对构建智能化地质勘探系统具有实际参考价值。1. 为什么地质勘探语料清洗和标注非得上AI大模型这一趟有一类数据看起来全是文字用起来全是堵点——这就是地质勘探语料。岩心编录、测井解释记录、钻孔成果表、地质填图卡片几十年攒下来的报告从扫描件到数据库版本混乱、术语随意、深度单位不统一。要用它建地质知识库、做语义检索或训练模型时先得有一批人花几个月去读、去改、去圈选。AI大模型做地质勘探语料清洗和标注就是把这段最贵的人工前移大模型先跑清洗管线把OCR噪音、断裂句、单位乱象清完再按预定义的标签体系把岩性、地层、构造、深度和样品位置预标出来最后由人工做抽检修正。适合正在做地质数据治理的团队也适合刚接手这类文本项目的NLP工程师——目标不是一步到位而是把人工投入压缩到原来的三分之一以下。2. 地质语料清洗管线术语、深度、地层代号这三种脏数据怎么处理地质文本的“脏”和新闻、电商评论完全不是一回事。新闻文本主要脏在错别字和口语而地质报告脏在几个固定场景OCR把“灰岩”识别成“灰·岩”单位在“m”“米”“公尺”“M”之间混用地层代号的上下标字号在复制粘贴后直接退化成一串裸字符。更麻烦的是这一类文本里还夹着大量行业缩写不加区分地做通用清洗会把地层、岩矿、流体信息一并洗没。所以地质语料清洗不是拿一个现成的中文NLP清洗包跑一遍而是要切成四个层次来处理。2.1 清洗分四层走版面、字符、词形、语义第一层是版面清洗。扫描件和PDF提取出来的文本页眉页脚、图号说明、表格断裂是最常见的噪声源。比如一张柱状图表格被PDF解析成几段“左列右列互相穿插”的碎片直接进标注流程会让大模型把表头和岩性描述混在一起。这一层以删为主常见做法是按页码和文档结构先把表格区、正文区拆开再把页眉页脚的重复正则清掉。第二层是字符规范化。全角半角混用、中文引号残片、多余空格、单位缩写不统一都要在这一层解决。注意这里不要做“全角全部转半角”这种一刀切操作中文文本的全角标点属于正常书写转半角反而会让句子粘连。第三层是词形规整针对“石灰岩/灰岩/石灰石”“粗中粒砂岩/中粗粒砂岩”这类同义词和乱序词靠一个按地质手册整理出来的别名映射表去对齐。第四层是语义级规整处理的是“可能为灰岩、局部见方解石脉”这类带判断性质的描述后面第五节还会讲到这类句子不能只抽实体还要抽状态词。2.2 清洗代码示例单位统一、地层代号保护和断行合并先看一段我常用的清洗规则片段覆盖了字符层的核心逻辑import re # 单位别名 - 标准写法 UNIT_MAP { 公尺: m, 米: m, : m, # 全角m } def normalize_units(text: str) - str: for alias, std in UNIT_MAP.items(): text re.sub(rf(\d(?:\.\d)?)\s*{alias}, rf\1 {std}, text) return text # 地层代号保护C1t(下石炭统土门组)、J2x(中侏罗统象山群) STRAT_RE re.compile(r\b[CJKNOPST][0-4]?[a-z]?\b) def protect_strat(text: str): placeholders {} def _replace(m): key f__STRAT_{len(placeholders)}__ placeholders[key] m.group(0) return key return STRAT_RE.sub(_replace, text), placeholders def restore_strat(text: str, placeholders: dict) - str: for key, val in placeholders.items(): text text.replace(key, val) return text # 断行合并上一行没有结尾标点下一行以数字开头通常还在同一句 def join_broken_lines(paragraph: str) - str: lines paragraph.splitlines() out, buf [], for ln in lines: ln ln.strip() if not ln: continue if not buf: buf ln elif re.search(r[。;!?]$, buf): out.append(buf) buf ln elif re.match(r^(深度|岩性|取样|孔深), ln): out.append(buf) buf ln else: buf ln if buf: out.append(buf) return \n.join(out)这段代码里最值得留意的是protect_strat这个函数。地质报告里的“C1t”是下石炭统土门组的代号其中 C 是石炭系首字母1 表示统级t 是组名的拼音首字母。后续清洗如果做了小写化、删短词、去数字都会把这个代号拆坏。所以先把它替换成__STRAT_0__这样的占位符等全部清洗结束再换回来。正则里的[CJKNOPST]覆盖石炭系、侏罗系、白垩系、新近系、奥陶系、二叠系、志留系、三叠系的英文代号[0-4]?[a-z]?匹配统号和组名后缀。这个模式的漏洞是可能误匹配英文缩写或某些量词所以上线前先拿一批真实报告跑一遍统计误保护率。normalize_units看起来简单但它处理的才是真正折磨人的部分。老报告里“320.5米”“320.5m”“320.5公尺”“320.5”都有可能出现不统一成“320.5 m”后续深度区间标注和数据库导入都会出问题。join_broken_lines则解决OCR断行——PDF提取出的段落经常在“320.5~”后面直接换行下一行开头接“342.8m”不做断行合并字段就碎成了两块。注意清洗规则上线后一定保留一份清洗前后的对齐报告方便排查哪一条规则误伤了哪种写法。规则调得越多越需要能回滚。2.3 什么该交给规则做什么该留给大模型常见误区是把整条清洗线都交给大模型。一个项目里要说“用AI大模型清洗”不是让大模型逐句翻译改写而是把大模型安排在规则引擎之后只处理规则搞不定的语义规整。规则适合处理高频、确定性强的问题全角半角、单位映射、页眉页脚、地层代号占位这些都是几十行正则就能解决的事用大模型反而慢、贵、还会引入新错。大模型适合做低频、需要上下文理解的活判断“花岗岩~闪长岩中粒”是不是跨域描述识别“可能为灰岩”里的不确定性把“深灰色泥岩夹薄层细砂岩”切分成合理的语义片段。我一般会把清洗管线设计成两层第一层全量跑正则规则第二层只对有问题的片段调大模型。怎么判断哪些片段有问题拿规则清洗完的文本跟原文做 diff凡是被删掉、改写的专业词都在召回清单里抽查一遍就知道规则的误伤率。这样大模型的实际调用量只有全文的百分之十到二十费用和时延都可控。地质语料里很多报告涉及保密要求本地部署一个7B量级的开源模型专门跑语义清洗也比每段文字都送到外部接口心里踏实得多。3. 用大模型做标注标签体系、预标注脚本和本地部署参数怎么定清洗完的地质文本下一步是标注。地质勘探语料的标注与通用的数据标注最大的不同在于标签体系里嵌套着行业逻辑。岩性、地层、地质年代、构造、深度区间、样品信息这些实体不是孤立存在的它们之间还有“位于”“包含”“控制”“取样”四类关系。比如“三叠系下统飞仙关组灰岩中发育一组 NE 向正断层”这里“三叠系下统飞仙关组”是地层“灰岩”是岩性“NE向正断层”是构造深层语义是断层发育在该地层中需要抽出实体也要抽出关系。只做实体标注不做关系标注下游建知识图谱时还得返工所以我建议第一版就把关系和实体一起做。3.1 标签体系怎么定稳住边界别一上来就贪多第一版标签体系建议控制在15个以内宁可粗标再精修也不要让标注员面对几十个标签犹犹豫豫。我常用的地质实体标签如下实体类型示例判定边界岩性石英砂岩、灰岩、含油水砂岩“含油、风化”这类修饰词单独标属性不并入岩性词根地层/层位太原组、C1t、J2x地层代号保留原文禁止展开成中文全称地质年代石炭纪、晚古生代与地层分开标不嵌套构造正断层、向斜、节理倾向、倾角放属性字段深度区间320.5-342.8m连续段用~统一缺终点的标存疑样品/实验薄片、光谱分析样采样位置和配号作为一个整体关系类型第一版只留四条位于岩性与地层、包含地层与构造、控制构造与岩性、取样样品与深度。关系太多会让标注工作量成倍上涨而且大模型对复杂关系的预测一致性会明显下降。等跑通一期拿真实标注数据看看哪类关系对下游最有用再加也不迟。3.2 预标注脚本Prompt约束、输出Schema和运行参数预标注阶段的任务是把无结构文本变成结构化JSON。我在脚本里会把标签体系直接写进Prompt并要求模型严格按JSON格式输出import json SCHEMA json.dumps({ entity_types: [岩性, 地层, 地质年代, 构造, 深度区间, 样品], relation_types: [位于, 包含, 控制, 取样], output_format: { entities: [ {type: 岩性, text: 灰岩, start_char: 12, end_char: 14} ], relations: [ {from: entities[0], to: entities[1], type: 位于} ], uncertainty: [推测, 可能, 局部] } }, ensure_asciiFalse) def build_prompt(text: str) - str: return ( 你是地质勘探语料标注助手。请从下面的钻孔编录文本中找出实体和实体间关系。\n f标签体系如下只按这个结构输出JSON\n{SCHEMA}\n 规则\n 1. 保留C1t、J2x这类地层代号原文不要展开中文全称\n 2. 必须保留‘推测、可能、局部、未见底’这类不确定性词\n 3. 深度单位统一为m缺单位的补‘m’并标记为存疑\n 4. 只输出JSON不要输出解释和Markdown代码块。\n f待标注文本\n{text} ) def parse_model_response(resp_text: str): # 兼容模型输出里带 json 代码块的情况 m re.search(rjson\s*(.?)\s*, resp_text, re.S) if m: resp_text m.group(1) return json.loads(resp_text)这个脚本里最关键的是两条一是“只输出JSON”写进了系统提示词二是parse_model_response对模型偶尔加的Markdown代码块做兼容。实际项目里我还会加一条结构化检查解析完JSON后校验实体类型是否在允许列表里不在就丢弃或标记为待人工确认而不是直接入库。运行参数方面我用的是保守一组temperature 0.2top_p 0.7max_tokens根据单段文本长度按2倍预估。温度设得过低会不会太机械对于标注任务一致性比创造性重要同一个实体出现十次就该被标成同一个结果温度高了做不到。如果接口支持JSON模式就直接开不支持也没关系靠Prompt约束加正则剥离也够用。硬件怎么配32G内存跑AI大模型完全可行。一个7B量级的Q4量化模型内存占用大约5到7GCPU推理一条300字的编录段落在十几秒到几十秒之间项目初期验证完全够用。真正要小心的是并发32G内存如果同时挤压十几个推理请求操作系统开始换页单条推理时间会从几秒级崩到几十秒级体验会变得很差。有GPU的话按显存选8G显存跑14B量化模型24G显存跑34B以上标注质量会明显好一截因为大模型对长文本的专业术语上下文理解更强。3.3 标注工具怎么选doccano、CVAT还是自建界面大模型预标注的结果总需要人工审核这时标注工具就是生产力。文本标注我一般看doccano序列标注和关系标注都能做前后端界面简单数据导入导出格式可控适合几十万字的项目。但doccano在某些版本上处理关系标注的导入导出有兼容性问题建议在正式开工前先拿三到五条数据全流程试跑一遍确认往返数据没丢再批量导入。CVAT则偏图像和视频标注遥感图像标注、岩心照片的像元分割这类任务常用它但用CVAT做地质文本字段标注就很别扭。如果项目同时有岩心影像和编录文本最好分开影像交给CVAT文本交给doccano不要试图在一个工具里解决所有事。第三种选择是自建一个带登录界面的字段级审核表单导出格式完全可控但开发有一定工作量适合长期大批量生产环境。选型时还要考虑一个问题预标注脚本产出的JSON能不能直接导入所选工具。doccano支持JSONL导入只要把模型输出的entities和relations展开成对应行的标签就行。3.4 人机协同闭环置信度过滤、人工抽检和榜单修正预标注结果不能直接交付。我一般会把置信度低于0.7的实体挑出来单独生成一份“待确认清单”。人工在这个清单上做二分类保留或修正。修正的结果不是改完就完事而是回填到Few-shot示例库里下一轮的预标注Prompt会带上这些样例模型的输出质量会随着迭代稳步提升。自动循环之后还要设计抽检机制。常见做法是按标签类型分层抽样岩性这类高频标签抽5%到10%构造和样品这类低频但风险高的标签抽50%。抽检不是为了看正确率而是为了找出大模型在哪些上下文里稳定犯错。比如发现模型总是把构造产状“NE向”漏标就把这个规律写进Prompt的规则4里比盲目调temperature有用得多。这个流程走下来一组人工标注员一天能处理的文本量大约是从前纯手标的四到六倍。4. 避坑地质语料清洗和标注中5个高频翻车现场前面讲的都是正向管线接下来是这几条最花钱的坑。每个坑都是项目里真实发生过的现象写得具体一点你拿自己的数据跑一遍就能对照出来。4.1 停用词表一口气把“水”洗没了含油水砂岩只剩“砂岩”现象清洗管线上接了一个通用NLP停用词表“的、了、和、及、水、层”全被删了。项目验收时发现“含油水砂岩”被清洗成“含油砂岩”“含水层”直接变成“”。原因通用停用词表是按通用文本语料统计出来的高频无义词“水”在新闻里是常字在地质报告里是流体标志。解决地质管线不要用通用停用词表自己维护一份极简停用列表只清理“的、了、和、及、与、或”这类真正无干扰的词。同时建一个业务白名单含水、含油、含气、油水界面、注水层这些词在清洗时禁止被拆开。上线前用一个高频专业词典跑一遍清洗前后的召回术语缺失率超过1%先停手查规则。4.2 地层代号被“规范化”成乱码C1t变成“下石炭统”现象原文里的“C1t、C2b、P1q”这些地层代号清洗后有的消失有的被展开成“下石炭统”“上石炭统”。模型在预标注时面对展开后的中文全称还能工作但原本的代号结构信息丢了后期做地层对比时两套写法对不上极难追回。原因清洗脚本里有一条“删除连续两到三个字符内混合自变量”的规则把短代号当乱码删了另一个原因是不少归一化规则把“C1t”这种短token当成模型噪音。解决清洗前用protect_strat这类正则把地层代号全部占位清洗结束后再恢复。标注Prompt里还要显式写“保留地层代号原文不要展开成中文全称”两条线都堵住才不会再犯。4.3 深度区间跨行被切碎342.8m离奇失踪现象抽取出来的结构化数据里深度字段只有起点“320.5”没有终点“342.8”。检查原文才发现PDF解析把“320.5~ 342.8m”在“~”后面断行了下一行开头是“342.8m”按行切分时这一截被拼到了后面的岩性描述里。原因字段切分脚本按行处理没有做跨行上下文合并。解决在切分前先跑一遍join_broken_lines只要上行以“~、-、至”结尾无论下行什么开头都强制拼回来。同时在做深度区间提取时用一条固定模式(\d(?:\.\d)?)\s*[~至-]\s*(\d(?:\.\d)?)\s*(m)一次性匹配起止深度而不是分成两次找数字。统一符号这步能省掉后面大量数据清洗。4.4 大模型吞掉“可能”“推测”风险信息在预标注里消失现象原文写着“该段可能为断层碎裂岩推测走向NW30°”预标注结果里只剩“断层碎裂岩”没有存疑标记也没有“推测”这个词。原因生成模型天然倾向于输出通顺的确定性表述“可能”被当作冗余修饰词吞掉了。但在地质报告里“可能”和“推测”代表的是技术人员的判断直接抹掉会让后续的风险分析失去依据。解决在输出Schema里加uncertainty字段专门记录推断类修饰词Prompt规则里要求必须保留“推测、可能、局部、风化强烈、破碎、未见底”这类状态词。这一条如果早期不处理训练出的模型会把整批不确定性信息学成“确定”再想纠正就要重新标注。4.5 预标注覆盖率98%人工抽检准确率只有六成现象中期汇报里用“实体有没有被标出”作为覆盖率指标显示98%。结果人工抽检200条严格按实体边界比对准确率只有61%。“灰质砂岩”被标记成“砂岩”这类边界漂移占了大半错误。原因机器自动标注覆盖率高是因为宽容匹配把所有带交集的结果都算成了命中“灰质”两个字漏掉但“砂岩”标上了宽松口径就认为命中。解决汇报时同时给严格匹配和宽容匹配两套指标。严格匹配要求实体文本和边界一字不差宽容匹配允许带修饰词偏差两套指标差距大于15个百分点说明边界稳定性有问题。抽检时用Kappa系数计算人工复标和系统标注的一致性要求不小于0.8才算通过低于这个值就该回到Prompt和标签定义上找原因。5. 验证方法和复用习惯把清洗标注成果变成可积累的地质语料资产这条管线的产出不只是“一批标好的数据”。我会严格检查两件事清洗有没有伤到专业术语标注结果有没有让下游检索或知识图谱的收益真的变好。术语召回率是清洗质量的第一个可量化指标拿地质词典和同义词表去回扫清洗前后的语料术语命中率下降超过1个百分点规则就要回滚。标注质量则看抽检集合上的严格/宽容准确率再加上人机一致性Kappa。跑完这两个验证再拿标好的JSONL数据去测试知识图谱的实体链接准确率能过才说明这条线真正通了。第二个习惯是把清洗规则、保护词典、标注schema和修正记录沉淀成资产包。每个项目改过的正则、补进白名单的术语、模型反复出错的上下文样例都分门别类归档。现在换一个开源大模型、调一次部署配置靠着这套资产包不需要从头再标一遍语料就能快速迁移到新模型上跑预标注。我自己也吃过亏——调清洗规则的时候不留版本记录两个月后再看到自己写的正则完全想不通为什么要那样写。从那以后每次改规则都会提交一份变更说明标注产出和修正记录一起进版本库。一个应用方案值不值得做就看这套清洗标注的资产在第二个项目上还能不能直接用能就是赚了不能就是白干。希望帮到你。本文还有配套的精品资源点击获取