从乱码到高精度检索探矿业务中 TXT、Word、PDF 与网页的 RAG 清洗之道上个月知识库上线后内部同事反馈最多的一句话是明明有这份报告怎么搜不到刚开始我还以为是 embedding 模型选得不对后来把原始文档打开一看一长串乱码、表格散成碎片、扫描页连 OCR 都没有——这根本不是检索算法的问题是进库之前的数据就已经坏了。做 RAG 项目的人大多有过类似经历模型搭得再像样清洗环节掉链子召回质量直接归零。尤其是探矿这类重文档业务大量历年地质报告、矿产储量表、区域规划文件以 TXT、Word、PDF、网页公告等多种格式散落在内网盘和旧站里格式杂、老版多、扫描件占比高。这篇文章就聚焦一条主线在探矿业务场景下如何把脏乱的非结构化文本清洗成高精度检索可用的知识片段。适合正在做企业知识库、本地 RAG、行业文档解析的工程师也适合刚接触 RAG 但对为什么检索不准一头雾水的人。下面所有方法都是我在实际项目里跑通过的路径代码片段可以直接拿走改。1. 乱码之外还有多少隐形乱码探矿文档检索差的真实原因先说一个反直觉的结论很多检索不上来不是因为向量化做得差而是因为喂给向量模型的文本本身就是坏的。文本坏不只有乱码这一种表现更像三层叠加在一起的污染字节层面坏了、格式层面碎了、语义层面丢了。三层全处理到位才谈得上高精度检索。1.1 检索差不是你 embedding 的问题是切片本身太脏RAG 的工作链条大致是文档 → 解析 → 清洗 → 切分 → embedding → 存储 → 检索。大多数人会把精力花在 embedding 模型选型、向量库调参、Rerank 设置上默认文本解析是小事。但真实业务里的文档远不像示例数据那样工整。探矿领域更是如此单位符号混用ppm、g/t、m³ 等在转码过程中变成 、□、乱码字符专业名词变形蚀变带变成蚀 变 带中间被换行符劈开表格结构碎裂储量计算表在 Word 里是清晰行列转成 TXT 后变成一堆数字串语义完全丢失页眉页脚污染每页重复的项目名称、页码、密级标识进入切片后形成大量重复片段扫描版 PDF全文是图片解析出来零文本必然检索不到。这些问题的共同点在于它们都不会让程序崩溃但会让向量对文本语义的判断发生偏移导致该召回时不召回、不该召回时乱召回。换句话说清洗不是在美化数据是在保护检索质量的下限。1.2 探矿文档的特殊难点多格式、老版本、结构嵌套如果只看公开教程里的 RAG常给人PDF 直接转文本就能用的错觉。探矿业务文档却有明显的领域特征清洗管线需要为这些特征专门设计。文档特征具体表现清洗难点多格式并存老项目有 TXT 采集数据、Word 报告、PDF 扫描件、网页公告每种格式解析路径完全不同版本跨度大部分文档是十年前的 GBK 编码甚至无编码声明乱码率高需编码探测结构嵌套深多级标题、附录、表格、公式、插图混排切片时容易打断逻辑关系扫描件占比高早期地质档案大量纸质扫描需要 OCR 且识别准确率敏感敏感信息多发的旧版页脚密级、区域代号、经纬度坐标清洗时要做敏感脱敏或过滤第三点特别值得展开。探矿报告的矿床特征 → 矿体赋存状态 → 资源量估算结构在 Word 里看是清晰的但转成纯文本后往往变成一坨连续的段落。如果直接按固定长度硬切很可能把一个完整的矿体描述从中间切断检索时你问矿体走向答案却被拆到两个 chunk 里谁也找不全。1.3 我给乱码下的三层定义字节乱码、格式乱码、语义乱码为了方便团队内部讨论我把乱码分成三层后续所有清洗步骤都是围绕这三层逐层消除第一层字节乱码字符编码不匹配如 GBK 文件按 UTF-8 打开出现一串锟斤拷。这一层最直观也最好修但修完之后并不意味着文本可用。第二层格式乱码没有乱码字符但版式结构全丢了。表格变流水账、标题和正文混在一起、列表缩进消失、页眉页脚混入正文。很多开发者在第一层结束后就宣布完工实际是假完工。第三层语义乱码文本看起来是正常句子但语义颗粒度、上下文完整性已经被破坏。典型如矿体走向为北东向倾角较缓平均 55°被切片拆成两句向量化之后前后关联丢失。第三层必须在切分策略里解决不是解析环节能独立完成的。我一般会把这三层写进清洗管线的验收标准里字节乱码要为零格式乱码要结构完整语义乱码要靠检索评测兜底。下面按文档类型逐一讲具体操作。2. TXT 与 Word 清洗先解决字节乱码再拆出版式结构TXT 和 Word 是探矿业务里最普及的两类文档源。前者老项目批量导出的监测数据、测绘记录一堆后者是历年报告的主力形态。两者都逃不开两个问题编码与结构。2.1 TXT 编码识别与标准化不要猜用探测再兜底我接手的老探矿数据里光 TXT 编码就出现过 UTF-8、GBK、GB18030、BIG5甚至同一文件内混排的情况。最可靠的第一招不是打开文件看而是用工具探测import chardet with open(survey_2007.txt, rb) as f: raw f.read(100000) # 采样前10万字节足够 result chardet.detect(raw) print(result) # {encoding: GBK, confidence: 0.99}对绝大多数 Linux 收尾环节我用 iconv 做转码iconv -f GB18030 -t UTF-8 survey_2007.txt survey_2007_utf8.txt这里有三个我踩过坑的经验不要把整个大文件一次性丢给 chardet采样读取性能好而且避免误判。在老版中文文档里GB18030 和 GBK 的置信度经常接近我习惯把 GB18030 作为兜底编码它对生僻字和少数民族字符的支持更全。探测结果不可靠时优先尝试 UTF-8 严格解码报错再回退 GB18030。在探矿领域的旧报告中UTF-8 和 GBK 大概各占一半按这个顺序能减少无谓的二次转码。转码完成后必须做一次乱码字符扫描比如用正则抓 、锟斤拷、锘 这类典型残留出现异常直接回到原文件人工复核或换编码。TXT 本身没有版式结构清洗的重点在去噪。老数据里常见行尾有多余空格、制表符分隔混乱、连续空行这些看着不起眼在后续切分时却会让段落判断失真。我一般会做一次 line 级别的规范化strip 行尾空白、把 Unicode 全角空格转半角、超过两个连续换行压缩成一个。2.2 Word 转 Markdown 的两条路线python-docx 与 pandoc 的真实分工Word 清洗的核心矛盾是我们需要保留结构标题、表格、列表但 Word 原生格式又不好直接喂给文本切分器。我的标准做法是先把 docx 统一转成 Markdown 或结构化的中间格式再做后续处理。对 xlsx 后添加的旧版 .doc 文件优先走 LibreOffice 批量转换libreoffice --headless --convert-to docx storage_reserve_2005.doc --outdir ./converted对 .docx 文件则有两条常用路线第一条纯文本提取用 python-docx。适合只需要正文段落、标题级别的场景轻量、灵活我可以自己控制哪些段落保留、哪些段落丢弃from docx import Document doc Document(储矿层厚度分析.docx) for para in doc.paragraphs: text para.text.strip() if text: # 依据 style 判断标题层级 print(para.style.name, text)第二条完整版式转换用 pandoc。它是把 docx 转 Markdown 最省心的工具能保留标题层级、表格、列表、粗斜体我实测在长报告上的转换质量稳定pandoc 2023年度勘探报告.docx -t markdown -o report.md --wrapnone --extract-media./media这里要解释一下为什么我坚持先转 Markdown 再切分而不是直接按 Word 段落编号切分。Markdown 是一种轻量、人类可读、结构显式的中间格式转出来之后我可以直接用标题符号# 级别作为切分锚点表格能保留管道符分隔向量化时这些结构符号也在语义边界比纯文本清晰得多。pandoc 转出的 Markdown 还能完整保留多级标题这是后续按结构切分的重要基础。2.3 Word 表格、公式、页眉页脚的定向清理Word 清洗真正的坑藏在表格、公式和页眉页脚这三类内容里。表格是我最谨慎的部分。探矿报告里的储量表、样品分析表行列结构承载着大量信息。直接按行读出再拼接数字会彻底失去语境。我通常把整个表格转成 Markdown 表格保留同时记录表格标题让切片器把表 3 矿区储量估算结果和表格主体放在同一片段内。公式是另一个老大难。老报告里的公式可能是 Word 公式对象、图片或者 MathType 嵌入直接提取会得到空字符或乱码。我采用的折中方案是公式转图片后单独抽离文本流中用占位符标记比如同时在清洗元数据里保留 LaTeX 转写正文版本。如果后续需要计算或问答由 LLM 根据图片再解释而非混入正文切片。页眉页脚和域代码必须提前剥离。我用 pandoc 时曾有报告把每页重复的内部资料混进正文检索时把大量重复片段召回。处理方式分两层在转换前用 Word 的样式机制过滤页眉页脚内容转换后在文本中扫高频短行比如出现次数超过全文档页数 70% 的行直接剔除。这一步看着简单但能大幅减少重复噪声对精度提升很直观。3. PDF 清洗扫描件靠 OCR、电子件靠解析、双层件靠对齐PDF 是探矿文档里最硬的一块骨头。原因很直白PDF 不是一种排版友好的格式而是最终打印效果的封装。不同团队产出的 PDF 形态完全不同清洗策略也完全不同。我在项目里把 PDF 先分成三类再分别处理试过之后发现时间和效果都能接受。3.1 不要拿到 PDF 就 OCR先判断文件属于哪一类PDF 类型判断方法提取路径电子版 PDF内置文本层可直接复制出文字PyMuPDF 按坐标提取文本块扫描版 PDF整页都是图像提取文本为空OCR 识别双层 PDF底层是图像上层覆盖透明 OCR 文本优先取文本层必要时与 OCR 对齐判断方式我用 PyMuPDF 直接试提文本先看输出长度是否为零或极短import fitz doc fitz.open(drill_log_2012.pdf) total_chars 0 for page in doc: total_chars len(page.get_text(text)) print(total_chars) # 0 或几千说明基本是扫描件如果文本量为 0或者单页平均不到 50 个字符直接走 OCR 管线。如果文本量正常还要抽查几页看是否有明显的识别错字、换行错乱不能只看数量。3.2 电子版 PDF 的坐标级提取用阅读顺序重排文本块很多开源解析器对双栏、多栏 PDF 的文本顺序处理得并不好提取结果常常先右栏后左栏语义连续性被打断。我用 PyMuPDF 的get_text(dict)拿到每个文本块的坐标再按从上到下、从左到右的逻辑重新排序。这里不贴完整代码核心思路是把页面上的文本块用 bbox 的 y 坐标聚类成行同行内按 x 排序跨栏页面再按列分割重排。探矿报告里很多老 PDF 是双栏排版不做这一步检索效果直接腰斩。排序完成后还要做一次段落合并把同一段落但被换行符拆开的行重新拼成一个完整段落。判断依据是行尾是否以标点或明显断句符号结束以及下一行的首字符缩进情况。这一步完成后得到的文本流才能进入后续的切片环节。3.3 扫描件 OCR识别精度取决于预处理 后处理两条腿扫描版探矿档案是清洗成本最高的部分。我用 PaddleOCR 处理中文扫描件效果明显优于早期尝试的通用 OCR尤其在单位符号和数字混排场景下。整个链路分三段第一段图像预处理。扫描件常见问题是偏斜、暗角、分辨率不足。我一般先转成 300 DPI 以上再做倾斜矫正必要时做灰度自适应二值化。地质图件里的细线、小字如果直接识别噪声极大预处理能显著降低误识别。第二段OCR 识别。PaddleOCR 的调用方式大致是from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(drill_core_page.png, clsTrue)识别结果会返回文本框坐标、置信度和文字内容我可以按坐标排序后组装成页面文本。这里有个重要细节不要把整页交给 OCR 后再祈祷它排对而是按段落区域切割后分别识别再用坐标归位能提升长文顺序的准确率。第三段后处理纠错。OCR 输出里最常见的错字集中在矿体走向这类专业词上比如北东向被识别成北方向、品位被识别成位品。我维护了一个领域词典做替换纠错词典内容从大概几百条开始随项目逐渐扩充。遇到拿不准的高频词还可以用文本中词频统计来辅助判断哪个写法在本报告中出现次数多就保留哪个写法。3.4 双层 PDF 的对齐增益文本层为主OCR 为辅双层 PDF 看起来省事直接用文本层提取即可但我在项目里发现部分双层 PDF 的文本层质量参差不齐——有些是后期生成时漏字符有些是坐标错位。稳妥的做法是双轨并行默认提取文本层按 3.2 的坐标重排逻辑组装内容对文本层明显缺字或错误率高的页面再跑一遍 OCR用 OCR 文本做交叉校验。如果同一坐标区域 OCR 结果与文本层差异过大标记为待人工复核而不是自动覆盖。这个流程确实比无脑提取文本层耗时但对精度要求高的探矿业务收益明显。我之前处理过一批 90 年代的矿权报告双层 PDF 上层文本层几乎全军覆没全靠 OCR 兜底才没让这段历史数据变成检索黑洞。4. 网页采集清洗从 HTML 标签噪声里还原正文探矿知识库除了本地文档还有大量网页来源地质调查局公告、矿权成交公示、行业资讯、项目招标页等。网页清洗的核心矛盾是提取正文不难难的是把正文从一堆导航、侧栏、推荐、页脚里干净地切出来。4.1 正文提取器不要自己造轮子trafilatura 是性价比最高的选择早期我试过自己用正则抓p标签结果被各种嵌套结构折磨到怀疑人生。后来切换到trafilatura一条命令解决大部分问题import trafilatura html requests.get(url).text markdown_text trafilatura.extract( html, output_formatmarkdown, include_linksFalse, include_imagesFalse, favor_precisionTrue, )这里要解释一下为什么选它trafilatura 融合了版面分析启发式规则和文本密集度打分能自动跳过导航、表格、推荐链接返回干净的正文。在探矿公告类页面上的实测效果比通用 Readability 更稳因为这类页面往往正文长、导航杂、广告少——恰好是 trafilatura 的强项。如果你遇到 trafilatura 提取结果为空动态渲染页常见我兜底方案是先用 Playwright 或 Selenium 渲染出静态 HTML 再提取而不是直接对原始 HTML 硬抠。某些招聘公告、矿业交易系统页面是 JS 渲染的直接抓取会抓回来一堆空壳标签。4.2 网页编码坑请求头声明和实际内容对不上网页清洗的第一个拦路虎是编码。不少老式政务网站返回charsetgb2312但实际内容可能是 GBK甚至 UTF-8。requests 库默认会猜测但经常猜错。我的处理顺序是先读响应头中的 Content-Type charset优先认它再解析 HTMLmeta charset如果两者不一致以meta为准的命中率更高两个都没有或者转换异常用 chardet 探测 HTML 内容字节流最后统一转为 UTF-8 文本。三层探测听起来繁琐但早期因为忽略编码声明不一致把整个批次网页索引成了乱码文本后来又重跑了一轮采集时间成本远超当时的偷懒节省。这个教训我记到现在。4.3 导航链表单剔除后还有三类隐形噪声必须抽走剔除导航和页脚只是第一步。网页正文里还有三类噪声会直接污染切片语义首段的来源某某网 发布时间2024-05-20以及点击量这类元信息行。我的处理方式是提前抽离到文档元数据字段里不进入正文切片。文末的相关阅读上一篇下一篇这类链接块。trafilatura 的默认配置偶尔会带上我在清洗后做一次尾部截断。正文中的图片说明行比如图 1 矿区地理位置。这类信息如果保留可以变成极有价值的位置描述如果图片本身没被解析仅留图 1 矿区地理位置反而成了无意义片段。我通常把配图说明与正文一起保留因为它是探矿语义线索但在后续 embedding 时单独控制权重。4.4 网页去重URL 规范化 内容哈希双保险同一份矿权公告可能被多个政府站点转载内容一样但 URL 不同。如果全塞进向量库会导致大量重复召回。我在采集入库前做了两道闸第一道URL 规范化。去掉 utm 参数、去尾部斜杠、统一 http/https 形式用规范化后的 URL 做一级去重。第二道内容指纹去重。把提取出的正文做归一化后去掉空格、标点、换行用 MD5 或 SimHash 生成内容指纹指纹相同但 URL 不同的文档直接合并保留权威来源标题其余标记为转载。SimHash 在长文档上的容错更好能处理个别字被修正过的转载变体。我给这类网页清洗定了条硬标准没有元数据来源、时间、原链接的网页片段不能进知识库否则检索回来无法溯源在探矿业务里等于埋了雷。5. 统一清洗管道设计与验收让脏数据变成可检索的知识片段以上四类文档的清洗方案单独看都能跑通但落成一个真实知识库项目时必须把它们编排成一条统一管道做到进库前一致、检索时可溯源。5.1 管道分四层解析层、清洗层、结构化层、切分层我把管道设计成四个层次每层职责单一方便单独调优和排查解析层负责把原始文件按类型转成中间形态——TXT 转文本流、Word 转 Markdown、PDF 提取/OCR 成文本流、网页提取成正文 Markdown。清洗层负责消除三层乱码——编码标准化、噪声剔除、OCR 纠错、页眉页脚过滤。结构化层负责把清洗后的文本拆成语义块比如标题、正文段落、表格、列表并在块级别挂载元数据来源文件、页码、区块类型。切分层负责把语义块切成长度合理、上下文完整的切片附带层级信息和 chunk_id。这种分层的好处是解析层出了问题直接看原始文件清洗层出了问题对比清洗前后文本切分层出了问题检查切片边界。实际运维中排查效率比一坨大函数高得多。5.2 切分策略先按结构定位锚点再用重叠窗口兜底探矿文档的切片我坚持结构优先 重叠兜底。结构优先指的是尽量以标题为边界一个二级标题下的完整小节作为一个切片。Word 转来的 Markdown 天然有#和##标记PDF 清洗后我也尽力还原标题层级网页正文则依靠 HTML 的 h1-h3 标签。如果某一段内容太长超出了设定的 chunk_size我一般用 token 数约 800-1000对应中文场景约 1000-1500 字我再启用递归切分配置 chunk_overlap 150-200 token避免跨类目的语义断裂。核心代码如下from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size1000, chunk_overlap150, separators[\n\n, \n, 。, , , ], ) chunks splitter.split_text(markdown_text)这里要强调separators 的顺序很关键。中文文档里把。和放在之前能让切片切在完整的语义边界上而不是在长句中间硬切。我测过很多版本这个顺序在探矿报告上的可读性最稳。5.3 清洗质量验收不看文本好看看检索指标严格来说清洗搞得好不好不能靠看起来挺干净来判断要用检索指标说话。我在项目里建立了三个验收维度维度工具/方法合格线字节乱码率全库扫描非法字符、编码异常0%结构完整率抽样人工对比原文与切片表格完整、标题存在≥95%检索命中率构造 20-30 条探矿业务查询对比清洗前后 Hit Rate 与 MRRHit Rate 提升≥30%MRR 提升≥0.2其中最硬核的是检索命中率。我会预先整理一批业务真实问法比如XX矿区铜矿平均品位是多少XX 报告中的资源量估算方法是什么。清洗前后跑同样的查询对比 Top 5 命中情况和排名均值。这样清洗优化才有方向感而不是凭感觉反复调参。为了提升探矿文档的召回精度我在切分后还会做一步元数据注入把报告编号、矿区名称、年份、文档类型拼进切片前缀比如[矿区:XX铜矿 | 来源:2023年度勘探报告 | 类型:储量表]。这样在做向量检索时可以配合元数据过滤也能让 embedding 在生成向量时感知所属上下文比纯正文切片多了一层业务锚点。5.4 旧数据的清洗闭环脏数据回溯重跑不丢信任知识库上线一段时间后往往还会发现有部分文档检索质量不佳。我会把这些问题文档标记出来回溯到管道的具体环节重新清洗而不是直接在向量库里改数据。这套回溯机制由三部分组成每份文档记录清洗版本号、每次入库保留清洗前后文本快照、检索结果中关联文档的清洗版本信息。这样做的好处是任何一次清洗规则调整都可以对全库跑一遍重放用同一套验收指标对比前后效果数据质量变动全程可追溯。在探矿业务里数据可信度是硬指标宁可多花一小时回溯清洗也不能让错误数据留在知识库里造成误判。写在最后的实际操作体会这几轮清洗管线跑下来我最深的体会是RAG 项目的质量瓶颈绝大多数不在模型而在上游数据的工业化程度。探矿业务尤其如此——格式杂、老版本多、扫描件比例高清洗根本不是可有可无的预处理而是整个检索系统的主线工程。字节乱码能靠编码探测和转码解决格式乱码得靠解析策略和结构还原打通语义乱码则要靠在切分和验收环节反复校验。每一层都到位了向量检索才会有真正的高精度可言。如果只让我给刚起步的团队留一条建议那就是先建清洗验收指标再调任何模型参数。没有指标你根本分不清一次召回变差是 embedding 的问题还是数据源的问题。清洗和检索的成败从来是同一个问题的两面。