企业官网建设流程全解析

去年接了一个矿区历史资料整理的项目，第一批TXT打开全是乱码，扫描版PDF用通用OCR跑完，"ZK301孔深285.6m"变成了"ZK30l孔深285.6m"，检索"ZK301"怎么都匹配不上。当时第一反应是Embedding模型不行，向量库不行，折腾了两周才发现，问题根本不在RAG链路的中后段，而在这批文档压根没洗干净。这篇就把我在探矿业务里和TXT、Word、PDF、网页这四种格式死磕出来的清洗经验完整写出来，从乱码根源到切块策略，再到上线之后的维护坑，一次性说清楚。

1. 探矿文档的"脏数据"画像：为什么这套清洗管线非做不可

先讲一个反直觉的结论：RAG的检索精度天花板，不是由Embedding模型决定的，而是由进向量库之前的文档质量决定的。模型再强，喂进去的是乱码和断裂表格，召回结果就是一堆语义噪音。探矿这类传统行业资料尤其严重，文档格式跨度大、历史跨度长、专业符号密集，如果不先把清洗管线做扎实，后面每一步都是在给错误数据做美化。

1.1 一次真实的翻车：乱码文档进向量库之后

我当时拿到的是某铅锌矿区几十年的历史勘探资料，包括早年用老式文字处理软件存盘的TXT、大量扫描成PDF的地质报告，以及一部分从行业网站抓下来的公告网页。最开始图省事，写了个脚本把TXT按UTF-8读出来，PDF直接交给OCR工具识别，网页用正则粗暴去标签，然后统统灌进向量库。

结果线上检索一测就出问题：用户问"ZK303孔浅部矿层的铅品位"，系统返回的是完全不相关的段落，因为原始文档里"ZK303"被OCR成了"ZK3O3"（数字0和字母O混淆），Embedding模型根本不知道该把这两个Token关联起来。更离谱的是，一份Word格式的地层对比表在提取时被拼成了一长段纯文本，原本的"顶板深度-底板深度-岩性描述"结构全部丢失，检索"蚀变带厚度"的时候，模型把整张表搅在一起返回了一段谁也看不懂的文字。

这次翻车让我意识到，探矿文档的"脏"是有共性的，而且远比想象中严重。直接把原始文件切块再Embedding，等于拿一堆半成品去做菜。

1.2 探矿RAG的四大格式难点

我梳理了探矿业务中最高频的四种来源格式，它们的病根各不相同，必须分开对症下药。

这四种格式在真实项目里往往是混合存在的：一个矿区的资料包既有老TXT，也有扫描PDF，还有从矿权公示网站抓下来的公告。清洗管线必须同时覆盖所有路径，任何一条短路都会拖垮整体检索效果。

1.3 清洗管线在整个RAG链路里的定位

整个RAG链路可以粗略划分为采集、清洗、切块、Embedding、向量检索、生成。很多团队把清洗当成一种"不做也行"的预处理，但实际上它是决定检索精度的核心环节。

你可以把清洗理解成浏览器显示网页时的编码设置：网页本身是GBK编码，浏览器当成UTF-8解析，显示出来全是乱码，这时候你不会觉得是浏览器渲染引擎不行，而是会先改编码。RAG也一样，原始文档的编码、排版、OCR结果出了问题，Embedding模型再优秀也无能为力。所以清洗做的事情有两个层面：一个是把乱码和OCR错误修掉，保证文本"可读"；另一个是把表格、公式、段落结构还原出来，保证文本"语义完整"。这两点做不到，检索精度就是空中楼阁。

2. TXT与Word清洗：编码判定和排版残留是两座山

TXT和Word是Office时代最基础的两种格式，看上去简单，实际坑最深。TXT的坑集中在编码判定，Word的坑集中在格式残留和结构丢失。这两个格式处理好了，清洗管线就算打下了半壁江山。

2.1 TXT乱码的根因：编码识别顺序不能错

TXT本身没有编码元信息，打开时用什么编码去解，完全取决于读取方的猜测。早年地质队员在Windows和DOS环境下存的文件，绝大多数是GBK或GB2312编码，但很多现代工具默认按UTF-8读取，中文字符一旦用错编码解码，就会变成"锟斤拷"这一类的经典乱码。

我的处理顺序是这样的：

1. 以二进制方式读取文件，先检查头部有没有BOM。有BOM的话，直接用BOM指定的编码（UTF-8、UTF-16）解码，这一步能解决一部分问题。
2. 没有BOM就用charset-normalizer或chardet做编码探测，输出概率最高的候选编码。
3. 解码时优先尝试GB18030而非GBK。GB18030是GBK的超集，能覆盖更多生僻字和冷门字符，探矿资料里经常出现的地名生僻字，靠GBK是解不出来的。
4. 无论解出来什么编码，统一转成UTF-8落到清洗中间件里，后续所有环节都只用UTF-8。

import chardet from charset_normalizer import from_bytes def safe_decode(raw: bytes) -> str: # 1. 有BOM就按BOM解码 if raw.startswith(b'\xef\xbb\xbf'): return raw.decode('utf-8-sig', errors='replace') if raw.startswith(b'\xff\xfe') or raw.startswith(b'\xfe\xff'): return raw.decode('utf-16', errors='replace') # 2. 无BOM，用chardet探测 guess = chardet.detect(raw[:10000]) encoding = guess.get('encoding', 'utf-8') try: return raw.decode(encoding, errors='replace') except LookupError: pass # 3. chardet搞不定时，退回charset_normalizer result = from_bytes(raw).best() if result is not None: return str(result) return raw.decode('gb18030', errors='replace')

这里有一个非常容易踩的坑：文件在采集或传输过程中被截断，最后一个汉字只剩一半字节，解码后会产生U+FFFD这个替换符。这些替换符如果不清理，会原样进入Embedding模型。所以解码之后要专门做一轮非法字符清理，把\ufffd、控制字符、零宽字符全部去掉，并且把所有全角空格统一成半角。

TXT清洗完成后，还要做一次人工抽检，随机打开几份文件确认内容语义通顺。编码探测算法不是万能的，遇到极短文本或纯数字文本经常猜错，抽检能兜底。

2.2 从docx里保住表格结构：地质报告最值钱的部分不能丢

Word清洗很多人用一个python-docx把paragraphs拼起来就结束了，但探矿报告里最值钱的信息恰恰在表格里：地层对比表、样品化验单、储量估算表。这些表格一旦被拍平成一长段文本，行列对应关系就没了，检索阶段面对"某钻孔见矿深度是多少"这类精确数据问题，基本是瘫痪的。

我的做法是把段落和表格分路解析，再按文档顺序合并。段落直接取文本，表格则逐行读取，单元格之间用制表符或竖线分隔，并给表格整体打上"附表编号"作为元数据标记。这样后续切块时可以把表格单独作为一个结构化块，检索时用户问到表格内容，可以直接命中对应行。

from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph def iter_block_items(parent): from docx.oxml.ns import qn for child in parent.element.body.iterchildren(): if child.tag == qn('w:p'): yield Paragraph(child, parent) elif child.tag == qn('w:tbl'): yield Table(child, parent) doc = Document("某矿区详查报告.docx") for block in iter_block_items(doc): if isinstance(block, Paragraph): print(block.text) else: for row in block.rows: cells = [cell.text.strip() for cell in row.cells] print(" | ".join(cells))

旧版.doc格式没有直接可用的Python解析库，我的经验是优先用LibreOfficeheadless模式转成docx再继续清洗，转换后要随机抽几页对比转换前后内容，防止字体和表格样式在转换中丢失。这里有个细节：早期地质报告里大量使用"宋体+仿宋+黑体"混排，转docx后字体信息会留在styles里，清洗时不要丢弃，字体可以辅助判断标题层级和正文顺序。

2.3 公式、符号与生僻字：Word清洗里的"隐藏炸弹"

探矿报告里到处都是上下标和化学符号：Fe₂O₃、ZnO、ΣREE、Ag品位等。直接提取纯文本时，上下标信息会丢失，变成"Fe2O3"这种容易被误读成普通数字的文本。我处理这类内容的标准做法是，解析时检测上下标，用markdown式的下划线或插入可读文本表达，例如把Fe₂O₃写成"Fe_2O_3"，把ΣREE写成"稀土总量（ΣREE）"。这样既保住了原意，又不影响Embedding模型对语义的理解。

Word里更麻烦的是公式。老报告里用MathType或AxMath插入的公式，原始结构是OMML格式，直接转纯文本就是一大段乱码。如果公式本身是图片，还得单独走OCR公式识别链路。对检索场景来说，我的建议是：能转LaTeX就转LaTeX保留语义，转不了的至少保留公式编号和一句话说明（例如"公式3-2：储量计算加权平均公式"），避免切块时把公式图片当乱码处理，同时让大模型在生成回答时知道这里有个公式。

生僻字和地名异体字也是一大类。GB18030能解决一部分，但还有一部分是历史写法差异，比如异体字"峆"和简写地名用字。这种问题最有效的方案是建立行业自定义词典，把高频错字、异体字、旧称映射到规范写法，在清洗阶段做一次规则替换。词典要基于语料持续更新，这也是为什么后面要强调清洗日志和样本库的重要性。

3. PDF清洗：文本层、版面还原与OCR兜底的三层防线

PDF是探矿业务里最复杂的格式，没有之一。同样是PDF，有的有文本层，有的是纯扫描件，有的是"扫描件套了一个透明文本层"，处理路径完全不同。我的经验是把PDF清洗拆成三层防线：先判断文本层可用性，再做版面还原，最后才是OCR兜底。

3.1 先判断PDF有没有"可用的文本层"

很多人拿到PDF就急着调OCR，结果把一个明明有文本层的文件用OCR重新跑一遍，反而引入一堆识别错误。正确的第一步是判断文本层是否可用。用PyMuPDF提取前几页文本，统计有效中文字符在总字符数里的占比，如果可读字符占比太低，或者提取出来的字符流和肉眼看到的内容完全对不上，就说明文本层不可用或字体映射有问题。

字体映射错误在国产软件导出的PDF里很常见：文本层存在，但ToUnicode映射表是错的，提取出来一堆乱码或方框。这种PDF靠修文本层很难，直接走OCR更实际。判断标准很简单：抽样提取三页，看字符流里是否存在大量"口"、乱码、方框，或者单词之间没有任何空格，出现这些特征就转OCR管线。

import fitz def check_text_layer(pdf_path): doc = fitz.open(pdf_path) sample_text = "" for page in doc.pages(start=0, stop=min(3, len(doc))): sample_text += page.get_text() if not sample_text.strip(): return "no_text_layer" # 统计中文字符占比 zh_chars = sum(1 for ch in sample_text if '\u4e00' <= ch <= '\u9fff') total = len(sample_text.replace(" ", "").replace("\n", "")) ratio = zh_chars / total if total else 0 if ratio < 0.1 and total < 20: return "no_text_layer" return "usable"

有文本层的PDF也不是直接提取就完事，页眉页脚、页码、交叉引用要单独处理。探矿报告经常每页顶部都有项目名称和共几页的字样，这些内容进了切块就是纯噪音。我用一个规则：通过坐标位置过滤掉页面上方和下方的固定区域，同时用正则把"第X页"、"共X页"这类模式删除。

3.2 扫描件OCR：选型对比与行业词表纠错

如果文档确实没有可用的文本层，OCR就是必经之路。我的选型经历比较曲折，最开始用开源Tesseract，中文识别效果在清晰印刷体上还行，但老扫描件模糊、背景有噪声时就完全不行了，数字和字母经常混淆。后来换成PaddleOCR，中文识别效果和表格结构识别能力都明显强一截。

探矿数据通常在企业内网处理，我的建议是优先本地化部署PaddleOCR。CPU模式跑起来确实慢，但胜在可控，几百页报告中午挂上跑，睡个午觉起来就完事了。真正要关心的不是速度，而是OCR之后的错字怎么修。

OCR错字最致命的地方是专业实体：钻孔编号"ZK301"识别成"ZK30l"，坐标纬度和经度里的"0"和"O"混在一起，化学符号"Zn"变成"Zr"。这些错字直接用Embedding模型根本救不回来，因为模型看到的是完全不同的Token。我的做法是建一个行业词表，把所有常见的易混淆字符对和关键词列表放进纠错器里做后处理：

• 数字与字母混淆：0/O、1/l、8/B
• 单位符号：g/t识别成g/1或g|t、m变成rn
• 化学元素符号：Zn与Zr、Pb与P、As与A5
• 常见专业词：品位识别成品仕、岩芯识别成岩心（行业术语保留原样）、矿化识别成矿他

每次OCR完先跑一轮纠错，再抽几页人眼看，把新的错例补充进映射表。OCR不可能做到100%正确，关键是把检索时最依赖的字段级信息（钻孔编号、深度、品位、坐标）控制到可接受范围。

3.3 表格和多栏版面：从视觉排版回到语义顺序

扫描版PDF经过OCR之后，得到的是散落的文本框，它们的位置是视觉坐标，不一定是阅读顺序。探矿报告最常见的版面是两栏正文加跨页表格，如果直接按坐标排序提取文本，会出现表格和正文交错、列顺序错乱的问题。

这一步我推荐用版面分析模型自动识别页面里的标题、正文、表格、图片区域，再按阅读顺序重组。PaddleOCR的PP-Structure就带这个能力，识别完会把每个区域标注类型和坐标，我再根据坐标从左到右、从上到下重排正文顺序，表格单独提取并按行合并。跨页表格尤其要小心，一个表格可能在第5页底部被截断，第6页顶部续排，我清洗时遇到"续表"字样会把两个表格片段按表头拼接成一张完整表。

版面还原的目的是让文本从"视觉上的块"变成"语义上通顺的段落"，这一步做得越细，后续切块时越不容易把一句话拆成两半。

3.4 混合型PDF的双轨处理

实际项目里还有一类更磨人的PDF：同一份文件有几十页扫描件，中间夹了几页文字版，或者每一页既有扫描图片又有文本层。我的处理方式是按页判断，逐页决定走文本提取还是OCR，最后按页码顺序合并成一个完整文档。

这里要强调：必须给每页打一个处理路径标记。比如文本层可用的页面标记为"text"，走OCR的标记为"ocr_zh"，后面做质量评估时能清楚看到哪些页面是OCR结果、哪些是原生文本，排查问题时也能快速定位。这类标记信息我会原样保存在文档的元数据里，进了向量库之后依然可以用于检索过滤。

4. 网页资料清洗：从HTML表格到结构化字段

探矿业务里大量公开资料来自矿权公示和出让公告网站，这些网页的清洗和普通文章完全不同。普通文章清洗的目标是提取通顺正文，而公告类页面的核心价值在表格里的结构化字段：探矿权人、许可证号、有效期限、勘查面积、坐标范围。

4.1 网页正文提取：公告页与普通文章要分开处理

用通用正文提取算法处理公告页是常见翻车点。Readability这类算法对新闻文章效果好，但遇到全是表格的公告页，要么丢表格，要么把表格内容横七竖八地塞进正文。我的经验是分两套方案：普通介绍性文章用通用正文提取，公告、公示、备案类页面用XPath模板化抽取。

模板化抽取的意思是，针对固定来源的网站，手工分析页面结构，用XPath把正文容器、表格容器、字段位置指出来。这样做的好处是稳定，坏处是要维护。对高频来源站点维护十几个模板，换来的是公告字段几乎零丢失，我觉得非常值得。

from lxml import html import requests resp = requests.get("https://example-mining-announcement.gov.cn/detail/12345", timeout=10) doc = html.fromstring(resp.text) # 假设公告详情页正文在 #main-content 下，表格在 .table-announcement 下 main_content = doc.xpath('//div[@id="main-content"]//text()') tables = doc.xpath('//table[contains(@class,"table-announcement")]')

网页本身的标签噪音也要处理干净：导航栏、版权信息、备案号、"上一篇/下一篇"链接、翻页碎片，这些都要在模板层就滤掉。有时候公告页面是JS动态渲染的，直接requests拿不到正文，需要headless浏览器渲染后再抓，但清洗逻辑保持不变。

4.2 字段抽取：把"人看的表格"变成"机器读的记录"

矿权公示信息里最核心的字段包括：项目名称、探矿权人、勘查单位、许可证号、勘查矿种、有效期限、勘查面积、坐标范围。这些内容在网页上以表格形式呈现，我的处理方式是先用BeautifulSoup解析表格结构，转成DataFrame，再把DataFrame按行变成结构化记录，写入PostgreSQL或SQLite。

这样做和"把整个表格拍平成文本"的本质区别在于：结构化记录既能进RAG向量库做语义召回，又能支持精确SQL查询。比如用户问"某省近三年出让的铅锌矿探矿权"，我先用结构化字段过滤，再走向量语义检索，效果和只靠向量检索完全不在一个量级。

坐标范围是一类特殊字段，网页上经常是"东经99°00′00″—99°30′00″，北纬35°00′00″—35°30′00″"这种文本。我清洗时会解析成数值区间并存成结构化字段，这样检索时能支持空间范围过滤。这个功能在探矿场景很实用，用户问"某某坐标附近有没有正在公示的探矿权"，可以直接命中。

4.3 去重与版本管理：别让向量库存三份一样的公告

同一份矿权公告经常被多个网站转载，同项目的PDF和网页版也可能并存。我做过去重统计，一个矿区的资料包里，网页公告和PDF报告的重叠率能到15%以上。这部分数据如果不清理，向量库里会堆满近似重复的chunk，检索时同一份内容占掉好几个Top位置，严重稀释检索质量。

去重方案我从简到繁试过几种：最基础的是内容哈希，整段文本算MD5，完全重复的直接扔掉。但网页转载经常带不同模板、不同页眉，完全一样的哈希几乎见不到，所以实际用的是SimHash或MinHash做近似去重，相似度超过阈值的文档只保留一份。

保留哪一份有讲究，我的规则是优先保留来源权威、文本更完整、清洗错误更少的版本，同时把source_url和抓取时间记录进元数据。网页版和PDF版并存时，如果PDF版是官方盖章扫描件，保留PDF版；如果是内容一样的网页转载，保留网页版就够了，因为文本更干净。

5. 清洗之后的最后一公里：切块、元数据与质量验证

文档清洗完之后，还有一关直接决定检索精度：切块和元数据注入。这一步做不好，前面所有的清洗努力都会在最终效果上打折扣。探矿业务的问题类型和通用知识库不一样，切块策略也要跟着调整。

5.1 切块策略不能脱离问题类型

探矿场景的提问大体分两类。第一类是段落型问题："这个矿区的区域地质背景是什么"，答案是一段通顺描述，适合用常规段落块。第二类是字段型问题："ZK303孔浅部矿层铅品位多少"，答案来自表格里某一行的某个单元格，这时候普通段落块根本没法精确命中。

我的做法是让切块尊重文档结构：段落按标题层级切，表格直接整体作为一个块，字段型内容单独切出一个"结构化摘要块"。探矿报告里的表格经常跨页，清洗阶段我已经把表格合并复原了，切块时整个表格入一个chunk，不硬拆。固定字数硬切是最省事的方案，但遇到表格和公式会切得支离破碎，检索精度直线下降。

参数上我习惯用300~500 token的窗口，重叠80~100 token，但每个项目都要拿验证集跑一遍再调，没有放之四海皆准的固定值。中文字符在LLMTokenizer里的占比和英文不同，300 token大概对应三百多个汉字，但对表格类内容，半个表就可能超过这个数，所以结构化块和段落块分开设参数更合理。

5.2 元数据与过滤：把高精度检索变成"先筛后搜"

给每个chunk打元数据是提升检索精度的性价比之王。我维护的元数据字段包括：

• 文档编号：对应原始文件名，方便溯源
• 矿区名称：直接决定检索范围
• 资料类型：报告、公告、规范标准、新闻
• 格式来源：TXT、Word、PDF、网页
• 页码/表格编号：用于精确定位
• 清洗路径标记：text还是ocr_zh

检索时先根据用户问题做一轮元数据过滤，比如用户问的是"某矿区详查报告里钻探情况"，系统先过滤出该矿区且资料类型为报告、字段内容包含钻探的chunk，再走向量召回。这样既缩小了语义搜索范围，又天然避免了跨矿区、跨资料类型带来的噪音。

实际链路顺序是：查询意图分析 -> 元数据过滤 -> 向量召回 -> 重排。这个顺序不要反过来。先召回再过滤的问题是，向量搜索已经把所有相似内容都混在一起了，过滤只能去掉一部分噪音，精度损失已经造成。

5.3 用标注问题集验证清洗效果：从乱码率到命中率

清洗做没做到位，不能靠肉眼感觉，要靠量化指标。我建了一套标注问题集，大概四十到五十条，覆盖不同类型问题，每条都标注了正确答案所在的源文档和页码。清洗前和清洗后各跑一遍RAG，统计Top5/Top10命中率，用数据说话。

这个结果很直观：清洗前后Top5命中率提升了30个百分点。除了命中率，我还会随机抽20到30个chunk人工检查文字准确率、段落是否断裂、表格是否完整。这一步能发现自动化指标发现不了的问题，比如某个段落被分成两半、某张表格的表头和表体错位。

6. 清洗管线上线后的三条保命经验

前面讲的是技术方案，最后分享几条在真实项目里被现实毒打出来的经验。这些经验不属于教科书，但在生产环境里每一条都救过我的时间。

6.1 没有清洗日志，后面调优就是盲人摸象

清洗管线一定要记录每份文档的处理日志：检测到的编码、乱码率、走了文本提取还是OCR、OCR置信度、版面分析结果、丢弃的页数和原因。这些日志有两个作用：一是线上出问题时能快速定位是哪一步洗坏了；二是新OCR模型上线或词表更新时，能用同一批历史文档做回归对比，看看准确率到底提升了多少。

我之前有一版清洗脚本跑完没留日志，后来一份报告的表格全被拼乱，排查半天也不知道是版面分析模型的问题还是Word解析路径的问题。加日志之后，这类问题定位从小时级缩短到分钟级。

6.2 部署形态决定OCR方案，别一上来就上GPU

OCR方案的部署形态要和数据量匹配。如果只是一个矿区的历史资料，总计几千页扫描件，单机CPU跑PaddleOCR完全可以接受，挂一晚上跑完，第二天看结果。为了提速上一台GPU服务器，后续的驱动维护、环境兼容、内网部署成本反而可能比收益还高。

但如果知识库要持续扩容，每个月都有新资料进来，那OCR就是常态化任务，GPU的投入就划算。我见过太多项目在起步阶段就搞了一套重部署，结果维护人员离职后整套环境没人敢动。先评估数据增量和处理频率，再决定部署形态，比一开始就追求最优性能稳得多。另外云OCR效果好，但探矿资料属于企业内部敏感数据，数据出不出域、交给第三方处理是否符合企业数据安全要求，这个合规问题必须在选型阶段就想清楚，不能等数据传上去才意识到。

6.3 把清洗做成管道不是脚本

最后一条：清洗逻辑一定要设计成可配置的管道，而不是每次手工改脚本。解析器、清洗器、校验器做成独立组件，用一套配置描述"这个来源走什么解析器、套什么清洗规则、用什么校验器"，新增一种格式时只加配置不写新脚本。

我早期每次拿到新格式就复制一个脚本改改，维护了几个月就乱成一锅粥。后来把所有逻辑收拢成一条管道，TXT、Word、PDF、网页都是插拔式组件，清洗规则和行业词表外置成配置文件，整个系统的可维护性一下子上来。这也是知识库能长期运行、资料持续扩充的根基。

这条管线我前后调了快两个月才稳定下来，回头看最值的投入不是换Embedding模型，而是把清洗层做实。探矿业务里很多历史资料都是不可再生的，清洗一次之后，后面建索引、做问答、出报告都建立在干净数据上。希望这篇能帮你少走点弯路，如果后续有新格式的坑，我也打算继续整理出来。