Azure AI 搜尋服務中的搜尋索引
在 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 搜尋服務的範例或逐步解說，進行建立索引的實際操作。 若是初學者，您可以選擇目錄中的任何快速入門。
但您也會需要熟悉使用資料載入索引的方法。 索引定義和資料匯入策略會在同一時間定義。 下列文章提供有關建立和載入索引的詳細資訊。