1. 探礦資料為什么必須做RAG清洗地質(zhì)勘探行業(yè)有一個很尷尬的現(xiàn)實(shí)數(shù)據(jù)量極大但真正能被檢索和復(fù)用的比例極低。一個中型勘探項(xiàng)目跑下來積累的資料包括野外記錄本掃描件、鉆孔柱狀圖PDF、化驗(yàn)報(bào)告Word文檔、老專家手寫的TXT臺賬、以及從不同渠道下載的網(wǎng)頁資料。這些文件散落在各個硬盤和共享目錄里格式五花八門命名毫無規(guī)律。你想查一個“某鉆孔在特定深度的巖性描述”只能靠人肉翻文件夾運(yùn)氣好十分鐘找到運(yùn)氣不好半天都翻不出來。RAG檢索增強(qiáng)生成看起來是解決這個問題的理想方案——把資料灌進(jìn)知識庫用自然語言提問系統(tǒng)自動檢索相關(guān)段落并生成回答。但真正動手做過的人都知道RAG的效果上限不取決于大模型有多強(qiáng)而取決于你喂進(jìn)去的數(shù)據(jù)有多干凈。垃圾進(jìn)垃圾出這句話在RAG場景下體現(xiàn)得淋漓盡致。探礦業(yè)務(wù)的特殊性在于資料格式跨度極大從純文本TXT到復(fù)雜排版的PDF從結(jié)構(gòu)化表格到自由書寫的Word報(bào)告還有大量從網(wǎng)頁復(fù)制粘貼的碎片信息。每種格式的清洗策略完全不同用一套通用流程去處理結(jié)果就是檢索時要么召回一堆無關(guān)內(nèi)容要么關(guān)鍵信息被切得支離破碎。我見過太多團(tuán)隊(duì)花大價(jià)錢搭了RAG框架最后因?yàn)閿?shù)據(jù)清洗沒做好檢索精度慘不忍睹項(xiàng)目不了了之。這篇文章面向的是正在或準(zhǔn)備在探礦業(yè)務(wù)中落地RAG的技術(shù)人員和地質(zhì)信息化從業(yè)者。我會把TXT、Word、PDF、網(wǎng)頁四種格式的清洗方法拆開講透包括每種格式的坑在哪里、怎么處理、為什么這樣處理。所有內(nèi)容基于實(shí)際項(xiàng)目經(jīng)驗(yàn)不是理論推演。2. 四種格式的清洗難度分級與核心挑戰(zhàn)在動手寫清洗代碼之前先要搞清楚每種格式到底難在哪里。我把探礦業(yè)務(wù)中常見的四種格式按清洗難度做了分級這個分級直接決定了你該投入多少精力。格式清洗難度核心挑戰(zhàn)典型問題TXT低編碼混亂、無結(jié)構(gòu)GBK與UTF-8混用、字段分隔符不統(tǒng)一Word中格式嵌套、公式圖表表格跨頁、公式對象無法直接提取PDF高版面還原、掃描件雙欄排版錯亂、OCR噪聲、表格線干擾網(wǎng)頁中高噪聲過濾、動態(tài)內(nèi)容導(dǎo)航欄廣告混入、JavaScript渲染缺失TXT看起來最簡單但探礦行業(yè)的TXT往往來自不同年代、不同軟件導(dǎo)出編碼問題能讓你抓狂。我遇到過一批2005年左右的地質(zhì)臺賬同一批文件里GBK、GB2312、UTF-8三種編碼混著來直接讀取全是亂碼。Word的問題在于“看起來是文本實(shí)際是對象”——公式是OLE對象、圖表是嵌入圖片、表格有合并單元格直接轉(zhuǎn)文本會丟失大量結(jié)構(gòu)信息。PDF是公認(rèn)最難啃的骨頭尤其是掃描版的老資料OCR識別出來的內(nèi)容需要大量后處理。網(wǎng)頁資料的問題則是噪聲太多導(dǎo)航欄、廣告、評論區(qū)全混在正文里。提示不要試圖用一種工具或一套正則規(guī)則處理所有格式。每種格式的清洗管線應(yīng)該獨(dú)立設(shè)計(jì)最后再統(tǒng)一輸出為RAG可消費(fèi)的標(biāo)準(zhǔn)化格式。3. TXT文件從編碼地獄到結(jié)構(gòu)化字段3.1 編碼檢測與批量轉(zhuǎn)碼的實(shí)操方案TXT清洗的第一步永遠(yuǎn)是編碼檢測。Python的chardet庫可以自動檢測編碼但它的準(zhǔn)確率在短文本上并不理想。我的做法是先用chardet做初步判斷然后對置信度低于0.8的文件用iconv嘗試多種編碼轉(zhuǎn)換看哪種能輸出可讀的中文。import chardet def detect_encoding(file_path): with open(file_path, rb) as f: raw f.read(10000) # 讀前10KB做檢測 result chardet.detect(raw) encoding result[encoding] confidence result[confidence] # 置信度低時嘗試常見中文編碼 if confidence 0.8: for enc in [utf-8, gbk, gb2312, gb18030]: try: raw.decode(enc) return enc, 1.0 except UnicodeDecodeError: continue return encoding, confidence批量轉(zhuǎn)碼時有一個關(guān)鍵決策統(tǒng)一轉(zhuǎn)成UTF-8還是保留原編碼我的建議是統(tǒng)一轉(zhuǎn)UTF-8因?yàn)楹罄m(xù)的RAG框架、向量數(shù)據(jù)庫、大模型接口基本都默認(rèn)UTF-8。轉(zhuǎn)碼過程中要記錄原始編碼萬一出現(xiàn)亂碼可以回溯。實(shí)際操作中還有一個坑有些TXT文件是“混合編碼”前半部分GBK后半部分UTF-8。這種情況chardet會給出一個折中結(jié)果導(dǎo)致兩邊都亂。處理方法是按行讀取逐行檢測編碼分別解碼后再拼接。雖然慢但能保證正確率。3.2 探礦臺賬的字段切分與語義保留編碼問題解決后下一個問題是結(jié)構(gòu)。探礦TXT臺賬通常長這樣ZK001 0-5m 第四系覆蓋層 黃色黏土 松散 ZK001 5-12m 強(qiáng)風(fēng)化花崗巖 灰白色 巖芯采取率75% ZK001 12-25m 中風(fēng)化花崗巖 青灰色 巖芯采取率90% 見石英脈這種數(shù)據(jù)如果直接整段塞進(jìn)RAG檢索“ZK001的巖芯采取率”時模型可能只召回其中一行丟失上下文。更好的做法是按鉆孔編號和深度區(qū)間做結(jié)構(gòu)化切分把每行轉(zhuǎn)成JSON對象{ hole_id: ZK001, depth_from: 0, depth_to: 5, layer: 第四系覆蓋層, description: 黃色黏土 松散, extra: {} }這樣切分的好處是檢索時可以精確匹配鉆孔編號和深度范圍生成回答時也能保留完整的層位信息。切分規(guī)則用正則就能搞定關(guān)鍵是字段分隔符要統(tǒng)一。我見過有的臺賬用空格、有的用制表符、有的用豎線清洗時需要先做分隔符歸一化。注意結(jié)構(gòu)化切分不是越細(xì)越好。如果切得太碎檢索時可能只召回“巖芯采取率75%”這一句丟失了“ZK001 5-12m 強(qiáng)風(fēng)化花崗巖”這個關(guān)鍵上下文。我的經(jīng)驗(yàn)是以“一個完整的地質(zhì)描述單元”為最小切分粒度通常是一行或一個自然段。4. Word文檔表格、公式與嵌入對象的處理策略4.1 表格跨頁與合并單元格的還原Word文檔在探礦業(yè)務(wù)中主要用于化驗(yàn)報(bào)告、項(xiàng)目總結(jié)、鉆孔設(shè)計(jì)書。這些文檔里最要命的是表格——化驗(yàn)報(bào)告的結(jié)果表往往跨頁表頭在第一頁數(shù)據(jù)延續(xù)到第三頁鉆孔設(shè)計(jì)書里的地層表有大量合并單元格。用python-docx讀取表格時跨頁表格會被識別為多個獨(dú)立的Table對象合并單元格則會出現(xiàn)空值。處理方法是先按表格的列數(shù)做分組列數(shù)相同的連續(xù)Table視為同一個邏輯表格然后合并。合并單元格的空值需要用“向上填充”策略處理——如果某單元格為空取同列上一行的值。from docx import Document def extract_tables(doc_path): doc Document(doc_path) tables [] for table in doc.tables: rows [] for row in table.rows: cells [cell.text.strip() for cell in row.cells] rows.append(cells) tables.append(rows) # 合并列數(shù)相同的連續(xù)表格 merged [] for t in tables: if merged and len(merged[-1][0]) len(t[0]): merged[-1].extend(t[1:]) # 跳過重復(fù)表頭 else: merged.append(t) return merged這個邏輯看起來簡單但實(shí)際跑起來會發(fā)現(xiàn)有些表格的列數(shù)因?yàn)楹喜卧穸翱雌饋聿煌毙枰茸隽袛?shù)歸一化。我的做法是取所有行的最大列數(shù)作為標(biāo)準(zhǔn)不足的補(bǔ)空。4.2 公式與圖表的文本化轉(zhuǎn)換探礦報(bào)告里的公式主要是品位計(jì)算公式、儲量估算公式。Word里的公式是OLE對象python-docx無法直接提取文本。有兩種處理路徑第一種是用docx2python或mammoth這類庫它們能把公式轉(zhuǎn)成LaTeX或MathML。第二種是先把Word轉(zhuǎn)成PDF再用PDF的公式識別方案處理。我傾向于第一種因?yàn)檗D(zhuǎn)換鏈路短信息損失小。圖表的處理更麻煩。探礦報(bào)告里的圖表通常是“品位等值線圖”“鉆孔柱狀圖”這些圖本身包含大量信息但RAG目前對圖片的處理能力有限。我的策略是圖片單獨(dú)存儲在文本中保留圖注和引用位置。比如原文是“見圖3-2 品位等值線圖”清洗后保留這段文字同時把圖3-2的圖片文件路徑記錄在元數(shù)據(jù)里。檢索時如果命中這段文字可以提示用戶查看對應(yīng)圖片。提示如果RAG知識庫需要存儲圖片建議把圖片轉(zhuǎn)成base64編碼后存入支持多模態(tài)的向量庫同時在文本chunk里保留圖片的描述性文字圖注、標(biāo)題、關(guān)鍵結(jié)論。純文本RAG無法直接檢索圖片內(nèi)容但可以通過圖注文字間接關(guān)聯(lián)。5. PDF解析版面分析與掃描件OCR的取舍5.1 雙欄排版與表格線的干擾排除PDF是探礦資料里最復(fù)雜的格式。老資料是掃描件新資料是排版軟件導(dǎo)出的電子版。電子版PDF的解析難點(diǎn)在于版面分析——地質(zhì)報(bào)告通常是雙欄排版直接按文本流讀取會把左右兩欄的內(nèi)容交錯在一起讀出來完全不通順。處理雙欄PDF我推薦用pdfplumber做版面分析。它可以把頁面按x坐標(biāo)切分成左右兩個區(qū)域分別提取文本。關(guān)鍵參數(shù)是layoutTrue和自定義的bbox裁剪區(qū)域。import pdfplumber def extract_two_column(pdf_path): with pdfplumber.open(pdf_path) as pdf: full_text [] for page in pdf.pages: width page.width left page.crop((0, 0, width/2, page.height)) right page.crop((width/2, 0, width, page.height)) left_text left.extract_text() or right_text right.extract_text() or full_text.append(left_text \n right_text) return \n.join(full_text)表格線是另一個干擾源。PDF里的表格是用線條畫的extract_text()會把表格內(nèi)容按閱讀順序拼成一行丟失行列關(guān)系。這時候需要用extract_tables()單獨(dú)提取表格再和正文合并。5.2 掃描件OCR后的噪聲清洗掃描件PDF必須走OCR。我常用的是PaddleOCR對中文地質(zhì)資料的識別率不錯。但OCR出來的文本有大量噪聲頁眉頁腳被識別成正文、表格線被識別成“—”“|”、手寫批注識別錯誤。清洗OCR結(jié)果需要一套組合拳頁眉頁腳過濾統(tǒng)計(jì)每頁開頭和結(jié)尾的重復(fù)文本出現(xiàn)頻率超過80%的視為頁眉頁腳刪除。短行合并OCR經(jīng)常把一行字切成多行需要根據(jù)標(biāo)點(diǎn)符號和語義合并。亂碼字符過濾連續(xù)出現(xiàn)3個以上非中文非英文非數(shù)字的字符大概率是識別錯誤標(biāo)記后人工復(fù)核。數(shù)字校驗(yàn)地質(zhì)數(shù)據(jù)里的數(shù)字很關(guān)鍵OCR容易把“0”識別成“O”、“1”識別成“l(fā)”需要用正則做模式校驗(yàn)。import re def clean_ocr_text(text): # 過濾連續(xù)亂碼 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9。、\s]{3,}, , text) # 修正常見數(shù)字誤識別 text re.sub(r(?\d)[Oo](?\d), 0, text) text re.sub(r(?\d)[lI](?\d), 1, text) # 合并被切斷的句子 text re.sub(r([^。\n])\n([^A-Z0-9]), r\1\2, text) return text注意OCR清洗沒有“一鍵完美”的方案。我的做法是清洗后隨機(jī)抽10%的頁面人工檢查如果錯誤率超過5%就調(diào)整OCR參數(shù)重新跑而不是硬著頭皮往下走。6. 網(wǎng)頁資料正文提取與動態(tài)內(nèi)容補(bǔ)全6.1 導(dǎo)航欄、廣告與評論區(qū)的剝離從網(wǎng)頁抓取的探礦資料最大的問題是噪聲。一篇地質(zhì)論文的網(wǎng)頁版正文可能只有3000字但導(dǎo)航欄、側(cè)邊欄、廣告、評論區(qū)加起來有10000字。直接全文抓取塞進(jìn)RAG檢索精度會被嚴(yán)重拉低。正文提取我推薦用trafilatura它對新聞和學(xué)術(shù)網(wǎng)頁的正文識別準(zhǔn)確率很高。如果trafilatura效果不理想可以用readability-lxml作為備選。兩個庫的核心邏輯都是找頁面上文本密度最高、鏈接密度最低的DOM節(jié)點(diǎn)那個節(jié)點(diǎn)大概率是正文。import trafilatura def extract_web_content(url): downloaded trafilatura.fetch_url(url) text trafilatura.extract( downloaded, include_commentsFalse, include_tablesTrue, no_fallbackFalse ) return textinclude_commentsFalse會剝離評論區(qū)include_tablesTrue保留表格。這兩個參數(shù)對探礦資料很重要——化驗(yàn)數(shù)據(jù)表要保留但網(wǎng)友評論要扔掉。6.2 JavaScript渲染頁面的抓取方案有些地質(zhì)數(shù)據(jù)庫網(wǎng)站是JavaScript動態(tài)渲染的直接請求HTML拿不到內(nèi)容。這時候需要用Playwright或Selenium模擬瀏覽器行為。我傾向于Playwright因?yàn)樗鼘Ξ惒郊虞d的處理更自然。from playwright.sync_api import sync_playwright def fetch_dynamic_page(url): with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url, wait_untilnetworkidle) content page.content() browser.close() return contentwait_untilnetworkidle表示等網(wǎng)絡(luò)請求完全停止后再抓取適合數(shù)據(jù)異步加載的頁面。但要注意有些頁面有無限滾動或定時刷新networkidle可能永遠(yuǎn)等不到這時候需要設(shè)置超時或改用domcontentloaded加手動等待。7. 清洗后的統(tǒng)一輸出與RAG入庫銜接四種格式清洗完最終要輸出成RAG能消費(fèi)的格式。我的標(biāo)準(zhǔn)輸出是JSONL每行一個chunk包含以下字段{ chunk_id: zk001_5_12, source_file: 鉆孔臺賬_2005.txt, source_type: txt, content: ZK001 5-12m 強(qiáng)風(fēng)化花崗巖 灰白色 巖芯采取率75%, metadata: { hole_id: ZK001, depth_from: 5, depth_to: 12, layer: 強(qiáng)風(fēng)化花崗巖 } }content是用于向量化的文本metadata是用于過濾和精確匹配的結(jié)構(gòu)化字段。RAG檢索時可以先按hole_id或depth范圍做元數(shù)據(jù)過濾再在過濾結(jié)果里做向量相似度檢索精度會大幅提升。切分粒度上我的經(jīng)驗(yàn)值是每個chunk 200-500字。太短丟失上下文太長向量化后語義被稀釋。對于結(jié)構(gòu)化數(shù)據(jù)如臺賬按行切分對于敘述性文本如報(bào)告按段落切分段落超過500字的再按句子邊界切分。提示清洗后的數(shù)據(jù)一定要做一輪抽樣驗(yàn)證。隨機(jī)抽50個chunk人工判斷“如果用戶問XX問題這個chunk能不能被召回并支撐回答”。如果召回率低于70%說明切分或清洗有問題需要回頭調(diào)整。8. 我踩過的坑與精度提升心得第一個坑是過度清洗。早期我做PDF清洗時把所有的換行符都刪了結(jié)果表格數(shù)據(jù)和正文混在一起檢索時完全分不清哪是表頭哪是數(shù)據(jù)。后來我學(xué)會了保留結(jié)構(gòu)標(biāo)記比如用[TABLE]和[/TABLE]包裹表格內(nèi)容用[PAGE_BREAK]標(biāo)記分頁。第二個坑是忽略元數(shù)據(jù)。一開始我只存文本內(nèi)容不存來源和結(jié)構(gòu)信息。結(jié)果檢索到一段“巖芯采取率75%”但不知道是哪個鉆孔、哪個深度。后來強(qiáng)制要求每個chunk必須帶來源文件和關(guān)鍵元數(shù)據(jù)檢索精度直接上了一個臺階。第三個坑是OCR語言模型選錯。探礦資料里有大量專業(yè)術(shù)語和地名通用OCR模型識別率很低。換成針對地質(zhì)領(lǐng)域微調(diào)過的OCR模型后專業(yè)術(shù)語的識別準(zhǔn)確率從60%提升到了90%以上。如果找不到領(lǐng)域模型至少要在OCR后加一個專業(yè)詞典做糾錯。第四個坑是網(wǎng)頁抓取頻率過高被封。批量抓取地質(zhì)數(shù)據(jù)庫時沒控制請求間隔IP被臨時封禁。后來加了隨機(jī)延遲1-3秒和User-Agent輪換問題解決。這個坑不涉及技術(shù)難度但很影響進(jìn)度。精度提升方面最有效的措施是混合檢索向量檢索加關(guān)鍵詞檢索BM25兩路結(jié)果做加權(quán)融合。純向量檢索對專業(yè)術(shù)語的匹配不夠精確加上BM25后像“ZK001”“花崗巖”“巖芯采取率”這類關(guān)鍵詞的召回率明顯提升。權(quán)重我一般設(shè)向量0.7、BM25 0.3具體根據(jù)數(shù)據(jù)特點(diǎn)調(diào)。另一個有效做法是查詢改寫。用戶問“ZK001的巖芯采取率是多少”直接檢索可能召回多個鉆孔的數(shù)據(jù)。我加了一個輕量的查詢解析步驟用正則提取鉆孔編號和指標(biāo)名稱先做元數(shù)據(jù)過濾再做向量檢索。這個改動讓檢索準(zhǔn)確率從65%左右提升到了85%以上。最后分享一個實(shí)用技巧建立清洗質(zhì)量監(jiān)控看板。每次清洗完一批數(shù)據(jù)自動統(tǒng)計(jì)chunk數(shù)量、平均長度、元數(shù)據(jù)完整率、亂碼率等指標(biāo)和歷史數(shù)據(jù)對比。如果某個指標(biāo)異常波動說明清洗流程可能出了問題。這個看板不復(fù)雜用Python腳本加一個簡單的HTML報(bào)告就能搞定但能幫你提前發(fā)現(xiàn)很多隱患。