Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
在 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 (only Edm.String fields can be keys) | false (default where applicable),
"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 of type Collection(Edm.Single)),
"vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations but 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){ }
}
集合 fields 通常是最大的部分。 每个字段都有一个名称、 数据类型和属性,用于确定查询时的使用情况。
为了简洁起见,其他元素会折叠,但以下链接提供了详细信息:
- 建议器支持预先输入查询,例如自动完成。
- scoringProfiles 用于相关性优化。
- 分析器用于根据分析器支持的语言规则或其他特征,将字符串处理成令牌。
- corsOptions(或跨域远程脚本 (CORS))用于发出来自不同域的请求的应用。
- encryptionKey 在索引中配置敏感内容的双重加密。
- 语义配置在全文和混合搜索中进行语义重新排序。
- vectorSearch 配置矢量字段和查询。
字段定义
搜索文档由fields创建索引请求正文中的集合定义。 你需要用于文档标识(键)、存储可搜索文本的字段,以及用于支持筛选器、各个方面和排序的字段。 你可能还需要为某个用户永远看不到的数据设置字段。 例如,你可能希望在 计分配置文件 中使用一些字段,例如利润率或营销促销,以提升搜索评分。
如果传入数据本质上是分层的,则可在索引中将其表示为用于嵌套结构的复杂类型。 示例数据集 Hotels 演示了使用地址(包含多个子字段)的复杂类型,其中地址与每个酒店具有一对一关系,以及一个房间复杂集合,其中多个房间与每个酒店相关联。
字段属性
字段属性决定了字段的使用方式,例如,是否用于全文搜索、分面导航和排序等操作中。
- 字符串字段通常标记为
searchable和retrievable。 - 用于缩小或排序搜索结果的字段被标记为
sortable,filterable并且facetable。
| 特征 | 描述 |
|---|---|
| 可搜索 | 可搜索全文或矢量。 文本字段在索引编制期间受词法分析的约束,例如断字。 有关详细信息,请参阅全文搜索工作原理。 |
| 可过滤的 | 在 $filter 查询中引用。
Edm.String 或 Collection(Edm.String) 类型的可筛选字段不进行分词,因此,比较仅用于查找完全匹配项。 给定字符串“sunny day”, $filter=f eq 'sunny' 则找不到匹配项,但 $filter=f eq 'sunny day' 成功。 |
| 可排序 | 默认情况下,系统按搜索分数排序,但可以根据文档中的字段配置显式排序。 无法对类型的 Collection(Edm.String) 字段进行排序。 |
| facetable | 通常用于包括了按类别(例如特定城市中的宾馆)的命中次数的搜索结果呈现中。 此选项无法与 Edm.GeographyPoint 类型的字段一起使用。
Edm.String 类型的可筛选、可排序或可查找字段的长度最多可以是 32 千字节。 有关详细信息,请参阅创建索引 (REST API)。 |
| 关键值 | 文档在索引内的唯一标识符。 必须仅选择单个字段作为键字段,并且它必须是 Edm.String 类型的。 |
| 可检索 | 决定了是否可以在搜索结果中返回此字段。 当希望将某个字段(例如利润)用作筛选器、排序或评分机制,但不希望该字段显示给最终用户时,这很有用。 对于 true 字段,此属性必须为 key。 |
尽管可以随时添加新字段,但在索引的生存期内现有字段定义将被锁定。 因此,开发人员通常使用 Azure 门户创建简单索引、测试创意,或者使用 Azure 门户页面来查找设置。 如果采用基于代码的方式以便可以轻松重新生成索引,那么对索引进行频繁迭代的设计就更为高效。
注意
用于生成索引的 API 具有不同的默认行为。 对于 REST API,大多数属性默认处于启用状态(例如,可搜索和可检索的字符串字段为 true),并且通常只需在想要关闭它们时设置它们。 对于 .NET SDK,情况恰恰相反。 在未显式设置的任何属性上,默认为禁用相应的搜索行为,除非专门启用它。
物理结构和大小
在 Azure AI 搜索中,索引的物理结构主要是内部实现。 可以访问其架构、加载和查询其内容、监视其大小和管理其容量。 但是,Azure 管理随搜索服务一起存储的基础结构和物理数据结构。
可以在 Azure 门户中的 “搜索管理 > 索引 ”页上监视索引大小。 或者,可以针对搜索服务或服务统计信息请求发出 GET INDEX 请求来检查存储大小的值。
注意
如果要主动 删除内容,则每隔几分钟更新索引存储和大小。 删除作为后台进程运行。 预期指标更新延迟较小。
索引的大小由以下项决定:
- 文档的数量和构成。
- 各个字段的属性:可检索不会增加索引的体积,但可筛选、可排序和可分面会消耗更多的存储空间来保存非标记化文本。
- 索引配置。 具体而言,是包括建议器还是专用 分析器。 如果使用 edgeNgram 分词器来存储逐字字符序列 (
a, ab, abc, abcd),则索引大于使用标准分析器时的索引。
文档的撰写和数量将由你选择导入的内容决定。 请记住,搜索索引应仅包含对搜索应用程序有用的内容。 如果源数据包括二进制字段,请忽略这些字段,除非使用 AI 扩充破解和分析内容来创建文本可搜索的信息。
字段属性可确定行为。 为了支持这些行为,索引过程将创建必要的数据结构。 例如,对于类型为 Edm.String 的字段,“searchable”调用全文搜索,该搜索将扫描标记化术语的倒排索引。 相比之下,“可筛选”或“可排序”属性将支持对未修改的字符串进行迭代。
建议器是支持预先输入或自动完成查询的构造。 在包含建议器时,索引过程将创建逐字字符匹配所需的数据结构。 建议器是在字段级别实现的,因此请仅选择对预先输入而言合理的字段。
基本操作和交互
现在,你已更好地了解索引是什么,本部分引入了索引运行时作,包括连接到和保护单个索引。
注意
没有门户或 API 支持移动或复制索引。 通常,可以将应用程序部署指向其他搜索服务(使用相同的索引名称)或修改名称以在当前搜索服务上创建副本,然后生成它。
索引隔离
在 Azure AI 搜索中,一次使用一个索引。 所有与索引相关的操作都以单个索引为目标。 无论是编制索引还是查询,都不存在“相关索引”的概念或独立索引的联接。
持续可用
索引在索引第一个文档后立即可供查询使用,但在对所有文档编制索引之前,该索引不会完全正常运行。 在内部,索引跨分区分布,并针对副本执行。 物理索引在内部管理。 管理逻辑索引。
索引持续可用,无法暂停或脱机。 由于它是为连续操作而设计的,因此内容更新和对索引本身的添加都是实时进行的。 如果请求与文档更新相吻合,查询可能会暂时返回不完整的结果。
文档操作(例如刷新或删除)以及不影响索引现有结构或完整性的修改(如添加新字段)都具有查询连续性。 结构更新(如更改现有字段)通常在开发环境中使用拖放和重新生成工作流进行管理,或者通过在生产服务上创建新版本的索引来管理。
为了避免索引重新生成,一些进行小更改的客户会通过创建与先前版本共存的新字段来“版本化”字段。 随着时间的推移,这会导致过时的字段和过时的自定义分析器定义产生孤立的内容,尤其是在复制成本高昂的生产索引中。 在索引生命周期管理过程中,可以在对索引进行计划内更新期间解决这些问题。
终结点连接和安全性
所有索引和查询请求都以索引为目标。 终结点通常是以下其中一项:
| 终结点 | 连接和访问控制 |
|---|---|
<your-service>.search.azure.cn/indexes |
以索引集合为目标。 在创建、列出或删除索引时使用。 这些作需要管理员权限,并且可通过管理员 API 密钥 或 搜索参与者角色获得。 |
<your-service>.search.azure.cn/indexes/<your-index>/docs |
以单个索引的文档集合为目标。 在查询索引或数据刷新时使用。 对于查询,读取权限足够,可通过查询 API 密钥或数据读取者角色获得。 对于数据刷新,需要管理员权限。 |
如何连接到索引
从 Azure 门户 和搜索服务仪表板开始。
尝试其他客户端进行编程访问。 建议使用快速入门进行前几个步骤:
后续步骤
你几乎可以使用 Azure AI 搜索的任何示例或演练来亲身体验如何创建索引。 对于初学者,可以从目录中选择任何快速入门。
但你最好也要熟悉加载索引和数据的方法。 索引定义和数据导入策略是一起定义的。 以下文章提供有关如何创建和加载索引的详细信息。