配置字段设置

本页面介绍了如何配置架构字段，以便为结构化数据、带有元数据的非结构化数据或具有自定义结构化属性的网站数据设置应用。

字段设置有助于确定 Agent Search 如何在其结果中使用字段。您可以使用Google Cloud 控制台中的架构标签页来配置字段设置。

只有当应用的数据存储区包含结构化数据或带有元数据的非结构化数据时，才能配置字段设置。

字段设置

以下字段设置适用于搜索或推荐数据中的许多字段类型，但并非适用于所有数据类型。架构包含针对各个字段的多个字段设置，下表包含可应用于架构中字段的设置。强烈建议您为以下字段设置使用结构化数据：

设置 定义 用途 应用场景示例
可编入索引

将字段设置为可编入索引后，便可对文档中的结构化字段执行过滤、提升和分面等操作。

类型为 Object 的字段不能设置为 Indexable。

将字段标记为 Indexable 可加快查找速度。

请注意，将字段标记为 Indexable 会增加搜索索引的大小，并可能会减慢索引编制速度。

 在酒店数据存储区中，您可以将某个字段（例如 hotel_chain）设置为可编入索引。这样，您就可以对 hotel_chain 应用排名、过滤和提升操作。例如，您可以应用过滤条件，以便搜索结果中仅显示包含过滤后的连锁酒店的结果。
可搜索

最可能与搜索相关的字段会被指定为 Searchable。字段可以不编入索引或不可检索，但可搜索。

只有包含文本值的字段才能标记为可搜索。因此，数字价格字段可以编入索引（用于过滤或分面），但无法作为全文进行搜索。

将某个字段设置为可搜索可提高该字段在搜索查询中的召回率，从而让用户能够通过查询这些字段中的文本来查找内容（例如网页）。将字段标记为可搜索后，即可应用排名。因此，将过多字段标记为可搜索可能会导致排名算法过度饱和并返回过多结果，从而对搜索精确度产生负面影响。这可能会导致返回不相关的搜索结果。

您可以对可搜索字段应用相对权重；不过，由于默认设置非常强大，因此很少需要这样做。请参阅下文中的可搜索的权重字段。

网络服务提供商的支持服务工单系统会将每个工单存储为结构化文档。如果这些文档包含可搜索的文本字段（例如 issue_description 或 resolution_notes），支持代理可以执行与这些字段中的内容相关的查询，例如如何解决调制解调器重置后网速缓慢的问题。然后，系统会在 issue_description 或 resolution_notes 字段中显示包含上述任一搜索字词（包括调制解调器、互联网、速度）的文档。
前缀可匹配
（预览版）

允许在过滤表达式中使用 STARTS_WITH 运算符对文本字段进行前缀匹配。只有 String 或 String Array 类型的字段才能设置为“可前缀匹配”。

如需了解详情，请参阅下文的使字段可用于前缀和部分匹配。

将字段设置为可前缀匹配，可使搜索引擎匹配作为字段值前缀的查询字符串。这对于匹配已知字符串开头的分层标识符、路径或代码特别有用。前缀匹配仅限于归一化字段值的前 12 个字符，并且会增加搜索索引的大小。您最多只能将 10 个字段设置为可前缀匹配。

您有一个字段 ticket_id，该字段使用 <country-code><city-code><number> 等格式。示例包括 UKLON100、UKMAN100、UKMAN101 和 USNY200。如需查找来自英国曼彻斯特的所有票券，您可以将 ticket_id 字段设置为可前缀匹配，然后使用过滤条件 ticket_id: STARTS_WITH("UKMAN")，该过滤条件会返回 UKMAN100 和 UKMAN101。
部分可匹配
（预览版）

允许在过滤表达式中使用 CONTAINS 运算符对文本字段进行部分字符串匹配。只有类型为 String 或 String Array 的字段才能设置为部分可匹配。

如需了解详情，请参阅下文的使字段可用于前缀和部分匹配。

将字段设置为部分可匹配，可在字段内启用基于词元的匹配，从而允许用户在仅知道部分字段值时查找内容。搜索引擎会将查询词元与字段值中的词元进行匹配，而不考虑其顺序。请注意，将字段标记为部分可匹配会增加搜索索引的大小。您最多只能将 10 个字段设置为部分可匹配。

您希望过滤出欧洲的区域。region 名称包括 Central Europe 和 Eastern Europe。 如果过滤条件为 region: ANY("Europe")，您将不会获得任何匹配项。但是，如果 region 字段设置为部分可匹配，则您可以使用 region: CONTAINS("Europe") 进行过滤，并获取 Central Europe 和 Eastern Europe 的匹配项。
与边输边搜功能兼容
（预览版）

将文本字段标记为可供边输入边搜索功能使用：当用户输入时，如果字段值包含以查询文本开头的词元，系统就会返回文档，并且每次按键都会对结果集进行重排序。

只有类型为 String 或 String Array 的字段才能设置为与边输入边搜索功能兼容。每个架构中，您最多只能将三个字段设置为与边输边搜功能兼容。

如需了解详情，请参阅下文的使字段可用于边输入边搜索。

将字段设置为 saytCompatible 后，用户在输入完整查询之前，每次按键都会收到一组经过刷新的排名文档。如果您希望用户在输入时浏览不断更新的结果列表，请应用此设置。例如，在目录查找或长尾导航中，用户在查询过程中识别出正确的结果，而不是完整地输入结果。这与自动补全不同，后者会建议查询字符串。边输入边搜索会返回与部分查询匹配的文档，并按相关性排序。

在电影数据存储区中，您将 title 字段设置为 saytCompatible。当用户输入 b 时，搜索结果会动态包含蝙蝠侠：侠影之谜、蝙蝠侠归来和蝙蝠，并根据用户的查询进行排名。当用户将查询扩展到 bat 时，结果集中仍会保留这三个文档，并针对较长的前缀重新排名。将查询扩展到 batm 会丢弃 Bats，因为其标题的第一个词元不以 batm 开头，因此仅保留 Batman Begins 和 Batman Returns，并再次重排序。
可动态分面 提供情境感知过滤条件，以便更好地针对用户进行搜索。将字段设置为 Dynamic Facetable 后，系统可以根据字段中存在的唯一值自动生成互动式过滤条件（分面）。 将字段设置为 Dynamic facetable 后，用户可以直接选择从提取的数据中派生的类别或属性，从而动态优化搜索结果，而无需手动预定义每个可能的过滤选项。这样，用户就可以将搜索范围缩小到高度具体的 Web 内容。
将动态可分面与可搜索结合使用，以获得更好的结果，从而提高搜索召回率和向用户提供的分面的质量。 		内部企业知识库中的页面（例如人力资源政策）会与 department、document_type 或 last_modified_date 等数据一起注入。如果这些字段被标记为 dynamic facetable，则员工搜索“费用报销”等字词时，系统会根据找到的相关结果动态生成交互式过滤条件。在这种情况下，网页界面可能会显示部门：财务、差旅、文档类型：政策、常见问题解答或上次修改日期：本季度、去年等构面。
可检索 当搜索查询命中匹配内容时，搜索引擎可以提取可检索字段的值，以便在应用中显示或使用，这意味着原始文档中的信息会作为搜索结果的一部分显示。键字段（文档的唯一标识符）设置为可检索。 可检索字段通过区分可显示其值的字段与仅用于搜索逻辑但其原始值不向用户显示的字段，来提供搜索上下文。 对于商家网站上的商品搜索，product_id、name、price 和 image_url 是您要设置为可检索的典型字段。另一方面，internal_tracking_code 可以被编入索引并可过滤，但仅用于管理目的，无法在公开搜索结果中检索。
可补全 允许将字段的内容用于搜索查询建议。如需了解详情，请参阅配置自动补全。

此设置可让系统在用户输入内容时，使用该字段中的值提供实时查询建议。此功能有助于引导用户找到相关内容，并加快搜索过程。某些因素（例如使用自然语言过滤）可能会影响此性能。

 如果为 product_name、brand 和 category 设置了 completable 字段，则当用户输入“Tech”时，自动补全建议可能会显示：
  • TechCo（来自 brand 字段）
  • TechCo UltraBook X1（来自 product_name 字段）
  • Technology GameMaster Pro（category 字段中的另一款商品）
可过滤 允许推荐功能使用字段来过滤推荐结果，从而确定用户会看到哪些搜索结果。如需了解如何过滤建议，请参阅过滤建议。 将字段设置为 Filterable 有助于为用户提供个性化推荐。请注意，过滤限制适用。 按语言和戏剧设置的过滤条件可能如下所示：language_code: ANY("en", "fr") OR categories: ANY("drama")。

常用设置之间的差异

可编入索引、可搜索和可检索字段设置之间存在关键差异。下表总结了这些差异。

功能 可编入索引 可搜索 可检索
主要角色 使字段内容可供搜索引擎使用 允许对字段内容进行全文查询 允许在搜索结果中返回字段的值
分析 系统会处理内容并将其放入索引中。 通常会经过广泛的词法分析。 值会按原样存储以供显示。
Can it be…
…可搜索？ 是（通常是前提条件） 无 不一定（可以检索，但不一定可搜索）
…可检索？ 不一定 不一定 无
…可过滤/可排序/可用于生成商品详情？ 是（通常也是这些的前提条件） 不能直接设置；这些是单独的属性，通常基于可编入索引的字段构建。 不直接相关；这些属性与字段的索引和查询方式有关，而不仅仅是显示方式。

在实践中，许多对用户体验至关重要的字段（例如标题、说明和身份信息）通常会设置为 indexable、searchable 和 retrievable。

限制

字段设置存在以下限制：

  • 您最多可以将 50 个字段配置为可编入索引、可搜索、可检索或动态可分面。
  • 如需将某个字段配置为动态可分面，必须先将其配置为可编入索引。
  • 更改可编入索引设置需要将数据重新编入索引，这可能需要数小时，尤其是对于大型数据存储区。

如果您要为媒体搜索应用配置字段，并希望详细了解架构中的字段，请参阅媒体文档和数据存储区简介。

更新字段设置

如需更新字段设置，请执行以下操作：

  1. 在 Google Cloud 控制台中，前往 AI Applications 页面。

    AI Applications

  2. 点击要修改的应用的名称。

  3. 点击数据。

  4. 点击架构标签页。此标签页显示当前的字段设置。

    如果您的数据存储区包含基本网站数据或不带元数据的非结构化数据，您将不会看到架构标签页。

  5. 点击修改。

  6. 选择或清除需要更新的字段设置。不支持某些字段设置。例如，数值字段不能设置为“可搜索”。

  7. 点击保存以应用更改。

如果您将某个字段标记为可搜索，则可以指定一个权重，以指明其在搜索结果中的相对重要性。在大多数情况下，您无需为各个字段指定权重，因为默认权重效果很好。

不过，在少数情况下，可能需要调整权重，例如：

  • 您正在从已使用加权字段的现有搜索平台迁移数据。

  • 当默认权重无法提供令人满意的搜索结果时。 具体而言，当您有许多可搜索字段，且其中一些字段明显比其他字段更重要时，可能会发生这种情况。

    也许摘要是搜索中最重要的字段，因此您希望优先考虑该文本。

    或者，架构中有一个字段包含高度相关的关键字，这些关键字是搜索结果的绝佳预测指标，但由于此字段比其他字段短得多，因此其影响往往会被较长的字段所掩盖。增加其权重可确保其产生预期影响。

体重水平

权重分为以下几个级别：

字段重要性 说明
极低 系统在合并所有字段的分数时仍会考虑的低值。如果您希望权重更低，使效果可以忽略不计，请勿将该字段标记为可搜索。
低 低于默认值的权重。
默认 可搜索字段的标准权重。此权重在大多数情况下都能提供相当不错的性能。
高 明显高于默认权重的权重。
很高 主导权重。通常，您最多为一个字段保留此值。

架构更新和重新索引

为可搜索字段添加权重需要更新架构，并随后重新为数据存储区中的数据编制索引。更新架构需要数小时，并且没有可靠的指标来告知您索引编制何时完成，因此您需要高估索引编制时间。

为字段设置权重级别

为字段设置权重级别可能是一项繁琐的任务，因为您应该只进行细微更改，然后仔细查看搜索结果，以检查是否有意外后果。每次更改后，您都必须等待重新编入索引完成，然后才能评估更改的影响。

您只能通过 API 配置搜索字段权重。 Google Cloud 控制台中不提供此功能。

如需设置权重，您需要通过 API projects.locations.dataStores.schemas.patch 方法更新数据存储区的架构。

  1. 如果您还没有架构，请按照查看架构定义中的说明获取架构。

  2. 按照说明以编程方式更新架构。 为一或多个可搜索字段添加权重，如以下示例所示：

    "summary": {
   "type": "string",
   "searchable": true,
   "weight": "high"
 },
 "uri": {
   "type": "string",
   "searchable": true,
   "weight": "low"
 },

    在此示例中，summary 字段的权重高于正常值，uri 字段的权重低于正常值。如果您想将权重恢复为默认值，请将其设置为 default。

    权重参数的允许值包括：

    • very_low
    • low
    • default
    • high
    • very_high

  3. 等待重新编入索引完成，然后测试搜索行为。

使字段可用于前缀和部分匹配（预览版）

对于 string 类型的字段，您可以修改架构，使这些字段可用于前缀匹配或部分匹配。这样，您便可在过滤表达式中使用 STARTS_WITH 或 CONTAINS。

架构更新和重新索引

如需使字段可用于前缀或部分匹配，需要更新架构，然后重新将数据存储区中的数据编入索引。更新架构需要数小时，并且没有可靠的指标来告知您索引编制何时完成，因此您需要高估索引编制时间。

更新架构以支持前缀和部分匹配

如需将字段指定为可用于前缀匹配或部分匹配，您需要通过 API projects.locations.dataStores.schemas.patch 方法更新数据存储区的架构。

  1. 如果您还没有架构，请按照查看架构定义中的说明获取架构。

  2. 按照说明以编程方式更新架构。 在架构中将可匹配参数设置为 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 字段设置为可部分匹配。

  3. 等待重新索引完成。

前缀匹配详情

借助 Agent Search 中的前缀匹配，您可以根据字段值是否以特定字符串开头来过滤结果。此功能由 STARTS_WITH 运算符提供支持，并且要求在架构中将目标文本字段配置为 prefixMatchable。

标准化和匹配逻辑

为了优化性能并确保一致性，系统会对字段值（在索引编制期间）和查询字符串（在搜索期间）应用特定的标准化流程。

  1. 转换为小写：所有字符都会转换为小写。这样，匹配时就不会区分大小写了。

  2. 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 会对字段值（在索引编制期间）和查询字符串（在搜索期间）进行标准化和词元化：

  • 转换为小写：Agent Search 会将字符转换为小写。这样，匹配时就不会区分大小写了。

  • 词元化：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 运算符的字符串会经历相同的标准化和词法分析过程。然后，搜索引擎会验证所有生成的查询词元是否与该字段的存储词元匹配。token 的顺序没有任何影响。

示例

以下示例演示了词元化如何影响部分匹配结果：

  • 基本词元匹配：如果字段值为 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") 等过滤条件都会成功匹配。

使字段可用于即输即搜（预览版）

对于类型为 string 的字段，您可以修改架构，将这些字段标记为 saytCompatible。当架构中的一个或多个字段为 saytCompatible 且您的应用在搜索请求中选择启用边输边搜功能时，Agent Search 会返回其 saytCompatible 字段包含以查询文本开头的词元的文档，并在每次按键时对这些文档进行重排序。

关于媒体即输即搜功能

即输即搜是媒体应用的一项正式版功能。如需了解仅限媒体的 searchAsYouTypeSpec.condition 请求字段，请参阅获取媒体应用的边输边搜结果。

saytCompatible 字段设置可让您标记特定的架构字段来回答部分查询，从而将边输入边搜索功能扩展到任何搜索应用。媒体应用可以继续像以前一样使用 searchAsYouTypeSpec.condition；非媒体应用需要在架构中添加 saytCompatible 字段。

自动补全和即输即搜

即输即搜与自动补全不同：

  • 自动补全功能可预测查询字符串，并由 completable 字段设置驱动。
  • Search-as-you-type会返回经过排名的文档，并由 saytCompatible 字段设置驱动。

这两项功能可以单独使用，也可以结合使用，并且它们不共享数据。

限制

将字段设为 saytCompatible 具有以下限制：

  • 每个架构中最多只能将三个字段标记为 saytCompatible。 如果您设置第四个，则在修补架构时，API 会返回 INVALID_ARGUMENT 错误。
  • saytCompatible 仅对 string 类型的字段有效。在 number、integer、boolean、object 或 datetime 字段上设置该值会从 API 返回 INVALID_ARGUMENT 错误。
  • 系统只会将字段值的前 12 个词元编入索引，并且每个词元最多会贡献其前 10 个字符的前缀片段。较长的值仍会被编入索引，但无法通过前缀访问尾部。

架构更新和重新索引

将字段设置为 saytCompatible 需要更新架构，并随后对数据存储区中的数据重新编制索引。更新架构需要数小时，并且没有可靠的指标来告知您索引编制何时完成，因此您需要高估索引编制时间。

更新架构以支持即输即搜

如需使用 projects.locations.dataStores.schemas.patch 方法将字段标记为 saytCompatible，请执行以下操作：

  1. 如果您还没有架构，请按照查看架构定义中的说明获取架构。

  2. 按照说明以编程方式更新架构。在要为此功能启用的字段上将 saytCompatible 设置为 true，如以下示例所示：

    "title": {
   "type": "string",
   "retrievable": true,
   "saytCompatible": true
 },
 "channel_name": {
   "type": "string",
   "retrievable": true,
   "saytCompatible": true
 },

    在此示例中，title 和 channel_name 字段均标记为 saytCompatible。如果对类型不是 string 的字段设置 saytCompatible，API 会返回 INVALID_ARGUMENT 错误；如果对架构中的三个以上字段设置该属性，也会返回此错误。

  3. 等待重新索引完成。

发送即输即搜搜索请求

重新索引完成后，通过发送正文包含 searchAsYouTypeSpec 的搜索请求，选择在每个搜索请求中启用即输即搜功能。仅当在请求中设置了 searchAsYouTypeSpec 时，系统才会参考架构中标记为 saytCompatible 的字段，因此您可以为部分查询和完整查询保留相同的服务配置。

如需发送边输边搜搜索请求，请执行以下操作：

  1. 按照获取搜索结果中的说明，对服务配置调用搜索方法。

  2. 在请求正文中，将 searchAsYouTypeSpec.condition 设置为 ENABLED。这会在请求中启用即输即搜功能。

  3. 可选：在同一 searchAsYouTypeSpec 中，将边输边搜范围缩小到架构的 saytCompatible 字段子集，为每个字段指定相对权重，并设置最低分数阈值，低于该阈值的文档将被丢弃。此代码块中的每个值都是可选的；如果省略，则应用默认值。

    • fields[i].key：标记为 saytCompatible 的架构字段。引用非 saytCompatible 字段不会返回该字段的边输边搜贡献。
    • fields[i].weight：字段在边输边搜得分中的相对重要性。默认值为 1.0。
    • scoreThreshold：排除边输边搜得分低于此值的文档。默认无阈值。

  4. 发送请求。以下示例展示了 searchAsYouTypeSpec 的形状，它支持边输入边搜索，将其范围限定为两个具有不同权重的字段，并设置了最低分数：

    "searchAsYouTypeSpec": {
  "condition": "ENABLED",
  "fields": [
    { "key": "title", "weight": 1.2 },
    { "key": "channel_name" }
  ],
  "scoreThreshold": 0.5
}

有关即输即搜的详细信息

借助代理搜索中的边输边搜功能，用户可以在架构中标记为 saytCompatible 的字段上，在每次按键时接收排名文档。

标准化和词元化逻辑

Agent Search 会对字段值（在索引编制期间）和查询文本（在搜索期间）进行标准化和词元化处理：

  • 转换为小写：Agent Search 会将字符转换为小写。这样，匹配时就不会区分大小写了。

  • 词元化：Agent Search 使用空格和常见标点符号作为分隔符，将字符串拆分为单个词元（字词），这与部分匹配的行为一致。

  • 每个字段的边界：系统只会为字段值的前 12 个词元编制索引，以用于边输入边搜索；每个词元最多贡献其前 10 个字符的前缀片段。

示例

如果 actor_name 字段标记为 saytCompatible，并且文档的值为 Christian Bale，则查询 chr 会通过 christian 词元的长度为 3 的前缀片段到达文档，并且将查询扩展到 chris 仍会通过长度为 5 的前缀片段进行匹配。通过字段值中第二个词元的长度为 4 的前缀片段，bale 查询也会匹配。在用户输入时，每次按键都会更新排名。

后续步骤