企业官网建设流程全解析

简介：该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个以内，宁可粗标再精修，也不要让标注员面对几十个标签犹犹豫豫。我常用的地质实体标签如下：

关系类型第一版只留四条：位于（岩性与地层）、包含（地层与构造）、控制（构造与岩性）、取样（样品与深度）。关系太多会让标注工作量成倍上涨，而且大模型对复杂关系的预测一致性会明显下降。等跑通一期，拿真实标注数据看看哪类关系对下游最有用，再加也不迟。

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_ascii=False) 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(r"```json\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.2，top_p 0.7，max_tokens根据单段文本长度按2倍预估。温度设得过低会不会太机械？对于标注任务，一致性比创造性重要，同一个实体出现十次就该被标成同一个结果，温度高了做不到。如果接口支持JSON模式就直接开，不支持也没关系，靠Prompt约束加正则剥离也够用。

硬件怎么配？32G内存跑AI大模型完全可行。一个7B量级的Q4量化模型，内存占用大约5到7G，CPU推理一条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和修正记录沉淀成资产包。每个项目改过的正则、补进白名单的术语、模型反复出错的上下文样例，都分门别类归档。现在换一个开源大模型、调一次部署配置，靠着这套资产包，不需要从头再标一遍语料，就能快速迁移到新模型上跑预标注。我自己也吃过亏——调清洗规则的时候不留版本记录，两个月后再看到自己写的正则，完全想不通为什么要那样写。从那以后，每次改规则都会提交一份变更说明，标注产出和修正记录一起进版本库。一个应用方案值不值得做，就看这套清洗标注的资产在第二个项目上还能不能直接用，能，就是赚了；不能，就是白干。希望帮到你。

本文还有配套的精品资源，点击获取