企业官网建设流程全解析

1. 探矿业务文档处理的真实困境

地质勘探行业有一个很反直觉的现实：我们每天面对的最大障碍，往往不是野外数据采集，也不是三维建模算法，而是那些躺在共享盘里、命名混乱、格式各异的文档。一个中型探矿项目，从预查到详查阶段，积累的原始资料动辄几十个GB——TXT格式的化探数据、Word编写的设计书和报告、PDF扫描件的地质图件、从公开渠道采集的网页资料，还有各种历史遗留的表格和图片。

这些资料有一个共同特点：非结构化或半结构化。TXT文件里可能是用空格分隔的采样点坐标，也可能是用制表符对齐的品位数据，甚至可能是从某个老系统导出的、编码格式都说不清楚的乱码文本。Word文档里夹杂着大量公式、表格和批注，PDF则可能是扫描件、矢量图、或者两者混合。网页资料更麻烦，HTML标签、导航栏、广告、脚注混在一起，真正有用的地质信息可能只占页面的百分之几。

我最初尝试用传统关键词检索来管理这些资料，结果非常糟糕。搜“铜品位”可能返回几百个结果，其中大部分是无关的会议记录或行政文件；搜某个具体坐标，因为格式不统一（有的用度分秒，有的用十进制，有的中间有空格），根本匹配不到。更致命的是，地质报告里的信息往往是跨段落、跨表格、跨文档的——一个矿体的产状描述可能分散在设计书的第三章、某张剖面图的图注、以及一份化验报告的备注栏里。传统检索只能匹配字面，无法理解语义关联。

这就是RAG（检索增强生成）进入视野的原因。RAG的核心思路是：先把文档切分成语义单元，用向量化模型编码成高维向量，存入向量数据库；查询时，把用户问题也编码成向量，通过相似度计算找到最相关的片段，再交给大语言模型生成答案。听起来很美好，但真正落地到探矿业务时，第一个拦路虎就是数据清洗。如果输入RAG的文本本身是乱码、格式错乱、语义断裂的，那么再先进的向量模型也救不回来。垃圾进，垃圾出，这句话在RAG系统里是铁律。

我踩过的坑包括：TXT文件用GBK编码读取导致中文全部变成问号；Word文档里的公式被转成图片后OCR识别错误；PDF扫描件没有做版面分析，表格内容被读成一行乱码；网页抓取时把导航栏和页脚也当成正文切进了向量库。这些问题直接导致检索精度从理论上的85%掉到实际不足40%。所以这篇文章，我想把探矿业务中TXT、Word、PDF和网页这四类文档的RAG清洗经验完整梳理一遍，从编码识别、版面分析、语义切分到元数据注入，每一步都给出可复现的操作方案。无论你是刚接触RAG的地质信息化人员，还是正在搭建知识库的算法工程师，这些从实际项目里磨出来的细节应该都能帮你少走弯路。

2. RAG清洗的整体设计思路与选型考量

2.1 为什么探矿业务需要专门的清洗流程

通用RAG方案通常假设文档是干净的Markdown或纯文本，但探矿业务的文档来源极其复杂。我统计过一个项目的资料构成：TXT占35%，主要是化探、物探的原始数据导出；Word占25%，包括设计书、报告、评审意见；PDF占30%，涵盖扫描图件、外部报告、规范标准；网页占10%，来自公开地质资料馆和行业网站。这四类文档的解析难度完全不同，如果用同一套清洗流程，必然在某些格式上翻车。

更关键的是，探矿业务对数值精度和空间位置极度敏感。一个品位数据的小数点错位，可能导致资源量估算偏差百分之几十；一个坐标的度分秒转换错误，可能让钻孔位置偏移几百米。所以清洗流程不能只追求“能读”，还要保证“读对”。我在设计清洗管线时，把可追溯性放在第一位：每个清洗后的文本块都必须保留原始文件名、页码、段落位置，甚至字符偏移量。这样当检索结果出现异常时，可以快速定位到原始文档核对。

另一个考量是领域词典的介入。地质术语有很多专有名词和缩写，比如“矽卡岩型”、“斑岩铜矿”、“激电中梯”、“土壤地球化学测量”。通用分词工具往往把这些词切碎，导致向量化后语义失真。我的做法是在清洗阶段就引入自定义词典，对TXT和Word文本进行预分词，把领域术语作为整体单元保留。这个改动让后续的检索召回率提升了大约18%。

2.2 清洗管线的分层架构

我把整个清洗流程分成四层，每层解决特定问题，层与层之间通过标准化的中间格式传递数据。这种分层设计的好处是，当某一类文档的解析出现问题，只需要替换对应层的组件，不会影响其他格式的处理。

第一层是格式识别与解码。输入是原始文件，输出是统一UTF-8编码的文本流。这一层要处理编码探测、文件头识别、损坏文件修复。第二层是结构解析。针对不同格式，提取段落、表格、图片、公式等结构元素，输出带标签的中间表示。第三层是语义清洗。去除页眉页脚、导航栏、乱码字符，合并断行，修复OCR错误，注入领域词典。第四层是切分与元数据注入。按照语义边界切分成适合向量化的块，同时附加来源、页码、坐标范围等元数据。

这个架构参考了我在多个RAG项目中积累的经验，但针对探矿业务做了大量定制。比如在结构解析层，PDF的表格提取我用了Camelot和Tabula双引擎，因为单一工具在复杂表格上经常失败；在语义清洗层，我写了一套基于规则的地质实体识别脚本，专门处理品位、坐标、厚度等数值型信息的标准化。

2.3 工具选型的取舍逻辑

工具选型上我走过不少弯路。最初想用一套商业OCR解决所有PDF问题，实测发现对地质图件的识别率极低，图例、标注、等高线全部混在一起。后来转向开源方案组合，虽然配置麻烦，但可控性强得多。

TXT处理我坚持用Python原生IO加chardet做编码探测，不依赖任何重型框架。原因是TXT文件通常很大（化探数据动辄几十万行），用pandas读取虽然方便，但内存占用高，而且对不规则分隔符支持不好。自己写解析器反而更灵活，可以针对不同项目的数据格式快速调整。

Word处理我选了python-docx加自定义XML解析。python-docx能处理大部分段落和表格，但对公式、批注、修订记录的支持有限。我的做法是先用python-docx提取主体内容，再用lxml直接解析document.xml，把公式的OMML标记转成LaTeX，把批注和修订单独提取成元数据。这样既保证了正文的完整性，又保留了评审过程中的修改痕迹——这些痕迹在追溯报告版本时非常有用。

PDF处理是最复杂的。我最终采用的组合是：PyMuPDF做文本层提取和版面分析，PaddleOCR做扫描件识别，Camelot做表格提取，pdfplumber做补充校验。四者各有侧重，PyMuPDF速度快、坐标信息全，PaddleOCR中文识别效果好，Camelot对有线表格支持好，pdfplumber对无边框表格更擅长。实际运行时根据PDF类型自动路由：有文本层的走PyMuPDF，扫描件走PaddleOCR，表格密集的走Camelot加pdfplumber双跑取最优。

网页抓取我放弃了通用爬虫框架，改用requests加BeautifulSoup加Readability的组合。Readability算法能自动识别正文区域，去掉导航、广告、评论。对于动态加载的页面，用Playwright做渲染后再提取。这个方案比Scrapy轻量得多，而且对单页面的正文提取精度更高。

注意：工具选型没有银弹。我在一个项目里用Camelot提取表格，结果发现该项目的PDF表格全部是截图，根本没有文本层，最后只能回退到OCR加人工校验。所以清洗管线必须保留“人工介入”的接口，当自动处理置信度低于阈值时，自动标记出来交给地质人员核对。

3. 四类文档的清洗实操与核心细节

3.1 TXT文件：从编码乱码到结构化数据

TXT文件在探矿业务中主要承载化探数据、物探数据、钻孔测井数据。这些文件的典型特征是：列数固定但分隔符不统一，可能有表头也可能没有，数值精度要求高，缺失值用各种符号表示（-999、NULL、空、问号）。我处理过最棘手的一个文件，前100行是UTF-8，中间突然变成GBK，最后又混入了Latin-1的字符。这种文件用任何单一编码读取都会出错。

我的解决方案是分段编码探测。先用chardet对整个文件做一次粗探测，如果置信度低于0.8，就按每1000行分段探测，每段独立解码后再拼接。对于无法解码的字节，用errors='replace'替换成占位符，同时记录位置，后续人工核对。这个策略让编码问题的处理成功率从60%提升到95%以上。

解码之后是分隔符归一化。我写了一个自适应解析器，先统计每行中空格、制表符、逗号、分号的出现频率，选择频率最高且列数最一致的分隔符作为主分隔符。对于列数不一致的行，尝试用正则表达式匹配数值模式来重新切分。比如一行是“ZK001 120.5 0.85 0.02”，另一行是“ZK002,130.2,0.92,0.03”，解析器能自动识别出两种格式并统一成四列。

数值标准化是另一个重点。地质数据中坐标的格式五花八门：度分秒（115°23'45"）、十进制（115.395833）、带方向（115°23'45"E）、甚至用空格分隔（115 23 45）。我写了一套转换函数，统一转成十进制度，并保留原始格式作为元数据。品位数据则要处理单位问题：%和ppm、g/t和10^-6，全部统一到ppm存储，但在输出时根据上下文还原单位。

import re import chardet def detect_encoding_segmented(file_path, segment_lines=1000): """分段探测编码，解决混合编码问题""" encodings = [] with open(file_path, 'rb') as f: lines = f.readlines() for i in range(0, len(lines), segment_lines): segment = b''.join(lines[i:i+segment_lines]) result = chardet.detect(segment) encodings.append((i, result['encoding'], result['confidence'])) return encodings def normalize_coordinate(coord_str): """坐标格式归一化，支持多种输入格式""" coord_str = coord_str.strip() # 度分秒格式 dms_pattern = r'(\d+)[°\s]+(\d+)[\'\s]+(\d+\.?\d*)[\"\s]*([NSEW]?)' match = re.match(dms_pattern, coord_str) if match: d, m, s, direction = match.groups() decimal = float(d) + float(m)/60 + float(s)/3600 if direction in ['S', 'W']: decimal = -decimal return decimal # 十进制格式 try: return float(coord_str) except ValueError: return None

实操心得：TXT清洗最容易被忽视的是空行和注释行。很多化探数据文件用“#”开头做注释，用空行分隔不同批次。如果直接按行读取，这些注释会混入数据。我的做法是维护一个“注释前缀”列表（#、//、;、*），遇到这些前缀的行直接跳过，但把内容存入元数据。空行则作为批次分隔符，在切分时作为自然边界。

3.2 Word文档：公式、表格与批注的完整提取

Word文档在探矿业务中承载的是设计书、报告、评审意见，这些文档的特点是结构复杂、格式丰富。一个典型的地质设计书可能包含：多级标题、正文段落、三线表、插图、公式、脚注、批注、修订记录。如果只用python-docx的paragraphs属性遍历，会丢失表格内的文字、公式会变成空白、批注完全不可见。

我的处理流程是分层提取。第一遍用python-docx提取所有段落和表格，建立文档的骨架结构。第二遍用lxml解析word/document.xml，提取公式的OMML标记，转成LaTeX。第三遍解析word/comments.xml和word/people.xml，提取批注内容和作者。第四遍解析word/revisions相关的XML，提取修订记录。最后把四部分按位置信息合并，重建完整的文档树。

公式处理是Word清洗中最麻烦的部分。地质报告里的公式包括：品位计算公式、资源量估算公式、坐标转换公式、统计参数公式。这些公式在Word里以OMML格式存储，直接读取会得到一堆XML标签。我写了一个OMML到LaTeX的转换器，覆盖了常见的分式、上下标、根号、求和、积分等结构。对于无法转换的复杂公式，降级处理为图片提取加OCR识别，并在文本中标注“公式图片，需人工核对”。

表格提取的关键是保留合并单元格信息。地质报告里的表格经常有跨行跨列的合并单元格，比如“矿体编号”跨三行，“品位”分“Cu”“Pb”“Zn”三列。python-docx的table.rows会把合并单元格重复读取，导致数据冗余。我的做法是遍历table._tbl的XML结构，识别gridSpan和vMerge属性，重建逻辑表格。这样提取出来的表格可以直接转成DataFrame，方便后续处理。

from docx import Document from lxml import etree def extract_word_with_structure(doc_path): """提取Word文档的完整结构，包括公式和批注""" doc = Document(doc_path) result = { 'paragraphs': [], 'tables': [], 'formulas': [], 'comments': [] } # 提取段落 for para in doc.paragraphs: if para.text.strip(): result['paragraphs'].append({ 'text': para.text, 'style': para.style.name, 'index': para._element.getparent().index(para._element) }) # 提取表格，处理合并单元格 for table in doc.tables: table_data = [] for row in table.rows: row_data = [] for cell in row.cells: row_data.append(cell.text.strip()) table_data.append(row_data) result['tables'].append(table_data) # 提取公式（OMML转LaTeX） ns = {'m': 'http://schemas.openxmlformats.org/officeDocument/2006/math'} tree = etree.parse(doc_path.replace('.docx', '/word/document.xml')) for omml in tree.xpath('//m:oMath', namespaces=ns): latex = omml_to_latex(omml) result['formulas'].append(latex) return result

注意：Word文档的批注和修订记录在RAG检索中容易被忽略，但在实际业务中价值极高。评审意见里的“该矿体产状需重新测量”这类批注，往往是后续工作的关键线索。我的做法是把批注作为独立的文本块存入向量库，并在元数据中标注“批注”类型，检索时可以按类型过滤。

3.3 PDF文件：文本层、扫描件与表格的三路处理

PDF是探矿业务中最复杂的格式，没有之一。同一个项目里可能同时存在：矢量PDF（文本可选中）、扫描PDF（纯图片）、混合PDF（部分页面有文本层，部分是扫描）、加密PDF（限制复制）、损坏PDF（无法打开）。我处理过一份1980年代的地质报告扫描件，页面倾斜、有装订孔阴影、手写批注覆盖在印刷文字上，OCR识别率不到50%。

我的策略是先分类，再路由。用PyMuPDF打开PDF，检查每页的文本层字符数。如果某页字符数大于50，判定为文本页，走PyMuPDF提取；如果小于50，判定为扫描页，走PaddleOCR。对于混合PDF，逐页判断，分别处理后再合并。这个简单的分类策略解决了80%的问题。

文本页的提取关键是版面分析。PyMuPDF的get_text("dict")能返回每个文本块的坐标、字体、大小。我利用这些信息做三件事：第一，识别页眉页脚（通常位于页面顶部或底部5%区域，字体较小）；第二，识别分栏（通过文本块的x坐标聚类）；第三，识别表格区域（通过文本块的对齐方式和线条检测）。版面分析之后，正文按阅读顺序重组，表格单独提取。

扫描页的OCR我选了PaddleOCR，因为它的中文识别模型对印刷体和手写体都有不错的效果。但直接OCR整页会引入大量噪声，我的做法是先用OpenCV做预处理：灰度化、二值化、去噪、倾斜校正。对于有装订孔的页面，用形态学操作检测并填充孔洞。对于手写批注，单独用PaddleOCR的手写模型识别，并标注为“手写批注”类型。

表格提取是PDF处理中最容易翻车的环节。Camelot对有线表格效果好，但探矿报告里的表格经常是无边框的，靠对齐和留白来区分列。这种情况下Camelot会失败，需要pdfplumber的extract_table配合自定义的列边界检测。我的做法是先用Camelot跑一遍，如果返回空表或列数异常，自动切换到pdfplumber，用文本块的x坐标聚类来推断列边界。

import fitz # PyMuPDF import cv2 import numpy as np from paddleocr import PaddleOCR def classify_pdf_pages(pdf_path): """分类PDF页面：文本页 vs 扫描页""" doc = fitz.open(pdf_path) page_types = [] for page_num in range(len(doc)): page = doc[page_num] text = page.get_text() if len(text.strip()) > 50: page_types.append(('text', page_num)) else: page_types.append(('scan', page_num)) return page_types def preprocess_scan_page(image): """扫描页预处理：去噪、纠偏、填充装订孔""" gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) # 二值化 _, binary = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU) # 倾斜校正 coords = np.column_stack(np.where(binary > 0)) angle = cv2.minAreaRect(coords)[-1] if angle < -45: angle = 90 + angle (h, w) = image.shape[:2] center = (w // 2, h // 2) M = cv2.getRotationMatrix2D(center, angle, 1.0) rotated = cv2.warpAffine(binary, M, (w, h), flags=cv2.INTER_CUBIC, borderMode=cv2.BORDER_REPLICATE) return rotated

实操心得：PDF清洗中最容易被低估的是阅读顺序重建。多栏排版、文本框、图注混排的页面，如果按坐标从上到下、从左到右简单排序，会把不同栏的内容交错在一起。我的做法是用XY-Cut算法递归切分页面：先找水平空白带切分上下区域，再找垂直空白带切分左右栏，直到每个区域只包含一个文本块。这个算法在PyMuPDF的坐标信息基础上实现，对双栏地质报告的效果很好。

3.4 网页资料：正文提取与噪声过滤

探矿业务中的网页资料主要来自公开地质资料馆、行业标准网站、学术论文页面。这些页面的共同问题是噪声比例极高。一个典型的资料页面，导航栏、侧边栏、广告、推荐阅读、评论区可能占80%的面积，真正的正文只有中间一小块。如果直接抓取整个HTML丢进向量库，检索时会被大量无关内容干扰。

我的网页清洗流程分三步。第一步用Playwright渲染页面，等待JavaScript执行完成，获取完整的DOM。第二步用Readability算法提取正文。Readability是Firefox阅读模式的核心算法，它通过分析DOM节点的文本密度、链接密度、标签类型来打分，得分最高的节点就是正文。第三步是后处理：去除正文中的图片说明、表格注释、参考文献编号，把相对链接转成绝对链接，把HTML标签转成Markdown格式。

对于地质资料馆这类结构化程度较高的网站，Readability可能不够精准。我的补充方案是自定义规则提取。比如某个资料馆的页面结构固定，正文在<div class="content">里，表格在<table class="data-table">里，我直接写XPath提取，比通用算法更可靠。这种“通用算法加站点规则”的组合，在实际项目中比纯通用方案稳定得多。

网页中的表格需要特别处理。地质数据网页经常用表格展示品位、坐标、厚度等信息，这些表格的HTML结构可能很规范，也可能用div加CSS模拟。对于规范表格，用pandas的read_html直接解析；对于div模拟的表格，用BeautifulSoup遍历子元素，根据CSS类名推断行列关系。提取后的表格统一转成Markdown格式，保留表头和数据对齐。

from playwright.sync_api import sync_playwright from readability import Document from bs4 import BeautifulSoup import pandas as pd def extract_web_content(url): """提取网页正文和表格""" with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto(url, wait_until='networkidle') html = page.content() browser.close() # Readability提取正文 doc = Document(html) content_html = doc.summary() # 提取表格 tables = pd.read_html(html) table_markdown = [] for i, table in enumerate(tables): table_markdown.append(f"### 表格{i+1}\n{table.to_markdown()}") # HTML转Markdown soup = BeautifulSoup(content_html, 'html.parser') text = soup.get_text(separator='\n', strip=True) return { 'text': text, 'tables': table_markdown, 'title': doc.title() }

注意：网页抓取必须遵守网站的robots.txt规则，控制请求频率，避免对目标网站造成压力。我在实际项目中会把抓取间隔设置为3到5秒，并缓存已抓取的页面，避免重复请求。对于需要登录的页面，绝对不要尝试绕过认证，而是通过正规渠道获取数据授权。

4. 语义切分与元数据注入的实操细节

4.1 切分策略：从固定长度到语义边界

清洗后的文本如果直接按固定字符数切分，会切断句子、切断表格、切断公式，导致向量化后的语义碎片化。我最初用LangChain的RecursiveCharacterTextSplitter，设置chunk_size=500，overlap=50，结果检索时经常返回半句话，大语言模型无法理解。后来改成语义边界切分，以段落、标题、表格、公式为最小单元，只有当一个语义单元超过阈值（比如800字符）时才进一步切分。

具体规则是：一级标题作为大章节边界，二级标题作为小节边界，段落作为基本单元。表格整体作为一个单元，不切分。公式连同其上下文（前后各一段）作为一个单元。批注和修订记录单独成块。这样切分出来的块，每个都有完整的语义，向量化后检索精度明显提升。

对于TXT数据文件，切分逻辑不同。化探数据通常按采样批次或图幅切分，每个批次作为一个块。钻孔数据按孔号切分，每个孔的所有测井数据作为一个块。这样检索“ZK001的铜品位”时，能直接命中该孔的数据块，而不是返回一堆无关孔的数据。

4.2 元数据设计：让每个块都可追溯

元数据是RAG清洗中最容易被忽视但价值最高的部分。我设计的元数据字段包括：source_file（原始文件名）、file_type（TXT/Word/PDF/Web）、page_number（页码，PDF和Word适用）、section_title（所属章节标题）、coordinates（如果块内包含坐标，提取其范围）、data_type（正文/表格/公式/批注）、confidence（清洗置信度，OCR和编码探测的置信度）、timestamp（清洗时间）。

这些元数据在检索时发挥多重作用。第一，过滤：用户可以限定只在“表格”类型中检索，或者只在某个坐标范围内检索。第二，排序：置信度高的块优先返回。第三，溯源：检索结果可以显示原始文件名和页码，方便人工核对。第四，去重：同一内容在不同文档中重复出现时，根据来源和时间戳判断优先级。

元数据的注入方式是在切分时同步完成。每个块生成时，从解析层传递下来的位置信息直接附加到块的属性中。对于坐标范围，我写了一个正则提取器，从块文本中识别坐标模式并计算边界框。这个提取器覆盖了度分秒、十进制、带方向等多种格式。

def create_chunk_with_metadata(text, source_info): """创建带元数据的文本块""" chunk = { 'text': text, 'metadata': { 'source_file': source_info.get('file_name'), 'file_type': source_info.get('file_type'), 'page_number': source_info.get('page'), 'section_title': source_info.get('section'), 'data_type': source_info.get('type', 'text'), 'confidence': source_info.get('confidence', 1.0), 'timestamp': datetime.now().isoformat() } } # 提取坐标范围 coords = extract_coordinates(text) if coords: chunk['metadata']['coordinates'] = coords return chunk def extract_coordinates(text): """从文本中提取坐标范围""" patterns = [ r'(\d+)[°\s]+(\d+)[\'\s]+(\d+\.?\d*)[\"\s]*([NSEW]?)', r'(\d{2,3}\.\d{4,8})' ] coords = [] for pattern in patterns: matches = re.findall(pattern, text) for match in matches: if isinstance(match, tuple): decimal = dms_to_decimal(match) else: decimal = float(match) coords.append(decimal) if coords: return {'min': min(coords), 'max': max(coords)} return None

4.3 向量化模型的选择与微调

清洗后的文本块需要编码成向量。通用中文向量模型（如text2vec、m3e）在通用语料上表现不错，但在探矿专业术语上经常失准。我测试过，用通用模型检索“矽卡岩型铜矿的蚀变分带”，返回的结果里混入了大量“砂岩型铀矿”的内容，因为模型没有区分“矽卡岩”和“砂岩”的语义差异。

我的解决方案是领域微调。用探矿报告、地质论文、规范标准构建了一个约5万对的训练集，每对包含一个查询和正负样本。用对比学习的方式微调text2vec模型，让模型学会区分地质术语。微调后的模型在内部测试集上的召回率从62%提升到81%。微调的成本不高，一张消费级显卡跑几个小时就能完成，但效果提升非常明显。

对于表格和数值数据，通用文本向量模型效果更差。我的做法是对表格单独建索引：把表格转成结构化数据后，用数值特征（品位均值、坐标中心、厚度范围）建一个标量索引，检索时先用标量索引过滤，再用文本向量做语义匹配。这种混合索引的方式，让“查找铜品位大于0.5%且位于某坐标范围内的样品”这类查询的响应时间从秒级降到毫秒级。

实操心得：向量化之前一定要做文本归一化。全角转半角、繁体转简体、单位统一、数字格式统一。这些看似琐碎的操作，对检索精度的影响很大。我做过对比实验，不做归一化时，检索“Cu品位0.8%”无法命中“铜品位0.80%”的文档；做了归一化后，两者能正确匹配。

5. 常见问题排查与避坑指南

5.1 编码与乱码问题速查

编码问题是TXT和网页清洗中最常见的故障。我整理了一个速查表，覆盖了实际项目中遇到的大部分情况。

编码问题的根本解决思路是不要相信声明，要相信字节。文件头声明的编码、HTTP响应头的编码、meta标签的编码，都可能与实际不符。唯一可靠的方法是直接分析字节流，用统计方法推断编码。chardet和charset-normalizer都是不错的选择，后者对新版Python支持更好。

5.2 PDF解析失败的典型场景

PDF解析失败的原因五花八门，我按出现频率排了个序。第一位是加密PDF，表现为PyMuPDF打开时报错或返回空文本。解决方案是先用pdf.is_encrypted检查，如果是仅限制复制的加密，可以用pdf.authenticate('')尝试空密码；如果是强加密，需要合法获取密码，绝不能尝试破解。

第二位是损坏PDF，表现为文件头正常但中间数据损坏。PyMuPDF的repair参数可以尝试修复，但修复后的内容可能不完整。我的做法是先用qpdf做一次修复，再用PyMuPDF读取，如果仍然失败，标记为“无法解析”并记录，后续人工处理。

第三位是字体嵌入问题，表现为文本层存在但提取出来是乱码或空白。这是因为PDF使用了自定义编码的字体，没有正确的ToUnicode映射。这种情况下PyMuPDF也无力回天，只能走OCR。我的判断方法是：如果get_text()返回的字符中非ASCII比例异常高，或者大量字符的Unicode码点在私用区，就判定为字体问题，自动切换到OCR流程。

第四位是版面分析错误，表现为多栏文档的阅读顺序错乱。XY-Cut算法对规则版面效果好，但对不规则版面（比如文字环绕图片）会失败。我的补充方案是引入版面检测模型（如LayoutParser），用深度学习识别标题、正文、表格、图片区域，再按区域类型重组阅读顺序。这个方案计算量大，只在XY-Cut置信度低时启用。

5.3 检索精度不达标的调优思路

如果清洗流程走完了，但检索精度仍然不理想，我通常按以下顺序排查。第一，检查切分粒度。块太大，语义不聚焦；块太小，上下文丢失。我的经验值是中文块300到800字符，英文块500到1200字符。第二，检查向量模型。用几个典型查询测试，看返回结果是否语义相关。如果模型对领域术语不敏感，考虑微调或换用领域预训练模型。

第三，检查元数据过滤。有时候检索精度低是因为噪声块太多，比如页眉页脚、导航栏没有被完全清除。通过元数据过滤掉低置信度块或非正文块，精度会明显提升。第四，检查查询改写。用户输入的查询可能太短或太模糊，比如只输入“铜品位”，没有限定范围。引入查询改写模块，把短查询扩展成完整问句，或者自动提取实体和约束条件，能显著改善召回。

第五，检查重排序。向量检索返回的Top-K结果中，真正相关的可能排在后面。引入交叉编码器做重排序，对Top-50结果重新打分，能把最相关的排到前面。这个步骤会增加延迟，但对精度提升明显，我通常只在最终答案生成前做一次重排序。

注意：调优是一个迭代过程，不要指望一次调整就达到理想效果。我的做法是建立一个评估集，包含50到100个典型查询和对应的正确答案，每次调整后跑一遍评估集，看召回率和精确率的变化。没有评估集的调优就是盲人摸象。

5.4 独家避坑技巧汇总

第一个技巧是保留原始文件快照。清洗过程中产生的中间文件（解码后的TXT、提取的XML、OCR的文本）全部保留，按项目和时间戳归档。当检索结果出现异常时，可以快速回溯到原始文件核对。这个习惯帮我定位过多次“数据对不上”的问题，最后发现是某个中间环节的编码转换错误。

第二个技巧是清洗日志要详细。每个文件的处理过程、遇到的异常、采取的措施、最终的置信度，全部记录到日志中。日志用结构化格式（JSON Lines），方便后续统计和排查。我通过分析日志发现，某个批次的PDF扫描件OCR置信度普遍偏低，追查后发现是扫描分辨率只有150dpi，后来要求重新扫描到300dpi，识别率大幅提升。

第三个技巧是人工校验接口。自动清洗不可能100%准确，必须保留人工校验的通道。我的做法是生成一个校验清单，列出所有置信度低于阈值的块，附上原始文件位置和清洗结果，交给地质人员核对。校验结果反馈回系统，用于调整清洗参数。这个闭环让清洗质量持续提升。

第四个技巧是版本控制。清洗管线、领域词典、微调模型、评估集，全部用Git做版本控制。每次调整都提交记录，方便回滚和对比。我吃过亏，有一次调整了切分参数，导致检索精度下降，但没有记录改了什么，花了半天才找到原因。从那以后，所有配置变更都必须提交。

第五个技巧是分阶段验证。不要等整个管线跑完再验证，而是每层输出后都做抽样检查。解码层检查编码是否正确，解析层检查结构是否完整，清洗层检查噪声是否去除，切分层检查语义是否完整。分阶段验证能快速定位问题出在哪一层，避免在错误的基础上继续叠加错误。

6. 从清洗到检索的完整链路回顾

6.1 一个真实项目的端到端复盘

去年我参与了一个铜多金属矿的详查项目，需要把过去十年的地质资料整理成可检索的知识库。资料包括：1200个TXT化探数据文件、86份Word设计书和报告、340份PDF图件和外部报告、约200个网页资料页面。原始资料总量约45GB，清洗后得到约12万个文本块，存入向量数据库。

整个流程耗时约三周，其中清洗占了两周，向量化和索引占了一周。最大的时间消耗在PDF处理上，340份PDF中有87份是扫描件，需要OCR和人工校验。TXT和Word的处理相对顺利，主要问题是编码和公式。网页资料最少，但噪声最多，Readability加自定义规则花了三天调试。

最终检索效果：对于“某矿体铜品位分布特征”这类查询，Top-5结果的相关率达到90%以上；对于“某坐标附近的钻孔见矿情况”这类空间查询，结合标量索引后响应时间在200毫秒以内。地质人员反馈，以前查一个数据要翻半天报告，现在几秒钟就能定位到原文，效率提升非常明显。

6.2 清洗质量对检索效果的影响量化

我做过一组对比实验，用同一套检索模型，分别用未清洗、基础清洗、深度清洗的文本库测试。未清洗的文本库包含大量乱码、页眉页脚、导航栏，检索召回率只有35%。基础清洗去除了明显噪声，但保留了格式错误和语义断裂，召回率提升到58%。深度清洗做了编码归一化、版面分析、语义切分、元数据注入，召回率达到82%。这个实验说明，清洗质量对RAG系统的最终效果有决定性影响，投入时间做深度清洗是值得的。

另一个发现是，元数据的价值被严重低估。在深度清洗的基础上，如果再加上元数据过滤（比如限定只在表格中检索），召回率能进一步提升到89%。元数据让检索从“全文匹配”变成“结构化匹配”，精度提升显著。

6.3 后续扩展方向

这套清洗管线目前主要处理文本和表格，对图件的处理还比较初级。地质图件（剖面图、平面图、柱状图）包含大量空间信息，如果能把图件中的坐标、产状、品位标注提取出来，与文本数据关联，检索能力会再上一个台阶。我正在尝试用版面检测加OCR的方式提取图件标注，初步效果还可以，但复杂图件的准确率还有待提升。

另一个方向是知识图谱融合。把清洗后的文本块中的实体（矿体、钻孔、地层、构造）和关系（空间关系、成因关系、时序关系）抽取出来，构建知识图谱，与向量检索结合。这样既能做语义检索，也能做关系推理。比如查询“与某矿体成因相关的侵入岩”，向量检索可能返回文本片段，知识图谱则能直接给出岩体名称和空间关系。

清洗管线的自动化程度也可以继续提升。目前编码探测、版面分析、OCR置信度评估已经自动化，但异常处理还需要人工介入。我在尝试用主动学习的方式，让模型自动识别低置信度的块，优先交给人工校验，人工反馈再用于模型迭代。这个闭环如果跑通，清洗效率还能再提升一个量级。

我个人在实际操作中的体会是，RAG清洗没有一劳永逸的方案，每个项目的数据特点不同，需要针对性地调整参数和规则。但核心原则是通用的：保留原始信息、分层处理、分阶段验证、持续迭代。把这四点做到位，即使工具不是最先进的，效果也不会差。最后再分享一个小技巧：清洗过程中遇到拿不准的情况，宁可保留原始格式也不要擅自“美化”，因为地质数据的精度要求极高，一个自动“修正”可能引入难以察觉的错误。保留原始信息，把判断权交给地质人员，这是我在多个项目中总结出的最稳妥的做法。