做探矿业务的 RAG 知识库最容易被低估、也最容易被卡死的环节不是模型选型也不是向量数据库调优而是最前面的文件清洗。我见过太多团队把地质报告、钻孔记录、化验数据一股脑塞进解析脚本结果出来的文本全是乱码和断裂段落检索时召回一堆莫名其妙的片段回答自然也就没法看。我这两年做矿区历史资料数字化和知识库落地接触最多的就是 TXT、Word、PDF 和网页四类来源。它们各自的乱码成因、解析陷阱、清洗策略完全不同但最终目标只有一个让进入向量库的每一段文本都干净、稳定、有上下文。这篇文章就把我从乱码到高精度检索的完整清洗流程、踩过的坑和排查技巧一次性说清楚适合正在做地质资料RAG、知识库建设、文档解析的工程师和数据人员参考。1. 探矿文档的“百格式混战”乱码与检索失效的根源1.1 为什么探矿业务特别吃“清洗”这一套探矿行业的资料有一个很典型的特点来源杂、年代跨度大、格式混乱程度远超一般企业文档。我接触过的真实场景里一个中型矿区的存档资料往往包含三类东西第一类是野外原始记录包括采样记录本、钻孔编录表、物化探数据这些很多是从老式仪器或早期数据库系统里导出的最常见的是TXT纯文本文件但编码可能是GBK、GB2312、UTF-8甚至Big5混用文件里还夹杂着制表符、空格缩进、行号、分页符。第二类是正式成果报告包括储量估算报告、可行性研究、评审意见书大多是Word和PDF。Word文档的问题在于版本混乱有早期.doc格式有后来.docx格式页眉页脚、批注、修订痕迹、域代码、内嵌公式、图片表格混在一起PDF则分文本型、扫描型和加密型三类扫描件占比相当高。第三类是外部参考资料来自行业公示、协会标准、同业机构网站以网页为主需要从大量导航、广告、版权声明中剥离出真正有用的正文。这些资料共同构成了一个“百格式混战”的局面。普通办公文档清洗可能只需要处理少量格式探矿资料则要把老式编码、多层嵌套表格、扫描图件、地理坐标信息全部兜住。这里有一个很容易被忽视的点地质文档里的术语和符号高度依赖上下文。比如“Au品位2.3g/t”“ZK301孔”“γδ矿体”这类内容一旦编码转换出错或者OCR识别出错变成“Au品位2.3glt”“Z K301孔”检索系统根本不可能把它跟用户的提问关联上。所以探矿场景下的RAG不是“向量化之后就能检索”而是“清洗之后才有资格向量化”。数据干净程度直接决定检索精度的天花板这不是夸张。1.2 乱码到底从哪来“锟斤拷”与“烫烫烫”的由来做探矿资料清洗必须先认识几类典型乱码。它们看起来像无规律字符实际背后是固定的编码错位问题。最常见的是“锟斤拷”。这个乱码的成因很典型一段原本是GBK编码的中文文本被某个程序按UTF-8解码再按GBK重新编码保存于是原本的汉字字节序列被转换成了一串无效字符最终固定显示为“锟斤拷锟斤拷”。在探矿资料里老式数据库导出的TXT文件经常出现这种问题因为导出工具默认用了错误的字符集。还有一种经典乱码是“烫烫烫”。这是C/C程序调试版中未初始化内存的填充字节0xCC在GBK编码下被显示成“烫”0xCD被显示成“屯”。如果一份TXT文件里全是“烫烫烫屯屯屯”说明这个文本根本不是正常文本可能是程序异常导出的文件需要直接从源头追溯。第三种情况出现了字符“”这是Unicode替换字符UFFFD意味着某些字节无法映射到任何合法字符。这类乱码常见于从网页复制到TXT又从TXT转Word的多次转码链条中。理解乱码成因是为了在清洗时知道该用什么工具去修复而不是盲目替换。比如“”可以尝试用GB18030强制解码修复而“烫烫烫”直接是无效数据再修也没有意义。探矿资料清洗的第一步并不是写解析脚本而是先做识别识别之后才有修复策略。2. 清洗流水线怎么搭分探测、分级、分格式三层设计2.1 别急着解析先做格式探测与分类我早期犯过一个错误拿到文件后直接按扩展名调用解析库结果大批文件因为实际格式与扩展名不符而解析失败。后来我总结出一套前置流程任何格式进来先做三类探测第一是文件头探测。用二进制方式读取文件前若干个字节判断真实文件类型。TXT/CSV是纯文本通常没有特殊文件头PDF固定以%PDF开头DOCX/ZIP格式的文件头是PKDOC的老格式则是OLE复合文档头D0 CF 11 E0。这个步骤能快速识别“扩展名是PDF但实际是DOC”这类伪格式文件。第二是编码探测。对于纯文本文件用chardet库做编码检测并配合一段地质领域采样文本做二次校验。比如某份TXT文件如果解码后出现“矿区”“钻孔”“矿化”“蚀变”这些词说明编码大概率正确如果解码后全是符号和无意义字符则尝试GB18030、UTF-8、Big5依次解码看哪种方案能正常解析中文。第三是质量抽样。按文件大小和来源分层抽样读取每个样本的前50行、中间50行、末尾50行检查是否有空行堆叠、行号残留、乱码、表格错位等问题。这个抽样能给出一个整体质量画像用于后续的分级处理。完成这三步探测后每个文件都应该有一个元数据记录真实格式、编码类型、抽样质量评分、预计清洗难度。这个清单本身就是后面分级清洗的依据。2.2 分级清洗把力气花在刀刃上探矿资料量通常不小一个矿区动辄几百份文档、几万页内容。如果每一份都精修到完美成本和时间完全不可接受。我采用的策略是分级清洗把文件按价值和处理成本分为三级A级是核心资料包括储量报告、钻孔编录表、采样化验数据表、矿区设计文件。这些是检索和问答的核心数据源必须全量清洗、逐段校验特别是表格数据要保证行列完整。B级是辅助资料包括区域地质调查报告、技术方案、评审意见等。这类文件做结构化清洗重点保障段落完整和标题层级清晰表格只要不出现严重错乱即可。C级是参考类资料包括行业新闻、通知公告、宣传材料。这类文件只做基础清洗把导航噪声和乱码段落去掉能入库检索就行。分级的意义在于控制投入产出比。探矿RAG系统的回答准确率主要依赖A级和B级资料把C级资料做到八十分就够用了。我实测下来分级清洗能把整体清洗时间压缩约40%而检索精度几乎没有下降。2.3 清洗后的质量校验别省这一步很多人清洗完就直接切块入库结果到检索环节才发现某些文件依然是乱的只能回头重新清洗。正确的做法是入库前做一次自动质量校验我用三项指标第一项是可读字符占比。清洗后的文本中中文字符、英文字母、数字、常见标点应占总字符数的95%以上。如果出现连续超过5个特殊符号或控制字符直接标记为异常文件。第二项是乱码特征检测。直接匹配“锟斤拷”“”“烫烫”等固定乱码模式只要出现该文件必须回到人工复核环节不能入库。第三项是段落结构与长度分布。正常的地质报告段落长度集中在50到500字之间如果一段文本超过2000字且没有任何标点大概率是PDF解析时丢失了换行符如果全文平均段落长度只有十几个字可能是表格被错误拆散。这两类异常都说明解析参数需要调整。校验环节在探矿场景中特别重要因为地质报告里大量内容是“数字密集”的比如品位、深度、坐标、储量这类信息一旦错位检索时不会被发现但回答会被带偏。3. 四类格式的清洗实操TXT、Word、PDF与网页的逐个击破3.1 TXT编码识别、乱码修复与表单文本规范化探矿业务里的TXT文件最常见的是两类一类是老数据库导出的文本记录另一类是GIS矢量数据导出的属性表。后者在热词里提到的“shp转txt”“GIS矢量如何转txt”就属于这个场景。不管哪类TXT清洗的重心都在编码和结构上。编码识别我推荐用Python的chardet库做初判再用GB18030作为兼容保底。原因在于GB18030是GB2312和GBK的超集能覆盖绝大多数中文字符遇到老编码文件时用GB18030解码成功率最高。实际操作时我会写一个自动解码函数按UTF-8、GB18030、GBK、Big5的顺序依次尝试以“能否成功解码且乱码率低于阈值”为判断依据。import chardet def smart_decode(content: bytes) - str: # 先用 chardet 预测编码 detected chardet.detect(content) candidates [detected.get(encoding), utf-8, gb18030, gbk, big5] for enc in candidates: if not enc: continue try: text content.decode(enc) # 乱码率粗略判断替换字符占比 bad_count text.count(\ufffd) text.count(锟斤拷) if bad_count / max(len(text), 1) 0.01: return text except (UnicodeDecodeError, LookupError): continue return content.decode(gb18030, errorsignore)解码之后TXT文件还要处理几个结构问题一是去掉行号很多老文本导出时每行前面带了“0001”“0002”这类编号需要按正则去掉二是合并断行地质文本里经常因为排版原因把一句话拆成多行我用的策略是“当前行末无标点且下一行首字母非大写或非数字时合并”三是清理制表符对齐产生的多余空格特别是表格型文本。对于GIS导出的TXT属性表我会先按分隔符解析成结构化表格再逐列清洗。这类文件里常见的问题有坐标字段带多余空格、属性值里混入换行符、空值字段用了不同字符表示“NULL”“-9999”“空”。统一清洗成标准格式后这些表格数据可以单独入结构化存储也可以转成自然语言描述文本供RAG使用。3.2 Word样式灾难、批注残留、公式与表格的专项处理Word文档是探矿业务里最“体面”但最暗藏危机的格式。表面看段落完整实际上页眉页脚、修订痕迹、批注、域代码、内嵌对象都会污染提取结果。处理Word我分两种情况.docx用python-docx直接解析老式.doc先用LibreOffice以headless模式转换成.docx或纯文本。转换命令很简单soffice --headless --convert-to docx --outdir /output_dir 老文件.doc这里要提醒一个坑LibreOffice转换长文档时偶尔会丢表格边框或改变分页所以转换后必须重新校验文件可读性不能直接当docx用。如果服务器上没有LibreOffice也可以把.doc文件丢给Windows端的Word COM对象处理但稳定性不如LibreOffice。python-docx提取时我会默认做四件事第一剥离页眉页脚。地质报告的页眉通常包含报告编号和密级字样这些内容如果不剥离会混入正文成为噪声检索时产生大量重复片段。第二清除批注和修订痕迹。python-docx本身不直接暴露批注需要解析XML节点把w:comment和w:ins/w:del相关节点排除掉。第三删除不可见文本和域代码残留。Word域代码在提取时可能输出奇怪的指令文本需要按{}结构识别并跳过。第四规范化段落标题。把Word里的“一、”“1.1”“第一章”这类标题样式统一映射为Markdown标题层级方便后面按标题切块。表格是探矿Word文档的高价值区也是提取的重灾区。我处理表格时采用“保留表头行转文本”的方式先识别表头行再把每一行数据拼接成“表头1: 值1表头2: 值2”的文本。比如钻孔编录表的一行会转成“孔号: ZK301深度: 125.6m岩性: 花岗岩矿化: 黄铁矿化”。这样做的好处是既保留了表格的结构信息又让这段文本在向量化时能被自然语言检索命中。插入的图片和公式python-docx提取不了内容图片需要单独导出做OCR公式则涉及热词里提到的“Word公式转LaTeX”问题。Word里的公式通常是以OMML格式存储的如果报告中有大量公式如储量计算方法、地质统计学公式可以用工具将OMML转成LaTeX再转成纯文本描述。没有现成工具时退而求其次的做法是把公式整体替换为占位符“[公式]”避免公式字符污染正文。3.3 PDF文本层、扫描件、双栏与表格还原PDF是探矿资料中最复杂、也是坑最多的格式。探矿行业的历史扫描件极多很多早期报告根本没有电子文本层。碰到PDF第一步永远是用PyMuPDF或pdfplumber检测文件是否带文本层。判断方法简单粗暴尝试提取第一页的前500个字符如果提取结果里中文可读字符占比低于50%基本可以断定是扫描件需要走OCR路线。文本型PDF的处理相对直接但我依然会处理几个细节一是双栏问题。很多期刊论文和行业报告是双栏排版直接按阅读顺序提取时左右两栏的文字会交错。我的处理方式是先用pdfplumber检测页面文字的x坐标分布如果文字明显分为左右两簇就按“先左栏后右栏”的顺序重新组装文本。二是换行问题。PDF提取文本时段内换行符和段间换行符无法区分。我会用“行尾字符是否以句号、分号、冒号、逗号结尾”来推断是否为段尾然后对非段尾的行做拼接。三是表格识别。文本型PDF里的表格pdfplumber的extract_table()多数时候能直接抽出来但合并单元格、跨页表格会出问题。稳妥做法是抽取之后按“表头: 值”格式转成文本跨页表格用表头重复检测来拼接。扫描型PDF是真正的硬骨头。我的工具链首选PaddleOCR加PP-Structure它对中文识别、版面分析标题、段落、表格、图例的支持比较好。处理流程是先按页面渲染成高清图片再做版面分析识别出文字区域、表格区域和图件区域然后对文字区域做OCR识别对表格区域做表格结构还原图件区域单独裁剪存储并生成说明文字。OCR之后的文本还需要一次后处理修正常见OCR错字比如“矿”识别成“旷”、“蚀”识别成“独”、合并断词断行、清除置信度低于阈值的识别结果。我会把OCR文本和原始页面图像都保留方便人工抽检。这一步虽然耗时但探矿数据里数字和术语一旦错识后续影响极大。加密PDF也要单独说明有些加密PDF只是禁止复制用PyMuPDF打开时会报权限错误对这种文件可以先尝试用空密码或已知密码解锁实在不行只能走OCR路线。3.4 网页正文抽取、去噪与动态渲染的兜底探矿业务里的网页数据主要来自行业公示、协会通知、标准发布页、同业官网的政策文件和展会资料。网页清洗的核心是“正文抽取”把导航栏、推荐位、广告、页脚版权声明全部剥离。我常用的工具是trafilatura它专为正文抽取设计能自动识别文章的标题、正文、发布时间对中文支持也较好。用法很简单import trafilatura downloaded trafilatura.fetch_url(url) text trafilatura.extract(downloaded, include_commentsFalse, include_tablesTrue)但在实际项目中trafilatura对结构复杂的页面会漏内容所以我通常配合BeautifulSoup做兜底先用trafilatura抽正文如果结果为空或长度异常就用BeautifulSoup按“article”“main”“content”等常见正文容器class去定位正文节点再递归提取段落和表格。这里有一个探矿场景特有的点网页里的地质数据和表格往往不是静态HTML而是通过JavaScript动态加载的。比如某些统计数据的列表页直接requests拿到的是空壳页面正文全靠前端接口渲染。这种情况我用Playwright做无头浏览器抓取等待页面加载完成后把document.body.innerText和表格DOM都取下来。动态页面抓取的成本更高所以我只在静态抓取确认失败时才启用并给这类页面打上“动态渲染”的元数据标记。抓下来的网页正文我还会再走一道清洗去掉连续空白字符、去除时间戳里的多余信息、把相对链接的锚文本清理掉最后转成Markdown格式存储。网页数据在探矿RAG中的作用主要是补充最新政策、标准和行业动态质量要求比正式报告低但正文噪声必须控制住。4. 分块与元数据清洗之后的最后一公里4.1 面向探矿文档的分块策略别一刀切洗干净的文档如果直接按固定字数切块依然会破坏地质报告的语义结构。我见过一个很典型的案例把一份储量报告按500字等长切块结果一个钻孔的描述被切成两半检索时永远只召回半截信息回答自然不完整。正确的做法是先按文档结构切再按需要补重叠。我的流程是第一步识别文档的标题层级。清洗时已经将标题规范化成了Markdown格式这一步直接按#、##、###的层级切出“章节块”。地质报告的章节通常有明确的小结和结论整章保留能最大程度维持语义完整。第二步处理超长章节。储量报告里的“矿体地质特征”一章可能有几十页整章切块会导致块体积过大、向量化时信息被稀释。我的策略是在章节内部再按子标题或自然段落切分同时保留章节标题作为前缀上下文。第三步表格单独成块。清洗后的表格文本“表头: 值”格式通常已经很规整我会把一张表格整体作为一个块并在块前面拼接表格标题和所属章节标题避免表格被切散后语音上下文断裂。第四步设置重叠窗口。对于正文段落我采用chunk_size500字符、overlap80字符的参数确保跨块边界的信息不会丢失。这里不推荐直接用token数作为切分单位因为地质术语和数字会被tokenizer拆得比较碎字符级别的切分在中文场景下更直观可控。4.2 元数据标注让检索自带“矿区”“矿种”“时间”上下文探矿资料有一个天然优势元数据非常明确。矿种、矿区/工区名称、文件类型、编制年份、数据来源这些在文件头或者文档正文里通常都有关键是要把它们抽出来存成结构化字段。我清洗时会给每个块附加一组元数据矿种Au、Cu、Fe、Pb-Zn等、矿区名称、文件类型报告/化验/设计/批复/公告、年份、来源URL或档案编号。这组元数据有两大作用一是入库后的过滤检索。用户问“XX矿区金矿品位特征”系统先用元数据把矿种Au、矿区XX的文档过滤出来再走向量相似度召回效果远好于纯向量检索。尤其在矿种多、资料杂的项目里没有元数据过滤的RAG会频繁召回其他矿种的相似表述精度很难看。二是回答时提供引用来源。吐出“依据XX报告第X章”会极大提升业务人员对知识库的信任度。这也是探矿这种严肃业务对RAG系统的基本要求。如果资料结构化程度足够高还可以在清洗过程中尝试抽取实体关系钻孔编号、勘探线号、矿体编号之间的关联构建一个小型知识图谱与RAG配合使用。热词里提到的“ontology RAG”“KG知识库”在这类场景是有价值的但前提仍然是清洗后的文本质量过硬不然图谱抽取的垃圾进、垃圾出。4.3 清洗、分块、向量化与重排序的完整链路到这里整套流程的脉络已经清楚了清洗解决“文本能不能读”的问题分块解决“语义完不完整”的问题元数据解决“检索范围准不准”的问题最后再通过向量化和重排序解决“相关度排序对不对”的问题。向量化阶段中文场景下我会优先选支持中文的Embedding模型如bge-m3这类它对长文本和中文术语的理解比通用英文模型好很多。探矿术语“矽卡岩型矿床”“构造蚀变岩型金矿”这类词组好的中文Embedding模型才能抓住语义相关性。重排序阶段我习惯在向量召回Top 50之后用bge-reranker这类的交叉编码器重新打分取Top 10送入大模型。重排序器能弥补向量模型对“精确数字匹配”和“否定语义”的不足。比如用户问“某某矿区的储量是多少”重排序器能更准确地判断文档里“某某矿区没有进行储量估算”这类段落和提问的相关程度。这套链路里清洗虽然是第一步但它的影响贯穿全程。一个清洗失败的数字比如把3.2g/t识别成32g/t向量化阶段看不出问题检索召回也能命中但最终问答结果就是错的。探矿业务对数字的敏感性远超普通文档这决定了清洗质量必须当作第一优先级来对待。5. 常见问题与排查技巧实录5.1 乱码问题速查表实操中遇到的乱码问题我整理成速查表便于按症状对号入座乱码表现可能原因处理方案“锟斤拷”反复出现UTF-8解码GBK字节流并回存用GB18030重新解码原始字节再转UTF-8“烫烫烫”“屯屯屯”程序异常导出的未初始化内存视为无效数据从源头重新导出大量“”替换字符多次转码导致字节丢失尝试GB18030强解码无法还原则重新OCR中文正常、英文和数字乱码CJK字符编码与ASCII字符编码混用用正则定位混用区分段修复OCR后“矿”变“旷”、“蚀”变“独”扫描质量差或识别模型误差建立地质术语错字映射表批量替换PDF提取后所有句子挤成一行段间换行符丢失用标点符号规则重新分段5.2 检索精度低的排查链路如果清洗和分块都做了检索效果还是差我建议按下面这条链路排查而不是盲目换模型第一步查召回。在向量库中直接检索几个典型问题看Top 10结果里有多少条其实是相关文档。如果相关文档召回不到50%问题大概率出在清洗质量或分块粒度上——先检查是否有乱码文件漏入库再检查段落是否被切得太碎。第二步查重排序。如果Top 10召回尚可但精准答案排不到前面就是重排序环节不足。要么没加重排序器要么重排序器的领域适配不够可以用人工标注的问答对微调重排序模型。第三步查生成。如果检索Top 3都很准但问答还是错说明大模型在生成时可能被低质量上下文干扰或者上下文窗口被无关内容填满。这时候要压缩单次送入的上下文数量把提示词改为“只依据给定材料回答不要使用内部知识”能显著减少幻觉。探矿RAG有一个特殊点用户问的“品位”“储量”“深度”这类数字不能只看语义相似还需要精确匹配。我会在检索链路里加一个“数字强制召回”规则用户提问中出现矿种、孔号、品位数值时先用元数据和正则做一次精确匹配把命中文档强制插入Top候选。这个技巧在实测中把数字类问题的准确率提升了很多。5.3 避坑清单这些坑我都替你踩过了第一个坑用扩展名判断文件类型。探矿资料流传过程中经常被改名PDF后缀的文件可能是Word另存的。必须用文件头探测兜底不然解析脚本会在奇怪的地方崩掉。第二个坑忽略页眉页脚和批注。Word报告提取时没剥离页眉结果每条检索结果都带着“机密”字样既占向量空间又影响相似度。这个在回流测试时很难发现但确实在拖累效果。第三个坑扫描件直接交给通用OCR。地质报告里有大量图件、曲线、柱状图通用OCR会把图例文字和正文混杂输出。必须用版面分析把图件区域单独隔离避免图面标注污染正文。第四个坑切块时把表格切散。储量和品位数据都在表格里一刀切会让数字碎得没法用。我后来坚持表格独立成块整表进入向量库效果立刻改观。第五个坑不保留中间产物。清洗和解析过程的中间文件原始字节、解码后的文本、OCR文本、抽出的表格一定要留存。探矿资料往往需要反复核验来源没有中间产物时只能重新跑一遍流程浪费大量时间。第六个坑入库前不做合规确认。探矿资料涉及未公开地质信息和图件在数字化和入库前应该确认资料的使用边界和密级要求。这既是行业规范也是保护项目自身的必要步骤。5.4 一个端到端的清洗流程参考最后给一个我在实际项目中用过的端到端清洗流程范本不算标准答案但可以作为搭流程的起点# 伪代码探矿资料清洗主流程 def main(file_path): # 1. 文件头探测真实格式 fmt detect_real_format(file_path) # 2. 按格式分派解析 if fmt txt: raw_text smart_decode(open(file_path, rb).read()) clean_text clean_txt(raw_text) elif fmt docx: clean_text clean_docx(file_path) elif fmt doc: convert_doc_to_docx(file_path) clean_text clean_docx(temp_docx) elif fmt pdf: clean_text clean_pdf(file_path) elif fmt html: clean_text clean_webpage(file_path) # 3. 质量校验 if not quality_check(clean_text): mark_for_manual_review(file_path) # 4. 分块 元数据 chunks split_by_structure(clean_text) meta extract_metadata(clean_text) # 5. 入库 upsert_to_vector_db(chunks, meta)这个流程跑通之后我又在外部套了一层任务队列把几百个文件分批清洗出错文件单独进入人工复核桶。整个体系跑下来A级资料的入库有效率稳定在95%以上检索精度相比早期直接塞文件提升了不止一个等级。回到开始那个问题RAG的瓶颈到底在哪里我的切身体会是探矿这类数据专业性强、格式多样的业务瓶颈往往不在模型而在上游的数据工程。清洗不是苦力活它是整个RAG系统里投入产出比最高的环节之一。如果你正在做类似的地质资料知识库项目我建议先拿一个矿区的资料把清洗、分块、检索链路完整跑通再考虑扩展到全量数据。链路跑通之后换模型、调提示词都是顺手的事唯有数据质量是绕不过去的基本功。