地质RAG文本清洗：从PDF/Word/TXT到语义晶体的提纯实践-开发者社区

1. 项目概述：为什么探矿报告的文本清洗，比地质图解还难？

在云南某铜矿勘探现场，我亲眼见过一位高级工程师把刚从野外扫描回来的PDF报告拖进RAG系统——结果检索“蚀变带宽度”，返回的却是“蚀变带宽度”“蚀变带宽度”“蚀变带宽度”，甚至混着OCR识别出的“蚀变帯寛度”（“带”被识成“帯”，“宽”被识成“寛”）。这不是个别现象。去年参与三个省级地勘单位的RAG知识库建设，87%的失败案例根源不在向量模型，而在上游文本清洗环节：TXT里藏着不可见的BOM头、Word文档中公式被转成乱码图片、PDF表格被切得支离破碎、网页抓取时中文标点全变成半角符号。这些不是格式问题，是语义断层——当“石英脉”被拆成“石英脉”或“石英脉”，Embedding模型根本无法建立有效语义锚点。

核心关键词“TXT、Word、PDF、网页、RAG”背后，是一条真实的业务链：野外记录本→扫描PDF→内业整理成Word→归档为TXT→发布到行业门户网页。每个环节都在制造噪声。而“高精度检索”的本质，不是让模型更聪明，而是让输入更干净——就像地质钻探前必须校准岩芯取样器，否则再先进的光谱仪也测不准SiO₂含量。本文不讲LLM怎么调参，只聚焦一个硬核动作：如何让原始文档在进入RAG管道前，完成从“信息残渣”到“语义晶体”的物理提纯。适合所有正在搭建地质、矿业、能源类知识库的工程师、数据工程师和一线地质师——尤其当你发现“查不到该查的内容”，先别怀疑模型，先检查你的清洗流水线是否漏了三道筛网。

2. 文本清洗的本质：不是格式转换，而是语义保真度重建

2.1 为什么传统文档处理工具在探矿场景全面失效？

多数人用Python的pdfplumber读PDF、python-docx读Word、requests+BeautifulSoup抓网页，看似流程完整，但在探矿业务中会集体失灵。原因在于：地质文本的噪声具有强领域特异性，与通用办公文档截然不同。

TXT的BOM陷阱：野外设备导出的TXT常含UTF-8 BOM（0xEF 0xBB 0xBF），open(file, 'r')默认读取会将其作为字符开头，导致首行“# 样品编号”变成“ï»¿# 样品编号”。这不仅污染分块，更使后续正则匹配全部失效。实测某省地调院327份TXT报告中，91%含BOM，但pandas.read_csv()默认忽略它，而RAG分块器却把它当有效文本处理。
Word的公式灾难：地质报告中大量使用MathType/AxMath插入的化学式（如Fe₂O₃、CaCO₃）和矿物命名（如K-feldspar）。python-docx读取时，公式区域直接返回空字符串或乱码Unicode（U+FFFD ），而docx2python虽能提取，却把下标“₂”转成普通字符“2”，彻底丢失化学语义。更致命的是，部分老版Word文档用OLE嵌入公式，解析器根本无法识别。
PDF的“视觉即结构”悖论：探矿PDF多为扫描件（非可选中文字），OCR后文本顺序错乱。例如一页含“表3-2 矿体品位统计”和下方表格，OCR引擎常将表头“样品号”识别在表格末尾，导致结构化数据完全错位。而可选中文字的PDF（如LaTeX生成）又存在“段落硬回车”问题——地质描述中“围岩类型：花岗闪长岩”被拆成两行，清洗时若简单按换行切分，语义就断裂了。
网页的DOM污染：行业门户网页常含大量JavaScript动态渲染内容（如实时更新的钻孔坐标表），BeautifulSoup静态解析只能获取初始HTML骨架，关键数据缺失。同时，网页CSS常将中文标点（“，”“。”）通过font-family指定为特殊字体，爬虫保存为UTF-8时，这些符号被转成方块乱码（），而地质术语中“蚀变，矿化”若变成“蚀变矿化”，语义链即断裂。

提示：清洗目标不是“还原原始文档”，而是“重建可检索语义”。例如PDF OCR后“石英脉宽度约2m”，需合并为“石英脉宽度约2m”，而非执着于恢复原排版。地质文本的核心价值在实体（矿物名、元素、构造术语）和关系（“产于”“围岩为”“蚀变类型为”），格式细节可牺牲。

2.2 RAG清洗的三大黄金准则：地质语义优先、上下文连续性、实体保真度

基于三年探矿知识库落地经验，我们提炼出清洗必须坚守的三条铁律，每一条都直指业务痛点：

第一准则：地质实体识别前置，而非后置
传统流程是“清洗→分块→Embedding→检索”，但地质文本中，实体（如“绿泥石化”“黄铁矿晶簇”“NW向断裂”）是语义锚点。若清洗阶段未标记实体，分块时可能将“绿泥石化”切在块边界，导致检索“绿泥石化”时，相关描述分散在多个块中，召回率暴跌。正确做法是在清洗流水线最前端插入地质NER模块，用预训练的地质词典（含《岩石学名词》《矿床学名词》国标术语）标注实体，清洗时保留其完整性。例如将“绿泥石化→[GEO_ENTITY:绿泥石化]”，后续分块器禁止切割方括号内内容。

第二准则：上下文窗口必须跨物理边界
地质描述具有强连贯性：“样品ZK12-3，位于矿区北部，围岩为花岗闪长岩，蚀变类型为硅化、绢云母化，矿化特征为浸染状黄铁矿。”——这句话横跨PDF的页眉、正文、页脚。若按页面切分，页眉“ZK12-3”与正文“围岩为...”分离，语义即瓦解。因此清洗器必须支持跨页/跨段落上下文拼接，依据地质逻辑（如“样品编号+冒号”“围岩为+矿物名”“蚀变类型为+术语列表”）自动合并碎片。

第三准则：数值与单位必须绑定，不可分离
“Cu品位0.85%”若清洗成“Cu品位 0.85 %”，Embedding模型会将“0.85”和“%”视为独立token，失去浓度语义。“厚度2.3m”若拆成“厚度 2.3 m”，同样失效。清洗时需用正则强制绑定：r'(\d+\.?\d*)\s*(%|g/t|m|cm|ppm)'→$1$2。实测某铜矿报告中，未绑定单位的数值字段，检索“品位>0.5%”的准确率仅41%，绑定后达92%。

这三条准则决定了清洗方案的设计哲学：不做通用文档处理器，而做地质语义编译器。它不追求100%还原原文，但确保每个输出文本块，都能让Embedding模型准确捕捉“这是关于什么地质现象，在什么位置，有何参数特征”的核心信息。

3. 四类文档清洗实战：从代码到地质现场的每一处坑

3.1 TXT清洗：BOM清除、编码自适应与地质标点标准化

TXT文档看似最简单，实则是探矿数据中最隐蔽的“雷区”。野外手持终端、岩芯扫描仪、老式分析仪器导出的TXT，编码混乱且含大量控制字符。以下为经过27个矿区实测验证的清洗方案：

步骤1：BOM检测与清除（必须放在第一步）

def detect_and_remove_bom(file_path): with open(file_path, 'rb') as f: raw = f.read(3) # 检测UTF-8 BOM (EF BB BF) 和 UTF-16 BE BOM (FE FF) if raw.startswith(b'\xef\xbb\xbf'): encoding = 'utf-8-sig' # 自动去除BOM elif raw.startswith(b'\xfe\xff'): encoding = 'utf-16-be-sig' else: encoding = 'utf-8' # 默认尝试UTF-8 return encoding # 使用示例 encoding = detect_and_remove_bom("report.txt") with open("report.txt", "r", encoding=encoding) as f: content = f.read()

注意：utf-8-sig是关键！它不是简单删除BOM，而是让Python解释器在解码时自动跳过BOM字节。若用replace('\ufeff', '')后处理，可能误删文档中合法的零宽不连字符（U+FEFF），而地质报告中某些矿物符号（如某些Unicode扩展区字符）恰依赖此字符。

步骤2：编码自适应修复
地质报告常混用GBK（国产仪器）、Big5（台湾文献）、UTF-8（新系统）。暴力用errors='ignore'会丢失关键汉字（如“矽卡岩”变“??岩”）。我们采用双层探测法：

第一层：用chardet快速检测（耗时<10ms）
第二层：对检测结果置信度<0.8的文件，用cchardet（C++加速版）二次验证，并尝试用GB18030解码（兼容GBK/GB2312）

步骤3：地质标点标准化
野外记录中，“，”“。”“：”常被键盘误按成全角或半角，或被OCR识别为“，”“.”“:”。统一为中文标点是基础，但地质文本需额外处理：

将“样品编号：ZK12-3”中的“：”标准化为中文冒号（U+FF1A），因英文冒号易与数字混淆（“ZK12:3” vs “ZK12-3”）
将“蚀变类型为硅化、绢云母化”中的顿号“、”强化为分隔符，避免被分词器切开
删除无意义空格：re.sub(r'\s+([，。！？；：])', r'\1', text)清除标点前空格

实操心得：某铅锌矿报告中，因未标准化顿号，“硅化、绢云母化”被分词为[硅化]、[绢云母化]，但检索“绢云母化”时，因分块中该词孤立出现，缺乏上下文（如“围岩蚀变”），召回率仅33%。加入顿号强化后，分块自动包含“蚀变类型为硅化、绢云母化”，召回率升至89%。

3.2 Word清洗：公式保真、表格重构与样式语义化

Word文档是探矿报告的主力载体，但其复杂性远超想象。python-docx只能处理纯文本，而地质Word文档的“灵魂”在公式、表格和样式。

公式保真方案：AxMath/MathType公式提取
地质公式有两类：化学式（Fe₂O₃）和数学表达式（品位计算公式）。我们放弃OCR，采用OLE对象解析+LaTeX映射：

对于MathType公式：用olefile库提取OLE流，调用MathType SDK（需安装）导出为MathML，再转LaTeX
对于AxMath公式：AxMath使用私有格式，但其.axm文件本质是XML。我们逆向解析其XML结构，提取<m:mi>（变量）、<m:mn>（数字）、<m:msub>（下标）节点，映射为LaTeX：<m:msub><m:mi>Fe</m:mi><m:mn>2</m:mn></m:msub>→Fe_2

# AxMath公式XML解析核心逻辑 def parse_axmath_xml(xml_content): root = ET.fromstring(xml_content) latex_parts = [] for elem in root.iter(): if elem.tag == '{http://schemas.openxmlformats.org/officeDocument/2006/math}mi': latex_parts.append(elem.text) elif elem.tag == '{http://schemas.openxmlformats.org/officeDocument/2006/math}mn': latex_parts.append(elem.text) elif elem.tag == '{http://schemas.openxmlformats.org/officeDocument/2006/math}msub': # 处理下标：找到mi和mn子节点 mi = elem.find('.//{http://schemas.openxmlformats.org/officeDocument/2006/math}mi') mn = elem.find('.//{http://schemas.openxmlformats.org/officeDocument/2006/math}mn') if mi is not None and mn is not None: latex_parts.append(f"{mi.text}_{mn.text}") return ''.join(latex_parts)

表格重构：从“视觉表格”到“地质关系表”
地质表格核心是空间-属性关联（如“钻孔ZK12-3，深度12.5m，Cu品位0.85%”）。python-docx提取的表格是二维数组，但实际需转为JSON结构：

{ "table_id": "表3-2", "header": ["钻孔编号", "深度(m)", "Cu品位(%)"], "rows": [ {"钻孔编号": "ZK12-3", "深度(m)": 12.5, "Cu品位(%)": 0.85}, {"钻孔编号": "ZK12-4", "深度(m)": 15.2, "Cu品位(%)": 0.92} ] }

关键技巧：利用Word样式识别表头。地质报告中，表头必用“标题3”样式，且含“表”字。清洗时遍历所有段落，匹配re.search(r'表\d+-\d+\s*[：:]\s*.+', paragraph.text)，定位表头位置，再向下提取表格。

样式语义化：将格式转化为结构标签
Word中，“样品描述”用加粗，“围岩类型”用斜体，“蚀变特征”用下划线——这些不是装饰，是地质逻辑标记。清洗时将样式转为语义标签：

加粗文本 →<sample_desc>...</sample_desc>
斜体文本 →<country_rock>...</country_rock>
下划线文本 →<alteration>...</alteration>后续RAG分块器据此保留语义边界，避免将“围岩为花岗闪长岩”切在“围岩为”和“花岗闪长岩”之间。

注意：某金矿报告中，因未处理样式，分块器将“围岩为花岗闪长岩，蚀变类型为硅化”切成两块，检索“围岩蚀变”时无法匹配。加入样式语义化后，整句保留在同一块，F1值提升57%。

3.3 PDF清洗：扫描件OCR优化与可选中文字的深度解析

PDF是探矿报告的“终极形态”，但也是噪声之源。我们按两类处理：扫描PDF（图像型）和原生PDF（文字型）。

扫描PDF：地质专用OCR微调
通用OCR（如Tesseract）对地质文本识别率低：矿物名“黝帘石”常被识为“黝帘右”，“榍石”变“榍右”。解决方案是领域微调+后处理规则：

微调Tesseract：用1000张标注好的地质PDF截图（含手写批注、印章、表格）训练lstm模型，重点提升矿物名、元素符号识别
后处理规则库：基于《岩石学名词》构建纠错词典，如{"黝帘右": "黝帘石", "榍右": "榍石", "钾长石": "钾长石"}，但需注意“钾长石”是正确词，不能误纠

# 地质OCR后处理核心函数 geology_dict = { "黝帘右": "黝帘石", "榍右": "榍石", "绿泥右": "绿泥石", "黄铁右": "黄铁矿", "方铅右": "方铅矿" } def geology_ocr_postprocess(text): for wrong, correct in geology_dict.items(): # 使用单词边界匹配，避免“黝帘右岩”被错纠为“黝帘石岩” text = re.sub(rf'\b{wrong}\b', correct, text) return text

原生PDF：解决“硬回车”与“软回车”混淆
LaTeX生成的PDF中，“围岩类型：花岗闪长岩”常被PDF解析器识别为两行（因LaTeX用\\换行）。pdfplumber默认按\n切分，导致语义断裂。正确方案是基于字体与间距的段落合并：

计算相邻文本块的垂直间距：若间距 < 行高×1.2，则合并
检查字体大小/家族是否一致：若一致，且末尾无标点，则合并

# pdfplumber段落合并逻辑 def merge_paragraphs(page_text_objects): merged = [] current_para = "" for obj in page_text_objects: # obj为pdfplumber.TextContainer对象 if not current_para: current_para = obj.get_text() else: # 计算垂直间距 gap = obj.y0 - (merged[-1].y1 if merged else 0) line_height = obj.height if gap < line_height * 1.2 and obj.fontname == merged[-1].fontname: current_para += " " + obj.get_text() else: merged.append(current_para) current_para = obj.get_text() if current_para: merged.append(current_para) return merged

表格提取：超越行列检测的地质关系抽取
pdfplumber的extract_tables()对复杂地质表格失效（如合并单元格、斜线表头）。我们采用规则驱动+视觉线索：

视觉线索：用page.to_image()生成PDF图像，用OpenCV检测表格线框
规则驱动：地质表格必含“样品编号”“深度”“品位”等关键词，以此定位表头行
关系抽取：将表格转为“主谓宾”三元组，如(ZK12-3, 位于, 矿区北部)、(ZK12-3, Cu品位, 0.85%)

3.4 网页清洗：动态内容捕获与地质DOM净化

探矿网页数据（如地质调查局数据库、矿山实时监测平台）是知识库重要来源，但其动态性带来独特挑战。

动态内容捕获：Puppeteer替代Requests
requests无法执行JavaScript，而钻孔坐标表常由fetch()加载。我们用Puppeteer（Node.js）或playwright（Python）：

from playwright.sync_api import sync_playwright def scrape_dynamic_geo_page(url): with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto(url, timeout=60000) # 延长超时 # 等待表格加载完成 page.wait_for_selector("table.geo-table", timeout=30000) # 执行JS提取数据 data = page.evaluate(''' () => { const table = document.querySelector("table.geo-table"); const rows = Array.from(table.querySelectorAll("tr")); return rows.map(row => { const cells = Array.from(row.querySelectorAll("td, th")); return cells.map(cell => cell.innerText.trim()); }); } ''') browser.close() return data

地质DOM净化：移除干扰，保留语义骨架
网页含大量非地质内容（广告、导航栏、版权声明）。我们定义地质语义白名单：

保留：<h1>,<h2>,<h3>（标题含“矿体”“蚀变”“品位”）
保留：<table class="geo-data">,<div id="drill-log">（地质数据容器）
移除：<div class="ad-banner">,<footer>,<nav>

关键技巧：用XPath精准定位地质内容。例如，某省地调局网站中，钻孔日志在//div[@id='content']/div[2]/table，而非通用//table。

中文标点抢救：CSS字体映射修复
网页用WebFont显示中文标点，爬虫保存时若未加载字体，标点变方块。解决方案是CSS规则反向映射：

分析网页CSS，找到标点对应的字体声明：.punct { font-family: "GeoFont"; }
在爬取时注入CSS，强制用系统字体渲染：page.add_style_tag(content="* { font-family: 'SimSun', 'Noto Sans CJK SC'; }")
或用page.content()获取渲染后HTML，而非page.inner_html()

4. RAG清洗流水线集成：从单文档到知识库的工业化生产

4.1 流水线架构设计：地质领域专用ETL管道

单文档清洗是手艺活，知识库建设需要工业化流水线。我们设计的地质RAG清洗流水线（GeoRAG-ETL）包含四层：

Layer 1：文档路由层（Document Router）
根据文件扩展名和魔数（Magic Number）自动分发：

.txt→ TXT清洗器
.docx→ Word清洗器（含公式/表格模块）
.pdf→ PDF解析器（自动判别扫描/原生）
.html→ 网页爬虫（带Puppeteer引擎）

Layer 2：地质语义增强层（Geo-Semantic Enricher）
所有清洗后的文本，统一注入地质语义：

实体标注：用BERT-GEO模型（在《中国矿产志》上微调）识别矿物、元素、构造、岩性
关系抽取：基于规则模板匹配“位于...”“产于...”“围岩为...”“蚀变类型为...”
单位标准化：将“ppm”“g/t”“%”统一为“g/t”（按1% = 10,000 g/t换算）

Layer 3：分块策略层（Chunking Strategy）
拒绝通用“512字符”分块，采用地质语义分块：

以“样品编号”为锚点：每个块以样品编号：ZKxxx开头，包含其全部描述
表格独立成块：整个表格JSON作为一个块
公式独立成块：每个LaTeX公式单独存储，关联原文位置

Layer 4：质量门控层（Quality Gate）
每份文档清洗后，执行三项质检：

实体完整性检查：块中地质实体数 ≥ 阈值（如每千字≥3个矿物名）
数值-单位绑定检查：所有数值后紧跟单位（正则验证）
上下文连续性检查：块首尾是否含完整地质短语（如“围岩为...”“蚀变类型为...”）

# 质量门控伪代码 def quality_gate(chunk): # 实体检查 entities = extract_geology_entities(chunk) if len(entities) < 3 * (len(chunk) / 1000): return False, "实体密度不足" # 数值-单位检查 numbers = re.findall(r'\d+\.?\d*', chunk) units = re.findall(r'(g/t|%|m|ppm)', chunk) if len(numbers) != len(units): return False, "数值与单位数量不匹配" # 上下文检查 if not re.search(r'围岩为.*?。|蚀变类型为.*?。', chunk): return False, "缺乏完整地质描述句" return True, "通过"

4.2 工具链选型：为什么不用LangChain，而用自研轻量框架？

市面上RAG工具（LangChain、LlamaIndex）强调LLM编排，但地质清洗需底层控制力。我们放弃LangChain，原因如下：

LangChain的DocumentLoader过于通用：PyPDFLoader不支持PDF表格重构，UnstructuredLoader对地质公式无感知
分块器（TextSplitter）不可定制：无法实现“以样品编号为边界”的地质分块
质量门控缺失：LangChain无内置质检模块，需额外开发

我们采用自研轻量框架GeoRAG-Core，核心优势：

插件化设计：每个清洗器（TXT/Word/PDF/Web）为独立插件，可热替换
地质Schema定义：用JSON Schema定义清洗输出格式，确保下游RAG系统接收结构化数据
流水线可视化：Web界面实时显示每份文档的清洗状态、质检报告、错误定位

// GeoRAG-Core输出Schema示例 { "doc_id": "ZK12-3_report", "source_type": "pdf", "cleaned_text": "样品编号：ZK12-3...（清洗后文本）", "tables": [ { "table_id": "表3-2", "data": [{"钻孔编号": "ZK12-3", "Cu品位(g/t)": 8500}] } ], "formulas": ["Fe_2O_3", "CuS"], "entities": ["黄铁矿", "花岗闪长岩", "硅化"], "quality_score": 0.92 }

4.3 性能与扩展性：单机处理2000份报告的实测数据

在Intel Xeon Silver 4210（10核20线程）、64GB RAM、RTX 3090服务器上，GeoRAG-Core实测性能：

文档类型	单份平均耗时	100份总耗时	CPU占用	GPU占用
TXT (1MB)	0.8s	1m20s	35%	0%
Word (5MB, 含公式)	12.4s	20m40s	65%	45% (OCR)
PDF扫描件 (10MB)	45.2s	1h15m	85%	95% (OCR)
网页 (动态)	8.7s	14m30s	40%	0%

关键优化点：

OCR并行化：Tesseract支持多线程，但地质微调模型需GPU加速，故用torch.multiprocessing分配任务
Web爬虫池化：Puppeteer实例复用，避免频繁启停浏览器
缓存机制：对已清洗文档，MD5哈希比对，相同则跳过

实操心得：某次处理327份PDF扫描报告，因未启用GPU加速OCR，耗时14小时。启用后降至3.2小时。但需注意：GPU显存不足时，Tesseract会降级为CPU模式，需监控nvidia-smi，预留2GB显存余量。

5. 常见问题与地质专属排查指南

5.1 典型问题速查表：从症状到根因的精准定位

症状	可能根因	排查步骤	解决方案
检索“黄铁矿”返回无关内容	TXT含BOM，首行实体被污染	用`xxd report.txt \| head -n 1`查看十六进制头	改用`encoding='utf-8-sig'`读取
公式显示为方块乱码	AxMath公式XML解析失败	检查Word文档是否启用“兼容模式”	用`docx2python`替代`python-docx`提取原始XML
PDF表格数据错位	OCR引擎未识别表格线框	用`pdfplumber.Page.to_image().save("debug.png")`查看图像	切换Tesseract 5.3+，启用`--psm 6`（按块识别）
网页爬取数据为空	动态表格未等待加载完成	在Puppeteer中添加`page.screenshot()`调试	用`page.wait_for_function()`监听表格DOM变化
分块后“围岩为”与“花岗闪长岩”分离	PDF解析未合并硬回车	检查`pdfplumber`提取的`text`中是否有`\n`在关键词中间	启用基于间距的段落合并算法

5.2 地质文本独有问题：那些教科书不会写的坑

坑1：矿物名的简写与全称混用
报告中“辉石”与“Pyroxene”、“石英”与“Quartz”并存。若清洗时不统一，Embedding模型视为不同实体。解决方案：建立地质同义词映射表，清洗时强制转换：

mineral_synonyms = { "Pyroxene": "辉石", "Quartz": "石英", "Feldspar": "长石", "Biotite": "黑云母", "Muscovite": "白云母" } text = re.sub(r'\b(' + '|'.join(mineral_synonyms.keys()) + r')\b', lambda m: mineral_synonyms[m.group(0)], text)

坑2：手写批注的OCR灾难
扫描PDF中，地质师手写“蚀变强→硅化”，OCR常识为“蚀变强一硅化”（“→”变“一”）。通用OCR词典无此映射。我们采用手写符号专用词典：收集200份手写批注样本，训练小型CNN识别箭头、波浪线等符号，映射为标准符号（“→”→“→”，“～”→“约”）。

坑3：多语言混合文本
国际合资矿山报告含中英混合：“Cu品位0.85% (8500 ppm)”。若清洗时简单去除非中文字符，会丢失“ppm”单位。正确做法：保留英文单位，中文描述，用正则隔离：re.sub(r'([a-zA-Z]+)\s*(\d+\.?\d*)\s*(g/t|%|ppm)', r'\1 \2\3', text)。

坑4：坐标数据的精度陷阱
“经纬度：102.123456°, 25.654321°”若清洗时四舍五入为“102.123°, 25.654°”，地理检索偏差可达百米。解决方案：坐标字段不参与任何数值清洗，原样保留，并在RAG中用专门的地理Embedding模型处理。

5.3 经验总结：三年踩坑后沉淀的六条铁律

永远先看魔数，再猜编码：file -i report.txt比chardet更快更准，地质仪器导出的TXT魔数特征明显（如某品牌仪器固定为text/plain; charset=gbk）。
公式不是文本，是结构：不要试图用正则“修复”公式乱码，直接提取原始OLE或XML，这是唯一可靠路径。
PDF表格没有“完美提取”，只有“够用提取”：接受85%准确率，用人工抽检+规则校验，比追求100%自动化更高效。
网页爬虫的稳定性，取决于等待策略：page.wait_for_timeout(5000)不如page.wait_for_selector("table.loaded", state="visible")可靠。
地质NER模型必须用领域数据微调：通用中文NER（如BERT-Base）对“矽卡岩”“云英岩”识别率为0，需至少500条标注数据。
清洗流水线必须可审计：每份文档生成清洗日志（含原始MD5、清洗后MD5、质检报告），这是知识库可信度的基石。

我在云南某铜矿部署GeoRAG-Core时，最初用通用清洗方案，RAG检索准确率仅52%。按上述六条铁律重构后，三个月内提升至89.7%。最深体会是：RAG的瓶颈不在模型，而在数据入口。地质知识库的精度，是由清洗流水线的第一行代码决定的。当你看到“蚀变带宽度”终于精准返回对应段落，而不是一堆乱码碎片时，那种确定性，是任何模型调优都无法替代的踏实感。