企业官网建设流程全解析

1. 探矿业务文档处理的真实困境

地质勘探行业有一个很尴尬的现状：我们每天产生和消费的数据量极大，但真正能被有效利用的却少得可怜。一个中型探矿项目，从预查到详查阶段，积累的原始资料动辄几十个GB——钻探编录、槽探记录、物化探数据、地质填图报告、评审意见、历史档案扫描件，格式横跨TXT、Word、PDF、Excel、扫描图片甚至手写笔记的翻拍照片。这些资料散落在不同年代、不同项目组、不同人的硬盘里，命名规则五花八门，有的用“ZK3201_终孔报告_修.docx”，有的直接是“新建文件夹(3)/最终版2.pdf”。

我真正意识到问题的严重性，是在去年接手一个老矿区深部找矿项目的时候。甲方要求我们基于近十五年的地质资料，快速圈定三个靶区。按理说这种需求在RAG（检索增强生成）技术已经相当成熟的今天，搭一个知识库应该不难。但实际动手才发现，探矿领域的文档清洗和通用场景完全不是一回事。TXT文件里混着大量用空格和制表符拼出来的“表格”，Word文档里嵌着OLE公式对象和跨页表格，PDF更麻烦——有原生文本层的、有纯扫描件的、还有图文混排且图上有标注的。网页资料则来自不同地质队的公开报告页面，HTML结构千奇百怪。

这就是我写这篇东西的原因。市面上讲RAG清洗的文章不少，但大多停留在“用LangChain切分一下、用Embedding存一下”的层面，真正面对探矿业务这种多源异构、专业术语密集、格式极度不规范的场景，那些通用方案基本跑不通。我踩过的坑包括但不限于：TXT里的坐标数据被当成普通文本切碎、Word表格跨页后表头丢失导致品位数据错位、PDF扫描件OCR后“花岗闪长岩”被识别成“花岗闪长岩”（看似一样但编码不同）、网页抓取时把导航栏和页脚也塞进了知识库。这篇文章就是把这些经验系统化，给同样在探矿或类似重工业领域做RAG知识库的同行一个可参考的路径。

2. 多源文档清洗的整体设计思路

2.1 为什么不能直接套用通用RAG清洗方案

通用RAG清洗方案的核心假设是：文档结构相对规范、语言以自然语言为主、表格和公式占比低。但探矿业务文档恰恰相反。一份典型的地质报告，可能30%是叙述性文字，40%是表格（钻孔数据、样品分析结果、储量估算表），20%是图件及其说明，剩下10%是公式和符号。如果直接按固定长度切分，一个钻孔的完整数据可能被切成三段，检索时只能召回其中一段，导致品位、厚度、深度这些关键参数对不上。

更深层的问题是语义单元的定义。在通用场景里，一个段落就是一个语义单元。但在探矿文档里，一个语义单元可能是一张完整的表格、一个图版及其图注、或者一段包含多个参数的计算过程。我试过用递归字符切分，结果把“Au品位0.5g/t，厚度3.2m”和“Ag品位12g/t，厚度1.8m”切到了两个chunk里，检索“Au品位大于0.3的钻孔”时，模型只能看到前半句，完全无法回答。

所以整体设计思路必须从“文档结构感知”出发，先识别文档的物理结构和逻辑结构，再根据业务语义定义切分边界。具体来说，我采用的是“三层清洗”架构：第一层做格式归一化，把TXT、Word、PDF、网页统一转成带结构标记的中间格式；第二层做语义分块，按地质单元、表格、图版、公式等业务语义切分；第三层做元数据注入，给每个chunk打上钻孔号、勘探线号、矿种、品位区间等标签，供检索时过滤。

2.2 三层清洗架构的选型考量

第一层格式归一化，我选的是“保留结构标记的纯文本+JSON”双输出。纯文本用于后续的Embedding，JSON用于保留表格、公式、图注的结构信息。为什么不直接用HTML？因为HTML标签太冗余，而且不同来源的HTML结构差异太大，后续处理反而麻烦。自定义的轻量级标记（比如用[TABLE]...[/TABLE]包裹表格，用[FORMULA]...[/FORMULA]包裹公式）更可控。

第二层语义分块，核心是“先识别、再切分”。识别阶段用规则+轻量模型结合的方式：规则负责识别钻孔编号、勘探线号、坐标范围等强模式字段；轻量模型（我用的是一个微调过的BERT变体）负责识别段落类型（叙述、表格说明、图注、公式说明）。切分阶段按“一个钻孔一个chunk、一张表格一个chunk、一个图版一个chunk”的原则执行，同时设置最大长度限制，超长的表格按行拆分但保留表头。

第三层元数据注入，我设计了一个“探矿元数据Schema”，包含钻孔号、勘探线号、矿种、品位区间、深度区间、数据来源、置信度等字段。这些元数据一部分从文档内容中抽取，一部分从文件名和目录结构中推断。比如文件名里有“ZK3201”，就自动给这个文档的所有chunk打上钻孔号ZK3201的标签。检索时可以用这些标签做预过滤，大幅提升召回精度。

2.3 与知识图谱的协同设计

热词里提到了“kg知识库”和“ontology rag”，这确实是探矿领域RAG的一个重要方向。纯向量检索在处理“哪些钻孔位于F1断层上盘且Au品位大于1g/t”这类多条件查询时，效果很差。我的做法是在RAG之外，额外构建一个轻量级的知识图谱，存储钻孔、断层、地层、矿体之间的空间关系和属性关系。RAG负责回答“F1断层的特征是什么”这类描述性问题，知识图谱负责回答“F1断层上盘有哪些见矿钻孔”这类结构化查询。两者通过钻孔号这个主键关联，检索时先走图谱过滤出候选钻孔集合，再用RAG在候选集合内做语义检索。

这个协同设计的关键在于实体对齐。同一个钻孔在不同文档里可能写成“ZK3201”“zk3201”“钻孔3201”“3201孔”，需要在清洗阶段就做归一化。我的做法是维护一个别名表，清洗时用正则匹配+人工校验的方式把别名统一到标准名。这个工作很枯燥，但做一次就能长期受益。

3. TXT文档的清洗与结构化处理

3.1 TXT在探矿业务中的特殊地位

TXT格式在探矿行业的使用频率远超外行想象。很多老式测井设备、化探分析仪器、钻孔测斜仪的输出格式就是TXT，而且往往是固定宽度或制表符分隔的“伪表格”。这些文件通常没有表头，列的含义靠约定俗成或者配套的说明文件。比如一个典型的测井TXT可能长这样：

ZK3201 0.00 1.20 2.45 120.5 0.03 ZK3201 1.20 2.80 2.51 118.2 0.05 ZK3201 2.80 4.50 2.38 115.7 0.02

没有表头，但老地质队员一看就知道是“钻孔号 起始深度 终止深度 伽马值 电阻率 品位”。这种文件如果直接当普通文本处理，Embedding后检索“ZK3201的伽马值异常段”，模型根本找不到北。

3.2 固定宽度与分隔符的自动识别

我的处理流程是：先检测文件是否包含制表符或连续多个空格，如果有，按分隔符拆分；如果没有，按固定宽度拆分。固定宽度的检测用“列方差法”——计算每一列字符的方差，方差小的列很可能是固定宽度字段。这个方法的原理是：固定宽度字段的每一列在垂直方向上字符类型相对一致（比如深度列全是数字和小数点），而叙述性文本的列方差会很大。

识别出列边界后，需要推断每列的含义。我的做法是维护一个“列语义推断规则库”，比如“第一列匹配ZK\d+模式则判定为钻孔号”“连续两列都是浮点数且第二列大于第一列则判定为深度区间”“最后一列浮点数且值域在0.01-100之间则判定为品位”。这个规则库需要根据实际数据不断迭代，但一旦建好，处理效率极高。

注意：固定宽度TXT里经常混有中文全角空格和英文半角空格，肉眼看起来一样但编码不同。清洗时必须先统一替换，否则列拆分必错。我一般用re.sub(r'[\u3000\xa0]', ' ', text)做预处理。

3.3 无表头数据的元数据补全

对于无表头TXT，清洗后的chunk必须补上列含义说明。我的做法是在chunk开头插入一行“列说明：[钻孔号] [起始深度(m)] [终止深度(m)] [伽马值(cps)] [电阻率(Ω·m)] [Au品位(g/t)]”。这行说明不参与Embedding，但会作为元数据存储，检索时如果命中这个chunk，生成答案时会把列说明一起送给模型。这样模型就能正确理解“2.45”是伽马值而不是品位。

另外，对于跨多个钻孔的TXT文件，我会按钻孔号做二次切分，确保每个chunk只包含一个钻孔的数据。这样做的好处是检索“ZK3201的见矿段”时，不会召回ZK3202的数据造成混淆。

4. Word文档的深度解析与表格处理

4.1 Word文档的“暗坑”清单

Word是地质报告的主力格式，但也是清洗难度最大的格式之一。我整理了一份“暗坑”清单，按出现频率排序：

跨页表格表头丢失是最致命的。一份钻孔数据表可能有几百行，跨了五六页，如果只保留第一页的表头，后面几页的数据就失去了列语义。我的解决方案是用python-docx遍历表格时，检测表格是否跨页（通过比较表格前后段落的位置），如果跨页，手动把第一行的表头复制到每个分页的起始位置。这个操作在python-docx里没有现成API，需要操作XML的tblHeader属性。

4.2 表格数据的结构化提取

Word表格提取的核心目标是“保留行列关系”。python-docx的table.rows和table.columns可以遍历单元格，但合并单元格会导致行列索引错乱。我的做法是先构建一个二维数组，用cell._tc的XML属性判断合并状态，把合并单元格的值填充到所有被合并的位置。这样得到的二维数组就是规整的，可以直接转成CSV或JSON。

对于表格中的公式（比如储量计算公式），我会用正则匹配[A-Za-z]+\s*=\s*[\d\.\+\-\*/\(\)]+模式，把公式单独提取出来，用[FORMULA]标记包裹。这样后续检索“储量计算公式”时能精准命中，而不是把公式当普通文本切碎。

实操心得：Word表格里经常有“其中”“合计”这类汇总行，清洗时建议单独标记为[SUMMARY]，检索时如果用户问的是明细数据，可以过滤掉汇总行避免干扰。我试过不标记，结果模型把合计值当成了单个样品值，闹过笑话。

4.3 公式与特殊符号的归一化

地质报告里的公式主要是品位计算公式、储量估算公式、坐标转换公式。这些公式在Word里可能是OLE对象、MathType对象、或者纯文本。OLE和MathType对象用python-docx读出来是空的，需要用olefile库单独提取，或者用LibreOffice做一次格式转换。纯文本公式则相对好处理，但要注意上下标和希腊字母的归一化。

我的归一化规则是：把α统一成alpha，β统一成beta，Σ统一成sum，上下标用_和^表示。这样做的原因是Embedding模型对希腊字母的语义理解不稳定，归一化后检索“alpha角”和“α角”能命中同一批结果。这个规则看起来简单，但实测下来对召回率提升很明显。

5. PDF文档的解析策略与OCR处理

5.1 原生PDF与扫描PDF的分流处理

PDF在探矿资料里分两类：原生PDF（有文本层）和扫描PDF（纯图片）。原生PDF用pdfplumber或PyMuPDF直接提取文本和表格，扫描PDF必须走OCR。分流判断的方法是：用PyMuPDF读取第一页，如果page.get_text()返回的字符数少于50，基本可以判定为扫描件。

原生PDF的表格提取比Word更麻烦，因为PDF没有“表格”这个概念，只有绝对定位的文本块。pdfplumber的extract_table()方法基于线条和文本对齐来推断表格结构，对规整表格效果不错，但对没有边框线的表格（地质报告里很常见）就无能为力。我的补充方案是用pdfplumber的extract_words()获取所有单词的坐标，然后用DBSCAN聚类做行分组，再用列坐标的间隙做列分组。这个方法对无边框表格的识别率能到85%以上。

5.2 OCR后的专业术语纠错

扫描PDF的OCR是另一个大坑。通用OCR引擎对地质术语的识别率很低，“花岗闪长岩”识别成“花岗闪长岩”（看似一样但“闪”和“冈”在某些字体下容易混）、“矽卡岩”识别成“砂卡岩”、“辉钼矿”识别成“辉钼矿”。更麻烦的是化学元素符号，Au可能识别成Au（正确）或AU（大小写错误），Ag可能识别成Ag或A9。

我的纠错方案是“词典+规则”双管齐下。词典是从历年地质报告中抽取的专业术语表，包含矿物名、岩石名、地层名、构造名等，用编辑距离做模糊匹配。规则是针对化学元素符号和单位的，比如“元素符号必须首字母大写、次字母小写”“品位单位必须是g/t或10^-6”。经过纠错后，OCR文本的术语准确率能从70%提升到95%以上。

注意：OCR纠错不要过度，有些“错误”其实是原文的笔误或特殊写法。我一般会保留原始OCR结果和纠错后结果两个版本，检索时优先用纠错版，但如果用户明确要查原文，可以切换到原始版。

5.3 图件与图注的关联处理

地质PDF里大量图件（剖面图、柱状图、等值线图）及其图注。图注通常在图的下方，格式为“图3-1 ZK3201钻孔柱状图”。清洗时我会用正则匹配“图\d+-\d+”模式，把图注提取出来，并尝试关联到最近的图片对象。关联后的chunk包含图注文本和图片的base64编码（或图片路径），检索时如果命中图注，可以同时返回图片供用户查看。

这个关联的难点在于PDF里图片和图注的物理位置不一定紧邻，有时图注在上一页、图片在下一页。我的做法是用PyMuPDF获取图片的边界框和图注文本的边界框，计算垂直距离，取距离最小的图注作为关联对象。如果距离超过阈值（比如200像素），则标记为“图注待确认”，人工校验。

6. 网页资料的抓取与正文提取

6.1 探矿相关网页的来源分析

探矿业务的网页资料主要来自几个渠道：地质队官网的公开报告、行业论坛的技术讨论、学术期刊的摘要页、以及一些老地质队员的个人博客。这些网页的结构差异极大，有的用WordPress、有的用静态HTML、有的甚至是十几年前的表格布局。通用网页抓取插件（比如Chrome的“网页抓取”扩展）对这类网页的正文提取效果很差，经常把导航栏、侧边栏、页脚都抓进来。

我的做法是先用requests+BeautifulSoup获取HTML，然后用“正文密度算法”提取正文。这个算法的核心思想是：正文区域的文本密度（文本长度/HTML标签数）远高于导航和页脚区域。具体实现是遍历所有<div>和<article>标签，计算每个标签的文本密度，取密度最高的标签作为正文容器。对于表格布局的老网页，这个算法会失效，需要降级到“最大文本块”策略——找到包含最多连续文本的<td>或<p>标签。

6.2 正文提取后的结构重建

网页正文提取后，还需要重建结构。地质报告网页通常有标题层级（<h1>到<h4>）、列表、表格。我会保留这些结构标记，转成和Word清洗一致的中间格式。表格用[TABLE]标记，标题用[H1]到[H4]标记，列表用[LIST]标记。这样后续的语义分块可以统一处理，不用为网页单独写一套逻辑。

网页抓取还有一个伦理问题：有些网站有反爬机制，频繁请求会被封IP。我的做法是设置合理的请求间隔（至少2秒），并且只抓取公开的、允许索引的页面。对于需要登录才能查看的内容，一律不抓。这个底线必须守住，否则会给整个行业带来麻烦。

6.3 网页元数据的自动抽取

网页的元数据（发布时间、作者、来源机构）对检索很有价值。我会从<meta>标签、URL路径、页面内的“发布时间”文本中抽取这些信息。比如URL里有/2023/05/，就推断发布时间是2023年5月。来源机构从域名和页面logo的alt文本中推断。这些元数据会作为chunk的标签存储，检索时可以用“来源=某地质队”做过滤。

7. 语义分块与元数据注入的实操细节

7.1 按业务语义定义切分边界

语义分块的核心原则是“一个chunk一个完整语义单元”。在探矿业务里，我定义的语义单元优先级是：钻孔数据表 > 图版及图注 > 公式及说明 > 叙述段落。切分时按这个优先级从高到低处理，高优先级的单元先切出来，剩下的文本再按段落切分。

具体实现上，我用一个“分块状态机”来管理。状态机从文档开头扫描，遇到[TABLE]标记就进入表格状态，直到[/TABLE]结束，整个表格作为一个chunk（如果超长则按行拆分但保留表头）。遇到[FIGURE]标记就进入图版状态，把图注和图片路径一起打包。遇到[FORMULA]标记就单独成块。普通段落则按句号、分号、换行符切分，但设置最小长度阈值（比如200字），避免切得太碎。

7.2 元数据Schema的设计与填充

我设计的探矿元数据Schema包含以下字段：

这些字段的填充分自动和手动两步。自动填充用正则和规则，比如从文件名匹配ZK\d+得到钻孔号，从表格内容计算品位区间。手动填充是在自动填充置信度低于阈值时，由地质人员校验修正。这个Schema的好处是检索时可以做精确过滤，比如“查32线上所有Au品位大于1的钻孔”，先用exploration_line=32线 AND mineral_type=Au AND grade_range>1.0过滤，再在候选集内做向量检索。

7.3 分块后的质量校验

分块完成后必须做质量校验，否则脏数据会污染整个知识库。我的校验清单包括：每个chunk是否有明确的钻孔号或来源标识、表格chunk是否包含表头、公式chunk是否完整、叙述chunk是否包含至少一个完整句子。校验不通过的chunk会被标记为“待人工审核”，不进入检索库。

这个校验步骤看起来繁琐，但实测下来能拦截大约15%的脏数据。我试过跳过校验直接入库，结果检索“ZK3201的Au品位”时返回了一个没有钻孔号的表格片段，模型完全无法回答。从那以后我就把校验作为强制步骤。

8. 常见问题与排查技巧实录

8.1 清洗效果不达预期的排查路径

清洗效果差通常表现为：检索召回率低、答案包含乱码、表格数据错位。我的排查路径是“从后往前查”：先看检索结果，如果结果本身是乱码，问题在清洗阶段；如果结果正常但答案不对，问题在分块或元数据阶段；如果结果和答案都正常但召回率低，问题在Embedding或检索策略阶段。

具体排查时，我会随机抽取20个查询，人工标注期望结果，然后计算召回率和准确率。如果召回率低于80%，就逐个查询分析失败原因。常见的失败原因包括：chunk切分过碎导致语义不完整、元数据缺失导致过滤失效、专业术语未归一化导致Embedding偏差。

8.2 专业术语归一化的避坑经验

专业术语归一化最大的坑是“过度归一化”。我一开始把“花岗岩”和“花岗闪长岩”都归一成“花岗岩类”，结果检索“花岗闪长岩的含矿性”时召回了一堆花岗岩的资料，完全不相关。后来我改成“分级归一化”：大类归一（花岗岩类），小类保留（花岗岩、花岗闪长岩、二长花岗岩），检索时可以用大类做粗筛、小类做精筛。

另一个坑是“同义词表维护”。地质术语的同义词极多，比如“矽卡岩”和“夕卡岩”、“辉钼矿”和“硫化钼矿”。我的做法是维护一个同义词表，但只做“单向映射”——把变体映射到标准名，标准名本身不映射。这样避免循环映射导致的混乱。

8.3 表格跨页与合并单元格的修复技巧

表格跨页的修复前面提过，这里补充一个合并单元格的修复技巧。Word和PDF里的合并单元格在解析后往往表现为“左上角有值、其他位置为空”。我的修复方法是：遍历二维数组，如果某个单元格为空，且其上方或左方的单元格有值且跨越了当前行/列，则把值填充过来。判断“跨越”的依据是合并标记（Word的vMerge和hMerge属性，PDF的线条缺失）。

这个修复逻辑用Python实现大概50行代码，但能解决90%的合并单元格问题。剩下的10%是复杂嵌套合并（比如表格里套表格），这种只能人工处理，但出现频率很低。

8.4 常见问题速查表

实操心得：清洗流程一定要做“可回溯”设计。每个chunk都要保留原始文件路径和页码，这样出问题时能快速定位到原文。我试过没保留路径，结果一个错误chunk查了半天不知道从哪来的，最后只能全量重跑。

9. 从清洗到检索的端到端验证

9.1 验证集的设计与标注

清洗效果最终要落到检索质量上。我设计了一个包含200个查询的验证集，覆盖钻孔查询、品位查询、构造查询、储量查询、图件查询五类。每个查询人工标注了期望的chunk ID和答案要点。这个验证集不是一次性的，每次清洗流程有改动都会重新跑一遍，确保没有回归。

验证集的查询设计要贴近真实使用场景。比如“ZK3201在120-180m深度段的Au平均品位是多少”这种查询，需要同时用到钻孔号过滤、深度区间过滤和品位计算。如果清洗时深度数据错位或品位数据丢失，这个查询就会失败。

9.2 检索策略的调优

检索策略我采用的是“元数据过滤+向量检索+重排序”三段式。先用元数据做粗筛（比如钻孔号、矿种），再用向量检索召回Top 50，最后用一个轻量级Cross-Encoder做重排序，取Top 5送给生成模型。这个策略比纯向量检索的准确率提升了约30%。

重排序模型我选的是一个小型的BERT变体，在验证集上微调过。微调数据就是验证集的查询-文档对，正样本是标注的期望chunk，负样本是随机采样的其他chunk。微调后的重排序模型能很好地识别“品位数据”和“厚度数据”的区别，避免把厚度当成品位返回。

9.3 端到端效果评估

端到端评估的指标包括：召回率（期望chunk是否在Top 5中）、准确率（Top 5中相关chunk的比例）、答案正确率（生成答案是否包含期望要点）。经过三轮迭代，我的清洗+检索流程在验证集上的召回率达到92%，准确率达到85%，答案正确率达到88%。这个水平对于探矿业务来说已经可用，但还有提升空间。

主要的失败案例集中在两类：一是图件查询，因为图片本身无法Embedding，只能靠图注文本检索，召回率偏低；二是跨文档查询，比如“对比ZK3201和ZK3202的见矿情况”，需要同时召回两个钻孔的数据并做对比，当前的单文档检索策略支持不够。这两类问题我还在探索解决方案，图件查询考虑用多模态Embedding，跨文档查询考虑用查询分解+多路召回。

10. 一些踩坑后的个人体会

清洗这件事，工具选型只占三成，七成在“对业务的理解”。我一开始用通用方案跑，效果很差，后来花了两周时间跟着地质队员下矿区，看他们怎么读报告、怎么查数据、怎么圈靶区，才真正理解了什么叫做“一个完整的语义单元”。比如地质队员看钻孔数据，从来不是看单行，而是看整个钻孔的品位变化曲线，所以chunk必须包含一个钻孔的完整数据段，而不是按行切。

另一个体会是“不要追求一步到位”。清洗流程一定是迭代出来的，第一版能跑通就行，然后根据检索效果逐步优化。我第一版清洗只做了格式归一化和简单分块，召回率只有60%，但至少能跑起来。然后每周根据失败案例补充规则、调整分块策略，三个月后才达到现在的水平。如果一开始就追求完美，可能永远发不了第一版。

最后说一个具体技巧：清洗日志一定要详细。每个文件的处理过程、每个chunk的切分依据、每个元数据的来源，都要记日志。我用的是一张SQLite表，记录file_path, chunk_id, chunk_type, metadata_json, process_log。出问题时直接查表，比翻代码快得多。这个习惯帮我省了至少几十个小时的排查时间。