北京
想象一下，你拿到一份精密的技術規格書，然后拿起剪刀，每五百個詞就咔嚓一刀。不管標題在哪里，不管章節從哪開始到哪結束，也不管一段完整的思路是否被攔腰斬斷。剪完，堆成一摞，編上號，完事。
聽起來很荒唐吧？可這正是許多檢索系統在把文檔送入向量數據庫之前，對它做的事——先肢解，再嘗試理解。我一直對這件事耿耿于懷：我們究竟在用一個多么奇怪的流程對待信息？
當前圍繞檢索增強生成（RAG）的討論中，一個反復出現的問題是：最佳分塊大小是多少？256個詞元？512？要不要讓分塊之間有重疊？在目睹足夠多的檢索翻車之后，我開始覺得，這根本就不是那個該問的問題。真正的問題不是“該在哪里切”，而是“所有文檔是不是都該用同一種切法”。
設想有一份名為“速率限制策略”的技術規格，里面四個部分清清楚楚：為什么要有限速、算法怎么運行、一段代碼示例、還有例外與邊界情況?，F在用固定大小的分塊策略去索引它。標題落在一個塊里，代碼示例掉進另一個塊，邊界情況的解釋又成了第三塊。每個塊被單獨嵌入，變成向量空間里一個個孤零零的點。文字還在，但作為連貫意義單元的文檔，已經消失了。
這時有人提問：“用戶觸發限速后會發生什么？”檢索器精準地返回了包含代碼的那個塊。從它的視角看，一切完美：標識符匹配，嵌入向量很接近，相似度分數很高。但一件重要的事被丟掉了：解釋這段代碼屬于哪一部分的標題在別處，說明算法為何這樣設計的段落也在別處，所有的例外情況都在別處。模型拿到的是有效的代碼，卻被剝奪了讓這些代碼有意義的前因后果。它能說出函數干了什么，卻解釋不了整個系統為什么有那樣的行為。
這引出一個核心觀點：結構本身就是語義。很多人以為文檔結構只是呈現形式上的裝飾，我不這么看。一個標題告訴讀者：下面所有的內容屬于同一個想法。一個章節邊界在說：這個思路到這里結束了。一個列表在說：這些條目應當被一起理解。這些不是視覺點綴，而是信息本身的一部分。當這些信號在索引過程中被抹掉，檢索就丟失了人類閱讀時幾乎不會刻意覺察、卻又全程依賴的線索。
于是我不再問“該怎樣切分這份文檔”，轉而問：“最小的、還能獨自保持意義的單元是什么？”有時它是一個段落，有時是整個小節，有時是代碼塊連同它上方那段解釋，有時是一張圖配它的說明。一份架構決策記錄，往往只有在決策、理由和后果被作為一個整體時才有意義——就像一份技術規格，只有把“為何如此”“如何實現”以及“有什么坑”放在一起時，才能構成真正的認知。
固定的分塊大小假設所有文檔都是同質的，可現實中的信息從來不是豆腐塊，不可能整齊劃一地切完還保持原味。糾結于256還是512詞元，就像在糾結該用多大的碎紙機來粉碎一本小說——越大殘片保留越多，但該散的上下文照樣散。真正需要的是倒過來想：先尊重文檔的結構，再談怎么存。畢竟，當一份規格書被剪成碎片，它的答案就只剩碎片，而我們卻在抱怨大模型給不出完整答案——這多少有點黑色幽默。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
