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