Armazenamento de vetores na Pesquisa de IA do Azure

  • Artigo

A Pesquisa de IA do Azure fornece armazenamento de vetor e configurações para busca em vetores e pesquisas híbridas. O suporte é implementado no nível do campo, o que significa que você pode combinar campos vetorial e não vetorial no mesmo corpus de pesquisa.

Os vetores são armazenados em um índice de pesquisa. Use a Criar API REST de índice ou um método equivalente do SDK do Azure para criar o armazenamento de vetores.

As considerações sobre o armazenamento de vetores incluem os seguintes pontos:

  • Criar um esquema para ajustar seu caso de uso com base no padrão de recuperação de vetor pretendido.
  • Estimar o tamanho do índice e verificar a capacidade do serviço de pesquisa.
  • Gerenciar um repositório de vetores
  • Proteger um repositório de vetores

Padrões de recuperação de vetor

Na Pesquisa de IA do Azure, existem dois padrões para trabalhar com resultados de pesquisa.

  • Pesquisa generativa. Os modelos de linguagem formulam uma resposta à consulta do usuário usando dados da Pesquisa de IA do Azure. Esse padrão inclui uma camada de orquestração para coordenar solicitações e manter o contexto. Nesse padrão, os resultados da pesquisa são inseridos em prompt flows e recebidos por modelos de chat como GPT e Text-Davinci. Essa abordagem é baseada na arquitetura de RAG (Geração Aumentada de Recuperação), na qual o índice de pesquisa fornece os dados de fundamentação.

  • Pesquisa clássica usando uma barra de pesquisa, cadeia de caracteres de entrada de consulta e resultados renderizados. O mecanismo de pesquisa aceita e executa a consulta de vetor, formula uma resposta e você renderiza esses resultados em um aplicativo cliente. Na Pesquisa de IA do Azure, os resultados são retornados em um conjunto de linhas achatadas e você poderá escolher em quais campos incluir os resultados da pesquisa. Como não há modelo de chat, espera-se que você preencha o armazenamento de vetores (índice de pesquisa) com conteúdo não vetorial legível em sua resposta. Embora o mecanismo de pesquisa corresponda em vetores, use valores não vetoriais para preencher os resultados da pesquisa. Consultas vetoriais e consultas híbridas, abrangem os tipos de solicitações de consulta que você poderá formular para cenários de pesquisa clássicos.

Seu esquema de índice deve refletir o caso de uso primário. A seção a seguir realça as diferenças na composição de campo para soluções compiladas para IA generativa ou pesquisa clássica.

Esquema de um repositório de vetores

Um esquema de índice para um repositório de vetores necessita de um nome, um campo de chave (cadeia de caracteres), um ou mais campos vetoriais e uma configuração de vetor. Campos não vetoriais são recomendados para consultas híbridas ou para retornar conteúdo de texto humanamente legível que não precisa passar por um modelo de linguagem. Para obter instruções sobre a configuração de vetor, consulte Criar um armazenamento de vetores.

Configuração básica do campo de vetor

Os campos de vetor são diferenciados por seu tipo de dados e propriedades específicas de vetor. Veja a aparência de um campo de vetor em uma coleção de campos:

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

Os campos de vetor são do tipo Collection(Edm.Single).

Os campos de vetor devem ser pesquisáveis e recuperáveis, mas não podem ser filtrados, facetáveis ou classificáveis ou ter analisadores, normalizadores ou atribuições de mapa de sinônimos.

Os campos de vetor devem ter dimensions definidas para o número de incorporações geradas pelo modelo de incorporação. Por exemplo, text-embedding-ada-002 gera 1.536 inserções para cada parte do texto.

Os campos de vetor são indexados usando algoritmos indicados por um perfil de pesquisa de vetor, que é definido em outro lugar no índice e, portanto, não é mostrado no exemplo. Para obter mais informações, consulte a configuração de pesquisa de vetor.

Coleção de campos para cargas de trabalho de vetor básicas

Os repositórios de vetores exigem mais campos além de campos de vetor. Por exemplo, um campo de chave ("id" neste exemplo) é um requisito de índice.

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

Outros campos, como o campo "content", fornecem o equivalente legível humano do campo "content_vector". Caso esteja usando modelos de linguagem exclusivamente para formulação de resposta, poderá omitir campos de conteúdo não vetorial, mas soluções que efetuam push dos resultados da pesquisa diretamente para aplicativos cliente, devem ter conteúdo não vetorial.

Os campos de metadados são úteis para filtros, especialmente se os metadados incluírem informações de origem sobre o documento de origem. Você não pode filtrar em um campo de vetor diretamente, mas pode definir modos de pré-filtro ou pós-filtro para filtrar antes ou depois da execução da consulta do vetor.

Esquema gerado pelo assistente de importação e vetorização de dados

É recomendável usar o Assistente de importação e vetorização de dados para avaliação e teste de prova de conceito. O assistente gera o esquema de exemplo nesta seção.

O desvio desse esquema é que os documentos de pesquisa são criados com base em partes de dados. Se um modelo de linguagem formula a resposta, como é comum para aplicativos de RAG, você espera um esquema criado com base em partes de dados.

A divisão de dados em partes é necessária para permanecer dentro dos limites de entrada dos modelos de linguagem, mas isso também melhora a precisão na pesquisa de similaridade, pois as consultas podem corresponder a partes menores de conteúdo extraída de vários documentos pai. Por fim, se você estiver usando a classificação semântica, o classificador semântico também terá limites de token, que serão atendidos com mais facilidade se a divisão de dados em partes é uma das suas abordagens.

No exemplo a seguir, para cada documento de pesquisa, há uma ID de parte, parte, título e campo vetorial. A chunkID e a ID pai são preenchidas pelo assistente, usando a codificação base 64 de metadados de blob (caminho). Parte e título são derivados do conteúdo de blob e do nome de blob. Somente o campo vetorial é totalmente gerado. É a versão vetorizada do campo de partes. As inserções são geradas chamando um modelo de inserção do Azure OpenAI que você fornece.

"name": "example-index-from-import-wizard",
"fields": [
  {"name": "chunk_id",  "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

Esquema para aplicativos no estilo RAG e chat

Se você estiver projetando armazenamento para pesquisa gerativa, poderá criar índices separados para o conteúdo estático indexado e vetorizado e um segundo índice para conversas que podem ser usadas em prompt flows. Os índices a seguir são criados a partir do acelerador chat-with-your-data-solution-accelerator.

Captura de tela dos índices criados pelo acelerador.

Campos do índice de chat que dão suporte à experiência de pesquisa gerativa:

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

Campos do índice de conversas que dão suporte à orquestração e ao histórico de chat:

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

Aqui está uma captura de tela mostrando os resultados da pesquisa no Gerenciador de Pesquisa o índice de conversas. A pontuação de pesquisa é 1,00 porque a pesquisa não foi qualificada. Observe os campos que existem para dar suporte a orquestração e prompt flow. Uma ID de conversa identifica um chat específico. "type" indica se o conteúdo é do usuário ou do assistente. As datas são usadas para tornar os chats do histórico obsoletos.

Captura de tela do Explorador de Pesquisa com resultados de um índice projetado para aplicativos RAG.

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 o esquema, carregar e consultar o conteúdo, monitorar o tamanho e gerenciar a capacidade, mas os clusters (índices de vetor e invertidos, e outros arquivos e pastas) são gerenciados internamente pela Microsoft.

O tamanho e a substância de um índice são determinados:

  • Pela quantidade e composição de seus documentos
  • Pelos atributos em campos individuais. Por exemplo, mais armazenamento é necessário para campos filtrados.
  • Configuração de índice, incluindo a configuração de vetor que especifica como as estruturas de navegação internas são criadas com base em se você escolhe HNSW ou KNN exaustivo para pesquisa de similaridade.

A Pesquisa de IA do Azure impõe limites ao armazenamento de vetores, o que ajuda a manter um sistema equilibrado e estável para todas as cargas de trabalho. Para ajudá-lo a permanecer abaixo dos limites, o uso de vetores é acompanhado e relatado separadamente no portal do Azure e programaticamente por meio de estatísticas de serviço e índice.

A captura de tela a seguir mostra um serviço S1 configurado com uma partição e uma réplica. Esse serviço específico tem 24 índices pequenos, com um campo de vetor em média, cada campo sendo composto por 1536 inserções. O segundo bloco mostra a cota e o uso para índices de vetor. Um índice de vetor é uma estrutura de dados interna criada para cada campo de vetor. Dessa forma, o armazenamento para índices de vetor é sempre uma fração do armazenamento usado pelo índice geral. Outros campos não vetoriais e estruturas de dados consomem o restante.

Captura de tela de blocos de uso mostrando armazenamento, índice vetorial e contagem de índices.

Os limites de índice vetor e as estimativas são abordados em outro artigo, mas dois pontos a serem enfatizados antecipadamente é que o armazenamento máximo varia de acordo com a camada de serviço e também quando o serviço de pesquisa foi criado. Os serviços mais recentes da mesma camada têm significativamente mais capacidade para índices de vetor. Por esses motivos, execute as seguintes ações:

  • Verifique a data de implantação do serviço de pesquisa. Se tiver sido criado antes de 3 de abril de 2024, considere criar um serviço de pesquisa para maior capacidade.

  • Escolha uma camada escalonável se você prever flutuações nos requisitos de armazenamento de vetor. A camada Básico é fixada em uma partição nos serviços de pesquisa mais antigos. Considere Standard 1 (S1) e superior para obter mais flexibilidade e desempenho mais rápido ou crie um serviço de pesquisa que use limites mais altos e mais partições em cada camada anulável.

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

Esta seção apresenta operações de tempo de execução de vetor, incluindo a conexão e a proteção de um único índice.

Observação

Ao gerenciar um índice, esteja ciente de que não há suporte para portal ou API para a migração ou cópia de um índice. Em vez disso, os clientes normalmente apontam a solução de implantação de aplicativo para um serviço de pesquisa diferente (se estiver usando o mesmo nome de índice) ou revisam o nome para criar uma cópia no serviço de pesquisa atual e a criam.

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 é 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 do ponto de extremidade

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

Ponto de extremidade 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. São necessários direitos de administrador para essas operações, disponíveis por meio de chaves de API do administrador ou de uma função 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 de uma função de leitor de dados. Para a atualização de dados, são necessários direitos de administrador.

  1. Garanta ter permissões ou uma chave de acesso à API. A menos que você esteja consultando um índice existente, você precisará de direitos de administrador ou uma atribuição de função de colaborador para gerenciar e exibir conteúdo em um serviço de pesquisa.

  2. Comece com o portal do Azure. A pessoa que criou o serviço de pesquisa pode exibir e gerenciar o serviço de pesquisa, incluindo a concessão de acesso a outras pessoas por meio da página Controle de acesso (IAM) .

  3. Passe para outros clientes para acesso programático. Recomendamos os guias de início rápido e amostras para as primeiras etapas:

Proteger o acesso aos dados de vetor

A Pesquisa de IA do Azure implementa criptografia de dados, conexões privadas para cenários sem Internet e atribuições de função para acesso seguro por meio do Microsoft Entra ID. Toda a gama de recursos de segurança da empresa é descrita na Segurança na Pesquisa de IA do Azure.

Gerenciar repositórios de vetores

O Azure fornece uma plataforma de monitoramento que inclui log e alertas de diagnósticos. Sugerimos as seguintes práticas recomendadas:

Confira também