近日，Maria Khalusova在Unstructured官方博客分享了有關分塊的最佳實踐。

Unstructured成立于2022年9月，致力于解決自然語言處理（NLP）和大型語言模型（LLM）應用中的數據預處理問題。公司總部位于美國，專注于將非結構化數據轉化為LLM可以處理的格式，當下流行的pdf解析庫就來自于它們，它們在數據預處理方面擁有非常前沿的技術和經驗。

為什么需要分塊？

出于多種原因，在為 RAG 準備數據時，分塊是必不可少的預處理步驟。

1）上下文窗口限制

首先從基礎開始。檢索到的塊將直接作為上下文輸入到提示中，以便LLM生成響應。這意味著所有檢索到的塊的總長度至少不能超過LLM的上下文窗口。盡管當下許多LLM有相當大的上下文窗口，但實際上并不希望填滿上下文窗口，因為這些LLM會面臨“大海撈針”的問題（延伸閱讀：超長上下文窗口大模型的“照妖鏡”——大海撈針實驗，大模型“打假”必知必會）。另外，開發者可能還想以其他方式利用這個大上下文窗口，比如提供詳細的指令、角色描述或一些少樣本示例（few-shot）。

此外，如果打算使用相似性搜索并嵌入（embedding）文檔，必須考慮到嵌入模型也有一個有限的上下文窗口。這些模型不能嵌入超過其上下文窗口最大長度的文本。這個限制因具體模型而異，但可以在模型的描述中找到這些信息，例如在Hugging Face Hub上的模型卡片上。一旦知道將使用哪種模型來生成嵌入，就能確定文本塊的最大值（以token為單位，而不是字符或單詞）。嵌入模型通常在上下文窗口大小上的最大值約為8K token或更少，這相當于英語中的大約6200個單詞。為了直觀理解有多大，比如，整個《指環王》系列，包括《霍比特人》，大約有576,459個單詞，所以如果想利用這個語料庫進行RAG與相似性搜索，需要將其分成至少93個塊。

2）塊大小對檢索精度的影響

雖然嵌入模型對其可以嵌入的標記數量規定了硬性的最大限制，但這并不意味著分塊必須達到這個長度。這只是意味著它們不能超過這個長度。事實上，在許多情況下，使用每個分塊的最大長度（如 6200 字（8K 標記））可能會過長。這里有幾個令人信服的理由來選擇較小的語塊。

回想一下當我們嵌入一段文本以獲得嵌入向量時會發生什么。大多數嵌入模型都是編碼器類型的轉換器模型，輸入文本的最大長度為 768。不管你給模型的是 10 個字的句子還是 1000 個字的段落，得到的嵌入向量的維度都是一樣的，都是 768。其工作原理是，模型首先將文本轉換為token，在預訓練過程中為每個token學習了一個向量表征。然后，它將應用一個池化操作，將單個token表征平均為一個單向量表征。

常見的池化類型包括：

• CLS池化：特殊CLS token的向量表征成為整個序列的表征
• 平均池化：token向量表征的平均值作為整個序列的表征返回
• 最大池化：具有最大值的token向量表征成為整個序列的表征

其目標是將細粒度的token級表征壓縮成單一的固定長度表征，其中包含整個輸入序列的含義。這種壓縮本身就是有損的。對于較大的塊，表征可能會變得過于粗糙，可能會掩蓋重要的細節。為確保精確檢索，文本塊必須擁有有意義且細致入微的表征。

現在，請考慮另一個潛在問題。一個大塊可能包含多個主題，其中一些可能與用戶查詢相關，而另一些則不相關。在這種情況下，單個向量中每個主題的表示可能會變得模糊，這同樣會影響檢索精度。

另一方面，較小的片段可以保持重點突出的上下文，從而可以更精確地匹配和檢索相關信息。通過將文檔分解成有意義的片段，檢索器可以更準確地找到特定段落或事實，從而最終提高 RAG 性能。那么，在保持上下文完整性的前提下，文件塊可以有多小？這取決于文檔的性質，可能需要進行一些試驗。通常情況下，250 個 token 左右的塊大小（相當于約 1000 個字符）是一個合理的實驗起點。

分塊的常見方法

1）字符級分塊

將大文檔分割成小塊的最基本方法是將文本分成 N 個字符大小的塊。通常在這種情況下，還會指定一定數量的字符，這些字符應在連續的文本塊之間重疊。這在一定程度上降低了句子或觀點在相鄰兩塊之間的邊界被突然切斷的可能性。不過，可以想象，即使有重疊，每個塊的固定字符數加上固定的重疊窗口，也不可避免地會導致信息流中斷、不同主題混合，甚至句子在一個詞的中間被分割。字符分割法完全不考慮文檔結構。

2）句子級分塊或遞歸分塊

字符分割是一種簡單化的方法，完全沒有考慮到文檔的結構。這種方法完全依賴于固定的字符數，經常會導致句子在中途甚至在詞的中間被拆分，效果并不好。

解決這一問題的方法之一是使用遞歸分塊法，這種方法有助于保留單個句子。使用這種方法，您可以指定一個有序的分隔符列表來指導分割過程。例如，以下是一些常用的分隔符：

• "\n\n" - 雙換行符，通常表示段落斷開
• "\n" - 單換行符
• "." - 句號
• " " - 空格

如果按照指定的順序使用上述分隔符，過程將是這樣的。首先，遞歸分塊會在每次出現雙新行（"\n\n"）時分解文檔。然后，如果這些分段仍然超過了所需的分塊大小，它將在新行處進一步分解它們（"\n"），以此類推。

雖然這種方法大大降低了中途斷句的可能性，但仍然無法捕捉到復雜的文檔結構。文檔通常包含多種元素，如段落、章節頁眉、頁腳、列表、表格等，所有這些元素都有助于文檔的整體組織。然而，上述遞歸分塊法主要考慮的是段落和句子，而忽略了其他結構上的細微差別。

此外，文檔以多種本地格式存儲，因此必須為每種不同的文檔類型設計不同的分隔符。上面的列表可能對純文本很有效，但對于標記符，你需要一個更細致、更有針對性的分隔符列表；如果是 HTML 或 XML 文檔，還需要另一個列表，等等。將這種方法擴展到處理 PDF 和 PowerPoint 演示文稿等基于圖像的文檔，會帶來更多復雜性。如果使用場景涉及各種非結構化文檔，那么統一應用遞歸分塊很快就會成為一項繁重的任務。

使用Unstructured智能分塊

這就意味著，你不必再想辦法區分文檔的各個部分。Unstructured 已經完成了這些繁重的工作，直接展示不同的文檔元素，這些元素封裝了文檔中的段落、表格、圖片、代碼片段和其他任何有意義的文本單元。在完成分區步驟后，文檔已經被劃分為更小的片段。這是否意味著文檔已經分塊？不完全是，但已經成功了一半！

分區后得到的某些文檔元素可能仍會超出嵌入模型的上下文窗口或所需的塊大小。這些需要進一步分割。相反，有些文檔元素可能太小，無法包含足夠的上下文。例如，一個列表被分割成單個的 ListItem元素，但你可以選擇將這些元素合并成一個單一的塊，只要它們仍然符合偏好設置的塊大小。

從系統劃分為離散元素的文檔開始，Unstructured 提供的智能分塊策略可以做到這一點：

• 確保信息流不中斷，防止簡單的字符分塊造成的中途分詞。
• 控制塊的最大和最小尺寸。
• 保證不同的主題或想法，如不同主題的獨立章節，不會被合并。

智能分塊比遞歸分塊更進一步，它實際上考慮到了文檔的語義結構和內容。

智能分塊提供了四種策略，它們在保證分塊內容純凈度方面各有不同：

• 基本分塊策略：這種方法可以在遵守最大分塊大小限制的前提下，將連續元素組合起來，最大限度地填充每個分塊。如果單個孤立的元素超過了最大硬限制，就會被分成兩個或更多塊。
• 按標題分塊策略：該策略利用分區過程中識別的文檔元素類型來理解文檔結構，并保留章節邊界。這就意味著，單個數據塊永遠不會包含出現在兩個不同章節中的文本，從而確保主題保持自足，提高檢索精度。
• 按頁面分塊策略（僅支持API調用）：該策略專為每一頁都能傳遞獨特信息的文檔而設計，可確保來自不同頁面的內容絕不會混雜在同一個分塊中。當檢測到一個新頁面時，即使下一個元素可以放在之前的內容塊中，也會完成現有的內容塊并開始一個新的內容塊。
• 按相似性分塊策略（僅支持API調用）：當文檔結構無法提供明確的主題邊界時，可以使用 "通過相似性 "策略。該策略使用 "sentence-transformers/multi-qa-mpnet-base-dot-v1 "嵌入模型來識別在主題上相似的順序元素，并將它們組合成塊。

Unstructured 智能分塊策略的另一個優勢是可普遍適用于各種文檔類型。不需要像遞歸分塊那樣，為每個文檔硬編碼和維護分隔符列表。可以輕松嘗試分塊大小和分塊策略，為任何給定的使用場景找出最佳方案。

結論

分塊是任何 RAG 系統中必不可少的預處理步驟之一。設置時的選擇會影響檢索質量，進而影響系統的整體性能。以下是設計分塊步驟時需要注意的一些事項：

• 嘗試不同的塊大小：雖然大塊可能包含更多上下文，但也會導致表述粗糙，對檢索精度產生負面影響。最佳塊大小取決于文檔的性質，但要在不丟失重要上下文的情況下優化較小的塊。
• 利用巧妙的分塊策略：選擇分塊策略，在有語義意義的邊界上分隔文本，避免信息流中斷或內容混雜。
• 評估分塊選擇對 RAG 整體性能的影響：為您的特定用例設置評估集，并跟蹤分塊大小和分塊策略實驗對整體性能的影響。無論文檔類型如何，您只需調整一兩個參數，非結構化技術就能簡化分塊實驗。

原文：https://unstructured.io/blog/chunking-for-rag-best-practices

本文轉載自?? AI工程化??，作者：ully