Índices de pesquisa no Azure AI Search

No Azure AI Search, um índice de pesquisa é o seu conteúdo pesquisável, disponível para o motor de pesquisa para indexação, pesquisa de texto completo, pesquisa vetorial, pesquisa híbrida e consultas filtradas. Um índice é definido por um esquema e salvo no serviço de pesquisa, com a importação de dados seguindo como uma segunda etapa. Este conteúdo existe dentro do seu serviço de pesquisa, além dos seus armazenamentos de dados primários, o que é necessário para os tempos de resposta de milissegundos esperados nas aplicações de pesquisa modernas. Exceto para cenários de indexação controlados por indexador, o serviço de pesquisa nunca se conecta ou consulta seus dados de origem.

Se você deseja criar e gerenciar um índice de pesquisa, este artigo ajuda você a entender os seguintes pontos:

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

Prefere ser prático imediatamente? Consulte Criar um índice de pesquisa.

Esquema de um índice de pesquisa

No Azure AI Search, os índices contêm documentos de pesquisa. Conceitualmente, um documento é uma única unidade de dados pesquisáveis em seu índice. Por exemplo, um varejista pode ter um documento para cada produto, uma universidade pode ter um documento para cada classe, 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 familiares: um índice de pesquisa equivale a uma tabela e os documentos são aproximadamente equivalentes a linhas em uma tabela.

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

{
  "name": "name_of_index, unique across the service",
  "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 emedding 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 são recolhidos para brevidade, mas os links a seguir fornecem detalhes:

• Os sugeridores suportam consultas de digitação antecipada, como o preenchimento automático.
• scoringProfiles são usados para ajuste de relevância.
• Os analisadores são usados para processar strings em tokens de acordo com regras linguísticas ou outras características suportadas pelo analisador.
• corsOptions, ou Cross-origin remote scripting (CORS), é usado para aplicativos que emitem solicitações de diferentes domínios.
• encryptionKey configura criptografia dupla de conteúdo confidencial no índice.
• A semântica configura a reclassificação semântica em texto completo e pesquisa híbrida.
• vectorSearch configura campos vetoriais e consultas.

Definições de campo

Um documento de pesquisa é definido pela coleção "fields" no corpo da solicitação Create Index. Você precisa de campos para identificação de documentos (chaves), armazenamento de texto pesquisável e campos para suportar filtros, facetas e classificação. Você também pode precisar de campos para dados que um usuário nunca vê. Por exemplo, você pode querer campos para margens de lucro ou promoções de marketing que você pode usar em um perfil de pontuação para aumentar uma pontuação de pesquisa.

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

Atributos do campo

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

Os campos de cadeia de caracteres são frequentemente marcados como "pesquisáveis" e "recuperáveis". Os campos usados para restringir os resultados da pesquisa incluem "classificável", "filtrável" e "facetable".

Embora possa adicionar novos campos em qualquer altura, as definições de campos existentes estão bloqueadas durante o ciclo de vida do índice. Por este motivo, os programadores utilizam normalmente o portal para criar índices simples, testar ideias ou utilizar as páginas do portal para procurar uma definição. A iteração frequente através de uma estrutura de índice é mais eficiente se seguir uma abordagem baseada em código de modo a poder reconstruir o índice facilmente.

Estrutura física e dimensão

No Azure AI Search, a estrutura física de um índice é, em grande parte, uma implementação interna. Você pode acessar seu esquema, consultar seu conteúdo, monitorar seu tamanho e gerenciar a capacidade, mas os próprios clusters (índices invertidos, índices vetoriais, fragmentos e outros arquivos e pastas) são gerenciados internamente pela Microsoft.

Você pode monitorar o tamanho do índice na página Índices de gerenciamento > de pesquisa no portal do Azure ou emitindo uma solicitação GET INDEX em seu serviço de pesquisa. Você também pode emitir uma solicitação de Estatísticas de Serviço e verificar o valor do tamanho do armazenamento.

O tamanho de um índice é determinado por:

• Quantidade e composição dos seus documentos
• Atributos em campos individuais
• Configuração do índice (especificamente, se você inclui sugestões)

A composição e a quantidade do documento são determinadas pelo que você escolhe importar. Lembre-se de que um índice de pesquisa deve conter apenas conteúdo pesquisável. Se os dados de origem incluírem campos binários, omita esses campos, a menos que você esteja usando o enriquecimento de IA para decifrar 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 cria 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. Em contraste, um atributo "filtrável" ou "classificável" suporta iteração em cadeias de caracteres não modificadas. O exemplo na próxima seção mostra variações no tamanho do índice com base nos atributos selecionados.

Os sugestivos são construções que suportam consultas de digitação antecipada ou de preenchimento automático. Como tal, quando você inclui um sugestão, o processo de indexação cria as estruturas de dados necessárias para correspondências de caracteres literais. Os sugestionadores são implementados no nível do campo, portanto, escolha apenas os campos que são razoáveis para digitação antecipada.

Exemplo demonstrando as implicações de armazenamento de atributos e sugestões

A captura de tela a seguir ilustra padrões de armazenamento de índice resultantes de várias combinações de atributos. O índice é baseado no índice de amostra de imóveis, que você pode criar facilmente usando o assistente de importação de dados e dados de exemplo internos. Embora os esquemas de índice não sejam mostrados, você pode inferir os atributos com base no nome do índice. Por exemplo, o índice pesquisável de imóveis tem o atributo "pesquisável" selecionado e nada mais, o índice recuperável de imóveis tem o atributo "recuperável" selecionado e nada mais, e assim por diante.

Embora essas variantes de índice sejam um pouco artificiais, podemos nos referir a elas para comparações amplas de como os atributos afetam o armazenamento:

• "recuperável" não tem efeito sobre o tamanho do índice.
• "filtrável", "classificável", "facetable" consomem mais armazenamento.
• O sugeridor tem um grande potencial para aumentar o tamanho do índice, mas não tanto quanto a captura de tela indicaria (todos os campos que poderiam ser considerados sugestivos foram selecionados, o que não é um cenário provável na maioria dos índices).

Também não refletido na tabela anterior é o efeito dos analisadores. Se você usar o tokenizador edgeNgram para armazenar sequências literais de caracteres (a, ab, abc, abcd), o índice será maior do que se você usar o analisador padrão.

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

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

Isolamento do índice

No Azure AI Search, você trabalha com um índice de cada vez, onde todas as operações relacionadas ao índice visam um único índice. Não há nenhum conceito de índices relacionados ou a 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 estará totalmente operacional até que todos os documentos estejam indexados. Internamente, um índice de pesquisa é distribuído entre partições e executado em réplicas. O índice físico é gerenciado internamente. O índice lógico é gerenciado por você.

Um índice está continuamente disponível, sem capacidade de pausar ou colocá-lo offline. Por ser projetado para operação contínua, quaisquer atualizações ao seu conteúdo, ou adições ao próprio índice, acontecem em tempo real. Como resultado, as consultas podem retornar temporariamente resultados incompletos se uma solicitação coincidir com uma atualização do documento.

Observe que a continuidade da consulta existe para operações de documento (atualização ou exclusão) e para modificações que não afetam a estrutura existente e a integridade do índice atual (como a adição de novos campos). Se você precisar fazer atualizações estruturais (alterando campos existentes), elas geralmente são gerenciadas usando um fluxo de trabalho 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 optam por "versionar" um campo criando um novo que coexiste com uma versão anterior. Com o tempo, isso leva a conteúdo órfão na forma de campos obsoletos ou definições obsoletas de analisador personalizado, especialmente em um índice de produção que é caro para replicar. Você pode resolver esses problemas em atualizações planejadas para o índice como parte do gerenciamento do ciclo de vida do índice.

Conexão e segurança do endpoint

Todas as solicitações de indexação e consulta destinam-se a um índice. Os parâmetros de avaliação são geralmente um dos seguintes:

Como conectar-se ao Azure AI Search

1. Comece com o portal do Azure. Os assinantes do Azure, ou a pessoa que criou o serviço de pesquisa, podem 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 inícios rápidos para as primeiras etapas:

   • Guia de início rápido: REST
   • Guia de início rápido: SDKs do Azure
   • Guia de início rápido: RAG (usando o Visual Studio Code e um bloco de anotações Jupyter)

Próximos passos

Você pode obter experiência prática na criação de um índice usando praticamente qualquer exemplo ou passo a passo para o Azure AI Search. Para começar, você pode escolher qualquer um dos inícios rápidos do índice.

Mas você também vai querer se familiarizar com metodologias para carregar um índice com dados. A definição do índice e as estratégias de importação de dados são definidas em conjunto. Os artigos a seguir fornecem mais informações sobre como criar e carregar um índice.

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