生產環境裡 RAG 的真正故障都是 chunking 故障，修法是按文件類型來分流

本週 Towards Data Science 上，Priyansh Bhardwaj 的一篇實務文章把一件事講清楚了：生產環境裡絕大多數 RAG 故障，其實是 chunking 故障，不是檢索或生成故障。全文的錨句很好引：「LLM 不是瓶頸。瓶頸在於「上一塊在哪裡結束、下一塊從哪裡開始」這個決定。」文章沒有停在抽象論證層面，而是給出四種具體故障模式和一套按文件類型來切塊、可量化的改進。任何上過線、見過 RAG 系統回傳「技術上說得通但就是不對」答案的人，看到這四種故障都會眼熟。

Bhardwaj 點出的四種模式都常見，都費時間去除錯。邏輯邊界被切開是其中最糟糕的一種：一塊在「承包商遵循第 4 節所述的標準入職流程」這裡斷掉，下一塊從「除非被安排到被歸入附件 B 的專案」開始，兩個片段單獨看都是錯的，而檢索器可能永遠不會把它們拼回去。固定長度的 token 視窗（512 token + 50 token 重疊那一套，還活在太多 stack 裡）對著「三段話的例外說明」或者「編號清單的第四步」照切不誤，因為它根本不看結構。表格被壓平之後，就成了一長串脫離了表頭的孤立數值。再加上不看 layout 的 PDF 擷取，上面所有問題會疊加放大，因為底層文本流已經和作者所依賴的視覺結構對不上了。

建議的解法既不性感，也剛剛好對。按文件類型分流。結構化文件（spec、runbook）用階層式切塊加 AutoMergingRetriever。敘事類內容（政策、指南、說明性文字）用 SentenceWindowNodeParser 配 3 句話的上下文視窗。混合或非結構化內容用語義切塊，並且誠實地把「延遲代價」說清楚。PDF 和簡報要先用 PyMuPDF 或 pdfplumber 做 layout 感知的預處理，再進 chunking。Bhardwaj 給出的敘事類文件基準升級結果不花俏但真：只是讓切塊器對上文件形態，context recall 從 0.72 升到 0.88，context precision 從 0.71 升到 0.83。這就是當你不再把 RAG 當作模型問題、而開始把它當作內容工程問題時，會拿到的那種數字。

如果你的 RAG 系統在生產環境中，而且你從來沒把 chunking 當作故障來源做過埋點，那就應該從這裡開始查。具體動作：抽 50 條最近被答錯或答得很薄的查詢，手工讀一遍被檢索回來的那些 chunk，統計有多少根本從切塊邊界那一步就註定失敗，不管你後面用哪個模型做生成。這個數字，幾乎永遠比團隊預想的大。第二步是別再把你整個語料當成同質的；按文件類型分流，因為那個適合 200 頁政策 PDF 的切塊器，肯定不適合一個以表格為主的 SKU 目錄。這一篇和昨天那篇 memweave 是一對：兩篇都在從不同角度講同一個更大的觀點。那些看起來最刺激的基礎設施決定，譬如換更大的向量庫、換更新的模型、換更長的上下文，多半不是你家品質問題真正住的地方。那些「怎麼把資料切、怎麼把資料建索引」的無聊選擇，才是。