本文示範如何建立搜尋服務，讓使用者除了與檔案相關聯的任何元數據之外，還要根據文件內容搜尋檔。
您可以在 Azure AI 搜尋中使用多個索引器來實作這項服務。
本文使用範例工作負載來示範如何建立以 Azure Blob 儲存體 檔案為基礎的單一搜尋索引。 檔案元數據會儲存在 Azure 數據表 儲存體 中。
架構
資料流程
- 檔案會儲存在 Blob 儲存體 中，可能與有限的元數據一起儲存（例如檔作者）。
- 其他元數據會儲存在數據表 儲存體 中，這可以儲存每個文件的詳細資訊。
- 索引器會讀取每個檔案的內容，以及任何 Blob 元數據，並將數據儲存在搜尋索引中。
- 另一個索引器會從數據表讀取其他元數據，並將其儲存在相同的搜尋索引中。
- 搜尋查詢會傳送至搜尋服務。 查詢會根據文件內容和檔元數據傳回相符的檔。
元件
- Blob 儲存體 為檔案數據提供符合成本效益的雲端記憶體，包括 PDF、HTML 和 CSV 等格式的數據，以及 Microsoft 365 檔案中的數據。
- 數據表 儲存體 為非關係結構化數據提供記憶體。 在此案例中，它會用來儲存每個檔的元數據。
- Azure AI 搜尋 服務是完全受控的搜尋服務，可提供基礎結構、API 和工具來建置豐富的搜尋體驗。
替代項目
此案例使用 Azure AI 搜尋 中的索引器，在支援的數據源中自動探索新內容，例如 Blob 和數據表記憶體，然後將它新增至搜尋索引。 或者，您可以使用 Azure AI 搜尋所提供的 API 將數據 推送至搜尋索引。 不過，如果您這麼做，您必須撰寫程式代碼，將數據推送至搜尋索引，以及剖析和擷取您想要搜尋的二進位檔中的文字。 Blob 儲存體 索引器支援許多檔格式，這可大幅簡化文字擷取和編製索引程式。
此外，如果您使用索引器，您可以選擇性地 擴充數據做為索引管線的一部分。 例如，您可以使用 Azure AI 服務來執行 光學字元辨識（OCR） 或 檔中影像的視覺分析 、 偵測文件語言 或 翻譯 檔。 您也可以定義自己的 自定義技能 ，以與商務案例相關的方式擴充數據。
此架構會使用 Blob 和數據表記憶體，因為它們符合成本效益且有效率。 此設計也可在單一記憶體帳戶中合併儲存檔和元數據。 檔本身支援的替代數據源包括 Azure Data Lake 儲存體 和 Azure 檔案儲存體。 檔元數據可以儲存在任何其他支持的數據源中，以保存結構化數據，例如 Azure SQL 資料庫 和 Azure Cosmos DB。
案例詳細資料
搜尋檔案內容
此解決方案可讓使用者根據檔案內容和針對每個檔個別儲存的其他元數據來搜尋檔。 除了搜尋檔的文字內容之外，使用者可能還想要搜尋檔的作者、檔案類型（例如紙張或報表），或其業務影響（高、中或低）。
Azure AI 搜尋 服務是完全受控的搜尋服務，可建立 搜尋索引 ，其中包含您想要允許使用者搜尋的資訊。
因為在此案例中搜尋的檔案是二進位檔，因此您可以將檔案儲存在 Blob 儲存體。 如果您這麼做，您可以使用 Azure AI 搜尋服務中的內建 Blob 儲存體 索引器，自動從檔案擷取文字，並將其內容新增至搜尋索引。
搜尋檔案元數據
如果您想要包含檔案的其他資訊，您可以直接將元數據與 Blob 產生關聯，而不使用個別存放區。 內建的 Blob 儲存體 搜尋索引器甚至可以讀取此元數據，並將其放在搜尋索引中。 這可讓用戶搜尋元數據以及檔案內容。 不過， 每個 Blob 的元數據數量限製為 8 KB，因此您可以在每個 Blob 上放置的資訊量相當小。 您可以選擇只將最重要的資訊直接儲存在 Blob 上。 在此案例中，只有檔的 作者 會儲存在 Blob 上。
若要克服此記憶體限制，您可以將其他元數據放在具有支援索引器的另一個數據源中，例如 Table 儲存體。 您可以將檔案類型、商務影響和其他元數據值新增為資料表中的個別數據行。 如果您將內建的數據表 儲存體 索引器設定為以與 Blob 索引器相同的搜尋索引為目標，則會針對搜尋索引中的每個文件合併 Blob 和數據表記憶體元數據。
針對單一搜尋索引使用多個數據源
為了確保這兩個索引器都指向搜尋索引中的相同檔， 搜尋索引 中的檔索引鍵會設定為檔案的唯一標識符。 接著會使用此唯一標識碼來參考這兩個數據源中的檔案。 Blob 索引器預設會使用 metadata_storage_path 做為 檔索引鍵。 屬性metadata_storage_path會將檔案的完整 URL 儲存在 Blob 儲存體，https://contoso.blob.core.windows.net/files/paper/Resilience in Azure.pdf例如 。 索引器會對 值執行Base64編碼，以確保檔索引鍵中沒有無效的字元。 結果是唯一的檔案索引鍵，例如 aHR0cHM6...mUucGRm0。
如果您在 Table 儲存體 中新增 metadata_storage_path 做為數據行，則確切地知道其他數據行中元數據所屬的 Blob，因此您可以在數據表中使用任何 PartitionKey 和 RowKey 值。 例如，您可以使用 Blob 容器名稱作為 PartitionKey 和 Blob 的 Base64 編碼完整 URL 作為 RowKey，確保這些密鑰中沒有任何無效字元。
然後，您可以使用數據表索引器中的欄位對應，將 Table 儲存體 中的數據行或另一個數據行對應metadata_storage_path至metadata_storage_path搜尋索引中的檔案索引鍵欄位。 如果您在欄位對應上套用base64Encode函式，則最後會使用相同的檔索引鍵（aHR0cHM6...mUucGRm0在先前的範例中），而 Table 儲存體 的元數據會新增至從 Blob 擷取的相同檔 儲存體。
注意
數據表索引器檔指出 ，您不應該定義數據表中替代唯一字串字段 的欄位對應。 這是因為索引器預設會串連 PartitionKey 和 RowKey 作為檔索引鍵。 由於您已經依賴 Blob 索引器所設定的檔索引鍵（這是 Blob 的 Base64 編碼完整 URL），因此請建立字段對應，以確保這兩個索引器參考搜尋索引中的相同檔是適當的，而且在此案例中受到支援。
或者，您可以 RowKey 直接將 （設定為 Blob 的 Base64 編碼完整 URL） 對應至 metadata_storage_path 檔密鑰，而不需將它分開儲存，並將它儲存為字段對應一部分的 Base64 編碼。 不過，將未編碼的 URL 保留在個別的數據行中，會釐清它所參考的 Blob，並可讓您選擇任何數據分割和數據列索引鍵，而不會影響搜尋索引器。
潛在使用案例
此案例適用於需要根據檔內容和其他元數據搜尋檔的應用程式。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。
可靠性
可靠性可確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性要素的概觀 (部分機器翻譯)。
如果您至少有兩個複本，Azure AI 搜尋會提供高服務等級協定 （SLA） 以進行讀取（查詢）。 如果您有至少三個複本，它會為 更新 提供高 SLA（更新搜尋索引）。 因此，如果您希望用戶能夠可靠地搜尋，而且如果索引的實際變更也需要高可用性作業，您應該布建至少兩個複本。
Azure 儲存體 一律會儲存數據的多個複本，以協助防止計劃性和非計劃性事件。 Azure 儲存體 提供額外的備援選項，以跨區域複寫數據。 這些保護措施適用於 Blob 和數據表記憶體中的數據。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性要素的概觀。
Azure AI 搜尋提供 強大的安全性控制 ，可協助您實作網路安全性、驗證和授權、數據落地和保護，以及可協助您維護安全性、隱私權和合規性的系統管理控制。
盡可能使用 Microsoft Entra 驗證來提供搜尋服務本身的存取權，並使用受控識別將搜尋服務連線到其他 Azure 資源（例如 Blob 和數據表記憶體）。
您可以使用私人端點，從搜尋服務連線到記憶體帳戶。 當您使用私人端點時，索引器可以使用私人連線，而不需要公開存取 Blob 和數據表記憶體。
成本最佳化
成本優化是減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。
如需執行此案例成本的相關信息，請參閱 Azure 定價計算機中的此預先設定估計值。 此處所述的所有服務都會在此估計中設定。 此估計值適用於 Blob 儲存體 中檔大小總計為 20 GB 的工作負載，以及數據表 儲存體 中 1 GB 的元數據。 有兩個搜尋單位可用來滿足 SLA 以供讀取之用，如本文的可靠性一節所述。 若要查看特定使用案例的定價如何變更，請變更適當的變數以符合您預期的使用量。
如果您檢閱估計值，您可以看到 Blob 和數據表記憶體的成本相對較低。 Azure AI 搜尋會產生大部分成本，因為它會執行執行搜尋查詢的實際索引和計算。
部署此案例
若要部署此範例工作負載，請參閱 在 Azure AI 搜尋中編制檔案內容和元數據的索引。 您可以使用此範例來：
- 建立必要的 Azure 服務。
- 將幾個範例檔上傳至 Blob 儲存體。
- 在 Blob 上填入 作者 元數據值。
- 將文件類型和商務影響元數據值儲存在數據表 儲存體 中。
- 建立維護搜尋索引的索引器。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- Jelle Druyts |首席客戶體驗工程師
其他參與者：
- 米克·阿爾伯特 |技術寫入器
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。