1. 探礦數(shù)據(jù)進(jìn)RAG之前為什么必須先過清洗這一關(guān)1.1 探礦領(lǐng)域的文檔生態(tài)比想象中更雜做探礦業(yè)務(wù)的知識庫和做通用知識庫完全是兩碼事。通用場景里的文檔再亂基本也就是網(wǎng)頁、PDF、Word這幾類格式相對規(guī)整。探礦業(yè)務(wù)呢我見過最典型的場景是一個鉆孔編錄報告集里既有上世紀(jì)八十年代的掃描件PDF也有地質(zhì)隊員用老式文本編輯器保存的TXT臺賬還有從OA系統(tǒng)導(dǎo)出的帶修訂痕跡的Word以及從各省地質(zhì)資料網(wǎng)站抓下來的公示文件。這四類東西要同時灌進(jìn)一個RAG知識庫里如果不先把清洗這一步做扎實后面檢索出來的結(jié)果基本沒法看。先說TXT。探礦行業(yè)很多老一輩地質(zhì)工作者留下的原始記錄存的就是純文本。這些TXT文件的問題不是“缺格式”而是編碼混亂。同一批文件中GB2312、GBK、UTF-8、甚至個別BIG5編碼混在一起你用默認(rèn)的UTF-8去讀GBK文件滿屏亂碼向量化之后整個塊就是一堆無意義字符。Word文檔呢問題在“看不見的格式污染”。修訂痕跡、批注、域代碼、目錄域這些內(nèi)容你在屏幕上看見的是正常文字但是一旦用腳本抽取批注和隱藏域內(nèi)容會混進(jìn)來。PDF最麻煩掃描件要OCR文字版要處理雙欄和表格稍微處理不當(dāng)一整段的地層描述就被切得七零八落。網(wǎng)頁倒是相對干凈但導(dǎo)航欄、頁腳、cookie彈窗這些噪聲會稀釋正文的比重導(dǎo)致分塊后語義模糊。這些文檔還有一個共同特征專有名詞密度極高。巖性名稱閃鋅礦、黃鐵礦、矽卡巖地層代號D2、C1、Pt1化驗指標(biāo)單位g/t、ppm、μg/g這些詞匯一旦被錯誤切分或識別檢索效果立刻崩盤。RAG系統(tǒng)檢索的是一段段的語義單元如果語義單元里摻雜著亂碼、殘缺表格、OCR錯字用戶問“某礦區(qū)銅礦體平均品位”系統(tǒng)可能把這段信息錯誤匹配到“某礦區(qū)鉆孔柱狀圖”的無關(guān)片段上。所以在探礦業(yè)務(wù)里清洗不是可選項而是決定RAG能不能落地的關(guān)鍵環(huán)節(jié)。我自己的經(jīng)驗是清洗做到位檢索命中率能提升一個量級清洗不到位后面所有向量化、檢索、重排的努力都會被噪聲淹沒。這篇文章就圍繞探礦業(yè)務(wù)中最常見的四類數(shù)據(jù)——TXT、Word、PDF、網(wǎng)頁——把每一類數(shù)據(jù)的清洗思路和實操方案講透從亂碼處理到結(jié)構(gòu)化恢復(fù)再到檢索精度驗證給你一條可以直接照做的路徑。1.2 臟數(shù)據(jù)進(jìn)了向量庫檢索精度會一路崩到谷底有人可能覺得向量化模型不是對噪聲有魯棒性嗎句子里面有幾個亂碼字符、幾個多余符號向量應(yīng)該還是能抓住語義吧。這個想法在通用語料上也許成立但在探礦數(shù)據(jù)上行不通。原因很簡單探礦文本里的關(guān)鍵信息往往集中在非常短的片段里而且這些片段之間的區(qū)分度不高。舉個例子一份鉆孔巖心編錄表里每行記錄就是一個深度區(qū)間和對應(yīng)的巖性描述。比如“120.5-121.3m 灰白色中?；◢忛W長巖含少量黃鐵礦”。如果把表格轉(zhuǎn)成了文本、格式又亂了變成“120.5-121.3m 灰白色中粒花崗閃長巖含少量黃鐵”或者“120.5-121.3m 灰白色中粒花崗閃長巖含少量黃鐵礦續(xù)”那這塊內(nèi)容的向量就和其他鉆孔的內(nèi)容高度相似用戶真正想查的“黃鐵礦富集層位”就淹沒在一堆相似向量里了。再比如儲量計算報告里的化學(xué)分析結(jié)果表如果表格被拆散、單位被截斷問答系統(tǒng)給出的數(shù)值可能就是錯的。探礦業(yè)務(wù)里一個數(shù)值錯誤可能影響整個礦體圈定結(jié)果的判斷。還有一類問題是數(shù)據(jù)版本。探礦項目的文檔有嚴(yán)格的版本鏈條初勘報告、詳勘報告、補(bǔ)充勘探報告、儲量核實報告每一份都是后續(xù)報告的基礎(chǔ)。如果把不同版本的表格數(shù)據(jù)混在一起灌進(jìn)知識庫RAG在回答“該礦體平均品位是多少”的時候可能同時檢索到初勘和詳勘兩個版本的數(shù)據(jù)系統(tǒng)不知道選哪個只能瞎拼。清洗階段就必須對文檔做版本標(biāo)注或者明確處理優(yōu)先級否則精準(zhǔn)檢索永遠(yuǎn)只是空談。這一章先把問題背景講清楚接下來每一章進(jìn)入具體的數(shù)據(jù)格式清洗路徑。先說最古老也最容易翻車的TXT。2. TXT類數(shù)據(jù)亂碼不是編碼問題那么簡單還有語義碎片2.1 編碼識別與轉(zhuǎn)換先把亂碼一次性解決TXT在探礦業(yè)務(wù)里的典型來源有幾類早期地質(zhì)軟件導(dǎo)出的文本、老同志的手打記錄、從PDF和Word轉(zhuǎn)出來的中間格式、以及各種設(shè)備導(dǎo)出的日志。其中最有時代特色的是老電子文檔存盤年代在1990到2005年之間編碼基本以GB2312和GBK為主少數(shù)來自港臺設(shè)備的文件可能是BIG5。如果你不加處理直接讀十個文件里至少有三四個是亂碼。亂碼的根源就一句話字符集對不上。文件的字節(jié)序列是按GBK編碼寫的你用UTF-8解碼自然全是“錕斤拷”“燙燙燙”這類經(jīng)典亂碼。反過來UTF-8文件被GBK解碼會出現(xiàn)一堆奇奇怪怪的漢字組合。處理思路很清晰先識別編碼再統(tǒng)一轉(zhuǎn)成UTF-8。Python里最常用的工具是chardet可以給出一段字節(jié)的編碼概率估計。import chardet with open(old_report.txt, rb) as f: raw f.read() result chardet.detect(raw) print(result) # 示例輸出{encoding: GB2312, confidence: 0.99}識別出編碼之后轉(zhuǎn)成UTF-8同時處理BOM問題。BOM是藏在文件頭部的幾個特殊字節(jié)有些Windows下的TXT會帶BOM不處理的話寫入文件時會多出一個不可見字符可能在向量化時產(chǎn)生一個異常標(biāo)記位。def normalize_text_file(input_path, output_path): with open(input_path, rb) as f: raw f.read() detected chardet.detect(raw) encoding detected[encoding] if detected[encoding] else utf-8 text raw.decode(encoding, errorsreplace) # 去除BOM字符 text text.lstrip(\ufeff) with open(output_path, w, encodingutf-8) as f: f.write(text)這里有個細(xì)節(jié)errorsreplace會把無法解碼的字節(jié)替換成“”這不是徹底解決辦法。如果文件里亂碼量不大可以接受如果亂碼率超過一定比例比如5%建議人工復(fù)查原始文件很可能文件本身就是損壞的或者被傳輸過程截斷過。編碼轉(zhuǎn)換是TXT清洗的第一步也是最機(jī)械的一步真正有技術(shù)含量的是亂碼消除之后的語義碎片重組。2.2 文本碎片重組讓被切斷的段落重新長回來TXT數(shù)據(jù)的語義碎片問題比亂碼更隱蔽。最常見的情況是原始文件里一個完整段落因為換行符位置錯亂被拆成了好幾行或者從PDF轉(zhuǎn)出來的TXT每一行都被強(qiáng)制切成了固定長度再或者表格轉(zhuǎn)成文本之后單元格內(nèi)的內(nèi)容被割裂成多行列對應(yīng)關(guān)系完全丟失。先看段落重組。地質(zhì)報告有一段描述通常長達(dá)幾百字比如“該礦區(qū)位于XX背斜南翼出露地層主要為二疊系下統(tǒng)棲霞組P1q巖性為灰黑色厚層狀灰?guī)r夾燧石結(jié)核局部見方解石脈充填……”如果這段文字在TXT里被按照屏幕寬度切成了五行那你直接按行分塊就會把一個完整的地層描述拆成五個毫無意義的小塊。正確做法是先做“行合并”如果某一行結(jié)尾沒有句號、感嘆號、問號等結(jié)束標(biāo)點并且下一行不是章節(jié)標(biāo)題就把下一行拼接到當(dāng)前行后面。import re def merge_lines(text): lines text.split(\n) merged [] current end_punct set(。) for line in lines: line line.strip() if not line: if current: merged.append(current) current continue if current and line and not line[0].isupper() and current[-1] not in end_punct: current line else: if current: merged.append(current) current line if current: merged.append(current) return \n.join(merged)這只是基本邏輯實際處理時還要搭配標(biāo)題識別如果某一行是“一、區(qū)域地質(zhì)”“二、礦區(qū)地質(zhì)”這種章節(jié)標(biāo)題即使上一行沒有結(jié)束標(biāo)點也不能接續(xù)到上一段文字里。所以合并行的前提是先做一輪標(biāo)題行標(biāo)記。為了避免一條條寫正則我建議先構(gòu)建一份“探礦業(yè)務(wù)章節(jié)標(biāo)題詞表”把常見章節(jié)名緒言、區(qū)域地質(zhì)背景、礦床地質(zhì)特征、礦石類型及品位、資源儲量估算、探礦工程布置、采樣及化驗方法等整理出來用精確匹配或前綴匹配去識別。這個動作別看簡單它能保住文本的層級結(jié)構(gòu)對后續(xù)RAG的分塊策略非常關(guān)鍵。再一個典型碎片是表格轉(zhuǎn)文本后的列錯位。探礦TXT臺賬里經(jīng)常有這樣的內(nèi)容ZK101 120.5-121.3 灰白色中?；◢忛W長巖 黃鐵礦 2% 1.35g/t ZK101 121.3-122.5 深灰色細(xì)粒閃長巖 磁鐵礦 5% 0.89g/t ZK102 88.2-90.1 灰?guī)r 方解石脈 3% /這種文本如果直接整體入向量庫檢索“ZK101鉆孔黃鐵礦品位”的時候系統(tǒng)可能只能捕捉到這一行的一部分字符更麻煩的是表格列數(shù)不一致時單位與數(shù)值對齊錯位檢索“1.35g/t”可能匹配到別的行。對于這類行結(jié)構(gòu)明顯的文本清洗思路是先把它們從正文里剝離出來按行解析成結(jié)構(gòu)化記錄比如用pandas讀入按空格或制表符分列然后統(tǒng)一編碼單位、加工成CSV或JSON作為獨立數(shù)據(jù)表入庫。正文文本和結(jié)構(gòu)化表格分開走兩條線互不干擾檢索效果反而更好。import pandas as pd rows [] for line in text.split(\n): if re.match(r^ZK\d\s, line): parts re.split(r\s, line.split(//, 1)[0].strip()) rows.append(parts) df pd.DataFrame(rows) df.columns [鉆孔編號, 區(qū)間, 巖石名稱, 礦物, 含量, 品位] df.to_csv(drillholes.csv, indexFalse, encodingutf-8)2.3 正則清理與專有名詞保護(hù)TXT文件的噪聲還有幾類頁眉頁腳殘留比如“XX地質(zhì)大隊 1987年”出現(xiàn)在每一頁頂端、字符上下標(biāo)丟失后的變形比如“m2”其實想寫的是平方米、OCR造成的錯別字如果TXT是從掃描件轉(zhuǎn)的這個很常見、以及多種空白符和分隔符混用。正則清理的要點是“先保護(hù)再清理”。把地質(zhì)專有名詞、地名、樣品編號、鉆孔編號先提取出來占位或加邊界符再執(zhí)行刪除操作避免誤傷。比如你想刪掉含“第 頁”的頁腳但正文里可能有“第X勘探線”這種內(nèi)容不加保護(hù)就一起刪了。我一般用一個地質(zhì)術(shù)語詞典做保護(hù)詞典除了常見的巖性礦物名稱還包括地層代號P1q、T3f、J2x這種格式、化探元素符號Cu、Pb、Zn、Au、Ag、Mo、單位組合g/t、m%、10^-6。正則可以匹配這些模式提前用標(biāo)記符替換清理完后再還原。單位規(guī)范化也是探礦數(shù)據(jù)清洗里的高頻操作。一份文檔可能同時出現(xiàn)“克/噸”“g/t”“0.0001%”三種表達(dá)方式檢索“品位g/t”時命中率肯定會受影響。清洗時建議統(tǒng)一成標(biāo)準(zhǔn)形式。這個操作不復(fù)雜但很值得做因為探礦用戶提問時常常直接說“查一下品位單位g/t的礦體”如果你的庫里面存的是“克/噸”匹配難度就會增加。TXT清洗做到位之后素材里最常見的問題已經(jīng)消滅了一大半。但探礦業(yè)務(wù)里大部分核心報告都不是TXT而是Word。Word文檔的格式污染問題比亂碼更讓人頭疼。3. Word文檔看不見的格式污染比內(nèi)容錯誤更致命3.1 修訂痕跡、批注和域代碼進(jìn)向量庫前必須處理探礦業(yè)務(wù)里Word文檔幾乎繞不開。從儲量核實報告、勘查設(shè)計書到采樣方案、環(huán)境恢復(fù)治理方案全部以Word形式流轉(zhuǎn)。而且這些文件很多經(jīng)過了多輪審核修訂文件里帶著大量修訂痕跡、批注和域代碼。你直接在Word里打開看到的可能是“已接受修訂”的干凈版本但如果你用python-docx或者Apache POI去抽取段落抽取出來的內(nèi)容可能同時包含刪除線文字、批注文字、域代碼的指令內(nèi)容。這里就容易出問題。假設(shè)一份報告里有這么一句被刪除的修訂“該礦體傾向南西傾角40°”審稿人刪掉了“40°”改成“45°”修訂痕跡完整保留了。你用腳本抽取全部段落時如果沒做修訂過濾兩個數(shù)值都會被抽出來向量的語義就自相矛盾了。RAG檢索系統(tǒng)可不認(rèn)識修訂前后的邏輯關(guān)系它只會把這句自相矛盾的話當(dāng)一個完整語義單元。處理方案是抽取段落時過濾掉修訂刪除的內(nèi)容如果需要保留修改后的內(nèi)容優(yōu)先提取修訂接受狀態(tài)下的文本。python-docx處理修訂痕跡比較麻煩它不像瀏覽Word的批注窗格那么直觀需要操作w:ins和w:del等底層XML標(biāo)簽。Apache POI處理Word表格的單元格寬度是強(qiáng)項但對修訂痕跡的處理同樣繞不開XML解析。我的建議是如果是帶修訂痕跡的復(fù)雜Word文檔先用Word桌面版或WPS執(zhí)行“接受全部修訂并保存”再進(jìn)入后續(xù)抽取流程。這一步人為操作一勞永逸比寫腳本解析XML省心得多。批注的處理原則只有一個全部剔除。批注是給審稿人看的交流信息不是報告內(nèi)容的一部分。python-docx提取批注相對容易doc.comments就能拿到的批注內(nèi)容抽取正文時直接跳過。域代碼也同理域代碼的顯示結(jié)果一般是正確的我們要的是顯示文本不是域的指令字段。宏也要注意。部分老式Word文檔帶有宏可能有宏安全風(fēng)險。處理這類文檔時不要用你自己的辦公軟件直接打開并允許宏運行我習(xí)慣用python-docx在只讀模式下抽取或者先轉(zhuǎn)成docx副本再處理。清洗環(huán)節(jié)本身就要規(guī)避執(zhí)行宏安全永遠(yuǎn)是第一位的。3.2 標(biāo)題層級與表格結(jié)構(gòu)提取策略決定分塊質(zhì)量Word清洗里我比較看重的是標(biāo)題層級提取。一份儲量報告動輒幾百頁章節(jié)編號有“第1章”“1.1”“1.1.1”三層甚至還有“附則”“附表”分區(qū)。如果抽取出來做成純文本流水賬后續(xù)不管是按固定長度切塊還是按段落切塊都會切出大量跨章節(jié)碎片。準(zhǔn)確提取標(biāo)題層級讓文檔形成樹狀結(jié)構(gòu)才能保證RAG分塊在“章節(jié)語義完整”的邊界上進(jìn)行。python-docx讀取段落樣式是常規(guī)思路from docx import Document def extract_headings(path): doc Document(path) for p in doc.paragraphs: if p.style.name.startswith(Heading): print(p.style.name, p.text)但實際情況里很多探礦報告的標(biāo)題不是使用“標(biāo)題1”“標(biāo)題2”樣式而是通過手動改字體大小實現(xiàn)的。遇到這種情況python-docx沒法直接告訴你哪段是標(biāo)題只能靠特征判斷居中、加粗、編號開頭如“第1章”“1.1”“一、”。這類規(guī)則容易誤判我的建議是構(gòu)建一個探礦報告章節(jié)編號正則庫用正則匹配“第[一二三四五六七八九十百]章”“[0-9](.[0-9])*”“[一二三四五六七八九十]、”等模式再疊加字體特征雙重校驗。寧可少數(shù)漏判也不要錯判把正文當(dāng)標(biāo)題因為錯判帶來的分塊錯誤是災(zāi)難性的。表格的提取策略更細(xì)。探礦報告里的表格主要有兩類一類是鉆孔一覽表、樣品分析結(jié)果表、資源量估算表這類數(shù)據(jù)型表格需要完整結(jié)構(gòu)另一類是描述性、說明性表格結(jié)構(gòu)相對松散。數(shù)據(jù)型表格我建議提取為結(jié)構(gòu)化數(shù)據(jù)再入庫和TXT臺賬走同一條路。處理Word表格時Apache POI的setColumnWidth這類寬度控制用得很多但清洗場景我們更關(guān)心內(nèi)容抽取。python-docx可以直接讀取doc.tables遍歷每個表格的rows和cells輸出CSV。需要注意跨頁表格問題。長表格在Word里經(jīng)?？珥撚械谋砀駮鸱殖啥鄠€物理Table或者表頭重復(fù)出現(xiàn)。抽取時要判斷相鄰表格是否可能是同一張表依據(jù)是表頭是否重復(fù)、列數(shù)是否一致。如果有圖表編號“表4-1 鉆孔巖心采樣分析結(jié)果”直接用編號把跨頁片段串起來。這一步如果漏了一張完整的鉆孔化學(xué)成分表會被拆成好幾塊檢索“表4-1 中ZK103的Au品位”時只命中其中一塊數(shù)值不完整。3.3 公式、圖表與版本混亂探礦報告里的公式主要是儲量計算相關(guān)比如塊段法儲量計算公式、體積公式、加權(quán)平均品位公式。Word里的公式可能是MathType或OMML格式清洗時有兩種處理路徑簡單場景把公式的文本描述抽出來比如“Q V × d式中Q為礦石量V為體積d為礦石體重”復(fù)雜場景建議將公式從Word里導(dǎo)出為圖片再把公式的LaTeX或文本描述作為相鄰文本補(bǔ)充。熱詞里有“Word公式轉(zhuǎn)LaTeX”探礦報告里的公式普遍不難轉(zhuǎn)成LaTeX或文本描述完全夠用不需要保留圖片做識別這一步能大幅降低向量化的噪聲。注意MathType和OMML的解析工具不完全一樣MathType對象是OLE嵌對象python-docx直接讀變量內(nèi)容可能不夠需要單獨處理。圖表更簡單也更重要圖片本身不進(jìn)入RAG文本鏈路但圖片的標(biāo)題、圖例說明必須保留。很多勘探圖件的說明文字里包含了巖性、構(gòu)造、礦體形態(tài)特征是檢索的高價值信息。清洗時把圖表標(biāo)題“圖2-3 XX礦區(qū)地質(zhì)簡圖”和緊隨其后的圖例說明作為獨立段落提取歸入對應(yīng)章節(jié)的上下文。版本混亂是Word清洗的最后一道坎。同一份儲量報告可能同時存在“儲量報告(最終版).docx”“儲量報告(終版).docx”“儲量報告(再也不改版).docx”內(nèi)容可能還各不相同。清洗入庫前必須先做版本核對比對目錄、頁數(shù)、修改時間保留內(nèi)容最新且完整的那一版如果拿不準(zhǔn)寧缺毋濫不要多個版本都進(jìn)庫。RAG最怕的就是一個知識點有多個版本互相打架。說完Word最重的戲來了PDF。探礦業(yè)務(wù)的老檔案基本都是PDF而且什么形態(tài)都有。4. PDF的三種形態(tài)掃描件、原生文本、表格混排的處理差異4.1 文字版PDF抽取順序與布局還原的坑先分清PDF的類型類型不同處理路徑完全不同。我見過太多人拿到一個PDF就直接跑OCR結(jié)果一個文字版PDF還被OCR出大量錯字得不償失。判斷是否文字版很簡單用工具直接抽取看看有沒有文本層。PyMuPDFfitz是一個我長期在用的庫速度快抽取質(zhì)量高。import fitz doc fitz.open(勘探報告.pdf) for page_num in range(len(doc)): page doc[page_num] text page.get_text(text, sortTrue) print(text)文字版PDF的麻煩不在于抽不出來而在于抽取順序。雙欄排版的地質(zhì)報告很常見左欄是正文右欄是表格或圖件說明有些報告還有頁眉頁腳。用get_text(text)抽取時默認(rèn)按文檔內(nèi)部結(jié)構(gòu)順序輸出經(jīng)常出現(xiàn)“左欄半段、右欄半段、再回左欄下半段”這種跳讀順序。處理方式是先用get_text(blocks)拿到塊的位置坐標(biāo)然后按橫坐標(biāo)排序區(qū)分欄位再按縱坐標(biāo)合并。def extract_sorted_text(page): blocks page.get_text(blocks) # block結(jié)構(gòu)(x0, y0, x1, y1, text, block_no, block_type) blocks.sort(keylambda b: (round(b[1] / 20), b[0])) lines [] for b in blocks: lines.append(b[4].strip()) return \n.join(lines)這個按y分粗組再按x排序的操作本質(zhì)上是把同一水平線上的塊按從左到右排列跨欄順序就不會亂了。實際效果因文檔而異需要抽樣驗證。文字版PDF的表格抽取可以交給pdfplumber它能識別線條并還原表格結(jié)構(gòu)import pdfplumber with pdfplumber.open(礦產(chǎn)儲量報告.pdf) as pdf: for page in pdf.pages: tables page.extract_tables() for table in tables: for row in table: print(row)pdfplumber對有線表格識別效果好對無線邊框的表格很多化學(xué)分析表只是空格對齊識別一般。無線表格我傾向于退回到按坐標(biāo)抽文本再拿正則去切分雖然慢但可控。還有一類坑是頁眉頁腳貫穿文本層。比如“XX礦區(qū)勘查報告 - 第 23 頁”這一串字符會出現(xiàn)在每一頁的文本抽取結(jié)果里如果不去掉整份文檔里同一個頁眉會重復(fù)出現(xiàn)幾十次RAG在檢索“XX礦區(qū)”的時候可能被這個高頻短語帶偏。清洗時先用正則匹配頁眉頁腳的固定模式刪掉再逐頁拼接正文。4.2 掃描件PDFOCR流程與詞典校準(zhǔn)掃描件PDF在探礦領(lǐng)域極其常見特別是上世紀(jì)的地質(zhì)報告、老圖紙、巖心照片掃描版。這些文件沒有文本層只能OCR。OCR的選擇很多Python生態(tài)里PaddleOCR和Tesseract是比較實用的兩個。個人經(jīng)驗中英文混排、含大量表格的地質(zhì)報告PaddleOCR識別率更好純英文文獻(xiàn)或字符規(guī)整的頁面Tesseract也夠用。兩個配合著用按文檔類型分流。paddleocr --image_dir page_001.png --lang ch --use_gpu False --output_dir ./ocr_resultOCR本身的流程不多說重點在校準(zhǔn)和后處理。地質(zhì)文本里有很多普通OCR模型容易出錯的詞包括巖性名稱“閃長玢巖”容易被識別成“閃長粉巖”、元素符號“Ag”識別成“Aq”、“Au”識別成“A”、地層代號“P1q”識別成“P1g”以及單位“g/t”識別成“g/I”。針對這個問題我的做法是準(zhǔn)備兩份詞典地質(zhì)專有名詞詞典從術(shù)語標(biāo)準(zhǔn)、勘探規(guī)范里提取核心詞條。OCR常見混淆詞典記錄模型容易出錯的字符對比如0/O、1/l/I、2/Z、6/G、8/B、g/9/q等以及“黃鐵”被識別成“黃錢”這類整詞錯誤。后處理時先跑一遍OCR得到原始文本再對文本里出現(xiàn)的候選詞做詞典匹配替換。替換邏輯要小心不要整篇文章無差別替換只處理高置信度的混淆詞。舉例corrections { 閃長粉巖: 閃長玢巖, 黃錢礦: 黃鐵礦, Aq: Ag, } for wrong, right in corrections.items(): text text.replace(wrong, right)還有一個非常實用的小技巧OCR前先做圖像預(yù)處理。老掃描件經(jīng)常有傾斜、暗角的毛病用OpenCV做一次二值化和傾斜校正識別率能提升一大截。傾斜頁面里的表格線會變成折線影響表格識別校正角度一般在10度以內(nèi)校正效果較好。掃描件里的表格識別屬于高難操作。如果表格區(qū)域是完整的矩形線條框PaddleOCR的表格結(jié)構(gòu)識別模型TableRec可以輸出HTML結(jié)構(gòu)再轉(zhuǎn)成CSV如果是手繪表格或者表格線模糊人工勾選區(qū)域反而更快。探礦業(yè)務(wù)的掃描件表格價值很高像老的地質(zhì)剖面表、鉆孔柱狀圖的數(shù)據(jù)表值得花人工做幾份高質(zhì)量的構(gòu)建一個結(jié)構(gòu)化樣本再反哺自動化腳本。OCR輸出的表格結(jié)構(gòu)完整性決定后續(xù)數(shù)值檢索的精讀質(zhì)量這個錢和時間不該省。4.3 混排表格PDF結(jié)構(gòu)化提取與回填大量勘探報告屬于第三類文字版PDF里嵌著表格、圖件、甚至部分掃描插入頁。處理這種混排文檔不能單一用文字抽取或單一用OCR而是要把頁面拆開處理。我通常的做法是先用PyMuPDF檢測每一頁的文本覆蓋率。如果某頁文本量極低、但包含圖像判定為掃描頁或圖件頁進(jìn)入OCR鏈路如果文本量正常但存在大塊跨欄圖片則保留文本層只對圖片做區(qū)域識別針對圖件中的標(biāo)注文字。表格用pdfplumber識別再和文本抽取結(jié)果做拼接。輸出格式上強(qiáng)烈建議把清洗后的文檔轉(zhuǎn)成帶層級標(biāo)記的Markdown而不是純文本。好處在于后續(xù)RAG分塊時可以直接按Markdown標(biāo)題層級來做邊界劃分即使用固定窗口切割也能感知當(dāng)前的章節(jié)歸屬。示例## 2.3 礦區(qū)地質(zhì)特征 該礦區(qū)出露地層主要為二疊系下統(tǒng)棲霞組P1q巖性為灰黑色厚層狀灰?guī)r夾燧石結(jié)核局部見方解石脈充填。 表2-1 主要巖石化學(xué)成分分析結(jié)果 | 樣品編號 | SiO2(%) | Al2O3(%) | Fe2O3(%) | |------|------|------|------| | H-01 | 63.25 | 15.42 | 4.81 |PDF清洗到這個程度才能說具備了進(jìn)RAG的基本素質(zhì)。但這還只是單一文件層面的清洗網(wǎng)頁數(shù)據(jù)這一類體量不大但格式問題突出的數(shù)據(jù)源也需要單獨處理。5. 網(wǎng)頁抓取正文提取、去廣告與結(jié)構(gòu)化編號保留5.1 從導(dǎo)航頁到正文抓取流程與噪點過濾探礦業(yè)務(wù)里需要抓取的網(wǎng)頁數(shù)據(jù)通常有幾類地質(zhì)資料館的公開目錄頁、招標(biāo)公告、行業(yè)標(biāo)準(zhǔn)的在線版本、政府公示的勘查許可證信息、以及相關(guān)新聞動態(tài)。網(wǎng)頁數(shù)據(jù)的特點是不需要做編碼轉(zhuǎn)換基本都是UTF-8但頁面結(jié)構(gòu)噪聲非常多頂部導(dǎo)航、側(cè)欄推薦、頁腳版權(quán)、Cookie彈窗、相關(guān)鏈接推薦都會混進(jìn)正文抽取結(jié)果。直接用requests加BeautifulSoup硬解析是最容易踩坑的方式。每次改版、每個網(wǎng)站結(jié)構(gòu)不同解析規(guī)則就要跟著改。我的經(jīng)驗是優(yōu)先用專門針對正文提取的工具比如trafilatura或readability-lxml它們會自動識別正文區(qū)域去除導(dǎo)航和頁腳輸出干凈文本。trafilatura還能保留標(biāo)題層級和段落結(jié)構(gòu)對RAG友好。import trafilatura downloaded trafilatura.fetch_url(https://example.com/notice/12345) text trafilatura.extract(downloaded, include_commentsFalse, include_tablesTrue, output_formatmarkdown) print(text)動態(tài)渲染頁面是另一類難題。很多地質(zhì)公告頁面用JavaScript渲染內(nèi)容直接抓HTML可能拿不到正文。這種頁面需要先渲染再提取可以在本地起一個Playwright或Selenium腳本等頁面加載完再執(zhí)行trafilatura的抽取邏輯。注意渲染會顯著增加抓取成本只對確實需要的頁面走這條通路不要把整站都動態(tài)渲染。網(wǎng)頁正文抽取完成之后還要做一輪針對網(wǎng)頁噪聲的清洗去掉“收藏”“打印”“字號”“責(zé)任編輯”這類的功能性文字去重同一公告可能在不同欄目重復(fù)發(fā)布把常見無信息量的段落“關(guān)于我們”“聯(lián)系我們”從正文里剔除。清洗后的網(wǎng)頁文本同樣統(tǒng)一轉(zhuǎn)成Markdown保留標(biāo)題層級。5.2 法規(guī)與公告的編號結(jié)構(gòu)只能在清洗時保住探礦業(yè)務(wù)里有一類非常重要的網(wǎng)頁文本是法規(guī)、標(biāo)準(zhǔn)和公告。這些文本的結(jié)構(gòu)化程度很高有編號如“第XX號令”、有條文序號第X條、有章節(jié)結(jié)構(gòu)第一章總則、第二章勘查許可還會引用其他法規(guī)條款。如果清洗時把這些編號全抹掉RAG在回答“關(guān)于探礦權(quán)延續(xù)登記的具體規(guī)定在第幾條”這類問題時就完全沒有引用依據(jù)。所以清洗策略和普通文本不同條文編號必須保留而且要作為結(jié)構(gòu)錨點。我建議把法規(guī)網(wǎng)頁轉(zhuǎn)換為結(jié)構(gòu)化度更高的格式——每一“條”作為一個語義單元前面加編號標(biāo)記。## 第三章 探礦權(quán)轉(zhuǎn)讓 第二十四條 探礦權(quán)轉(zhuǎn)讓應(yīng)當(dāng)符合下列條件 一持有探礦權(quán)滿2年 二已繳納探礦權(quán)使用費 三完成了規(guī)定的最低勘查投入 ……這里的一二三子項也要保留很多檢索場景是用戶問“探礦權(quán)轉(zhuǎn)讓需要滿足什么條件”子項的完整性直接決定回答質(zhì)量。網(wǎng)頁抓取時還經(jīng)常遇到一個問題頁面正文和上下文的關(guān)聯(lián)信息丟失。比如一份公告說“依據(jù)××規(guī)定第九條”但前文對××規(guī)定的完整引用可能在另一個頁面。清洗時要考慮跨頁面合并把同一政策不同頁面的內(nèi)容拼成一份完整文檔這樣后續(xù)RAG不會在回答中引用一個“看情況再說”的懸空條款。5.3 時效性與鏈接去重網(wǎng)頁數(shù)據(jù)的時效性比TXT、Word、PDF都要強(qiáng)。地質(zhì)公告有發(fā)布期限勘查許可證有有效期行業(yè)標(biāo)準(zhǔn)有廢止和替代關(guān)系。清洗入庫時一定要增加兩個字段發(fā)布時間和時效狀態(tài)。發(fā)布時間可以直接從頁面正文或數(shù)據(jù)字段里提取時效狀態(tài)則需要判斷比如頁面標(biāo)注“已廢止”“已失效”“自2023年5月1日起施行”清洗時要自動識別并標(biāo)記。時效狀態(tài)的判斷在RAG鏈路里特別重要。用戶提問“現(xiàn)在還需要提交××材料嗎”如果庫里的依據(jù)是已廢止的文件系統(tǒng)會理直氣壯地給出一個過時答案。所以清洗時不但要保留時效字段還要把它和分塊內(nèi)容綁定或者在文本頭部加一行的概述比如“注意本文件已于2024年1月廢止”。這樣即使被切分到的塊也能讓模型感知到狀態(tài)信息。鏈接去重也別忽略。同一份公告可能同時存在于“通知公告”和“政策法規(guī)”兩個欄目頁面URL不同但正文完全一致。清洗時用正文的哈希值做去重保留來源可靠、發(fā)布時間最早或最新的一份。數(shù)據(jù)量大的時候還可以用MinHash或局部敏感哈希做近似去重處理那些只有細(xì)微差別的頁面。網(wǎng)頁清洗相對于文檔清洗來說工程量不大但容易讓人掉以輕心——往往是抓了幾千個頁面正文里混著導(dǎo)航詞和頁腳詞灌進(jìn)去之后一搜全是不相關(guān)內(nèi)容。到這里四類數(shù)據(jù)的清洗路徑都說完了。但清洗完不等于能上線你還需要驗證清洗效果否則可能帶著問題上線而不自知。6. 清洗效果怎么驗證從召回率到答案準(zhǔn)確率6.1 規(guī)則閥門機(jī)器自查的硬指標(biāo)清洗完一批文檔第一件事不是急著向量化而是跑一輪規(guī)則閥門。規(guī)則閥門是一組輕量腳本檢查清洗后文本是否還殘留典型的臟數(shù)據(jù)模式。我的檢查項包括亂碼殘留率文本里是否還出現(xiàn)“錕斤拷”“”和異常Unicode字符?？招斜壤逑春笪臋n是否還有大量連續(xù)空行。段落平均長度如果一段話少于15個字符多半是頁眉頁腳或表格碎片殘留。重復(fù)率相鄰段落是否存在重復(fù)文本比如頁眉重復(fù)。結(jié)構(gòu)完整率一個文檔應(yīng)該有多少章標(biāo)題實際識別到多少。編碼一致性清洗后文檔是否統(tǒng)一為UTF-8無BOM。這些檢查項可以用腳本批量跑生成一份報告。報告里把不合格的文件挑出來重新處理。規(guī)則閥門的意義在于把清洗從“手工作坊”變成“可度量流程”每一步都能知道丟了多少數(shù)據(jù)。6.2 檢索鏈路驗證用真實業(yè)務(wù)問題集打分規(guī)則閥門解決的是“清潔度”問題但清潔度高不等于檢索精度高。要驗證清洗是否真正提升了RAG效果還需要一組真實業(yè)務(wù)問題作為評測集。探礦業(yè)務(wù)問題集我一般分三類來構(gòu)造術(shù)語實體類比如“閃鋅礦的賦存層位是什么”“礦區(qū)出露的地層有哪些”.這類問題考察專有名詞和實體的召回能力。數(shù)值檢索類比如“ZK103鉆孔在120米處的巖性是什么”“銅礦體平均品位是多少”。這類問題考察表格抽取和結(jié)構(gòu)還原效果。規(guī)范引用類比如“申請?zhí)降V權(quán)延續(xù)登記需要提交哪些材料”。這類問題考察條文編號和章節(jié)結(jié)構(gòu)的保留情況。構(gòu)造好問題集之后跑一遍RAG鏈路對每個問題檢查兩個指標(biāo)top-K命中率正確答案是否在檢索返回的前幾塊里和最終答案準(zhǔn)確率基于檢索結(jié)果的生成回答是否可接受。我還要強(qiáng)調(diào)一個非常容易被忽視的細(xì)節(jié)檢索命中率比生成答案準(zhǔn)確率更能反映清洗效果。生成答案可以靠模型“腦補(bǔ)”蒙對但檢索命中率直接反映清洗質(zhì)量——相關(guān)資料沒有被搜到就是向量化之前的清洗沒做好。實操中清洗前和清洗后的對比結(jié)果非常直觀。我之前處理過一批老的地下巖心編錄掃描件PDF清洗前問“礦區(qū)矽卡巖的分布范圍”檢索返回的是OCR錯字“砂卡巖”的亂文本塊回答完全不可用清洗后同一個問題檢索返回了目標(biāo)段落的準(zhǔn)確上下文答案可以直接采納。這就是為什么要花時間在清洗上——它直接影響數(shù)據(jù)進(jìn)庫后的可用性。6.3 分塊與清洗的配合光清洗不夠還要切得對清洗產(chǎn)出的是干凈的Markdown文本下一步是分塊。分塊策略的選擇要和清洗方式強(qiáng)配合。如果清洗時保留了標(biāo)題層級分塊邊界就能按章節(jié)語義劃分一個標(biāo)題下設(shè)一個塊塊的內(nèi)容是這個標(biāo)題下的完整段落集。塊過大超過1000字符會稀釋語義塊過小少于100字符會丟失上下文。探礦報告里一塊200到800字符之間通常效果較好但具體要根據(jù)文檔類型調(diào)整鉆孔編錄短小精悍可以分小塊儲量報告章節(jié)豐富適合用章節(jié)邊界劃分。分塊時還要考慮重疊overlap策略。清洗后的文檔本身段落間有強(qiáng)邏輯關(guān)系如果分塊完全無重疊跨段落的問答比如“根據(jù)上一段內(nèi)容這個礦體的平均品位如何”會丟失信息。適當(dāng)設(shè)置20-50字符的重疊可以緩解這個問題。分塊完成后需要對每個塊再抽檢一遍看是否出現(xiàn)跨表格、跨章節(jié)的內(nèi)容拼接。出現(xiàn)這種情況優(yōu)先調(diào)整分塊邊界而不是硬調(diào)向量化參數(shù)。很多人在RAG精度不足時第一反應(yīng)是換更好的向量模型但模型換完了效果依然一般問題往往就出在清洗和分塊環(huán)節(jié)。驗證通過之后可以進(jìn)入實際使用階段。但探礦數(shù)據(jù)的清洗不是一次性的庫會增長文檔會更新清洗規(guī)則也要跟著迭代。這些是落地時的經(jīng)驗問題最后單獨說。7. 落地過程中的真實體會與建議7.1 先建清洗流水線再談知識庫探礦業(yè)務(wù)的數(shù)據(jù)清洗千萬不要做成一次性的“大掃除”。真實情況是每隔一段時間就會有一批新文檔進(jìn)來比如新完成的勘查報告、新公示的出讓公告、新修訂的規(guī)范。如果每次都重新跑一遍手工腳本效率太低且容易漏步驟。我強(qiáng)烈建議把清洗流程腳本化、流水線化第一步文件格式識別分發(fā)到對應(yīng)清洗模塊。第二步各模塊執(zhí)行格式清洗輸出標(biāo)準(zhǔn)Markdown和結(jié)構(gòu)化CSV。第三步規(guī)則閥門自動質(zhì)檢。第四步人工抽檢通過后進(jìn)入向量化入庫。流水線的價值不只是節(jié)省人力更在于清洗規(guī)則可以版本化管理。每次發(fā)現(xiàn)一個之前沒覆蓋的亂碼模式或OCR錯詞就更新規(guī)則庫流水線重跑一遍歷史數(shù)據(jù)也不會遺漏。這個機(jī)制讓清洗質(zhì)量持續(xù)進(jìn)化而不是做完一次就停滯。7.2 清洗規(guī)則與詞典要持續(xù)更新沒有哪個體量足夠的探礦數(shù)據(jù)能靠一次性正則清干凈。每個礦區(qū)的文檔都有自己的行文習(xí)慣每個時期的地質(zhì)報告也有不同的格式偏好。比如有些老報告用“品位1.35克/噸”新報告用“品位1.35g/t”你需要不斷把這類變體納入規(guī)范化詞典。地質(zhì)專有名詞詞典同樣如此不同礦種有新術(shù)語比如隨著稀有金屬勘探的展開鋰輝石、花崗偉晶巖這類詞匯會頻繁出現(xiàn)詞典里沒有就容易被OCR或分塊環(huán)節(jié)誤處理。我維護(hù)的詞典是一個單獨的文本文件每個詞條一行里面不僅有標(biāo)準(zhǔn)術(shù)語還有常見的錯誤拼寫映射。更新流程很簡單在質(zhì)檢階段發(fā)現(xiàn)某個詞頻繁出問題就追加到詞典。方法論不重要重要的是堅持記錄。7.3 人工抽檢由業(yè)務(wù)人員來做開發(fā)人員只做兜底清洗腳本質(zhì)檢能抓住大部分機(jī)器可識別的問題但有一些錯漏是腳本發(fā)現(xiàn)不了的。比如OCR把“矽卡巖型銅礦床”識別成了“砂卡巖型銅礦床”單獨看這個詞似乎沒什么問題但在地質(zhì)語境里“矽卡巖”才是標(biāo)準(zhǔn)寫法。這種問題規(guī)則閥門很可能判斷“合格”但業(yè)務(wù)人員一眼就能看出來。所以清洗流程的最后一道質(zhì)檢必須由業(yè)務(wù)人員參與。抽檢比例不用太高每批抽30%到50%就夠了。更有效的做法是讓地質(zhì)工程師直接試用檢索系統(tǒng)發(fā)現(xiàn)檢索結(jié)果里出現(xiàn)怪異詞匯或錯誤術(shù)語反饋回來再去修正清洗規(guī)則。這樣形成一個閉環(huán)——清洗、入庫、檢索測試、反饋、再清洗比一次性追求極致的清洗質(zhì)量更現(xiàn)實。7.4 寧缺毋濫讓合格的數(shù)據(jù)進(jìn)庫最后一條經(jīng)驗也是我踩過最多坑之后總結(jié)出來的清洗環(huán)節(jié)一定要敢做減法。一個PDF掃描件OCR之后文本質(zhì)量實在不行與其硬著頭皮入庫不如標(biāo)記為“待人工處理”暫時不參與檢索。RAG的精度取決于最高質(zhì)量的上下文一條臟數(shù)據(jù)有可能會把正確答案的排序擠下去。寧可庫里少幾份文檔也比讓臟數(shù)據(jù)污染答案強(qiáng)。文件級別的質(zhì)量閾值也要設(shè)置清楚。我的經(jīng)驗是OCR錯字率超過5%的文檔或者表格結(jié)構(gòu)完全無法還原的文檔先掛起等人工處理或找替代來源。很多老報告網(wǎng)上有二次整理的Word版或重新錄入版質(zhì)量比直接OCR高得多優(yōu)先用高質(zhì)量來源。7.5 一個實用的小技巧優(yōu)先清洗高頻、高價值文檔如果你手頭的文檔數(shù)量特別大比如幾千份而人力資源有限不要平均用力。把所有文檔按使用頻率和價值分兩級高頻高價值文檔——儲量報告、采樣分析數(shù)據(jù)、勘探規(guī)范、招拍掛公告——優(yōu)先清洗建立嚴(yán)格的質(zhì)量標(biāo)準(zhǔn)長尾文檔——行業(yè)新聞、歷史動態(tài)、周邊資訊——可以放寬閾值用一條簡單流水線批量處理。先讓核心數(shù)據(jù)保證高精度再逐步擴(kuò)大清洗范圍。我見過太多項目一上來就追求“把全部數(shù)據(jù)洗得干干凈凈再上線”結(jié)果洗到一半失去了耐心反而拖垮了整個落地節(jié)奏。正確的路子是小步快跑核心優(yōu)先。探礦業(yè)務(wù)的RAG清洗本質(zhì)上是在做一件很枯燥但價值極高的事把歷史數(shù)據(jù)從“能看”提升到“能查、能答、能引用”。從TXT的亂碼與碎片重組到Word的格式污染清理再到PDF的OCR校準(zhǔn)與表格結(jié)構(gòu)化最后是網(wǎng)頁的正文抽取和時序標(biāo)記每一類數(shù)據(jù)都有自己的方法論。清洗完再用問題集驗證檢索效果形成閉環(huán)。這套流程跑通之后你手里的知識庫才真正具備高精度檢索的底子。我也還在不斷迭代自己這套清洗規(guī)則每次處理新批次的數(shù)據(jù)都能發(fā)現(xiàn)一些沒見過的臟數(shù)據(jù)形態(tài)。這個過程沒有終點但每一步的改進(jìn)都在實打?qū)嵉靥嵘卮鹳|(zhì)量這就是做這件事最有價值的地方。