共用方式為

搜索 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.StringCollection(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 搜索中,索引的物理结构主要是内部实现。 可以访问其架构、加载和查询其内容、监视其大小和管理其容量。 但是,Azure 管理随搜索服务一起存储的基础结构和物理数据结构。

可以在 Azure 门户中的 “搜索管理 > 索引 ”页上监视索引大小。 或者,可以针对搜索服务或服务统计信息请求发出 GET INDEX 请求来检查存储大小的值。

索引的大小由以下项决定:

  • 文档的数量和构成。
  • 单个字段的属性。
  • 索引配置。 具体而言,是否包括建议器。

文档的撰写和数量将由你选择导入的内容决定。 请记住,搜索索引应该只包含可搜索的内容。 如果源数据包括二进制字段,请忽略这些字段,除非使用 AI 扩充破解和分析内容来创建文本可搜索的信息。

字段属性可确定行为。 为了支持这些行为,索引过程将创建必要的数据结构。 例如,对于类型为 Edm.String 的字段,“searchable”调用全文搜索,该搜索将扫描标记化术语的倒排索引。 相比之下,“可筛选”或“可排序”属性将支持对未修改的字符串进行迭代。 下一节中的示例显示了基于所选属性的索引大小的变化。

建议器是支持预先输入或自动完成查询的构造。 在包含建议器时,索引过程将创建逐字字符匹配所需的数据结构。 建议器是在字段级别实现的,因此请仅选择对预先输入而言合理的字段。

演示属性和建议器的存储意义的示例

以下屏幕截图演示了各种属性组合产生的索引存储模式。 该索引基于“房地产示例索引”,你可使用“导入数据”向导和内置的示例数据轻松创建该索引。 尽管未显示索引架构,但可以基于索引名称推断属性。 例如,只选择了 realestate-searchable 索引中的“searchable”属性,只选择了 realestate-retrievable 索引中的“retrievable”属性,等等 。

基于属性选择的索引大小

尽管这些索引变体是伪造的,但我们可以参考这些变体来对属性影响存储的方式进行大致比较:

  • “可检索”不影响索引大小。
  • “可筛选”、“可排序”、“可具面化”使用更多存储。
  • 建议器极可能增加索引大小,但并不会像屏幕截图所示那么大(所有能感知建议器的字段都被选中,大多数索引中不太可能出现这种情况)。

未在前表中反映出的还有分析器的影响。 如果使用 edgeNgram 分词器来存储逐字字符序列 (a, ab, abc, abcd),则索引大于使用标准分析器时的索引。

基本操作和交互

现在,你已更好地了解索引是什么,本部分引入了索引运行时作,包括连接到和保护单个索引。

注意

没有门户或 API 支持移动或复制索引。 通常,可以将应用程序部署指向其他搜索服务(使用相同的索引名称)或修改名称以在当前搜索服务上创建副本,然后生成它。

索引隔离

在 Azure AI 搜索中,一次使用一个索引。 所有与索引相关的操作都以单个索引为目标。 无论是编制索引还是查询,都不存在“相关索引”的概念或独立索引的联接。

持续可用

索引在索引第一个文档后立即可供查询使用,但在对所有文档编制索引之前,该索引不会完全正常运行。 在内部,索引跨分区分布,并针对副本执行。 物理索引在内部管理。 管理逻辑索引。

索引持续可用,无法暂停或脱机。 由于它是为连续操作而设计的,因此内容更新和对索引本身的添加都是实时进行的。 如果请求与文档更新相吻合,查询可能会暂时返回不完整的结果。

文档操作(例如刷新或删除)以及不影响索引现有结构或完整性的修改(如添加新字段)都具有查询连续性。 结构更新(如更改现有字段)通常在开发环境中使用拖放和重新生成工作流进行管理,或者通过在生产服务上创建新版本的索引来管理。

为了避免索引重新生成,一些进行小更改的客户会通过创建与先前版本共存的新字段来“版本化”字段。 随着时间的推移,这会导致过时的字段和过时的自定义分析器定义产生孤立的内容,尤其是在复制成本高昂的生产索引中。 在索引生命周期管理过程中,可以在对索引进行计划内更新期间解决这些问题。

终结点连接和安全性

所有索引和查询请求都以索引为目标。 终结点通常是以下其中一项:

终结点 连接和访问控制
<your-service>.search.azure.cn/indexes 以索引集合为目标。 在创建、列出或删除索引时使用。 这些作需要管理员权限,并且可通过管理员 API 密钥搜索参与者角色获得。
<your-service>.search.azure.cn/indexes/<your-index>/docs 以单个索引的文档集合为目标。 在查询索引或数据刷新时使用。 对于查询,读取权限足够,可通过查询 API 密钥或数据读取者角色获得。 对于数据刷新,需要管理员权限。
  1. 从 Azure 门户开始。 Azure 订阅者或创建搜索服务的人员可以在 Azure 门户中管理搜索服务。 Azure 订阅需要为“参与者”或具有更高权限才能创建或删除服务。 此权限级别足以在 Azure 门户中完全管理搜索服务。

  2. 尝试其他客户端进行编程访问。 建议使用快速入门进行前几个步骤:

后续步骤

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

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