Índices de pesquisa na Pesquisa de IA do Azure

Na Pesquisa de IA do Azure, um índice de pesquisa é o conteúdo pesquisável, disponível para mecanismo de pesquisa para indexação, pesquisa de texto completo, busca em vetores, 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 como segunda etapa. Esse conteúdo existe no seu serviço de pesquisa, separado dos armazenamentos de dados primários, que é necessário para os tempos de resposta de milissegundos esperados em aplicativos modernos de pesquisa. Exceto em cenários de indexação controlados por indexador, o serviço de pesquisa nunca se conecta aos dados de origem ou consulta esses dados.

Se você deseja criar e gerenciar um índice de pesquisa, este artigo vai ajudá-lo a entender os seguintes pontos:

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

Prefere por a mão na massa logo de cara? Confira 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",
  "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 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 interno, 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”.

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 para criar índices simples, testar ideias ou usar as páginas do portal 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.

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, consultar seu conteúdo, monitorar seu tamanho e gerenciar a capacidade, mas os clusters em si (í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 Gerenciamento de pesquisa > Índices 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:

• Pela quantidade e composição de seus documentos
• Pelos atributos em campos individuais
• Pela configuração do índice (especificamente, se você inclui sugestores)

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 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 de 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, em um campo do tipo Edm.String, “pesquisável” invoca a pesquisa de texto completo, que examina índices invertidos para o termo com token. Por outro lado, um atributo “filtrável” ou “classificável” dá suporte à 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 Sugestores são constructos que dão suporte a consultas de preenchimento automático ou autocompletar. Assim, quando você inclui um sugestor, o processo de indexação cria as estruturas de dados necessárias para as correspondências exatas de caracteres. 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.

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

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 imobiliário, que você pode criar facilmente usando o assistente de importação de dados e os dados de amostra 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 realestate-searchable tem o atributo “pesquisável” selecionado e nada mais, o índice realestate-retrievable tem o atributo “recuperável” selecionado e nada mais e assim por diante.

Embora essas variantes de índice sejam relativamente artificiais, podemos referenciá-las para obter amplas comparações de como os atributos afetam o armazenamento:

• "recuperável" não tem impacto no tamanho do índice.
• "filtráveis", "classificáveis", "facetáveis" consomem mais armazenamento.
• O sugestor 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 reconhecer sugestores foram selecionados, o que não é um cenário provável na maioria dos índices).

Na tabela anterior, também não aparece o impacto dos analyzers. 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.

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 tempo de execução de índice, incluindo a conexão e a segurança de um único índice.

Isolamento de índice

Na Pesquisa de IA do Azure, você trabalha com um índice por vez, em que 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 estará disponível imediatamente para consultas assim que o primeiro documento for indexado, mas não estará totalmente operacional até que todos os documentos sejam 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 pausar ou ficar offline. Como ele foi projetado para operação contínua, todas as atualizações de seu conteúdo ou adições ao próprio índice ocorrem em tempo real. Como resultado, as consultas poderão retornar temporariamente resultados incompletos se uma solicitação coincidir com uma atualização de documento.

Observe que a continuidade da consulta existe para as operações de documento (atualizando ou excluindo) e para as modificações que não afetam a estrutura e a integridade existentes do índice atual (como adicionar novos campos). Se você precisar fazer atualizações estruturais (alterando campos existentes), elas normalmente são gerenciadas usando um fluxo de trabalho de recomposição em um ambiente de desenvolvimento ou criando uma nova versão do índice no serviço de produção.

Para evitar a recriação de índice, alguns clientes que fazem pequenas alterações optam por fazer a “versão” de um campo criando um novo que coexiste junto com uma versão anterior. Ao longo do tempo, isso leva a conteúdos órfãos, na forma de campos obsoletos ou definições obsoletas do analisador personalizado, especialmente em um índice de produção cuja replicação é onerosa. 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 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:

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: SDKs do Azure
   • Início Rápido: RAG (usando o Visual Studio Code e um Jupyter notebook)

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
• Criar um repositório de vetores
• Criar um índice de alias
• Visão geral da importação de dados
• Carregar um índice