探矿RAG知识库数据清洗实战：TXT、Word、PDF与网页处理策略

1. 探矿数据清洗为什么比模型选型更让人头疼做过地质探矿项目的人都有一个共识数据清洗花掉的时间往往比后面搭检索系统的时间还多。我参与过一个覆盖三个成矿带、累计二十多万份资料的探矿知识库项目前期评估时大家都觉得难点在向量模型和检索策略上结果真正开工之后百分之七十的精力全砸在了数据清洗上。TXT 编码乱码、Word 里的公式变成图片、PDF 扫描件没有文字层、网页抓取回来一堆导航栏和广告——这些问题不解决后面再好的 RAG 框架也是白搭。探矿业务的数据源有个很鲜明的特点格式极度混杂且专业符号密度极高。一份典型的地质报告里可能同时出现化学元素符号、坐标数据、地层代号、矿物名称缩写、图版编号、表格里的品位数据还有大量手写扫描件。这些东西如果清洗阶段处理不好切分出来的文本块就是一堆无意义的字符碎片检索时要么召回一堆噪声要么把关键信息切得七零八落。这篇内容面向的是正在做或准备做探矿领域 RAG 知识库的工程师和数据治理人员。我会把 TXT、Word、PDF、网页这四类数据源在探矿场景下的清洗策略拆开讲重点说清楚每一步为什么这么做、参数怎么定、哪些坑我亲自踩过。全文不涉及任何具体商业平台的推荐只讲方法论和可复现的操作路径。提示探矿数据的清洗目标不是把文件转成纯文本这么简单而是保留专业语义结构的同时去除格式噪声。这两者的区别决定了你后面检索质量的上限。2. TXT 文件编码识别与结构化重建的完整链路2.1 乱码的本质为什么探矿 TXT 特别容易出问题TXT 看起来是最简单的格式但在探矿行业里它反而是最容易出乱码的一类。原因在于探矿数据的 TXT 来源太杂有从老式地质数据库导出的有从 DOS 时代软件里拷贝的有从各种仪器配套软件生成的还有人工用记事本手打的。这些文件的编码可能是 GBK、GB2312、GB18030、UTF-8、UTF-8 with BOM甚至是 Latin-1 和 ASCII 的混合体。我遇到过最离谱的一个案例一份钻孔编录数据前半部分是 GBK 编码后半部分因为中间经过一次软件转换变成了 UTF-8直接导致读取时前半段正常、后半段全是问号。这种混合编码文件用常规的编码检测库比如 chardet也判断不准因为它返回的是一个全局置信度而不是分段结果。处理这类问题的正确思路是分段检测 逐段解码 统一重编码。具体做法是先把文件按固定字节窗口比如 4096 字节切分对每个窗口单独做编码检测然后根据检测结果决定解码方式。如果某个窗口的检测置信度低于阈值我一般设 0.7就尝试用候选编码列表逐个解码看哪个能产出合法的中文字符比例最高。import chardet def detect_encoding_by_segment(file_path, window_size4096): results [] with open(file_path, rb) as f: while True: chunk f.read(window_size) if not chunk: break det chardet.detect(chunk) results.append((det[encoding], det[confidence])) return results def safe_decode(file_path): raw open(file_path, rb).read() candidates [utf-8, gb18030, gbk, big5, latin-1] for enc in candidates: try: text raw.decode(enc) # 统计中文字符占比作为合法性判断 cn_count sum(1 for c in text if \u4e00 c \u9fff) if cn_count / max(len(text), 1) 0.05: return text, enc except UnicodeDecodeError: continue return raw.decode(utf-8, errorsreplace), utf-8-replace这段代码的核心逻辑是不信任单一编码检测结果而是用解码后中文字符占比作为最终判据。探矿文本里中文占比通常不会太低如果某个编码解出来中文比例极低基本可以判定编码选错了。2.2 从自由文本到结构化记录钻孔数据的字段还原探矿 TXT 的第二个大问题是结构丢失。很多钻孔编录、槽探记录、化学分析结果都是以固定宽度或分隔符形式存储的但经过多次转手之后分隔符可能被替换、列宽可能错位。我见过一份化探数据原本是逗号分隔结果因为中间有人用 Excel 打开再另存为 TXT逗号变成了制表符和空格混用。处理这类数据的策略是先探测分隔模式再做字段对齐。具体步骤统计每行中候选分隔符逗号、制表符、竖线、连续空格的出现次数分布。找出出现次数最稳定、且与预期字段数最接近的分隔符。用该分隔符切分后检查每行的字段数是否一致不一致的行单独标记出来人工复核。对字段内容做类型推断坐标类字段应该是数字品位字段应该是数字或数字区间岩性字段应该是有限枚举值。这里有个经验探矿数据里的空值表达方式极其多样可能是空字符串、可能是-、可能是null、可能是未分析、可能是0但实际代表未检出。清洗时必须把这些统一成标准空值标记否则后面做数值检索时会出大问题。我的做法是维护一个空值映射表把所有变体映射到统一的NULL标记同时在元数据里保留原始值。2.3 TXT 清洗后的质量校验三个必须做的检查清洗完 TXT 之后不能直接扔进切分流程必须做质量校验。我一般做三个检查字符集检查确认没有残留的乱码字符比如 UFFFD 替换字符、连续问号、异常控制字符。字段完整性检查统计每个字段的非空率如果某个关键字段比如品位、坐标非空率低于预期说明切分或解码有问题。数值合理性检查对数值字段做范围校验比如品位值不应该出现负数或超过百分之百坐标值应该落在合理的地理范围内。这三个检查看起来简单但能拦住大部分清洗事故。我在一个项目里就是靠数值合理性检查发现了一批坐标数据的小数点错位问题如果没拦住后面检索出来的矿点位置全是错的。3. Word 文档公式、表格与嵌入对象的处理策略3.1 Word 公式转 LaTeX为什么不能直接复制粘贴探矿报告里的公式虽然不如物探、化探那么密集但品位计算公式、储量估算公式、坐标转换公式还是经常出现的。Word 里的公式有两种存在形式一种是旧版的 OLE 嵌入对象MathType 或早期公式编辑器生成的一种是新版的原生公式OMML 格式。这两种的处理方式完全不同。旧版 OLE 对象在纯文本提取时通常会变成一个占位符或者直接丢失新版 OMML 虽然可以提取 XML但直接转文本会丢失结构。我试过几种方案最终比较可靠的是用 pandoc 做中间转换先把 docx 转成 markdown 或 LaTeXpandoc 对 OMML 公式的支持相对成熟能转出可读的 LaTeX 表达式。pandoc input.docx -t markdown --extract-media./media -o output.md但这里有个坑pandoc 对旧版 OLE 公式基本无能为力遇到这种文档我的做法是先人工在 Word 里把公式批量转换为新版格式Word 有转换功能再走 pandoc 流程。如果文档量太大可以考虑用 Word 的宏批量处理但要注意宏安全设置别从不可信来源直接运行宏。转换出来的 LaTeX 公式在切分时建议整条公式作为一个独立文本块不要从中间切断。因为公式的语义是整体的切断了检索时既召不回也读不懂。我通常会在公式前后加特殊标记比如[FORMULA]...[/FORMULA]方便后续检索时识别和特殊处理。3.2 Word 表格合并单元格是最大的敌人探矿报告里的表格特别多而且特别喜欢用合并单元格。品位表、储量表、钻孔坐标表几乎每个表都有跨行跨列的合并。这些表格转成文本时如果不做特殊处理合并单元格的内容要么重复填充要么丢失导致数据错位。我的处理流程是这样的用 python-docx 读取表格先还原合并单元格的逻辑结构。python-docx 本身对合并单元格的支持有限需要自己根据gridSpan和vMerge属性重建。把表格转成二维数组合并单元格的内容填充到它覆盖的所有位置。对二维数组做表头识别通常第一行或前两行是表头识别出来后作为每个数据行的字段名前缀。把每个数据行转成字段名: 值的键值对形式这样切分后每个数据行都是自包含的检索时不会丢失上下文。from docx import Document def extract_table_with_merge(table): rows [] for row in table.rows: cells [] for cell in row.cells: cells.append(cell.text.strip()) rows.append(cells) return rows def table_to_records(rows): if not rows: return [] header rows[0] records [] for row in rows[1:]: record {} for i, val in enumerate(row): key header[i] if i len(header) else fcol_{i} record[key] val records.append(record) return records这段代码是简化版实际处理合并单元格时需要更复杂的逻辑。但核心思想是把表格的每一行转成自包含的记录而不是保留表格的二维结构。因为 RAG 切分是按文本块来的二维结构切完就散了自包含记录才能保证检索质量。3.3 Word 里的图片和嵌入对象该丢的丢该留的留探矿 Word 文档里经常嵌入图片地质图、剖面图、照片、扫描件。这些图片在纯文本 RAG 里默认是丢失的但有些图片承载了关键信息比如图版编号对应的矿物照片、剖面图上的标注。我的策略是图片分类处理装饰性图片logo、边框、无关照片直接丢弃。信息性图片图版、剖面图、柱状图提取出来用 OCR 或图像描述模型生成文字描述作为图片的替代文本嵌入到文档流中。图版编号和题注这些通常是文字正常提取但要和对应的图片建立关联。这里有个细节Word 里图片的题注往往是图 3-1 某某矿区剖面图这样的文字提取时要把题注和图片位置关联起来。我的做法是在提取文本时遇到题注就记录其位置然后把图片的 OCR 结果插入到题注后面。这样切分时题注和图片描述在同一个文本块里检索某某矿区剖面时能同时召回题注和图片内容。4. PDF 解析文字层、扫描件与复杂版式的分层处理4.1 先判断 PDF 类型文字型、扫描型还是混合型PDF 是探矿数据里最麻烦的格式因为它的内部结构差异极大。同样是 PDF可能是原生数字排版有完整文字层可能是扫描件只有图片也可能是两者混合部分页面有文字层部分没有。不做类型判断就直接解析结果要么大量丢失内容要么提取出一堆乱码。我的做法是逐页判断 PDF 类型import fitz # PyMuPDF def classify_pdf_pages(pdf_path): doc fitz.open(pdf_path) page_types [] for page in doc: text page.get_text().strip() images page.get_images() if len(text) 100: page_types.append(text) elif images: page_types.append(scanned) else: page_types.append(empty) return page_types判断阈值我一般设 100 个字符因为有些扫描件会带少量 OCR 残留文字但不足以支撑检索。如果一页文字少于 100 字符且有图片基本可以判定为扫描页。4.2 文字型 PDF版面分析比文字提取更重要文字型 PDF 的提取本身不难PyMuPDF、pdfplumber 都能做。难的是版面分析探矿报告通常是双栏排版还有页眉页脚、图表穿插、脚注。如果直接按阅读顺序提取双栏内容会交错在一起读起来完全乱套。我的处理流程用 pdfplumber 获取每个字符的坐标信息。根据坐标做栏位聚类把 x 坐标相近的字符归到同一栏。按栏位分别提取文字再按 y 坐标排序。识别页眉页脚通常位于页面顶部和底部固定区域且在多页中重复出现用重复度检测剔除。识别表格区域pdfplumber 有表格检测功能但探矿表格经常没有边框线需要结合文字对齐特征判断。import pdfplumber def extract_by_column(page): words page.extract_words() # 按 x0 坐标聚类分栏 words_sorted sorted(words, keylambda w: w[x0]) columns [] current_col [] last_x None for w in words_sorted: if last_x is not None and abs(w[x0] - last_x) 200: columns.append(current_col) current_col [] current_col.append(w) last_x w[x0] if current_col: columns.append(current_col) # 每栏内按 y 坐标排序 result [] for col in columns: col_sorted sorted(col, keylambda w: w[top]) result.append( .join(w[text] for w in col_sorted)) return \n.join(result)这个分栏逻辑比较粗糙实际项目中我会用更精细的聚类算法但核心思路是一样的先按空间位置分栏再按阅读顺序排序。4.3 扫描型 PDFOCR 之后的文本修复才是重头戏扫描件必须走 OCR这个没有捷径。但 OCR 出来的文本不能直接用因为探矿文档里的专业符号和特殊字符识别错误率很高。我统计过一批地质扫描报告的 OCR 结果常见错误包括原始内容常见误识别修复策略品位符号 g/tg/t 识别成 g1t 或 gIt正则替换元素符号 Cu、Pb、Zn识别成 Cu、Pb、Zn 的大小写混乱元素符号词典校正地层代号 D、C、P识别成 0、C、P结合上下文判断坐标数字 0 和 O混淆数字字段强制转数字图版编号 图3-1识别成 图3—1 或 图3.1统一格式我的修复流程是先做规则替换再做词典校正最后做人工抽检。规则替换处理格式类问题词典校正处理专业术语人工抽检用来发现规则覆盖不到的新问题。抽检比例我一般设百分之五如果抽检错误率超过百分之二就说明规则需要补充。注意OCR 修复不要追求百分之百准确那是不可能的。关键是保证关键字段品位、坐标、元素符号的准确率因为这些字段直接影响检索和后续分析。非关键字段描述性文字的错误可以容忍。4.4 PDF 表格提取无边框表格的处理技巧探矿 PDF 里的表格很多是无边框的靠文字对齐来区分列。pdfplumber 的表格检测对这类表格效果一般我的做法是基于文字坐标做列聚类提取页面所有文字及其坐标。统计 x 坐标的分布找出峰值位置作为列边界候选。根据列边界把文字分配到各列。按 y 坐标分组每组是一行。对每行做字段对齐缺失的字段补空值。这个方法对规整的无边框表格效果不错但如果表格有合并单元格或者跨页就需要额外处理。跨页表格我一般会在提取后做一次表头延续处理如果某页表格的第一行和上一页表头结构相似就认为是续表合并处理。5. 网页抓取从导航噪声中提取探矿正文5.1 网页正文提取为什么 Readability 类算法在探矿网站经常失效探矿相关的网页数据来源包括地质调查机构网站、矿业公司公告、学术论文页面、行业资讯网站。这些页面的正文提取通用的 Readability 类算法比如 newspaper3k经常失效原因是探矿网页的正文里夹杂大量表格、图版、专业符号算法容易把表格误判为噪声剔除或者把正文误判为导航。我的做法是针对探矿网站做定制化的正文提取规则先分析目标网站的结构找出正文容器的 CSS 选择器模式。对多个页面做采样确认选择器模式的稳定性。用选择器提取正文再用通用算法做兜底。对提取结果做质量评分中文字符占比、专业术语密度、段落长度分布。from bs4 import BeautifulSoup import re def extract_mining_content(html, content_selectors): soup BeautifulSoup(html, lxml) for selector in content_selectors: container soup.select_one(selector) if container: text container.get_text(separator\n, stripTrue) if is_quality_content(text): return text # 兜底用通用算法 return fallback_extract(soup) def is_quality_content(text): if len(text) 200: return False cn_ratio sum(1 for c in text if \u4e00 c \u9fff) / len(text) if cn_ratio 0.3: return False # 检查是否包含探矿相关术语 mining_terms [品位, 矿体, 地层, 钻孔, 储量, 勘探线] term_count sum(1 for term in mining_terms if term in text) return term_count 2这个质量评分逻辑的核心是探矿正文必然包含一定密度的专业术语。如果一段文字里连两个探矿术语都没有那它大概率是导航或广告。5.2 网页表格和图片保留还是丢弃探矿网页里的表格通常是数据表比如品位统计表、储量汇总表。这些表格的处理方式和 Word 表格类似转成自包含记录。但网页表格有个优势就是 HTML 结构清晰用 pandas 的read_html就能直接解析。图片的处理要分情况如果是数据图表建议用 OCR 或图像描述生成替代文本如果是装饰性图片直接丢弃。网页图片的 URL 要保留在元数据里方便后续溯源。5.3 网页抓取的合规与频率控制做网页抓取必须注意合规性。我的原则是遵守目标网站的 robots.txt。控制抓取频率单站点并发不超过 2请求间隔不低于 1 秒。不抓取需要登录或明确声明禁止抓取的内容。保留抓取时间和来源 URL方便后续溯源和更新。这些不是技术问题但如果不注意轻则被封 IP重则涉及法律风险。我在项目里会把这些规则写成配置强制所有抓取任务遵守。6. 清洗后的统一切分与元数据设计6.1 切分策略按语义单元切不按固定长度切四类数据源清洗完之后都要进入切分环节。很多人习惯按固定字符数切分比如每 500 字一块这在探矿场景下是灾难性的因为会把一个完整的矿体描述切成两半检索时两边都召不回。我的切分策略是按语义单元切分TXT 结构化记录每条记录作为一个块。Word 段落按自然段切段落过长时按句子边界切。Word 表格每个数据行作为一个块。PDF 正文按章节标题切标题作为块的元数据。PDF 表格每个数据行作为一个块。网页正文按段落切保留标题层级。块的大小控制在 200 到 800 字之间过短的块合并过长的块按句子边界拆分。公式块单独处理不参与合并。6.2 元数据设计让每个块都能溯源元数据是 RAG 检索质量的关键。我的元数据设计包含以下字段字段名说明示例source_type数据源类型txt/word/pdf/websource_file原始文件名某矿区钻孔编录.txtpage_num页码PDF12section_title所属章节标题第三章 矿体特征record_id记录唯一标识ZK001-2023coordinates坐标信息经度,纬度element元素类型Cugrade品位值1.25created_time数据创建时间2023-06-15这些元数据在检索时可以作为过滤条件比如检索铜品位大于 1 的矿体记录就能通过 element 和 grade 字段快速过滤大幅提升检索精度。6.3 清洗质量评估三个量化指标清洗完成后我会用三个指标评估质量完整率清洗后文本字符数 / 原始文件字符数估算值。低于 0.8 说明可能丢失了内容。专业术语保留率清洗后文本中探矿术语数量 / 原始文本中术语数量。低于 0.9 说明清洗过度。噪声率清洗后文本中非正文内容页眉页脚、导航、乱码占比。高于 0.05 说明清洗不足。这三个指标结合起来能比较全面地反映清洗质量。我在项目里会把它们做成自动化报告每次清洗后自动生成方便快速定位问题。7. 几个让我印象深刻的踩坑记录第一个坑是编码检测的假阳性。有一次一批 TXT 文件用 chardet 检测全是 UTF-8但打开一看全是乱码。后来发现这些文件是 GBK 编码但内容里恰好有大量 ASCII 字符导致 chardet 误判。从那以后我再也不信任单一检测结果一定要用解码后中文占比做二次验证。第二个坑是PDF 表格的跨页合并。一份储量表跨了三页我一开始按页分别提取结果表头只出现在第一页后两页的数据行没有字段名切分后完全无法理解。后来加了跨页表头延续逻辑才解决。这个坑的教训是PDF 解析不能只看单页要有全局视角。第三个坑是Word 公式的批量转换。一批文档里的公式是旧版 OLE 对象我写了个脚本批量转换结果部分文档转换后公式变成了图片反而更难处理。后来改成先检测公式类型只对可转换的做转换不可转换的标记出来人工处理。这个坑的教训是批量处理前一定要先做类型检测和抽样验证。第四个坑是网页抓取的正文误判。有个矿业资讯网站正文里有个数据表格被 Readability 算法当噪声剔除了导致提取出来的正文缺了关键数据。后来我加了表格保留规则只要表格里有数字和专业术语就保留。这个坑的教训是通用算法在专业领域一定要做定制化调整。8. 写在最后的一些个人体会探矿数据的 RAG 清洗说到底是一个理解数据的过程。你不能把它当成单纯的格式转换而要理解每一类数据在探矿业务里的含义理解哪些信息是关键的、哪些是噪声。我见过太多项目清洗阶段图省事后面检索效果差回头返工的成本是当初的十倍。如果让我给正在做这类项目的同行一个建议那就是清洗阶段多花的时间后面都会以检索质量的形式回报给你。宁可清洗慢一点、细一点也不要为了赶进度跳过质量校验。另外清洗规则一定要版本化管理每次调整都要记录原因和影响范围否则出了问题根本查不到是哪次改动导致的。最后分享一个小技巧清洗过程中遇到拿不准的内容不要自己拍脑袋决定建一个待确认清单定期找业务专家复核。探矿领域的专业性强很多符号和缩写的含义只有一线地质人员才清楚问一句能省你半天猜测。