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