在 Azure 上為 AI 工作負載提供基礎數據設計
針對 AI 應用程式，妥善架構的數據設計架構方法必須解決操作性、成本和安全性等非功能性需求，並遵循 Azure 良好架構架構支柱的核心原則。 它也應該考慮功能需求，例如數據擷取、準備和驗證。
您選擇的 AI 模型會影響後續的數據設計決策。 本文討論需要增強以增強結果相關性的基礎模型的重要架構考慮。 這些模型通常是再生模型。
產生式 AI 模型已預先建置或預先定型，可讓您立即使用它們，而不需要進行修改。 不過，現用的模型通常不符合特定的工作負載需求。 為了解決此問題，模型會隨著內容特定數據而增強，以改善其效能。 例如，您可以在各種使用案例中使用 GPT 模型。 這些應用程式包括從檔擷取資訊、提供IT技術服務人員支援，以及摘要複雜的資訊。 若要使用基礎模型來符合您的特定需求，請務必瞭解這些考慮。
重要
數據設計是以統計實驗為基礎的反覆程式。 Generative AI 應用程式會將查詢傳送至包含提示和內容數據的模型。 若要精簡數據設計，應該逐一查看提示和內容數據。 反覆程式應該包含前置處理、選取內嵌和區塊化。 這些步驟有助於建立適合索引的數據。 如需詳細資訊，請參閱 設計和開發擷取增強世代 （RAG） 解決方案。
當您進行實驗並反覆運算時，請記住耗用量使用案例。 根據實際的查詢模式調整數據設計。 透過精簡和測試來判斷可接受的內容。
在解決方案中，您可以使用產生 AI 和歧視 AI 模型的組合，以滿足工作負載需求。 如需定型數據的詳細資訊，請參閱 定型數據設計。
建議
以下是本文所提供的建議摘要。
| 建議 | 描述 |
|---|---|
| 預期用戶查詢。 | 瞭解與源數據相關的預期問題類型，以及他們對新鮮度的期望。 這項瞭解可協助您設計數據管線和索引，以提供相關的地面數據。 |
| 將數據外部化至搜尋索引。 | 使用搜尋索引，而不是直接從來源系統查詢。 根據工作負載需求評估不同的索引技術。 建立功能矩陣，以評估最符合您的需求。 請考慮強大的搜尋索引技術，例如 Elasticsearch 或 AI 搜尋。 ▪ 索引 |
| 開發擷取策略。 | 開發涵蓋數據擷取和前置處理的完整索引管理策略。 藉由解決不一致和重複的問題，並將標準化為通用架構，以移除嘈雜或不相關的數據。 將來源格式和類型轉換為有助於查詢和分析的數據類型。 ▪ 數據準備 ▪ 數據磁碟區重新複製 |
| 設計索引以達到最大相關性。 | 啟用特定欄位的篩選、排序和元數據處理等功能，以改善查詢效率。 例如，只有在您想要搜尋欄位時，才能將字段標記為可搜尋。 為了避免不必要的儲存成本，請勿在沒有特定使用案例的情況下，讓每個字段都能擷取。 ▪ 架構設計 ▪ 索引功能 ▪ 有效率的查詢 |
| 更新您的索引，以防止推斷過時的數據。 | 當您更新索引時，請考慮採用並存部署策略進行維護。 重建索引可確保處理刪除和更新，因為索引會變成新的數據集。 此方法允許在讓索引上線之前徹底測試數據。 當您變更索引時，請使用程式代碼更新來協調架構修改。 這種做法可確保順暢的轉換。 ▪ 索引維護 |
資料類型
您可以在推斷期間使用內容數據來增強產生 AI 模型，或透過微調程式進一步優化它們。 這兩種方法都需要補充數據，以提供更多內容給模型。 模型會使用該內容來回應用戶查詢，並根據預期形成答案。 一般而言，您會使用下列數據類型：
源數據 是生產環境中現有的數據。 此數據可以結構化，例如資料庫中的數據，或半結構化的數據，例如 JSON 檔案。 它也可以是非結構化的，例如檔、影像和音訊檔案。
基礎數據來自源數據 ，其中包含模型初始定型數據中未涵蓋的主題相關信息。 地面數據會與使用者查詢結合，以形成在特定推斷呼叫內容中傳送至大型語言模型的提示。 您可以在推斷呼叫中包含的其他數據是系統提示、單次或幾槍範例，以及先前互動等內容相關數據。
此數據應該很容易搜尋並快速擷取。 由於這項需求，您應該將數據儲存在已針對搜尋優化的索引中。 當使用者等候答案時，會即時存取此索引。 如果沒有此數據，模型可能會產生不正確的結果，或不適用於用戶特別尋找的結果。
微調數據 是用來影響模型的資訊，使其可以適應未來推斷要求的特定工作、定義域或響應樣式。 例如，如果模型預期在特定文法樣式中提供答案，該樣式指南會做為微調數據。
用戶數據 報含使用者在與應用程式互動期間提供的資訊。 當您與產生模型互動時，會發生具狀態的互動。 這些模型缺少固有的記憶體，並將每個互動視為不可部分完成。
當您管理具狀態互動，也稱為 聊天應用程式中的 TURN 數據 時，請務必在最短時間內儲存數據。 在理想情況下，此數據應在會話結束之後終結。 不過，可能有作業或合規性原因會要求您保留某些數據，例如原始問題或模型回應，超出會話持續時間。 可能的話，請避免將此數據儲存在會話之後。
編製索引
數據設計的核心包括有效率地儲存和管理基礎數據。 此方法可確保數據可以擴增，以達到最高層級的相關性。
簡單的 AI 策略可能涉及查詢每個用戶互動的源數據。 不過，這種方法並不實用，因為直接數據源互動的成本很高和複雜度。 相反地，您應該在已針對搜尋和擷取優化的索引中，將源數據重新設定為複本。 此方法的目標是改善模型的理解和產生相關回應的能力。
請考慮銀行工作負載，其會儲存與使用者帳戶相關詳細數據，以及數據存放區中的喜好設定和財務交易。 在使用RAG模式的產生式AI案例中，會建立基礎數據，並以內容編製索引，讓模型可以提供相關的回應。 例如，藉由在推斷期間提供使用者交易的相關數據，模型可以在上一季回答與用戶消費模式相關的問題。
特製化索引技術
請考慮將地面數據外部化為搜尋索引。 使用此方法，而不是直接從來源系統進行查詢。
使用搜尋索引有好處。 您可以根據預期的查詢來建立資料模型並轉換複本。 對主要來源的直接查詢有問題，因為有可能無法存取源數據。 索引可確保只要您認為數據與應用程式相關，數據仍可供使用。 您也可以避免讓源數據系統產生壓力。 此策略可確保 AI 相關查詢不會影響其主要使用案例。
某些技術選項具有自我編製索引功能。 索引可以連絡數據源併入其數據。 針對此選項，網路考慮是關鍵。 如果索引需要連線到資料庫，可能會發生問題，例如網路等待時間和可靠性。
匯入數據的初始成本。 數據在索引中之後，除非有變更或更新，否則您不需要再次移動它。 一段時間的數據管理是索引設計的重要層面。 如需詳細資訊，請參閱 索引維護。
預設或自定義索引
某些技術支持自動為您的數據建立預設索引。 此索引會在數據擷取上產生，且輸入最少。 索引具有現用的功能。 概念證明和某些生產案例可能可以接受預設索引。
在某些情況下，您可能需要有自定義索引架構，以根據特定的工作負載需求來改善相關性。 這些需求會決定如何設計架構、啟用索引功能，以及包含相關的元數據。
結構描述設計
您可以將索引視為組織及優化數據以擷取的結構。 更具體來說，他們會在數據表的檔和欄位中組織數據。 請考慮下列幾點：
索引拓撲。 評估是否要共置單一索引中的所有數據，或分散到多個索引。 此決策會大幅影響文件之間的查詢效能、索引維護、查詢簡單性，以及不同的字段組態（或架構）。
例如，請考慮要求特定語言內容的用戶查詢。 最簡單的數據設計選擇可能是將所有語言翻譯成一種語言，並將其儲存在單一索引中。 或者，數據可以儲存在單一索引中的所有語言中。 這個選擇會產生每個語言的多個檔。 索引的篩選功能可用來將結果限制為所需的語言。 或者，每個索引都可以在查詢中如預期般包含指定語言的翻譯版本。
在某些情況下，您可能需要多個搜尋索引。 此方法可讓您獨立優化每個索引，以取得搜尋查詢的最大相關性。 例如，HR 員工手冊和產品維護手冊有不同的用途和物件。 藉由個別編製索引，您可以針對每個專案量身打造架構和搜尋查詢，進而改善用戶體驗。 這種方法可能很難實作，而且需要協調器來協助呼叫每個索引。 協調流程元件描述於 Azure 上 AI 工作負載的應用程式設計。
注意
兩個拓撲和數據分割策略之間的選擇取決於工作負載需求、使用案例和使用者期望。
執行跨索引查詢可能具有挑戰性，而且可能會影響搜尋相關性。 在最壞的情況下，可能會手動篩選結果，決定哪一個符合準則。 此程式引進延遲並增加複雜度。 相反地，單一索引方法更簡單且更直接。 使用篩選等索引功能可以改善相關性。
在某些情況下，合規性考慮會導致需要個別索引。 例如，如果商務需求要求數據在歐美之間隔離，則多個索引可能不可避免。
文件設計。 將您的數據設計與預期的使用者查詢對齊，以優化相關性。 請考慮每個檔應如何提供查詢。 針對搜尋索引，將相關文件排定優先順序，並將結果精簡為一組密集且包含相關信息的精簡集合。
欄位設計。 設定索引欄位以支援搜尋效能和相關性。 您的索引欄位應該對應至您想要讓可搜尋、可擷取、可篩選和可排序的文件屬性。 它們包括內嵌、標識碼或任何其他可提升搜尋數據的數據。
索引功能
設定搜尋索引欄位以傳回最相關的檔集。 決策取決於搜尋索引技術和工作負載需求支援的功能。
篩選、搜尋和排序選項。 請考慮這些選項，因為它們與擴增的使用案例直接相關。 例如， 可篩選會 根據查詢中提供的值來判斷 true 或 false，並傳回相關的檔。 針對 可搜尋性，屬性會指出搜尋查詢是否可以參考欄位。 例如，您可能會檢查文字欄位是否包含特定文字，或是否以數學方式與另一個向量相關。 您可以選擇性地將相對權數指派給該欄位做為搜尋查詢的一部分。 您也可以將結果集 設為可排序，依相關性列出結果。
權衡。 啟用索引欄位的功能會增加空間需求，並影響成本。 只新增您想要使用的功能。Metadata. 索引通常具有與索引欄位相關聯的元數據。 元數據可藉由提供相關詳細數據，協助我們瞭解及管理數據。 設計索引時，請考慮元數據是可擷取的，還是只用於相關性判斷。 決策會影響計算成本，因為基礎索引編製程式不同。 過多的元數據可能會不必要地增加索引的大小。
索引有許多技術選擇。 許多共用類似的特性，例如先前列出的特性。 某些索引可能有額外的功能，例如在編製索引期間處理文字和語言分析。 若要讓文字更適合編製索引和搜尋、將文字分成標記、將其轉換成小寫，或移除停用字詞。
高效率查詢
在產生的 AI 應用程式中會使用地面數據，以提高回應對使用者查詢的精確度和相關性。 請考慮事先查詢使用者。 瞭解可以詢問哪些問題、詢問問題的人員，以及他們詢問的頻率。 此資訊可協助應用程式表單內容，並了解結果可能相關。
一般搜尋類型包括：
向量查詢 會根據高維度空間中的向量表示法或數據點來搜尋類似的專案。
關鍵詞搜尋 會在文字檔的完整內容中搜尋。 它會索引和查詢大量的文字數據，而且通常用於搜尋引擎、資料庫和檔管理系統。
語意排名 會根據查詢的語意相關性來重新排序搜尋結果的相關性，將最相關的語意比對提升至清單頂端，藉此改善搜尋結果的相關性。
混合式搜尋 結合了不同的搜尋類型，例如向量搜尋、全文搜索和語意排名，以進一步改善搜尋結果的相關性。
若要進一步改善模型效能，請結合搜尋類型。
儲存和處理數據的方式會影響查詢效率。 每次將數據新增至索引時，都需要計算週期才能編製索引。 如果對相同的計算資源進行索引編製和回應查詢，可能會發生爭用。 在理想情況下，索引應著重於有效率地響應查詢的主要目標，並尋找相關的檔，而不是過度編製索引。
成本和效能是索引設計的關鍵驅動因素。 建立陰影複製等技術可以加速查詢。 不過，數據重複會透過產生成本的索引發生。
針對數據存放區的技術選擇，搜尋索引，例如 Elasticsearch 或 AI 搜尋，提供強大的搜尋功能，包括向量化和相關性型搜尋。 或者，請考慮支援您擁有之數據類型的資料庫選項，以及您需要的查詢類型，因為它們已針對查詢進行優化。 歸根結底，這是關於選項所提供的功能，以及在小組上建置新技能集的投資。
資料準備
基礎數據是以現有的數據為基礎，需要進行適合語意查詢。 在索引中尋找相關文件的一些查詢可以是常值比對。 其他查詢需要模糊比對。
在內容相關數據準備好支援對模型的推斷要求之前，有一個前置處理步驟旨在清除、轉換和建構數據。 目標是減少雜訊和偏差、有效率地搜尋，以及最大化索引搜尋的相關性。 前置處理的選擇工具或邏輯取決於工作負載小組，但有一些廣泛的考慮。
數據磁碟區重新複製
數據磁碟區重新複製牽涉到藉由展開或縮小數據範圍來建立緊密索引，以增加相關性。 查詢效率是另一個重大問題。 儲存不必要的數據會對這兩個目標造成負面影響。 例如，請考慮使用者的位置數據。 如果只有城市部分是相關的，請只儲存城市文字而非代表位址的全文，以優化。
以下是一些廣泛的考慮。
數據刪除。 只保留產品功能不可或缺的內容，捨棄不必要的詳細數據。 以下是一些常見範例。
定性消除。 從廣泛的範圍轉換成較窄的相對範圍，其中一種方法是選擇性地選擇編製相關源數據的索引，以消除低質量的數據。 挑戰在於以程式設計方式識別與 AI 案例無關的內容。 雖然內容可能適用於其他意圖，例如稽核或完整性，但包括 AI 工作負載中的內容可能會降低相關性。 標幟這類內容的其中一種方式是使用元數據，如果內容必須新增至索引，則可以在索引母體擴展時間使用。
敏感性資料。 將數據從源數據複製到索引也可能帶來敏感性資訊。 尊重在來源套用的數據分類標籤，並維持此數據集的相同敏感度層級。 當您處理具有個人信息的數據時，除非您需要它來回應查詢，否則請勿儲存個人資料。 例如，在編製電子郵件索引時套用數據分類。 如果電子郵件標示為敏感性，請避免將其儲存在一般敏感度數據存放區中。
正規化和標準化文字。 解決錯字和標準化文字對於關鍵詞型索引至關重要。 潛在的使用案例是翻譯，特別是在處理多語系內容時。
內嵌也需要這種類型的前置處理，這可讓您根據其內容和重要性來比較單字。 不過，單字區分大小寫會發生一項挑戰。 內容很重要，而且可能有細微差別，例如形容詞“公民”與適當名詞“（本田）公民”之間的語意差異。
數據新增。 擴增內容通常依賴元數據，這通常不會出現在源數據中。 例如，請考慮文字段。 迴圈中的人類或 AI 會建立可使用代碼段內容回答的相關問題。 當您將這些問題與基礎數據一起儲存時，可以將使用者查詢與產生的查詢進行比較，以評估文件相關性。 此新數據與地面數據共置是擴充區塊化數據的強大方式。
另一個使用案例是在分析非結構化數據時找到的實體。 這些實體可以新增至索引，並用於搜尋和篩選外部系統，或用來執行複雜的計算。 例如，如果我們識別公司名稱，我們可能會從外部資料庫查閱其產業或其他相關信息，並將其新增至我們的索引。
請考慮維護數據譜系。 AI 工作負載務必追蹤數據源，因為當系統將各種元件匯總成一個索引時，該資訊可能會遺失。 此資訊可能永遠不會公開給使用者，但數據來源的相關信息對於內部數據控管小組而言非常重要。 此元數據不一定適用於模型。 它有助於保持透明度和責任。
權衡。 一方面，新增數據會增加在數據集內尋找相關性的機會。 不過，這項好處會付出代價。 具體而言，處理和管理該欄位所需的計算資源。 收集和儲存數據所花費的時間可能相當龐大。 請注意，使用不必要的欄位多載可能會使資源變得緊張。處理文字數據。 請考慮同義字、詞幹和語意鄰近性等技術，以增強相關性。 盡可能將這些技術委派給工具。 某些技術，例如 Elasticsearch 或 AI 搜尋，在索引建立期間提供前置處理數據的功能。
數據類型變形
數據存放區中的索引欄位是數據類型來提供特定用途。 數值欄位有助於有效率的查詢、文字欄位允許文字型搜尋，以及布爾欄位處理二進位資訊。
源數據通常存在於各種類型的數據中，例如文字、影像和數據表，以及處理這些數據可能相當複雜。 您可能必須擷取機碼/值組、識別語意區塊化的區段標題、辨識特定標識碼等等。
例如，如果您的源數據包含影像，則它們原本就無法搜尋。 它們必須轉換成向量表示法，才能啟用有效率的語意搜尋和比較。 如果相關性系結至這些格式背後的數據，請投資擷取數據。 將源數據類型轉換成有助於查詢和分析的功能數據類型。
區塊化和內嵌
地面數據通常包含大量的資訊，但模型只能標記特定數量。 區塊化 是重要的數據設計策略，因為它牽涉到將檔分割成較小的片段，可以個別處理和編製索引。 儘管令牌限制，此策略仍允許有效率的搜尋和擷取。 檢查您選擇的大型語言模型可以處理的令牌數目上限。 您的區塊不應超過該限制。
實作區塊化有許多技術。 如需詳細資訊，請參閱 區塊化方法。
內嵌 也是另一個可啟用向量搜尋功能的設計策略。 內嵌是以地面數據為基礎的 AI 模型所產生的物件數學表示法。 它們會儲存在索引中，並新增更多內容，以協助複雜的查詢產生具有更佳相關性的結果。 如需詳細資訊，請參閱產生內嵌。
索引維護
一段時間的維護是索引設計的重要層面。 對於靜態數據，檔保持不變，索引維護很簡單。 但是，大部分的索引都是動態的。 一段時間后，可能會新增數據，而且索引架構可能需要新的欄位。 相反地，如果某些數據和欄位不再相關，可能需要刪除。 索引器常用的技術選項具有自動處理更新的功能。 如需建議索引特性的相關信息，請參閱 搜尋索引的考慮。
維護準則
功能更新。 如果應用程式功能有所變更，可能需要更新索引。 當系統詢問新問題時，就會發生這種情況。 若要容納這些變更，您可能需要將新的欄位新增至索引，或修改現有欄位上的篩選、搜尋或文字處理選項。
資料刪除。 刪除數據是一項挑戰，因為您需要分析可用和遺漏的數據，以判斷無關緊要的內容。 若要從索引中排除過時的內容，請考慮使用可防止搜尋引擎編製特定頁面或內容的索引的元數據。 此外，當您選擇記憶體選項時，請選取可有效率地支援刪除的技術。 例如，Blob 記憶體支援虛刪除。 如果您使用 AI 搜尋和從記憶體載入檔，Blob 記憶體可以偵測移除的檔案並刪除對應的專案。 這種方法並不理想，但重新編製索引的成本很高，因為索引大小很大。
被遺忘的權利概念是指個人有權將其個人資料從在線平臺或資料庫移除。 確定您已設定原則，以在用於定型時移除個人資料。 您可以重新編製數據集的索引，以解決此需求。 如果從交易資料庫刪除數據，後續的索引更新會反映這些變更。
維護相容性。 應用程式通常需要特定的數據結構，而且任何偏差都可能會中斷其功能。 例如，如果移除欄位，且應用程式要求該欄位，則可能會發生失敗狀況。 如同傳統資料庫，請採用索引的向前相容性思維，並維持一定程度的嚴謹性。 當您變更索引時，例如新增或移除欄位，使用程式代碼更新來協調架構變更。
權衡。 針對索引新增、更新和刪除動作的成本很高。 根據數據存放區大小和效率，考慮更新的頻率和效能成本。 在索引中保留過時的檔會產生記憶體、維護和查詢成本。
部署策略
部署策略。 更新索引的主要策略有兩種。
並存部署。 在此方法中，具有更新的新索引會與現有索引並存。 在測試新的索引並完全運作之後，查詢會切換為使用更新的索引。 應用程式仍然不知道這個參數，因為它只會與新的索引互動。 如果您在將新索引部署至生產環境使用之後發現其他問題，則可以還原為舊索引。 這種方法可將停機時間降到最低，並確保持續可用性。
當重建索引的成本合理且可在合理的時間範圍內完成時，並存更新運作良好。 一般而言，由於較大的索引耗用更多資源，因此盡量保持索引的效率。 定期監視和維護索引，以避免不必要的成長。
提示
當您執行資源密集型數據前置處理工作，例如實體辨識、查閱和計算時，請考慮儲存結果的複本。 此方法可確保當您需要重建索引時，可以避免重做所有計算。 某些計算可能不再適用，因為刪除或更新，但許多計算仍會保持相關。
就地更新部署。 此方法會直接修改現有的索引。 節省重複成本可能很有説明，但也會因為潛在的停機時間和資源密集型作業而造成風險。 如果您的索引很大，並從頭開始重建它超過所需的更新頻率，您可以考慮使用就地更新。 不過，這種方法具有挑戰性，而且有可能違反您的服務等級目標 （SLO）。
權衡。 針對部署新增、更新和刪除的就地更新，評估並存部署索引的成本。 在大部分情況下，您應該使用並存更新，而不是就地更新。 重建索引時，程式會有效地處理刪除和更新，因為它會建立全新的數據集。 此策略提供測試數據的機會。 雖然並存部署會暫時重複數據併產生額外的成本，但測試和效能評估的優點通常可證明此記憶體需求合理。 在讓索引上線之前，請先檢查數據，以確保其符合您的預期。排程的更新。 您可以定期重新整理地面數據，而不是維護與數據源的持續實時通訊。 這種方法可確保數據會透過排程的更新保持相關，而不需要持續互動。
緊急更新。 可能發生非預期的情況，例如不小心外泄至搜尋索引的垃圾數據。 如果發生此問題，您可能需要立即採取行動，例如移除特定檔或調整索引中的數據。 無論您選擇的部署策略為何，例如並存更新或就地更新，一律規劃緊急作業的可能性。
自我更新索引。 如果您的索引技術支援自動更新索引，使其與外部數據源保持同步，它或許可以自動處理數據中的變更。 數據變更包括新增或刪除，而不需手動介入。 請記住，每個變更都會觸發索引中的作業，這會耗用資源。 索引可能會繼續回應查詢，但其處理查詢的容量可能會在更新程序期間減少。
Freshness 作業
測量源數據建立或修改與索引新增為指標之間的時間範圍，並針對 SLO 進行追蹤。 此指標會推動數據決策來更新資料管線設計，以確保當您需要數據時，可在索引中使用數據。 索引應該只如同必要一樣新鮮。
若要維持新鮮度，您可以完全重建索引，或以累加方式更新索引，以保持與原始數據源的同步。 這兩種方法可確保索引保持最新且正確。
預先對微調模型的投資可能比實作 RAG 模式、提示工程和數據增強方法的成本要低。