探矿RAG数据清洗实战：TXT、Word、PDF、网页四类数据源处理指南-北京尧图网络

1. 探矿业务里的数据泥潭为什么通用RAG方案一上就翻车做过矿业数字化的人都有一个共同体会这个行业的数据脏得超出互联网人的想象。地质报告是扫描件钻孔柱状图是CAD导出的PDF化验数据是Excel里手打后另存为TXT的历史档案里还夹着一堆Word 97格式的老文档外加几十个内部网页上挂着的表格。你想搭一套RAG知识库把这些东西盘活第一步就卡住了——解析出来的文本全是乱码检索出来的结果驴唇不对马嘴。我前后在两个探矿项目上落地过RAG清洗管线踩的坑足够写一本小册子。这篇文章就把TXT、Word、PDF、网页这四类数据源的清洗方法拆开讲透重点不是教你调某个库的API而是讲清楚为什么这么洗、洗到什么程度算合格、哪些地方最容易翻车。如果你正在做地质、矿业、勘探相关的知识库或者手头有一堆格式混乱的行业文档要处理这篇内容可以直接抄作业。先说清楚一个前提探矿业务的RAG和通用问答RAG完全是两码事。通用场景下一段文本切错了顶多答非所问但在探矿场景里一个品位数据、一个孔深坐标、一个地层代号搞错了可能导致完全错误的找矿判断。所以我们的清洗目标不是能检索就行而是高精度、可溯源、字段级准确。这个目标决定了后面所有的技术选型。2. 四类数据源的特性拆解与清洗策略选型2.1 先搞清楚每类文件的脏在哪里在动手写代码之前我习惯先做一轮数据摸底。拿一个真实的探矿项目举例大概三千多份文档分布是这样的数据源类型占比典型脏数据问题解析难度TXT约35%编码混乱GBK/GB2312/UTF-8混杂、分隔符不统一、表头缺失低Word约25%老版本doc格式、公式对象、表格跨页、批注混入正文中PDF约30%扫描件无文字层、双栏排版、表格线识别错乱、页眉页脚污染高网页约10%动态渲染、导航栏噪声、表格嵌套、编码声明缺失中这张表是我实际统计出来的不是拍脑袋。你会发现PDF占了将近三分之一而且难度最高这跟探矿行业的特性直接相关——大量历史地质报告只有纸质扫描件数字化程度极低。2.2 清洗策略的核心原则分层处理逐级提纯我的整体思路是四层漏斗原始层保留不动解析层做格式转换清洗层做内容提纯切片层做语义切分。每一层都有明确的输入输出标准任何一层出问题都能回溯定位。为什么不直接一步到位因为探矿数据的错误往往是连锁的。比如PDF解析时把0.85%识别成了0.85%o如果你在解析层没发现到了切片层这个错误就被埋进向量库里了后面检索再准也没用。分层的好处是每层可以单独验证我通常会在解析层和清洗层之间加一个人工抽检环节随机抽50份文档核对关键字段。提示不要迷信任何单一解析工具。我试过市面上主流的七八种PDF解析方案没有一个是万能的。扫描件必须走OCR文字层PDF直接提取双栏排版要特殊处理这个判断逻辑必须自己写。2.3 工具选型的取舍逻辑工具选型这块我的原则是能用成熟库就不自己造轮子但关键环节必须可控。具体来说TXT处理Python原生chardet做编码探测配合codecs做转换不引入额外依赖Word处理python-docx处理docx老doc格式用LibreOffice无头模式转换公式用pandoc转LaTeXPDF处理文字层用pdfplumber表格识别比PyPDF2强太多扫描件走PaddleOCR版面分析用layoutparser网页处理BeautifulSoup做静态解析动态内容用Playwright渲染后抓取这里重点说PDF。为什么选pdfplumber而不是PyPDF2因为探矿报告里表格极多PyPDF2提取表格基本是灾难它会把整页文字按行拼成一坨。pdfplumber能基于坐标还原表格结构虽然慢一点但准确率完全不是一个量级。至于OCRPaddleOCR对中文地质术语的识别率明显优于Tesseract尤其是矽卡岩斑岩型这类专业词汇。3. TXT与Word清洗从编码地狱到结构化字段3.1 TXT编码探测一个字符毁掉整份文件TXT看起来最简单实际上编码问题能让你怀疑人生。探矿行业的TXT来源太杂了九十年代的DOS系统导出的是GB2312两千年代的软件导出的是GBK近几年的新系统才用UTF-8。更坑的是有些文件是混合编码前半段GBK后半段UTF-8chardet探测出来都犯迷糊。我的处理流程是这样的import chardet import codecs def detect_and_read(filepath): with open(filepath, rb) as f: raw f.read() # 先尝试UTF-8严格模式 try: return raw.decode(utf-8) except UnicodeDecodeError: pass # 用chardet探测但只信高置信度结果 result chardet.detect(raw) if result[confidence] 0.9: return raw.decode(result[encoding]) # 兜底按GBK解码忽略错误字符 return raw.decode(gbk, errorsreplace)关键点在最后那个errorsreplace。很多人喜欢用errorsignore觉得把乱码字符丢掉就干净了。千万别这么干探矿数据里一个被忽略的字符可能正好是小数点或者负号丢掉之后0.85变成085数据直接废掉。用replace至少能留下一个占位符后面人工核查时能发现异常。注意编码探测一定要在读取阶段做不要等到清洗阶段。我见过有人先把文件读成字符串再处理编码那时候已经晚了错误已经固化。3.2 TXT结构化分隔符的归一化处理探矿TXT文件的内容形态主要有三种化验数据表、钻孔测斜记录、地质描述文本。前两种是结构化的字段之间用逗号、制表符、空格甚至竖线分隔毫无规律。我的做法是先做分隔符归一化再按行解析import re def normalize_delimiter(line): # 把连续的空格、制表符、竖线统一成单个制表符 line re.sub(r[\t|], \t, line) line re.sub(r\s{2,}, \t, line) return line.strip() def parse_geology_txt(text): records [] for line in text.split(\n): line normalize_delimiter(line) if not line or line.startswith(#): continue fields line.split(\t) records.append(fields) return records这里有个经验不要试图用固定列数去解析。探矿TXT的表头经常缺失或者错位硬编码列数会导致整批数据错位。我的做法是保留原始字段列表在后续的字段映射阶段再根据内容特征比如数值范围、单位后缀来判断哪一列是品位、哪一列是厚度。3.3 Word文档公式、表格与批注的三重陷阱Word文档在探矿行业主要用于地质报告和设计方案难点集中在三个地方。第一个是公式。地质报告里经常有计算公式比如品位计算公式、储量估算公式。这些公式在docx里是OMML对象直接提取文本会变成一堆乱码。我的处理方式是先用pandoc把docx转成Markdown公式会自动转成LaTeXpandoc input.docx -o output.md --wrapnone转出来的LaTeX公式虽然不能直接用于检索但至少是可读的而且保留了公式的语义结构。如果后续要做公式检索可以进一步把LaTeX转成MathML或者用专门的公式向量化模型。第二个是表格跨页。Word表格跨页时表头不会自动重复解析出来就是一堆没有列名的数据行。我的处理逻辑是检测到表格的第一行如果全是文本且后续行有数值就把它当作表头缓存起来遇到新表格时先比对列数列数一致就复用表头。第三个是批注混入正文。python-docx默认会把批注内容也提取出来这些批注往往是审稿意见混进正文会严重污染检索结果。必须显式过滤from docx import Document def extract_docx_text(filepath): doc Document(filepath) paragraphs [] for para in doc.paragraphs: # 跳过批注段落 if para.style.name.startswith(Comment): continue paragraphs.append(para.text) return \n.join(paragraphs)提示老版doc格式Word 97-2003用python-docx打不开必须先用LibreOffice转换。命令是libreoffice --headless --convert-to docx *.doc批量转换时注意加超时控制有些损坏的文件会卡死进程。4. PDF解析探矿RAG清洗的最大拦路虎4.1 先判断PDF类型再决定解析路径PDF在探矿数据里占大头而且类型极其复杂。我把它分成四类每类走不同的解析路径PDF类型特征解析方案准确率文字层PDF可选中文字pdfplumber直接提取95%扫描件PDF图片格式不可选中PaddleOCR识别85%-92%混合型PDF部分页有文字层逐页判断分流处理90%左右双栏排版PDF学术论文式排版版面分析后分栏提取88%左右判断逻辑很简单用pdfplumber打开随机抽三页如果提取出的文字长度超过阈值比如每页200字符就判定为文字层PDF否则走OCR。import pdfplumber def classify_pdf(filepath): with pdfplumber.open(filepath) as pdf: sample_pages pdf.pages[:min(3, len(pdf.pages))] total_chars sum(len(p.extract_text() or ) for p in sample_pages) avg_chars total_chars / len(sample_pages) if avg_chars 200: return text_layer return scanned4.2 文字层PDF表格提取的坐标法文字层PDF的正文提取不难难的是表格。探矿报告里的化验表、钻孔数据表用常规的extract_text()提取出来就是一堆错位的文字。pdfplumber提供了基于坐标的表格提取def extract_tables(filepath): all_tables [] with pdfplumber.open(filepath) as pdf: for page in pdf.pages: tables page.extract_tables({ vertical_strategy: lines, horizontal_strategy: lines, snap_tolerance: 3, join_tolerance: 3, }) for table in tables: # 清洗单元格内的换行和多余空格 cleaned [[cell.replace(\n, ).strip() if cell else for cell in row] for row in table] all_tables.append(cleaned) return all_tables参数里的snap_tolerance和join_tolerance是关键。探矿报告的表格线经常是断断续续的容差设太小会漏掉单元格设太大又会把相邻单元格合并。我实测下来3像素是个比较稳的值但不同来源的PDF可能需要微调。4.3 扫描件PDFOCR预处理决定成败扫描件是探矿数据里最头疼的部分。很多五六十年代的地质报告只有纸质版扫描质量参差不齐有的还是手写体。OCR的准确率高度依赖预处理质量。我的预处理流程是灰度化 → 二值化 → 去噪 → 倾斜校正 → 分辨率提升。其中倾斜校正最容易被忽略但影响巨大。扫描时稍微歪一点OCR的识别率能掉十几个百分点。import cv2 import numpy as np def preprocess_scan(image_path): img cv2.imread(image_path, cv2.IMREAD_GRAYSCALE) # 自适应二值化比全局阈值更适合不均匀光照 binary cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) # 去噪 denoised cv2.medianBlur(binary, 3) # 倾斜校正 coords np.column_stack(np.where(denoised 128)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle (h, w) denoised.shape[:2] center (w // 2, h // 2) M cv2.getRotationMatrix2D(center, angle, 1.0) rotated cv2.warpAffine(denoised, M, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return rotated预处理完之后再送进PaddleOCR识别率能从裸图的70%左右提升到90%上下。对于手写体说实话目前没有特别好的方案我的做法是标记出来走人工录入不要硬用OCR错误率太高。4.4 页眉页脚与版面噪声的清除PDF解析出来最烦人的是页眉页脚。每页都重复XX地质队第X页共X页这种内容如果不清理切片之后每个片段都带着这些噪声检索时会被大量误召回。我的清理策略是频次统计法统计所有页面中重复出现的文本行出现频率超过页面总数60%的判定为页眉页脚统一删除。from collections import Counter def remove_headers_footers(pages_text): line_counter Counter() for text in pages_text: lines set(text.split(\n)) for line in lines: stripped line.strip() if stripped: line_counter[stripped] 1 threshold len(pages_text) * 0.6 noise_lines {line for line, count in line_counter.items() if count threshold} cleaned [] for text in pages_text: lines [l for l in text.split(\n) if l.strip() not in noise_lines] cleaned.append(\n.join(lines)) return cleaned这个方法简单但极其有效。唯一需要注意的是有些报告的关键信息比如章节标题也可能高频出现所以阈值不能设太低60%是个比较安全的经验值。5. 网页数据抓取与清洗动态渲染与噪声过滤5.1 静态网页结构化提取的优先级策略探矿行业的网页数据主要来自内部管理系统、在线地质资料库、矿权公示平台。静态网页用BeautifulSoup就够了关键是提取策略要有优先级。我的提取顺序是正文容器 → 表格 → 列表 → 段落。先找article、main或者带有content、body类名的div找不到再降级到全页提取。表格单独处理因为表格里的数据往往是最有价值的。from bs4 import BeautifulSoup def extract_web_content(html): soup BeautifulSoup(html, lxml) # 移除脚本、样式、导航 for tag in soup([script, style, nav, footer, header]): tag.decompose() # 优先找正文容器 main soup.find(article) or soup.find(main) or \ soup.find(div, class_lambda x: x and content in x.lower()) if main: return main.get_text(separator\n, stripTrue) return soup.get_text(separator\n, stripTrue)5.2 动态网页渲染等待与内容稳定判断有些矿权公示页面是前端渲染的直接抓HTML只能拿到空壳。这时候必须用Playwright渲染。但渲染有个坑不能简单地wait_for_timeout固定等待网络慢的时候内容还没加载完就抓了。我的做法是等待特定元素出现再加一个内容稳定检测from playwright.sync_api import sync_playwright def fetch_dynamic_page(url, wait_selector): with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url, wait_untilnetworkidle) page.wait_for_selector(wait_selector, timeout15000) # 内容稳定检测连续两次获取的内容一致才返回 prev for _ in range(5): current page.content() if current prev: break prev current page.wait_for_timeout(500) html page.content() browser.close() return html5.3 网页表格的特殊处理网页表格和PDF表格不一样它有明确的HTML结构提取起来反而更可靠。但要注意合并单元格rowspan/colspan的处理pandas.read_html能自动处理大部分情况import pandas as pd def extract_web_tables(html): try: tables pd.read_html(html) return [t.to_dict(records) for t in tables] except ValueError: return []提示pd.read_html对编码很敏感如果页面声明的是GBK但实际是UTF-8会直接报错。建议先用chardet探测编码再传给pd.read_html的encoding参数。6. 清洗后的切片策略与检索精度验证6.1 探矿文本的切片不能按固定长度通用RAG教程都教你按500字或者1000字切片这在探矿场景下是灾难。地质报告的逻辑单元是钻孔剖面地层一个钻孔的描述可能只有200字一个剖面描述可能有3000字。固定长度切片会把完整的逻辑单元切碎。我的切片策略是语义边界优先长度兜底优先按标题层级切一级标题、二级标题其次按段落切段落内如果超过800字再按句子切表格单独成块不切分每个切片保留上下文元数据来源文件、页码、章节路径def semantic_chunk(text, max_length800): paragraphs text.split(\n\n) chunks [] current for para in paragraphs: if len(current) len(para) max_length and current: chunks.append(current.strip()) current para else: current \n\n para if current.strip(): chunks.append(current.strip()) return chunks6.2 元数据是检索精度的生命线很多人清洗完只保留文本内容把元数据丢了。这是大忌。探矿RAG的检索精度一半靠文本质量一半靠元数据过滤。我要求每个切片必须携带这些元数据元数据字段作用示例source_file溯源某矿区详查报告.pdfpage_number定位47section_path章节路径第三章/资源量估算/参数选择data_type数据类型化验数据/地质描述/设计方案coordinates空间范围经度XX-XX纬度XX-XXyear时间2019有了这些元数据检索时可以先做元数据过滤再做向量检索精度能提升一大截。比如用户问2019年某矿区的铜品位数据直接过滤year2019 AND data_type化验数据召回范围瞬间缩小到几十个切片。6.3 检索精度验证人工标注自动化指标清洗效果好不好不能靠感觉。我的验证方法是构建一个小型评测集从清洗后的数据里随机抽100个问题人工标注正确答案所在的切片然后跑检索看命中率。关键指标有三个Recall5前5个结果里包含正确答案的比例目标85%MRR正确答案的平均排名倒数目标0.7字段准确率数值型字段品位、厚度、坐标的提取准确率目标95%如果Recall5低于80%说明切片或清洗有问题如果字段准确率低于90%说明解析环节有系统性错误需要回溯检查。7. 实操中踩过的坑与排查速查表7.1 那些让我加班到凌晨的典型问题问题一PDF解析出来全是问号。排查了半天发现是字体嵌入问题某些PDF用了非标准字体pdfplumber提取时映射不到Unicode。解决方案是换pdfminer.six的pdf2txt试试或者直接走OCR。问题二OCR把0识别成O把1识别成l。这在数值数据里是致命的。我的解决方案是在OCR后加一层正则校验对于纯数字字段把字母O、l、I强制替换成0、1、1然后再做数值范围校验。问题三Word表格提取出来列数对不上。原因是合并单元格。python-docx对合并单元格的处理是返回重复值需要手动去重。我的做法是检测连续相同的单元格值只保留第一个。问题四网页抓取被反爬。这个不多说合规前提下控制请求频率加合理的User-Agent不要给目标站点造成压力。7.2 排查速查表现象可能原因排查方法解决方案文本乱码编码错误用chardet探测按探测结果重新解码表格错位分隔符不统一打印原始行归一化分隔符OCR准确率低图像质量差查看预处理结果加强二值化和倾斜校正检索召回差切片不合理检查切片长度分布改成语义边界切片数值提取错误字符混淆抽样核对加正则校验层页眉页脚污染未做频次过滤统计高频行频次阈值过滤7.3 几条用血泪换来的经验第一永远保留原始文件。清洗管线再完善也可能出错原始文件是最后的退路。我习惯把原始文件按年份/矿区/文件类型三级目录归档清洗后的数据单独存两者用文件哈希关联。第二抽样人工核查不能省。自动化指标再漂亮也可能掩盖系统性问题。我每个批次至少抽50份文档人工核对关键字段尤其是数值型的。第三清洗规则要版本化。今天改了一个正则可能影响之前所有数据。我的做法是把清洗规则写成配置文件每次修改都记录版本号和影响范围方便回溯。第四不要追求100%自动化。探矿数据里总有一些奇葩文件手写体、破损扫描件、特殊格式这些走人工处理反而更快更准。把自动化留给80%的常规数据剩下20%人工兜底整体效率最高。8. 从清洗到检索一个可复用的管线设计把上面所有环节串起来我的完整管线是这样的原始文件 → 格式识别 → 分流解析 → 内容清洗 → 元数据注入 → 语义切片 → 向量化 → 入库每个环节的产出都落盘保存方便单独调试。比如解析层的产出是纯文本表格JSON清洗层的产出是去噪后的文本切片层的产出是带元数据的JSONL。这样任何一层出问题都能快速定位。向量化这块我用的是领域微调过的模型通用模型对地质术语的语义理解不够。如果不想微调至少要用支持中文长文本的模型切片长度控制在模型最大长度的70%左右留出余量。最后说一个容易被忽略的点增量更新。探矿数据是持续产生的新钻孔、新化验、新报告不断进来。管线必须支持增量处理不能每次全量重跑。我的做法是用文件哈希做去重新文件走完整管线修改过的文件重新处理并更新对应切片。这套管线在两个项目上跑下来检索准确率稳定在88%以上数值字段准确率95%以上。当然每个项目的数据特性不一样参数需要根据实际情况调整。核心思路是不变的分层处理、保留元数据、语义切片、人工兜底。把这四点做到位探矿RAG的清洗这关就算过了。

探矿RAG数据清洗实战：TXT、Word、PDF、网页四类数据源处理指南

相关推荐

排水管网监测系统有效破解地下排水管网巡检难题

OpenShell：开源终端AI编程助手实战指南

bat脚本全攻略：从基础语法到自动化运维实战

更多资讯

OwnCloud自建私有网盘：从LNMP部署到安全加固实战

React Native与鸿蒙跨平台表格组件优化实践

seaborn regplot线性回归图的统计原理与可信绘图指南

闽南话会议纪要总整理不完？方言会议记录从录音到成稿的完整实操方案（附全流程步骤）

双显卡配置全攻略：核显独显协同、多屏输出与驱动调试实战

impeccable CLI设计：npx-first、AST注入与契约驱动的开发者工具范式

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？