简介面向地质勘探研究人员、工程师及技术管理者的AI应用方案文档系统阐述如何借助AI大模型完成地质勘探语料的清洗与标注。内容覆盖语料收集的数据源选择、噪声识别与去重处理标注类别定义、工具平台选型及流程验证同时兼顾人员培训、质量控制与数据存储管理为后续模型训练和智能决策奠定高质量数据基础。全文为1个PDF文件共940KB虽体量精炼但目录结构完整从引言、AI大模型概述到语料处理、模型训练与应用规划均有清晰展开。已有79人学习下载。读者可从中获得系统化的地质语料治理路径包括网络爬虫与数据库检索等采集方法、开源标注工具比较、自定义平台开发思路以及围绕勘探精度与相关性筛选数据的操作框架对推动地质勘探智能化、提升资源评估与自动报告生成能力具有直接参考价值。1. 地质勘探语料AI大模型清洗和标注到底解决什么问题做地质勘探的人手头最不缺的就是文本钻孔编录、岩芯描述、地质报告、水文观测记录、物化探成果总结几十年攒下来散落在 Word、PDF、扫描件甚至老式打印机出的纸堆里。这些资料是勘探决策真正的底牌但想直接用却非常难——同一套地层在不同报告里叫法不一样“凝灰岩”和“凝灰质熔岩”可能说的是同一层深度写成“45.2-48.7m”和“孔深45米2到48米7”混着来还有大量表格被转成文本之后的乱序碎片。前些年我们做矿区数据整合光是把 200 多份历史报告整理成结构化表格就耗掉三个人两个月而且整理完还得人工核对因为清洗规则一改前面的结果就全要返工。AI大模型进入这个领域最大的价值不是“听懂地质”而是把清洗和标注这两件最耗时、最容易被规则脚本写死的事变成半自动流程。清洗是指把混乱、缺漏、格式不统一的原始文本整理成合格语料标注则是在语料上标出岩性、地层、构造、矿化、深度区间这些实体以及它们之间的关系为后续训练自己的行业模型做准备。这篇文章就按“先清洗、后标注、再避坑”的顺序把一套可以照着落地的应用方案讲透包括模型选型、提示词设计、标注工具配置和质量验证。适合两类人手里握着大量地质文本却不知道从哪里下手的勘探工程师以及要做行业落地的 AI 工程师——后者更需要知道地质语料和通用语料从清洗到标注的差别在哪。2. 地质语料的“脏”把清洗目标拆成四项可执行任务2.1 钻井编录里的典型脏数据长什么样先看一段真实的钻孔编录文本做了脱敏处理这是我从一个矿区项目的扫描报告里提取后未经处理的样式ZK12-3 孔深312.40m 开孔日期2011/6/3 终孔日期2011/7/15 0-2.1m 第四系坡积层 松散 黄褐色 含植物根系 2.1-6.8 凝灰岩 灰绿 安山质 块状构造 裂隙发育 见黄铁矿化 6.8-15.2 安山质凝灰岩 深绿色 碎裂岩化 ...ZK12-3孔 312.40 米 0.00-2.10m 坡积层 2.10-6.80 凝灰岩灰绿色 ...这两段来自同一次施工的不同班报表描述的是同一个钻孔。第一眼看过去“0-2.1m”“2.1-6.8”和“0.00-2.10m”“2.10-6.80”其实是同一段分层但格式、精度、术语全部不一致。整份报告里类似的重复描述还有七八处每一处都略有差异。这就是地质语料最典型的“脏”同一对象多种写法、数值精度不统一、术语混用、描述碎片化。如果直接拿去做训练或检索模型会把这个钻孔的岩性序列学得四分五裂。这类脏数据不是清洗一次就能永久解决的。地质文本的特殊之处在于它高度依赖上下文——单独看“灰绿色凝灰岩”和“安山质凝灰岩”是两种岩性但放到同一个钻孔的相邻层段可能只是同一层位的两种描述习惯。所以清洗必须先建立“层级上下文”的概念以钻孔为基本单位按深度区间切分再在这个框架内统一术语和格式。先切分再清洗顺序反了会把本来连续的层段拆散。2.2 清洗任务的四项拆解噪音、归一、补全、去重我把清洗目标拆成四类每一类对应不同处理策略不建议上来就写一个大而全的“清洗脚本”第一是噪音剔除。表格转文本后的残留竖线、分页符、页眉页脚、扫描 OCR 产生的乱码字符、图例说明混入正文。这类问题规则匹配最有效比如^—{3,}$、连续的|符号、第 X 页 共 Y 页这类固定模式用正则先扫一遍。噪音不剔除干净后面大模型做归一化时会被这些符号干扰出现莫名其妙的输出。第二是格式归一。深度区间写成“0-2.1m”“0.00-2.10m”“孔深0米至2.1米”要统一成0.00-2.10m这种带小数位的标准格式岩性术语按一个固定的词表做映射比如“凝灰岩灰绿色”和“灰绿色凝灰岩”统一成“凝灰岩|灰绿色”。词表映射可以用正则硬匹配但变体太多时就得上大模型做语义判定了。第三是上下文补全。很多老报告为了省纸同一钻孔后续层段会省略岩性名只写“同上”“同上层”“夹薄层”等指代词。这类信息补全必须结合同一个钻孔内上下文的层段信息规则脚本写起来非常绕而大模型在这一步的准确率明显更高——因为它能“读懂”指代关系。第四是重复剔除。同一个钻孔的不同班报表、月报表、最终报告之间存在大量重复描述但表述参差不齐。剔除时不能简单按文本相似度去重因为相邻层段的文本本来就可能长得像都是“凝灰岩 灰绿色 块状构造”一去重就误删。需要按“钻孔编号 深度区间”作为唯一键先对齐层段再做相似度判断。2.3 清洗工具链选型规则脚本与大模型的分工我自己的原则是能用正则一分钟处理完的绝不上大模型大模型只做那些“需要读上下文才能决定”的事。理由很现实规则脚本跑一次十万条文本只要几十秒而大模型逐条处理耗时以小时计成本不在一个量级。而且规则脚本的行为是可预期的出了问题看代码就能定位大模型的输出是概率性的同样的输入今天明天可能结果不一样定位问题只能靠抽检。所以完整清洗流程是三层流水线第一层正则与规则脚本做粗清剔除噪音、统一明显格式第二层大模型做细清处理术语变体、上下文补全、指代消解第三层规则复核用词表和大模型输出做比对把超出词表的内容打回人工复核。这套流程里规则脚本负责“量”大模型负责“难”各干各的活。很多团队一上来就把所有清洗任务丢给大模型最后发现输出的术语五花八门比原始数据还难收拾——这不是大模型不行是分工没做好。3. 用AI大模型做语料清洗本地部署、提示词与批量脚本3.1 模型怎么选本地部署的显存与效果边界地质语料清洗这件事模型选择的关键不是“哪个分数高”而是“能不能在可控成本下跑完你的数据量”。我见过有人拿最强商用模型 API 去清洗历史报告效果确实好但费用按 token 算下来清洗一个中型矿区的文本就要几千块而且地质文本要送到外部接口处理很多单位在数据安全这关就过不了。所以这里重点说本地部署的路径。本地部署大模型做清洗数据规模是首要约束。我的经验是32G 内存的机器可以跑 7B-14B 参数量的量化模型Q4 或 Q8 量化做术语归一、指代消解这类“读短文、写短文”的任务完全够用如果想要更稳定的输出预算允许就上 64G 内存 一张 24G 显存的显卡跑 32B 模型。但得泼一盆冷水地质领域的专家经验更多体现在“知道术语的边界”上而不是“生成华丽的句子”上所以参数量带来的提升边际递减很明显。7B 模型在归一化任务上做到 90% 准确率换成 32B 可能只提升到 93%但推理时间和硬件成本翻了几倍这 3% 能不能接受取决于你的数据量——如果只有几万条人工复核这 3% 更划算如果有上百万条才值得上大模型。另外要注意“去限制”的问题。很多开源模型的基座版本在指令遵循上做得一般需要做对话模板适配或 few-shot 提示。我一般用 Qwen 系列或 LLaMA 系列的指令微调版配合 vLLM 做批量推理。跑批量清洗时不要用交互式对话接口直接用 vLLM 的离线批处理模式速度和稳定性都好很多。# 用 vLLM 启动离线批处理服务示例配置 python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-14b-instruct-q4_k_m.gguf \ --served-model-name geo-cleaner \ --port 8001 \ --max-model-len 4096 \ --gpu-memory-utilization 0.85 \ --enforce-eager启动之后通过 OpenAI 兼容接口调用这样后续换模型只需要改--model路径不需要动业务脚本。参数里--max-model-len 4096是给地质文本留的上下文窗口——很多清洗任务需要把“当前层段 上一个层段 下一个层段”一起喂进去窗口太小会截断太大则影响推理速度--gpu-memory-utilization 0.85是给 KV cache 预留空间设太高容易 OOM设太低则并发上不去。3.2 清洗提示词模板与批量处理脚本清洗任务的提示词设计核心是给模型一个明确的“输入→输出”框架禁止它自由发挥。我用的模板固定为四个部分任务角色、输入格式说明、处理规则、输出格式要求。具体到地质语料清洗处理规则要写清楚“保留原始专业术语的判断不做同义改写”这一条否则模型会把“凝灰岩”改成“火山碎屑岩”这类“更像书面语”的说法反而破坏了术语一致性。下面这段代码是一个实际在用的清洗脚本核心部分已做过脱敏调整import json import re from openai import OpenAI client OpenAI(base_urlhttp://localhost:8001/v1, api_keyEMPTY) CLEAN_PROMPT 你是地质勘探文本清洗助手。你的任务是把一段钻孔编录文本清洗为标准格式遵循以下规则 1. 深度区间统一写成“起始深度-终止深度”单位m保留两位小数。 2. 岩性术语保持专业原样禁止同义改写如“凝灰岩”不要改成“火山碎屑岩”。 3. 去掉明显的噪音字符竖线、连续横线、乱码。 4. 遇到“同上”、“同上层”等指代词结合输入的上下文填充完整岩性描述。 5. 只输出清洗后的文本不输出任何解释。 输入文本 {input_text} 上下文层段 {context_text} 清洗结果 def clean_one_interval(drill_id, start, end, raw_text, context_text): # 先走正则粗清剔除常见噪音字符 raw_text re.sub(r[|│‖]{2,}, , raw_text) raw_text re.sub(r第\s*\d\s*页\s*共\s*\d\s*页, , raw_text) prompt CLEAN_PROMPT.format(input_textraw_text, context_textcontext_text) resp client.chat.completions.create( modelgeo-cleaner, messages[{role: user, content: prompt}], temperature0.1, # 低温度保证输出稳定不做创造性改写 max_tokens512 ) cleaned resp.choices[0].message.content.strip() return cleaned逻辑说明这个函数先做一轮正则粗清把表格转文本最常见的噪音干掉了再走大模型做术语归一和指代补全。注意temperature0.1这个参数非常关键——清洗不是创作温度调低能让模型每次都给出尽量稳定的输出。我曾试过用默认温度跑同一条文本隔天清洗结果居然不一样后来排查发现就是温度太高导致的。另外max_tokens512对地质层段描述足够用了因为正常一个层段的清洗结果应该在 50-100 字以内设太大反而会让模型“凑字数”。批处理时还要在脚本外套一层断点续跑每处理 1000 条记录写一次进度文件把清洗结果按原结构落盘。原因很现实——地质文本量动辄几万条vLLM 跑到一半崩掉是常态没做断点续跑就得从头再来那才是真的血泪经验。3.3 清洗结果的抽检与回流清洗流程跑完之后一定不能直接进入标注环节得做一次抽检。抽检比例我习惯按 3%-5% 来做重点看两类问题一是大模型有没有“自作主张”改写术语二是上下文补全有没有补错——特别是把相邻层段的岩性张冠李戴。抽检结果如果发现某一类错误率超过 2%我会把那部分数据回流到规则层处理而不是改提示词再全量跑一遍因为全量重跑的成本太高了。回流机制的具体做法抽检出有问题的记录按错误类型打标签术语改写、深度格式错误、指代补全错误、噪音残留然后累计到一定量我一般攒满 500 条统一喂给大模型做一次“纠错式清洗”——把错误输出和原始文本都放进提示词让模型对照着重新清洗。这种做法比直接改规则要快得多而且错误样本越攒越多后面做标注模型的 few-shot 示例也有了素材。这里沉淀下来的错误样本就是后期训练行业专用小模型的基础数据。4. 地质勘探语料标注标签体系、Doccano与AI预标注流程4.1 标签体系设计实体、属性、关系三类标签清洗完的语料是“干净的文本”但要让 AI 模型真正学到东西还需要把文本里的专业信息变成机器可读的结构化标签。地质勘探语料标注和通用文本标注有一个显著区别信息密度高且实体之间存在复杂的层次关系。一篇钻孔编录的每一句话里几乎都同时包含岩性、颜色、构造、深度多个信息而通用新闻文本的一句话往往只有一个核心实体。我习惯把标签体系拆成三类。第一类是实体标签主要标四种岩性凝灰岩、花岗岩、大理岩、地层单位二叠系下统、茅口组、构造断层、裂隙密集带、破碎带、矿化标识黄铁矿化、褐铁矿化、硅化。第二类是属性标签挂在实体下面描述颜色、结构、构造、粒度、蚀变程度等。第三类是关系标签连接两个实体最常见的是“岩性-深度区间”的包含关系凝灰岩的深度区间是 2.10-6.80m和“矿化-岩性”的赋存关系黄铁矿化赋存于凝灰岩中。关系标注是地质语料标注里价值最大也最难标的部分——下游做三维地质建模或者成矿预测时真正需要的就是这些关系而不是孤立实体。下表是我给一个矿区项目设计的最小标签集供参考标签类型标签名示例文本说明实体岩性凝灰岩含变种描述实体地层二叠系下统注意不要与岩性混淆实体构造断裂带含裂隙、破碎带实体矿化黄铁矿化含蚀变类型属性颜色灰绿色挂在岩性实体下属性结构块状构造挂在岩性实体下关系深度区间2.10-6.80m与岩性实体关联关系赋存黄铁矿化 → 凝灰岩矿化与岩性关系需要提醒的是标签体系在启动标注前就要定稿并且用 20-30 条典型样本做试标。因为地质师和 AI 工程师对“构造”这个词的理解经常不一致——地质师可能指断层、褶皱这类宏观构造AI 工程师可能把节理裂隙也归进去。这种边界不明确的问题一旦进入正式标注阶段就会成倍放大后面统一标准要付出巨大返工代价。4.2 用Doccano搭标注项目项目配置与数据导入标注工具的选择上文本类标注我不太推荐用 CVAT——虽然功能全面但它是为图像标注设计的文本关系标注的体验很别扭。文本项目里我常用的是 Doccano开源、部署简单、中文支持好序列标注和关系标注都能做。如果你的团队已经买了商业标注平台那流程是相通的核心是标签体系的落地和项目设置。# 用 Docker 快速启动 Doccano按需修改端口 docker pull doccano/doccano docker run -d --name doccano \ -p 8000:8000 \ -e ADMIN_USERNAMEadmin \ -e ADMIN_PASSWORDchange_me \ doccano/doccano启动后浏览器打开http://localhost:8000就能访问了。项目创建时关键配置有两个一是“文本标注”项目类型要选对二是把上面设计的标签集按类型录入注意区分实体标签、属性标签Doccano 里可以定义为实体标签的嵌套或前缀标注和关系标签。Doccano 的关系标注需要先在标签设置里定义好“关系类型”包括赋存、包含、伴生等否则标注页面的关系列表是空的。数据导入格式用 JSONL每一行是一个样本对象。地质文本建议按“钻孔分层段”而不是“整篇报告”作为一条数据——因为一条数据对应一个标注单元太长的文本会让标注员疲劳且漏标率升高。Doccano 导入支持多字段可以同时导入文本和元数据钻孔编号、深度区间这样标注员能带着上下文看文本。数据导入代码示例import json def build_doccano_jsonl(drill_id, depth_start, depth_end, cleaned_text): 构造 Doccano 导入的一行数据 record { text: cleaned_text, meta: { drill_id: drill_id, depth_start: depth_start, depth_end: depth_end } } return json.dumps(record, ensure_asciiFalse) # 示例一条层段 sample build_doccano_jsonl( drill_idZK12-3, depth_start2.10, depth_end6.80, cleaned_text凝灰岩 灰绿色 块状构造 裂隙发育 见黄铁矿化 ) print(sample)逻辑说明meta字段在 Doccano 中会显示为标注页面的参考信息对标注员判断指代关系非常重要。我把深度区间放进 meta 而不是正文是为了避免深度本身被当成实体重复标——很多标注平台会自动对文本中的数字敏感容易把“2.10-6.80”识别成实体放进 meta 后这个干扰就消失了。ensure_asciiFalse这个参数别漏否则导出的 JSONL 里中文会变成\uXXXX转义序列Doccano 导入时可能出现显示异常。4.3 大模型预标注脚本压缩人工标注量的实操标注最贵的是人工所以核心策略是大模型预标注 人工修正而不是让人从零开始标。预标注质量能到 70% 以上的话人工工作量就能砍掉一半以上。做法有三种我按成本从低到高介绍。第一种是基于规则的预标注用正则和地质词表直接匹配文本中的岩性、深度等实体。适合岩性这类术语相对固定的标签——词表里有一万个岩性名文本里出现哪个就标哪个。缺点是词表之外的说法俗称、变种、错别字全都匹配不上匹配率一般到 50%-60% 就顶天了。第二种是大模型推理预标注把文本和标签体系说明一起喂给大模型让它按 JSON 格式输出标注结果。覆盖率高能处理规则匹配不上的变体是主力方案。下面的代码演示了怎么调大模型做预标注并把结果转成 Doccano 可导入的格式import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8001/v1, api_keyEMPTY) ANNOTATE_PROMPT 你是地质勘探文本标注助手。请对下面这段钻孔编录文本做实体和关系标注严格按 JSON 格式输出。 标签体系 - 实体类型岩性(ROCK)、地层(STRATUM)、构造(STRUCTURE)、矿化(MINERALIZATION) - 关系类型包含关系(CONTAINS岩性包含矿化/构造)、深度区间(DEPTH岩性对应的深度范围) 输出要求 {{ entities: [{{text: 凝灰岩, type: ROCK, start: 0, end: 3}}], relations: [{{from: 0, to: 1, type: CONTAINS}}] }} 注意start和end是实体在文本中的字符偏移量从0开始。 待标注文本 {text} def pre_annotate(cleaned_text): resp client.chat.completions.create( modelgeo-cleaner, messages[{role: user, content: ANNOTATE_PROMPT.format(textcleaned_text)}], temperature0, response_format{type: json_object} ) result json.loads(resp.choices[0].message.content) return result逻辑说明这段代码把预标注限制为 JSON 输出temperature0保证输出格式稳定。response_format{type: json_object}是 vLLM 兼容接口提供的功能能让模型强制输出合法 JSON不用自己在提示词里反复强调。拿到结果后还需要写一段转换函数把模型输出的start/end偏移量折算成 Doccano 的标签格式并且丢弃掉那些超出文本长度的非法偏移。第三种是人工修正预标注加载到 Doccano 之后标注员只需改错和补漏。这一步很考验前两步的功底预标注质量越高人越轻松但预标注不代表可以全自动——特别是关系标注模型输出的关系经常把“黄铁矿化赋存于凝灰岩”和“凝灰岩见黄铁矿化”的关系方向搞反。关系方向错误是预标注最常见的翻车点所以人工修正阶段的第一优先级就是检查关系方向而不是检查实体边界。5. 语料清洗与标注的避坑记录五个翻车现场复盘5.1 正则把岩性术语拦腰切断现象用正则匹配“凝灰岩|玄武岩|花岗岩”这类词表时文本里出现“凝灰质粉砂岩”“玄武质安山岩”这类复合岩性名正则只匹配到了“凝灰岩”三个字把完整岩性切断了。原因岩性术语本身是组合式的基性岩结构次要矿物可以组成无限多的复合词。词表匹配天然漏掉这些组合不是正则写错而是词表无法穷举。解决把词表匹配从“精确匹配”改成“前缀/包含匹配”——先用规则找出候选词再结合上下文判断是否复合岩性同时把复合岩性词的完整形态写进词表做二次匹配。更省事的做法是这类文本直接走大模型标注不做规则匹配反正数量不大。5.2 大模型“一本正经”地补全了不存在的深度现象某层段原文写“6.8-15.2 见黄铁矿化”上下文没有提供这一段的岩性。大模型在清洗补全时把“推测为凝灰岩深度区间可能为15.2-20.0”这种带“推测”“可能”的话直接当成清洗结果输出还自作主张补了一个不存在的深度区间。原因提示词里写了“遇到缺失信息可以结合上下文补全”但没限定“只能在上下文明确出现过的情况下补全”。模型在自信模式下会生成看起来合理但实际不存在的推断。解决给补全规则加硬约束——“上下文明确出现的信息才可补全不确定的信息输出[无法确定]标记”。清洗结果里凡是出现“推测”“可能”“约”这类模糊词的记录全部打回人工复核。我现在还会对补全过的字段单独标记来源人工复核时只看标记过的记录不用全文重看。5.3 标注一致性崩了同一实体两种写法现象预标注跑了三分之一的批次后抽检发现同一个“ZK12-3 钻孔的凝灰岩层”有些标注成“凝灰岩”有些标注成“安山质凝灰岩”标注员把两种都当成了不同实体。原因语料本身的写法不一致在前面的清洗阶段没有完全统一——大模型清洗时保留了“凝灰岩”和“安山质凝灰岩”两种说法因为它们都是合法术语但这种粒度差异在标注时应合并为同一实体。解决在建标签体系时增加“别名表”明确哪些说法算同一实体并安排标注组长每两天对已标注的 200 条做一次一致性核对发现歧义赶紧统一口径而不是等项目结束再收拾。这个坑越早踩越好拖到后面一致性修复成本是指数级上涨的。5.4 关系标注的漏标比错标更严重现象模型可以把错的关系抽出来人工改掉就行但漏标的关系人工如果不逐句重读很难发现——尤其是一句话里同时存在“黄铁矿化”、“硅化”、“褐铁矿化”三种蚀变时模型只抽出前两种第三种被漏掉。原因关系标注的召回率天然低于实体标注因为模型需要同时识别实体的存在和实体之间的语义联系任何一个环节断开都会漏标。而人类的眼跳现象严重人工修正时也常跟着模型的思路走漏标被“继承”下来。解决这问题靠提示词很难根治我最后是靠“分割验证法”缓解——把一句话的每个关系对拆开成独立的布尔问题“这句话是否包含黄铁矿化与凝灰岩的赋存关系”用分类模型逐一验证漏掉的自动补回。这套方法把关系标注的召回率从 82% 提到了 94%花费不算高但收益明显。5.5 小模型贪快导致清洗回流率飙升现象为了赶进度把一个 7B 模型部署在 CPU 上跑GPU 被其他任务占了清洗速度倒是能接受但输出质量下降明显——专有术语被改写的比例从 2% 蹿到 8%回流率翻了三倍。原因CPU 推理下模型的有效上下文处理能力下降受限于内存带宽长文本里的上下文信息没有被充分学习到另外 7B 量化模型在 CPU 上跑时量化精度损失的效果会被放大。解决后来把所有清洗任务统一放在 GPU 上跑或者换成 GPU 实例如果必须用 CPU就接受更低的速度并加大抽检比例。这个经历让我得到一个原则别为了赶进度而牺牲推理环境质量清洗质量一旦崩返工成本远超多等几个小时的时间成本。6. 验证与迭代把标注质量变成可量化的工程指标6.1 抽检方案分层抽检与一致性计算标注质量不能靠“感觉差不多”要量化。我采取“分层随机抽检”——不是简单随机抽而是先按钻孔编号、地层时代、文本长度三个维度分成层再从每层里随机抽 5% 的记录让质检员重新标注然后计算与原标注的一致性。分层是为了保证抽检覆盖到不同情况避免所有抽检样本都是短文本或同一个钻孔的。一致性计算用 Cohens Kappa简单说就是去除随机一致之后的一致率。实体标注的 Kappa 值我要求不低于 0.8关系标注不低于 0.7。低于这个线说明标注标准本身存在问题继续往下标只会越标越乱必须停下来对齐标准再重启。一致性计算有现成的 Python 库可以做但要注意一次只算一个标签维度把所有标签类型混在一起算出来的 Kappa 没有意义因为岩性标注的难度和地层标注完全不同。6.2 Bad Case 回流机制让模型越用越准抽检出问题不能修完就完事。我养成的习惯是每周把当周发现的所有 Bad Case 汇总成一份固定格式的 JSONL内容包括原始文本、模型输出、人工修正结果、错误类型。攒到一定量后分为两个用途。一是作为 few-shot 示例在下一次微调或提示词优化时放进去——大模型预标注出问题往往集中在某几类边界情况把真实错误案例摆到模型面前比抽象描述规则有效得多。二是统计错误类型的分布用于资源分配决策如果“关系方向颠倒”占全部错误的 60%那下一轮迭代重点就是关系标注的后处理而不是优化实体识别。这个闭环跑两到三周之后预标注质量会肉眼可见地变好。第一周模型可能只有 60% 的标注可以直接用到第三周基本上 70% 以上直接可用人工只修剩下的部分。我做过的一个矿区项目中从零开始搭这套流程到预标注质量稳定大约花了三周清洗标注的整体工期比纯人工缩短大约 40%而且质量是可控可查的不是“感觉减少了工作量”。最后说个我的个人习惯不管活多急每次清洗和标注的结果都分版本存档——原始文本、清洗后文本、标注结果三个文件夹分别管理版本号写清日期和引擎参数。原因很简单大模型是个黑匣子今天能跑通的参数明天可能就不行了不存档的话出了问题连回退都做不到。地质勘探语料这个东西几十年积累下来不可再生折腾一遍很费功夫稳一点总没错。希望帮到你。本文还有配套的精品资源点击获取