現在您已經收集了測試文件和查詢，並在準備階段執行了文件分析，下一階段擇要進行分塊。 將文件分解為大小合適的區塊集合，每個區塊都包含語義相關的內容，這是檢索增強生成 (RAG) 實作成功的關鍵因素。 傳遞整個文件或超大區塊的成本很高，可能會超出模型的標記限制，並且不會產生最佳結果。 將資訊傳遞至與查詢無關的語言模型，可能會導致幻覺。 您需要最佳化傳遞相關資訊並刪除不相關資訊的流程。 您可以透過使用有效的分塊和搜尋策略來進行這種最佳化，以最小化假陽性和假陰性，同時最大化真陽性和真陰性。
傳遞過小且缺乏足夠上下文來處理查詢的區塊也會導致結果不佳。 可能無法擷取跨多個區塊存在的相關上下文。 技術是針對您的特定文件類型及其結構和內容實作有效的分塊方法。 有多種分塊方法可供考慮，每種方法都有自己的成本影響和有效性，這取決於它們所應用的文件的類型和結構。
本文介紹了各種分塊方法，並研究了文件的結構如何影響您選擇的分塊方法。
本文是系列文章的一部分。 閱讀簡介。
分塊經濟學
在確定整體分塊策略時，您必須考慮預算以及文件語料庫的品質和吞吐量要求。 每個獨特的分塊實施的設計和實施都有工程成本，每個文件的處理成本也根據方法的不同而不同。 如果您的文件具有嵌入或連結的媒體，您必須考慮處理這些元素的經濟性。 對於分塊，該處理通常使用語言模型來產生媒體的描述，然後對這些描述進行分塊。 另一種帶有媒體的替代方法是在推斷時，將它們原樣傳遞給多模態模型，但這種方法不會影響分塊的經濟性。
本節研究分塊影像和整體解決方案的經濟性。
影像分塊經濟學
使用語言模型產生影像描述然後對其進行分塊是有成本的。 例如，Azure OpenAI 等基於雲端的服務要么按每筆交易基本收費，要么按預付費設定收費。 較大的影像會產生較大的成本。 透過文件分析，您應該確定哪些影像對分塊有價值以及哪些影像應該忽略。 接下來，您需要了解解決方案中影像的數量和大小，並且應該權衡影像描述分塊的價值與生成這些描述的成本。
確定要處理哪些影像的一種方法是使用 Azure AI 視覺等服務對影像進行分類、標記影像或進行標誌偵測。 然後，您可以使用結果和信賴度指標來確定影像是否增加了有意義的上下文值，並決定是否進行處理。 對 Azure AI 視覺的呼叫可能比對語言模型的呼叫成本更低，因此這種方法可以節省成本。 您需要進行試驗，以確定哪些信賴水準以及哪些分類或標籤能為您的資料提供最佳結果。 另一種選擇是建立您自己的分類器模型。 您需要考慮建立、託管和維護自己的分類器模型的成本。
另一個成本最佳化是使用另行快取模式進行快取。 您可以根據影像的雜湊值產生金鑰。 第一步，您可以檢查是否有來自先前執行或已處理文件的快取結果。 如果有，則您可以使用該結果。 這種方法可以讓您避免呼叫分類器或語言模型所產生的成本。 如果沒有快取，當您呼叫分類器或語言模型時，您將快取結果。 以後對該影像的呼叫將使用快取。
一個能簡單整合這些成本最佳化流程的工作流程如下：
- 檢查影像處理是否被快取。 如果有，請使用快取的結果。
- 執行分類器以確定是否應該處理影像。 快取分類結果。 只有當分類邏輯告訴您這樣做時，才繼續進行。
- 產生影像的描述。 快取結果。
整體解決方案的經濟性
在考慮整體解決方案的成本時，需要考慮以下因素：
- 唯一的分塊實作數量 - 每個唯一的實作都有其工程和維護成本。 您需要考慮語料庫中唯一文件類型的數量，以及每個獨特實作的成本與品質之間的權衡。
- 每個實作的文件成本 - 某些分塊方法可能會產生品質更好的區塊，但產生這些區塊的財務和時間成本更高。 例如，在 Azure AI 文件智慧服務服務中使用預建模型的每文件成本，可能比純文字剖析實作更高，但可能會產生更好的區塊。
- 初始文件數量 - 啟動解決方案所需處理的初始文件數量。
- 增量文件的數量 - 為持續維護系統而必須處理的新文件數量和速率。
載入和分塊
從邏輯上講，在分塊期間，必須先將文件以某種格式載入到記憶體中。 然後分塊程式碼針對文件的記憶體表示進行操作。 您可以選擇將載入程式碼與分塊結合起來，也可以將載入分離到自己的階段。 您選擇的方法應該在很大程度上基於架構限制和您的偏好。 本節簡要探討這兩個選項，然後為您提供一些一般性建議。
單獨加載和分塊
您可能會出於多種原因選擇將載入階段和分塊階段分開。 您可能希望將邏輯封裝在載入程式碼中。 您可能希望在分塊之前保留載入程式碼的結果，特別是在嘗試各種分塊排列以節省處理時間或成本時。 最後，出於架構原因，您可能希望在單獨的程序中執行載入和分塊程式碼，例如程序隔離或涉及刪除 PII 的安全分段。
將邏輯封裝在載入程式碼中
您可以選擇在載入階段封裝預先處理邏輯。 這簡化了分塊程式碼，因為它不需要進行任何預先處理。 預先處理可以簡單到刪除或註釋您在文件分析中確定要忽略的部分，例如浮水印、頁首和頁尾，或複雜到重新格式化文件。 以下是您可能選擇在載入階段封裝的一些預先處理範例：
- 刪除或註釋您想要忽略的項目。
- 將影像參考替換為影像描述。 在此階段，您使用 LLM 產生影像的描述並使用該描述更新文件。 如果您在文件分析中確定周圍的文字為影像提供了有價值的上下文，請將其與影像一起傳遞給法學碩士。
- 將影像下載或複製到文件儲存 (例如 Azure Data Lake)，以便與文件文字分開處理。 如果您在文件分析中確定周圍的文字為影像提供了有價值的上下文，則需要將此文字與影像一起儲存在檔案儲存體中。
- 重新格式化表格，使其更容易處理。
保存載入程式碼的結果
您可能會出於多種原因選擇保留載入程式碼的結果。 原因之一是，如果您希望能夠在載入和預先處理文件之後、執行分塊邏輯之前檢查文件。 另一個原因是，您可能希望在開發或生產流程中，針對相同的預先處理程式碼執行不同的分塊邏輯。 保留載入的程式碼可以加快此流程。
在單獨的程序中執行載入和分塊程式碼
將載入和分塊程式碼分離到單獨的程序中有助於針對相同的預先處理程式碼執行多個分塊實作。 這種分離還允許您在不同的計算環境和不同的硬體上執行載入和分塊程式碼。 此外，這種設計允許您獨立擴展用於載入和分塊的計算。
結合加載和分塊
在大多數情況下，將載入和分塊程式碼結合起來是一種更簡單的實作。 您可能會考慮在單獨的載入階段進行預先處理的許多操作都可以在分塊階段完成。 例如，分塊邏輯可以呼叫 LLM 來取得文字描述並對描述進行分塊，而不是在載入階段用描述取代圖片 URL。
當您的文件格式 (例如 HTML) 具有引用影像的標籤時，您需要確保分塊程式碼所使用的閱讀器或剖析器不會刪除標籤。 分塊代碼需要能夠識別影像引用。
建議
以下是在決定是組合還是分離分塊邏輯時需要考慮的一些建議。
- 從組合載入和分塊邏輯開始。 當您的解決方案需要時將它們分開。
- 如果您選擇分離程序，請避免將文件轉換為中間格式。 諸如此類的操作可能是有損的。
分塊法
本節概述了一些常見的分塊方法。 此清單並不詳盡，而是一些常見的代表性方法。 您可以在實作中使用多個方法，例如結合語言模型的用法，以取得影像的文字表示法與許多列出的方法。
每種方法都附有一個總結的決策矩陣，突出顯示了工具、相關成本等。 工程工作和處理成本是主觀的，包括在內是為了進行相對比較。
基於句子的句法分析
這種簡單的方法將文字文件分解為由完整句子組成的區塊。 這種方法的優點包括實施成本低、處理成本低，並且可以應用於任何以散文或完整句子編寫的基於文字的文件。 這種方法的一個挑戰是每個區塊可能無法捕捉思想或意義的完整上下文。 通常，必須將多個句子放在一起才能擷取語義。
工具：SpaCy 句子標記化工具、LangChain 遞迴文字分隔器、NLTK 句子標記化工具
工程工作量：低
處理成本：低
使用案例：處理以散文或完整句子寫成的非結構化文件，且您的文件語料庫包含過多不同文件類型，無法為每種類型建立個別的分塊策略。
範例：使用者生成的內容，例如來自問卷的開放式意見反應、論壇貼文、評論、電子郵件、小說或論文
固定大小剖析 (具有重疊)
這種方法會根根據固定數量的字元或標記將文件分解為區塊，並允許區塊之間存在一些字元重疊。 這種方法與句子式剖析有許多相似的優點和缺點。 與句子式剖析相比，這種方法的一個優點是可以獲得具有跨越多個句子的語義區塊。
您必須選擇區塊的固定大小和重疊量。 由於不同文件類型的結果各不相同，因此最好使用像 HuggingFace 的區塊視覺化檢視進行探索性分析。 此類工具可讓您根據您的決定，直觀地了解文件的分塊情況。 使用固定大小的剖析時，最佳做法是使用 BERT 標記而不是字元計數。 BERT 標記是以有意義的語言單元為基礎，因此它們比字元計數保留了更多的語義資訊。
工具：LangChain 遞迴文字分隔器、Hugging Face 區塊視覺化檢視
工程工作量：低
處理成本：低
使用案例：處理以散文或非散文形式撰寫的非結構化文件，包括完整或不完整的句子。 您的文件語料庫包含過多不同的文件類型，以至於無法為每種類型建立個別的分塊策略。
範例：使用者生成的內容，例如來自問卷的開放式意見反應、論壇貼文、評論、電子郵件、個人或研究筆記或清單
自訂程式碼
此方法會使用自訂程式碼來剖析文件，以建立區塊。 這種方法在以文字為基礎的文件中最為成功，尤其是當文件結構已知或可以推斷，並且需要對區塊建立進行高度控制。 您可以使用文字剖析技術 (如規則運算式) 來根據文件結構中的模式建立區塊。 目標是建立長度相似且具有不同內容的區塊。 許多程式語言都支援規則運算式的，有些還提供了具有更優雅字串操作功能的程式庫或套件。
工具：Python (re、regex、BeautifulSoup、lxml、html5lib、marko)、R (stringr、xml2)、Julia (Gumbo.jl)
工程工作量：中等
處理成本：低
使用案例：可以推斷結構的半結構化文件
範例：專利申請、研究論文、保險單、腳本和劇本
語言模型增強
語言模型可用來建立區塊。 常見的使用案例是使用大型語言模型 (例如 GPT-4) 來產生可用作區塊的影像的文字表示或表格的摘要。 語言模型擴充會與其他區塊化方法搭配使用，例如自定義程序代碼。
如果您在檔分析區段的 影像部分中判斷 影像之前或之後的文字必須回答一些問題，則必須將此額外的內容傳遞至語言模型。 請務必進行實驗，以確定這些額外的上下文是否能夠提高解決方案的效能。
如果您的分塊邏輯將影像描述拆分為多個區塊，請確保在每個區塊中包含影像 URL。 在每個區塊中包含影像 URL 可確保為影像服務的所有查詢都傳回中繼資料，特別是對於終端使用者需要能夠透過該 URL 存取來源影像，或希望在推理期間使用原始影像的情況。
工具：Azure OpenAI、OpenAI
工程工作量：中等
處理成本：高
使用案例：影像、表格
範例：產生表格和影像的文字表示，總結會議、演講、訪談或播客的文字記錄
文件版面配置分析
文件版面配置分析庫和服務將光學字元辨識 (OCR) 功能與深度學習模型相結合，以提取文件和文字的結構。 結構元素可以包括頁首、頁尾、標題、章節標題、表格和圖形。 目標是為文件中包含的內容提供更好的語義。
文件版面分析庫和服務公開了一個表示文件內容 (結構和文字) 的模型。 您仍然需要編寫與模型互動的程式碼。
注意
Azure AI 文件智慧服務是一項基於雲端的服務，要求您將文件上傳到該服務。 您需要確保您的安全和合規法規允許您將文件上傳到此類服務。
工具：Azure AI 文件智慧服務文件分析模型、Donut、版面配置剖析器
工程工作量：中等
處理成本：中
使用案例：半結構化文件
範例：新聞文章、網頁、履歷
預建模型
有些服務 (例如 Azure AI 文件智慧服務) 提供了可用於各種文件類型的預建模型。 有些模型針對特定文件類型 (例如美國稅務 W-2 表格) 進行訓練，而其他模型則針對更廣泛的文件類型 (例如發票)。
工具：Azure AI 文件智慧服務預建模型、Power Automate 智慧文件處理、LayoutLMv3
工程工作量：低
處理成本：中/高
使用案例：存在預建模型的結構化文件
具體範例：發票、收據、健保卡、W-2 表格
自訂模型
對於不存在預建模型的高度結構化文件，您可能需要建立一個自訂模型。 這種方法對於高度結構化的影像或文件可能非常有效，這使得它們難以使用文字剖析技術。
工具：Azure AI 文件智慧服務自訂模型、Tesseract
工程工作量：高
處理成本：中/高
使用案例：不存在預建模型的結構化文件
範例：汽車維修和保養計劃、學術成績單和記錄、技術手冊、操作程序、維護指南
文件結構
文件的結構數量各不相同。 有些文件 (例如政府表格) 具有複雜且眾所周知的結構，例如 W-2 美國稅務文件。 另一方面是非結構化文件，例如自由格式的筆記。 文件類型的結構程度是決定有效分塊方法的良好起點。 雖然沒有硬性規定，但本節為您提供了一些需要遵循的準則。
依文件結構顯示分塊方法的圖表。
圖 1. 分塊方法適合文件結構
結構化文件
結構化文件 (有時稱為固定格式文件) 具有已定義的版面配置。 這些文件中的資料位於固定位置。 例如，日期或客戶姓氏可以在相同固定格式的每個文件的相同位置找到。 固定格式文件的範例包括 W-2 美國稅務文件。
固定格式文件可能是手寫原始文件的掃描影像，或具有複雜的版面配置結構，這使得它們難以使用基本的文字解析方法進行處理。 處理複雜文件結構的常見方法是使用機器學習模型來提取資料，並在可能的情況下將語義套用於該資料。
範例：W-2 表格、保險卡
常見方法：預建模型、自訂模型
半結構化文件
半結構化文件沒有固定的格式或模式，如 W-2 表單，但它們確實提供了格式或模式的一致性。 例如，所有發票的版面配置並不相同，但是，通常它們具有一致的架構。 您可以預期發票會包含 invoice number，以及某種形式的 bill to 和 ship to 名稱和地址，還有其他資料。 網頁可能不具有架構一致性，但它們具有相似的結構或版面配置元素，例如 body、title、H1 和 p，這些元素可以用來為周圍的文字新增語義意義。
與結構化文件一樣，具有複雜版面配置結構的半結構化文件很難透過文字剖析進行處理。 對於這些文件類型，機器學習模型是一個很好的方法。 對於某些具有一致模式的領域 (如發票、合約或健康保險) 有預建模型。 考慮為不存在預建模型的複雜結構建立自訂模型。
範例：發票、收據、網頁、Markdown 檔案
常用方法：文件分析模型
推斷結構
有些文件具有結構，但不是用標記編寫的。 對於這些文件，必須推斷其結構。 以下歐盟法規文件就是一個很好的例子。
該圖顯示了歐盟法規作為具有推斷結構的文件範例。
圖 2. 歐盟法規顯示了推斷的結構
因為您可以清楚地了解文件的結構，並且沒有已知的模型，所以您可以確定您可以編寫自訂程式碼。 此類文件格式可能無法保證建立自訂模型的努力，具體取決於您正在使用的此類不同文件的數量。 例如，如果您的語料庫全部是歐盟法規或美國州法律，那麼自訂模型可能是個好方法。 如果您使用單一文件 (例如範例中的歐盟法規)，則自訂程式碼可能更具成本效益。
範例：法律文件、腳本、製造規範
常見方法：自訂程式碼、自訂模型
非結構化文件
對於幾乎沒有結構的文件，一個好的方法是基於句子或固定大小的重疊方法。
範例：使用者生成的內容，例如來自問卷的開放式意見反應、論壇貼文或評論、電子郵件以及個人或研究筆記
常見方法：基於句子或基於邊界的重疊
測試
儘管列出了每種分塊方法的最佳選擇，但實際上，任何方法都可能適合任何文件類型。 例如，基於句子的剖析可能適合高度結構化的文件，或者自訂模型可能適合非結構化文件。 最佳化 RAG 解決方案的一部分是嘗試各種分塊方法，同時考慮您擁有的資源數量、資源的技術技能以及必須處理的文件量。 為了實現最佳的分塊策略，您需要觀察您測試的每種方法的優點和權衡，以確保您為您的使用案例選擇合適的方法。