我最近在排查一個線上知識庫的檢索效果問題模型參數調了好幾輪向量庫也換了更貴的結果召回來的內容還是莫名其妙。后來把鏈路拆開一層層看發(fā)現(xiàn)問題根本不在模型而是出在最前面的文檔解析和切片上——PDF里的表格被解析得支離破碎切片又把本來完整的一段業(yè)務規(guī)則攔腰截斷。那一刻我才真正意識到文檔解析與切片這套地基如果打歪了后面embedding、重排、生成做得再花哨都是白搭。這篇就專門聊聊解析和切片這兩個環(huán)節(jié)。它們看上去門檻低實際上決定了整個檢索鏈路的天花板。如果你正在搭RAG應用、知識庫問答系統(tǒng)或者在做文檔結構化處理這篇文章值得你花十分鐘讀完——我會把選型邏輯、切片策略、以及我在真實項目里踩過的坑一次性講清楚。1. 解析與切片的問題是怎么一步步毀掉檢索效果的1.1 一個典型的模型沒問題效果卻很爛案例先說一個我實際處理過的案例。一個企業(yè)內部制度問答系統(tǒng)文檔源主要是Word和PDF總量大概兩千份。初版上線后用戶問請假的審批流程是什么系統(tǒng)召回的全是考勤管理制度-第一章-總則里面只有一句請假需按規(guī)定辦理真正的流程表格完全沒被切進去。再問報銷額度上限召回來的是封面頁和目錄頁正文圖表完全缺失。我把embedding模型從bge-small換到bge-m3把向量檢索的top-k從5調到20加上了重排模型效果依然沒有本質改善。后來把ssembled文本dump出來一看發(fā)現(xiàn)問題全在解析階段PDF里的表格被讀成了豎排一列的文本Word里的章節(jié)標題丟失了層級關系有的文檔干脆只讀到了第一頁。這個案例說明一件事檢索效果不是從向量檢索那一刻才開始的而是從文檔被解析成文本的那一刻就已經被決定了。解析階段丟掉的信息后面無論怎么調參都找不回來。1.2 解析與切片真正影響的是召回而不是排序很多人會把檢索效果不好歸咎于排序模型但實際上解析和切片主要影響的是召回環(huán)節(jié)。召回的本質是把用戶的問題和候選片段做相似度匹配。如果切片里存的文本是殘缺的、語義錯位的那么它和用戶問題之間的向量距離天然就很遠。排序模型只能在召回來的候選項里做排序如果候選項本身質量差排序再好也是矮子里拔將軍。我用一個簡單的類比來解釋解析和切片就像做飯前的洗菜切菜。菜沒洗干凈、切得大小不一后面廚藝再好炒出來的菜也是夾著沙子的。做RAG的人往往花大量精力在模型選型、Prompt設計上卻忽略了前面這兩步——這恰恰是最不該忽略的。等到效果出問題再回頭改地基返工成本遠高于一開始就做好。2. 文檔解析怎么選型按文檔類型進攻而不是一套工具打天下2.1 PDF解析的方案對比PyMuPDF、pdfplumber與重型工具PDF是最常見的文檔格式也是最難處理的。原因在于PDF本質上是一套畫布指令它記錄的是每個字符放在哪個坐標位置而不是這里是一個段落這樣的邏輯結構。所以解析PDF本質上是在做逆向工程。我實際用過的方案有這幾類先說結論再展開方案適用場景優(yōu)點缺點PyMuPDFfitz文字型PDF、版面簡單的文檔速度快、文本提取質量尚可表格結構丟失、復雜版面錯亂pdfplumber需要精確坐標、表格抽取能拿到字符級坐標、表格線識別較好速度慢、對掃描版無能為力marker / MinerU復雜版面、多欄、有圖表的論文版面還原度高、能識別標題層級依賴深度學習模型、需要GPU、速度慢OCRPaddleOCR等掃描版PDF能處理圖片型文檔識別錯誤率、布局還原難我現(xiàn)在的選擇策略很簡單先用PyMuPDF快速識別文檔類型如果頁面里沒有復雜表格、沒有多欄排版直接用PyMuPDF提文本就夠了快且穩(wěn)定。如果檢測到表格切到pdfplumber單獨處理表格頁。如果是掃描版或者版面特別復雜的論文用marker這類工具做整體解析。這里有一個反直覺的結論不是工具越重越好。對于文字敘述為主、版面簡單的文檔用重型工具反而可能引入識別錯誤。我見過marker把公司名稱里的冒號識別成亂碼的情況輕量工具反而沒這個問題。2.2 Word/PPT/HTML的處理細節(jié)結構信息別丟很多人解析PDF時小心翼翼處理Word和PPT卻很隨意直接用python-docx和python-pptx把段落文本提出來就完事。這其實是個大坑。Word文檔的寶貴之處在于它的結構信息是現(xiàn)成的Heading 1/2/3、表格單元格、加粗、項目符號這些都是語義信號。如果只提取純文本等于把這些信號全扔了。我的做法是保留標題層級標記在文本里用特殊符號標注比如## 表示二級標題這樣后面切片時就可以基于標題做切分。PPT的處理更要注意。PPT的文本往往以文本框為單位散落在頁面上閱讀順序并不等于文本框的存儲順序。如果直接用python-pptx按順序讀讀出來的內容順序很可能是亂的。我的做法是先按每個文本框的坐標top屬性排序再按從左到右的順序組合文本這樣才能保證一段話的先后關系是正確的。HTML文檔相對簡單用BeautifulSoup提取正文時注意去掉導航、廣告、頁腳之類的噪音然后把p標簽、h2標簽這些語義信息保留下來。很多爬蟲抓下來的網頁正文前后全是推薦鏈接不清理的話噪音會占據切片名額。2.3 表格解析的保真讓列的語義存活下來表格是文檔解析里最容易翻車的地方。我見過最離譜的情況是一個三列的報銷標準表格解析后被讀成了三行連續(xù)的文本每一行是費用類型 限額 備注這種內容的交錯拼接。這種文本喂給切分器要么被切成毫無意義的片段要么和query的匹配度極低。我的處理方式是先檢測頁面是否包含表格然后對表格單獨走行列重組流程。具體做法是利用pdfplumber拿到表格線的坐標或者用python-docx拿到表格對象然后把每一行的單元格內容合并成一個結構化字符串單元格之間用自定義分隔符比如 | 連接。這樣一個表格行就變成了一段相對完整的語義單元。重組之后還需要做一個關鍵處理把表格的表頭信息拼進每一行。比如表格第一行是費用類型|限額|備注第二行是住宿|500/天|需發(fā)票我會把表頭拼到數據行后面變成費用類型住宿限額500/天備注需發(fā)票。這樣切出來的片段單獨拿出來也是自解釋的檢索時不會因為缺少表頭信息、上下文不完整而失效。3. 切片策略沒有銀彈按文本形態(tài)設計chunking方案3.1 四種常見切片策略及其適用場景切片是做RAG最糾結的一環(huán)因為不存在一個參數能讓所有文檔類型都表現(xiàn)好。我整理過四種常見策略它們各有各的適用場景固定長度切片按字符數或token數硬切。實現(xiàn)最簡單但語義完整性最差。只適合文本結構均勻的日志、規(guī)則條文這類場景。遞歸字符切分先用段落分隔符切段落太長再按句號切句子太長再按逗號切。這是LangChain等框架的默認方案對普通文本效果尚可但對結構化內容不敏感。語義切分把文本按embedding相似度聚類或者在語義邊界處切斷。效果好但計算成本高而且對短文本、表格類內容容易誤判。結構切分基于文檔本身的標題結構切一個章節(jié)作為一個切片。適合有明確章節(jié)結構的文檔但章節(jié)太長時切片過大需要再二次切分。我在實際項目中用的最多的是結構切分遞歸字符切分的組合先按標題把文檔切成章節(jié)塊每個章節(jié)塊如果超過設定長度再按段落和句子遞歸切分。這樣既保留了章節(jié)的語義邊界又控制了切片長度。3.2 語義邊界比長度更重要為什么要在標題、段落邊界切不少人設定切片長度時會糾結chunk_size到底是512還是1024但其實長度的絕對值并沒有那么重要重要的是切的時候有沒有照顧語義邊界。我舉個例子一段話是根據規(guī)定員工出差住宿費標準為一線城市500元/天二線城市350元/天其他城市260元/天。超過標準部分不予報銷。如果在一線城市500元/天后面硬切那么第一個切片里只有半句話第二個切片開頭是二線城市350元/天兩邊的信息都不完整。用戶問二線城市住宿標準第二個切片也許能匹配上但如果用戶問住宿費報銷標準是什么兩個切片都覆蓋不了整條規(guī)則。所以我的原則是在句子邊界和段落邊界切盡量保持一個完整的語義單元。如果必須在一個段落內部切也要在句號、分號這類標點處切而不是按字符數硬切。這一步看似簡單但它直接決定了后續(xù)embedding時每個切片的語義密度。3.3 特殊內容怎么辦代碼塊、表格和列表的切片策略代碼塊和表格這類結構化內容用普通文本切片策略會切得稀碎。代碼塊的問題在于函數定義、調用、返回往往跨越多個段落硬切會把函數體攔腰截斷導致篩出來的代碼片段沒法運行。表格的問題前面也提過行列信息一旦被切成碎片就完全失去了表意能力。對于代碼塊我建議按函數或類來切而不是按行數切?？梢杂煤唵蔚腁ST解析先識別出每個函數的起止行號再按函數邊界切片。如果文檔是Markdown格式代碼塊本身有明確的分隔標記可以保留這些標記作為邊界。對于沒有AST工具的場合至少也要在空行處切而不是在代碼行中間切。對于表格前文提到了表頭拼接法切片時直接以表格塊為單位一個表格行或一組相關行作為一個切片。確保切片內包含表頭信息這樣檢索時即使只有片段也能還原出每個單元格的含義。列表的話盡量保留項目符號或編號把整個列表作為一個切片不要切斷中間的項目項。4. 別再拿Python列表切片那套思路切文檔4.1 Python數組切片的語法與直覺提到切片這個詞很多Python開發(fā)者第一反應是列表切片# 列表切片 items [0, 1, 2, 3, 4, 5] print(items[1:4]) # [1, 2, 3] print(items[:3]) # [0, 1, 2] print(items[::2]) # [0, 2, 4]這種切片的直覺是我有n個元素按照下標范圍切出來一段剩下的是另一段。這個模型放在數組上完全正確因為數組元素之間沒有上下文依賴每個元素是獨立的。但文本不是這樣的。文本的每個字符、每個詞之間有著強烈的上下文依賴——他指代的是前文的某個人根據上述規(guī)定依賴的是上一段的條款。如果你把文本當成數組來越界切分就相當于把一句話從中間掰斷前后兩部分都失去了理解所需的上下文。這就是用list思維切文檔最大的坑。4.2 文本切片的隱藏變量語義、上下文與metadata文本切片和數組切片最大的不同在于切片對象不是元素而是語義塊。一個語義塊可以被理解不取決于它的長度而取決于它是否包含完整的語義單元。除了語義還要關注上下文和metadata。我在實際項目中吃過一個虧一開始切片時沒有保留來源信息結果用戶檢索到一段內容后系統(tǒng)無法給出引用來源哪個文檔、第幾頁導致回答的可信度大打折扣。后來我在每個切片對象里都加上了metadata包括文檔名、章節(jié)路徑、頁碼、切片序號。這樣做還有個額外的好處檢索結果可以做聚合同一個章節(jié)命中的多個切片可以合并去重避免回答時反復重復同一段內容。另外相鄰切片之間要有一定程度的overlap重疊。我常用的設置是切片長度500個token重疊50個token。重疊的部分能讓跨越邊界的語義信息在兩側都能被找到。這個在數組切片里是不存在的概念但在文本切片里非常關鍵。4.3 從切成塊到切得能檢索兩種思路的差別切成塊的思維是我有一整篇文檔我要把它切成若干等長的小塊每個小塊負責存儲文檔的一部分。這種思路的邏輯中心是存儲效率。切得能檢索的思維是用戶會拿問題來匹配切片切片里存儲的內容要盡量和可能的問題對齊。比如用戶問蓋章對合同是否有效能召回未加蓋公章不影響合同效力這個切片不是因為切片恰好包含了蓋章和合同這兩個詞而是因為切片本身是一個完整的法律判斷句。這種思路的邏輯中心是語義可匹配性。兩者差別直接體現(xiàn)在切片設計上。前者關心chunk_size和overlap參數調多大后者關心如何保留標題結構、如何把表頭拼進行、如何按函數邊界切代碼。當你把檢索效果作為衡量標準時切片策略的選擇維度就完全不同了。這也是我在前面反復強調結構信息、表格保真的原因——所有這一切都是為了讓切片在檢索時能被找到。5. 切片質量的評估與調優(yōu)先有衡量標準再調參數5.1 怎么衡量切片好不好三個可落地的指標切片質量不是感覺出來的是可以量化評估的。我實際用下來有三個指標最實用檢索命中率拿一組測試問答對去檢索看正確的切片是否出現(xiàn)在top-k結果里。這是最直接的指標能反映切片和query的匹配程度。切片信息完整度讓人工檢查切片內容看它是否包含完整語義單元比如有沒有被攔腰截斷的句子、有沒有缺失表頭的表格行。切片長度分布統(tǒng)計切片的token數分布是否合理。如果大量切片遠低于設定長度說明切分過于激進語義被切碎了如果大量切片遠超設定長度說明結構切分沒有生效。這三個指標里檢索命中率是最核心的。我建議每個項目在一開始就準備一套三五十條的測試問答對后續(xù)調優(yōu)切片參數時用這套測試集來驗證。5.2 三個典型失敗case與修復過程我整理三個真實調優(yōu)過程中的失敗樣例你大概率也會遇到類似情況Case 1一個章節(jié)被切成了20個小切片用戶問題卻一個都沒命中。排查發(fā)現(xiàn)該章節(jié)是一個連續(xù)的表格被遞歸字符切分器按行切碎每一行只有項目名稱|金額這類殘缺信息。修復方式識別到表格塊時整個表格作為一個切片單元同時把表頭拼進每一行。Case 2Chunk size設太大2000 tokenembedding和檢索速度都慢了而且一個切片里包含太多主題導致query匹配得分被稀釋。修復方式改回500 token但利用章節(jié)標題做分層切片一個章節(jié)內部再按段落切。Case 3切片邊界恰好切在一段規(guī)則的中間前半段是條件、后半段是結論用戶按結論查詢時后半段切片缺少了條件信息回答不完整。修復方式增大重疊窗口同時調整切分邏輯在句號處強制斷開。這類問題在調試時是最耗時的因為報錯不會直接暴露解析和切片的錯誤只會表現(xiàn)為檢索效果差。我的建議是在調模型之前先做一輪切片質量的人工抽檢——隨機抽20個切片看內容是否完整抽50個測試問題看召回是否合理。這一步能省下后面至少一半的調試時間。5.3 我的參數組合與調優(yōu)順序參考給一個我目前在多個項目里驗證過、效果比較穩(wěn)定的起始參數組合參數推薦值說明切片長度500 token足夠承載一個完整段落或表格行組重疊窗口50 token保持跨切片的語義銜接切分邏輯結構優(yōu)先段落/句子次之標題邊界 段落邊界 句子邊界表格處理表頭拼接進每一行保證切片自解釋metadata文檔名、章節(jié)路徑、頁碼用于引用溯源和結果聚合代碼塊按函數/類邊界切保證代碼語義完整調優(yōu)順序上我建議先保證語義完整再調切片長度最后調重疊窗口?？梢韵热斯び^察20個切片的語義完整性如果切片內部語義殘缺優(yōu)先調整切分邏輯而不是長度。語義完整之后再通過測試集調整長度和重疊參數用檢索命中率來驗證。我還想強調一點不同的文檔類型可能需要不同的參數。我接觸過一個項目既有長篇幅的規(guī)章制度又有短小的問題清單用同一套參數跑出來的效果就很差。后來我按文檔類型分流規(guī)章制度用結構切分問題清單直接整體作為一個切片效果提升明顯。這個思路值得你用在自己的項目里。6. 給后來者的一份自查清單6.1 每新增一批文檔先做這三步新增文檔入庫前先花幾分鐘做三件事隨機抽取3到5個文檔人工查看解析出的文本是否完整重點看表格、頁眉頁腳、多欄版面。用一組5到10個測試問題檢查這批文檔內容能否被正確檢索到。這一步能提前發(fā)現(xiàn)問題。抽查切片結果確認沒有半截句子、丟失表頭、代碼被攔腰切斷的情況。我在項目里吃過太多虧都是因為文檔入庫時沒有檢查等到用戶反饋效果差才回頭排查那個時候已經積壓了大量臟數據。再臟的數據也能重新解析但你得先知道它什么時候臟的不然最后只能全量重跑一遍非常痛苦。6.2 解析與切片階段容易忽略的四個細節(jié)最后分享四個實操中很容易忽略的細節(jié)頁眉頁腳需要在解析階段識別并剔除。很多PDF的頁眉是XX公司內部文件如果混入切片會讓所有切片帶上公司名這個噪音詞嚴重干擾embedding的語義區(qū)分度。中文文本的句號、分號、引號都是在切分時值得利用的邊界信號。不要只看長度就切斷要學會利用語言自身的標點符號。切片后要做去重。有些文檔的目錄和正文內容重復目錄部分解析后會生成和正文幾乎一樣的切片這些冗余切片檢索時會被重復召回。始終保留原始文本在切片對象里。embedding向量可以用于檢索但最終展示和回答時仍然需要原始文本。切片對象里保存原始文本后面還有機會做后處理。我做了幾年RAG相關的項目最大的體會是解析和切片這套地基工作做的時候費工夫但能省下后面十倍甚至百倍的調優(yōu)時間。與其在模型和Prompt上反復折騰不如先把這一步做扎實。畢竟地基歪了蓋出來的樓再好看也經不住一次地震。