Azure 上 AI 工作負載的數據平臺
數據平臺是一組整合式技術，其設計目的是藉由內嵌源數據，然後篩選、匯總和準備取用工作負載需求來管理工作負載需求。
數據具有根據其預期用途的不同特性。 強烈建議您先瞭解良好數據管線設計的原則，再探索本文所描述的技術功能。 如需詳細資訊，請參閱訓練數據設計和基礎數據設計。
當數據位於管線中的特定點時，平臺也會滿足記憶體需求。 如果工作負載很複雜並處理大規模數據，您可以將管線工作分散到各種元件之間。 針對更簡單的使用案例，評估您是否可以在提供這些合併功能的存放區中使用源數據。
詢問下列問題，讓您避免為數據平台設計過於複雜的架構。 最好在可以的時候讓事情保持簡單。
- 您的應用程式是否可以透過從單一來源內嵌數據來擁有預期的預測能力？
- 您最初選擇的數據存放區是否支援資料倉儲功能？
- 源數據是否已針對 AI 搜尋進行優化？
如果您回答這些問題是，則可以允許應用程式直接存取數據源，以簡化架構。 這種方法不需要巨量數據架構元件，例如數據擷取、分析存放區整合和外部數據處理。 如果源資料庫可以處理必要的搜尋，則直接將搜尋索引功能整合到源資料庫可能是一種實用方法。 請確定來源可以符合成本效益地調整以符合新的需求。
例如，Azure Cosmos DB 支援向量搜尋，因此您可能不需要另一個索引。 另一個使用案例是使用讀取複本作為搜尋作業的端點。 對於具有讀取複本的 SQL 資料庫，直接搜尋這些複本可以優化效能。 利用資料庫的內建功能，盡可能簡化架構。
適用於大規模工作負載的數據平台架構更為複雜。
從多個數據源擷取數據，以及跨各種平臺協調搜尋可能會變得複雜且沒有效率。 此外，您仍然需要一些擷取、轉換和載入 （ETL）：擷取、載入和轉換 （ELT）：或擷取和載入 （EL） 程式，以重新塑造資料存放區中的數據。 當數據需要更多處理時，案例會變得更複雜。 您需要將許多元件新增至架構，以處理端對端管線，從擷取到提供查詢。 許多巨量數據技術都是高度特製化且專為有效處理這些處理工作而建置的。
其中一種技術是搜尋索引。 新增個別索引的主要優點是能夠有效率地管理查詢，並處理具有高輸送量的大量數據。 此函式會從原始數據源卸除 AI 功能，讓索引可以專注於其主要功能，提供查詢。
根據平臺的特定功能和用途選擇平臺，並考慮您的功能和技術需求。 如果您的架構正在演進以處理複雜的使用案例，請專注於下列有關匯總數據存放區、處理管線和搜尋索引的章節。
建議
以下是本文所提供的建議摘要。
| 建議 | 描述 |
|---|---|
| 建置安全、高效能且符合成本效益的數據存放區。 | 數據平臺的關鍵部分是一種數據存放區，可匯總多個來源的數據，並允許與各種整合工作整合。 這有助於您的工作負載大規模執行。 請務必檢閱數據存放區的各種功能和非功能性需求，以確保符合成本效益的部署。 ▪ 儲存匯總數據的考慮 |
| 遵循數據擷取和處理的最佳做法。 | 高品質數據可協助改善工作負載和用戶體驗的可靠性。 請考慮工作負載的需求，以及建置有效率的擷取和數據轉換程式的重要最佳做法，以協助維護高品質的條形圖。 ▪ 處理數據的考慮 |
| 設計可靠且相關的搜尋索引。 | 目標是高效能、寫入一次、讀取多的數據存放區，以有效率地處理即興查詢和模糊查詢，將相關結果傳遞給您的使用者基底，即使查詢不精確也一定。 ▪ 搜尋索引的考慮 |
| 確定功能數據存放區會大規模執行。 | 視工作負載的功能需求而定，您可能需要建立功能數據存放區，例如離線推斷。 請務必使用指定的函式來建立數據存放區，並套用函式的最佳做法。 ▪ 功能存放區的考慮 ▪ 離線推斷數據存放區的考慮 |
儲存匯總數據的考慮
在 AI 工作負載中，數據會隨著管線的協助，在儲存和處理的各個階段移動，以協調這些階段之間的工作流程。 其中一個關鍵階段是數據存放區，其中包含從多個來源擷取和匯總的數據。 您需要此存放區進行處理，直到數據達到適合定型或編製索引的狀態為止。 主要重點是確保數據能準確地反映其來源。
注意
替代方法是直接存取數據源。 不過，這種方法可能會導致效能問題，因為它可能會多載具有 AI 功能的來源系統。 也可能有數據存取問題。 若要避免這些問題，建議您將數據複製到此存放區。
此存放區的數據平臺應符合數據源所套用的安全性標準、符合成本效益，並支援與 ETL、ELT 和 EL 處理工作的整合。 選項會根據數據量，從基本記憶體到巨量數據技術而有所不同。 選擇經濟型記憶體，以協助您達到足夠的可靠性和效能。
下一節提供當您選取數據存放區技術時要考慮的功能指引。 如需詳細資訊，請參閱 數據處理管線。
功能需求
平臺可以處理各種數據格式嗎？
數據存放區應該能夠儲存各種數據格式，並視需要將它們轉換成其他格式。
假設您的擷取管線會從關係資料庫和 Parquet 檔案源數據，因此它同時支持結構化和半結構化數據。 您想要根據其架構定義，將關係型數據轉換成 Parquet 格式。 數據平台應該具有內建功能，不需要撰寫自定義程式碼即可進行該轉換。
您是否預期會儲存多個版本的數據？
數據值和架構可能會隨著時間而變更，並管理多個版本的數據會變得很重要。
來源系統通常只會儲存目前的數據，而不是歷程記錄數據。 如果保留歷程記錄數據很重要，您可能需要從來源系統複製大型數據集。 在此情況下，版本控制可以釐清目前的數據與歷程記錄數據。
在某些情況下，您可能需要維護不同使用案例的數據複本。 若要支援此案例，您可能需要派生數據。 每個分叉都可以獨立變動，以提高其品質和可用性。 您的數據平台應該能夠維護這些分支的適當版本控制。
您的數據平台應該能夠儲存一段時間的數據版本，以提供歷程記錄內容。 此 contetxt 對於處理和定型 AI 模型很有幫助，因為它提供多個觀察，而不只是單一時間點。
平臺是否有內建的數據生命週期管理功能？
數據生命週期管理 （DLM） 是管理資料從建立到刪除的程式，其階段包括數據收集、記憶體、使用量、封存和處置。
若沒有 DLM，數據可能會不受控制地成長，通常會在經過品質層級時產生多個複本。 數據平台應該具有 DLM 功能，以防止未系結的數據成長。
請考慮此案例。 前置處理步驟必須重複以精簡數據，直到達到可接受的訓練質量為止。 您的數據平台應該能夠刪除資料的中繼複本。
在某些情況下，您可能需要保留數據以進行法規稽核。 數據平台應該具有不常存取數據的冷記憶體功能，因此您可以以較低的成本封存數據。
平臺是否支持數據控管功能？
可稽核性是 AI 工作負載的重要層面。 數據存放區應維護可追蹤數據存取、確保隱私權及了解數據源的稽核線索。
使用數據字典功能來管理元數據、數據類型、用途和譜系。 從多個來源擷取數據時，這項功能特別重要。
您是否打算使用生產數據進行訓練？
部署、模型部署和程式代碼部署有兩種方法。 在模型部署中，生產數據會用於開發中，這需要嚴格的安全性措施。 在程式代碼部署中，模型在生產環境之前不會看到生產數據。 雖然程式代碼部署可簡化開發環境中的安全性考慮，但它會增加計算成本。 無論您選擇哪一種方法，您的數據平臺都應該支持開發與生產環境的不同環境。
您是否將便利功能優先於重要功能功能？
當您選擇 AI 或機器學習的數據平臺時，不只依賴其筆記本功能。 雖然筆記本對於探勘數據分析很有用，但它們不應該是決定因素。 筆記本的計算資源通常不在匯總數據存放區的範圍之外。 它們通常會與其他資源整合，例如 Azure 機器學習。
非功能需求
您預期要儲存多少數據？
AI 工作負載會產生大量數據。 磁碟區可能會因為多個版本和額外的元數據而大幅增加。
記憶體和輸送量的延展性很重要。 數據平台必須有效率地取用內嵌管線中的數據，同時處理數據量、管理並行寫入，並確保個別寫入效能不會降低。 這些準則也適用於讀取、處理甚至回寫至存放區的處理管線。
當您做出決策時，請考慮整個程序，因為擷取和處理通常會同時發生。 設計必須能夠管理頻繁的數據移動和處理。 數據平台應該提供高層級的平行處理原則，以有效地處理數據。
平臺技術應該發出遙測，以深入了解讀取和寫入作業的輸送量和效能。
此數據是否儲存重要元件，有助於工作負載的可靠性目標？
選擇使用多個實例來增強可靠性和延展性的數據存放區。 巨量數據存放區通常會有內建控制器，可協調跨實例的數據處理。 如果一個復本失敗，則可以使用另一個複本。
請記住，如果數據不正確或無法存取，則不會提供其用途。 數據平臺應保證持久性，並確定數據保持不變。 請確定可存取查詢數據的 API。 此外，請考慮具有備份功能的數據存放區。
一般而言，您不需要備份此數據。 不過，如果每次從頭開始匯總數據的成本相當高，您可以考慮從備份重新凍結數據。
您是否有任何成本限制？
如果數據可靠性和效能已足夠，請考慮成本影響。
系統應該針對寫入優化 一次，讀取許多 ，以避免在數據記憶體上超支。 定型或地面數據很重要，但不像生產資料庫那樣重要，這需要立即回應。 重點是平衡成本，效率剛好，以最大化投資報酬率。
上述需求可能會自然導致您考慮使用 Data Lake，因為它提供 DLM、品質層級、可觀察性，以及各種檔格式的支援。 如果您的工作負載已經使用 Data Lake，請利用該資源來符合您的 AI 需求。 或者，您可以選擇其他記憶體選項，例如 Azure Blob 儲存體，以提供某種層級的 DLM、監視功能和高交易速率。
處理數據的考慮
您必須處理匯總數據存放區中的數據，以增加其下游公用程式。 ETL 管線會執行這項工作，這在下列幾點最為重要：
擷取層
管線負責從各種來源收集數據，並將其移至匯總數據存放區。 在此程式期間，管線通常會執行基本前置處理，甚至可能以可查詢格式建構數據。
若要將自定義程式代碼的需求降到最低，建議您將大部分責任卸除至數據平臺。 當您選取技術時，請考慮支援模型定型和增強所需的 ETL 特性。
處理層
匯總數據存放區中的數據會經過廣泛的處理，才能用於編製索引或模型定型使用案例。 處理管線需要與擷取管線類似的可靠性和調整層級。 主要差異在於對數據完成的處理類型。
此程式牽涉到數據的重大重新複製和重組。 此程式包含實體辨識、將其他數據整合到數據集，以及執行查閱等工作。 此程式也可能包括刪除不必要的數據，以及透過資料協調流程平臺套用數據邏輯。
數據處理階段可以產生各種輸出，這些輸出會落入不同意圖的不同目的地。 其主要目標是準備和傳輸來自匯總數據存放區的數據，以供最終目的地取用。 取用者可以在需要時提取數據，或者處理層可以在數據就緒時推送數據。
注意
在機器學習和產生 AI 的內容中，區分 ETL、ELT 和 EL 程式非常重要。 傳統 ETL 對於數據倉儲和對象關係型對應至關重要，因為架構限制，因此必須先轉換數據，才能將它載入目標系統。 ELT 牽涉到擷取數據、將數據載入數據湖中，然後使用 Python 或 PySpark 之類的工具加以轉換。 在產生式 AI 中，特別是為了擷取增強的產生（RAG），此程式通常涉及先擷取和載入檔到記憶體，然後是區塊化或影像擷取等轉換。
下一節提供當您選取具有 ETL 功能的數據處理技術時所要考慮的指引。
功能需求
線上至數據源的支持為何？
需要處理的數據可能會儲存在關係資料庫、巨量數據源或各種記憶體解決方案中。
大部分的數據處理技術都支援預先建置的整合，可讓您連線到各種數據源，而不需要撰寫程序代碼。 連接器具有功能，例如能夠將數據從來源複製到接收、執行查閱，以及套用某種形式的數據控管。 有一些工具提供拖放功能，以避免不必要的程式代碼撰寫。
選擇可輕鬆地與預期的數據源整合的數據平臺。
平臺可以處理各種數據格式嗎？
數據可能以各種格式提供，例如資料庫和 JSON 等結構化數據、影像和檔等非結構化數據，或從物聯網裝置串流數據。 管線應該能夠處理預期的檔類型。
平臺是否提供數據準備和重新複製的功能？
您必須處理您想要用於定型或擴增的數據，直到適合定型、微調或編製索引為止。 您的數據設計策略應該明確概述需求。
下列文章說明特定考慮：
作為基本清理的一部分，平臺會移除重複專案、填入遺漏值，並在擷取期間消除多餘的雜訊。 針對某些使用案例，例如實作RAG模式，建議您使用小寫區塊。
雖然這些前置處理步驟是必要的，但平臺也必須支援您需求特有的豐富數據操作。 此程式牽涉到載入、重新複製和轉換數據。 針對特定模型，平臺必須能夠查詢外部來源以進行檔分析，例如文件智慧或其他 AI 工具。 準備數據和數據擴充時，需要這項工作。
如果您的資料存放區支援此層級的處理，您可以在存放區中當地語系化此階段，而不需要將它移至別處。 否則，您需要外部技術，例如 Azure Databricks 或 Azure Data Factory。 這些技術適用於行動數據和執行操作，例如篩選、填滿遺漏值，以及標準化字串大小寫。 對於更複雜的工作，通常需要作業裝載平臺。 您可以使用 Spark 集區來進行巨量數據協調流程。
在某些使用案例中，您可能會想要將此責任外部化給數據的取用者。 例如，使用機器學習的 AI 模型提供作業處理功能，以使用自訂 Python 程式代碼來讀取、操作和寫入數據。
另一個範例是RAG實作。 常見的處理步驟是區塊化，其中檔分成多個區塊，而每個區塊都會成為索引中的數據列。 它也會儲存 OpenAI 服務通常針對這些區塊產生的內嵌。 在 AI 搜尋中，不論使用 OpenAI 還是 Azure AI 搜尋，此程式都是在編製索引工作流程內進行協調。
是否有用於管理工作流程的內建協調器？
處理工作是模組化的，並以作業的形式執行。 平台應該具有協調流程功能，將工作流程分解成步驟或作業。 每個作業都應該獨立定義、執行及監視。
在複雜的工作流程中，某些步驟取決於先前步驟的成功完成。 協調器應該處理作業相依性，並確定工作會以正確的順序完成。
數據設計是反覆的程式，因此協調器工具應該有足夠的彈性，以便輕鬆地修改工作流程。 您應該能夠插入新的步驟，或調整現有的步驟，而不需要重寫大量的程序代碼。
Data Factory 是熱門的選擇，因為它提供豐富的功能集來管理數據工作流程。 Azure Databricks 也可以管理複雜的工作流程和排程和監視作業。 您也應該考慮成本影響。 例如，Azure Databricks 功能可能非常廣泛，但成本也很高。 開放原始碼替代選項，例如 Apache NiFi，可能更具成本效益。
最後，您選擇的工具取決於貴組織允許的內容，以及工作負載小組所熟悉的技能。
非功能需求
當您選擇處理管線時，平衡輸送量和可觀察性非常重要。 管線必須在足夠的時間範圍內可靠地處理和降落模型或索引的必要數據。 它應該足夠輕量，以支援您目前的需求，並可調整以在未來成長。 Teams 必須決定他們需要多少時間來證明平臺，以避免稍後發生技術債務。 主要考慮包括數據擷取的頻率和數量、程式的可靠性，以及能夠及時監視和解決問題的需求。
您預期要擷取多少數據？
針對擷取和處理階段，請考慮平臺的延展性和處理工作速度。 例如，您預期每天將 10 TB 的數據載入索引或模型定型。 您的數據擷取平臺應該能夠處理那麼多的磁碟區和預期的輸送量。 在此情況下，使用 Azure Logic Apps 可能不可行，因為它可能會在這類負載下失敗。 相反地，Data Factory 更適合這種數據處理規模。
處理大量量的其中一種方式是透過平行處理原則，因為它允許更有效率的數據處理和處理。 Azure Databricks 等平臺可以藉由為相同的作業建立多個實例並有效率地散發負載，藉此協調工作。
此外，請考慮可容忍的延遲和作業的複雜度。 例如，數據清理涉及驗證並可能取代無效的欄位或遮罩敏感性資訊。 這些工作雖然基本，但需要大量資源，因為每個數據列都會個別處理，這會增加整體時間。
您需要哪些監視功能？
數據處理管線應該具有監視功能，並提供管線作業效能和狀態的深入解析。
您必須能夠追蹤作業的進度。 假設管線會執行未完成或部分完成的數據清理作業。 可能會對定型模型的數據品質造成下游影響，這可能會影響預測能力。
與工作負載中的其他元件類似，您應該啟用數據管線上的記錄、計量和警示，以瞭解其行為。 收集和分析效能計量，以瞭解效率和可靠性層面。
識別內建遙測中的任何差距，並判斷您需要實作哪些額外的監視。 這項監視可能包括新增自定義記錄或計量，以擷取作業步驟的特定詳細數據。
您預期數據處理平臺的可靠性為何？
數據處理管線的可靠性會根據平台的選擇而有所不同。 雖然 Logic Apps 具有協調流程功能，但可能不如 Data Factory 那麼可靠。 Data Factory 裝載於 Azure Kubernetes Service （AKS） 叢集上，可能有不同的可靠性特性。
單一實例設定會被視為失敗點。 選擇支援可靠性功能的平臺，例如多個實例，以符合您的需求。
平臺也應該支持復原功能。 例如，協調器應該會自動重試失敗的工作，以減少手動重新啟動的需求。
根據數據新鮮度和延遲需求，批處理比推斷更可靠。 如果每周進行定型，且處理需要一天的時間，則偶爾會因為有足夠的時間重試而無法接受失敗。
是否有任何成本限制？
當您考慮數據處理管線的成本效益時，請務必選擇符合您需求的解決方案，而不需要不必要的費用。 如果您的需求無法證明 Azure Databricks 的進階功能合理，則 Data Factory 之類的更經濟的選項可能就已足夠。 此外，Apache Airflow 或 Apache NiFi 等開放原始碼工具可以降低成本來提供強大的功能。 關鍵是避免對不需要的功能超支，並選取平衡功能和成本效益的平臺。
工作流程和您處理之數據的安全性需求為何？
請清楚瞭解安全性、隱私權和數據落地需求。 例如，請考慮任何地理法規需求。 確保數據儲存並處理於特定區域內，以符合數據落地需求。 您可能需要針對不同的區域執行不同的管線，例如歐洲的管線，另一個用於美國，以符合當地合規性法規。
數據管線平臺應該支援身分識別和存取管理，以確保只有授權的身分識別可以存取工作流程內的特定作業或步驟。 例如，如果您的 ETL 程式包含數個工作流程，其中一個工作流程會處理高度機密的數據，則平臺應該可讓您限制該工作流程的存取，同時讓其他人保持可存取性。 這項功能可協助您滿足安全性需求，而不需要不同數據敏感度層級的個別平臺。 在理想情況下，平台應該提供這類隔離的內建支援，以便有效率且安全的數據管理。
數據處理管線可以將數據輸出至搜尋索引或模型定型管線。 視使用案例而定，請參閱搜尋索引或功能存放區的區段。
搜尋索引的考慮
搜尋索引的設計目的是儲存內容相關或地面數據，以傳送至模型推斷端點，以及提示。 這兩個呼叫、索引查詢和推斷端點調用都會在服務相同用戶端 HTTP 要求的內容中進行。 不同於處理離線和批次作業的 ETL 程式，此索引支援即時推斷，這需要高效能和可靠性。 它是針對 AI 查詢而特製化，並提供關鍵詞索引編製和篩選等功能，這不是巨量數據存放區的典型功能。 目標是要有高效能、 寫入一次、讀取多 的數據存放區，以支援即興和模糊查詢。 此數據存放區可以提供相關結果，而不需要精確的查詢。
功能需求
搜尋索引支援哪些類型的搜尋？
系統收到的查詢基本上是搜尋，而且索引必須支持豐富的搜尋功能。 針對RAG，向量搜尋不可談判，因為數據會儲存為計算向量或內嵌，用於搜尋。
向量搜尋功能強大，並結合篩選和全文搜索可增強搜尋索引的有效性。 您的數據設計應該考慮結合這些類型的搜尋，例如向量、全文搜索、篩選，以及地理位置等特殊數據類型。
您的數據設計應該明確陳述這些需求。 如需詳細資訊，請參閱 數據設計中的有效率查詢。
索引是否支援多模式數據？
選擇支援多模式數據的索引技術。 例如，AI 搜尋可以分析電子郵件、將影像轉換成向量，並將描述儲存在索引中。 使用此函式可搜尋各種內容形式，包括影像、影片和音訊檔案。
當數據源中的數據變更時，索引是否支持自動更新功能？
選擇具有自動更新功能的索引。 如果無法使用，您必須手動偵測並推送變更至索引。 利用這些功能，索引器可以偵測數據源中的變更，並自動提取更新。 藉由將此責任卸除至平臺，您可以降低作業額外負荷並簡化維護程式。
非功能需求
索引可以使用大量數據執行嗎？
索引應該能夠處理大量數據、可調整，並針對大量搜尋工作負載執行良好。 索引會儲存原始數據，以及與其相關聯的所有元數據、擴充和實體。 在RAG模式的內容中，分割成多個區塊的單一檔可能會導致數據量大幅增加。
索引是否有內建的可靠性功能？
請考慮推斷端點或模型的可靠性與數據存放區之間的對齊方式，因為它們彼此相依。
搜尋程式包含兩個步驟：查詢數據存放區，然後查詢推斷端點。 這兩個步驟都需要有類似的可靠性特性。 平衡這兩個元件之間的可靠性目標，以確保搜尋效率。
為了確保復原能力，工作負載應支持預期的並行用戶數目，並有足夠的頻寬來處理流量激增。 在理想情況下，平臺應該在區域性中斷中倖存下來。
數據平台應該設計成防止使用損毀的索引進行推斷。 在這種情況下，您應該能夠輕鬆地重建索引。 索引也應該支援索引之間的可靠交換，方法是使用別名之類的功能，將索引交換期間的停機時間降到最低。 如果沒有這項功能，您可能需要依賴索引的備份。 管理備份具有更複雜的功能。
從工作負載的觀點來看，瞭解潛在的失敗模式或壓力指標，例如節流。 例如，雖然系統通常可能支援 50 個並行使用者，但在以背景作業方式執行的重新編製索引程式期間，它可能只支援 30 位使用者。 在此情況下，背景工作的時間變得很重要。 當您評估索引的輸送量時，請同時包含前端查詢和後端作業。
這項技術的主要成本驅動因素為何？
當您建立成本模型時，請估計與數據量、查詢數目和索引預期輸送量相關聯的費用。 請記住，索引大多是平臺即服務（PaaS），其中定價是抽象的。 研究層級及其功能，以避免過度支付未使用的容量或功能。
例如，AI 搜尋會以單位計費，其中包括容量、輸送量和記憶體。 額外的功能可能會導致更多費用。 例如，大量使用影像擷取功能可能會導致高帳單。 相依性，例如技能集功能，位於索引範圍之外，但屬於數據處理的一部分，可能會產生額外的成本。
在不使用完整容量的情況下支付階層費用可能會導致超額付款。 同樣地，索引中的數據表數目，以及處理並行流量的能力會影響成本。
若要瞭解與 AI 搜尋相關聯的成本，請參閱規劃和管理 AI 搜尋服務 的成本。
索引的安全性功能是否符合安全性數據設計？
您的數據設計應該清楚指定安全性和隱私權需求。 在使用實際生產數據的開發和測試環境中，索引應該支援符合所有訪問控制和可追蹤性量值的功能。 檢閱安全性功能，例如數據遮罩，以及移除索引中的個人資訊。
選擇索引，其能夠透過 Microsoft Entra 識別碼唯一識別用戶端。 搜尋索引也應該支援檔層級訪問控制，以允許依身分識別查詢相關性。 如果索引不提供這些功能，請調整您的設計，以使用查詢篩選達到類似的功能。 如需詳細資訊，請參閱 AI 搜尋中修剪結果的安全性篩選。
在理想情況下，搜尋索引應該符合網路安全性需求。 例如，如果您需要篩選非Microsoft網站的輸出流量並維持可觀察性，索引應該提供輸出控件。 它也應該支持網路分割。 如果後端計算位於虛擬網路中，密鑰元件的私用連線能力，包括索引，對於避免公開因特網而言很重要。 索引應該能夠輕鬆地與專用網整合，並支援透過 entra ID Microsoft 進行驗證的受控識別。
功能存放區的考慮
針對歧視模型，您的數據設計可能包含一個中繼數據存放區，可快取數據以進行額外精簡。 這個存放區稱為功能存放區，可讓數據科學家將特徵儲存為匯總數據存放區以外的最後一個步驟。
功能存放區可藉由新增產生時間和來源等元數據，協助編錄多個用途的目錄數據。 此中繼登陸點非常適合用於 黃金定型數據。
機器學習 中的 受管理的功能存放區 是與 MLflow 和其他工具整合的數據儲存選項。 它會從匯總數據存放區擷取和定型數據，為 機器學習 內更好的數據譜系和正式識別新增可重複使用的圖層。
當您使用功能存放區時，請將其視為具有安全性和存取考慮的數據存放區。
離線推斷數據存放區的考慮
在某些情況下，個別存放區的使用適用於更快速的未來查閱，因為預先收集及預先計算的數據會先進行推斷。 在此程式中，使用者要求永遠不會到達 AI 模型。 有幾個優點：
- 藉由減少延遲來改善效率和用戶體驗。 結果會更快提供給頻繁的查詢，例如產生結果常見問題。
- 推斷呼叫可以更輕鬆地相應放大為批處理，而不需要即時處理的條件約束。
- 允許預先驗證確保生產之前的正確性。
- 由於要求不會導向至干擾端點，因此會減少負載，從而影響工作負載的可靠性。
- 可能更具成本效益，因為它可減少實時處理所需的高效能硬體需求。
不過，只有在您可以預測可能的要求 ，而且 用戶預期會有相當一部分的預測時，此方法才有效。 對於重複要求較少的案例，離線推斷存放區可能較不有效。
此案例的數據存放區應針對讀取作業優化，必須能夠處理大量數據並提供有效率的擷取。 它也應該能夠整合到匯總的數據存放區。 任何具有這些功能的存放區都可以考慮，例如 Azure Cosmos DB，甚至是數據表記憶體。
資源
這些文章提供有關 Azure 產品的詳細資訊，建議您作為本文所討論考慮的技術選項。