1. 為什么 RAG 的第一步不是模型而是數(shù)據(jù)導入很多人一上來就研究向量庫選型、Embedding 模型對比、重排序策略結(jié)果折騰了兩周檢索效果還是稀爛。我踩過這個坑之后才徹底想明白一件事RAG 的上限在數(shù)據(jù)導入階段就已經(jīng)被鎖死了。你后面換再貴的模型、調(diào)再細的參數(shù)都救不回來一份被切得七零八落的原始文檔。這一篇先聚焦最基礎(chǔ)、也最容易被輕視的一環(huán)——通用文本與結(jié)構(gòu)化文本的導入與解析具體就是從純文本 txt 到 Markdown 這一類“半結(jié)構(gòu)化”文檔的處理。為什么先講這個因為絕大多數(shù)人的知識庫素材無非就是幾類隨手記的 txt 筆記、導出的 Markdown 文檔、從網(wǎng)頁另存下來的內(nèi)容、以及各種系統(tǒng)導出的結(jié)構(gòu)化文本。這些格式看起來簡單但恰恰是解析環(huán)節(jié)翻車最多的地方。我見過太多案例一份 300 頁的產(chǎn)品手冊用默認的字符切分器一切表格被攔腰截斷代碼塊被拆成兩半標題和正文混在一起最后檢索出來的片段驢唇不對馬嘴。用戶問“第三章第二節(jié)講了什么”系統(tǒng)返回的是某個表格中間的一行數(shù)字。這不是模型的問題是導入解析階段沒有把文檔的結(jié)構(gòu)信息保留下來。所以這篇內(nèi)容適合誰看如果你是剛接觸 RAG、正準備搭建第一個知識庫的開發(fā)者這篇能幫你避開最基礎(chǔ)的坑如果你已經(jīng)踩過一些坑、檢索效果不理想這篇能幫你回頭檢查數(shù)據(jù)導入環(huán)節(jié)到底哪里出了問題如果你在做企業(yè)級知識管理需要處理大量異構(gòu)文檔這篇提供的思路可以直接套用。核心關(guān)鍵詞就幾個RAG、數(shù)據(jù)導入、解析、txt、Markdown。我會圍繞這幾個詞把從原始文本到可檢索片段的完整鏈路拆開講包括格式識別、結(jié)構(gòu)提取、分塊策略、元數(shù)據(jù)注入以及每一步背后的取舍邏輯。1.1 先搞清楚RAG 里的“數(shù)據(jù)導入”到底在做什么很多人把數(shù)據(jù)導入理解成“把文件讀進來”這個認知太淺了。在 RAG 的語境下數(shù)據(jù)導入實際上要完成四件事第一是格式歸一化。你的原始素材可能是 txt、Markdown、HTML、PDF、Word甚至是從數(shù)據(jù)庫導出的 CSV。這些格式的底層結(jié)構(gòu)完全不同但最終都要變成同一種中間表示通常是帶結(jié)構(gòu)的純文本加上元數(shù)據(jù)。第二是結(jié)構(gòu)提取。文檔里的標題層級、段落邊界、列表、表格、代碼塊、引用塊這些結(jié)構(gòu)信息在后續(xù)檢索時極其重要。一個標題為“安裝步驟”的片段和一個正文里隨便一句話檢索權(quán)重應該是不一樣的。第三是語義分塊。不能簡單地按固定字符數(shù)切那樣會把完整的語義單元切碎。理想的分塊應該盡量保證每個塊是一個自包含的語義單元同時控制塊的大小在 Embedding 模型的最佳輸入范圍內(nèi)。第四是元數(shù)據(jù)注入。每個塊需要攜帶來源信息來自哪個文件、哪個章節(jié)、第幾頁、什么時間導入的。這些元數(shù)據(jù)在檢索過濾和結(jié)果溯源時必不可少。這四件事里格式歸一化和結(jié)構(gòu)提取是基礎(chǔ)語義分塊是核心難點元數(shù)據(jù)注入是工程細節(jié)。下面逐個拆開講。1.2 為什么從 txt 和 Markdown 講起有人會問現(xiàn)在 PDF 解析工具那么多為什么不直接從 PDF 開始講原因很簡單txt 和 Markdown 是理解解析本質(zhì)的最佳切入點。PDF 的解析本質(zhì)上是在做逆向工程——從排版結(jié)果反推邏輯結(jié)構(gòu)這個過程充滿了不確定性。而 txt 和 Markdown 不一樣它們的結(jié)構(gòu)信息是顯式存在的。Markdown 的#就是標題|就是表格 就是代碼塊。你不需要猜只需要正確識別。先把這兩種格式吃透建立起“結(jié)構(gòu)感知”的思維習慣再去處理 PDF 這種“結(jié)構(gòu)隱式”的格式會順暢很多。而且實際項目中Markdown 正在成為知識庫素材的主流格式——很多文檔工具都支持導出 Markdown很多技術(shù)文檔本身就是用 Markdown 寫的。2. 通用文本與結(jié)構(gòu)化文本的解析核心思路2.1 格式識別與預處理別急著讀文件內(nèi)容拿到一個文件第一件事不是直接讀內(nèi)容而是先判斷它到底是什么格式。這里有個坑文件擴展名不可信。我遇到過.txt文件實際是 HTML 源碼的也遇到過.md文件里混著大量 HTML 標簽的。穩(wěn)妥的做法是做一個輕量的格式探測讀取文件前 2KB 內(nèi)容檢查是否有 Markdown 特征#開頭的行、|表格、 代碼塊圍欄檢查是否有 HTML 特征html、div、p等標簽檢查是否有 CSV 特征逗號分隔、制表符分隔、行列數(shù)一致如果都沒有按純文本處理這個探測邏輯不需要很復雜幾十行代碼就能搞定。但就是這幾十行代碼能幫你避免后面大量的解析異常。預處理階段還有幾件事要做編碼統(tǒng)一。中文文檔常見的編碼有 UTF-8、GBK、GB2312甚至還有 GB18030。如果編碼判斷錯了讀出來全是亂碼。我的做法是先用chardet之類的庫探測編碼然后用探測到的編碼讀取讀完之后統(tǒng)一轉(zhuǎn)成 UTF-8。如果探測置信度低于某個閾值就嘗試用 UTF-8 讀取失敗再回退到 GBK。換行符統(tǒng)一。Windows 的\r\n、Unix 的\n、老 Mac 的\r這三種換行符混在一起會讓后續(xù)的分行邏輯出錯。統(tǒng)一替換成\n是標準操作?？瞻鬃址謇怼＿B續(xù)多個空行、行尾多余空格、制表符和空格混用這些都會影響結(jié)構(gòu)識別的準確性。但注意不要過度清理比如 Markdown 里行尾兩個空格表示換行這個不能刪。提示預處理階段的所有操作都應該是可逆的或者有日志記錄的。一旦發(fā)現(xiàn)解析結(jié)果異常你需要能回溯到原始內(nèi)容判斷是預處理引入的問題還是解析邏輯本身的問題。2.2 結(jié)構(gòu)提取把文檔的“骨架”抽出來結(jié)構(gòu)提取的目標是回答一個問題這份文檔的層級關(guān)系是什么。對于 Markdown結(jié)構(gòu)是顯式的。#到######對應六級標題標題之間的內(nèi)容屬于該標題的章節(jié)。解析時可以用一個棧來維護當前的標題路徑。比如遇到## 第二章棧變成[第二章]再遇到### 2.1 節(jié)棧變成[第二章, 2.1 節(jié)]。每個內(nèi)容塊都記錄它所屬的完整標題路徑。對于純文本結(jié)構(gòu)是隱式的但通常有規(guī)律可循。常見的模式包括用數(shù)字編號的行如1.、1.1、第一章用特殊符號裝飾的行如、-----、*****全行加粗或全行大寫的行縮進層級變化我一般會寫一組正則規(guī)則來識別這些模式按優(yōu)先級依次匹配。匹配到的行標記為“疑似標題”然后根據(jù)編號的層級關(guān)系推斷標題級別。比如1.是一級1.1是二級1.1.1是三級。這里有個經(jīng)驗不要追求 100% 的標題識別準確率。實際文檔里總有一些奇怪的格式強行識別反而會引入噪聲。我的做法是設(shè)置一個置信度閾值高置信度的直接標記為標題低置信度的保留為普通段落但在元數(shù)據(jù)里標注“疑似標題”。后續(xù)檢索時可以根據(jù)需要決定是否利用這個信息。表格的提取是另一個重點。Markdown 表格用|分隔解析相對簡單。純文本表格就麻煩了可能是空格對齊、制表符對齊、或者用---畫邊框。我的建議是能識別就識別識別不了就整塊保留。千萬不要把表格拆成一行一行的文本那樣表格的語義就徹底丟了。代碼塊的識別相對簡單Markdown 用 圍欄純文本通?？靠s進或者前后空行判斷。代碼塊在分塊時應該作為一個整體不要從中間切開。2.3 分塊策略RAG 效果的分水嶺分塊是數(shù)據(jù)導入階段最核心的決策沒有之一。分塊策略直接決定了檢索質(zhì)量的上限。先說一個反直覺的結(jié)論固定長度分塊幾乎總是錯的。很多人圖省事直接按 500 字符切重疊 50 字符。這種做法在簡單場景下能用但只要文檔有結(jié)構(gòu)就會出問題。一個完整的操作步驟被切成兩半前半段說“點擊設(shè)置按鈕”后半段說“在彈出窗口中選擇高級選項”檢索時只召回前半段用戶根本不知道下一步該干什么。我的分塊策略是結(jié)構(gòu)感知的遞歸分塊具體邏輯如下第一優(yōu)先級是按結(jié)構(gòu)邊界切分。標題、章節(jié)、列表項、表格、代碼塊這些都是天然的邊界。一個章節(jié)的內(nèi)容如果不超過最大塊大小就整塊作為一個 chunk。如果超過再往下切。第二優(yōu)先級是按語義邊界切分。段落是最小的語義單元盡量保證一個段落不被切開。如果單個段落就超過了最大塊大小比如一段超長的法律條款那就只能按句子切。第三優(yōu)先級才是按長度切分。當以上邊界都不存在時才退回到按字符數(shù)切分并且盡量在句子結(jié)束符處斷開。塊大小的選擇需要根據(jù) Embedding 模型來定。大多數(shù)中文 Embedding 模型的最佳輸入長度在 256 到 512 個 token 之間。我的經(jīng)驗值是目標塊大小 400 到 600 字符最大不超過 800 字符塊之間重疊 10% 到 15%。重疊的目的是防止邊界處的信息丟失但重疊太多會導致檢索結(jié)果冗余。這里有個細節(jié)不同結(jié)構(gòu)的塊應該有不同的目標大小。表格和代碼塊可以大一些因為它們的語義密度高切碎了反而不好。普通敘述性段落可以小一些因為語義密度低塊太大反而稀釋了關(guān)鍵信息。2.4 元數(shù)據(jù)設(shè)計讓每個塊都能“自報家門”元數(shù)據(jù)在檢索階段的價值經(jīng)常被低估。一個好的元數(shù)據(jù)設(shè)計能讓檢索效果提升一個檔次。每個 chunk 至少應該攜帶以下元數(shù)據(jù)元數(shù)據(jù)字段說明用途source_file來源文件名結(jié)果溯源、按文件過濾file_type文件類型按類型過濾、調(diào)試heading_path標題路徑結(jié)果展示、按章節(jié)過濾chunk_index塊序號排序、去重char_count字符數(shù)質(zhì)量監(jiān)控has_table是否含表格特殊處理標記has_code是否含代碼特殊處理標記import_time導入時間增量更新標題路徑heading_path是我認為最有價值的元數(shù)據(jù)。它記錄了當前塊所屬的完整章節(jié)路徑比如[第三章 安裝部署, 3.2 環(huán)境配置, 3.2.1 依賴安裝]。在檢索結(jié)果展示時把這個路徑顯示出來用戶一眼就能知道這個片段來自哪里信任度會高很多。而且在檢索時可以利用標題路徑做上下文增強。比如用戶問“依賴安裝有哪些步驟”檢索到的塊標題路徑里包含“依賴安裝”這個塊的權(quán)重就應該提高。這種基于結(jié)構(gòu)的加權(quán)比單純依賴向量相似度要可靠得多。3. 從 txt 到 Markdown 的完整實操流程3.1 環(huán)境準備與依賴選擇我用的技術(shù)棧是 Python核心依賴就幾個pip install chardet markdown-it-py beautifulsoup4 lxmlchardet編碼探測處理中文文檔必備markdown-it-pyMarkdown 解析比正則更可靠beautifulsoup4lxml處理混入的 HTML 內(nèi)容如果你不想引入太多依賴純文本處理用標準庫就夠了。但 Markdown 解析我強烈建議用專門的庫自己寫正則處理嵌套結(jié)構(gòu)會瘋掉。3.2 第一步文件讀取與編碼歸一化import chardet def read_file_safely(file_path): with open(file_path, rb) as f: raw f.read() # 探測編碼 detected chardet.detect(raw[:10000]) encoding detected[encoding] confidence detected[confidence] # 置信度低時回退 if confidence 0.7 or encoding is None: encoding utf-8 try: text raw.decode(encoding) except UnicodeDecodeError: # 回退鏈 for fallback in [utf-8, gbk, gb18030, latin-1]: try: text raw.decode(fallback) break except UnicodeDecodeError: continue else: text raw.decode(utf-8, errorsreplace) # 換行符統(tǒng)一 text text.replace(\r\n, \n).replace(\r, \n) return text這段代碼的關(guān)鍵在于回退鏈。中文文檔的編碼情況很復雜單一探測不一定準。我實測下來chardet對 UTF-8 和 GBK 的區(qū)分準確率大概在 85% 左右剩下的 15% 就得靠回退鏈兜底。注意latin-1放在回退鏈最后是有原因的。它能解碼任何字節(jié)序列永遠不會拋異常但解出來的可能是亂碼。所以它只是最后的保底不能作為首選。3.3 第二步格式探測與路由import re def detect_format(text): sample text[:2000] # Markdown 特征 md_patterns [ r^#{1,6}\s, # 標題 r^\|.*\|$, # 表格 r^, # 代碼塊 r^\s*[-*]\s, # 無序列表 r^\s*\d\.\s, # 有序列表 ] md_score sum(1 for p in md_patterns if re.search(p, sample, re.MULTILINE)) # HTML 特征 html_score len(re.findall(r[a-z][^]*, sample)) # CSV 特征 lines sample.split(\n)[:10] csv_score 0 if len(lines) 1: comma_counts [line.count(,) for line in lines if line.strip()] if comma_counts and len(set(comma_counts)) 1 and comma_counts[0] 0: csv_score 3 if md_score 2: return markdown elif html_score 5: return html elif csv_score 3: return csv else: return plaintext這個探測邏輯的核心思想是多特征投票而不是單一特征判斷。因為實際文檔里經(jīng)常出現(xiàn)混合情況比如 Markdown 里嵌了 HTML純文本里用了#做注釋。多特征投票能降低誤判率。3.4 第三步Markdown 結(jié)構(gòu)解析用markdown-it-py把 Markdown 解析成 token 流然后遍歷 token 構(gòu)建結(jié)構(gòu)樹from markdown_it import MarkdownIt def parse_markdown_structure(text): md MarkdownIt() tokens md.parse(text) structure [] heading_stack [] current_content [] for token in tokens: if token.type heading_open: # 保存之前的內(nèi)容 if current_content: structure.append({ type: content, heading_path: list(heading_stack), text: \n.join(current_content) }) current_content [] level int(token.tag[1]) # h1 - 1 # 維護標題棧 while heading_stack and heading_stack[-1][0] level: heading_stack.pop() heading_stack.append((level, )) elif token.type inline and heading_stack and heading_stack[-1][1] : # 標題文本 heading_stack[-1] (heading_stack[-1][0], token.content) elif token.type in (fence, code_block): current_content.append(f\n{token.content}\n) elif token.type table_open: # 表格單獨處理 pass elif token.type inline: current_content.append(token.content) # 處理最后一段 if current_content: structure.append({ type: content, heading_path: [h[1] for h in heading_stack], text: \n.join(current_content) }) return structure這段代碼的核心是標題棧。棧里維護的是當前所處的標題路徑遇到新標題時根據(jù)級別彈出舊標題、壓入新標題。每個內(nèi)容塊都記錄它被解析時的標題路徑。實際使用中還需要處理表格和代碼塊的完整提取。markdown-it-py的 token 流里表格會被拆成table_open、tr_open、td_open等一系列 token需要專門寫邏輯把它們重新組裝成結(jié)構(gòu)化的表格數(shù)據(jù)。3.5 第四步純文本結(jié)構(gòu)推斷純文本沒有顯式結(jié)構(gòu)需要靠正則和啟發(fā)式規(guī)則推斷def infer_plaintext_structure(text): lines text.split(\n) blocks [] current_block [] current_heading None # 標題識別規(guī)則按優(yōu)先級排列 heading_patterns [ (r^第[一二三四五六七八九十][章節(jié)篇]\s*, 1), (r^\d\.\d\.\d\s, 3), (r^\d\.\d\s, 2), (r^\d\.\s, 1), (r^[一二三四五六七八九十][、.]\s*, 2), (r^{3,}$, 0), # 下劃線裝飾標記上一行為標題 (r^-{3,}$, 0), ] for i, line in enumerate(lines): stripped line.strip() # 空行作為塊邊界 if not stripped: if current_block: blocks.append({ type: content, heading: current_heading, text: \n.join(current_block) }) current_block [] continue # 檢查是否是標題 is_heading False for pattern, level in heading_patterns: if re.match(pattern, stripped): if level 0: # 裝飾線把上一行提升為標題 if current_block: current_heading current_block.pop() else: # 保存之前的內(nèi)容 if current_block: blocks.append({ type: content, heading: current_heading, text: \n.join(current_block) }) current_block [] current_heading stripped is_heading True break if not is_heading: current_block.append(line) # 收尾 if current_block: blocks.append({ type: content, heading: current_heading, text: \n.join(current_block) }) return blocks這套規(guī)則不是萬能的但覆蓋了中文技術(shù)文檔里 80% 以上的標題格式。剩下的 20% 需要根據(jù)具體文檔類型定制規(guī)則。實操心得我一般會先拿幾份典型文檔跑一遍把識別錯誤的標題打印出來針對性調(diào)整正則。這個過程通常需要迭代兩三輪但一旦調(diào)好后續(xù)同類文檔都能復用。3.6 第五步結(jié)構(gòu)感知的分塊有了結(jié)構(gòu)樹之后分塊就變成了一個遞歸過程def chunk_by_structure(blocks, max_size600, min_size100, overlap80): chunks [] for block in blocks: text block[text] heading block.get(heading, ) # 塊本身不超過限制直接作為一個 chunk if len(text) max_size: if len(text) min_size: chunks.append({ text: text, heading: heading, char_count: len(text) }) continue # 超長塊按段落切分 paragraphs text.split(\n\n) current [] current_len 0 for para in paragraphs: para_len len(para) if current_len para_len max_size and current: chunk_text \n\n.join(current) chunks.append({ text: chunk_text, heading: heading, char_count: len(chunk_text) }) # 保留重疊部分 overlap_text chunk_text[-overlap:] if len(chunk_text) overlap else chunk_text current [overlap_text, para] current_len len(overlap_text) para_len else: current.append(para) current_len para_len if current: chunk_text \n\n.join(current) chunks.append({ text: chunk_text, heading: heading, char_count: len(chunk_text) }) return chunks這里有幾個關(guān)鍵決策點為什么最小塊大小是 100 字符太小的塊語義不完整Embedding 出來的向量質(zhì)量差檢索時容易誤召回。100 字符大約是一到兩句話是語義完整性的下限。為什么重疊是 80 字符這是經(jīng)驗值。重疊太少起不到防止邊界信息丟失的作用重疊太多會導致檢索結(jié)果大量重復。80 字符大約是一句話的長度能保證邊界處的語義連續(xù)性。表格和代碼塊怎么處理它們不應該參與常規(guī)分塊。表格應該整體保留如果太大就按行切分但保留表頭。代碼塊應該整體保留如果太大就按函數(shù)或邏輯塊切分。3.7 第六步元數(shù)據(jù)注入與輸出最后一步是把分塊結(jié)果和元數(shù)據(jù)組裝起來輸出成后續(xù)流程能消費的格式import json from datetime import datetime def build_chunks_with_metadata(chunks, source_file, file_type): result [] for i, chunk in enumerate(chunks): result.append({ id: f{source_file}_{i}, text: chunk[text], metadata: { source_file: source_file, file_type: file_type, heading: chunk.get(heading, ), chunk_index: i, char_count: chunk[char_count], has_table: | in chunk[text] and --- in chunk[text], has_code: in chunk[text], import_time: datetime.now().isoformat() } }) return result輸出格式我推薦 JSON Lines每行一個 chunk。這樣便于流式處理也便于后續(xù)增量更新時按行追加。4. 常見問題與排查技巧實錄4.1 編碼問題排查速查表現(xiàn)象可能原因排查方法解決方案中文全是亂碼編碼判斷錯誤用十六進制查看器看字節(jié)嘗試 GBK/GB18030部分字符亂碼混合編碼分段探測編碼分段解碼后拼接問號替代中文解碼時 errorsreplace檢查原始字節(jié)換正確編碼重新解碼換行符異?；旌蠐Q行符統(tǒng)計 \r\n 和 \n 數(shù)量統(tǒng)一替換編碼問題我踩過最坑的一次是一份文檔前半部分是 UTF-8后半部分是 GBK。chardet探測出來是 UTF-8結(jié)果后半部分全亂碼。后來我的做法是分段探測每 10KB 探測一次如果發(fā)現(xiàn)編碼不一致就分段解碼。4.2 結(jié)構(gòu)識別失敗的典型場景場景一標題沒有編號。有些文檔的標題就是加粗的一行文字沒有任何編號。這種情況純文本推斷很難識別。我的做法是結(jié)合行長和上下文空行來判斷如果一行文字長度小于 30 字符前后都有空行且不以標點結(jié)尾就標記為疑似標題。場景二列表嵌套過深。Markdown 的嵌套列表用縮進表示但縮進可能是 2 空格、4 空格、或者 Tab。解析時需要統(tǒng)一縮進單位。我的做法是統(tǒng)計所有縮進取最小公約數(shù)作為一級縮進單位。場景三表格跨頁。從 PDF 轉(zhuǎn)出來的文本表格經(jīng)常被分頁符打斷。這種情況需要在預處理階段識別分頁符嘗試把跨頁的表格拼接起來。拼接邏輯是如果上一頁末尾是表格行下一頁開頭也是表格行且列數(shù)一致就嘗試合并。4.3 分塊質(zhì)量的快速驗證方法分塊做完之后怎么知道分得好不好我一般用三個快速檢查檢查一隨機抽樣 20 個 chunk人工閱讀?？疵總€ chunk 是否語義完整是否包含足夠的上下文。如果發(fā)現(xiàn)大量 chunk 以半句話開頭或結(jié)尾說明分塊邊界有問題。檢查二統(tǒng)計 chunk 大小分布。畫個直方圖看是否集中在目標大小附近。如果出現(xiàn)大量極小 chunk小于 50 字符或極大 chunk大于 1000 字符說明分塊邏輯有漏洞。檢查三做一輪檢索測試。準備 10 個典型問題看檢索結(jié)果是否相關(guān)。如果檢索結(jié)果經(jīng)常是表格中間的一行、或者代碼塊的片段說明結(jié)構(gòu)處理有問題。實操心得我習慣在分塊完成后把 chunk 列表導出成 Markdown 文件用編輯器打開快速瀏覽。肉眼掃一遍比看統(tǒng)計數(shù)字更容易發(fā)現(xiàn)異常。4.4 性能優(yōu)化的幾個實用技巧數(shù)據(jù)導入階段如果處理大量文檔性能會成為瓶頸。幾個我實測有效的優(yōu)化批量讀取。不要一個文件一個文件地讀用concurrent.futures做并發(fā)讀取。IO 密集型任務并發(fā)能帶來數(shù)倍提升。惰性解析。如果文檔很大不要一次性全部解析成 token 流。markdown-it-py支持流式解析可以邊解析邊處理。緩存中間結(jié)果。結(jié)構(gòu)解析的結(jié)果可以緩存起來后續(xù)調(diào)整分塊參數(shù)時不需要重新解析。我用pickle把結(jié)構(gòu)樹緩存到本地調(diào)試分塊邏輯時能省大量時間。正則預編譯。所有正則表達式在模塊加載時就編譯好不要每次調(diào)用時重新編譯。這個優(yōu)化在小文檔上不明顯但處理上萬份文檔時差距很大。5. 從導入到檢索的銜接要點5.1 導入結(jié)果如何影響檢索策略數(shù)據(jù)導入階段產(chǎn)出的 chunk 和元數(shù)據(jù)直接決定了檢索階段能做什么。如果 chunk 攜帶了heading元數(shù)據(jù)檢索時就可以做基于標題的加權(quán)。具體做法是計算 query 和 chunk 標題的相似度把這個相似度作為一個加權(quán)因子和向量相似度做加權(quán)求和。我實測下來這個加權(quán)能讓檢索準確率提升 10% 到 15%。如果 chunk 標記了has_table和has_code檢索時就可以做類型感知的展示。表格類結(jié)果用表格渲染代碼類結(jié)果用代碼塊渲染用戶體驗會好很多。如果 chunk 記錄了source_file和chunk_index檢索時就可以做上下文擴展。召回一個 chunk 后把它的前后相鄰 chunk 也取出來拼成更完整的上下文。這個技巧對回答“步驟類”問題特別有效。5.2 增量導入的設(shè)計考慮實際項目中知識庫是持續(xù)更新的。增量導入的設(shè)計要點文件指紋。對每個文件計算 MD5 或 SHA256導入前先比對指紋。指紋沒變就跳過變了就重新導入。版本管理。每次導入生成一個版本號chunk 的 ID 里包含版本信息。這樣檢索時可以指定只檢索最新版本或者做版本對比。刪除處理。文件被刪除時對應的 chunk 也要標記刪除。不要物理刪除而是打上deleted標記檢索時過濾掉。這樣萬一誤刪還能恢復。5.3 質(zhì)量監(jiān)控指標導入流程上線后需要持續(xù)監(jiān)控幾個指標指標含義健康范圍平均 chunk 大小所有 chunk 的字符數(shù)均值300-600極小 chunk 占比小于 50 字符的 chunk 比例 5%極大 chunk 占比大于 1000 字符的 chunk 比例 3%編碼異常率解碼時使用回退鏈的比例 2%結(jié)構(gòu)識別率成功識別標題的文檔比例 80%這些指標異常時說明導入流程的某個環(huán)節(jié)出了問題需要回頭排查。6. 一些踩坑之后的個人體會做 RAG 數(shù)據(jù)導入這一年多最大的體會是慢就是快。剛開始我總想快點把數(shù)據(jù)灌進去結(jié)果檢索效果差回頭返工的時間遠超當初省下的時間。后來我養(yǎng)成了一個習慣每接入一種新格式的文檔先拿 5 到 10 份樣本做小規(guī)模測試把解析結(jié)果人工過一遍確認沒問題了再批量導入。另一個體會是不要迷信自動化。結(jié)構(gòu)識別、分塊這些環(huán)節(jié)純靠算法很難做到 100% 準確。我的做法是提供一個“人工校正”的接口對于識別異常的文檔允許手動調(diào)整結(jié)構(gòu)標記。這個接口看起來增加了工作量但實際上大幅提升了最終質(zhì)量。還有一個細節(jié)保留原始文本。不管怎么預處理、怎么分塊原始文本一定要完整保留。我見過太多案例預處理時做了不可逆的清洗后來發(fā)現(xiàn)清洗掉了關(guān)鍵信息想恢復都恢復不了。我的做法是原始文本單獨存一份所有處理都是基于副本進行的。最后分享一個小技巧用檢索測試反推導入質(zhì)量。準備一組典型問題每次調(diào)整導入?yún)?shù)后跑一遍檢索測試看召回結(jié)果的變化。這比看統(tǒng)計指標更直觀也更能發(fā)現(xiàn)實際問題。我一般會維護一個 50 題左右的測試集覆蓋事實查詢、步驟查詢、對比查詢等不同類型每次調(diào)整參數(shù)后都跑一遍記錄準確率變化。這個內(nèi)容后續(xù)還可以這樣擴展把 PDF、Word、HTML 這些格式的解析也納入進來形成一套完整的異構(gòu)文檔導入方案。另外表格和圖片的專項處理也值得單獨展開特別是表格的結(jié)構(gòu)化提取和圖片的 OCR 處理都是實際項目中繞不開的環(huán)節(jié)。