Azure AI 搜索中的搜索索引

在 Azure AI 搜索中， 搜索索引 是可供搜索引擎用于索引、全文搜索、矢量搜索、混合搜索和筛选查询的可搜索内容。 索引由架构定义并保存到搜索服务中，第二步是数据导入。 此内容存在于搜索服务中，除了主要数据存储之外，这对于新式搜索应用程序中预期的毫秒响应时间是必要的。 除了索引器驱动的索引场景外，搜索服务永远不会连接到源数据或查询源数据。

本文介绍创建和管理搜索索引的关键概念，包括：

• 内容（文档和架构）
• 物理数据结构
• 基本操作

小窍门

想要立即开始？ 请参阅 “创建搜索索引”。

搜索索引的架构

在 Azure AI 搜索中，索引包含搜索文档。 从概念上讲，文档是索引中的一个可搜索数据单元。 例如，零售商可能为每件商品都创建了文档，大学可能为每个班级创建了文档，旅游网站可能为每家酒店和每个目的地都创建了文档等等。 将这些概念对应到更为熟悉的数据库等效对象：搜索索引等同于表，文档大致相当于表中的行。

文档的结构由索引架构确定，如以下示例所示。 通常，索引中大部分都是“字段”集合，其中每个字段都已命名、分配了数据类型，并具有允许行为的属性（确定该字段的用法）。

{
  "name": "name_of_index, unique across the service",
  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees."
  "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 embedding 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){ }
}

为了简洁起见，其他元素会折叠，但以下链接提供了详细信息：

• 建议器支持预先输入查询，例如自动完成。
• scoringProfiles 用于相关性优化。
• 分析器用于根据分析器支持的语言规则或其他特征，将字符串处理成令牌。
• corsOptions（或跨域远程脚本 (CORS)）用于发出来自不同域的请求的应用。
• encryptionKey 在索引中配置敏感内容的双重加密。
• 语义配置在全文和混合搜索中进行语义重新排序。
• vectorSearch 配置矢量字段和查询。

字段定义

创建索引请求主体中的“fields”集合定义了一个搜索文档。 你需要用于文档标识（键）、存储可搜索文本的字段，以及用于支持筛选器、各个方面和排序的字段。 你可能还需要为某个用户永远看不到的数据设置字段。 例如，你可能需要利润率或营销促销字段，以便在计分概要文件中使用这些字段来提高搜索分数。

如果传入数据本质上是分层的，则可在索引中将其表示为用于嵌套结构的复杂类型。 内置的示例数据集 Hotels 演示的复杂类型使用一个 Address（包含多个子字段），其中有与每个酒店的一对一关系，并且有一个 Rooms 复杂集合，其中有多个房间与每个酒店相关联。

字段属性

字段属性决定了字段的使用方式，例如，是否用于全文搜索、分面导航和排序等操作中。

字符串字段通常标记为“searchable”和“retrievable”。 用来缩小搜索结果范围的字段包括“sortable”、“filterable”和“facetable”。

特征	说明
“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 类型的字段为可筛选，“sortable”或“facetable”字段的长度最多可以是 32 千字节。 有关详细信息，请参阅创建索引 (REST API)。
“key”	文档在索引内的唯一标识符。 必须仅选择单个字段作为键字段，并且它必须是 Edm.String 类型的。
“retrievable”	决定了是否可以在搜索结果中返回此字段。 当希望将某个字段（例如“利润率”）用作筛选器、排序或评分机制，但不希望该字段显示给最终用户时，这很有用。 对于 true 字段，此属性必须为 key。

尽管可以随时添加新字段，但在索引的生存期内现有字段定义将被锁定。 因此，开发人员通常使用 Azure 门户创建简单索引、测试创意，或者使用 Azure 门户页面来查找设置。 如果采用基于代码的方式以便可以轻松重新生成索引，那么对索引进行频繁迭代的设计就更为高效。

注意

用于生成索引的 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”会消耗更多存储。
• 建议器极可能增加索引大小，但并不会像屏幕截图所示那么大（所有能感知建议器的字段都被选中，大多数索引中不太可能出现这种情况）。

未在前表中反映出的还有分析器的影响。 如果使用 edgeNgram 分词器来存储逐字字符序列 (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 搜索

1. 从 Azure 门户开始。 Azure 订阅者或创建搜索服务的人员可以在 Azure 门户中管理搜索服务。 Azure 订阅需要为“参与者”或具有更高权限才能创建或删除服务。 此权限级别足以在 Azure 门户中完全管理搜索服务。

2. 尝试其他客户端进行编程访问。 建议根据快速入门完成前几个步骤：

   • 快速入门：REST
   • 快速入门：全文搜索
   • 快速入门：RAG（使用 Visual Studio Code 和 Jupyter 笔记本）

后续步骤

你几乎可以使用 Azure AI 搜索的任何示例或演练来亲身体验如何创建索引。 对于初学者，可以从目录中选择任何快速入门。

但你最好也要熟悉加载索引和数据的方法。 索引定义和数据导入策略是一起定义的。 以下文章提供有关如何创建和加载索引的详细信息。

• 创建搜索索引
• 更新索引
• 创建矢量存储
• 创建索引别名
• 数据导入概述
• 加载索引