共用方式為

建置增強檢索功能的生成系統

  • 發行項

本文將深入探討檢索增強生成（RAG）。 我們會說明開發人員建立生產就緒RAG解決方案所需的工作和考慮。

若要瞭解建置「透過您的資料聊天」應用程式的兩個選項，這是企業中產生 AI 的熱門使用案例之一，請參閱 使用 RAG 增強 LLM 或微調。

下圖描述 RAG 的步驟或階段：

描述簡單RAG流程的圖表，方塊代表連接每個方塊的步驟或程式和箭號。

這種描述稱為 天真 RAG。 一開始了解實作 RAG 型聊天系統所需的機制、角色和責任，是一種有用的方法。

但實際實作有更多前置處理和後置處理步驟，可準備文章、查詢和回應以供使用。 下圖是更貼近實際的RAG描繪，有時稱為進階RAG。

一個圖表，展示進階的RAG邏輯流程，將其描繪為一系列方框，並以箭頭連接。

本文提供概念架構，可了解真實世界 RAG 型聊天系統中的前置處理和後置處理階段：

  • 擷取階段
  • 推理管線階段
  • 評估階段

擷取

資料收集主要是關於儲存您組織的文件，以便可以輕鬆地檢索它們來回答用戶的問題。 挑戰在於確保在推理過程中找到並使用最符合使用者查詢的文件部分。 比對主要是透過向量化內嵌和餘弦相似性搜尋來完成。 不過，藉由瞭解內容的性質（例如模式和表單）和數據組織策略，有助於比對（數據儲存在向量資料庫中時的數據結構）。

若要導入，開發人員必須考慮下列步驟：

  • 內容前置處理和擷取
  • 分塊策略
  • 區塊化組織
  • 更新策略

內容前置處理和擷取

乾淨準確的內容是改善以RAG為基礎的聊天系統整體品質的最佳方法之一。 若要取得乾淨、準確的內容，請從分析要編製索引之文件的圖形和形式開始。 檔案是否符合檔等指定的內容模式？ 如果沒有，檔可能會回答哪些類型的問題？

至少，在引入管線中建立步驟：

  • 標準化文字格式
  • 處理特殊字元
  • 拿掉不相關的過時內容
  • 已建立版本內容的帳戶
  • 內容體驗的帳戶（索引標籤、影像、數據表）
  • 擷取

其中一些資訊（例如元數據）如果與檔案一同存放在向量資料庫中，並在推斷管線的擷取和評估過程中使用，可能會很有用。 它也可以與文字區塊結合來影響區塊的向量嵌入。

分塊策略

身為開發人員，您必須決定如何將較大的檔分成較小的區塊。 區塊化可以改善傳送至 LLM 的補充內容的相關性，從而更準確地回應用戶查詢。 也請考慮如何在擷取之後使用這些塊。 系統設計者應該研究常見的產業技術，並進行一些實驗。 你甚至可以在組織中以有限的程度測試你的策略。

開發人員必須考慮：

  • 區塊大小優化：決定理想的區塊大小，以及如何指定區塊。 依區段？ 依段落？ 依句子？
  • 重疊和滑動視窗區塊：決定是否要將內容分割成離散區塊，還是區塊重疊？ 您甚至可以在滑動視窗設計中執行這兩個動作。
  • Small2Big：當區塊化是在如單一句子這樣細微的層級完成時，內容會被組織得便於很容易找到鄰近的句子或包含該句子的段落。 擷取此資訊並提供給 LLM，可能會提供更多內容來回應用戶查詢。 如需詳細資訊，請參閱下一節。

區塊化組織

在RAG系統中，策略性地組織向量資料庫中的數據，是有效擷取相關信息以增強產生程序的關鍵。 以下是您可能會考慮的編製索引和擷取策略類型：

  • 階層式索引：此方法牽涉到建立多層索引。 最上層索引 （摘要索引） 會快速將搜尋空間縮小到潛在相關區塊的子集。 第二層索引 （區塊索引） 會提供更詳細的實際數據指標。 這個方法可以大幅加快擷取程式的速度，因為它可藉由先篩選摘要索引來減少詳細索引中掃描的項目數。
  • 特製化索引：視數據的性質和區塊之間的關聯性而定，您可以使用圖形型或關係資料庫等特製化索引：
    • 當區塊具有可增強擷取的互連資訊或關聯性時，圖表型索引 很有用，例如引文網路或知識圖表。
    • 關係資料庫 如果資料區塊是以表格式結構化，則可以有效。 使用 SQL 查詢根據特定屬性或關聯性來篩選和擷取數據。
  • 混合式索引：混合式方法結合了多個索引方法，以將其優勢套用至整體策略。 例如，您可以使用階層式索引進行初始篩選和圖形型索引，以在擷取期間動態探索區塊之間的關聯性。

對齊優化

若要增強所擷取區塊的相關性和精確度，請與其回答的問題或查詢類型緊密對齊。 一個策略是為每個區塊生成並插入一個假設問題，這個問題代表該區塊最適合回答的問題。 這可透過數種方式來協助：

  • 改善比對：在擷取期間，系統會比較傳入查詢與這些假設問題，以找出最佳比對，以改善所擷取區塊的相關性。
  • 機器學習模型的訓練資料：這些問題與區塊配對可以用作訓練資料，用來改善RAG系統中基礎元件的機器學習模型。 RAG 系統會瞭解每個區塊最能回答哪些類型的問題。
  • 直接查詢處理：如果實際使用者查詢與假設問題緊密相符，系統就可以快速擷取並使用對應的區塊，並加快回應時間。

每個區塊的假設性問題就像是用來引導檢索演算法的標籤，使之更專注且具備內容上下文意識。 當區塊涵蓋各種資訊主題或類型時，這種優化非常有用。

更新策略

如果您的組織索引經常更新的文件，請務必維護最新的文集，以確保檢索器元件可以存取最新的資訊。 擷取器元件 是系統中針對向量資料庫執行查詢的邏輯，然後傳回結果。 以下是在這些系統中更新向量資料庫的一些策略：

  • 累加式更新：

    • 定期時間間隔：根據文件變更的頻率，排定定期更新時間（例如每日或每週）。 此方法可確保資料庫會定期根據已知的排程重新整理。
    • 觸發式更新：實作更新時觸發重新編製索引的系統。 例如，任何修改或新增文件都會自動起始受影響區段中的重新編製索引。

  • 部分更新：

    • 選擇性重新編製索引：不要重新編製整個資料庫索引，而是只更新變更的主體元件。 這種方法比完整重新編製索引更有效率，尤其是針對大型數據集。
    • 差異編碼：只儲存現有文件與其更新版本之間的差異。 這種方法可藉由避免處理未變更數據的需求來減少數據處理負載。

  • 版本設定：

    • 快照集：在不同的時間點維護文件主體版本。 這項技術提供備份機制，並允許系統還原至舊版或參考舊版。
    • 檔版本控制：使用版本控制系統有系統地追蹤文件變更，以維護變更歷程記錄及簡化更新程式。

  • 即時更新：

    • 串流處理：當信息時間軸很重要時，請在對檔進行變更時，使用串流處理技術進行即時向量資料庫更新。
    • 實時查詢：不只依賴預先編製索引的向量，而是使用即時數據查詢方法來 up-to日期回應，可能會將實時數據與快取的結果結合，以提高效率。

  • 優化技術：

    • 批處理：批處理會累積變更，以較不頻繁地套用，以優化資源並減少額外負荷。

    • 混合式方法：結合各種策略：

      • 針對次要變更使用累加式更新。
      • 請針對重大更新使用完整重新編製索引。
      • 記錄對主體所進行的結構變更。

選擇正確的更新策略或正確的組合取決於特定需求，包括：

  • 文件主體大小
  • 更新頻率
  • 實時數據需求
  • 資源可用性

根據特定應用程式的需求評估這些因素。 每個方法都有複雜度、成本和更新延遲的取捨。

推斷管線

您的發行項會進行區塊化、向量化，並儲存在向量資料庫中。 現在，將您的焦點轉向解決完成過程中的挑戰。

若要取得最精確且最有效率的完成，您必須考慮許多因素：

  • 用戶的查詢是以取得使用者正在尋找的結果的方式撰寫的嗎？
  • 用戶的查詢是否違反組織的任何原則？
  • 如何重寫用戶的查詢，以改善在向量資料庫中尋找最接近相符項目的機會？
  • 如何評估查詢結果，以確保文章片段符合查詢？
  • 如何在您將查詢結果傳遞至 LLM 之前評估及修改查詢結果，以確保完成中包含最相關的詳細數據？
  • 如何評估 LLM 的回應，以確保 LLM 完成會回答使用者的原始查詢？
  • 如何確保 LLM 的回應符合組織的原則？

整個推論管線會即時執行。 設計前置處理和後續處理步驟沒有一個正確的方法。 您可能會選擇程式設計邏輯與其他 LLM 呼叫的組合。 其中一個最重要的考慮是，在盡可能建置最精確且符合規範的管線，以及進行此作業所需的成本和延遲之間取捨。

讓我們在推斷管線的每個階段識別特定策略。

查詢前置處理步驟

查詢前置處理會在使用者提交其查詢之後立即發生：

重複進階RAG步驟的圖表，強調標示為查詢處理步驟的方塊。

這些步驟的目標是確保使用者在您的系統範圍內提出問題，並準備使用者的查詢，以增加通過使用餘弦相似度或「最近鄰居」搜尋來找出最佳可能文章區塊的可能性。

原則檢查：此步驟牽涉到可識別、移除、旗標或拒絕特定內容的邏輯。 一些範例包括移除個人資料、移除髒話，以及識別「越獄」嘗試。 越獄 是指用戶嘗試規避或操作模型的內建安全、道德或操作指導方針。

查詢重寫：此步驟可能涉及展開縮略詞和移除俚語，重新措辭問題使其更抽象，以便擷取高階概念和基本原則（退後提示）。

退步提示的一種變化是 假設性文件嵌入（HyDE）。 HyDE 使用大型語言模型回答使用者的問題，建立該回應的嵌入向量（假設文件的嵌入向量），然後利用該嵌入向量在向量資料庫中執行搜尋。

子查詢 (部分機器翻譯)

子查詢處理步驟是以原始查詢為基礎。 如果原始查詢很長且很複雜，以程序設計方式將它分成數個較小的查詢，然後合併所有回應會很有用。

例如，關於物理學科學發現的問題可能是：「誰對現代物理學、阿爾伯特·愛因斯坦或尼爾斯·布爾做出了更重大的貢獻？

將複雜的查詢細分為子查詢，使其更容易管理：

  • Subquery 1：「阿爾伯特·愛因斯坦對現代物理學的關鍵貢獻是什麼？
  • 子查詢 2：「尼爾斯·布爾對現代物理學的關鍵貢獻是什麼？

這些子查詢的結果詳細說明瞭每個物理學家的主要理論和發現。 例如：

  • 對於愛因斯坦來說，貢獻可能包括相對論、光電效應和 E=mc^2。
  • 對布爾來說，貢獻可能包括布爾的氫原子模型、布爾的量子力學工作，以及布爾的互補性原則。

概述這些貢獻時，可以評估這些貢獻以判斷更多子查詢。 例如：

  • 子查詢 3：“愛因斯坦的理論如何影響現代物理學的發展？
  • 子查詢 4：「布爾的理論如何影響現代物理學的發展？

這些子查詢會探索每個科學家對物理的影響，例如：

  • 愛因斯坦的理論如何導致宇宙學和量子理論的進步
  • 布爾的工作如何有助於瞭解原子結構和量子力學

結合這些子查詢的結果，有助於語言模型根據理論進步對現代物理做出更重大貢獻的人形成更全面的回應。 此方法藉由存取更具體、可回答的元件，然後將這些結果合成成一致的答案，藉此簡化原始的複雜查詢。

查詢路由器

您的組織可能會選擇將其內容主體分成多個向量存放區或整個擷取系統。 在該案例中，您可以使用查詢路由器。 查詢路由器 選取最適當的資料庫或索引，以提供特定查詢的最佳答案。

查詢路由器通常會在使用者制定查詢後的某一階段運作，但在查詢傳送至檢索系統之前。

以下是查詢路由器的簡化工作流程：

  1. 查詢分析：LLM 或其他元件會分析傳入查詢，以瞭解其內容、內容和可能需要的信息類型。
  2. 索引選取：根據分析，查詢路由器會從可能有幾個可用的索引中選取一或多個索引。 每個索引可能會針對不同類型的數據或查詢進行優化。 例如，某些索引可能更適合事實查詢。 其他索引可能擅長提供意見或主觀內容。
  3. 查詢分派：查詢會分派至選取的索引。
  4. 結果匯總：擷取所選索引的回應，並可能進行匯總或進一步處理，以形成完整的答案。
  5. 回應產生：最後一個步驟涉及根據擷取的信息產生一致回應，可能整合或合成來自多個來源的內容。

您的組織可能會針對下列使用案例使用多個擷取引擎或索引：

  • 數據類型特製化：某些索引可能專門處理新聞文章、學術論文中的其他索引，以及其他一般Web內容或特定資料庫，例如醫療或法律資訊。
  • 查詢類型優化：某些索引可能會針對快速事實查閱進行優化（例如日期或事件）。 其他可能更適合用於複雜的推理工作，或需要深入領域知識的查詢。
  • 演算法差異：不同的擷取演算法可用於不同的引擎，例如向量型相似性搜尋、傳統關鍵詞型搜尋，或更進階的語意理解模型。

想像一個以RAG為基礎的系統應用於醫療諮詢的情境。 系統可以存取多個索引：

  • 針對詳細和技術說明優化的醫學研究論文索引
  • 臨床案例研究索引，提供真實世界的癥狀和治療範例
  • 基本查詢和公共衛生資訊的一般健康情況資訊索引

如果使用者詢問有關新藥生化效果的技術問題，查詢路由器可能會因為其深度和技術焦點而優先處理醫學研究論文索引。 然而，對於常見疾病典型癥狀的問題，可能會選擇一般健康指數，以取得其廣泛且容易理解的內容。

擷取後處理步驟

擷取後處理會在擷取器元件從向量資料庫擷取相關的內容區塊之後發生：

重複進階RAG步驟的圖表，強調標示為擷取後處理步驟的方塊。

在擷取候選內容區塊之後，下一個步驟是在準備要呈現給 LLM 的提示之前，先 增強 LLM 提示時，驗證發行項區塊有用性。

以下是一些要考慮的提示的方面：

  • 包含太多補充資訊可能會導致忽略最重要的資訊。
  • 包含不相關的資訊可能會對答案造成負面影響。

另一個考慮是 針頭在乾草袋 問題，一個術語指的是一些 LLM 的已知怪癖，其中內容在提示的開頭和結尾對 LLM 的重量比中間的內容更大。

最後，請考慮 LLM 的上下文視窗長度上限，以及完成極長提示詞所需的令牌數目（尤其是大規模的查詢）。

若要處理這些問題，擷取後處理管線可能包含下列步驟：

  • 篩選結果：在此步驟中，請確定向量資料庫傳回的發行項區塊與查詢相關。 如果不符合條件的話，當 LLM 提示訊息組成時，結果將被忽略。
  • 重新排名：對從向量存放區擷取的文章區塊進行排名，以確保相關詳細數據接近提示的邊緣（開頭和結尾）。
  • 提示壓縮：使用小型且高效的模型，將多個文章段落壓縮並摘要成單一壓縮提示，然後將提示傳送至 LLM。

完成後處理步驟

後續處理會在使用者的查詢和所有內容區塊傳送至 LLM 之後進行：

重複進階RAG步驟的圖表，強調標示完成後處理步驟的方塊。

正確性驗證會在 LLM 的提示完成之後進行。 完成後處理管線可能包含下列步驟：

  • 事實查核：目的是識別文章中作為事實提出的具體聲明，然後檢查這些事實的準確性。 如果事實檢查步驟失敗，建議重新查詢 LLM，希望取得更好的答案或將錯誤訊息傳回給使用者。
  • 政策檢查：這是確保答案不包含有害內容的最後一道防線，無論是對使用者還是對組織來說。

評估

評估非決定性系統的結果並沒有大部分開發人員都熟悉的執行單元測試或整合測試那麼簡單。 您需要考慮數個因素：

  • 使用者是否滿意他們取得的結果？
  • 使用者是否獲得正確回答其問題？
  • 如何擷取用戶意見反應？ 您是否有任何政策限制您可以收集哪些用戶數據？
  • 若要診斷不盡如人意的回應，您是否能夠瞭解所有回答問題的工作？ 您是否在輸入和輸出的推斷管線中保留每個階段的記錄，以便執行根本原因分析？
  • 如何在不回歸或降低結果的情況下對系統進行變更？

從使用者擷取並採取行動

如先前所述，您可能需要與貴組織的隱私權小組合作，以設計意見反應擷取機制、遙測和記錄，以進行查詢會話的鑑識和根本原因分析。

下一個步驟是開發 評量管線。 評量管線可協助分析逐字意見反應的複雜度和時間密集型本質，以及 AI 系統所提供回應的根本原因。 這項分析非常重要，因為它牽涉到調查每個回應，以瞭解 AI 查詢如何產生結果、檢查檔使用的內容區塊適當性，以及分割這些檔時採用的策略。

它也牽涉到考慮任何可能會增強結果的額外前置處理或後續處理步驟。 此詳細檢查通常會發現內容差距，特別是當沒有適當的檔可供回應使用者的查詢時。

建立評量管線對於有效管理這些工作的規模至關重要。 高效的流程會使用自定義工具來評估接近 AI 所提供答案品質的指標。 此系統可簡化程式，以判斷為何特定答案提供給用戶的問題、哪些檔用來產生該答案，以及處理查詢的推斷管線的有效性。

黃金數據集

評估 RAG 聊天系統等非決定性系統結果的其中一個策略是使用黃金數據集。 黃金數據集 是一組精心策劃的問題和核准的答案，如主題與問題類型等的元數據，以及可作為答案真實資料的源文檔參考，甚至涵蓋不同的表述方式，用以捕捉使用者對相同問題可能有的多樣化詢問方式。

黃金數據集代表「最佳案例」。開發人員可以評估系統以查看其執行效能，然後在其實作新功能或更新時執行回歸測試。

評估傷害

傷害模型化是一種旨在預測潛在危害的方法，發現產品中可能造成個人風險的缺陷，以及制定主動式策略來減輕這類風險。

專為評估技術（特別是 AI 系統）影響而設計的工具，會根據所提供的資源中所述的傷害模型化原則，提供數個關鍵元件。

損害評估工具的主要功能可能包括：

  • 項目關係人識別：此工具可協助用戶識別並分類受技術影響的各種項目關係人，包括直接使用者、間接受影響的各方和其他實體，例如子代或非人因素，例如環境問題。

  • 損害類別和描述：此工具可能包含潛在危害的完整清單，例如隱私權損失、情緒痛苦或經濟剝削。 此工具可引導用戶進行各種案例、說明技術如何造成這些傷害，以及協助評估預期和非預期的結果。

  • 嚴重性和機率評估：此工具可協助用戶評估每個已識別傷害的嚴重性和機率。 用戶可以優先解決需要首先處理的問題。 範例包括可用數據所支援的定性評量。

  • 風險降低策略：此工具可以在識別並評估危害之後建議潛在的風險降低策略。 範例包括系統設計變更、新增保護措施，以及將已識別風險降至最低的替代技術解決方案。

  • 意見反應機制：此工具應納入從項目關係人收集意見反應的機制，讓傷害評估程序動態且回應新的信息和觀點。

  • 文件記錄和報告：為了達到透明性和問責性，此工具可能會協助詳細報告，記錄損害評估過程、結果，以及採取的潛在風險降低措施。

這些特性能協助您識別和緩解風險，但也能幫助您從一開始就考慮各種影響，設計出更具道德性和責任感的 AI 系統。

如需詳細資訊，請參閱下列文章：

測試及驗證防護

本文概述數個流程，旨在降低RAG型聊天系統被利用或受損的可能性。 Red 小組 在確保安全防護措施有效方面扮演了重要角色。 Red-teaming 牽涉到模擬潛在對手的行動，以找出應用程式中的潛在弱點或漏洞。 這種方法在解決重大越獄風險方面尤其重要。

開發人員必須在各種指導方針案例下嚴格評估以RAG為基礎的聊天系統保護，以有效地測試及驗證它們。 這種方法不僅能確保健全性，還能協助您微調系統的回應，以嚴格遵守定義的道德標準和操作程式。

應用程式設計的最終考慮

以下是這篇文章中需要考慮的一些重要事項和可能影響應用程式設計決策的重點：

  • 在您的設計中認可 Generative AI 的非決定性本質。 規劃輸出的變化，並設定機制以確保回應的一致性和相關性。
  • 根據延遲和成本的潛在增加，評估前置處理使用者提示的優點。 在提交之前簡化或修改提示可能會改善回應品質，但可能會增加響應週期的複雜性和時間。
  • 若要增強效能，請調查平行處理 LLM 要求的策略。 這種方法可能會降低延遲，但需要謹慎的管理，以避免增加複雜度和潛在的成本影響。

如果您想要立即開始實驗建置產生式 AI 解決方案，我們建議您參閱 使用 Python的自有數據範例開始聊天。 本教學課程也適用於 .NET、Java和 JavaScript。