本页介绍了如何配置架构字段,以设置应用来处理结构化数据、包含元数据的非结构化数据,或包含自定义结构化属性的网站数据。
字段设置有助于确定代理搜索如何在搜索结果中使用字段。您可以使用Google Cloud 控制台中的架构标签页来配置字段设置。
只有数据存储区包含结构化数据或包含带元数据的非结构化数据的应用才能配置字段设置。
字段设置
以下字段设置适用于搜索或推荐数据中的许多字段类型,但并非适用于所有数据类型。一个架构包含多个针对各个字段的字段设置,下表列出了可应用于架构中字段的设置。强烈建议为以下字段设置使用结构化数据:
| 设置 | 定义 | 用途 | 应用场景示例 |
|---|---|---|---|
| 可编入索引 | 将字段设置为可编制索引后,便可对文档中的结构化字段执行过滤、提升和分面等操作。 类型为 |
将字段标记为 请注意,将字段标记为 |
在酒店数据存储区中,您可以将某个字段(例如 hotel_chain)设置为可编制索引。这样,您就可以对 hotel_chain 应用排名、过滤和提升操作。例如,您可以应用过滤条件,以便搜索仅返回包含过滤后的连锁酒店的搜索结果。 |
| 可搜索 |
最有可能与搜索相关的字段被指定为 只有包含文本值的字段才能标记为可搜索。因此,数字价格字段可以编制索引(用于过滤或分面),但不能作为全文进行搜索。 |
将某个字段设置为可搜索可提高该字段在搜索查询中的召回率,从而让用户能够通过查询这些字段中的文本来查找网页等内容。将字段标记为可搜索后,系统便可应用排名。因此,将过多的字段标记为可搜索可能会使排名算法过度饱和并返回过多的结果,从而对搜索精确度产生负面影响。这可能会导致搜索结果不相关。 您可以对可搜索字段应用相对权重;不过,由于默认值非常可靠,因此很少需要这样做。请参阅下文中的加权可搜索字段。 |
互联网服务提供商的支持服务工单系统将每个工单存储为结构化文档。如果这些文档包含可搜索的文本字段(例如 |
| 可匹配前缀 (预览版) |
允许在过滤条件表达式中使用 如需了解详情,请参阅下文的使字段可用于前缀匹配和部分匹配。 |
将字段设置为可进行前缀匹配后,搜索引擎便可匹配作为字段值前缀的查询字符串。这对于匹配字符串开头已知的分层标识符、路径或代码特别有用。前缀匹配仅限于标准化字段值的前 12 个字符,并且会增加搜索索引的大小。您最多只能将 10 个字段设置为可进行前缀匹配。 |
您有一个字段 |
| 部分可匹配 (预览版) |
允许在过滤条件表达式中使用 如需了解详情,请参阅下文的使字段可用于前缀匹配和部分匹配。 |
将字段设置为可部分匹配后,系统便可在字段内进行基于令牌的匹配,从而让用户在只知道部分字段值的情况下也能找到相应内容。搜索引擎会将查询令牌与字段值中的令牌进行匹配,而不考虑它们的顺序。请注意,将字段标记为部分可匹配会增加搜索索引的大小。您最多只能将 10 个字段设置为可部分匹配。 |
您想过滤欧洲的区域。 |
| 动态分面 | 提供情境感知过滤器,以便更好地定位用户搜索。将某个字段设置为 Dynamic Facetable 可让系统根据该字段中存在的唯一值自动生成互动式过滤条件(分面)。 |
将某个字段设置为 Dynamic
facetable 可让用户通过选择直接从已提取的数据中派生的类别或属性来动态优化搜索结果,而无需手动预先定义每种可能的过滤条件选项。这样,用户便可将搜索范围缩小到高度特定的网页内容。将动态可构面与可搜索搭配使用可获得更好的结果,从而提高搜索的召回率和提供给用户的构面质量。 |
内部公司知识库(例如人力资源政策)中的网页会与 department、document_type 或 last_modified_date 等数据一起被提取。如果这些字段标记为 dynamic facetable,那么员工在搜索“费用报销”等字词时,系统会根据找到的相关结果动态生成交互式过滤条件。在这种情况下,网页界面可能会显示以下方面的分面:部门:财务、旅游、文档类型:政策、常见问题解答或上次修改日期:本季度、去年。 |
| 可检索 | 当搜索查询命中匹配的内容时,搜索引擎可以提取可检索字段的值以供显示或在应用中使用,这意味着原始文档中的信息会显示为搜索结果的一部分。关键字段(文档的唯一标识符)设置为可检索。 | 可检索字段通过区分以下两种字段来提供搜索上下文:一种是其值可以显示的字段,另一种是仅用于搜索逻辑但其原始值不应向最终用户显示的字段。 | 对于商家网站上的商品搜索,product_id、name、price 和 image_url 通常是您希望设置为可检索的字段。另一方面,internal_tracking_code 可以仅出于管理目的进行索引和过滤,但无法在公开搜索结果中检索。 |
| 可完成 | 允许将字段的内容用作搜索查询建议。如需了解详情,请参阅配置自动补全。 | 此设置可让系统在用户输入内容时,使用相应字段中的值提供实时查询建议。此功能有助于引导用户找到相关内容,并加快搜索过程。使用自然语言过滤等某些因素可能会影响此性能。 | 如果为 product_name、brand 和 category 设置了 completable 字段,那么当用户输入 Tech 时,自动补全建议可以显示:
|
| 可过滤 | 允许推荐功能使用某个字段来过滤推荐结果,从而确定用户看到的搜索结果。如需了解如何过滤推荐结果,请参阅过滤推荐结果。 | 将字段设置为 Filterable 有助于为用户量身定制推荐内容。请注意,过滤条件限制适用。 |
按语言和戏剧过滤的设置可能如下所示:language_code: ANY("en", "fr") OR categories: ANY("drama")。 |
常用设置之间的区别
可编入索引、可搜索和可检索的字段设置之间存在一些关键区别。下表总结了这些差异。
| 功能 | 可编入索引 | 可搜索 | 可检索 |
|---|---|---|---|
| 主要作用 | 使字段内容可供搜索引擎使用 | 允许针对字段内容进行全文查询 | 允许在搜索结果中返回字段的值 |
| 分析 | 系统会处理内容并将其放入索引中。 | 通常会进行广泛的词汇分析。 | 值按原样存储以供显示。 |
| 是否可以... | |||
| ...可搜索? | 是(通常是前提条件) | 无 | 不一定(即使无法搜索,也可以检索) |
| …可检索? | 不一定 | 不一定 | 无 |
| ...是否可过滤/排序/用于生成商品详情? | 是(通常也是这些功能的先决条件) | 不能直接实现;这些是单独的属性,通常基于可编入索引的字段构建。 | 不能直接实现;这些属性与字段的索引和查询方式有关,而不仅仅是显示方式。 |
在实践中,许多对用户体验至关重要的字段(例如商品名、说明和身份信息)通常设置为 indexable、searchable 和 retrievable。
限制
字段设置具有以下限制:
- 您最多可将 50 个字段配置为可编入索引、可搜索、可检索或动态可分面。
- 如需将某个字段配置为可进行动态分面,必须先将其配置为可编入索引。
- 更改可编入索引的设置需要将数据重新编入索引,这可能需要数小时,尤其是在处理大型数据存储区时。
如果您要为媒体搜索应用配置字段,并希望详细了解架构中的字段,请参阅媒体文档和数据存储区简介。
更新字段设置
如需更新字段设置,请执行以下操作:
在 Google Cloud 控制台中,前往 AI Applications 页面。
点击要修改的应用的名称。
点击数据。
点击架构标签页。此标签页显示当前的字段设置。
如果您的数据存储区包含基本网站数据或不含元数据的非结构化数据,您将不会看到架构标签页。
点击修改。
选择或清除需要更新的字段设置。某些字段设置不受支持。例如,无法将数字字段设置为可搜索。
点击保存以应用更改。
可搜索字段的权重(预览版)
如果您将某个字段标记为可搜索,则可以指定一个权重来指示该字段在搜索结果中的相对重要性。在大多数情况下,您无需为各个字段指定权重,因为默认权重效果很好。
不过,在少数情况下,可能需要调整权重,例如:
您要从已使用加权字段的现有搜索平台迁移数据。
当默认权重无法提供令人满意的搜索结果时。具体来说,当您有许多可搜索的字段,并且其中一些字段明显比其他字段更重要时,可能会出现这种情况。
也许,摘要是搜索最重要的字段,因此您希望优先处理该文本。
或者,架构中有一个字段包含与搜索结果高度相关的关键字,这些关键字是出色的预测指标,但由于此字段比其他字段短得多,因此其影响往往会被较长的字段掩盖。增加此字段的权重可确保其发挥预期影响。
体重水平
权重分为以下几个级别:
| 字段重要性 | 说明 |
|---|---|
| 非常低 | 系统在合并所有字段的分数时仍会考虑的较低值。如果您希望权重更低,以至于效果可以忽略不计,请不要将相应字段标记为可搜索。 |
| 低 | 低于默认值的权重。 |
| 默认 | 可搜索字段的标准权重。此权重在大多数情况下都能提供相当不错的性能。 |
| 高 | 明显高于默认值的权重。 |
| 非常高 | 占主导地位的权重。通常,您最多只能为一个字段预留此空间。 |
架构更新和重新编制索引
为可搜索字段添加权重需要更新架构,然后重新为数据存储区中的数据编制索引。更新架构需要数小时,而且没有可靠的指标来告知您索引编制何时完成,因此您需要高估索引编制时间。
设置字段的权重级别
为字段设置权重级别可能是一项繁琐的任务,因为您应该只进行小幅更改,并在之后仔细检查搜索结果,以查看是否会产生意外后果。每次更改后,您都必须等待重新编入索引完成后,才能评估更改的影响。
您只能通过 API 配置搜索字段权重。此功能在 Google Cloud 控制台中不可用。
如需设置权重,您需要通过 API projects.locations.dataStores.schemas.patch 方法更新数据存储区的架构。
如果您还没有架构,请按照查看架构定义中的说明获取架构。
按照说明以编程方式更新架构。为一个或多个可搜索字段添加权重,如以下示例所示:
"summary": { "type": "string", "searchable": true, "weight": "high" }, "uri": { "type": "string", "searchable": true, "weight": "low" },在此示例中,
summary字段的权重高于正常水平,而uri字段的权重低于正常水平。如果您想将权重恢复为默认值,请将其设置为default。权重参数的允许值包括:
very_lowlowdefaulthighvery_high
等待重新编制索引完成,然后测试搜索行为。
使字段可用于前缀匹配和部分匹配(预览版)
对于 string 类型的字段,您可以修改架构,使这些字段可用于前缀匹配或部分匹配。这样,您就可以在过滤表达式中使用 STARTS_WITH 或 CONTAINS。
架构更新和重新编制索引
如需使字段可用于前缀匹配或部分匹配,需要更新架构,然后重新为数据存储区中的数据编制索引。更新架构需要数小时,并且没有可靠的指示器来告知您索引编制何时完成,因此您需要高估索引编制时间。
更新了前缀和部分匹配的架构
如需指定可用于前缀匹配或部分匹配的字段,您需要通过 API projects.locations.dataStores.schemas.patch 方法更新数据存储区的架构。
如果您还没有架构,请按照查看架构定义中的说明获取架构。
按照说明以编程方式更新架构。在架构中将可匹配的参数设置为
true,如以下示例所示:"zone": { "type": "string", "searchable": true, "prefixMatchable": true }, "region": { "type": "string", "searchable": true, "partialMatchable": true }, "model": { "type": "string", "searchable": true, "prefixMatchable": true, "partialMatchable": true },在此示例中,
zone字段设置为可进行前缀匹配。最多 12 个字符,不区分大小写,可用于过滤表达式以匹配字段值。region字段设置为可部分匹配。等待重新编制索引完成。
有关前缀匹配的详细信息
在代理搜索中,前缀匹配功能可让您根据字段值是否以特定字符串开头来过滤结果。此功能由 STARTS_WITH 运算符提供支持,并且要求目标文本字段在架构中配置为 prefixMatchable。
归一化和匹配逻辑
为了优化性能并确保一致性,系统会对字段值(在编入索引期间)和查询字符串(在搜索期间)应用特定的归一化流程。
转换为小写:所有字符都会转换为小写。这样一来,匹配就不区分大小写了。
截断为 12 个字符:系统仅考虑字符串的前 12 个字符。超出此限制的任何字符都会被忽略,以用于前缀匹配。
工作原理
在编制索引时,对于标记为 prefixMatchable 的字段,系统会为前 12 个字符生成前缀令牌。对于 asia-south1-c 之类的值,索引会存储 a、as、asi、asia、asia- 等令牌,最多存储到第 12 个字符 (asia-south1-)。
在查询时,提供给 STARTS_WITH 运算符的字符串也会转换为小写并截断为 12 个字符。然后,系统会将查询与存储的前缀令牌进行匹配。
示例
以下示例展示了 12 字符规范化如何影响搜索结果:
广泛匹配:
STARTS_WITH("A")匹配以“a”开头(不区分大小写)的任何值,例如asia、australia或africa。部分前缀:
STARTS_WITH("asia-south")同时匹配asia-south1-a和asia-southeast1-b,因为两者都以指定的 10 个字符的字符串开头。截断行为:由于系统仅匹配前 12 个字符,因此
STARTS_WITH("asia-south1-a")会与asia-south1-c的字段值匹配。这是因为这两个字符串都归一化为相同的前 12 个字符:asia-south1-。
有关部分匹配的详细信息
在代理搜索中,您可以根据字段的值是否包含特定字词或令牌来过滤结果。此功能由 CONTAINS 运算符提供支持,并且要求在架构中将目标文本字段配置为 partialMatchable。
归一化和词法单元化逻辑
代理搜索会在索引编制期间对字段值进行归一化和令牌化,并在搜索期间对查询字符串进行归一化和令牌化:
转换为小写:代理搜索会将字符转换为小写。这样,匹配时不区分大小写。
词元化:Agent Search 使用空格和其他字符作为分隔符,将字符串拆分为各个词元(字词)。
标准分隔符:空格和常见标点符号可作为分隔符,包括连字符 (
-)、斜线 (/)、英文逗号 (,)、英文句点 (.)、星号 (*)、大括号 ({ })、方括号 ([ ])、圆括号 (( )) 和英文撇号 (')。非分隔符:和号 (
&) 和下划线 (_) 不会充当分隔符。系统会将通过这些符号连接的字符视为单个词法单元。电子邮件定界符 (
@):@符号充当特殊定界符,有助于识别电子邮件地址。系统会为各个组成部分以及组合形式生成令牌。例如,它会将support+tier1@example.com分词为support、tier1、example、com、support+tier1@example.com和support@example.com。
工作原理
在编制索引时,对于标记为 partialMatchable 的字段,系统会对字段值进行归一化和分词,并将生成的分词存储在索引中。例如,系统会将字段值 25-meter, outdoor, swimming
pool 分词为 [25, meter, outdoor, swimming, pool]。
在查询时,提供给 CONTAINS 运算符的字符串会经历相同的归一化和分词过程。然后,搜索引擎会验证所有生成的查询令牌是否与该字段的存储令牌匹配。令牌的顺序没有影响。
示例
以下示例演示了分词如何影响部分匹配结果:
基本令牌匹配:如果字段值为
25-meter, outdoor, swimming pool,则CONTAINS("Outdoor pool")的过滤条件匹配。系统会将查询内容标记化为[outdoor, pool],这两个词元都存在于字段的词元中。顺序无关性:过滤条件
CONTAINS("pool outdoor")也会匹配字段值25-meter, outdoor, swimming pool,因为系统会检查每个令牌是否存在,而不会考虑它们的顺序。电子邮件地址匹配:如果某个字段存储了电子邮件地址
support+tier1@example.com,则@符号的特殊分词功能可确保CONTAINS("support")、CONTAINS("example.com")或CONTAINS("support@example.com")等过滤条件都能成功匹配。