Criar um índice na IA do Azure Search
Neste artigo, saiba quais são as etapas para definir um esquema para um índice de pesquisa e enviá-lo para um serviço Pesquisa. Criar um índice estabelece as estruturas de dados físicos no seu serviço de pesquisa. Depois que o índice for criado, carregue o índice como uma tarefa separada.
Pré-requisitos
Permissões de gravação como um Colaborador do Serviço Pesquisa ou uma chave de API de administrador para autenticação baseada em chave.
Uma compreensão dos dados extras do dispositivo que você quer importar. Um índice de pesquisa é baseado no conteúdo externo que você quer tornar pesquisável. O conteúdo pesquisável é armazenado como campos em um índice. Você deve ter uma ideia clara de quais campos de origem deseja tornar pesquisáveis, recuperáveis, filtrados, facetáveis e classificáveis na Pesquisa de IA do Azure. Consulte a lista de verificação de esquema para obter diretrizes.
Um campo exclusivo nos dados de origem que possa ser usado como a chave (ou ID) do documento no índice.
Um local de índice estável. Não há suporte para mover um índice existente para um serviço de pesquisa diferente. Revisite os requisitos do aplicativo e verifique se o serviço de pesquisa existente (capacidade e região) é suficiente para suas necessidades. Se você estiver usando uma dependência dos serviços de IA do Azure ou do OpenAI do Azure, escolha uma região que forneça todos os recursos necessários.
Por fim, todas as camadas de serviço têm limites de índice no número de objetos que você pode criar. Por exemplo, se você estiver experimentando na camada Gratuita, só poderá ter três índices em um determinado momento. No próprio índice, há limites para vetores e limites de índice no número de campos simples e complexos.
Chaves de documentos
A criação do índice de pesquisa tem dois requisitos: um índice precisa ter um nome exclusivo no serviço de pesquisa e deve ter uma chave de documento. O atributo booliano key
em um campo pode ser definido como true para indicar qual campo fornece a chave do documento.
Uma chave de documento é o identificador exclusivo de um documento de pesquisa, e um documento de pesquisa é uma coleção de campos que descreve completamente algo. Por exemplo, se você estiver indexando um conjunto de dados de filmes, um documento de pesquisa conterá o título, o gênero e a duração de um único filme. Os nomes de filmes são exclusivos neste conjunto de dados, portanto, você pode usar o nome do filme como a chave do documento.
Na Pesquisa de IA do Azure, uma chave de documento é uma cadeia de caracteres e precisa se originar de valores exclusivos na fonte de dados que está fornecendo o conteúdo a ser indexado. Como regra geral, um serviço de pesquisa não gera valores de chave, mas, em alguns cenários, (como o Indexador de Tabelas do Azure), sintetiza os valores existentes para criar uma chave exclusiva para os documentos que estão sendo indexados. Outro cenário é a indexação um-para-muitos para dados em partes ou particionados, nesse caso, as chaves de documento são geradas para cada parte.
Durante a indexação incremental, em que o conteúdo novo e atualizado é indexado, os documentos de entrada com novas chaves são adicionados, enquanto os documentos de entrada com chaves existentes são mesclados ou substituídos, dependendo se os campos de índice são nulos ou preenchidos.
Pontos importantes sobre chaves de documento incluem:
- O comprimento máximo dos valores em um campo de chave é de 1.024 caracteres.
- Exatamente um campo de nível superior em cada índice precisa ser escolhido como o campo de chave e precisa ser do tipo
Edm.String
. - O padrão do atributo
key
é falso para campos simples e nulo para campos complexos.
Os campos-chave podem ser usados para pesquisar documentos diretamente e atualizar ou excluir documentos específicos. Os valores dos campos de chave são tratados de maneira diferenciada de maiúsculas de minúsculas ao pesquisar ou indexar documentos. Confira GET Documento (REST) e Index Documentos (REST) para obter detalhes.
Lista de verificação de esquema
Use esta lista de verificação para auxiliar as decisões de design do índice de pesquisa.
Examine as convenções de nomenclatura para que os nomes de índice e de campo esteja em conformidade com as regras de nomenclatura.
Examine tipos de dados com suporte. O tipo de dados afetará como o campo é usado. Por exemplo, o conteúdo numérico pode ser filtrado, mas não pesquisável por texto completo. O tipo de dados mais comum é
Edm.String
para texto pesquisável, que é tokenizado e consultado usando o mecanismo de pesquisa de texto completo. O tipo de dados mais comum para um campo vetorial éEdm.Single
, mas você também pode usar outros tipos.Identifique uma chave de documento. Uma chave de documento é um requisito de índice. É um campo único de cadeia de caracteres preenchido com base em um campo de dados de origem que contém valores exclusivos. Por exemplo, se você estiver indexando do Armazenamento de Blobs, o caminho de armazenamento de metadados geralmente será usado como a chave do documento porque identifica exclusivamente cada blob no contêiner.
Identifique os campos na sua fonte de dados que podem contribuir com conteúdo pesquisável no índice.
O conteúdo não vetorial pesquisável inclui cadeias de caracteres curtas ou longas que são consultadas usando o mecanismo de pesquisa de texto completo. Se o conteúdo for detalhado (frases pequenas ou partes maiores), experimente analisadores diferentes para ver como o texto é tokenizado.
O conteúdo vetorial pesquisável pode ser imagens ou texto (em qualquer idioma) que exista como uma representação matemática. Você pode usar tipos de dados estreitos ou compactação de vetores para diminuir o tamanho dos campos vetoriais.
Atributos definidos em campos, como
retrievable
oufilterable
, determinam tanto os comportamentos de pesquisa quanto a representação física do seu índice no serviço Pesquisa. Determinar como os campos devem ser especificados é um processo iterativo para muitos desenvolvedores. Para acelerar as iterações, comece com os dados de exemplo para que você possa remover e recriar com facilidade.Identifique quais campos de origem podem ser usados como filtros. Conteúdo numérico e campos de texto curto, especialmente aqueles com valores repetidos, são boas opções. Ao trabalhar com filtros, lembre:
Os filtros podem ser usados em consultas vetoriais e não vetoriais, mas o filtro em si é aplicado a campos alfanuméricos (não vetoriais) em seu índice.
Opcionalmente, os campos filtráveis podem ser usados faceted navigation.
Campos filtráveis são retornados em ordem arbitrária e não passam por pontuação de relevância, portanto, considere torná-los classificáveis também.
Para campos vetoriais, especifique uma configuração de busca em vetores e os algoritmos usados para criar caminhos de navegação e preencher o espaço de inserção. Para obter mais informações, confira Adicionar campos vetoriais.
Os campos vetoriais têm propriedades extras que os campos não vetoriais não têm, como os algoritmos a serem usados e a compactação de vetores.
Os campos vetoriais omitem atributos que não são úteis em dados vetoriais, como classificação, filtragem e facetamento.
Para campos não vetoriais, determine se deve usar o analisador padrão (
"analyzer": null
) ou um analisador diferente. Os analisadores são usados para tokenizar campos de texto durante a indexação e a execução da consulta.Nas cadeias de caracteres multilíngues, considere um analisador de linguagem.
Nas cadeias de caracteres hifenizadas ou caracteres especiais, considere analisadores especializados. Um exemplo é palavra-chave que trata todo o conteúdo de um campo como um único token. Esse comportamento é útil para os dados como CEP, IDs e alguns nomes de produto. Para obter mais informações, consulte Pesquisa de termo parcial e padrões com caracteres especiais.
Observação
A pesquisa de texto completo é realizada em termos tokenizados durante a indexação. Se suas consultas não retornarem os resultados esperados, teste a tokenização para verificar se a cadeia de caracteres que você está pesquisando realmente existe. Você pode experimentar diferentes analisadores em cadeias de caracteres para ver como os tokens são produzidos para vários analisadores.
Configurar definições de campo
A coleção de campos define a estrutura de um documento de pesquisa. Os campos têm um nome, atributos e um tipo de dados.
Definir um campo como pesquisável, filtrável, classificável ou facetável tem um efeito sobre o tamanho do índice e o desempenho da consulta. Não defina esses atributos em campos que não devem ser referenciados em expressões de consulta.
Se um campo não estiver definido como pesquisável, filtrável, classificável ou facetável, o campo não poderá ser referenciado em nenhuma expressão de consulta. Isso é desejável para campos que não são usados em consultas, mas são necessários nos resultados da pesquisa.
As APIs REST têm atribuição padrão com base nos tipos de dados, que também são usados pelos Assistentes de importação no portal do Azure. Os SDKs do Azure não têm padrões, mas têm subclasses de campo que incorporam propriedades e comportamentos como SearchableField para cadeias de caracteres e SimpleField para primitivos.
As atribuições de campo padrão para as APIs REST são resumidas na tabela a seguir.
Tipo de dados | Pesquisável | Recuperável | Filtrável | Com faceta | Classificável | Armazenado |
---|---|---|---|---|---|---|
Edm.String |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Collection(Edm.String) |
✅ | ✅ | ✅ | ✅ | ❌ | ✅ |
Edm.Boolean |
❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
Edm.Int32 , Edm.Int64 , Edm.Double |
❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
Edm.DateTimeOffset |
❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
Edm.GeographyPoint |
✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
Edm.ComplexType |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Collection(Edm.Single) e todos os outros tipos de campo de vetor |
✅ | ✅ ou ❌ | ❌ | ❌ | ❌ | ✅ |
Campos de cadeia de caracteres também podem ser associados opcionalmente a analisadores e mapas de sinônimos. Campos do tipo Edm.String
que são filtráveis, classificáveis ou facetáveis podem ter, no máximo, 32 quilobytes de tamanho. Isso ocorre porque os valores desses campos são tratados como um termo de pesquisa único e o comprimento máximo de um termo na Pesquisa de IA do Azure é de 32 quilobytes. Se você precisar armazenar mais texto do que isso em apenas um campo de cadeia de caracteres, deverá definir explicitamente filtrável, classificável e facetável para false
em sua definição de índice.
Os campos de vetor precisam ser associados a dimensões e perfis de vetor. O padrão recuperável será verdadeiro se você adicionar o campo de vetor usando o Assistente de importação e vetorização no portal, caso contrário, será falso se você usar a API REST.
Os atributos de campo são descritos na tabela a seguir.
Atributo | Descrição |
---|---|
name | Obrigatórios. Define o nome do campo, que precisa ser exclusivo na coleção de campos do índice ou campo pai. |
tipo | Obrigatória. Define o tipo de dados para o campo. Os campos podem ser simples ou complexos. Campos simples são de tipos primitivos, como Edm.String para texto ou Edm.Int32 para inteiros. Campos complexos podem ter sub-campos que são simples ou complexos. Isso permite que você modele objetos e matrizes de objetos, o que, por sua vez, permite carregar a maioria das estruturas de objetos JSON no índice. Confira Tipos de dados compatíveis para obter uma lista dos tipos compatíveis. |
chave | Obrigatória. Defina esse atributo como true para designar que os valores de um campo identifiquem documentos de maneira exclusiva no índice. Confira Chaves de documento neste artigo para obter detalhes. |
retrievable | Indica se o campo pode ser retornado em um resultado da pesquisa. Defina este atributo para false se você quiser usar um campo como um mecanismo de filtro, classificação ou pontuação, mas não quiser que o campo seja visível para o usuário final. Esse atributo precisa ser true para campos de chave e precisa ser null para campos complexos. Esse atributo pode ser alterado em campos existentes. A configuração recuperável para true não causa nenhum aumento nos requisitos de armazenamento de índice. O padrão é true para campos simples e null para campos complexos. |
searchable | Indica se o campo é pesquisável por texto completo e pode ser referenciado em consultas de pesquisa. Isso significa que ele será submetido a 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á normalizado nos tokens individuais “dia” e “ensolarado”. Isso habilita pesquisas de texto completo para esses termos. Campos do tipo Edm.String ou Collection(Edm.String) são pesquisáveis por padrão. Esse atributo precisa ser false para campos simples de outros tipos de dados não cadeia de caracteres e precisa ser null para campos complexos. Um campo pesquisável consome espaço extra em seu índice, pois a Pesquisa de IA do Azure processa o conteúdo desses campos e os organiza em estruturas de dados auxiliares para pesquisa com desempenho. Se você desejar economizar espaço no índice e não for necessário incluir um campo em pesquisas, defina searchable como false . Confira Como funciona a pesquisa de texto completo na Pesquisa de IA do Azure para obter detalhes. |
filterable | Indica se deve-se permitir que o campo seja referenciado em consultas $filter . Filtrável difere de pesquisável em como as cadeias de caracteres são tratadas. Campos do tipo Edm.String ou Collection(Edm.String) que são filtráveis não passam por análise lexical, portanto, as comparações são apenas para 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á. Esse atributo precisa ser null para campos complexos. O padrão é true para campos simples e null para campos complexos. Para reduzir o tamanho do índice, defina esse atributo para false em campos pelos quais você não estará filtrando. |
sortable | Indica se deve-se permitir que o campo seja referenciado em expressões $orderby . Por padrão, a Pesquisa de IA do Azure classifica os resultados pela pontuação, mas, em muitas experiências, os usuários desejam classificar por campos nos documentos. Um campo simples só poderá ser classificado se for de valor único (ele tem apenas um valor no escopo do documento pai). Campos de coleção simples não podem ser classificáveis, pois têm vários valores. Subcampos simples de coleções complexas também têm vários valores e, portanto, não podem ser classificáveis. Isso é verdade se é um campo pai imediato, ou um campo ancestral, que é a coleção complexa. Campos complexos não podem ser classificados e o atributo classificável precisa ser null para esses campos. O padrão para classificável é true para campos simples com valor único, false para campos simples com valores múltiplos e null para campos complexos. |
facetable | Indica se deve-se permitir que o campo seja referenciado em consultas de faceta. Geralmente usado em uma apresentação dos resultados de pesquisa que inclui a contagem de ocorrências por categoria (por exemplo, pesquisar câmeras digitais e ver as ocorrências por marca, por megapixels, por preço etc.). Esse atributo precisa ser null para campos complexos. Campos do tipo Edm.GeographyPoint ou Collection(Edm.GeographyPoint) não podem ser facetáveis. O padrão é true para todos os outros campos simples. Para reduzir o tamanho do índice, defina esse atributo como false em campos pelos quais você não estará facetando. |
analisador | Define o analisador lexical para tokenizar cadeias de caracteres durante operações de indexação e consulta. Os valores válidos para essa propriedade incluem analisadores de idioma, analisadores internos e analisadores personalizados. O padrão é standard.lucene . Esse atributo pode ser usado somente com campos pesquisáveis e não pode ser definido conjuntamente com searchAnalyzer ou indexAnalyzer. Depois que o analisador é escolhido e o campo é criado no índice, ele não pode ser alterado para o campo. Precisa ser null para campos complexos. |
searchAnalyzer | Defina essa propriedade junto com indexAnalyzer para especificar diferentes analisadores léxicos para indexação e consultas. Se você usar essa propriedade, defina o analisador null e verifique se indexAnalyzer está definido como um valor permitido. Os valores válidos para essa propriedade incluem analisadores internos e analisadores personalizados. Esse atributo só pode ser usado com campos pesquisáveis. O analisador de pesquisa pode ser atualizado em um campo existente, pois ele só é usado em tempo de consulta. Precisa ser null para campos complexos]. |
indexAnalyzer | Defina essa propriedade junto com searchAnalyzer para especificar diferentes analisadores léxicos para indexação e consultas. Se você usar essa propriedade, defina o analisador null e verifique se searchAnalyzer está definido como um valor permitido. Os valores válidos para essa propriedade incluem analisadores internos e analisadores personalizados. Esse atributo só pode ser usado com campos pesquisáveis. Depois que o analisador de índice for escolhido, ele não poderá ser alterado para o campo. Precisa ser null para campos complexos. |
synonymMaps | Uma lista dos nomes dos mapas de sinônimos a serem associados a esse campo. Esse atributo só pode ser usado com campos pesquisáveis. Atualmente, há suporte para apenas um mapa de sinônimos por campo. Atribuir um mapa de sinônimos a um campo garante que os termos de consulta direcionados a esse campo sejam expandidos em tempo de consulta usando as regras no mapa de sinônimos. Esse atributo pode ser alterado em campos existentes. Precisa ser null ou uma coleção vazia para campos complexos. |
fields | Uma lista de subcampos se este for um campo de tipo Edm.ComplexType ou Collection(Edm.ComplexType) . Precisa ser null ou vazio para campos simples. Confira Como modelar tipos de dados complexos na Pesquisa de IA do Azure para obter mais informações sobre como e quando usar subcampos. |
Crie um índice
Quando você estiver pronto para criar o índice, use um cliente de pesquisa que possa enviar a solicitação. Você pode usar o portal do Azure ou as APIs REST para desenvolvimento inicial e testes de prova de conceito; caso contrário, é comum usar SDKs do Azure.
Durante o desenvolvimento, planeje recompilações frequentes. Como as estruturas físicas são criadas no serviço, é necessário remover e recriar índices para muitas modificações. Considere trabalhar com um subconjunto de seus dados para acelerar as recompilações.
O design de índice por meio do portal impõe requisitos e regras de esquema para tipos de dados específicos, como a não permissão de recursos de pesquisa de texto inteiro em campos numéricos.
Entre no portal do Azure.
Verifique o espaço. Os serviços de pesquisa estão sujeitos a número máximo de índices, variando de acordo com o nível de serviço. Certifique-se de ter espaço para um segundo índice.
Na página Visão geral do serviço de pesquisa, escolha uma das opções para criar um índice de pesquisa:
- Adicionar índice, um editor inserido para especificar um esquema de índice
- Assistentes de importação
O assistente é um fluxo de trabalho de ponta a ponta que cria um indexador, uma fonte de dados e um índice concluído. Ele também carrega os dados. Se você não precisa de tantas funções, use Adicionar Índice.
A captura de tela a seguir destaca onde Adicionar Índice, Importar dados e Importar e vetorizar dados aparecem na barra de comandos.
Depois que um índice é criado, você pode encontrá-lo novamente na página Índices do painel de navegação esquerdo.
Dica
Depois de criar um índice no portal, você pode copiar a representação JSON e adicioná-la ao código do aplicativo.
Definir corsOptions
para consultas entre origens
Esquemas de índice incluem uma seção para definir corsOptions
. Por padrão, o JavaScript do lado do cliente não pode chamar as APIs porque os navegadores impedem todas as solicitações entre origens. Para permitir consultas entre origens pelo índice, habilite o Compartilhamento de Recursos entre Origens (CORS) definindo o atributo corsOptions. Por motivos de segurança, apenas as APIs de consulta dão suporte ao CORS.
"corsOptions": {
"allowedOrigins": [
"*"
],
"maxAgeInSeconds": 300
As seguintes propriedades podem ser definidas para o CORS:
allowedOrigins (obrigatório): essa é uma lista de origens às quais será concedido acesso ao seu índice. O código JavaScript fornecido dessas origens tem permissão para consultar seu índice (supondo que o chamador forneça uma chave válida ou tenha permissões). Cada origem é tipicamente da forma,
protocol://<fully-qualified-domain-name>:<port>
embora<port>
seja frequentemente omitida. Para obter mais informações, consulte compartilhamento de recursos entre origens (Wikipédia).Se você quiser permitir acesso a todas as origens, inclua
*
como um único item na matriz allowedOrigins. Essa não é uma prática recomendada para os serviços de pesquisa de produção, mas geralmente é útil para desenvolvimento e depuração.maxAgeInSeconds (opcional): navegadores usam esse valor para determinar a duração (em segundos) para respostas de simulação de CORS de cache. Esse deve ser um inteiro não negativo. Um período de cache mais longo oferece melhor desempenho, mas estende a quantidade de tempo que uma política CORS precisa para entrar em vigor. Se esse valor não for definido, será usada uma duração padrão de cinco minutos.
Atualizações permitidas em índices existentes
Criar Índice cria as estruturas de dados física (arquivos e índices invertidos) no serviço de pesquisa. Depois que o índice é criado, sua capacidade de efetuar alterações usando Criar ou Atualizar Índice depende do fato de suas modificações invalidarem essas estruturas físicas. A maioria dos atributos de campo não pode ser alterada depois que o campo é criado no índice.
Para minimizar a variação no código do aplicativo, você pode criar um alias de índice que serve como uma referência estável para o índice de pesquisa. Em vez de atualizar o seu código com nomes de índice, você pode atualizar um alias de índice para apontar para versões de índice mais recentes.
Para minimizar a rotatividade no processo de design, a tabela a seguir descreve quais elementos são fixos e flexíveis no esquema. Alterar um elemento fixo requer uma recompilação do índice, enquanto elementos flexíveis podem ser alterados a qualquer momento sem afetar a implementação física. Para obter mais informações, confira Atualizar ou recompilar um índice.
Element | É possível atualizar? |
---|---|
Nome | Não |
Chave | Não |
Nomes e tipos de campo | Não |
Atributos de campo (pesquisáveis, filtráveis, facetáveis, classificáveis) | Não |
Atributo de campo (recuperável) | Sim |
Armazenado (aplica-se a vetores) | Não |
Analisador | Você pode adicionar e modificar analisadores personalizados no índice. Em relação às atribuições do analisador nos campos da cadeia de caracteres, você só pode modificar searchAnalyzer . Todas as outras atribuições e modificações exigem uma recompilação. |
Perfis de pontuação | Sim |
Sugestores | Não |
CORS (compartilhamento de recursos entre origens) | Yes |
Criptografia | Sim |
Mapas de sinônimos | Sim |
Configuração semântica | Sim |
Próximas etapas
Use os seguintes links para saber mais sobre recursos especializados que podem ser adicionados a um índice:
- Adicionar campos de vetor e perfis de vetor
- Adicionar perfis de pontuação
- Adicionar classificação semântica
- Adicionar sugestores
- Adicionar mapas de sinônimos
- Adicionar analisadores
- Adicionar criptografia
Use estes links para carregar ou atualizar um índice: