简介面向地质勘探研究人员、工程师与技术管理者的完整方案文档系统讲解AI大模型在勘探语料清洗与标注中的落地路径。全篇围绕高质量语料建设展开从项目背景、目标与适用范围写起细化数据源选择与网络爬虫、数据库检索、现场调查等收集方法再依次给出语料清洗目的、精度相关性筛选、噪声识别及去重算法并介绍地质层位、矿体特征、结构特征等标注类别与标注工具、流程设计。内容还延伸至人员培训考核、数据存储管理、模型选择优化与智能应用场景最终讨论实施计划、风险管理和未来展望可帮助读者建立从语料治理到智能预测、资源评估及自动化报告生成的闭环实施框架。包体为单个PDF文件压缩包约940KB目录结构清晰便于按章节查阅。目前已有78人学习下载适合需要落地地质数据治理与AI建模应用的从业者参考。1. AI大模型做地质勘探语料清洗和标注要过的第一关不是模型参数AI大模型做地质勘探语料清洗和标注要过的第一关不是模型参数而是语料本身的物理状态。钻孔编录里的深度区间和岩性描述可能挤在同一行化验单里的“Cu”和“0.32%”隔着一整页表格内容扫描质量差的老报告连“凝灰质熔结凝灰岩”这种长词都会被OCR切碎。数据量大起来后全人工清洗意味着一个矿区项目的文本整理要耗掉工程师几周时间最终交付给检索和建模的数据质量仍然不稳定。解决思路不是让AI大模型替代地质专家而是把初筛、补全、规范、粗标这类高重复性工作交给模型再把抽样、判定和修正留给人。下面给出一条可落地的方案从PDF抽取文本开始经过AI大模型语料清洗再做实体和关系标注最后用最小金标准集验证全流程。整个过程数据不出内网模型走本地部署调用。2. 地质勘探语料的噪声来自哪里先给清洗和标注划定边界2.1 三种常见语料来源和它们各自的噪声特征从项目现场回来的原始语料一般可以归成三类。搞清楚你的语料属于哪一类就知道该把修复逻辑放在规则层还是放在大模型层。语料来源文件形态典型噪声清洗目标钻孔编录与柱状图PDF、Excel、机打表格OCR把长岩性词切断、深度区间和岩性描述粘连、页脚页码混入正文恢复成“钻孔号深度区间岩性描述”的段内结构化验分析报告PDF表格粘贴单位不统一、元素与品位错位、多行数据被拆成碎块统一单位恢复元素与品位的绑定物探与遥感解释文本Word段落、PDF方位词变体多、地层代号缺上下文、图形说明文字混入正文规范化方位术语保留地层代号上下文这类语料有一个共同特征局部字符错乱可以用规则修复但“这一段说的是哪个钻孔、哪一段岩心、属于什么构造”这类关联信息必须依赖上下文理解。这也是之后决定把清洗拆成两段——规则兜底和大模型理解——的根本原因。2.2 为什么纯规则管线在地质文本上走不通有些团队首版方案会走纯规则维护一堆正则把单位、错别字、特殊符号全部替换掉然后直接进标注。正则和词典的工时积累到一定程度就会发现地质语料中间义词和省略写法太多词典永远低一级。举两个真实语境。第一个是同义表达同一段描述里“褐铁矿化带”“Fe氧化物带”“褐铁带”出现的次数可能一样多。要把它们统一成同一个术语规则维护者得去读大量历史报告然后不断往词典里加条目。第二个是断行截断PDF抽取出来的文本里“深部见工业品位银铅”这种句子表面看是完整的实际上一句描述的是“工业品位银铅矿体”下一句才是走向。规则正则无法知道“银铅”的主语范围更无法补全省略的“矿体”两个字。这两个问题恰好是大模型擅长的。给足上下文模型能判断“银铅”是矿体还是矿物组合从而在清洗时做规范补全对不明确的句子它也能保持原样而不是强行改写。这里的关键是给模型设置好边界可以补全缺失的修饰语但不允许改动数值和矿种名。2.3 规则兜底与大模型理解的分工配置清洗流程我一般拆成规则层和大模型层两步。规则层只处理特征明确、低语义的操作去掉页眉页脚、压缩空白、修复字符集转码错误。大模型层负责需要语境的规范化OCR语义修复、单位统一、省略语补全。职责一旦切清楚清洗结果的可审可靠性就高得多。import re def rule_clean(text: str) - str: # 规则层只做低风险字符级清理不碰语义 text re.sub(r\s, , text) # 压缩连续空白 text re.sub(r页\s*眉[:].*?(?\n|$), , text) # 去掉页眉行 return text.strip() def llm_clean(text: str) - str: # 大模型层做语义规范化只接收规则层处理后的结果 return clean_segment(rule_clean(text))这里clean_segment是下一章要实现的清洗调用函数。规则层的改动都是确定性的出现问题可以回溯到具体替换规则大模型层的输出虽然不一定百分百稳定但通过降低请求温度和把任务限定在语义规范化上可以把风险控制在可审计的范围内。3. 大模型语料清洗的落地实现从PDF抽取到分块规范3.1 本地部署AI大模型的接口约定与选型建议地质报告通常要求数据不出内网所以首要选择是本地部署AI大模型。常见做法是用 vLLM 或 Ollama 拉起一个 7B 到 14B 参数量的开源模型单张 24 GB 显存以内的卡就能跑。服务起来之后业务代码只面向 OpenAI 兼容接口发请求不绑定任何厂商私有协议。vllm serve qwen2.5-14b-instruct \ --served-model-name qwen2.5-14b-instruct \ --port 8000--served-model-name要和你客户端里传的model参数保持一致否则请求会拿不到模型。启动后客户端配置如下from openai import OpenAI client OpenAI( api_keyEMPTY, base_urlhttp://127.0.0.1:8000/v1, # 本地模型服务的OpenAI兼容地址 ) model_name qwen2.5-14b-instruct # 替换为本地部署时的实际模型名这个client在后续清洗和标注代码里完全一致只会在 system prompt 和 temperature 参数上不同。如果你用的是云端模型把base_url换成内部网关地址即可业务代码不需要改第二处。选型时我一般不看榜单而是拿项目里最有代表性的五十段乱码文本去试跑。重点观察两件事一是对“凝灰质熔结凝灰岩”这类长岩性词的OCR纠错效果二是对单位混用场景的归一化稳定性。如果是老扫描件中文乱码比例高我会选中文语料占比更好的模型如果只做标注7B 模型低温就够用没必要上大参数量。3.2 清洗提示词与批量调用代码清洗从PDF抽取开始。我用 PyMuPDF 的纯文本模式抽取文字层并把每一页的文字按顺序拼回来。扫描版 PDF 没有文字层需要先做 OCR这一般是独立的前置流程不影响清洗代码的逻辑。import fitz def extract_pdf_text(pdf_path: str) - str: 把PDF全文抽成纯文本 doc fitz.open(pdf_path) parts [] try: for page in doc: parts.append(page.get_text(text)) finally: doc.close() return \n.join(parts).strip()清洗提示词要明确写出不让模型做的事否则模型会出现两种典型问题一是顺手把“0.32%”改成“0.32”这种格式整理之外的数值调整二是给输出加一段解释性语言导致下游解析失败。我在系统提示词里把约束写成硬性要求CLEAN_SYSTEM_PROMPT 你是地质勘探语料清洗助手。 用户输入是地质报告原始文本段可能包含OCR识别错误、断行、单位不统一等问题。 请输出清洗后的纯文本要求 1. 修复明显的OCR错误包括错字和缺字 2. 将单位统一为中文规范写法米、克/吨、% 3. 不改变或虚构任何数值、矿种和岩石名称 4. 不要输出解释、前缀或Markdown标记。 def clean_segment(segment: str) - str: resp client.chat.completions.create( modelmodel_name, messages[ {role: system, content: CLEAN_SYSTEM_PROMPT}, {role: user, content: segment}, ], temperature0.1, max_tokens2048, ) return resp.choices[0].message.content.strip()temperature 设成 0.1 是有意的清洗需要模型对语序和错字做一些纠错完全零温度又会限制纠错能力温度太高则输出会抖。对纯单位统一类任务可以直接用 temperature0。max_tokens 要保证足够覆盖清洗后的文本长度防止长段落被截断如果发现经常截断优先缩小分块尺寸而不是调大 max_tokens。批量清洗时每个清洗结果按原文档名加分块序号存成 jsonl 文件。这样即使某一段请求超时后续恢复时只需要重跑失败分块不需要重新处理整个文档。3.3 长报告的分块策略、参数与重试地质报告长度从几十页到几百页不等一次性送入模型既不现实效果也会随上下文变长而下降。分块要同时考虑模型上下文窗口和显存占用。我一般用字符数加句末对齐的方式在上下块之间保留重叠窗口def split_text(text: str, chunk_size: int 1200, overlap: int 150): 按字符数切块句号处对齐重叠窗口保留前后文。 chunk_size 越大单次查询携带的信息越多 overlap 越大跨块上下文越完整但总查询次数也越多。 chunks [] start 0 n len(text) while start n: end min(start chunk_size, n) if end n: pos text.rfind(。, start chunk_size // 2, end) if pos ! -1: end pos 1 chunks.append(text[start:end]) if end n: break start max(end - overlap, start) if start end: break return chunks为什么是 1200 字符对 14B 模型来说这是一次请求比较舒适的上下文长度批量并发时显存压力也可控。为什么需要 150 字符重叠地质语料的主语经常跨句延续重叠窗口能让上一块的尾部信息出现在下一块的开头避免“矿体”和“走向”被切到两块。如果你的语料大量来自化验单粘贴块长可以降到 800因为表格噪声密度高模型需要在更短的文本内集中注意力。批量调用时务必处理两类异常连接超时和返回内容解析失败。捕获异常后对同一分块重试 3 次仍失败就把分块标记为“待人工处理”并在日志里记录其在原文的起止偏移量方便后续定位到 PDF 对应页面。4. 地质语料标注方案实体关系Schema、JSON输出与质量校验4.1 用七类实体和五类关系建标注Schema标注的第一步不是写提示词而是先定义清楚要收集哪些信息。标注字段一旦定错后面洗数据、训练模型、建知识库都会被带偏。对地质勘探文本我把实体压缩成七个类型关系压缩成五个类型这样模型输出 JSON 时不需要做复杂选择稳定性会高很多。实体类型代码实例钻孔编号BOREHOLEZK8、ZK12-3深度区间DEPTH12.5~15.2m0.8m岩石类型ROCK辉绿岩、灰岩、凝灰岩矿物名称MINERAL黄铁矿、方铅矿、闪锌矿方位描述DIRECTION北西向、NNW元素符号ELEMENTCu、Zn、Au品位值GRADE0.32%、2.1g/t关系类型同样要收窄常见的地质语义可以归成五类关系类型主语类型宾语类型对应句子borehole_rockBOREHOLEROCKZK8见辉绿岩depth_rockDEPTHROCK12.5~15.2m见辉绿岩rock_mineralROCKMINERAL辉绿岩含黄铁矿element_gradeELEMENTGRADECu品位0.32%direction_rockDIRECTIONROCK岩体北西向展布这样定义需要注意一点不要试图把每一个语义关系都建模。比如“品位值属于 Cu 又属于黄铁矿”这种二义性如果全部建模模型的输出稳定性会明显下降。五大关系之外的细节可以留给清洗后的整段文本后续做检索时依然能搜到。4.2 用结构化输出约束大模型返回JSON格式模型返回的标注结果必须严格符合一个 JSON 结构否则下游解析和质检都会变困难。标注提示词里我会把实体类型、关系类型、输出样例全部写清楚并指定 start/end 用 Python 字符串偏移计算ANNOTATION_PROMPT 你是地质勘探语料标注助手。 判断用户段落中的实体实体类型限定为 BOREHOLE、DEPTH、ROCK、MINERAL、DIRECTION、ELEMENT、GRADE。 并判断实体间关系关系类型限定为 borehole_rock、depth_rock、rock_mineral、element_grade、direction_rock。 输出JSON不输出其他内容 { entities: [ {text: ZK8, type: BOREHOLE, start: 0, end: 3}, {text: 12.5~15.2m, type: DEPTH, start: 5, end: 15} ], relations: [ {source: ZK8, source_type: BOREHOLE, target: 辉绿岩, target_type: ROCK, relation: borehole_rock} ] } 注意start和end是Python字符串偏移中文按1个字符计算。 def annotate(segment: str): resp client.chat.completions.create( modelmodel_name, messages[ {role: system, content: ANNOTATION_PROMPT}, {role: user, content: segment}, ], temperature0.0, response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content)这里有两处参数值得说明。第一temperature0.0 是标注任务的标配。清洗可以接受 0.1 的灵活性但实体边界和关系类型一旦改来改去后面的去重、质量统计都不知道以哪个版本为准。第二response_format 是否可用取决于本地服务后端vLLM 新版本一般都支持Ollama 的兼容层不一定支持不支持的话就在解析层加一道校验解析失败的输出进失败队列交给人工而不是程序去改。4.3 质检闭环双模型一致性、数据标注工具回填与人工修正标注不是让模型跑一遍就坐收结果。大模型在同一段文字上最常犯的错误是实体边界偏移比如把“12.5~15.2m”误标成“12.5”把“北西向”和“灰岩接触带”错误合并成一个关系。这类错误单看一次输出很难发现抽样看多了才能看出规律。实际操作中我先用双模型交叉做初步质检用两个模型分别跑同一批语料对比它们实体集合的叠合度。叠合度高说明标注稳定叠合度低说明该段进入人工复核区。一致率计算用交并比即可def consistency_ratio(r1, r2): set1 {(e[text], e[type], e[start]) for e in r1[entities]} set2 {(e[text], e[type], e[start]) for e in r2[entities]} union set1 | set2 return len(set1 set2) / len(union) if union else 1.0跑全量分块时把每条结果的一致率算出来低于阈值就自动筛选for i, (a, b) in enumerate(zip(resp_a, resp_b)): r consistency_ratio(a, b) if r 0.6: print(f分块 {i} 双模型一致率过低需要人工复核)这里 0.6 不是一个普适阈值先跑一轮看分布再按项目对数据质量的容忍度调整。人工修正建议交给界面型标注工具。地质项目如果涉及岩心照片或遥感影像的框选才走 CVAT、Labelme 这类视觉标注链路文本语料标注更适合用 Label Studio 这类支持实体和关系类型的界面把 JSON 导入后逐条修正偏移再回填数据集实现把人从全量标注压到只看分歧样本的质检闭环。5. 收尾技巧用最小金标准集验证清洗标注全流程5.1 金标准集设计与指标计算金标准集不需要大但覆盖面要全。五类关系各至少出现一次七类实体各至少出现一次外加一段公认难例验证模型补全能力。这里用一段典型钻孔描述当示例ZK8孔12.5~15.2m见辉绿岩含黄铁矿、方铅矿Cu品位0.32%。 岩体北西向展布与围岩灰岩接触带见硅化蚀变。 深部见闪锌矿化Au品位2.1g/t。人工为这段写好实体集合和模型输出做比较def evaluate(pred_entities): gold { (ZK8, BOREHOLE), (12.5~15.2m, DEPTH), (辉绿岩, ROCK), (黄铁矿, MINERAL), (方铅矿, MINERAL), (Cu, ELEMENT), (0.32%, GRADE), (北西向, DIRECTION), (灰岩, ROCK), (Au, ELEMENT), (2.1g/t, GRADE), } pred {(e[text], e[type]) for e in pred_entities} correct len(pred gold) precision correct / len(pred) if pred else 0 recall correct / len(gold) f1 2 * precision * recall / (precision recall) \ if (precision recall) else 0 return {precision: precision, recall: recall, f1: f1}提示实体在对比之前先做规范化。深度区间统一为“12.5~15.2m”形式元素符号统一大写矿物名称不能加“矿”字后缀否则指标会被格式问题拉低而不是被模型能力拉低。关系集合的对比同理但匹配时不要直接比字符串而是比对“source 实体 text/type 加上 relation 加上 target 实体 text/type”的三元组这样关系方向的错误也能查出来。5.2 失败样本的组织与迭代方式全流程跑完你拿到的不仅是精确率和召回率还有两类失败样本一类是清洗后仍然错乱的文本一类是模型标注偏离实体边界的段落。对这些案例不要直接改提示词而是把它们积累成一个效果档案每一条记录原始段落、模型输出、人工修正。当同类错误出现三五条以后再做进标注提示词的小样本示例提醒模型不要再错。清洗提示词同理把典型 OCR 错误和正确结果作为示例放进用户消息模型下一轮的纠正率提升通常会比单纯改提示词描述更明显。标注任务变差的最常见原因不是模型不够聪明而是项目方没有形成从失败样本到提示词更新的闭环。本文还有配套的精品资源点击获取