Índices de pesquisa na Pesquisa de IA do Azure

No Azure AI Search, um índice de pesquisa é o conteúdo pesquisável, disponível para o mecanismo de pesquisa para indexação, pesquisa agente, pesquisa de texto completo, pesquisa de vetor, pesquisa híbrida e consultas filtradas. Um índice é definido por um esquema e salvo no serviço de pesquisa, com a ingestão de dados seguindo como uma segunda etapa. O conteúdo indexado existe em seu serviço de pesquisa, além dos repositórios de dados externos primários, o que é necessário para os tempos de resposta de milissegundos esperados em aplicativos de pesquisa modernos. Exceto para cenários de indexação controlados por indexador, o serviço de pesquisa nunca se conecta ou consulta seus dados de origem externos.

Este artigo aborda os principais conceitos para criar e gerenciar um índice de pesquisa, incluindo:

• Conteúdo (documentos e esquema)
• Estrutura física de dados
• Operações básicas

Tip

Quer começar imediatamente? Consulte Criar um índice de pesquisa.

Esquema de um índice de pesquisa

Na IA do Azure Search, os índices contêm documentos de pesquisa. Conceitualmente, um documento é uma única unidade de dados pesquisáveis no índice. Por exemplo, um varejista pode ter um documento para cada produto, uma universidade pode ter um documento para cada aula, um site de viagens pode ter um documento para cada hotel e destino, e assim por diante. Mapeando esses conceitos para equivalentes de banco de dados mais conhecidos: um índice de pesquisa é semelhante a uma tabela e documentos são equivalentes a linhas em uma tabela.

A estrutura de um documento é determinada pelo esquema de índice, conforme ilustrado no exemplo a seguir. Normalmente, a coleção de "campos" é a maior parte de um índice, onde cada campo é nomeado, atribuído a um tipo de dado e atribuído com os comportamentos permitidos que determinam como ele é usado.

{
  "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){ }
}

Outros elementos foram recolhidos para fins de brevidade, mas os seguintes links fornecem detalhes:

• suggesters dão suporte a consultas de preenchimento automático.
• scoringProfiles são usados para ajuste de relevância.
• analyzers são usados para processar cadeias de caracteres em tokens de acordo com regras linguísticas ou outras características compatíveis com o analisador.
• corsOptions, ou CORS (script remoto entre origens), é usado para aplicativos que emitem solicitações de domínios diferentes.
• encryptionKey configura a criptografia dupla de conteúdo confidencial no índice.
• semantic configura a reclassificação semântica em texto completo e pesquisa híbrida.
• vectorSearch configura campos de vetor e consultas.

Definições do campo

Um documento de pesquisa é definido pela coleção "fields" no corpo da solicitação Criar Índice. Você precisa de campos para identificação de documento (chaves), que armazenem texto pesquisável, e campos para dar suporte a filtros, facetas e classificações. Você também pode precisar de campos para dados que um usuário nunca vê. Por exemplo, talvez você queira campos para margens de lucro ou promoções de marketing que possam ser usados em perfil de pontuação para melhorar a classificação de pesquisa.

Se os dados de entrada forem hierárquicos por natureza, você poderá representá-los em um índice como um tipo complexo, usado para estruturas aninhadas. O conjunto de dados de exemplo, Hotéis, ilustra os tipos complexos usando um endereço (contém vários subcampos) que têm uma relação de um para um com cada hotel e uma coleção complexa de quartos, em que vários quartos são associados a cada hotel.

Atributos do campo

Os atributos de campo determinam como um campo é usado, por exemplo, se ele é usado na pesquisa de texto completo, na navegação facetada, nas operações de classificação, e assim por diante.

Geralmente, os campos de cadeia de caracteres são marcados como “pesquisáveis” e “recuperáveis”. Os campos usados para restringir os resultados da pesquisa incluem “classificável”, “filtrável” e “com faceta”.

Attribute	Description
"searchable"	Texto completo ou vetor pesquisável. Campo de texto estão sujeitos à análise lexical, como separação de palavras durante a indexação. Se você definir um campo pesquisável com um valor como “dia ensolarado”, internamente, ele será dividido nos tokens individuais “dia” e “ensolarado”. Para obter detalhes, consulte Como funciona a pesquisa de texto completo.
"filterable"	Referenciado nas consultas $filter. Campos filtráveis dos tipos Edm.String ou Collection(Edm.String) não são submetidos à separação de palavras, portanto, as comparações são apenas para as correspondências exatas. Por exemplo, se você definir um campo f como “dia ensolarado”, $filter=f eq 'sunny' não encontrará correspondências, mas $filter=f eq 'sunny day' as encontrará.
"sortable"	Por padrão, o sistema classifica os resultados pela pontuação, mas você pode configurar a classificação com base nos campos dos documentos. Campos do tipo Collection(Edm.String) não podem ser “classificáveis”.
"facetable"	Normalmente, usado em uma apresentação dos resultados da pesquisa que inclui uma contagem de ocorrências por categoria (por exemplo, hotéis em uma cidade específica). Essa opção não pode ser usada com os campos do tipo Edm.GeographyPoint. Campos do tipo Edm.String que são “filtráveis”, “classificáveis” ou “facetáveis” podem ter, no máximo, 32 KB. Para obter detalhes, consulte Criar índice (API REST).
"key"	Identificador exclusivo para documentos no índice. Exatamente um campo deve ser escolhido como o campo chave e deve ser do tipo Edm.String.
"retrievable"	Determina se o campo pode ser retornado em um resultado da pesquisa. Isso é útil quando você quer usar um campo (por exemplo, margem de lucro) como mecanismo de filtro, classificação ou pontuação, mas não quer que o campo seja visível para o usuário final. Esse atributo deve ser true for key .

Embora seja possível adicionar novos campos a qualquer momento, as definições de campo existentes são bloqueadas durante o tempo de vida do índice. Por esse motivo, os desenvolvedores geralmente usam o portal do Azure para criar índices simples, testar ideias ou usar as páginas do portal do Azure para pesquisar uma configuração. A iteração frequente em um design de índice será mais eficiente se você seguir uma abordagem baseada em código, de modo que você possa recriar o índice com facilidade.

Note

As APIs usadas para criar um índice têm comportamentos padrão variados. Para as APIs REST, a maioria dos atributos é habilitada por padrão (por exemplo, "pesquisável" e "recuperável" são verdadeiros para campos de cadeia de caracteres) e, muitas vezes, você só precisa defini-los se desejar desativá-los. Para o SDK .NET, o oposto é verdadeiro. Em uma propriedade é definida de forma explícita, o padrão é desabilitar o comportamento de pesquisa correspondente a menos que você o habilite especificamente.

Estrutura física e tamanho

Na IA do Azure Search, a estrutura física de um índice é basicamente uma implementação interna. Você pode acessar seu esquema, carregar e consultar seu conteúdo, monitorar seu tamanho e gerenciar sua capacidade. No entanto, a Microsoft gerencia a infraestrutura e as estruturas de dados físicos armazenadas com seu serviço de pesquisa.

Você pode monitorar o tamanho do índice na página Índices de Gerenciamento > de Pesquisa no portal do Azure. Como alternativa, você pode emitir uma solicitação GET INDEX no serviço de pesquisa ou em uma solicitação de Estatísticas de Serviço para verificar o valor do tamanho do armazenamento.

O tamanho de um índice é determinado pelo:

• Quantidade e composição de seus documentos.
• Atributos em campos individuais: "recuperável" não sobrecarrega seu índice, mas "filtrável", "ordenável" e "facetable" consomem mais armazenamento para armazenar texto não tokenizado.
• Configuração de índice. Especificamente, se você incluir sugestores ou analisadores especializados. Se você usar o tokenizer edgeNgram para armazenar sequências verbatim de caracteres (a, ab, abc, abcd), o índice será maior do que se você usar o analisador padrão.

A composição e a quantidade de documentos serão determinadas pelo que você optar por importar. Lembre-se de que um índice de pesquisa deve conter apenas conteúdo útil para seu aplicativo de pesquisa. Se os dados de origem incluirem campos binários, omita esses campos, a menos que você esteja usando o enriquecimento de IA para quebrar e analisar o conteúdo para criar informações pesquisáveis em texto.

Os atributos de campo determinam comportamentos. Para dar suporte a esses comportamentos, o processo de indexação criará as estruturas de dados necessárias. Por exemplo, para um campo do tipo Edm.String, "pesquisável" invoca a pesquisa de texto completo, que verifica índices invertidos para o termo tokenizado. Por outro lado, um atributo “filtrável” ou “classificável” dá suporte à iteração em cadeias de caracteres não modificadas.

Os sugestores são constructos que dão suporte a consultas de preenchimento automático. Quando você inclui um sugestor, o processo de indexação cria as estruturas de dados necessárias para correspondências de caracteres verbatim. Os sugestores são implementados no nível de campo, portanto, escolha apenas os campos que são razoáveis para o preenchimento automático.

Operações básicas e interação

Agora que você tem uma ideia melhor do que é um índice, esta seção apresenta operações de runtime de índice, incluindo a conexão e a proteção de um único índice.

Note

Não há suporte para portal ou API para mover ou copiar um índice. Normalmente, você aponta sua implantação de aplicativo para um serviço de pesquisa diferente (usando o mesmo nome de índice) ou revisa o nome para criar uma cópia no serviço de pesquisa atual e, em seguida, compilá-la.

Isolamento de índice

No Azure AI Search, você trabalha com um índice por vez. Todas as operações relacionadas ao índice têm como destino um único índice. Não há conceitos de índices relacionados nem junção de índices independentes para indexação ou consulta.

Disponível continuamente

Um índice fica imediatamente disponível para consultas assim que o primeiro documento é indexado, mas não está totalmente operacional até que todos os documentos sejam indexados. Internamente, um índice é distribuído entre partições e executado em réplicas. O índice físico é gerenciado internamente. Você gerencia o índice lógico.

Um índice está continuamente disponível e não pode ser pausado ou colocado offline. Como ele foi projetado para operação contínua, as atualizações de seu conteúdo e adições ao próprio índice ocorrem em tempo real. Se uma solicitação coincidir com uma atualização de documento, as consultas poderão retornar temporariamente resultados incompletos.

A continuidade da consulta existe para operações de documento, como atualização ou exclusão, e para modificações que não afetam a estrutura ou a integridade existentes de um índice, como a adição de novos campos. As atualizações estruturais, como a alteração de campos existentes, normalmente são gerenciadas usando um fluxo de trabalho de drop-and-rebuild em um ambiente de desenvolvimento ou criando uma nova versão do índice no serviço de produção.

Para evitar uma reconstrução do índice, alguns clientes que estão fazendo pequenas alterações versionam um campo criando um novo que coexiste com uma versão anterior. Ao longo do tempo, isso resulta em conteúdos órfãos, por meio de campos obsoletos e definições obsoletas do analisador personalizado, especialmente em um índice de produção cuja replicação é cara. Você pode resolver esses problemas durante atualizações planejadas para o índice como parte do gerenciamento do ciclo de vida do índice.

Conexão e segurança do ponto de extremidade

Todas as solicitações de indexação e consulta têm como destino um índice. Os pontos de extremidade geralmente são um dos seguintes:

Endpoint	Conexão e controle de acesso
<your-service>.search.windows.net/indexes	Tem como destino a coleção de índices. Usado ao criar, listar ou excluir um índice. Os direitos de administrador são necessários para essas operações e estão disponíveis por meio de chaves de API de administrador ou uma função de Colaborador de Pesquisa.
<your-service>.search.windows.net/indexes/<your-index>/docs	Tem como destino a coleção de documentos de um único índice. Usado ao consultar um índice ou atualização de dados. Para consultas, os direitos de leitura são suficientes e estão disponíveis por meio de chaves de API de consulta ou uma função de leitor de dados. Para a atualização de dados, são necessários direitos de administrador.

Como se conectar à Pesquisa de IA do Azure

1. Comece com o portal do Azure. Os assinantes do Azure ou a pessoa que criou o serviço de pesquisa pode gerenciar o serviço de pesquisa no portal do Azure. Uma assinatura do Azure requer permissões de Colaborador ou superiores para criar ou excluir serviços. Esse nível de permissão é suficiente para gerenciar totalmente um serviço de pesquisa no portal do Azure.

2. Experimente outros clientes para acesso programático. Recomendamos os guias de início rápido para as primeiras etapas:

   • Início Rápido: REST
   • Início Rápido: Pesquisa de texto completo
   • Início rápido: recuperação por meio de agentes

Próximas etapas

Você pode ter uma experiência prática ao criar um índice usando praticamente amostras ou passo a passo da IA do Azure Search. Os iniciantes podem escolher uma guia de início rápido do sumário.

Mas você também pode conhecer as metodologias para carregar um índice com dados. As estratégias de definição de índice e de importação de dados são definidas ao mesmo tempo. Os artigos a seguir oferecem mais informações para criar e carregar um índice.

• Criar um índice de pesquisa
• Atualizar um índice
• Criar um repositório de vetores
• Criar um alias de índice
• Visão geral da importação de dados
• Carregar um índice