建置進階擷取增強產生系統
上一篇文章討論了建置「透過您的數據聊天」應用程式的兩個選項，這是企業中產生 AI 的首映使用案例之一：
- 擷取增強世代 （RAG），其補充大型語言模型 （LLM） 訓練與可搜尋文章的資料庫，這些文章可以根據使用者的查詢相似性擷取，並傳遞至 LLM 以完成。
- 微調，這會擴充 LLM 的訓練，以深入了解問題領域。
上一篇文章也討論了何時使用每個方法、每個方法的優缺點，以及數個其他考慮。
本文會更深入地探索 RAG，特別是建立生產就緒解決方案所需的所有工作。
上一篇文章說明使用下圖的RAG步驟或階段。
這種描述稱為「天真 RAG」，是先了解實作 RAG 型聊天系統所需的機制、角色和責任的實用方式。
不過，更真實世界的實作有更多前置和後置處理步驟來準備文章、查詢和回應以供使用。 下圖是RAG更現實的描述，有時稱為「進階RAG」。
本文提供概念架構，可了解真實世界 RAG 型聊天系統中的前置和後置處理考慮類型，如下所示：
- 擷取階段
- 推斷管線階段
- 評估階段
作為概念性概觀，關鍵詞和想法會以內容和起點的形式提供，以供進一步探索和研究。
擷取
擷取主要涉及以這類方式儲存貴組織的檔，以便輕鬆擷取以回答用戶的問題。 挑戰是確保最符合使用者查詢的檔部分，會在推斷期間找到並利用。 比對主要是透過向量化內嵌和餘弦相似性搜尋來完成。 不過，瞭解內容的性質（模式、形式等）和數據組織策略，有助於了解數據組織策略（儲存在向量資料庫中時的數據結構）。
為此，開發人員必須考慮下列事項：
- 內容前置處理和擷取
- 區塊化策略
- 區塊化組織
- 更新策略
內容前置處理和擷取
乾淨準確的內容是改善以RAG為基礎的聊天系統整體品質的最佳方法之一。 若要達成此目的，開發人員必須從分析要編製索引之文件的圖形和形式開始。 檔案是否符合檔等指定的內容模式？ 如果沒有，檔可能會回答哪些類型的問題？
開發人員至少應該在擷取管線中建立步驟，以：
- 標準化文字格式
- 處理特殊字元
- 拿掉不相關的過時內容
- 已建立版本內容的帳戶
- 內容體驗的帳戶（索引標籤、影像、數據表）
- 擷取
其中一些資訊（例如元數據，例如）可能很適合與向量資料庫中的檔一起保存，以在推斷管線的擷取和評估程序期間使用，或與文字區塊結合，以說服區塊的向量內嵌。
區塊化策略
開發人員必須決定如何將較長的檔分成較小的區塊。 這可以改善傳送至 LLM 的補充內容相關性，以正確回應用戶的查詢。 此外，開發人員還需要考慮如何在擷取時利用區塊。 這是一個區域，系統設計工具應該對業界所使用的技術進行一些研究，並進行一些實驗，甚至在其組織中以有限的容量進行測試。
開發人員必須考慮：
- 區塊大小優化 - 決定區塊的理想大小，以及如何指定區塊。 依區段？ 依段落？ 依句子？
- 重疊和滑動視窗區塊 - 決定如何將內容分割成離散區塊。 還是區塊會重疊？ 還是兩者（滑動視窗）？
- Small2Big - 當以單一句子等細微層級進行區塊處理時，內容會以容易找到鄰近句子或包含段落的方式組織嗎？ （請參閱「區塊化組織」。擷取這項額外資訊，並將它提供給 LLM，可以在回答使用者的查詢時提供更多內容。
區塊化組織
在RAG系統中，向量資料庫中的數據組織對於有效擷取相關信息以增強產生程序至關重要。 以下是開發人員可能會考慮的索引編製和擷取策略類型：
- 階層式索引 - 此方法牽涉到建立多層索引，其中最上層索引（摘要索引）會快速將搜尋空間縮小到潛在相關區塊的子集，而第二層索引（區塊索引）則提供更詳細的實際數據指標。 此方法可以大幅加速擷取程式，因為它會先篩選摘要索引，以減少在詳細索引中掃描的項目數。
- 特製化索引 - 根據數據的性質和區塊之間的關聯性，可以使用圖形型或關係資料庫等特製化索引。 例如：
- 當區塊具有可增強擷取的互連資訊或關聯性時，圖表型索引 很有用，例如引文網路或知識圖表。
- 如果區塊是以表格式格式結構化，則關係資料庫 可能會有效，其中 SQL 查詢可用來根據特定屬性或關聯性來篩選和擷取數據。
- 混合式索引 - 混合式方法結合了多個索引編製策略，以運用每個索引的優點。 例如，開發人員可能會使用階層式索引進行初始篩選和圖形型索引，以在擷取期間動態探索區塊之間的關聯性。
對齊優化
為了增強所擷取區塊的相關性和精確度，更貼近要回答的問題或查詢類型，這很有説明。 若要達成此目的，其中一個策略是為每個區塊產生並插入假設問題，代表區塊最適合回答的問題。 這可透過數種方式來協助：
- 改善比對：在擷取期間，系統會比較連入查詢與這些假設問題，以找出最佳的比對，以改善所擷取區塊的相關性。
- 機器學習 模型的定型數據：這些問題與區塊的配對可作為定型數據，以改善RAG系統基礎的機器學習模型，協助瞭解哪些問題類型最適合由哪些區塊回答。
- 直接查詢處理：如果實際使用者查詢與假設問題緊密相符，系統就可以快速擷取並使用對應的區塊，加快響應時間。
每個區塊的假設性問題都會作為一種「標籤」，引導擷取演算法，使其更專注且內容相關。 這在區塊涵蓋各種主題或信息類型的案例中很有用。
更新策略
如果您的組織需要為經常更新的文件編製索引，請務必維護更新的主體，以確保擷取器元件（負責對向量資料庫執行查詢並傳回結果的系統邏輯）可以存取最新的資訊。 以下是在這類系統中更新向量資料庫的一些策略：
- 累加式更新：
- 定期間隔：根據文件變更的頻率，定期排程更新（例如每日、每周）。 此方法可確保資料庫會定期重新整理。
- 觸發程式型更新：實作更新觸發程式重新編製索引的系統。 例如，任何修改或新增檔，都可能會自動起始受影響區段的重新編製索引。
- 部分更新：
- 選擇性重新編製索引：不要重新編製整個資料庫的索引，而是選擇性地只更新已變更之主體的部分。 這比完整重新編製索引更有效率，尤其是針對大型數據集。
- 差異編碼：只儲存現有文件與其更新版本之間的差異。 這種方法可藉由避免處理未變更數據的需求來減少數據處理負載。
- 版本控制：
- 快照集：在不同的時間點維護文件主體的版本。 這可讓系統在必要時還原或參考舊版，並提供備份機制。
- 檔版本控制：使用版本控制系統以系統的方式追蹤檔中的變更。 這有助於維護變更的歷程記錄，並可簡化更新程式。
- 即時更新：
- 串流處理：利用串流處理技術即時更新向量資料庫，因為對檔所做的變更。 這對於信息時間軸至關重要的應用程式。
- 實時查詢：不只依賴預先編製索引的向量，而是實作一種機制來查詢最新響應的實時數據，可能會將此與快取的結果結合，以提高效率。
- 優化技術：
- 批處理：累積變更並以批次方式處理，以優化資源的使用，並減少經常更新所造成的額外負荷。
- 混合式方法：結合各種策略，例如針對次要變更使用累加式更新，以及文件主體中重大更新或結構變更的完整重新編製索引。
選擇正確的更新策略或策略組合取決於特定需求，例如文件主體的大小、更新的頻率、實時數據的需求和資源可用性。 每個方法都有其複雜性、成本和更新延遲方面的取捨，因此必須根據應用程式的特定需求來評估這些因素。
推斷管線
既然發行項已區塊化、向量化，並儲存在向量資料庫中，焦點就會變成完成時的挑戰。
- 用戶的查詢是以這種方式撰寫，以從使用者所尋找的系統取得結果嗎？
- 用戶的查詢是否違反我們的任何原則？
- 我們如何重寫用戶的查詢，以改善在向量資料庫中尋找最接近相符項目的機會？
- 如何評估查詢結果，以確保發行項區塊對齊查詢？
- 如何在將查詢結果傳遞至 LLM 之前評估及修改查詢結果，以確保 LLM 完成中包含最相關的詳細數據？
- 我們如何評估 LLM 的回應，以確保 LLM 的完成會回答使用者的原始查詢？
- 我們如何確保 LLM 的回應符合我們的原則？
如您所見，開發人員必須考慮的許多工作，主要是以下列形式：
- 預先處理輸入，以將取得所需結果的可能性優化
- 後續處理輸出以確保所需的結果
請記住，整個推斷管線會實時執行。 雖然設計執行前置和後置處理步驟的邏輯沒有任何正確方法，但可能是程式設計邏輯和其他 LLM 呼叫的組合。 然後最重要的考慮之一，就是盡可能建置最精確且符合規範的管線，以及進行此作業所需的成本和延遲之間的取捨。
讓我們看看每個階段來識別特定策略。
查詢前置處理步驟
查詢前置處理會在使用者提交查詢之後立即發生，如下圖所示：
這些步驟的目標是確保使用者在我們的系統範圍內提出問題（而不是嘗試「越獄」系統使其執行非預期的事情），並準備用戶的查詢，以增加使用餘弦相似性/「最接近鄰」搜尋找出最佳可能文章區塊的可能性。
原則檢查 - 此步驟可能牽涉到可識別、移除、旗標或拒絕特定內容的邏輯。 某些範例可能包括移除個人標識資訊、移除驅逐，以及識別「越獄」嘗試。 越獄是指使用者可能用來規避或操作模型內建安全、道德或操作指導方針的方法。
查詢重新撰寫 - 這可能是任何從擴大縮略字和移除俚語，以更抽象地詢問問題來擷取高階概念和原則（“退步提示”）。
退步提示的變化是 假設性檔內嵌 （HyDE），它會使用 LLM 回答使用者的問題、建立該回應的內嵌（假設性檔內嵌），並使用內嵌來對向量資料庫執行搜尋。
子查詢 (部分機器翻譯)
此處理步驟涉及原始查詢。 如果原始查詢很長且很複雜，則以程序設計方式將它分成數個較小的查詢會很有用，然後合併所有回應。
例如，請考慮與科學發現相關的問題，特別是在物理領域。 用戶的查詢可能是：「誰對現代物理、艾因斯坦或尼爾斯·波爾做出了更重大的貢獻？
此查詢可能非常複雜，無法直接處理，因為「重大貢獻」可能具有主觀性和多面性。 將其細分為子查詢，可讓其更容易管理：
- 子查詢 1： 「阿爾伯特·愛因斯坦對現代物理學的關鍵貢獻是什麼？
- 子查詢 2： 「尼爾斯·布爾對現代物理學的關鍵貢獻是什麼？
這些子查詢的結果將詳細說明每個物理學家的主要理論和發現。 例如：
- 對於愛因斯坦來說，貢獻可能包括相對論、光電效應和E=mc^2理論。
- 對於波爾來說，貢獻可能包括他的氫原子模型、他對量子力學的工作，以及他的互補性原則。
概述這些貢獻之後，即可評估這些貢獻以判斷：
- 子查詢 3： 「愛因斯坦的理論如何影響現代物理學的發展？
- 子查詢 4： 「布爾的理論如何影響現代物理學的發展？
這些子查詢將探索每個科學家對這個領域工作的影響，例如愛因斯坦的理論如何導致宇宙學和量子理論的進步，以及波爾的工作如何促成對原子結構和量子力學的理解。
結合這些子查詢的結果，有助於語言模型根據理論進步的程度和影響，對現代物理做出更重大貢獻的人員形成更全面的回應。 此方法藉由處理更具體、可回答的元件，然後將這些結果合成成一致的答案，藉此簡化原始的複雜查詢。
查詢路由器
貴組織可能決定將其內容主體分成多個向量存放區或整個擷取系統。 在此情況下，開發人員可以使用 查詢路由器，這是一種機制，可智慧地根據提供的查詢判斷要使用的索引或擷取引擎。 查詢路由器的主要功能是選取最適當的資料庫或索引，以提供特定查詢的最佳答案，以優化擷取資訊。
查詢路由器通常會在使用者制定查詢之後的某個時間點運作，但在傳送至任何擷取系統之前。 以下是簡化的工作流程：
- 查詢分析：LLM 或其他元件會分析傳入查詢，以瞭解其內容、內容，以及可能需要的信息類型。
- 索引選取：根據分析，查詢路由器會從可能有幾個可用的索引中選取一或多個索引。 每個索引可能會針對不同類型的數據或查詢進行優化，例如，有些索引可能更適合事實查詢，而另一些索引可能擅長提供意見或主觀內容。
- 查詢分派：查詢接著會分派至選取的索引。
- 結果匯總：會擷取所選索引的回應，並可能進行匯總或進一步處理，以形成完整的答案。
- 答案產生：最後一個步驟涉及根據擷取的信息產生一致回應，可能整合或合成來自多個來源的內容。
您的組織可能會針對下列使用案例使用多個擷取引擎或索引：
- 數據類型特製化：某些索引可能專門處理新聞文章、學術論文中的其他索引，以及其他一般 Web 內容或特定資料庫，例如醫療或法律資訊的索引。
- 查詢類型優化：某些索引可能會針對快速事實查閱進行優化（例如日期、事件），而其他索引可能更適合用於需要深度領域知識的複雜推理工作或查詢。
- 演算法差異：不同的擷取演算法可用於不同的引擎，例如向量型相似性搜尋、傳統關鍵詞型搜尋，或更進階的語意理解模型。
想像一下在醫療諮詢內容中使用的RAG型系統。 系統可以存取多個索引：
- 針對詳細和技術說明優化的醫學研究論文索引。
- 臨床案例研究索引，提供真實世界的癥狀和治療範例。
- 基本查詢和公共衛生資訊的一般健康情況資訊索引。
如果使用者詢問有關新藥生化效果的技術問題，查詢路由器可能會因為其深度和技術焦點而優先處理醫學研究論文索引。 然而，對於常見疾病典型癥狀的問題，可能會選擇一般健康指數，以取得其廣泛且容易理解的內容。
擷取後處理步驟
擷取後處理會在擷取器元件從向量資料庫擷取相關內容區塊之後發生，如下圖所示：
在擷取候選內容區塊時，後續步驟是驗證文章區塊在增強 LLM 提示時會很有用，然後開始準備要呈現給 LLM 的提示。
開發人員必須考慮提示的幾個層面。 包含太多補充資訊的提示，以及一些（可能最重要的資訊）可以忽略。 同樣地，包含不相關信息的提示可能會不過度影響答案。
另一個考慮是 乾草袋 問題的針頭，一個術語指的是一些 LLM 的已知怪癖，其中提示的開頭和結尾的內容對 LLM 的重量比中間的內容更大。
最後，必須考慮 LLM 的內容視窗長度上限和完成異常長時間提示所需的令牌數目（特別是在大規模處理查詢時）。
若要處理這些問題，擷取後處理管線可能包含下列步驟：
- 篩選結果 - 在此步驟中，開發人員可確保向量資料庫傳回的文章區塊與查詢相關。 如果沒有，則撰寫 LLM 提示時會忽略結果。
- 重新排名 - 將從向量存放區擷取的文章區塊排名，以確保相關詳細數據會即時存在於提示的邊緣（開頭和結尾） 附近。
- 提示壓縮 - 使用小型、廉價的模型，其設計目的是在傳送至 LLM 之前，將多個發行項區塊合併並摘要成單一壓縮的提示。
完成後處理步驟
完成後處理會在用戶的查詢和所有內容區塊傳送至 LLM 之後發生，如下圖所示：
一旦 LLM 完成提示，就可以驗證完成，以確保答案正確無誤。 完成後處理管線可能包含下列步驟：
- 事實檢查 - 這可以採取許多形式，但意圖是識別文章中提出的特定宣告，這些宣告呈現為事實，然後檢查這些事實是否正確性。 如果事實檢查步驟失敗，可能適合重新查詢 LLM，希望有更好的答案或將錯誤訊息傳回給使用者。
- 原則檢查 - 這是最後一道防線，以確保答案不包含有害內容，無論是使用者還是組織。
評估
評估不具決定性系統的結果並不像大多數開發人員熟悉的單元或整合測試一樣簡單。 有幾個因素需要考慮：
- 使用者是否滿意他們取得的結果？
- 使用者是否獲得正確回答其問題？
- 我們如何擷取用戶意見反應？ 是否有任何原則可限制我們能夠收集哪些用戶數據？
- 對於對不盡如人意的響應進行診斷，我們是否能夠瞭解回答問題的所有工作？ 我們會在輸入和輸出的推斷管線中保留每個階段的記錄，以便我們可以執行根本原因分析嗎？
- 如何在不回歸或降低結果的情況下，對系統進行變更？
從使用者擷取並採取行動
如先前所述，開發人員可能需要與組織的隱私權小組合作，以設計意見反應擷取機制和遙測、記錄等，以在指定的查詢會話上啟用鑑識和根本原因分析。
下一個步驟是開發 評量管線。 評估管線的需求來自於分析逐字意見反應的複雜度和時間密集型本質，以及 AI 系統所提供回應的根本原因。 這項分析非常重要，因為它涉及調查每個回應，以瞭解 AI 查詢如何產生結果、檢查檔所使用的內容區塊是否適當，以及分割這些文件時採用的策略。
此外，它牽涉到考慮任何可增強結果的額外前置或後續處理步驟。 此詳細檢查通常會發現內容差距，特別是當沒有適當的檔存在以回應使用者的查詢時。
因此，建置評量管線對於有效管理這些工作的規模至關重要。 有效率的管線會利用自定義工具來評估計量，以估計 AI 所提供的答案品質。 此系統會簡化判斷使用者問題為何獲得特定答案的程式、哪些檔用來產生該答案，以及處理查詢的推斷管線的有效性。
黃金數據集
評估RAG聊天系統等不具決定性系統結果的一個策略，就是實作「黃金數據集」。 黃金數據集是一組經過策劃的問題，其中包含已核准的答案、元數據（例如主題和問題類型）、源文檔的參考，這些檔可作為答案的基礎真相，甚至是變化（不同的詞組來擷取使用者如何詢問相同問題的多樣性）。
「黃金數據集」代表「最佳案例」，可讓開發人員評估系統，以查看其執行效能，以及在實作新功能或更新時執行回歸測試。
評估傷害
傷害模型化是一種旨在預測潛在危害的方法，發現產品中可能造成個人風險的缺陷，以及制定主動式策略來減輕這類風險。
為了評估技術的影響而設計的工具，特別是 AI 系統，會根據所提供的資源中所述的傷害模型化原則，提供數個關鍵元件。
損害評估工具的主要功能可能包括：
項目關係人識別：此工具可協助使用者識別並分類受技術影響的各種利害關係人，包括直接使用者、間接受影響的各方，以及其他實體，例如子代或非人為因素，例如環境考慮（）。
傷害類別和描述：它將包括潛在危害的完整清單，例如隱私權損失、情感痛苦或經濟剝削。 此工具可引導使用者完成各種案例，說明技術如何造成這些傷害，協助評估預期和意外的後果。
嚴重性和機率評估：此工具可讓用戶評估每個已識別傷害的嚴重性和機率，讓他們優先處理哪些問題。 這可能包括質化評定，而且數據可在可用時得到支援。
風險降低策略：在識別和評估危害時，此工具會建議潛在的風險降低策略。 這可能包括系統設計變更、更多保護措施或替代技術解決方案，以將已識別的風險降到最低。
意見反應機制：此工具應納入機制，以收集專案關係人的意見反應，確保傷害評估程式是動態的，並回應新的信息和觀點。
文件和報告：為了協助透明度和問責，此工具將協助建立詳細的報告，記錄損害評估程式、結果和採取行動，以減輕潛在風險。
這些功能不僅有助於識別和降低風險，也有助於設計更道德和負責任的 AI 系統，一開始就考慮各種影響。
如需詳細資訊，請參閱
測試及驗證防護
本文概述數個旨在減輕RAG型聊天系統遭到惡意探索或入侵的可能性的程式。 Red-teaming 在確保風險降低有效方面扮演了重要角色。 Red-teaming 牽涉到模擬敵人針對應用程式的行動，以找出潛在的弱點或弱點。 這種方法在解決重大越獄風險方面尤其重要。
若要有效地測試及驗證 RAG 型聊天系統的保護措施，開發人員必須在可測試這些指導方針的各種案例下嚴格評估這些系統。 這不僅能確保健全性，而且有助於微調系統的響應，嚴格遵循定義的道德標準和操作程式。
可能會影響應用程式設計決策的最終考慮
以下是本文所要考慮的事項清單，以及其他會影響應用程式設計決策的專案：
- 認可設計中產生 AI 的非決定性本質、規劃輸出的變化，以及設定機制以確保回應的一致性和相關性。
- 根據延遲和成本的潛在增加，評估前置處理使用者提示的優點。 在提交之前簡化或修改提示可能會改善回應品質，但可能會增加響應週期的複雜性和時間。
- 調查平行處理 LLM 要求以提升效能的策略。 這種方法可能會降低延遲，但需要謹慎的管理，以避免增加複雜度和潛在的成本影響。
如果您想要立即開始實驗建置產生式 AI 解決方案，建議您先 看看使用您自己的 Python 數據範例開始使用聊天。 .NET、Java 和 JavaScript 也提供教學課程版本。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應