共用方式為

建置RAG的非結構化數據管線

本文說明如何建置 Gen AI 應用程式的非結構化數據管線。 非結構化管線特別適用於 Retrieval-Augmented 產生 （RAG） 應用程式。

瞭解如何將文本檔和 PDF 等非結構化內容轉換成 AI 代理程式或其他擷取程式可以查詢的向量索引。 您也會瞭解如何實驗和微調管線，以優化區塊化、編製索引和剖析數據，讓您對管線進行疑難解答和實驗，以取得更好的結果。

非結構化資料流程筆記本

下列筆記本說明如何實作本文中的資訊，以建立非結構化數據管線。

Databricks 非結構化數據管線

拿筆記本

資料管線的主要元件

任何具有非結構化資料之 RAG 應用程式的基礎都是資料管線。 此管線負責以RAG應用程式可以有效使用的格式策劃和準備非結構化數據。

RAG 資料管線基本元件的圖表。

雖然根據使用案例，此數據管線可能會變得複雜，但以下是您在第一次建置 RAG 應用程式時需要考慮的重要元件：

  1. Corpus 組合和擷取：根據特定使用案例選取正確的數據源和內容。
  2. 數據前置處理：將原始數據轉換成適合內嵌和擷取的全新一致格式。
    1. 剖析：使用適當的剖析技術從原始數據擷取相關信息。
    2. 擴充：使用其他元數據擴充數據並移除雜訊。
      1. 元數據擷取：擷取有用的元數據，以實作更快速且更有效率的數據擷取。
      2. 重複資料刪除：分析檔以識別並消除重複或近乎重複的檔。
      3. 篩選：從集合中排除無關或不必要的檔。
  3. 區塊化：將剖析的數據細分為較小的可管理區塊，以有效率地擷取。
  4. 內嵌：將區塊化文字數據轉換成可擷取其語意意義的數值向量表示法。
  5. 索引和記憶體：為優化搜尋效能建立有效率的向量索引。

Corpus 組合和匯入

您的RAG應用程式無法擷取在沒有正確數據主體的情況下回應用戶查詢所需的資訊。 正確的數據完全取決於應用程式的特定需求和目標，因此請務必花時間瞭解可用數據的細微差別。 如需詳細資訊，請參閱 Generative AI 應用程式開發人員工作流程。

例如，建置客戶支援機器人時，您可能會考慮包含以下內容：

  • 知識庫文件
  • 常見問題集 (FAQ)
  • 產品手冊和規格
  • 疑難排解指南

從任何專案一開始就與領域專家和專案關係人互動，以協助識別及策劃可改善數據主體品質和涵蓋範圍的相關內容。 他們可以提供使用者可能提交之查詢類型的深入解析，並協助排定要包含的最重要資訊優先順序。

Databricks 建議您以可調整且累加的方式內嵌數據。 Azure Databricks 提供各種數據擷取方法，包括 SaaS 應用程式和 API 整合的完全受控連接器。 最佳做法是，原始源數據應該擷取並儲存在目標數據表中。 此方法可確保數據保留、可追蹤性和稽核。 請參閱 Lakeflow Connect 中的標準連接器。

數據前置處理

擷取數據之後，必須清除原始數據，並將原始數據格式化成適合內嵌和擷取的一致格式。

剖析

識別擷取器應用程式的適當數據源之後，下一個步驟是從原始數據擷取所需的資訊。 此程式稱為剖析，牽涉到將非結構化數據轉換成RAG應用程式可以有效使用的格式。

您使用的特定剖析技術和工具，取決於處理的資料類型。 例如：

  • 文字文件 (PDF、Word 檔案)：非結構化和 PyPDF2 等現成的程式庫可處理各種檔案格式，並提供自訂剖析流程的選項。
  • HTML 檔案： HTML 解析函式庫，例如 BeautifulSoup 和 lxml，可用來從網頁擷取相關內容。 這些連結庫可協助流覽 HTML 結構、選取特定元素，以及擷取所需的文字或屬性。
  • 影像和掃描的檔： 光學字元辨識（OCR）技術通常需要從影像中擷取文字。 熱門 OCR 連結庫包括開放原始碼連結庫，例如 Tesseract 或 SaaS 版本，例如 Amazon Textract、Azure AI 視覺 OCR，以及 Google Cloud Vision API。

剖析資料的最佳做法

剖析可確保數據乾淨、結構化且已準備好內嵌產生和向量搜尋。 剖析資料時，請考慮下列最佳做法：

  • 數據清除： 預先處理擷取的文字，以移除無關或嘈雜的資訊，例如頁首、頁尾或特殊字元。 減少RAG鏈結需要處理的不必要或格式不正確的信息數量。
  • 處理錯誤和例外：實作錯誤處理和記錄機制，識別及解決剖析流程遇到的任何問題。 這可協助您快速找出並修正問題。 這個方法通常指向來源資料品質的上游問題。
  • 自訂剖析邏輯：視資料的結構和格式而定，您可能必須自訂剖析邏輯，才能擷取最相關的資訊。 雖然它可能需要事先進行額外的工作，但請視需要投入時間來執行此動作，因為它經常會防止許多下游質量問題。
  • 評估剖析品質： 手動檢閱輸出範例，即可定期評估已剖析資料的品質。 這個作法協助您在剖析流程識別有改善空間的任何問題或領域。

擴充

使用其他元數據擴充數據，並移除雜訊。 雖然擴充是選擇性的，但它可以大幅改善應用程式的整體效能。

元數據擷取

產生和擷取捕捉文件內容、背景和結構關鍵信息的元數據，可以顯著提升RAG應用程式的檢索品質和效能。 元數據提供可改善相關性、啟用進階篩選和支援特定網域搜尋需求的其他訊號。

雖然像 LangChain 和 LlamaIndex 的程式庫提供內建的剖析器，可以自動擷取關聯的標準元數據，但通常情況下，使用專為特定使用案例量身定制的自定義元數據進行補充會更有幫助。 此方法可確保擷取重要的領域特定資訊，以改善下游擷取和產生。 您也可以使用大型語言模型 （LLM） 來自動化元數據增強功能。

中繼資料的類型包括：

  • 檔層級元數據： 檔名、URL、作者資訊、建立和修改時間戳、GPS 座標和檔版本設定。
  • 以內容為基礎的元數據： 擷取的關鍵詞、摘要、主題、具名實體和特定領域的標籤（如 PII 或 HIPAA 的產品名稱和類別）。
  • 結構元數據： 區段標頭、目錄、頁碼和語意內容界限（章節或子區段）。
  • 關係型元數據： 來源系統、擷取日期、數據敏感度層級、原始語言或跨國指示。

將元數據與區塊化檔或其對應的內嵌一起儲存，對於最佳效能至關重要。 它也有助於縮小擷取的資訊範圍，並改善應用程式的精確度和延展性。 此外，將元數據整合到混合式搜尋管線中，這表示將向量相似度搜尋與關鍵詞型篩選相結合，可以增強相關性，特別是在大型數據集或特定搜尋準則案例中。

重複資料刪除

視您的來源而定，您最終可能會有重複的文件或近似重複的文件。 例如，如果您從一或多個共用磁碟驅動器提取，相同檔的多個復本可能會存在於多個位置。 其中有些復本可能會有細微的修改。 同樣地，您的知識庫可能會有產品檔副本或部落格文章草稿複本。 如果這些重複資料保留在您的語料庫中，您最終可能會有高度重複的區塊，這可能降低應用程式的性能。

您可以僅使用元數據來消除某些重複項目。 例如，如果專案具有相同的標題和建立日期，但來自不同來源或位置的多個專案，您可以根據元數據來篩選這些專案。

不過，這可能還不夠。 為了協助根據文件的內容識別和消除重複專案，您可以使用稱為地區敏感性哈希的技術。 具體而言，MinHash 的技術在這裡運作良好，Spark 實作已在 Spark ML中使用。 其運作方式是根據文件所包含的單詞建立文件的哈希，然後透過匹配這些哈希，有效率地識別重複文件或接近重複文件。 概括而言，這是一個四個步驟的過程：

  1. 為每個檔建立特徵向量。 如有需要，請考慮採用去除停止詞、詞幹分析、詞形還原等技術來改善分析結果，然後進行詞元化為 n-gram。
  2. 針對 Jaccard 距離 ，使用MinHash 來調整 MinHash 模型並哈希向量。
  3. 使用這些哈希執行相似度聯結，針對每個重複或近乎重複的檔產生結果集。
  4. 篩選掉您不想保留的重複專案。

基本的重複資料排除步驟可以選擇任意保留的文件（例如，選擇每個重複項目結果中的第一個文件，或在重複項中隨機選擇一個）。 可能的改進是使用其他邏輯來選取重複的「最佳」版本（例如最近更新、發行狀態或最權威的來源）。 此外，請注意，您可能需要實驗特徵化步驟和 MinHash 模型中所使用的哈希表數目，以改善比對結果。

如需詳細資訊，請參閱 Spark 文檔，了解 區域敏感哈希。

篩選

您匯入到語料庫的某些檔案可能無法為您的人工智能提供幫助，因為它們可能與用途無關、過於陳舊或不可靠，或者因為內容存在問題，例如具攻擊性或傷害性的語言。 然而，其他檔可能包含您不想透過代理人公開的敏感資訊。

因此，請考慮在流程中包含一個步驟，使用任何元數據來篩選出這些文件，例如將毒性分類器應用到文件上，以生成您可以用作篩選的預測。 另一個範例是將個人標識資訊 （PII） 偵測算法套用至檔以篩選檔。

最後，您提供給代理程式的任何檔來源都是惡意執行者啟動數據中毒攻擊的潛在攻擊媒介。 您也可以考慮新增偵測和篩選機制，以協助識別和消除這些機制。

區塊化

為向量索引將文件資料區塊化的圖表。

將原始數據剖析成更結構化的格式、移除重複專案，以及篩選掉不必要的信息之後，下一個步驟是將其分解成較小的可管理單位，稱為區塊。 將大型檔分割成較小的語意集中區塊，可確保擷取的數據符合 LLM 的內容，同時將干擾或無關的資訊納入降至最低。 對區塊化所做的選擇將直接影響 LLM 所提供的擷取數據，使其成為 RAG 應用程式中的第一個優化層之一。

將資料區塊化時，請考慮下列因素：

  • 區塊化策略：您用來將原始文字分割成區塊的方法。 這可以牽涉到基本技術，例如依句子、段落、特定字元/標記計數，或更進階的文件特定的分割策略。
  • 區塊大小： 較小的區塊可能會專注於特定詳細數據，但遺失一些相關的內容資訊。 較大的區塊可能會擷取更多內容，但可能包含無關的資訊，或計算成本高昂。
  • 區塊重疊：為了確保將資料分割成區塊時不會損失重要資訊，請考慮讓相鄰區塊部分重疊。 重疊可確保跨區塊的持續性和內容保留，並改善擷取結果。
  • 語意一致性： 盡可能建立語意連貫的區塊，其中包含相關信息，但可以獨立作為有意義的文字單位。 為此，您可以考慮原始資料的結構，例如段落、區段或主題邊界。
  • 元數據：相關的元數據，例如源文檔名稱、區段標題或產品名稱，可以改善擷取。 這項額外資訊有助於比對擷取查詢與區塊。

資料區塊化策略

尋找適當的區塊化方法既是反覆的，又取決於上下文。 沒有一種通用的方法。 最佳區塊大小和方法取決於所處理數據的特定使用案例和本質。 大致上，區塊化策略可視為下列各項：

  • 固定大小的區塊化：將文字分割成預先決定大小的區塊，例如固定的字元數或權杖數 (例如 LangChain CharacterTextSplitter)。 雖然以任意數目的字元/令牌分割是快速且容易設定的，但通常不會產生一致的語意連貫區塊。 這種方法很少適用於生產等級的應用程式。
  • 以段落為基礎的區塊化：使用文字的自然段落邊界定義區塊。 此方法有助於保留區塊的語意一致性，因為段落通常包含相關信息（例如 LangChain RecursiveCharacterTextSplitter）。
  • 格式特定區塊處理： Markdown 或 HTML 等格式具有可以定義區塊界限的固有結構（例如 Markdown 標頭）。 LangChain 的 MarkdownHeaderTextSplitter 或 HTML 標頭/區段型分隔器等工具可用於此用途。
  • 語意區塊化： 主題模型化等技術可以套用，以識別文字中的語意連貫區段。 這些方法會分析每個文件的內容或結構，以根據主題轉變來判斷最適當的區塊界限。 雖然比基本方法更涉及，但語意區塊化有助於建立更符合文字中自然語意分割的區塊（例如，請參閱 LangChain SemanticChunker。

範例：大小固定的區塊化

顯示文件大小固定區塊化範例的影像。

使用 LangChain 的 RecursiveCharacterTextSplitter 搭配 chunk_size=100 和 chunk_overlap=20 的固定大小區塊化範例。 ChunkViz 提供互動式方式，以可視化方式可視化不同區塊大小和區塊重疊值與 Langchain 的字元分隔器如何影響產生的區塊。

嵌入

資料區塊如何根據語意意義向量化的圖表。

將資料區塊化之後，下一個步驟是使用內嵌模型，將文字區塊轉換為向量表示法。 內嵌模型會將每個文字區塊轉換成可擷取其語意意義的向量表示法。 藉由將區塊表示為密集向量，內嵌可根據擷取查詢的語意相似性，快速且準確地擷取最相關的區塊。 擷取查詢會在查詢時使用用來在數據管線中內嵌區塊的相同內嵌模型來轉換。

選取內嵌模型時，請考慮下列因素：

  • 模型選擇： 每個內嵌模型都有細微差別，而且可用的基準檢驗可能無法擷取數據的特定特性。 選取已針對類似數據定型的模型非常重要。 您也可以探索專為特定工作設計的可用內嵌模型。 實驗不同的現成內嵌模型，甚至是標準排行榜排名可能較低的模型，例如 MTEB。 要考慮的一些範例：
  • 最大令牌： 知道所選的嵌入模型的最大令牌限制。 如果您傳遞超過此限制的區塊，這些區塊將會遭到截斷，可能會遺失重要資訊。 例如，bge-large-en-v1.5 的令牌限制上限為 512。
  • 模型大小： 較大的內嵌模型通常會執行得更好，但需要更多計算資源。 根據您的特定使用案例和可用的資源，您必須平衡效能和效率。
  • 微調： 如果您的 RAG 應用程式處理領域特定語言（例如內部公司縮寫或術語），請考慮微調領域特定數據的內嵌模型。 這有助於模型更妥善地擷取特定網域的細微差別和術語，而且通常會導致提升擷取效能。

索引編製和記憶體

管線中的下一個步驟是對先前步驟中產生的嵌入向量和元數據建立索引。 這個階段牽涉到將高維度向量內嵌到有效率的數據結構中，以快速且精確的相似性搜尋。

在部署向量搜尋端點和索引時，馬賽克 AI 向量搜尋搜尋會使用最新的索引技術，以確保向量搜尋查詢的快速且有效率的查閱。 您不需要擔心測試和選擇最佳索引編製技術。

建置並部署索引之後，即可將它儲存在支援可調整、低延遲查詢的系統中。 對於具有大型數據集的生產RAG管線，請使用向量資料庫或可調整的搜尋服務，以確保低延遲和高輸送量。 將額外的元數據與內嵌一起儲存，以在擷取期間啟用有效率的篩選。