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行分段探测每段独立解码后再拼接。对于无法解码的字节用errorsreplace替换成占位符同时记录位置后续人工核对。这个策略让编码问题的处理成功率从60%提升到95%以上。解码之后是分隔符归一化。我写了一个自适应解析器先统计每行中空格、制表符、逗号、分号的出现频率选择频率最高且列数最一致的分隔符作为主分隔符。对于列数不一致的行尝试用正则表达式匹配数值模式来重新切分。比如一行是“ZK001 120.5 0.85 0.02”另一行是“ZK002,130.2,0.92,0.03”解析器能自动识别出两种格式并统一成四列。数值标准化是另一个重点。地质数据中坐标的格式五花八门度分秒115°2345、十进制115.395833、带方向115°2345E、甚至用空格分隔115 23 45。我写了一套转换函数统一转成十进制度并保留原始格式作为元数据。品位数据则要处理单位问题%和ppm、g/t和10^-6全部统一到ppm存储但在输出时根据上下文还原单位。import re import chardet def detect_encoding_segmented(file_path, segment_lines1000): 分段探测编码解决混合编码问题 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:isegment_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, namespacesns): 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), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return rotated实操心得PDF清洗中最容易被低估的是阅读顺序重建。多栏排版、文本框、图注混排的页面如果按坐标从上到下、从左到右简单排序会把不同栏的内容交错在一起。我的做法是用XY-Cut算法递归切分页面先找水平空白带切分上下区域再找垂直空白带切分左右栏直到每个区域只包含一个文本块。这个算法在PyMuPDF的坐标信息基础上实现对双栏地质报告的效果很好。3.4 网页资料正文提取与噪声过滤探矿业务中的网页资料主要来自公开地质资料馆、行业标准网站、学术论文页面。这些页面的共同问题是噪声比例极高。一个典型的资料页面导航栏、侧边栏、广告、推荐阅读、评论区可能占80%的面积真正的正文只有中间一小块。如果直接抓取整个HTML丢进向量库检索时会被大量无关内容干扰。我的网页清洗流程分三步。第一步用Playwright渲染页面等待JavaScript执行完成获取完整的DOM。第二步用Readability算法提取正文。Readability是Firefox阅读模式的核心算法它通过分析DOM节点的文本密度、链接密度、标签类型来打分得分最高的节点就是正文。第三步是后处理去除正文中的图片说明、表格注释、参考文献编号把相对链接转成绝对链接把HTML标签转成Markdown格式。对于地质资料馆这类结构化程度较高的网站Readability可能不够精准。我的补充方案是自定义规则提取。比如某个资料馆的页面结构固定正文在div classcontent里表格在table classdata-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_untilnetworkidle) 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### 表格{i1}\n{table.to_markdown()}) # HTML转Markdown soup BeautifulSoup(content_html, html.parser) text soup.get_text(separator\n, stripTrue) return { text: text, tables: table_markdown, title: doc.title() }注意网页抓取必须遵守网站的robots.txt规则控制请求频率避免对目标网站造成压力。我在实际项目中会把抓取间隔设置为3到5秒并缓存已抓取的页面避免重复请求。对于需要登录的页面绝对不要尝试绕过认证而是通过正规渠道获取数据授权。4. 语义切分与元数据注入的实操细节4.1 切分策略从固定长度到语义边界清洗后的文本如果直接按固定字符数切分会切断句子、切断表格、切断公式导致向量化后的语义碎片化。我最初用LangChain的RecursiveCharacterTextSplitter设置chunk_size500overlap50结果检索时经常返回半句话大语言模型无法理解。后来改成语义边界切分以段落、标题、表格、公式为最小单元只有当一个语义单元超过阈值比如800字符时才进一步切分。具体规则是一级标题作为大章节边界二级标题作为小节边界段落作为基本单元。表格整体作为一个单元不切分。公式连同其上下文前后各一段作为一个单元。批注和修订记录单独成块。这样切分出来的块每个都有完整的语义向量化后检索精度明显提升。对于TXT数据文件切分逻辑不同。化探数据通常按采样批次或图幅切分每个批次作为一个块。钻孔数据按孔号切分每个孔的所有测井数据作为一个块。这样检索“ZK001的铜品位”时能直接命中该孔的数据块而不是返回一堆无关孔的数据。4.2 元数据设计让每个块都可追溯元数据是RAG清洗中最容易被忽视但价值最高的部分。我设计的元数据字段包括source_file原始文件名、file_typeTXT/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 None4.3 向量化模型的选择与微调清洗后的文本块需要编码成向量。通用中文向量模型如text2vec、m3e在通用语料上表现不错但在探矿专业术语上经常失准。我测试过用通用模型检索“矽卡岩型铜矿的蚀变分带”返回的结果里混入了大量“砂岩型铀矿”的内容因为模型没有区分“矽卡岩”和“砂岩”的语义差异。我的解决方案是领域微调。用探矿报告、地质论文、规范标准构建了一个约5万对的训练集每对包含一个查询和正负样本。用对比学习的方式微调text2vec模型让模型学会区分地质术语。微调后的模型在内部测试集上的召回率从62%提升到81%。微调的成本不高一张消费级显卡跑几个小时就能完成但效果提升非常明显。对于表格和数值数据通用文本向量模型效果更差。我的做法是对表格单独建索引把表格转成结构化数据后用数值特征品位均值、坐标中心、厚度范围建一个标量索引检索时先用标量索引过滤再用文本向量做语义匹配。这种混合索引的方式让“查找铜品位大于0.5%且位于某坐标范围内的样品”这类查询的响应时间从秒级降到毫秒级。实操心得向量化之前一定要做文本归一化。全角转半角、繁体转简体、单位统一、数字格式统一。这些看似琐碎的操作对检索精度的影响很大。我做过对比实验不做归一化时检索“Cu品位0.8%”无法命中“铜品位0.80%”的文档做了归一化后两者能正确匹配。5. 常见问题排查与避坑指南5.1 编码与乱码问题速查编码问题是TXT和网页清洗中最常见的故障。我整理了一个速查表覆盖了实际项目中遇到的大部分情况。现象可能原因排查方法解决方案中文全部变成问号用UTF-8读取GBK文件用chardet探测编码按探测结果重新解码部分中文正常部分乱码混合编码文件分段探测编码分段解码后拼接出现“锟斤拷”UTF-8和GBK互转错误检查文件头BOM去除BOM后重新解码网页中文乱码页面声明编码与实际不符检查meta标签和响应头以实际字节流探测为准特殊符号丢失编码不支持该字符检查字符Unicode范围用errorsreplace并记录位置编码问题的根本解决思路是不要相信声明要相信字节。文件头声明的编码、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清洗没有一劳永逸的方案每个项目的数据特点不同需要针对性地调整参数和规则。但核心原则是通用的保留原始信息、分层处理、分阶段验证、持续迭代。把这四点做到位即使工具不是最先进的效果也不会差。最后再分享一个小技巧清洗过程中遇到拿不准的情况宁可保留原始格式也不要擅自“美化”因为地质数据的精度要求极高一个自动“修正”可能引入难以察觉的错误。保留原始信息把判断权交给地质人员这是我在多个项目中总结出的最稳妥的做法。