Azure AI 搜尋服務中的搜尋索引

文章
10/22/2024

在 Azure AI 搜尋服務中，搜尋索引是一種可搜尋內容，讓搜尋引擎用於編製索引、全文檢索搜尋、向量搜尋、混合搜尋，以及篩選查詢。索引會由架構再儲存至搜尋服務，第二個步驟是資料匯入。此內容位於您的搜尋服務中，而非主要資料存放區，這是現代應用程式保持毫秒級回應時間的必要條件。除了索引子驅動的索引編製案例之外，搜尋服務永遠不會連線或查詢來源資料。

如果您想要建立和管理搜尋索引，本文可協助您了解下列幾點：

內容 (銀箭和架構)
實體資料結構
基本作業

想要立即實際操作嗎？請改為參閱建立搜尋索引。

搜尋索引的結構描述

在 Azure AI 搜尋服務中，索引包含搜尋文件。就概念而言，文件是索引中可搜尋資料的單一單位。例如，零售商可能有每個產品的檔、大學可能有每個課程的檔、旅遊網站可能有每個旅館和目的地的檔等等。對應這些概念到更熟悉的資料庫同等項目：「搜尋索引」相當於「資料表」，而「文件」大致上相當於資料表中的「資料列」。

文件的結構取決於索引結構描述，如下列範例所示。「fields (欄位)」集合通常是索引中最大的一部分，其中每個欄位都有名稱、指派的資料類型和屬性，以及可決定其使用方式的可允許行為。

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

為保持版面簡潔，其他元素已經折疊，不過詳細資料可參考下列連結：

suggester 支援預先輸入查詢，例如自動完成。
scoringProfiles 用於相關性微調。
analyzers 可用來根據分析器所支援的語言規則或其他特性，將字串處理成權杖。
corsOptions 或稱跨來源遠端指令碼 (CORS) 用於從不同網域發出要求的應用程式。
encryptionKey 會設定索引中敏感性內容的雙重加密。
semantic 會設定全文檢索和混合式搜尋中的語意重新排名。
vectorSearch 會設定向量欄位和查詢。

欄位定義

搜尋文件是由建立索引要求內文中的「fields (欄位)」集合所定義。您需要文件識別 (索引鍵)的欄位、儲存可搜尋文字的欄位，以及支援篩選、Facet 和排序的欄位。您可能也需要不會向使用者顯示的資料欄位。例如，您可能想要利潤或行銷促銷欄位，用於在評分設定檔中提升搜尋分數。

如果傳入資料原本是階層式資料，您可以在索引內將其表示為複雜類型 (complex type)，以用於巢狀結構。內建的範例資料集「旅館」示範使用「地址」複雜類型 (包括多個子欄位)，其與每個旅館具有一對一關聯性，以及一個「房間」複雜集合，其中每個旅館與多個房間相關聯。

欄位屬性

欄位屬性會決定欄位的使用方式，例如，是否將它用於全文檢索搜尋、多面向導覽、排序作業等。

字串欄位通常會標示為 "searchable" (可搜尋) 和 "retrievable" (可擷取)。用來縮小搜尋結果的欄位包括 "sortable" (可排序)、"filterable" (可篩選) 和 "facetable" (可 Facet)。

屬性	描述
"searchable"	可全文檢索或向量搜尋。文字欄位受限於語彙分析，例如編製索引期間的斷詞功能。如果您為可搜尋欄位設定像是「sunny day」的值，則系統會在內部將其分割為「sunny」和「day」這兩個獨立的語彙基元。如需詳細資訊，請參閱全文檢索搜尋如何運作。
"filterable"	在 $filter 查詢中加以參考。類型 `Edm.String` 或 `Collection(Edm.String)` 的可篩選欄位不會執行斷詞功能，因此，只會針對完全相符的項目進行比較。例如，如果您將欄位 f 之類的欄位設為「sunny day」，`$filter=f eq 'sunny'` 就會找不到相符項目，但 `$filter=f eq 'sunny day'` 可以。
"sortable"	根據預設，系統會依分數來排序結果，但您可根據文件中的欄位設定排序。類型 `Collection(Edm.String)` 的欄位不能是 "sortable"。
"facetable"	通常用來呈現搜尋結果，其中包含依類別的叫用次數 (例如，特定城市中的旅館)。此選項無法與類型 `Edm.GeographyPoint`的欄位搭配使用。類型為 `Edm.String` 的欄位如果為 "filterable"、"sortable" 或 "facetable"，則長度上限為 32 KB。如需詳細資訊，請參閱建立索引 (REST API)。
「索引鍵」	索引內文件的唯一識別碼。您必須只選擇一個欄位作為索引鍵欄位，而它的類型必須是 `Edm.String`。
"retrievable"	判斷搜尋結果中是否會傳回該欄位。當您想要使用某個欄位 (例如 profit margin) 作為篩選、排序或評分機制，但不想讓使用者看見該欄位時，這非常有用。針對 `true` for `key` 。

雖然您可以隨時新增欄位，但現有的欄位定義會在索引的存留期間加以鎖定。基於這個理由，開發人員通常會使用入口網站來建立簡單的索引、測試概念，或使用管理入口網站頁面來查詢設定。如果您遵循以程式碼為基礎的方法，則整個索引設計中頻繁的反覆動作就會更有效率，如此便能讓您輕鬆地重建索引。

注意

您用來建置索引的 API 具有不同的預設行為。 REST API 預設會啟用大部分屬性 (例如，字串欄位的 "searchable" 和 "retrievable" 為 true)，而您通常只需要在想關閉時再設定即可。在 .NET SDK 當中則正好相反。針對任何未明確設定的屬性，對應的搜尋行為皆為停用，除非特別啟用。

實體結構和大小

在 Azure AI 搜尋服務中，索引的實體結構主要是內部實作。您可以存取其架構、查詢其內容、監視其大小及管理容量，但叢集本身（反向索引、向量索引、分區和其他檔案和資料夾）是由內部管理Microsoft。

您可以在 Azure 入口網站的 [搜尋管理>索引] 頁面中監視索引大小，或針對您的搜尋服務發出 GET INDEX 要求。您也可以發出服務統計資料要求，並檢查儲存體大小的值。

索引的大小取決於：

文件的數量和組合
個別欄位的屬性
索引組態 (特別是您是否包含建議工具)

文件組合和數量取決於您選擇匯入的內容。請記住，搜尋索引應該只包含可搜尋的內容。如果來源資料包含二進位欄位，除非使用 AI 擴充來破解和分析內容以建立文字可搜尋的資訊，否則請省略這些欄位。

欄位屬性會決定行為。為支援這些行為，索引編製程序會建立必要的資料結構。例如，針對 Edm.String 類型的欄位，"searchable" 會叫用全文檢索搜尋，以掃描權杖化字詞的反向索引。相反地，"filterable" 或 "sortable" 屬性支援反覆運算未修改的字串。下一節中的範例會顯示索引大小根據所選屬性的變化。

建議工具是支援預先輸入或自動完成查詢的建構。因此，當您包含建議工具時，索引編製程序會建立逐字字元比對所需的資料結構。建議工具會在欄位層級實作，因此請只選擇適合預先輸入的欄位。

示範屬性和建議工具對儲存體影響的範例

下列螢幕擷取畫面說明各種屬性組合所產生的索引儲存模式。此索引是以房地產範例索引為基礎，您可以使用匯入資料精靈和內建的範例資料輕鬆建立。雖然未顯示索引結構描述，但您可以根據索引名稱推斷屬性。例如，realestate-searchable 索引只選取 "searchable" 屬性，realestate-retrievable 索引僅只選取 "retrievable" 屬性。

雖然這些索引變體會受到人為影響，但我們可以參考這些變體，以便廣泛比較屬性如何影響儲存體：

"retrievable" 不會影響索引大小。
"filterable"、"sortable"、"facetable" 會耗用更多儲存體。
suggester (建議工具) 可能會增加索引大小，但不會像螢幕擷取畫面所顯示的這麼多 (建議工具可能感知的所有欄位都已選取，大部分索引通常不會選取這麼多項)。

上表也未反映analyzers (分析器) 的影響。如果您使用 edgeNgram Tokenizer 來儲存字元的逐字序列 (a, ab, abc, abcd)，索引的大小會比使用標準分析器時還大。

基本作業和互動

既然您已更清楚瞭解索引是什麼，本節將介紹索引執行階段的作業，包括連線至及保護單一索引。

注意

管理索引時需注意一點，沒有入口網站或 API 可支援移動或複製索引。作為替代，客戶通常會將其應用程式部署解決方案指向不同的搜索服務 (如果使用相同索引名稱)，或是修改名稱以在目前的搜尋服務上建立複本。

索引隔離

在 Azure AI 搜尋服務中，請一次使用一個索引，當中的所有索引相關作業都會以單一索引為目標。在編製索引或查詢方面，不存在相關索引或獨立索引聯結的概念。

持續可用

在第一份文件完成編製索引後，索引便立即可供查詢使用，但必須等到所有文件索引編製完成才能獲得完整功能。在內部，搜尋索引會分散到分割區，並在複本上執行。實體索引是由內部管理。邏輯索引是由您管理。

索引會持續可用，無法暫停或離線。因為索引是設計用於連續作業，所以其內容的任何更新或索引本身的新增都會即時發生。因此，如果要求與文件更新同時發生，查詢可能會暫時傳回不完整的結果。

請注意，文件作業 (重新整理或刪除) 以及不影響目前索引的現有結構和完整性的修改 (例如新增欄位)，將不會影響查詢持續性。如果您需要進行結構化更新 (變更現有欄位)，這些更新的管理方式通常是在開發環境中使用卸載和重建工作流程，或在實際執行服務上建立新版本的索引。

若要避免索引重建，某些進行小型變更的客戶會建立與舊版並存的新欄位，藉此保留欄位的各個「版本」。但隨著時間增長，這種做法會導致過時欄位或過時自訂分析器定義形式的孤立內容，特別是在成本高昂的實際執行索引中。您可以在索引生命週期管理流程中，透過索引計劃性更新來解決這些問題。

端點連線和安全性

所有索引編製和查詢要求都會以索引為目標。端點通常是下列其中一項：

端點	連線和存取控制
`<your-service>.search.windows.net/indexes`	以索引集合為目標。在建立、列出或刪除索引時使用。這些作業需要管理員權限，這些權限可透過系統管理員 API 金鑰或搜尋參與者角色取得。
`<your-service>.search.windows.net/indexes/<your-index>/docs`	以單一索引的文件集合為目標。在查詢索引或資料重新整理時使用。查詢只需要讀取權限即可，並可透過查詢 API 金鑰或資料讀取者角色取得。資料重新整理需要管理員權限。

如何連線至 Azure AI 搜尋服務

從 Azure 入口網站開始。 Azure 訂閱者或建立搜尋服務的人員可以在 Azure 入口網站中管理搜尋服務。 Azure 訂用帳戶需要「參與者」或更高權限才能建立或刪除服務。此權限等級足以在 Azure 入口網站中完全管理搜尋服務。
請嘗試使用其他用戶端以程式設計方式存取。我們建議進行第一個步驟的快速入門：

下一步

您可以使用幾乎所有 Azure AI 搜尋服務的範例或逐步解說，進行建立索引的實際操作。若是初學者，您可以選擇目錄中的任何快速入門。

但您也會需要熟悉使用資料載入索引的方法。索引定義和資料匯入策略會在同一時間定義。下列文章提供有關建立和載入索引的詳細資訊。

分享方式：