刚开始接手探矿业务的知识库项目时我以为自己面对的最大难题会是“向量化模型选型”或者“检索链路调优”。真正跑起来才发现所有的瓶颈都汇成了一句话文档还没洗干净谈什么高精度检索。TXT、Word、PDF、网页这四种在探矿业务中几乎覆盖了从老地质队员手写扫描件到数据库导出文件的全谱系而它们恰恰也是RAG系统摄入阶段的四大“灾区”。乱码不是玄学是编码、字体和解析器之间的一场混战。如果这一步处理不彻底后面无论你用多先进的Embedding模型检索到的都是带噪声、脏字符、甚至语义错乱的片段。这篇文章完全从实操出发我把自己在探矿项目里踩过的坑、拆过的文件、写过的清洗正则和分块策略全部整理出来给正在做RAG工程化或者知识库建设的朋友一份可以参考的“避坑指南”。1. 探矿文档的“混合毒打”为什么RAG检索一上来就翻车1.1 四种格式的典型乱象TXT编码、Word表格、PDF扫描件、网页动态加载探矿业务的数据来源非常杂我总结下来基本盘是这四种TXT文件多来自老式数据库导出、GPS设备的点位记录、测井仪器的原始输出。乍看是纯文本天生适合RAG但编码问题极其头疼。国内探矿历史数据里GB2312、GBK、UTF-8、UTF-16、ANSI混着来。最典型的是某个繁体地质报告用GBK编码打开后直接输出成“锟斤拷”这种乱码这种字节错位一旦发生信息就永远丢了如果清洗阶段不做编码检测后面所有工序都是白费。Word文件在探矿业务里扮演的是“正式成果”角色——储量估算报告、岩芯拍照描述表、勘探设计书。它的坑不是文字本身而是结构化内容表格由几百个小单元格拼成坐标和岩性描述挤在一起公式用公式编辑器嵌入提取出来变成OLE对象还有批注、修订痕迹、文本框、页眉页脚混在里面解析时稍微一疏忽正文段落就会被截断。PDF文件是探矿资料归档的主力格式也是最难啃的骨头。文本型PDF还好用解析库能直接把内容抽出来最怕的是扫描型PDF——老的地质报告是A4纸扫描的有的甚至带手写批注、红章、折痕不跑OCR根本拿不到文字。而混合型PDF更麻烦前半本是扫描首页后半本有文本层不做页面级判断直接解析结果就是一半能搜到一半检索永远为空。网页内容多来自公开的地质资料网站、储量评审公示、矿业权公告信息。看着是HTML但不少是动态渲染表格数据靠JavaScript异步加载直接requests抓回来只有空壳需要用渲染工具等待页面加载完成后才能拿到完整DOM。这四种格式混在一个知识库里如果清洗策略“一刀切”基本上是顾此失彼用纯文本清洗规则去处理PDF结果连换行符的问题都处理不了用网页提取规则去处理TXT又会把正常行误判成噪声。1.2 清洗不是“锦上添花”而是RAG的地基很多人对RAG有一种错觉认为只要切片够多、向量模型够好就能保证检索精度。我举个反例把一份矿调报告里的坐标“东经118°23′45″”切片之后如果清洗阶段没把半角撇号“′”和全角“’”统一检索时用户问“东经118度23分45秒”就完全匹配不上。再比如老PDF通过OCR识别出的“铁矿石Fe含量45%”其中“Fe”被识别成“F e”中间插入空格或者数字“45”被OCR成“4 5”这种噪声会让向量检索结果偏移。清洗的本质是把原始文件里影响语义的噪声去掉然后给文本一个稳定的、可检索的形态。这个过程做不好RAG系统吃的就是带沙子的米模型再强大也吐不出干净的结果。我在项目里给团队定过一个原则清洗不通过下游链路不接受。每条文档入库前必须经过清洗质检宁可入库慢也不允许脏数据混进索引。1.3 探矿行业特有的检索难点区块编号、矿种别名、坐标精度单纯把文本洗干净还不够探矿业务自带几个检索难点必须在这一层就提前设计处理策略。第一是区块编号的变体。同一个矿区报告首页写着“江西省XX县XX矿区铜多金属矿详查报告”正文里可能缩写为“XX铜矿详查”表格里又写作“XX矿区铜”。如果清洗阶段不做编号归一化用户检索“XX矿区详查报告”时系统可能命中别的报告。第二是矿种别名问题。黄铜矿、铜矿、Cu矿、硫化铜矿在专家术语里指同一类东西但机器不管。清洗时要建一个矿种同义词表在分词和切片前把术语统一这个步骤直接决定检索召回率。第三是坐标精度和格式。探矿报告的坐标有三种表示方式经纬度度分秒、十进制经纬度、高斯投影坐标X/Y带带号。同一本报告中可能混着三种如果不统一后续做空间检索就完全失信。清洗时可以用正则把坐标提取出来转成统一格式写回文档元数据里这一步对后面的地理语义检索帮助极大。2. 从原始文件到可解析文本解析层怎么做2.1 TXT先解决编码再谈清洗TXT文件看起来最无脑实际上编码检测的坑比想象中多得多。我强烈建议不要依靠单个库自认为的“自动检测”因为在中文场景下猜错编码的概率不低。我自己在项目中稳定运行的方案是三步式第一步用chardet做一次大范围编码猜测设置一个候选字符集列表优先级按探矿老文件的实际情况排列GB18030、GBK、UTF-8、BIG5、UTF-16LE、UTF-16BE。第二步用charset_normalizer对结果做交叉验证。单靠chardet容易在一些短文件上误判加上第二个库交叉判断能极大降低误判率。第三步对于典型的探矿仪器导出文件很多其实是“GBK编码 固定宽度字段”的老结构。这类文件用通用编码检测法反而效果差因为它们可能夹杂二进制字段。我的处理方式是先读文件头判断是否有明显的字段分隔符逗号、制表符、空格如果有分离结构就应该按CSV或固定宽度来解析而不是单纯当纯文本读。实际的编码归一化例子如下import charset_normalizer from chardet import detect def read_text_file(path): raw open(path, rb).read() # 第一轮用chardet快速探测 guess detect(raw) enc guess.get(encoding, utf-8) # 第二轮用charset_normalizer交叉验证 better charset_normalizer.from_bytes(raw).best() if better and better.encoding ! enc: enc better.encoding # 尝试按候选编码解码 for encode in [enc, gb18030, utf-8]: try: return raw.decode(encode) except (UnicodeDecodeError, UnicodeError): continue return raw.decode(gb18030, errorsreplace)这里有个重要细节errorsreplace只是兜底不是方案。如果真的走到这一步要标记该文件为“可疑乱码”写进清洗日志后续人工抽检。不能沉默地把坏字符送进知识库。2.2 Word表格和公式是两个大坑Word处理我用的是python-docx为主、Pandoc为辅的策略。先说表格。python-docx解析Word表格时会拿到张量级嵌套的表格结构探矿报告的表格往往是一个大表套多个小表甚至用合并单元格表示数据归属关系。如果直接遍历个位数单元格输出顺序会错而且合并单元格带来的重复值会把清洗规则搞晕。我处理表格有两个原则按“行优先”读取遇到合并单元格时将这个单元格的值填充到所有跨行跨列的位置保证每一行都是齐整的数据。表格数据不要直接拼成大文本而是先提取成“结构化记录”再转成文本。比如钻孔岩芯数据表的每一行应该拼成“孔深XX米岩性为XX采取率XX%”这种语义化句子而不是把表格的原始内容原样堆砌。公式处理是另一个大坑。Word里嵌入的公式如果是使用LaTeX类似字体或MathType写入的python-docx默认只能拿到OLE对象拿不到可读文本。我的做法是优先尝试提取oMath对象Word自带的公式结构拿到UnicodeMath格式的公式文本如果是MathType那就需要借助转换工具把公式转成图片再走OCR。不过更稳妥的方案是在设计清洗流程时就确认公式在业务中的价值。对于探矿业务真正需要保留的公式不多多数是氧化还原电位计算式、品位加权公式等这类公式对检索的实际意义不大有时直接处理成“公式见附件”反而更干净。我在项目里把这类公式单独存成一个JSON元数据字段检索时不参与向量化需要时再展示。2.3 PDF文本型、扫描型、混合型的解析策略PDF解析是我投入时间最多的部分探矿业务的PDF花样实在太多。对于文本型PDF首选pdfplumber。它在识别表格和坐标信息上比PyPDF2和pdfminer更强。探矿报告中很多表格边框并不标准pdfplumber能根据字符位置重构表格结构这一点在解析钻孔参数表时特别有用。要注意的是探矿报告里的换行规则由于排版原因一句话可能被拆成两行直接拼接会把“矿石类型磁铁 矿”这种内容引入导致语义错误。解决方式是开启x_tolerance参数让同一行内间隔较近的字符合并同时用末尾标点判断句子是否完整。对于扫描型PDF方案不是直接OCR整本而是先做图像预处理再分段识别。我在项目中稳定跑通的链路是PyMuPDFfitz按页渲染成PNG图片 → OpenCV做灰度化和二值化 → 用Tesseract或PaddleOCR识别。如果原页面有手写批注还要先裁剪出手写区域单独识别并标记为“人工批注”避免和正文混在一起。对于混合型PDF关键是页面级判断。我写了一个简单分类器解析某一页时如果发现文本层字符密度特别低比如每页少于50个字符就判定为扫描页如果字符密度正常就用文本抽取。这样同一本PDF可以分段处理扫描页走OCR文本页走pdfplumber最后再按页顺序合并效率和精度都有保障。2.4 网页动态渲染下的正文提取网页数据在探矿业务中通常来自各类矿业平台、储量公示系统其特点是以表格为主的动态页面。用requests直接get往往拿不到表格数据因为很多站点加载数据时走XHR异步请求数据在浏览器的内存里不在HTML源码中。我的做法是先用Playwright启动一个真正的浏览器设置常用的User-Agent打开页面后显式等待networkidle状态或特定的表格加载完成节点。拿到完整HTML之后再用BeautifulSoup或lxml抽取核心DOM。抽取时探矿网站必须处理的一个问题是“信息噪音”导航栏、广告区、相关推荐、版权信息这些如果在清洗时不排除会占据大量向量空间稀释真正有价值的报告内容。我维护了一份公共的CSS选择器黑名单和正文识别规则优先使用article、table、.content、#main这类结构标签定位正文。对于无法通过结构识别的页面退回到“正文密度算法”——按文本块统计中文字符占比超过阈值才视为正文。3. 文本清洗的核心工序从乱码到规范文本3.1 清洗流水线的标准工序解析层解决的是“文件到文本”的问题清洗层解决的是“文本到语义稳定文本”的问题。我把清洗流水线固定为以下7步每一步都有明确的输入输出方便排查字符集归一化将全角英文转半角、统一引号、破折号、空格类型。去除控制字符删除不可见字符、替换符、零宽空格。去除页眉页脚通过正则识别常见页眉模式如“第X页 共Y页”、“XX矿区详查报告”、“XX地质队”。修复断行将硬换行与段落结束符区分开合并中间断开的句子。表格结构化提取对表格区域执行行列还原输出为“每一行一条记录”文本。公式特殊处理将公式转成占位符或单独元数据不参与后续清洗。术语归一化替换同义词、统一矿种名称、修正OCR常见错字。这套工序如果中间任何一个环节断掉最终构建出的Embedding都会存在偏差。比如页眉页脚不去除检索“共Y页”这种词都可能命中一堆无关文档完全干扰高精度检索。3.2 处理表格探矿报告里最宝贵的结构化信息探矿报告表格里的内容密度远超正文品位数据、钻孔坐标、储量计算表、化验结果几乎都是结构化关键信息。如果按普通文本顺序拼接表格的列语义会完全丢失检索者问“ZK301孔深300米处岩性”系统根本找不到。我在清洗时单独为表格设计了一条处理分支。取一行数据时先获取表头再把单元格值和表头组成键值对最后构建成语义化文本。举例说明一个表格如果表头是“孔号/孔深/矿体编号/矿石类型/品位/(%)”其中一行数据是“ZK301/320m/Fe-1/磁铁矿/42.5”清洗后输出的句子是“孔号ZK301孔深320米矿体编号Fe-1矿石类型磁铁矿品位42.5%”。这样既保留了原表的对应关系又让文本的表达接近自然语言Embedding之后检索匹配度会显著提升。这里有个很重要的坑表格中经常有“同上”“〃”“-”这类表示重复或空值的符号。清洗时必须把“同上”替换成上一行的对应值“-”有时表示无数据有时表示零要结合具体业务判断不能一刀切删除。3.3 处理公式从Word公式/图片到可检索文本探矿报告中公式数量不算多但一旦出现就非常关键。比如计算矿石平均品位时用到的加权公式直接关系到资源量估算结果。这类公式通常以三种形态出现Word原生公式、图片式公式、扫描PDF里的手写公式。对Word原生公式我尝试用python-docx提取oMath结构。如果成功就保留为LaTeX或UnicodeMath格式文本标注类型是“公式”单独入库。对图片式公式传统OCR识别公式的准确率很低如果盲目转文本会把分式结构识别成乱码。我的经验是只要这个公式不是检索的核心语义部分就把它替换成公式占位符[公式:xx]同时把图片单独存档不参与文本检索。这样既不污染向量空间又保留了原始档案的完整性。对扫描PDF里的公式我会在图像预处理阶段用模板匹配识别公式区域裁剪下来按公式图处理。试过用Mathpix这类工具转LaTeX精度还不错但对清晰度和中文文章混排支持有限整体还是以占位符为主这是更稳妥的选择。3.4 统一术语矿种别名的合并探矿业务里同一个矿种的说法太多直接影响检索召回。比如“铝土矿”有时写成“铝矿”“铝土”“铝矾土”“铅锌矿”在不同资料里可能是“铅锌矿”“铅锌”“PbZn矿”。我的做法是维护一个矿种术语别名表在清洗管道里做映射归一。这里有一个原则性的细节不要做“广谱同义词替换”只替换能明确对应到唯一实体的术语。否则容易把“铜矿”这种大类术语误替换成具体矿物名让检索结果范围缩小。术语归一后强烈建议给每个文档加上“实体元数据”字段内容包括矿区编号、主要矿种、行政区位置、坐标范围、报告类型。这些实体字段在后期做过滤检索时非常有用能把“地理上无关但语义相似的文档”排除掉。3.5 质控如何用采样抽样评估清洗质量清洗流程跑完后必须做质量评估否则你不知道干净到什么程度。我在项目里设计了一套抽检方案按文件分类各抽5%的样本人工检查四个维度乱码率异常Unicode替换符数量占总字符数的比例阈值设为0.1%。句子完整率以句号、分号结尾的比例不完整句子主要是断行没处理好。表识别率对表格样本文档检查跨行跨列的表头是否被正确填充数值是否错位。关键术语命中率检查矿种名称、区块编号是否归一化成功。抽检不合格的文档自动打回重洗清洗参数调整后再次测试。我们在实践中发现一次清洗流程通常需要迭代三到五轮才能稳定这是完全正常的过程不要指望一轮就通过。4. 从清洗走向高精度检索分块与元数据4.1 分块策略按文档结构分还是按语义分清洗完的文本要进入RAG链路首先面对分块问题。探矿报告有个特点结构化强章节清晰但段落之间的逻辑跳跃也比较大——前一页还在讲区域地质背景下一页就进入钻孔描述。这种内容如果按固定长度盲目切块很容易把两个不相干的主题切进一个块里检索时会召回到语义混杂的内容。我倾向于以文档结构为准的分块策略。探矿报告的标题层级就是从“章”到“节”再到“小节”我可以根据标题级别定义切块粒度比如“节”为默认切片单位如果一节内容太长再按段落拆开到子块。但结构分块有个副作用不同章节长度差异很大。有的节只有一行字有的节有几十页表格。因此我将长文档设置一个最大分块长度比如1500字超出上限的部分按句子边界二次切分并设置块间重叠如100字保证边界语义不断裂。4.2 元数据标注让“高精度检索”落地的关键清洗完成后我建议立即给每条文本块打上元数据而不是等到入库之后再补。探矿业务需要的元数据字段我列出几个重要的字段示例作用数据来源江西省地质调查院提交XX报告检索时按来源过滤矿区编号JX-2024-CU-012精确定位矿区地理坐标东经118°23′45″北纬29°45′12″支持空间过滤报告类型详查报告/普查报告/储量核实报告分类过滤文档格式Word/PDF/TXT/HTML排查清洗问题清洗状态通过/待复检/含公式占位符质检与回退采样位置ZK301孔深300-320m钻孔级定位这些元数据在检索阶段的价值体现在两个环节。第一前置过滤用户检索时可以通过元数据字段做强制过滤比如只搜“江西铜矿详查报告”这里不是靠向量相似度而是靠元数据精确匹配精度立刻提升。第二后置加权向量检索返回结果后通过元数据做重排把“矿区编号精确匹配”的文档排到前面。4.3 检索精度的评估不能只看RecallK探矿项目里我评估检索精度不是单纯看RecallK和MRR这些小指标因为业务侧更关心“我要找的那段话到底有没有排在前三名”。我用的是一套混合评估方案人工构造查询集从业务人员那里收集50条典型问题比如“XX矿区ZK302孔的铁矿厚度是多少”“XX报告矿石品位参数是多少”。这些问题本身带着探矿业务独有的术语能测试清洗环节是否到位。答案命中率判断正确答案出现在检索结果前5条中的占比。夹取错误率检索结果中混入的域外内容比如别的矿区文档占比这个指标能直接反映出元数据过滤是否生效。实践中通过清洗优化答案命中率可以从初始的60%以下提升到85%以上夹取错误率可以从20%降到5%以内。这个提升不是模型换出来的是清洗换出来的。4.4 High-Precision检索的两条隐藏链路除了文本向量检索探矿业务中还有一个容易被忽略的检索路径表格内数值检索。比如用户问题是“品位大于40%的铁矿石有多少吨”这个问题纯粹靠文本向量很难精确回答因为文档里表格的数值和文本的措辞并不一致。针对这种情况我建议从清洗阶段就把表格数据单独抽出来构建一个结构化索引解决这类“数值/空间/时间精确条件”的查询场景与向量检索形成互补。结构化数据检索、向量检索、元数据过滤三者形成的混合检索框架是探矿业务中最终能达到高精度检索效果的关键。千万别一上来就只铺向量检索那是把路走窄了。5. 实战排查乱码、解析失败与检索偏差的处置实录5.1 乱码的真实案例与小修方案案例1GBK文件被错误解码成UTF-8现象是全文出现大量“锟斤拷”和“烫烫烫”。这种乱码非常典型原因是UTF-8解码器把GBK双字节序列误当成单码点。我的排查思路是看到“锟斤拷”直接确定源编码是GBK系改用GB18030重解。如果重解后仍有个别字符乱那么这个字符大概率是繁体生僻字需要人工以字形或图片补录。案例2繁体中文报告编码正常但检索失效问题不在编码而在繁体与简体差异。探矿老报告大量使用繁体字用户检索词是简体Embedding模型对繁简字形差异不敏感跨字体会显著影响检索准确率。我的方案是清洗流水线里增加一步繁简转换OpenCC把GBK繁体文件统一转简体再做分块。案例3UTF-16文件含BOM首行出现“”字符BOM字符在Notepad里看不见但在程序解析时会被当作额外字符。我的处理是在编码归一化阶段就删除BOM否则BOM会附着在第一个切片文字前面污染整个切片的Embedding。5.2 解析失败与处理心得Word表格行数太多导致内存溢出python-docx在处理超大Word文档时内存占用惊人。一个500页的勘探报告会直接把进程杀死。我的方案是先用Pandoc把Word转换成Markdown或纯文本再按章节顺序读取必要时对文档做分段处理而不是一次性加载全部对象。PDF字体子集化导致的乱码扫描型PDF里常见一种情况PDF文件是用特殊字体子集方式嵌入的复制文本时能复制但提取出来的字符映射全乱。这种情况说明这个PDF没有真正的Unicode文本层需要用OCR替代文本提取。检查方式很简单提取到的文本里如果有大量Unicode私有区字符或者和原显示字形完全不符就应该放弃文本层走图像OCR路线。网页数据被验证码拦截探矿类的政府或行业平台经常有访问频率限制。我的建议是控制爬取频率加真实浏览器的headers并对重要数据进行页面快照存储。一旦当天获取失败可以通过快照补录避免数据源断档影响知识库更新。5.3 检索偏差的三类处置思路第一类偏差是“术语不匹配”。用户检索“铜矿石”但文档里写“硫化铜矿石”向量模型可能匹配到相似但不完全一致的内容。这类只能靠术语归一化和同义扩展处理我在清洗阶段已经做过另外还会在检索阶段维护一个同义词扩展列表。第二类偏差是“粒度不匹配”。用户问“某矿区的储量”但文档拆成了多个区块切片每个切片只包含一个区块的储量检索时召回结果分散在各块中。我的解法是在分块时保留“章级摘要块”每章的摘要内容单独切片一次包含这一章所有子节的概要信息这样粒度不够时可以快速向上回溯。第三类偏差是“时效性偏差”。探矿数据有很强的时效性同一矿区可能有2010年的普查报告和2024年的补充勘查报告用户检索时如果不知道区分会把旧报告内容当现状。我的方案是在元数据里加上报告日期并在检索后期加一个时间衰减重排让“较新报告”排前面。5.4 一套排错自查清单把经验沉淀成清单后排查效率会大幅提升。我在项目中一直用的排查口诀是先看源头文件再看解码方式三看解析路径四看清洗规则五看分块与元数据。落成自查清单大概是这样的乱码源文件到底是什么编码用什么解码器解码错误是全局还是局部文字缺失是解析器漏了还是源文件本身就没文本层页面渲染有没有被遮挡表格错乱表头是否被正确识别跨行跨列是否填充换列时有没有按“行优先”读取切片语义错乱分块边界是否落在段落中间重叠长度是不是够检索结果偏移是术语没统一元数据过滤写错还是分块粒度不对这套清单在每次出现新问题的时候都会派上用场。结尾实操经验沉淀我个人操作下来最大的体会是探矿知识库的RAG项目真正决定成败的不是模型不是向量库而是清洗环节的细致程度。清洗这种活看起来琐碎每一次编码检测、每一行正则、每一个表格修复都是在为检索系统的“高精度”铺路。最后再分享一个小技巧清洗代码里每一个关键处理环节哪怕是条简单的正则替换都务必留下日志记录处理前后的字符数、替换次数、失败样本。不要小看这些日志迭代到第三次清洗优化的时候你会发现它们才是定位问题的最可靠地图。这套从解析到清洗再到检索引发的管道跑通一次以后后续新矿区的文档进来只是增量工作不用再经历从零开始的痛苦。