Configurar as definições de campo

Nesta página, mostramos como configurar os campos de esquema para configurar um app para dados estruturados, dados não estruturados com metadados ou dados de sites com atributos personalizados e estruturados.

As configurações de campo ajudam a determinar como a Pesquisa do agente usa os campos nos resultados. Use a guia Esquema no consoleGoogle Cloud para configurar as opções de campo.

A configuração de campos está disponível apenas para apps com repositórios de dados que contêm dados estruturados ou não estruturados com metadados.

Configurações do campo

As configurações de campo a seguir estão disponíveis para muitos tipos de campos nos seus dados de pesquisa ou recomendações, mas não para todos os tipos de dados. Um esquema contém várias configurações de campo para campos individuais, e a próxima tabela contém configurações que podem ser aplicadas a um campo em um esquema. É altamente recomendável usar dados estruturados para essas configurações de campo:

Configuração Definição Finalidade Exemplo de caso de uso
Indexável

Definir campos como indexáveis permite operações como filtragem, reforço e atributos em campos estruturados dentro de um documento.

Campos do tipo Object não podem ser definidos como Indexable.

Marcar um campo como Indexable permite pesquisas mais rápidas.

Marcar um campo como Indexable aumenta o tamanho do índice de pesquisa e pode diminuir a velocidade da indexação.

 Em um repositório de dados de hotel, é possível definir um campo, como hotel_chain, como indexável. Isso permite aplicar operações de classificação, filtragem e reforço em hotel_chain. Por exemplo, você pode aplicar um filtro para que a pesquisa mostre apenas resultados que contenham a rede de hotéis filtrada.
Pesquisável

Os campos mais propensos a serem relacionados a pesquisas são designados como Searchable. Um campo pode ser pesquisável sem ser indexável ou recuperável.

Somente campos com valores de texto podem ser marcados como pesquisáveis. Assim, um campo de preço numérico pode ser indexável (para filtragem ou refinamento), mas não pesquisável como texto completo.

Definir um campo como Pesquisável melhora o recall desse campo nas consultas de pesquisa, permitindo que os usuários encontrem conteúdo, como páginas da Web, consultando o texto nesses campos. Marcar um campo como pesquisável permite que o ranking seja aplicado. Consequentemente, marcar um número excessivo de campos como pesquisáveis pode afetar negativamente a precisão da pesquisa ao saturar demais o algoritmo de classificação e retornar muitos resultados. Isso pode levar a resultados de pesquisa irrelevantes.

É possível aplicar uma ponderação relativa aos campos pesquisáveis, mas, devido aos padrões robustos, isso raramente é necessário. Consulte Campos pesquisáveis de peso abaixo.

O sistema de tíquetes de suporte de um provedor de serviços de Internet armazena cada tíquete como um documento estruturado. Se esses documentos contiverem campos de texto pesquisáveis, como issue_description ou resolution_notes, um representante de suporte poderá fazer uma consulta relacionada ao conteúdo desses campos, como como corrigir a lentidão da Internet após a redefinição do modem. O sistema mostraria os documentos que contêm qualquer um desses termos de pesquisa, incluindo modem, internet, velocidade, em um ou ambos os campos issue_description ou resolution_notes.
Correspondência de prefixo
(Prévia)

Permite campos de texto de correspondência de prefixo usando o operador STARTS_WITH em expressões de filtro. Somente campos do tipo String ou String Array podem ser definidos como "Correspondência de prefixo".

Para mais informações, consulte Disponibilizar campos para correspondência parcial e de prefixo abaixo.

Definir um campo como correspondência de prefixo permite que o mecanismo de pesquisa corresponda a strings de consulta que são prefixos do valor do campo. Isso é particularmente útil para corresponder a identificadores, caminhos ou códigos hierárquicos em que o início da string é conhecido. A correspondência de prefixo é limitada aos primeiros 12 caracteres do valor do campo normalizado e aumenta o tamanho do índice de pesquisa. Não é possível definir mais de 10 campos como correspondência de prefixo.

Você tem um campo, ticket_id, que usa um formato como <country-code><city-code><number>. Exemplos incluem UKLON100, UKMAN100, UKMAN101 e USNY200. Para encontrar todos os tíquetes de Manchester (Reino Unido), defina o campo ticket_id como correspondência de prefixo e use o filtro ticket_id: STARTS_WITH("UKMAN"), que retorna UKMAN100 e UKMAN101.
Parcialmente correspondente
(pré-lançamento)

Permite correspondência parcial de string em campos de texto usando o operador CONTAINS em expressões de filtro. Somente campos do tipo String ou String Array podem ser definidos como parcialmente correspondentes.

Para mais informações, consulte Disponibilizar campos para correspondência parcial e de prefixo abaixo.

Definir um campo como parcialmente correspondente permite a correspondência baseada em tokens dentro de um campo, permitindo que os usuários encontrem conteúdo quando apenas uma parte do valor do campo é conhecida. O mecanismo de pesquisa corresponde a tokens de consulta com tokens no valor do campo, independente da ordem. Observação: marcar um campo como parcialmente correspondente aumenta o tamanho do índice da Pesquisa. Não é possível definir mais de 10 campos como parcialmente correspondentes.

Você quer filtrar regiões na Europa. Os nomes region incluem Central Europe e Eastern Europe. Se o filtro for region: ANY("Europe"), você não vai receber nenhuma correspondência. No entanto, se o campo region estiver definido como parcialmente correspondente, você poderá filtrar com region: CONTAINS("Europe") e receber correspondências para Central Europe e Eastern Europe.

Tabela dinâmica Oferece filtros contextuais para segmentar melhor as pesquisas dos usuários. Definir um campo como Dynamic Facetable permite que o sistema gere automaticamente filtros interativos (facetas) com base nos valores exclusivos presentes no campo. Definir um campo como Dynamic facetable permite que os usuários refinem dinamicamente os resultados da pesquisa selecionando categorias ou atributos derivados diretamente dos dados ingeridos, sem precisar pré-definir manualmente todas as opções de filtro possíveis. Isso permite que o usuário restrinja a pesquisa a conteúdo da Web altamente específico.
Use Dynamic Facetable com Searchable para conseguir resultados melhores, o que melhora o recall da pesquisa e a qualidade das facetas oferecidas ao usuário. 		As páginas de uma base de conhecimento corporativa interna, como políticas de RH, são ingeridas com dados como department, document_type ou last_modified_date. Se esses campos forem marcados como dynamic facetable, uma pesquisa de um funcionário por um termo como reembolso de despesas vai gerar filtros interativos com base nos resultados relevantes encontrados. Nesse caso, a interface da Web pode mostrar refinamentos para Departamento: Finanças, Viagens, Tipo de documento: Política, Perguntas frequentes ou Data da última modificação: Este trimestre, Ano passado.
Recuperável Quando uma consulta de pesquisa encontra conteúdo correspondente, o mecanismo de pesquisa pode extrair os valores dos campos recuperáveis para exibição ou uso no aplicativo. Isso significa que as informações do documento original são mostradas como parte dos resultados da pesquisa. Os campos de chave (identificadores exclusivos de documentos) são configurados como recuperáveis. Os campos recuperáveis fornecem contexto de pesquisa ao distinguir campos cujos valores podem ser mostrados daqueles que só devem ser usados na lógica de pesquisa, mas cujos valores brutos não devem ser mostrados ao usuário final. Para uma pesquisa de produtos no site de um comerciante, product_id, name, price e um image_url são campos típicos que você quer definir como recuperáveis. Por outro lado, o internal_tracking_code pode ser indexado e filtrado apenas para fins administrativos, mas não recuperado em resultados de pesquisa públicos.
Concluível Permite que o conteúdo de um campo seja usado para sugestões de consulta de pesquisa. Para mais informações, consulte Configurar o preenchimento automático.

Essa configuração permite que os valores nesse campo sejam usados para fornecer sugestões de consulta em tempo real à medida que os usuários digitam. Esse recurso ajuda a direcionar os usuários para conteúdo relevante e acelera o processo de pesquisa. Alguns fatores, como o uso da filtragem por linguagem natural, podem afetar essa performance.

 Se o campo completable estiver definido como product_name, brand e category, quando o usuário digitar Tech, as sugestões de preenchimento automático poderão mostrar:
  • TechCo (do campo brand)
  • TechCo UltraBook X1 (do campo product_name)
  • Tecnologia GameMaster Pro (outro produto do campo category)
Filtrável Permite que as recomendações usem um campo para filtrar os resultados recomendados, determinando quais resultados da pesquisa seus usuários veem. Para informações sobre como filtrar recomendações, consulte Filtrar recomendações. Definir um campo como Filterable ajuda a personalizar as recomendações para os usuários. Observe que os limites de filtragem são aplicáveis. Uma configuração de filtro por idioma e drama pode ter esta aparência: language_code: ANY("en", "fr") OR categories: ANY("drama").

Diferenças entre as configurações usadas com frequência

Há diferenças importantes entre as configurações de campo indexável, pesquisável e recuperável. A tabela resume essas diferenças.

Recurso Indexável Pesquisável Recuperável
Função principal Disponibiliza o conteúdo do campo para o mecanismo de pesquisa. Permite consultas de texto completo no conteúdo do campo Permite que o valor do campo seja retornado nos resultados da pesquisa.
Análise O conteúdo é processado e colocado em um índice. Geralmente passa por uma análise lexical extensa. O valor é armazenado como está para exibição.
Será que...
...Pesquisável? Sim (geralmente um pré-requisito) N/A Não necessariamente (pode ser recuperável sem ser pesquisável)
...Recuperável? Não necessariamente Não necessariamente N/A
...Filtrável/ordenável/transformável em atributo? Sim (geralmente um pré-requisito para eles também) Não diretamente. Esses são atributos separados, geralmente criados em um campo indexável. Não diretamente. Esses atributos se relacionam à forma como o campo é indexado e consultado, não apenas exibido.

Na prática, muitos campos cruciais para a experiência do usuário (como títulos, descrições e informações de identificação) costumam ser definidos como indexable, searchable e retrievable.

Limitações

As configurações de campo têm as seguintes limitações:

  • É possível configurar até 50 campos como indexáveis, pesquisáveis, recuperáveis ou com facetas dinâmicas.
  • Para configurar um campo como dinâmico e com facetas, ele precisa primeiro ser configurado como indexável.
  • Para mudar a configuração indexável, é necessário indexar os dados de novo, o que pode levar horas, principalmente para grandes armazenamentos de dados.

Se você estiver configurando campos para um app de pesquisa de mídia e quiser informações detalhadas sobre os campos no esquema, consulte Sobre documentos de mídia e repositórios de dados.

Atualizar as configurações de campo

Para atualizar as configurações de campo:

  1. No console Google Cloud , acesse a página Aplicativos de IA.

    Aplicativos de IA

  2. Clique no nome do app que você quer editar.

  3. Clique em Dados.

  4. Clique na guia Esquema. Essa guia mostra as configurações atuais dos campos.

    A guia Esquema não vai aparecer se o repositório de dados tiver dados básicos de site ou dados não estruturados sem metadados.

  5. Clique em Editar.

  6. Selecione ou desmarque as configurações de campo que você precisa atualizar. Algumas configurações de campo estão indisponíveis. Por exemplo, campos numéricos não podem ser definidos como Pesquisável.

  7. Clique em Salvar para aplicar as alterações.

Se você marcar um campo como pesquisável, poderá especificar um peso para indicar a importância relativa dele nos resultados da pesquisa. Na maioria das situações, não é necessário especificar ponderações para campos individuais porque as ponderações padrão funcionam bem.

No entanto, o ajuste de ponderações pode ser necessário em algumas situações, por exemplo:

  • Você está migrando dados de uma plataforma de pesquisa que já usa campos ponderados.

  • Quando os pesos padrão não fornecem resultados de pesquisa satisfatórios. Isso pode acontecer quando você tem muitos campos pesquisáveis e alguns são muito mais importantes que outros.

    Talvez o resumo seja o campo mais importante para as pesquisas, e você queira priorizar esse texto.

    Ou o esquema tem um campo com palavras-chave altamente relevantes que são excelentes preditores de resultados da pesquisa, mas, como esse campo é muito menor do que outros, sua influência é frequentemente ofuscada por campos mais longos. Aumentar o peso garante que ele tenha o impacto pretendido.

Níveis de peso

As ponderações são agrupadas nos seguintes níveis:

Importância do campo Explicação
Muito baixa Um valor baixo que o sistema ainda considera ao combinar pontuações de todos os campos. Se você quiser ainda menos peso para que o efeito seja insignificante, não marque o campo como pesquisável.
Baixa Um peso menor que o padrão.
Padrão O peso padrão para campos pesquisáveis. Esse peso oferece um desempenho razoavelmente bom para a maioria dos casos.
Alta Um peso visivelmente maior que o padrão.
Muito alto Um peso dominante. Normalmente, você reserva isso para, no máximo, um campo.

Atualização do esquema e reindexação

Para adicionar ponderações aos campos pesquisáveis, é necessário atualizar o esquema e reindexar os dados no repositório de dados. A atualização do esquema leva horas, e não há um indicador confiável para informar quando a indexação é concluída. Por isso, é necessário superestimar o tempo de indexação.

Definir níveis de ponderação nos campos

A tarefa de definir níveis de ponderação para campos pode ser tediosa porque você só deve fazer pequenas mudanças e revisar cuidadosamente os resultados da pesquisa depois para verificar consequências não intencionais. Depois de cada mudança, aguarde a conclusão da reindexação antes de avaliar o impacto da mudança.

É possível configurar a ponderação do campo de pesquisa apenas pela API. Esse recurso não está disponível no console Google Cloud .

Para definir ponderações, atualize o esquema do repositório de dados usando o método da API projects.locations.dataStores.schemas.patch.

  1. Se você ainda não tiver um esquema, siga as instruções para acessar a definição em Ver uma definição de esquema.

  2. Siga as instruções para atualizar o esquema de forma programática. Adicione pesos a um ou mais campos pesquisáveis, como nestes exemplos:

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

    Neste exemplo, o campo summary está definido com um peso maior do que o normal, e o campo uri, com um peso menor. Se você quiser retornar um peso ao valor padrão, defina-o como default.

    Os valores permitidos para o parâmetro "peso" são:

    • very_low
    • low
    • default
    • high
    • very_high

  3. Aguarde a conclusão da reindexação e teste o comportamento da pesquisa.

Disponibilizar campos para correspondência parcial e de prefixo (pré-lançamento)

Para campos do tipo string, é possível editar o esquema para disponibilizar os campos para correspondência de prefixo ou parcial. Isso permite usar STARTS_WITH ou CONTAINS em expressões de filtro.

Atualização do esquema e reindexação

Para disponibilizar campos para correspondência parcial ou de prefixo, é necessário atualizar o esquema e reindexar os dados no repositório de dados. A atualização do esquema leva horas, e não há um indicador confiável para informar quando a indexação é concluída. Por isso, é necessário superestimar o tempo de indexação.

Atualizar o esquema para correspondência parcial e de prefixo

Para especificar campos como disponíveis para correspondência de prefixo ou parcial, atualize o esquema do repositório de dados usando o método da API projects.locations.dataStores.schemas.patch.

  1. Se você ainda não tiver um esquema, siga as instruções para acessar a definição em Ver uma definição de esquema.

  2. Siga as instruções para atualizar o esquema de forma programática. Defina os parâmetros correspondentes como true no esquema, como nestes exemplos:

    "zone": {
   "type": "string",
   "searchable": true,
   "prefixMatchable": true
 },
 "region": {
   "type": "string",
   "searchable": true,
   "partialMatchable": true
 },
 "model": {
   "type": "string",
   "searchable": true,
   "prefixMatchable": true,
   "partialMatchable": true
 },

    Neste exemplo, o campo zone está definido para correspondência de prefixo. Até 12 caracteres, sem diferenciação de maiúsculas e minúsculas, podem ser usados na expressão de filtro para corresponder ao valor do campo. O campo region está definido para correspondência parcial.

  3. Aguarde a conclusão da reindexação.

Detalhes sobre a correspondência de prefixos

Com a correspondência de prefixos na Pesquisa de agentes, é possível filtrar resultados com base em se o valor de um campo começa com uma string específica. Esse recurso é alimentado pelo operador STARTS_WITH e exige que o campo de texto de destino seja configurado como prefixMatchable no esquema.

Lógica de normalização e correspondência

Para otimizar a performance e garantir a consistência, o sistema aplica um processo de normalização específico ao valor do campo (durante a indexação) e à string de consulta (durante a pesquisa).

  1. Minúsculas: todos os caracteres são convertidos para minúsculas. Isso faz com que a correspondência não diferencie maiúsculas de minúsculas.

  2. Truncamento de 12 caracteres: o sistema considera apenas os primeiros 12 caracteres da string. Qualquer caractere além desse limite é ignorado para fins de correspondência de prefixo.

Como funciona

No momento da indexação, para um campo marcado como prefixMatchable, o sistema gera tokens de prefixo para os primeiros 12 caracteres. Para um valor como asia-south1-c, o índice armazena tokens para a, as, asi, asia, asia- e assim por diante, até o 12º caractere (asia-south1-).

No momento da consulta, a string fornecida ao operador STARTS_WITH também é convertida para minúsculas e truncada em 12 caracteres. Em seguida, a consulta é comparada com os tokens de prefixo armazenados.

Exemplos

Os exemplos a seguir mostram como a normalização de 12 caracteres afeta os resultados da pesquisa:

  • Correspondências amplas: STARTS_WITH("A") corresponde a qualquer valor que comece com "a" (sem diferenciação de maiúsculas e minúsculas), como asia, australia ou africa.

  • Prefixos parciais: STARTS_WITH("asia-south") corresponde a asia-south1-a e asia-southeast1-b porque ambos começam com a string de 10 caracteres especificada.

  • Comportamento de truncamento: como apenas os primeiros 12 caracteres são correspondentes, STARTS_WITH("asia-south1-a") corresponde a um valor de campo de asia-south1-c. Isso acontece porque ambas as strings são normalizadas para o mesmo prefixo de 12 caracteres: asia-south1-.

Detalhes sobre a correspondência parcial

A correspondência parcial na Pesquisa do agente permite filtrar resultados com base em se o valor de um campo contém palavras ou tokens específicos. Esse recurso é alimentado pelo operador CONTAINS e exige que o campo de texto de destino seja configurado como partialMatchable no esquema.

Lógica de normalização e tokenização

A Pesquisa do agente normaliza e tokeniza o valor do campo (durante a indexação) e a string de consulta (durante a pesquisa):

  • Conversão em minúsculas: a Pesquisa do agente converte os caracteres em minúsculas. Isso faz com que a correspondência não diferencie maiúsculas de minúsculas.

  • Tokenização: a Pesquisa do agente divide a string em tokens individuais (palavras) usando espaços e outros caracteres como delimitadores.

    • Delimitadores padrão: espaços e pontuação comum atuam como delimitadores, incluindo hífens (-), barras (/), vírgulas (,), pontos (.), asteriscos (*), chaves ({ }), colchetes ([ ]), parênteses (( )) e apóstrofos (').

    • Não delimitadores: o "e" comercial (&) e o sublinhado (_) não funcionam como delimitadores. O sistema trata os caracteres unidos por esses símbolos como um único token.

    • Delimitador de e-mail (@): o símbolo @ funciona como um delimitador especial para ajudar a reconhecer endereços de e-mail. O sistema gera tokens para os componentes individuais e para as formas combinadas. Por exemplo, ele tokeniza support+tier1@example.com em support, tier1, example, com, support+tier1@example.com e support@example.com.

Como funciona

No momento da indexação, para um campo marcado como partialMatchable, o sistema normaliza e tokeniza o valor do campo e armazena os tokens resultantes no índice. Por exemplo, ele tokeniza um valor de campo 25-meter, outdoor, swimming pool para [25, meter, outdoor, swimming, pool].

No momento da consulta, a string fornecida ao operador CONTAINS passa pelo mesmo processo de normalização e tokenização. Em seguida, o mecanismo de pesquisa verifica se todos os tokens de consulta resultantes correspondem aos tokens armazenados para o campo. A ordem dos tokens não tem efeito.

Exemplos

Os exemplos a seguir mostram como a tokenização afeta os resultados da correspondência parcial:

  • Correspondência básica de token: se o valor do campo for 25-meter, outdoor, swimming pool, um filtro de CONTAINS("Outdoor pool") vai corresponder. O sistema tokeniza a consulta para [outdoor, pool], que existem nos tokens do campo.

  • Independência de ordem: um filtro de CONTAINS("pool outdoor") também corresponde ao valor do campo 25-meter, outdoor, swimming pool porque o sistema verifica a presença de cada token, independente da ordem.

  • Correspondência de endereços de e-mail: se um campo armazena o e-mail support+tier1@example.com, filtros como CONTAINS("support"), CONTAINS("example.com") ou CONTAINS("support@example.com") correspondem devido à tokenização especial do símbolo @.

A seguir