企业官网建设流程全解析

从乱码到高精度检索：探矿业务中 TXT、Word、PDF 与网页的 RAG 清洗之道

做探矿业务的都知道，真正值钱的不是那些公开发表的论文，而是几十年积攒下来的内部资料——野外记录本扫描件、老工程师手写的化探报告、不同年代用不同软件导出的物探数据表、上级单位下发的规范文件、还有散落在各台电脑里的项目结题材料。这些资料有个共同特点：格式五花八门，质量参差不齐，很多连打开都是乱码。这两年RAG（检索增强生成）技术火了之后，我们团队也尝试把知识库搭建起来，结果踩了无数坑才明白——RAG效果好不好，检索准不准，根本不取决于模型多聪明，而是取决于喂进去的数据干不干净。清洗这一步做不好，后面全白搭。

这篇文章把我这段时间在探矿业务中做RAG数据清洗的完整过程记录下来，从TXT编码乱码、Word宏病毒残留、PDF扫描件识别到网页正文抽取，全部覆盖。适合正在搭建地质知识库的朋友参考，也适合手里攥着一堆历史资料不知道怎么处理的团队收藏。

1. 探矿业务的数据现状：为什么清洗比模型选型更关键

1.1 探矿数据的特点决定了RAG系统的地基

探矿业务的数据和互联网文本完全不同，它有几个让人头疼的典型特征。首先是时间跨度大，从八九十年代的手写档案到现在的数字报告，跨越了三十年以上的技术变迁，不同年代的资料存储格式差异极大。其次是专业性强，涉及大量地质术语、化学符号、坐标数据、岩性描述，通用分词器根本处理不了。最后是多模态混杂，一份典型的勘查报告里既有文字描述、又有数据表格、还可能包含地质图件和剖面图，信息高度耦合。

这些特点直接决定了RAG系统的预处理策略不能照搬通用方案。我之前见过有人直接把PDF文本提取后丢给向量模型，结果检索出来的内容全是页眉页脚和图表编号，真正的岩矿鉴定描述反而沉在下面。原因很简单——探矿资料的排版往往是两栏甚至三栏，表格和图片穿插，直接提取文本会把版面结构打乱，切出来的文本块毫无语义完整性。

1.2 乱码问题不是技术问题是历史遗留问题

探矿行业的老资料乱码率极高。我统计过我们单位一个项目档案库，光是TXT文件就有差不多40%存在编码识别错误。这些TXT文件从何而来？有的是早期用UCDOS或WPS生成的文档转换而来，有的是从野外设备导出的观测数据，还有的是从老旧的GIS系统里导出的属性表。

这些文件的关键问题在于，它们的编码方式五花八门——有GB2312、GBK、GB18030，还有部分使用UTF-8，甚至个别文件里同一段文字混用了两种编码。更麻烦的是，很多文件没有BOM头，依靠程序自动检测编码基本靠猜。如果这一步处理不当，后续无论RAG系统用什么模型，检索出来的永远都是乱码文本，根本谈不上精度。

1.3 清洗的目标不只是可读，而是可检索

我反复跟我们团队强调一个概念：清洗的目标不是让文件在记事本里能正常打开，而是让文件内容经过切分后能被检索模型有效理解和匹配。这两者有着本质区别。

一份排版混乱的报告，人工阅读可能不受影响，但切分成块之后，每块文本可能包含大量无关内容，比如页脚页码、图例说明、上标下标字符等，这些噪声会严重稀释语义密度。检索时用户问"铅锌矿的赋存状态"，模型匹配到的可能是页脚里"第12页共45页"这种无关信息。所以清洗必须做到语义级别的净化，而不只是格式级别的正常化。

2. 四大格式的清洗流程与参数选择详解

2.1 TXT文本：编码识别与乱码修复的实操方案

TXT在探矿业务里占据的比例远超想象。很多老系统的数据导出、仪器记录、早期的数字化报告，都是以TXT形式留存。处理TXT的第一步是编码检测，我推荐使用Python的charset-normalizer库，它在处理中文编码时的准确率明显优于chardet。

from charset_normalizer import from_bytes def detect_encoding(file_path): with open(file_path, 'rb') as f: raw_data = f.read(65536) result = from_bytes(raw_data).best() return result.encoding if result else 'utf-8'

检测到编码后，需要做归一化处理。我们的标准做法是统一转为UTF-8编码，并且处理BOM头问题。这里有个细节容易踩坑——转码后如果保留了BOM，在后续切分和向量化环节，BOM字符会被当作特殊字符处理，产生干扰。所以转码完成后必须去掉BOM。

def normalize_to_utf8(input_path, output_path): encoding = detect_encoding(input_path) with open(input_path, 'r', encoding=encoding, errors='replace') as f: content = f.read() # 去除BOM标记 content = content.lstrip('\ufeff') with open(output_path, 'w', encoding='utf-8', errors='replace') as f: f.write(content)

对于已经发生字节损坏的文件，errors='replace'会把无法识别的字节替换为替代字符，但这样做的负面影响是产生了大量噪声字符。更好的做法是先尝试多种编码逐一解码，保留成功解码的版本。我写过一段函数，用GB18030、GBK、UTF-8依次尝试，取字符替换率最低的方案。

def best_decoding(file_path): with open(file_path, 'rb') as f: data = f.read() candidates = ['utf-8', 'gb18030', 'gbk', 'utf-16'] best_result = None best_score = float('inf') for enc in candidates: try: text = data.decode(enc) score = text.count('\ufffd') + text.count('?') if score < best_score: best_score = score best_result = (text, enc) except Exception: continue return best_result

探矿数据里TXT还有个特有坑：坐标数据混在文本中。有些TXT文件是从GPS设备导出的，一行一个坐标点，格式为"点位编号 东经 北纬 高程"，但小数分隔符可能是逗号或句号混用。这种文件如果直接切分，每个块里可能只有几个点数据，语义上不完整。处理方式是把坐标数据单独抽取出来，转成结构化表格后存入独立的向量空间。

2.2 Word文档：从doc到docx的统一处理策略

探矿圈里的Word文档真是个重灾区。早年间大家用WPS或Word 97存的.doc文件，格式不规范还带各种奇怪的嵌入对象。还有不少文件是从其他系统导出的伪Word文档，打开后全是域代码和制表符。

处理Word必须先解决格式统一问题。我强烈建议初始阶段将所有的.doc转化为.docx，可以用LibreOffice的批处理模式来转，比用Word COM对象更稳定、速度也更快。

soffice --headless --convert-to docx --outdir /tmp/converted/ *.doc

转换完成后，用python-docx库做内容抽取。但这个库有个局限性——它只能处理.docx格式，而且对文本框、页眉页脚、表格嵌套的支持有限。这里我建议分层抽取：先抽取主要段落，再抽取表格内容，最后单独处理页眉页脚。

from docx import Document def extract_docx_content(path): doc = Document(path) paragraphs = [p.text.strip() for p in doc.paragraphs if p.text.strip()] tables = [] for table in doc.tables: rows = [] for row in table.rows: cells = [cell.text.strip() for cell in row.cells] rows.append(' | '.join(cells)) tables.append('\n'.join(rows)) return '\n\n'.join(paragraphs + tables)

这里有个通用工具解决不了的问题——Word里的嵌入对象和公式。探矿报告里有大量化学公式和地层对比图，在python-docx中只能看到一串不可读的嵌入标记。如果直接把内容喂给RAG，这部分信息会变成乱码。

我的处理方案是，用PyMuPDF库先将Word文档另存为PDF，然后用PDF处理流程走一遍，公式和图表能以图像方式提取并用OCR兜底。这个方案虽然不是最高效的，但对付探矿资料的复杂版式很管用。

Word表格的清洗有几个关键细节值得单独说。探矿报告里的分析结果表通常有大量数值列，单元格里可能有空格、千分位逗号、上下标字符，如果不加清洗直接使用，检索时用户输入"品位25.3克每吨"，模型可能在表里找到"25.30 g/t"却匹配不上，因为格式不一致。我们做了一个规则库来统一这些单位表示，比如"g/t"统一为"克/吨"，"Au"保持大写但增加别名"金"。

2.3 PDF文档：矢量版式和扫描件的分治处理

PDF是探矿资料里最复杂的格式，没有之一。我先把它分成两大类：矢量PDF（文字可选择、复制）和扫描PDF（纯图像）。两类处理思路截然不同。

矢量PDF用pdfplumber或PyMuPDF提取文本。这里有个参数选择问题：是每个页面提取一整个文本块，还是按列和区域分别提取？探矿报告大多双栏排版，如果整页提取，栏的划分会被打破，上下文错乱。我用PyMuPDF的按块提取功能，把每页按"块"切分，同时记录块的位置坐标，坐标相近且语义相关的块合并为一个切片。

import fitz def extract_pdf_blocks(path): doc = fitz.open(path) blocks_by_page = [] for page in doc: blocks = page.get_text("dict")["blocks"] page_blocks = [] for b in blocks: if b['type'] == 0: # text block lines = [] for line in b['lines']: line_text = ''.join(span['text'] for span in line['spans']) lines.append(line_text) page_blocks.append({ 'text': '\n'.join(lines), 'bbox': b['bbox'] }) blocks_by_page.append(page_blocks) return blocks_by_page

扫描PDF是探矿知识的重灾区。大量历史档案是纸质文件扫描成PDF的，完全没有文本层。做这类PDF必须走OCR流程，我推荐PaddleOCR配合PaddleOCR的版面分析模型一起用。PaddleOCR的版面分析模型能把页面自动分成标题、正文、表格、图注等区域，这个能力对探矿资料的复杂排版非常有用。

OCR还有个关键后处理步骤——坐标信息配准。地质资料里常包含经纬度坐标，扫描件经过OCR识别后，经纬度中的度分秒符号和数字极易识别错误，比如把"105°30′"识别成"105°3O′"（字母O代替数字0）。我写了一套坐标正则匹配规则，专门处理这类问题，识别到疑似坐标文本后做分项核对，必要时人工复核。

PDF清理中还有一个不太被注意但实际影响检索效果的部分：页眉页脚的去除策略。探矿报告每一页都有固定的项目编号、页码和密级标识，这些内容如果保留在切块中，会出现大量几乎相同的文本块，造成极大的向量空间浪费，也容易产生假匹配。我在清洗流程里加入了判断逻辑：如果一个字符串在大多数页面的相同位置重复出现，就判定为页眉页脚并移除。

2.4 网页内容：动态加载与正文抽取的取舍

探矿业务中网页资料的主要来源是政府公示的地质矿产信息、行业新闻以及学术数据库的公开摘要。网页清洗的核心目标是抽取正文，去噪，保留关键引用信息和时间戳。

网页抓取的第一个坑是编码判断。很多政府网站仍是GB2312编码，Python的requests库默认按utf-8解码，直接抓取就会乱码。解决方案是用headers里的charset参数判断，或者用Requests-HTML库自动处理。

from requests_html import HTMLSession session = HTMLSession() response = session.get(url) response.encoding = response.apparent_encoding

内容抽取方面，我用的是Readability算法的改良版。传统的Readability库在处理新闻类网页时效果很好，但处理地质报告类页面时经常把关键表格数据过滤掉。我在保留正文的同时，单独抓取页面中的所有表格和图片位置，与正文合并成一个结构化的内容单元。

还有一类网页是动态加载的。很多学术网站的摘要详情页是JS渲染的，requests拿不到内容。需要用Selenium或Playwright模拟浏览器。但这里要注意，Playwright并不是万能的，有些网站检测到Headless浏览器会返回空白页面。我的方法是设置真实浏览器UA，并加上等待条件确保页面完全渲染后再抓取。

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=True, args=['--disable-blink-features=AutomationControlled']) context = browser.new_context(user_agent='Mozilla/5.0 ...') page = context.new_page() page.goto(url, wait_until='networkidle') content = page.content() browser.close()

网页数据清洗的最后一步是规范化URL和抓取时间。RAG系统需要保证知识库内容可溯源，所以在每个抓取内容块中保留来源URL、抓取时间和标题信息，检索结果展示时可以附上出处。

3. 实操过程中总结的清洗流程标准与切块_configuration

3.1 一套可复用的探矿资料清洗标准

我整理了一套适合探矿业务的清洗pipeline，按处理顺序分成了八个阶段。这套流程在我们的多个项目中复用，效果稳定。

每一步都有对应的质量验证方法。比如第4步结构标定，我们会在处理完成后随机抽20个文件，人工比对标注的结构类型与实际内容是否吻合。如果准确率低于95%，就需要调整版面分析模型的参数。

3.2 切块策略的深度优化：从固定长度到语义感知

切块参数直接影响检索精度。我做过对比实验，固定长度512个字符的切块方式，在探矿资料上的检索准确率只有62%，原因在于切断了完整的地质描述段落——比如"矿体围岩为灰白色中厚层状大理岩，局部见矽卡岩化"这句话被拦腰截断，前半句和后半句分属不同的块，检索时只能匹配到一半语义。

改用语义感知切块后，准确率提升到了84%。具体做法是用段落边界为第一优先级，表格为一整个块，标题及其下一段内容作为一个语义单元。对于特别长的段落，再用滑动窗口切分，窗口大小设为400字符，重叠50个字符。

def semantic_split(text, max_len=400, overlap=50): # 优先按段落切分 paragraphs = [p.strip() for p in re.split(r'\n\s*\n', text) if p.strip()] chunks = [] current_chunk = '' for para in paragraphs: if len(current_chunk) + len(para) < max_len: current_chunk += '\n' + para else: if current_chunk: chunks.append(current_chunk) # 超长段落用滑动窗口进一步切分 if len(para) > max_len: for i in range(0, len(para), max_len - overlap): chunks.append(para[i:i + max_len]) else: current_chunk = para if current_chunk: chunks.append(current_chunk) return chunks

切块之后还需要做块级元信息标注。我给每个块打上文件来源、所属章节、页码、切割时间等信息，这样在检索时可以实现按来源过滤，比如只检索某一年度的勘查报告。

3.3 坐标数据和表格的独立通道处理

探矿数据中的坐标信息需要特殊对待。经纬度坐标、直角坐标、矿权范围坐标这些都是查询频率极高的数据，但它们天然带数值特征，向量化效果远不如用结构化存储加精确检索。

我的做法是设计一个坐标实体抽取器，从清洗后的文本中抽取出所有坐标点，存入独立的地理数据库，建立坐标与文本块的关联索引。用户查询"某个矿点的坐标范围"时，先通过精确匹配地理库中的坐标数据，再通过关联索引拉取对应的文本块做语义扩展。这种混合检索的方式比纯向量检索快得多，准确率也高得多。

表格数据的处理分两种情况。结构化数据表（如化验分析表）不适合向量化，我将其转成每行一个独立记录的JSON，存入ES或MongoDB，做精确值查询。非结构化文本表格（如地层对比表）则保留表格语义，转成文字描述后走正常切块流程。

4. 清洗之后：验证、调优与常见问题实录

4.1 检索精度验证的标准方法

清洗完成后必须做系统性的检索验证，不能只看一两轮的反馈就下结论。我采用的验证方法是构造一个标准评测集——从50份不同格式的资料中挑选200个典型的用户查询问题，每类问题都附带标准答案和所在文档。

评测指标上，我同时看召回率和精准率。召回率反映的是"相关内容是否被检索出来"，精准率反映的是"检索出来的内容是否相关"。对于探矿业务来说，精准率往往比召回率更重要，因为如果给用户返回一堆不相关的块，不仅浪费阅读时间，还可能造成误判。

实际操作中还有个指标容易被忽略：答案的溯源完整度。RAG系统应该支持用户从答案追溯到原始文档的具体位置。如果清洗时把源信息丢弃了，这个能力就没了。所以我在清洗流程里特别保留每个块的文件路径、页码和章节编号。

4.2 实战中踩过的九个典型场景与解决方案

场景一：GBK编码文件被识别为UTF-8，出现大量菱形乱码。根因是charset-normalizer在文件内容全为汉字且字节数较少时，误判概率较高。解决方案是加入先验知识——我们维护了一份探矿常用术语表，解码后如果术语匹配率极低，就判定为编码错误，换用其他编码重试。

场景二：Word文档的图片注释没有提取出文字。python-docx只能读取文本节点，图片里的注释文字在嵌入对象中。解决方案是使用Office2PDF流程先转一次PDF，再用PyMuPDF提取图像，最后用OCR处理图像区域。

场景三：PDF文件的表格提取后数据错位。pdfplumber提取表格时，对于跨页表格和嵌套单元格容易丢失对应关系。解决方案是把PDF先转成图片，用PaddleOCR的表格结构识别模型，它擅长还原复杂表头和多栏布局，虽然速度慢一些，但准确率提升明显。

场景四：网页内容抽取时正文中包含大量无关的推荐链接。继续用Readability算法会把推荐的标题也当作正文块。解决方案是维护一个停用词规则库，识别常见的"相关阅读""热门文章""推荐新闻"等标签，出现时截断正文抽取。

场景五：OCR识别扫描型PDF时分不清上下标。地质报告里大量使用Fe₂O₃、CaO等化学式，OCR识别出的结果往往是"Fe203"或"Fe2O3"混用。解决方案是在识别后增加一步化学式归一化规则：检测到元素符号加数字的组合时，统一转为标准下标表示。这一步极大地提升了后续检索对化学式相关问题的匹配能力。

场景六：坐标数据小数位丢失。扫描件OCR识别经纬度时，小数点经常被识别成句号或者被直接忽略。如果不修正，坐标偏差可能达到数公里。解决方案是对所有坐标类文本做针对性复核，识别疑似坐标后用精度范围校验，超出合理范围的坐标标出并记录人工复核。

场景七：切分时长文本的语义断裂。某些特别长的物探综合报告，一章内容上万字，固定窗口切块经常切在方法论和结果之间。解决方案是优先检测章节标题和关键结构词如"研究方法""实验数据""结论分析"，在这些位置设置切分点。

场景八：多份文件内容重复。同一份报告可能以Word版、PDF扫描版、网页版分别存在，入库后造成大量重复块，检索时返回相同内容。解决方案是计算块的MD5哈希做精确去重，再用向量相似度>0.95做语义级去重。

场景九：清洗后文本质量检测。引入一个自动化评分函数，从语料中随机抽样，计算可读性和噪声比，低于阈值的文件退回重新清洗。我设定的阈值为：可读性得分大于75分（基于中文句子完整度），噪声比（乱码字符数/总字符数）小于5%。

4.3 向量化参数和混合检索的经验值

清洗完成后，向量化参数的选择也会明显影响检索精度。我对比过BGE、M3E、OpenAI Embedding和百川等模型在探矿资料上的效果，综合速度和精度后推荐使用BGE系列模型，中文地质术语的支持明显好于通用英文模型。

向量维度方面，320和768两个维度我都试过，维度越高精度略好，但存储和检索耗时成倍增加。如果数据量小于100万块，建议直接用768维，别在维度上省资源，得不偿失。数据量极大时再降维。

检索策略上，我最终采用了混合检索架构：向量检索负责语义匹配，ES的BM25负责关键词精确匹配，两者结果用RRF（Reciprocal Rank Fusion）算法融合后输出。测试表明，在有大量专业术语和坐标数值的探矿场景中，混合检索比纯向量检索的召回率高出约18%。这点非常关键，建议做知识库的朋友不要迷信纯向量检索。

5. 探矿RAG清洗实操的总结与继续深耕方向

从一开始处理乱码TXT文件时的手忙脚乱，到现在形成一整套针对探矿资料的清洗pipeline，我最大的体会是：数据清洗这件事没有一劳永逸的解法，每个格式、每个来源都藏着没预想到的坑。但反过来想，只要把规则库和异常库建好，每踩一次坑都是在给别人铺路，团队的效率会随着语料积累越来越快。

我目前还在继续完善两个方向。一个是OCR结果的置信度标注——对所有识别文本打上置信度评分，低置信度的块不直接进入知识库，而是进入待人工复核队列，避免错误信息误导检索结果。另一个是把探矿资料涉及的专业术语图谱和清洗流程结合，让术语标准化从规则匹配升级为上下文感知的语义纠错。

最后再分享一个小的实操心得：做清洗时一定要保留完整的处理日志，记录每个文件原始编码、处理时间、处理规则版本、处理后文件的hash值。遇到检索问题时能顺着日志快速定位到底是哪一步出了问题，否则排查一个脏数据可能要花掉一整天。这个习惯帮我们节省了海量的时间，也推荐给所有做RAG知识库的朋友。