我在这行干了快十年接手过不少探矿业务的资料整理项目。说句实在话地质报告、钻探记录、化验单这批文档可能是这个世界上最不适合直接扔给RAG的知识库原料。为什么因为我见过太多团队兴致勃勃搭好向量数据库导入文档然后检索结果出来一堆锟斤拷和乱码甚至命中率还不如直接CtrlF。问题不在向量模型不在Embedding参数而在数据进管道之前的那一步——清洗。这篇文章我想好好聊聊在探矿这种专业场景下TXT、Word、PDF和网页这四类来源到底该怎么清洗才能喂给RAG做出真正能用的高精度检索。不聊虚的全是实际操作和踩坑记录。1. 探矿业务文档的脏数据全景乱码只是冰山一角先别急着写代码搞清楚你的数据到底脏在哪里比什么都重要。探矿业务的文档来源极杂我整理过的一个中型矿区项目光历史资料就有二十年跨度来源包括上级单位下发的函件、老一辈地质队员手写的岩心编录、不同版本软件导出的化验数据、扫描精度参差不齐的图件以及从行业网站抓下来的政策文件。这些资料的共性是格式混乱、编码复杂、版面残缺、元数据缺失。1.1 四类来源各自的脏法不一样TXT文件看着最老实实际最容易出鬼。我碰到过的最典型场景是某年头的区域地质调查报告从老系统导出来是TXT打开全是对的但程序读进去就是满屏乱码。原因几乎都是编码问题——文件明明是GBK或GB2312编码系统却按UTF-8去解或者反过来。更恶心的是混合编码一个文件前一半是GBK后一半不知道哪次转存变成了UTF-8这种情况下chardet检测结果都是错的。Word文档的脏不在于编码在于结构干扰。页眉页脚、目录域、批注、修订痕迹、文本框、嵌入的Excel表格这些东西在视觉上不影响阅读但在RAG切块时全是噪音。还有公式探矿报告里储量计算公式、品位计算公式不少Word里的公式可能是OMML对象、MathType域代码甚至干脆就是一张图片。不做处理检索时这些关键计算过程基本是盲区。PDF文件是重灾区。历史图件的扫描PDF根本没有文本层本质上就是一叠图片。而电子版PDF也未必省心——表格线断裂导致内容错位希腊字母和上下标变成乱码多栏排版把正文顺序打乱。最坑的是某些单位用国产软件生成的PDF文本能复制但复制出来全是半角空格插在字中间检索时一个词组被拆得七零八落。网页来源则要区分政策文件和行业动态。政策文件相对规整但很多地调系统的官网还是GBK编码页面里混杂着导航栏、相关链接、页脚版权信息直接抓下来整页入库检索时全是噪音。动态加载的网页更麻烦列表页能看到标题详情页内容要另发请求才能拿到。1.2 乱码到检索失效的完整链路很多人不理解为什么文档里有个别字是乱的会导致检索效果差。其实链路是这样的乱码字符在切块时可能被切进块里Embedding模型没见过这种乱码Token组合把整个块的语义向量拉偏检索时用户问该矿区银品位多少命中的块里全是锟斤拷占位符向量相似度反而低于那些内容不全但字符正常的块。更隐蔽的是乱码会导致某些本该合并的段落被切断切块边界正好落在乱码处上一半下一半都是残缺信息。所以RAG清洗不是锦上添花是决定生死。下面我从TXT开始逐类讲清洗的实际做法。2. TXT清洗实战编码识别、噪声剔除与半结构化转换TXT的清洗核心是三件事识别正确编码、去掉非正文噪声、把有规律的半结构化文本转成更利于切块的结构。先说编码这是最基础也是翻车率最高的一步。2.1 乱码检测的完整姿势别只信chardet我早期处理TXT就是chardet一把梭后来发现远远不够。chardet的短板在于它对短文本的检测准确率低对混合编码文件它会给你一个最有可能的结果但文件后半段的乱码依然存在。所以我的做法分四步第一步先用file命令或Python的magic库判断文件声明的编码格式很多TXT文件头有BOM标记这是最可靠的信号比任何推断都准。第二步抽样检测。不要全文件检测取文件开头、中间、结尾各1KB做三次chardet检测如果三个结果不一致这个文件大概率是混合编码。混合编码的处理没有银弹我在实践中常用的是分割点检测把文件切成多个片段逐段检测编码然后按检测结果为每段单独解码再拼接回来。这个思路听着笨但对老地质报告这种前半截打印体后半截手写体扫描注释的文件实测有效。第三步针对特定领域做字符集白名单过滤。探矿文档里中文、英文、数字、单位符号% 、g/t、m、mm、°C是高频字符。如果解码结果出现大量冷僻字符或Unicode替换符UFFFD说明解码不对立刻换方案。这一步可以用正则把允许的字符类别以外的内容标出来人工抽查。第四步修复常见转码错位。历史文件经常出现UTF-8内容被GBK解码再存成UTF-8的双重错误典型表现是出现锟斤拷、烫烫烫这类垃圾串。遇到这个要先逆向操作恢复原始字节序列再按正确编码解码。网上不少教程有现成的还原脚本我建议直接在清洗管线上预置一个锟斤拷检测规则命中了就走逆向修复分支。2.2 页眉页脚与噪声剔除正则加上下文规则探矿TXT的噪声最常见的是重复页眉比如XX矿区地质普查报告 第X页、空行、制表符混乱、以及从PDF转换过来的残留页码。剔除思路分两层第一层是全量正则凡是匹配第\d页、页码数字、重复出现的报告名称直接删掉。但这里有个坑正文里如果讨论第3勘探线剖面图第3不该被删。所以正则要带上下文约束比如页眉翻页时页码通常前后是换行符或分隔线用\n\s*第?\d\s*页?\s*\n这类模式去匹配而不是全局替换。第二层是结构感知。我写过一个简单的启发式规则统计每个段落的内容长度如果一个段落的长度小于10个字符且不含句号、数字、单位大概率是页眉页脚残留标记为候选噪声再人工确认一批后加入黑名单。这个方案放到探矿场景特别适用因为正式报告正文里少有小段落而页眉页脚恰恰就是小段落。2.3 钻探记录等半结构化文本的重组纯TXT里最值钱的往往是钻探编录和化验数据。这类数据的特征是字段对齐、行间关联、靠缩进和分隔符表达结构。但TXT没有表格的格子概念清洗时如果原样保留切块后一个钻孔的完整信息会被拦腰截断。我的建议是把这类半结构化TXT转成明确的Markdown表格或JSON片段。具体做法是识别表头行比如孔号 孔深 岩性 品位然后把后续行映射成表格行用管道符拼接。为什么要转因为RAG切块时Markdown表格的分隔线提供了天然的块边界而且Embedding对表格形式的理解明显好于纯文本对齐。更重要的是这种转换能保住行的完整性——每一行对应一个钻孔记录检索时命中一行就能给出完整的对应数据而不是半行文字加半行乱码。这里我踩过一个具体的坑直接按空格列分割会把含金石英脉这种岩性描述拆成含金石英脉两块。后来我加了规则先找数值型分隔符数字与单位之间的空格再在剩余空格里找一致性最高的分割点。总结一句话就是——TXT清洗的终点不是能读而是可结构化。3. Word文档解析公式、表格与内嵌对象的三重考验Word文档的清洗步骤不比PDF少。python-docx是常规选择但拿它直接处理探矿报告很快会碰到墙读不出公式内容、表格结构丢失、页眉页脚和正文混在一起。下面按三个难点逐个讲我的处理方式。3.1 页眉页脚、目录域与文本顺序的修正先说最基础的。python-docx读取Word时默认不会自动把页眉页脚拼进正文但如果你用某些RAG框架的Word解析器比如LangChain的UnstructuredWordLoader它会把页眉页脚内容当作正文段落输出结果每个切块里都混着重复的XX矿区勘探报告内部资料这种字样污染率相当高。我的做法是先用python-docx遍历document.sections把每个section的页眉页脚内容提取出来和正文做一次相似度比对如果页眉页脚短语在正文中高频出现比如每页都有就把该段从正文中剔除只在metadata里保留一次。目录域是个更隐蔽的问题。Word报告里目录占一整页看似是正文实际是域代码。python-docx读出来的是目录文本串但这些内容与后文正文完全重复。RAG入库后检索储量估算方法时命中的可能是目录页里的同一句话而目录页没有上下文检索结果就是孤立短语。我的处理是检测段落文本是否包含大量..........目录引导符或者判断段落内容是否与后文某标题完全一致命中了就整段丢弃。文本顺序也要注意。Word排版里正文文本块可能分散在多个文本框python-docx默认的paragraphs顺序不一定等于视觉阅读顺序。探矿报告特别爱用文本框放图件说明这些说明文字如果被系统排在正文后面切块时就会导致图件说明与对应章节分离。这个问题不能靠python-docx解决我现在的方案是先按document.xml里的元素顺序遍历段落和文本框再根据页面位置坐标排序尽量还原视觉顺序。坐标信息在读取时是能拿到的只是很少人愿意多写这几十行代码。3.2 OMML公式转LaTeX储量计算过程不能丢探矿报告里真正有计算逻辑的部分公式是核心资产。然而RAG系统对公式的向量化能力天然弱因为Embedding模型是按自然语言训练的公式的符号排列对它们来说几乎是噪音。这时候清洗的目标不是让模型理解公式而是让检索能命中公式所在的上下文。Word中公式有三种存储形态OMMLOffice Math Markup Language、MathType域、图片。OMML是原生格式理论上有标准方法转LaTeX比如用pandoc处理Word文档时它对OMML有较完整的转换支持。我实数过pandoc转出来的LaTeX在简单的品位计算公式如品位 金属量 / 矿石量 × 100%上表现不错但遇到复杂的方括号矩阵或求和符号转出来经常出错。更麻烦的是MathType和图片公式。MathType域本质上是一段OLE对象python-docx读不到内容只能读到MathType Equation的占位文本。图片公式只能走OCR。我的取舍是公式本身不指望直接进RAG的向量检索而是把公式的语义标签作为文本补充。比如图片公式OCR识别成LaTeX后不把LaTeX源码直接嵌入正文那会让检索更乱而是把公式的近似文本描述品位计算公式金属量除以矿石量乘以百分之百放在公式旁边作为替代文本。实测下来检索品位怎么算时命中率比裸公式高得多。这一步在清洗阶段做比在检索阶段做成本低十倍。3.3 大表格与合并单元格的结构保真Word表格处理是清洗管线里最容易出现语义丢失的环节。python-docx能遍历表格和单元格但合并单元格比如跨行合并的岩性描述列在数据里会变成重复值或空值。探矿报告里的综合地层表、化验结果汇总表几乎都有合并单元格。我的处理原则是三条第一合并单元格向下填充——跨行合并的单元格内容填充到每一行保证每一行数据独立完整不依赖上下文。第二列名拼进单元格内容——比如品位这一列在数值前加上品位前缀这样切块时即使表格被截断单行也保有列语义。第三表格前后各加一个摘要句——我在每个表格前插入一句本表为XX矿区XX钻孔化验结果汇总表格后用一句以上为XX数据汇总。这两句话看着冗余但检索时作用很大它等于给表格块提供了可被匹配的上文锚点。实际操作有一个坑要提醒Word里的表格不一定是真表格。有些人用制表符加空格排版假装表格python-docx的tables列表里根本找不到它们。我处理探矿历史报告时遇到很多这种情况只能用文本启发式去识别对齐的多行数据再重组。这个我放在TXT那节讲过的方法在Word里同样适用本质还是先识别行结构再转成真表格。4. PDF攻防战扫描件、双层PDF与图件说明文本PDF是探矿资料里占比最大、也最让人头疼的格式。我把它分成有文本层和无文本层两类处理因为技术路径完全不同。4.1 先探测文本层PyMuPDF提取的可信度检查拿到一个PDF第一步不是OCR而是先判断它有没有文本层。用PyMuPDFfitz打开文件后对每一页执行page.get_text()如果返回的字符串长度除以页面估计字数小于某个阈值就判定为扫描件。这个阈值在我处理的地质图件扫描件上大概是5%。为什么强调先探测因为直接对码全图做OCR时间和成本是文本提取的几十倍而且OCR结果还会引入识别错误。能免费从文本层拿到的内容绝不让OCR重造轮子。文本层的提取也不是全无问题。PyMuPDF提取出来的文本顺序在多栏排版下经常错乱。探矿报告里的附图说明常采用双栏PyMuPDF默认按块的位置输出可能把右栏内容排在左栏前面。解决方案是用page.get_text(blocks)获取每个文本块的坐标按(column, row)排序重建阅读顺序。这个坐标排序逻辑不算复杂但写完之后要人工验证几页因为不同PDF软件生成的排版规则略有差异。另一个坑是特殊字符。探矿文档里的品位数值常常带上下标如m³、g/t文本层提取出来上下标经常会丢或者变成普通字符。这里没有完美的自动化方案我的做法是对提取结果做一轮单位正则修正——把g/t规范化成克/吨、m3修正为立方米让常见单位以中文形式保留而不是依赖可能丢失的上下标符号。这步修正看似简单但对Embedding的匹配效果提升明显因为很多中文语料里用户的问法就是克每吨而不是g/t。4.2 PaddleOCR处理扫描历史图件的参数调优扫描件比如老的地质剖面图、矿区地形图附带的说明文字必须走OCR。我用过Tesseract、也用过商业OCR服务最后固定在PaddleOCR上因为它的中文识别在历史文档场景下比Tesseract好很多。但开箱即用是不够的有几个参数值得调第一个是det_limit_side_len控制检测端的图像缩放。大图件直接送进去检测框容易漏掉边角的文字。我一般设置成960或1280让长边在保持比例的情况下缩到这个尺寸既保证速度也保证召回。第二个是rec_batch_num和use_angle_cls。历史扫描件很多是歪的或者手写体带角度use_angle_clsTrue能识别文字方向并纠正。探矿图件的图例、比例尺、责任表字体小且排列密集我实测如果不开启方向分类会丢大量小字识别。第三个是后处理步骤单位与数值的纠错。OCR识别品位0.56g/t经常把点识别成逗号或空格把斜杠识别成1。我在OCR输出后加了规则数字之间出现逗号换成点、识别出gltgl这类错误模式就近替换成g/t。这些规则看起来笨但在固定领域的文档上非常有效因为它抓住了这个领域的高频词汇模式。需要说明的是OCR的定位不是替代原文而是给原本不可检索的扫描件补一层可检索的文字。加工后的OCR文本我建议单独存成文本文件或双层PDF和原图件分开管理。这样RAG检索时命中OCR文本块还能反向链接到原始图件的坐标位置方便用户在产出物里跳转查看原始凭证。4.3 pdfplumber处理表格数据几列对齐的取舍有文本层的PDF表格提取用pdfplumber比较好。但它不是万能的遇到无边框表格靠空格对齐的表格、跨页表格、单元格内换行时输出经常错位。我的经验是三步走第一步先判断页面是否是表格型页面用page.find_tables()看检测到的表格行数和列数是否合理。第二步对检测到的表格用Table对象的方法提取数据。第三步对没检测到但明显是表格的页面手动设置vertical_strategy或explicit_vertical_lines补画竖线来做列切分。跨页表格是重灾区。一个钻孔柱状表跨了三页每页单独提取后页与页之间的列宽可能不一致导致合并时数据错位。我现在干脆不合并保持每页独立表格但把表头信息循环带到每页的提取结果里——比如每页顶部加一个接上页XX钻孔柱状表标记。这样切块时每页的表格数据都有独立上下文检索不必跨页拼接也能命中。还有一个很多教程不讲的细节PDF表格和Word表格不同它没有合并单元格的概念视觉上的合并是靠空单元格实现的。清洗时如果原样保留空单元格切块后行内会出现空洞。我的处理是把空单元格填充为同左或继承上一行对应列的值结合表头语义判断保证每行数据的密集度和完整性。5. 网页抓取与清洗信息源甄别与动态页面处理网页也是探矿业务中不可忽视的一类数据源——区域规划、矿权政策、行业标准、勘查动态很多信息只在网上发布。网页抓取的难点不在抓到而在抓完还能用。5.1 地质资料网站的编码陷阱国内大量地质行业网站仍采用GBK编码尤其是各级地调单位的老站点。用requests直接抓取时如果不显式指定编码resp.encoding可能识别成ISO-8859-1导致中文全是乱码。我的习惯是headers里带上Accept-Encoding和合适的User-Agent拿到响应后用resp.apparent_encoding做参考再尝试gbk和utf-8两种解码选择合法字符比例高的那个。这个逻辑跟TXT清洗的编码检测是一套思路只是多了一个从响应头charset参数获取声明编码的优先分支。还有一个坑是页面内嵌脚本在HTML里占了大头。抓下来的HTML如果直接转文本会混入大量JS、CSS噪音。我用的策略是先用BeautifulSoup抽取主体内容标签通常是article、div classcontent这类容器再用get_text()提取文本。但选择器不能写死因为不同网站结构差异极大。我写了一个通用的负向过滤方案先去掉script、style、nav、footer、aside等标签再按文本密度过滤掉短链路文字比如首页上一页相关阅读这类短串。在探矿类网站的实际测试里这个方案能去掉70%-90%的导航噪音。5.2 正文抽取与语义去重政策文件与行业动态的差异政策类网页比如矿权审批公告和行业动态类网页比如勘探进展新闻清洗重点不同。前者需要保全文号、发布时间、实施范围等要素后者只需要保留下正文核心内容。我建议在清洗管线里给网页加一个来源分类标签不同分类走不同的清洗规则。政策类网页提取完正文后还要做一轮结构化增强——把发文字号成文日期适用范围这些字段抽出来写进metadata。这类字段信息很规则用正则就能抓但价值极大因为RAG检索XX省2024年矿权管理新规时metadata里的发文时间和文号能直接参与过滤比纯向量检索精准得多。语义去重是另一个被低估的环节。政府网站和行业网站经常互相转载同一篇政策解读同一个通知可能出现在三四个网站上直接入库后重复块会被多次检索到挤占结果页面。我的做法是对入库文本计算SimHash设定一个汉明距离阈值低于阈值的视为重复内容只保留来源权威性最高的那一份。这个在探矿语料上实测效果很好因为政策文本基本都是官方通稿转载很少改动正文。5.3 动态渲染页面与列表-详情页结构有些地调系统的信息平台是前后端分离的列表页是HTML详情数据靠接口动态加载。requests直接抓详情页拿到的是空壳。这种情况我的方案是分两类处理如果接口返回JSON且结构规整直接请求接口解析JSON字段比解析HTML可靠得多如果接口有签名校验或者不可直接访问就退到Selenium或Playwright渲染页面后再抓。我一般优先推荐直接找接口。方法是在浏览器开发者工具里看详情页发出的XHR请求很多API路径就藏在/api/detail?id123这类地方。探矿行业的系统往往没有复杂签名直接拼参数就能拿到数据比上浏览器自动化快且稳定。但要注意抓取频率必须控制——单位网站服务器抗不住高频请求QPS设置成0.5-1每次请求间隔随机化同时遵守robots.txt的约定这个底线不能破。列表-详情页结构还有一个常见问题列表页只给标题和摘要详情页才是全文。如果你只抓了列表页RAG里就只有几十个字的摘要检索命中后信息量严重不足。我的管线是先抓列表页解析出详情页URL再去抓详情页正文并把列表页的标题和日期合并进详情页的metadata。这样入库的每个网页对象同时拥有标题、发布时间、来源URL、正文四个完整字段切块和检索都有据可依。6. 切块与metadata设计从清洗干净到查得准清洗完的文本如果切块策略不对前面的功夫会白费一大半。这一节讲我的切块原则和metadata设计这些经验是根据探矿业务文档特征反复调出来的。6.1 按文档结构切块而非固定窗口入行时我用过最朴素的固定窗口切块——每500字符一块重叠100字符。在探矿文档上效果极差一块里可能包含半张表格加半个段落语义不完整。后来我改成了结构感知切块。具体做法是先把清洗后的文档转成Markdown格式保留标题层级#、##、###和表格结构。切块时按标题层级作为主边界从最高的层级往下切如果某个标题下的内容太短就向上合并到兄弟节点如果某个标题下的内容过长比如一个大地质背景章节写了上万字就以二级标题或表格为子边界拆成多个子块。这个策略里最关键的一点是子块要继承父级的标题路径。比如一个关于XX矿区蚀变带特征的块它的metadata里要写入矿区概述 地质特征 蚀变带 XX矿区蚀变带特征这整条路径。检索时用户问XX矿区的蚀变带有哪几种这个块能通过标题路径快速命中而且Embedding匹配时标题路径可以拼进文本显著提升召回率。我实测同一批清洗后的探矿文档从固定窗口切块切出来的500块命中率只有结构感知切块的三分之二左右。6.2 关键metadata经纬度、矿种、报告编号探矿业务检索有一个强烈的领域特征用户经常按矿区、矿种、时间、报告类型来找内容。这些条件光靠向量检索很难精确满足必须靠metadata过滤。我在清洗管线的输出阶段会为每个块生成一个metadata JSON包含以下字段字段示例提取方式矿区名称白云鄂博矿区从标题或首段矿种稀土、铁矿领域词表匹配经纬度范围109.5°E, 41.7°N正则提取报告编号DZ-2023-015正则提取报告类型普查/详查/勘探关键词分类年份2023标题/正文提取来源格式PDF/TXT/Word/Web管道级记录维度经纬度数据在探矿检索里尤其重要。用户经常问的是XX坐标附近的矿化信息如果metadata里有经纬度就能做空间过滤向量检索只在候选集内跑速度和精度都提升一大截。我见过一些团队把坐标写进正文向量化检索108度30分附近时效果很差因为度分秒的写法在向量空间里毫无距离感。坐标这种数值型条件就适合结构化过滤不适合向量匹配。6.3 实测中embedding检索的常见失效模式清洗和切块都做完了检索仍然可能失败。分享一下我在这类项目里经常遇到的三种失效模式和对应的处理经验。第一种是同义表述失效。用户问金品位文档里写的是Au品位。Embedding模型对小写化学元素符号和中文关键词的映射不敏感。我用的补丁方案是在清洗阶段做术语归一化——把Au品位统一写成金Au品位g/t统一为克/吨。这一步在清洗时做比在查询时做改写要省事得多。第二种是数值范围查询失效。用户问品位大于3克每吨的矿段向量检索对这种数值条件几乎无能为力。纯靠RAG系统很难正确处理这类查询好一点的方案是把数值条件识别出来后转成结构化过滤条件对metadata或表格数据走规则查询向量部分只负责召回相关文档。这个混合检索Hybrid Search架构在探矿场景下几乎是必须的。第三种是表格块语义孤岛。表格数据被清洗成Markdown表格后Embedding对它理解得还是不如自然语言段落。我发现的缓解办法是在切块时给表格块配一句自然语言的摘要放在表格前面作为引导文本。这段摘要由清洗管线自动生成取表头列名的中文拼接加一行典型数据检索时优先匹配这段引导文本再定位到表格块。这招在化验结果表、钻孔数据表的检索中效果很稳定。7. 入库后的验证与持续迭代清洗质量要能用数据说话清洗工作不是一锤子买卖。我认为每个RAG项目都必须建立一套清洗质量回归机制否则很难知道改动是变好还是变坏。我常用的验证方式是构造一个领域评估集——从真实业务中挑出50到100个比较典型的问题每个问题标注好期望命中的源文档位置。比如XX矿区主矿体平均品位是多少对应某详查报告的第三章表格某年某省发布的矿权管理新规是什么文号对应某政策网页。每次清洗管线改动后都用这批题跑一遍检索计算命中率。命中率涨了改动保留跌了回滚。清洗管线本身的代码组织和版本管理也要像对待正式项目一样。我的习惯是每个清洗环节封装成独立的类或函数输入输出都是统一格式的JSON中间产物落盘方便排查问题环节。比如一个文档从原始TXT到最终切块中间会生成乱码检测结果、清洗后文本、Markdown转换结果、切块列表、metadata JSON五种中间文件。平时这些文件不占多少存储但在某个文档被检索得很差时可以直接把中间文件翻出来定位是哪一个环节出了问题。还有一个值得提的教训不同批次的文档清洗参数可能不一样。我处理过一个项目2010年以前的报告多是扫描PDF2010以后的报告是电子Word为主。我最初用同一套管线处理所有文件结果扫描件的OCR参数在电子文档上表现很差浪费了大量算力。后来在管线入口加了文件类型探测和年代估计两个前置判断不同类别走不同清洗子流程效率提升立竿见影。清洗管线的架构从设计第一天起就要考虑可扩展性和可配置性别指望一套参数打通所有格式。最后说一点我在实际项目里的体会。清洗工作枯燥、琐碎、见效慢但它是整个RAG系统里ROI最高的一环。很多团队把精力花在调Embedding模型、换向量库、调检索参数上结果数据没洗干净改什么都收效甚微。特别是在探矿这种专业领域文档的稀碎程度远超通用语料不做清洗高精度检索就是空中楼阁。我希望这篇分享能让你少走几趟弯路——从乱码到高精度检索中间隔的不是一个神奇的模型而是一条老老实实的清洗流水线。 
长河君 · 2026/10/14 6:53:48 · 阅读 1.2k 探矿业务文档RAG清洗实战：从乱码到高精度检索
我在这行干了快十年接手过不少探矿业务的资料整理项目。说句实在话地质报告、钻探记录、化验单这批文档可能是这个世界上最不适合直接扔给RAG的知识库原料。为什么因为我见过太多团队兴致勃勃搭好向量数据库导入文档然后检索结果出来一堆锟斤拷和乱码甚至命中率还不如直接CtrlF。问题不在向量模型不在Embedding参数而在数据进管道之前的那一步——清洗。这篇文章我想好好聊聊在探矿这种专业场景下TXT、Word、PDF和网页这四类来源到底该怎么清洗才能喂给RAG做出真正能用的高精度检索。不聊虚的全是实际操作和踩坑记录。1. 探矿业务文档的脏数据全景乱码只是冰山一角先别急着写代码搞清楚你的数据到底脏在哪里比什么都重要。探矿业务的文档来源极杂我整理过的一个中型矿区项目光历史资料就有二十年跨度来源包括上级单位下发的函件、老一辈地质队员手写的岩心编录、不同版本软件导出的化验数据、扫描精度参差不齐的图件以及从行业网站抓下来的政策文件。这些资料的共性是格式混乱、编码复杂、版面残缺、元数据缺失。1.1 四类来源各自的脏法不一样TXT文件看着最老实实际最容易出鬼。我碰到过的最典型场景是某年头的区域地质调查报告从老系统导出来是TXT打开全是对的但程序读进去就是满屏乱码。原因几乎都是编码问题——文件明明是GBK或GB2312编码系统却按UTF-8去解或者反过来。更恶心的是混合编码一个文件前一半是GBK后一半不知道哪次转存变成了UTF-8这种情况下chardet检测结果都是错的。Word文档的脏不在于编码在于结构干扰。页眉页脚、目录域、批注、修订痕迹、文本框、嵌入的Excel表格这些东西在视觉上不影响阅读但在RAG切块时全是噪音。还有公式探矿报告里储量计算公式、品位计算公式不少Word里的公式可能是OMML对象、MathType域代码甚至干脆就是一张图片。不做处理检索时这些关键计算过程基本是盲区。PDF文件是重灾区。历史图件的扫描PDF根本没有文本层本质上就是一叠图片。而电子版PDF也未必省心——表格线断裂导致内容错位希腊字母和上下标变成乱码多栏排版把正文顺序打乱。最坑的是某些单位用国产软件生成的PDF文本能复制但复制出来全是半角空格插在字中间检索时一个词组被拆得七零八落。网页来源则要区分政策文件和行业动态。政策文件相对规整但很多地调系统的官网还是GBK编码页面里混杂着导航栏、相关链接、页脚版权信息直接抓下来整页入库检索时全是噪音。动态加载的网页更麻烦列表页能看到标题详情页内容要另发请求才能拿到。1.2 乱码到检索失效的完整链路很多人不理解为什么文档里有个别字是乱的会导致检索效果差。其实链路是这样的乱码字符在切块时可能被切进块里Embedding模型没见过这种乱码Token组合把整个块的语义向量拉偏检索时用户问该矿区银品位多少命中的块里全是锟斤拷占位符向量相似度反而低于那些内容不全但字符正常的块。更隐蔽的是乱码会导致某些本该合并的段落被切断切块边界正好落在乱码处上一半下一半都是残缺信息。所以RAG清洗不是锦上添花是决定生死。下面我从TXT开始逐类讲清洗的实际做法。2. TXT清洗实战编码识别、噪声剔除与半结构化转换TXT的清洗核心是三件事识别正确编码、去掉非正文噪声、把有规律的半结构化文本转成更利于切块的结构。先说编码这是最基础也是翻车率最高的一步。2.1 乱码检测的完整姿势别只信chardet我早期处理TXT就是chardet一把梭后来发现远远不够。chardet的短板在于它对短文本的检测准确率低对混合编码文件它会给你一个最有可能的结果但文件后半段的乱码依然存在。所以我的做法分四步第一步先用file命令或Python的magic库判断文件声明的编码格式很多TXT文件头有BOM标记这是最可靠的信号比任何推断都准。第二步抽样检测。不要全文件检测取文件开头、中间、结尾各1KB做三次chardet检测如果三个结果不一致这个文件大概率是混合编码。混合编码的处理没有银弹我在实践中常用的是分割点检测把文件切成多个片段逐段检测编码然后按检测结果为每段单独解码再拼接回来。这个思路听着笨但对老地质报告这种前半截打印体后半截手写体扫描注释的文件实测有效。第三步针对特定领域做字符集白名单过滤。探矿文档里中文、英文、数字、单位符号% 、g/t、m、mm、°C是高频字符。如果解码结果出现大量冷僻字符或Unicode替换符UFFFD说明解码不对立刻换方案。这一步可以用正则把允许的字符类别以外的内容标出来人工抽查。第四步修复常见转码错位。历史文件经常出现UTF-8内容被GBK解码再存成UTF-8的双重错误典型表现是出现锟斤拷、烫烫烫这类垃圾串。遇到这个要先逆向操作恢复原始字节序列再按正确编码解码。网上不少教程有现成的还原脚本我建议直接在清洗管线上预置一个锟斤拷检测规则命中了就走逆向修复分支。2.2 页眉页脚与噪声剔除正则加上下文规则探矿TXT的噪声最常见的是重复页眉比如XX矿区地质普查报告 第X页、空行、制表符混乱、以及从PDF转换过来的残留页码。剔除思路分两层第一层是全量正则凡是匹配第\d页、页码数字、重复出现的报告名称直接删掉。但这里有个坑正文里如果讨论第3勘探线剖面图第3不该被删。所以正则要带上下文约束比如页眉翻页时页码通常前后是换行符或分隔线用\n\s*第?\d\s*页?\s*\n这类模式去匹配而不是全局替换。第二层是结构感知。我写过一个简单的启发式规则统计每个段落的内容长度如果一个段落的长度小于10个字符且不含句号、数字、单位大概率是页眉页脚残留标记为候选噪声再人工确认一批后加入黑名单。这个方案放到探矿场景特别适用因为正式报告正文里少有小段落而页眉页脚恰恰就是小段落。2.3 钻探记录等半结构化文本的重组纯TXT里最值钱的往往是钻探编录和化验数据。这类数据的特征是字段对齐、行间关联、靠缩进和分隔符表达结构。但TXT没有表格的格子概念清洗时如果原样保留切块后一个钻孔的完整信息会被拦腰截断。我的建议是把这类半结构化TXT转成明确的Markdown表格或JSON片段。具体做法是识别表头行比如孔号 孔深 岩性 品位然后把后续行映射成表格行用管道符拼接。为什么要转因为RAG切块时Markdown表格的分隔线提供了天然的块边界而且Embedding对表格形式的理解明显好于纯文本对齐。更重要的是这种转换能保住行的完整性——每一行对应一个钻孔记录检索时命中一行就能给出完整的对应数据而不是半行文字加半行乱码。这里我踩过一个具体的坑直接按空格列分割会把含金石英脉这种岩性描述拆成含金石英脉两块。后来我加了规则先找数值型分隔符数字与单位之间的空格再在剩余空格里找一致性最高的分割点。总结一句话就是——TXT清洗的终点不是能读而是可结构化。3. Word文档解析公式、表格与内嵌对象的三重考验Word文档的清洗步骤不比PDF少。python-docx是常规选择但拿它直接处理探矿报告很快会碰到墙读不出公式内容、表格结构丢失、页眉页脚和正文混在一起。下面按三个难点逐个讲我的处理方式。3.1 页眉页脚、目录域与文本顺序的修正先说最基础的。python-docx读取Word时默认不会自动把页眉页脚拼进正文但如果你用某些RAG框架的Word解析器比如LangChain的UnstructuredWordLoader它会把页眉页脚内容当作正文段落输出结果每个切块里都混着重复的XX矿区勘探报告内部资料这种字样污染率相当高。我的做法是先用python-docx遍历document.sections把每个section的页眉页脚内容提取出来和正文做一次相似度比对如果页眉页脚短语在正文中高频出现比如每页都有就把该段从正文中剔除只在metadata里保留一次。目录域是个更隐蔽的问题。Word报告里目录占一整页看似是正文实际是域代码。python-docx读出来的是目录文本串但这些内容与后文正文完全重复。RAG入库后检索储量估算方法时命中的可能是目录页里的同一句话而目录页没有上下文检索结果就是孤立短语。我的处理是检测段落文本是否包含大量..........目录引导符或者判断段落内容是否与后文某标题完全一致命中了就整段丢弃。文本顺序也要注意。Word排版里正文文本块可能分散在多个文本框python-docx默认的paragraphs顺序不一定等于视觉阅读顺序。探矿报告特别爱用文本框放图件说明这些说明文字如果被系统排在正文后面切块时就会导致图件说明与对应章节分离。这个问题不能靠python-docx解决我现在的方案是先按document.xml里的元素顺序遍历段落和文本框再根据页面位置坐标排序尽量还原视觉顺序。坐标信息在读取时是能拿到的只是很少人愿意多写这几十行代码。3.2 OMML公式转LaTeX储量计算过程不能丢探矿报告里真正有计算逻辑的部分公式是核心资产。然而RAG系统对公式的向量化能力天然弱因为Embedding模型是按自然语言训练的公式的符号排列对它们来说几乎是噪音。这时候清洗的目标不是让模型理解公式而是让检索能命中公式所在的上下文。Word中公式有三种存储形态OMMLOffice Math Markup Language、MathType域、图片。OMML是原生格式理论上有标准方法转LaTeX比如用pandoc处理Word文档时它对OMML有较完整的转换支持。我实数过pandoc转出来的LaTeX在简单的品位计算公式如品位 金属量 / 矿石量 × 100%上表现不错但遇到复杂的方括号矩阵或求和符号转出来经常出错。更麻烦的是MathType和图片公式。MathType域本质上是一段OLE对象python-docx读不到内容只能读到MathType Equation的占位文本。图片公式只能走OCR。我的取舍是公式本身不指望直接进RAG的向量检索而是把公式的语义标签作为文本补充。比如图片公式OCR识别成LaTeX后不把LaTeX源码直接嵌入正文那会让检索更乱而是把公式的近似文本描述品位计算公式金属量除以矿石量乘以百分之百放在公式旁边作为替代文本。实测下来检索品位怎么算时命中率比裸公式高得多。这一步在清洗阶段做比在检索阶段做成本低十倍。3.3 大表格与合并单元格的结构保真Word表格处理是清洗管线里最容易出现语义丢失的环节。python-docx能遍历表格和单元格但合并单元格比如跨行合并的岩性描述列在数据里会变成重复值或空值。探矿报告里的综合地层表、化验结果汇总表几乎都有合并单元格。我的处理原则是三条第一合并单元格向下填充——跨行合并的单元格内容填充到每一行保证每一行数据独立完整不依赖上下文。第二列名拼进单元格内容——比如品位这一列在数值前加上品位前缀这样切块时即使表格被截断单行也保有列语义。第三表格前后各加一个摘要句——我在每个表格前插入一句本表为XX矿区XX钻孔化验结果汇总表格后用一句以上为XX数据汇总。这两句话看着冗余但检索时作用很大它等于给表格块提供了可被匹配的上文锚点。实际操作有一个坑要提醒Word里的表格不一定是真表格。有些人用制表符加空格排版假装表格python-docx的tables列表里根本找不到它们。我处理探矿历史报告时遇到很多这种情况只能用文本启发式去识别对齐的多行数据再重组。这个我放在TXT那节讲过的方法在Word里同样适用本质还是先识别行结构再转成真表格。4. PDF攻防战扫描件、双层PDF与图件说明文本PDF是探矿资料里占比最大、也最让人头疼的格式。我把它分成有文本层和无文本层两类处理因为技术路径完全不同。4.1 先探测文本层PyMuPDF提取的可信度检查拿到一个PDF第一步不是OCR而是先判断它有没有文本层。用PyMuPDFfitz打开文件后对每一页执行page.get_text()如果返回的字符串长度除以页面估计字数小于某个阈值就判定为扫描件。这个阈值在我处理的地质图件扫描件上大概是5%。为什么强调先探测因为直接对码全图做OCR时间和成本是文本提取的几十倍而且OCR结果还会引入识别错误。能免费从文本层拿到的内容绝不让OCR重造轮子。文本层的提取也不是全无问题。PyMuPDF提取出来的文本顺序在多栏排版下经常错乱。探矿报告里的附图说明常采用双栏PyMuPDF默认按块的位置输出可能把右栏内容排在左栏前面。解决方案是用page.get_text(blocks)获取每个文本块的坐标按(column, row)排序重建阅读顺序。这个坐标排序逻辑不算复杂但写完之后要人工验证几页因为不同PDF软件生成的排版规则略有差异。另一个坑是特殊字符。探矿文档里的品位数值常常带上下标如m³、g/t文本层提取出来上下标经常会丢或者变成普通字符。这里没有完美的自动化方案我的做法是对提取结果做一轮单位正则修正——把g/t规范化成克/吨、m3修正为立方米让常见单位以中文形式保留而不是依赖可能丢失的上下标符号。这步修正看似简单但对Embedding的匹配效果提升明显因为很多中文语料里用户的问法就是克每吨而不是g/t。4.2 PaddleOCR处理扫描历史图件的参数调优扫描件比如老的地质剖面图、矿区地形图附带的说明文字必须走OCR。我用过Tesseract、也用过商业OCR服务最后固定在PaddleOCR上因为它的中文识别在历史文档场景下比Tesseract好很多。但开箱即用是不够的有几个参数值得调第一个是det_limit_side_len控制检测端的图像缩放。大图件直接送进去检测框容易漏掉边角的文字。我一般设置成960或1280让长边在保持比例的情况下缩到这个尺寸既保证速度也保证召回。第二个是rec_batch_num和use_angle_cls。历史扫描件很多是歪的或者手写体带角度use_angle_clsTrue能识别文字方向并纠正。探矿图件的图例、比例尺、责任表字体小且排列密集我实测如果不开启方向分类会丢大量小字识别。第三个是后处理步骤单位与数值的纠错。OCR识别品位0.56g/t经常把点识别成逗号或空格把斜杠识别成1。我在OCR输出后加了规则数字之间出现逗号换成点、识别出gltgl这类错误模式就近替换成g/t。这些规则看起来笨但在固定领域的文档上非常有效因为它抓住了这个领域的高频词汇模式。需要说明的是OCR的定位不是替代原文而是给原本不可检索的扫描件补一层可检索的文字。加工后的OCR文本我建议单独存成文本文件或双层PDF和原图件分开管理。这样RAG检索时命中OCR文本块还能反向链接到原始图件的坐标位置方便用户在产出物里跳转查看原始凭证。4.3 pdfplumber处理表格数据几列对齐的取舍有文本层的PDF表格提取用pdfplumber比较好。但它不是万能的遇到无边框表格靠空格对齐的表格、跨页表格、单元格内换行时输出经常错位。我的经验是三步走第一步先判断页面是否是表格型页面用page.find_tables()看检测到的表格行数和列数是否合理。第二步对检测到的表格用Table对象的方法提取数据。第三步对没检测到但明显是表格的页面手动设置vertical_strategy或explicit_vertical_lines补画竖线来做列切分。跨页表格是重灾区。一个钻孔柱状表跨了三页每页单独提取后页与页之间的列宽可能不一致导致合并时数据错位。我现在干脆不合并保持每页独立表格但把表头信息循环带到每页的提取结果里——比如每页顶部加一个接上页XX钻孔柱状表标记。这样切块时每页的表格数据都有独立上下文检索不必跨页拼接也能命中。还有一个很多教程不讲的细节PDF表格和Word表格不同它没有合并单元格的概念视觉上的合并是靠空单元格实现的。清洗时如果原样保留空单元格切块后行内会出现空洞。我的处理是把空单元格填充为同左或继承上一行对应列的值结合表头语义判断保证每行数据的密集度和完整性。5. 网页抓取与清洗信息源甄别与动态页面处理网页也是探矿业务中不可忽视的一类数据源——区域规划、矿权政策、行业标准、勘查动态很多信息只在网上发布。网页抓取的难点不在抓到而在抓完还能用。5.1 地质资料网站的编码陷阱国内大量地质行业网站仍采用GBK编码尤其是各级地调单位的老站点。用requests直接抓取时如果不显式指定编码resp.encoding可能识别成ISO-8859-1导致中文全是乱码。我的习惯是headers里带上Accept-Encoding和合适的User-Agent拿到响应后用resp.apparent_encoding做参考再尝试gbk和utf-8两种解码选择合法字符比例高的那个。这个逻辑跟TXT清洗的编码检测是一套思路只是多了一个从响应头charset参数获取声明编码的优先分支。还有一个坑是页面内嵌脚本在HTML里占了大头。抓下来的HTML如果直接转文本会混入大量JS、CSS噪音。我用的策略是先用BeautifulSoup抽取主体内容标签通常是article、div classcontent这类容器再用get_text()提取文本。但选择器不能写死因为不同网站结构差异极大。我写了一个通用的负向过滤方案先去掉script、style、nav、footer、aside等标签再按文本密度过滤掉短链路文字比如首页上一页相关阅读这类短串。在探矿类网站的实际测试里这个方案能去掉70%-90%的导航噪音。5.2 正文抽取与语义去重政策文件与行业动态的差异政策类网页比如矿权审批公告和行业动态类网页比如勘探进展新闻清洗重点不同。前者需要保全文号、发布时间、实施范围等要素后者只需要保留下正文核心内容。我建议在清洗管线里给网页加一个来源分类标签不同分类走不同的清洗规则。政策类网页提取完正文后还要做一轮结构化增强——把发文字号成文日期适用范围这些字段抽出来写进metadata。这类字段信息很规则用正则就能抓但价值极大因为RAG检索XX省2024年矿权管理新规时metadata里的发文时间和文号能直接参与过滤比纯向量检索精准得多。语义去重是另一个被低估的环节。政府网站和行业网站经常互相转载同一篇政策解读同一个通知可能出现在三四个网站上直接入库后重复块会被多次检索到挤占结果页面。我的做法是对入库文本计算SimHash设定一个汉明距离阈值低于阈值的视为重复内容只保留来源权威性最高的那一份。这个在探矿语料上实测效果很好因为政策文本基本都是官方通稿转载很少改动正文。5.3 动态渲染页面与列表-详情页结构有些地调系统的信息平台是前后端分离的列表页是HTML详情数据靠接口动态加载。requests直接抓详情页拿到的是空壳。这种情况我的方案是分两类处理如果接口返回JSON且结构规整直接请求接口解析JSON字段比解析HTML可靠得多如果接口有签名校验或者不可直接访问就退到Selenium或Playwright渲染页面后再抓。我一般优先推荐直接找接口。方法是在浏览器开发者工具里看详情页发出的XHR请求很多API路径就藏在/api/detail?id123这类地方。探矿行业的系统往往没有复杂签名直接拼参数就能拿到数据比上浏览器自动化快且稳定。但要注意抓取频率必须控制——单位网站服务器抗不住高频请求QPS设置成0.5-1每次请求间隔随机化同时遵守robots.txt的约定这个底线不能破。列表-详情页结构还有一个常见问题列表页只给标题和摘要详情页才是全文。如果你只抓了列表页RAG里就只有几十个字的摘要检索命中后信息量严重不足。我的管线是先抓列表页解析出详情页URL再去抓详情页正文并把列表页的标题和日期合并进详情页的metadata。这样入库的每个网页对象同时拥有标题、发布时间、来源URL、正文四个完整字段切块和检索都有据可依。6. 切块与metadata设计从清洗干净到查得准清洗完的文本如果切块策略不对前面的功夫会白费一大半。这一节讲我的切块原则和metadata设计这些经验是根据探矿业务文档特征反复调出来的。6.1 按文档结构切块而非固定窗口入行时我用过最朴素的固定窗口切块——每500字符一块重叠100字符。在探矿文档上效果极差一块里可能包含半张表格加半个段落语义不完整。后来我改成了结构感知切块。具体做法是先把清洗后的文档转成Markdown格式保留标题层级#、##、###和表格结构。切块时按标题层级作为主边界从最高的层级往下切如果某个标题下的内容太短就向上合并到兄弟节点如果某个标题下的内容过长比如一个大地质背景章节写了上万字就以二级标题或表格为子边界拆成多个子块。这个策略里最关键的一点是子块要继承父级的标题路径。比如一个关于XX矿区蚀变带特征的块它的metadata里要写入矿区概述 地质特征 蚀变带 XX矿区蚀变带特征这整条路径。检索时用户问XX矿区的蚀变带有哪几种这个块能通过标题路径快速命中而且Embedding匹配时标题路径可以拼进文本显著提升召回率。我实测同一批清洗后的探矿文档从固定窗口切块切出来的500块命中率只有结构感知切块的三分之二左右。6.2 关键metadata经纬度、矿种、报告编号探矿业务检索有一个强烈的领域特征用户经常按矿区、矿种、时间、报告类型来找内容。这些条件光靠向量检索很难精确满足必须靠metadata过滤。我在清洗管线的输出阶段会为每个块生成一个metadata JSON包含以下字段字段示例提取方式矿区名称白云鄂博矿区从标题或首段矿种稀土、铁矿领域词表匹配经纬度范围109.5°E, 41.7°N正则提取报告编号DZ-2023-015正则提取报告类型普查/详查/勘探关键词分类年份2023标题/正文提取来源格式PDF/TXT/Word/Web管道级记录维度经纬度数据在探矿检索里尤其重要。用户经常问的是XX坐标附近的矿化信息如果metadata里有经纬度就能做空间过滤向量检索只在候选集内跑速度和精度都提升一大截。我见过一些团队把坐标写进正文向量化检索108度30分附近时效果很差因为度分秒的写法在向量空间里毫无距离感。坐标这种数值型条件就适合结构化过滤不适合向量匹配。6.3 实测中embedding检索的常见失效模式清洗和切块都做完了检索仍然可能失败。分享一下我在这类项目里经常遇到的三种失效模式和对应的处理经验。第一种是同义表述失效。用户问金品位文档里写的是Au品位。Embedding模型对小写化学元素符号和中文关键词的映射不敏感。我用的补丁方案是在清洗阶段做术语归一化——把Au品位统一写成金Au品位g/t统一为克/吨。这一步在清洗时做比在查询时做改写要省事得多。第二种是数值范围查询失效。用户问品位大于3克每吨的矿段向量检索对这种数值条件几乎无能为力。纯靠RAG系统很难正确处理这类查询好一点的方案是把数值条件识别出来后转成结构化过滤条件对metadata或表格数据走规则查询向量部分只负责召回相关文档。这个混合检索Hybrid Search架构在探矿场景下几乎是必须的。第三种是表格块语义孤岛。表格数据被清洗成Markdown表格后Embedding对它理解得还是不如自然语言段落。我发现的缓解办法是在切块时给表格块配一句自然语言的摘要放在表格前面作为引导文本。这段摘要由清洗管线自动生成取表头列名的中文拼接加一行典型数据检索时优先匹配这段引导文本再定位到表格块。这招在化验结果表、钻孔数据表的检索中效果很稳定。7. 入库后的验证与持续迭代清洗质量要能用数据说话清洗工作不是一锤子买卖。我认为每个RAG项目都必须建立一套清洗质量回归机制否则很难知道改动是变好还是变坏。我常用的验证方式是构造一个领域评估集——从真实业务中挑出50到100个比较典型的问题每个问题标注好期望命中的源文档位置。比如XX矿区主矿体平均品位是多少对应某详查报告的第三章表格某年某省发布的矿权管理新规是什么文号对应某政策网页。每次清洗管线改动后都用这批题跑一遍检索计算命中率。命中率涨了改动保留跌了回滚。清洗管线本身的代码组织和版本管理也要像对待正式项目一样。我的习惯是每个清洗环节封装成独立的类或函数输入输出都是统一格式的JSON中间产物落盘方便排查问题环节。比如一个文档从原始TXT到最终切块中间会生成乱码检测结果、清洗后文本、Markdown转换结果、切块列表、metadata JSON五种中间文件。平时这些文件不占多少存储但在某个文档被检索得很差时可以直接把中间文件翻出来定位是哪一个环节出了问题。还有一个值得提的教训不同批次的文档清洗参数可能不一样。我处理过一个项目2010年以前的报告多是扫描PDF2010以后的报告是电子Word为主。我最初用同一套管线处理所有文件结果扫描件的OCR参数在电子文档上表现很差浪费了大量算力。后来在管线入口加了文件类型探测和年代估计两个前置判断不同类别走不同清洗子流程效率提升立竿见影。清洗管线的架构从设计第一天起就要考虑可扩展性和可配置性别指望一套参数打通所有格式。最后说一点我在实际项目里的体会。清洗工作枯燥、琐碎、见效慢但它是整个RAG系统里ROI最高的一环。很多团队把精力花在调Embedding模型、换向量库、调检索参数上结果数据没洗干净改什么都收效甚微。特别是在探矿这种专业领域文档的稀碎程度远超通用语料不做清洗高精度检索就是空中楼阁。我希望这篇分享能让你少走几趟弯路——从乱码到高精度检索中间隔的不是一个神奇的模型而是一条老老实实的清洗流水线。