1. 探矿业务文档处理的真实困境搞地质勘查和矿产勘探的人都有一个共同的痛资料太多、太杂、太乱。一个中型探矿项目从预查、普查到详查阶段积累的文档动辄上千份——钻孔柱状图、勘探线剖面图说明、化验分析报告、物化探数据表、地质填图记录、评审意见书格式横跨TXT纯文本、Word文档、PDF扫描件、网页存档甚至还有从老系统里导出的半结构化数据。这些资料如果只是堆在硬盘里那就是一堆死数据但如果能把它们清洗干净、结构化地喂给RAG系统就能变成一个真正能用的地质知识库。我所在团队从2023年下半年开始尝试用RAG技术做探矿知识管理踩了无数坑。最开始想得很简单把文档往向量数据库里一扔做个embedding检索就完事了。结果第一版上线后检索出来的内容驴唇不对马嘴——问“某矿区花岗岩蚀变带特征”返回的却是“花岗岩分类标准”的通用教材内容。问题出在清洗环节TXT里的表格错位、Word里的公式变成乱码、PDF扫描件OCR后错字连篇、网页存档夹杂大量导航栏和广告文本。这些噪声直接污染了向量空间导致检索精度惨不忍睹。后来我们花了将近四个月时间专门打磨文档清洗流水线才把检索准确率从最初的不到40%提升到85%以上。这篇文章就是把这套清洗方法论完整拆解出来包括TXT的结构化解析、Word的公式与表格处理、PDF的分层提取策略、网页的正文抽取以及最终如何把这些清洗后的内容组织成适合RAG检索的知识库。无论你是做地质信息化、矿业数字化还是其他需要处理多格式文档的领域这套思路都可以直接参考。2. 整体清洗架构与方案选型2.1 为什么不能直接“一刀切”转TXT很多人处理多格式文档的第一反应是全部转成纯文本统一处理。我一开始也是这么干的用Python的textract库批量转换结果发现这是最糟糕的方案。TXT转换会丢失所有结构信息——表格变成一堆空格分隔的数字标题和正文混在一起公式直接消失。对于探矿业务来说化验分析表里的品位数据、钻孔编录中的分层深度这些恰恰是最需要保留结构的信息。正确的做法是分层处理不同格式走不同的提取管道但最终输出统一的结构化中间格式。我们选的是Markdown作为中间格式原因是它既能保留标题层级、表格、列表等结构又足够轻量方便后续做分块和embedding。具体来说TXT走规则解析管道Word走python-docx加自定义后处理PDF走PyMuPDF加OCR兜底网页走trafilatura正文抽取。每条管道输出的Markdown再经过统一的清洗、分块、元数据标注最后入向量库。2.2 分块策略按地质语义切不按字数切RAG检索的质量很大程度上取决于分块策略。最常见的做法是按固定字数切分比如每500字一块。但在探矿文档里这种做法会直接把一个钻孔的完整编录切得七零八落。我们采用的是语义分块以地质单元为最小粒度比如一个钻孔的某一层描述、一个化验批次的完整数据表、一段独立的构造分析段落。具体实现上先用标题层级做一级切分再在段落内用地质术语词典做二级切分。这里有个关键参数块大小控制在300到800字之间重叠区设为50到100字。为什么是这个范围因为地质描述通常比较紧凑一个完整的岩性描述段落大约200到400字加上上下文的蚀变信息和矿化信息500字左右能覆盖一个完整的语义单元。重叠区是为了防止边界处的关键信息被切断比如“上覆地层为……”这种跨段落的指代关系。2.3 元数据标注让检索能按业务维度过滤光有文本内容还不够探矿业务检索经常需要按矿区、按矿种、按文档类型、按年代来过滤。我们在清洗阶段就给每个块打上元数据标签矿区名称、经纬度范围、矿种类型、文档来源格式、原始文件名、页码或段落位置、置信度评分。这些元数据存在向量库的payload里检索时可以先用元数据做粗筛再做向量相似度匹配精度提升非常明显。举个例子用户问“西藏某铜矿的蚀变分带特征”如果没有元数据过滤系统可能会返回全国各地的铜矿蚀变资料。加上矿区名称和经纬度过滤后检索范围直接缩小到目标矿区准确率从50%多跳到了80%以上。3. TXT文档的结构化解析3.1 探矿TXT的典型形态探矿业务里的TXT文件主要有几种来源老式数据库导出的定长文本、仪器直读数据、人工录入的简版编录、以及从其他系统转换来的半结构化文本。这些文件的共同特点是没有统一的格式标准字段分隔符五花八门有的用制表符有的用多个空格有的用竖线还有的干脆就是固定列宽。我处理过最棘手的一个TXT文件是某老矿区1990年代的钻孔数据每行128个字符前20位是孔号21到30位是深度31到50位是岩性描述后面是化验数据。这种定长格式用常规的split根本搞不定必须按字符位置精确切片。3.2 规则解析管道的实现针对这类TXT我写了一套基于配置的解析器。核心思路是先自动检测文件的分隔模式再根据检测结果选择对应的解析策略。自动检测的逻辑是统计每行中制表符、连续空格、竖线、逗号的出现频率取频率最高且行间一致性最好的作为分隔符。如果所有分隔符的一致性都低于阈值就判定为定长格式转而用字符位置配置来解析。解析完成后输出结构化的字典列表每个字典代表一条记录键是字段名值是字段内容。字段名从文件头或配套的说明文档中提取如果找不到就自动生成field_1、field_2这样的占位名后续再人工映射。这一步的关键是保留原始行号和字符位置方便回溯核对。3.3 表格数据的特殊处理TXT里的表格是最难处理的。有些表格用加号、减号、竖线画边框有些用等号分隔表头和表体还有些干脆就是纯文本堆叠。我的做法是先用正则识别表格边界连续多行包含相同分隔符模式再把表格区域单独提取出来用类似CSV的解析逻辑处理。对于没有明确分隔符的表格尝试用列对齐信息来推断列边界——统计每列字符的起始位置如果多行的起始位置一致就认为这是一列。解析后的表格统一转成Markdown表格格式保留表头和数据行的对应关系。这里有个细节探矿数据表里经常有合并单元格比如一个化验批次下多个样品共享同一个批号。Markdown表格不支持合并单元格我的处理方式是把合并单元格的值向下填充到每一行同时在元数据里标注“原始合并”标记避免后续检索时误判。注意TXT解析最怕的是编码问题。国内探矿文档常见GBK、GB2312、UTF-8三种编码混用甚至同一文件里不同段落编码不同。我的做法是先用chardet检测检测置信度低于0.8的用GB18030兜底尝试再不行就按字节流手动解码。千万别直接用UTF-8硬读否则乱码会让你怀疑人生。4. Word文档的深度清洗4.1 公式与特殊符号的处理Word文档在探矿业务里主要用于编写地质报告、设计书、评审意见。这些文档里经常嵌入MathType或AxMath公式直接转文本会变成乱码或者丢失。我试过用python-docx直接读公式部分返回的是空字符串或者XML片段根本没法用。后来采用的方案是先用python-docx提取正文文本和表格同时用docx2python库提取公式的OMMLOffice Math Markup Language源码。OMML是XML格式的里面包含了公式的完整结构信息。我写了一个转换器把常见的OMML元素映射成LaTeX分数转\frac{}{}上下标转^和_根号转\sqrt{}积分转\int。对于复杂的矩阵和分段函数转换器覆盖不全的就保留OMML源码在Markdown里用注释块标注检索时跳过这些块但保留位置信息供人工查阅。实测下来常见的地质公式——比如品位计算公式、储量估算公式、坐标转换公式——转换成功率在90%以上。剩下的10%主要是手写公式的扫描件嵌入这种只能走OCR加人工校对。4.2 表格列宽与合并单元格的还原Word表格在转Markdown时有个经典问题列宽信息丢失导致表格结构错乱。python-docx可以读取单元格的宽度属性但很多文档的列宽是“自动调整”模式实际宽度取决于渲染环境。我的做法是优先读取显式设置的列宽如果没有就根据单元格内容的平均字符数来估算列宽比例生成Markdown表格的分隔线。合并单元格的处理更麻烦。Word里一个跨三列的单元格在python-docx里会表现为三个独立的cell对象但只有第一个有内容。我的还原逻辑是遍历表格的XML结构识别gridSpan和vMerge属性重建合并关系。对于横向合并把内容放在第一列后续列留空对于纵向合并把内容放在第一行后续行留空。同时在Markdown表格下方加一个注释说明哪些单元格是合并的。4.3 批注与修订记录的取舍地质报告在评审过程中会产生大量批注和修订记录。这些内容对理解文档的演变过程很有价值但直接混入正文会干扰检索。我的策略是批注和修订单独提取作为元数据附加到对应的段落块上不混入正文文本。检索时如果用户明确需要查看评审意见可以通过元数据过滤调出默认情况下只检索正文。具体实现上python-docx可以读取comments.xml和settings.xml里的修订信息。批注的锚点位置通过commentRangeStart和commentRangeEnd定位把批注内容关联到对应的段落。修订记录则通过w:ins和w:del标签识别插入和删除的内容插入内容保留删除内容用删除线标注后放入元数据。实操心得Word文档清洗最耗时的不是技术实现而是处理各种“非标准”操作。比如有人用文本框排版、用艺术字做标题、用图片代替表格。这些情况没有通用解法只能靠预处理阶段先扫描文档结构发现异常元素就标记出来走人工复核通道。我一般会统计文档中文本框、图片、艺术字的数量超过阈值就单独处理。5. PDF文档的分层提取策略5.1 文本型PDF与扫描型PDF的自动判别PDF是探矿资料里最复杂的格式没有之一。同样是PDF可能是原生数字排版也可能是扫描件还可能是两者混合——正文是文字附图是扫描图片。我的判别逻辑是用PyMuPDF逐页提取文本如果某页提取出的字符数超过阈值比如50个字符且字符分布均匀就判定为文本页如果字符数极少但图片面积占比很大就判定为扫描页。混合文档按页分别处理。文本页直接用PyMuPDF的get_text(dict)方法提取保留字体大小、加粗、颜色等信息用于推断标题层级。扫描页走OCR管道我用的PaddleOCR对中文地质文档的识别效果比Tesseract好不少尤其是表格和手写体。5.2 版面分析与阅读顺序还原PDF的版面分析是清洗的关键难点。地质报告常见双栏排版、图表混排、页眉页脚干扰。如果直接按文本流提取阅读顺序会乱掉——左栏和右栏的内容交错在一起表格和正文混在一起。我的做法是先用PyMuPDF获取每个文本块的边界框坐标再用版面分析算法判断分栏。具体来说统计所有文本块的x坐标分布如果存在明显的双峰分布就判定为双栏按x坐标把文本块分成左右两组先读左栏再读右栏。对于跨栏的标题和表格通过宽度判断——宽度超过页面宽度60%的块视为跨栏元素单独处理。页眉页脚通过位置过滤y坐标在页面顶部5%或底部5%以内的文本块且在多页重复出现的判定为页眉页脚直接丢弃。图表标题通过字体和位置识别字号较小、位于图片下方或上方的文本块判定为图题或表题与对应的图片关联。5.3 表格与图片的分离处理PDF里的表格提取是个老大难。我试过camelot、tabula、pdfplumber各有优劣。camelot对有线表格效果好但对无线表格无能为力pdfplumber能处理无线表格但复杂合并单元格容易出错。最后的方案是组合使用先用pdfplumber检测表格区域如果检测到表格线用camelot提取如果没有表格线用pdfplumber的文本对齐信息推断列边界。图片的处理相对简单提取出来单独存储用OCR识别图片中的文字比如扫描的化验报告识别结果作为图片的alt文本附加到Markdown中。对于地质图件还会用图像分类模型判断图件类型柱状图、剖面图、平面图等作为元数据标注。注意PDF清洗最容易被忽视的是字体嵌入问题。有些PDF用了非标准字体提取出来的文本是乱码。遇到这种情况我的做法是先检查字体的ToUnicode映射表如果映射缺失就回退到OCR识别。虽然OCR会引入少量错误但总比乱码强。6. 网页存档的正文抽取6.1 探矿相关网页的类型分析探矿业务需要的网页资料主要有几类地质调查局的公开报告页面、矿业期刊的在线论文、行业标准发布页、以及一些地质论坛的讨论帖。这些页面的共同特点是正文被大量导航栏、侧边栏、广告、评论区包围直接抓取会引入大量噪声。我试过用BeautifulSoup按标签提取效果很差——不同网站的HTML结构千差万别写规则写到崩溃。后来改用trafilatura这是一个专门做正文抽取的库基于文本密度和标签语义自动识别正文区域。实测下来对新闻类和博客类页面的抽取准确率在85%以上对论坛类页面稍差但也能达到70%左右。6.2 正文抽取与噪声过滤trafilatura的核心逻辑是计算每个HTML节点的文本密度文本长度除以标签数量密度高的节点更可能是正文。同时结合标签语义——article、main、p标签权重高nav、aside、footer权重低。最终输出的是纯文本加基本的结构标记标题、段落、列表。对于抽取结果我还会做一轮后处理过滤掉长度小于20个字符的段落通常是残留的导航文字过滤掉包含“版权所有”、“免责声明”等关键词的段落过滤掉纯链接列表。对于地质论坛的帖子额外提取发帖时间、作者、楼层号作为元数据。6.3 动态网页的预处理有些地质数据平台是动态加载的直接抓HTML只能拿到空壳。这种情况需要先用无头浏览器渲染。我用的Playwright等页面加载完成后获取渲染后的HTML再交给trafilatura处理。这里有个坑有些平台有反爬机制频繁请求会被封。我的做法是控制请求频率每次请求间隔3到5秒同时设置合理的User-Agent和Referer头。对于需要登录才能查看的内容我一般不建议强行抓取而是通过正规渠道获取数据授权。毕竟探矿资料很多涉及商业机密合规性比技术更重要。7. 统一清洗与知识库构建7.1 清洗后的质量校验四条管道输出的Markdown汇总后还需要一轮统一的质量校验。我设计了几个检查项文本长度是否在合理范围太短可能是提取失败太长可能是噪声混入、表格行列数是否一致、公式LaTeX是否能正常渲染、元数据字段是否完整。校验不通过的块会被标记出来进入人工复核队列。校验通过后还会做一轮去重。探矿资料里经常有同一份报告的不同版本或者同一数据在不同文档中重复出现。我用SimHash做近似去重汉明距离小于3的视为重复保留元数据更完整的那一份。7.2 向量化与索引构建清洗后的Markdown块用嵌入模型转成向量。我对比过几个中文嵌入模型text-embedding-ada-002对通用中文效果好但对地质术语不够敏感BGE-large-zh在地质领域微调后效果最好尤其是对岩性名称、矿物名称、地层代号这些专业术语的区分度明显更高。向量库用的Milvus支持标量字段过滤和向量相似度联合查询。索引类型选的是HNSW因为探矿知识库的查询量不大但要求低延迟HNSW在召回率和速度之间平衡得比较好。参数上M设为16efConstruction设为200efSearch设为64实测召回率在95%以上。7.3 检索效果验证与迭代知识库上线后我用一批真实的地质查询做了验证。查询集包括“某矿区主要蚀变类型及分带特征”、“某钻孔见矿深度及品位”、“某区域地层序列及接触关系”等。评估指标是Top-5检索结果的相关性由两位地质工程师独立打分。第一轮验证发现构造类查询的准确率明显低于岩性和矿化类查询。分析原因是构造描述往往跨段落、跨章节分块时被切断了。后来调整了分块策略对构造分析章节用更大的块800到1200字并增加块间重叠到150字。调整后构造类查询准确率从62%提升到了81%。8. 常见问题与排查技巧实录8.1 乱码问题的系统排查乱码是文档清洗中最常见的问题表现形式多样中文变问号、变方块、变奇怪符号。排查思路是分层定位先确认文件编码用file -i命令或chardet检测再确认读取方式Python里用open(file, encodingxxx)显式指定编码最后确认输出编码写入文件时统一用UTF-8。如果编码检测置信度低可以尝试用iconv命令行工具做编码转换测试看哪种编码转换后能正常显示。对于混合编码的文件只能按段落或按行检测分段解码。8.2 表格错位的修复方法表格错位通常表现为列对不齐、数据串行。修复方法是先检查原始表格的分隔符是否一致如果不一致统一替换成制表符再检查是否有单元格内容包含分隔符如果有用引号包裹或转义最后检查列数是否一致不一致的行标记出来人工核对。对于Markdown表格还要注意管道符|的转义。单元格内容里的|必须写成\|否则会破坏表格结构。8.3 公式转换失败的兜底方案公式转换失败时不要强行转换而是保留原始OMML或MathML源码在Markdown里用HTML注释包裹。检索时跳过这些注释块但保留位置标记。同时把公式截图保存为图片在Markdown里用图片链接引用这样人工查阅时能看到公式原貌。8.4 检索精度下降的排查清单问题现象可能原因排查方法解决方案返回结果与查询无关分块过大噪声混入检查块大小和内容缩小块大小增加清洗规则返回结果不完整分块过小语义切断检查块边界增大块大小增加重叠专业术语检索不准嵌入模型领域适配不足测试领域术语相似度微调嵌入模型或增加术语词典按矿区过滤失效元数据缺失或错误检查元数据字段补全元数据增加校验规则表格数据检索错乱表格解析错误检查Markdown表格结构修复表格解析逻辑实操心得清洗流水线一定要有日志和回滚机制。每处理一个文档记录原始文件路径、处理时间、各阶段输出、异常信息。一旦发现某批文档清洗质量下降可以快速定位是哪个环节出了问题回滚到上一版本重新处理。我一般会保留最近三个版本的清洗结果方便对比。9. 一些踩坑后的个人体会这套清洗流水线从最初的想法到稳定运行前后迭代了十几个版本。最大的体会是不要追求一步到位而是先跑通最小闭环再逐步优化。最开始我们只处理TXT和文本型PDF能检索就行后来逐步加入Word、扫描PDF、网页每加一种格式就专门打磨对应的清洗管道。另一个体会是地质领域的RAG和其他领域最大的不同在于术语的精确性。通用嵌入模型对“花岗闪长岩”和“花岗岩”的区分度不够但对地质学家来说这是两种完全不同的岩石。后来我们在嵌入模型微调时加入了大量地质术语对让模型学会区分这些细粒度概念检索准确率才有了质的提升。最后文档清洗不是一劳永逸的事。新的文档格式、新的排版风格、新的噪声类型会不断出现清洗规则需要持续维护。我的做法是建立一个反馈闭环用户每次标记“检索结果不相关”就把对应的查询和文档块记录下来定期分析原因补充清洗规则或调整分块策略。这个闭环跑起来后知识库的检索精度才能持续提升而不是上线即巅峰然后慢慢退化。