Armazenamento vetorial na Pesquisa de IA do Azure

O Azure AI Search fornece armazenamento vetorial e configurações para pesquisa vetorial e pesquisa híbrida. O suporte é implementado no nível do campo, o que significa que você pode combinar campos vetoriais e não vetoriais no mesmo corpus de pesquisa.

Os vetores são armazenados em um índice de pesquisa. Use a Create Index REST API ou um método equivalente do SDK do Azure para criar o repositório de vetores.

As considerações para o armazenamento vetorial incluem os seguintes pontos:

• Projete um esquema para se adequar ao seu caso de uso com base no padrão de recuperação de vetor pretendido.
• Estime o tamanho do índice e verifique a capacidade do serviço de pesquisa.
• Gerenciar um repositório de vetores
• Proteger um repositório vetorial

Padrões de recuperação de vetores

No Azure AI Search, há dois padrões para trabalhar com resultados de pesquisa.

• Pesquisa generativa. Os modelos de linguagem formulam uma resposta à consulta do usuário usando dados do Azure AI Search. Esse padrão inclui uma camada de orquestração para coordenar prompts e manter o contexto. Nesse padrão, os resultados da pesquisa são alimentados em fluxos de prompt, recebidos por modelos de bate-papo como GPT e Text-Davinci. Essa abordagem é baseada na arquitetura de geração aumentada de recuperação (RAG), onde o índice de pesquisa fornece os dados de aterramento.

• 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 vetorial, formula uma resposta e você processa esses resultados em um aplicativo cliente. Na Pesquisa de IA do Azure, os resultados são retornados em um conjunto de linhas niveladas e você pode escolher quais campos incluir os resultados da pesquisa. Como não há um modelo de bate-papo, espera-se que você preencha o repositório de vetores (índice de pesquisa) com conteúdo não vetorial legível por humanos em sua resposta. Embora o mecanismo de pesquisa corresponda em vetores, você deve usar valores não vetoriais para preencher os resultados da pesquisa. As consultas vetoriais e as consultas híbridas abrangem os tipos de solicitações de consulta que você pode formular para cenários de pesquisa clássicos.

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

Esquema de um repositório vetorial

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

Configuração básica do campo vetorial

Os campos vetoriais são distinguidos por seu tipo de dados e propriedades específicas do vetor. Veja a aparência de um campo vetorial 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 vetoriais são do tipo Collection(Edm.Single).

Os campos vetoriais devem ser pesquisáveis e recuperáveis, mas não podem ser filtráveis, faciáveis ou classificáveis, nem ter analisadores, normalizadores ou atribuições de mapas de sinônimos.

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

Os campos vetoriais são indexados usando algoritmos indicados por um perfil de pesquisa vetorial, que é definido em outra parte do índice e, portanto, não é mostrado no exemplo. Para obter mais informações, consulte Configuração de pesquisa vetorial.

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

Os armazenamentos vetoriais exigem mais campos além dos campos vetoriais. Por exemplo, um campo-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 "content" campo, fornecem o equivalente legível por humanos do "content_vector" campo. Se você estiver usando modelos de linguagem exclusivamente para formulação de respostas, poderá omitir campos de conteúdo não vetoriais, mas as soluções que enviam resultados de 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. Não é possível filtrar diretamente um campo vetorial, mas é possível definir os modos pré-filtro ou pós-filtro para filtrar antes ou depois da execução da consulta vetorial.

Esquema gerado pelo assistente Importar e vetorizar dados

Recomendamos o assistente Importar e vetorizar dados para avaliação e teste de prova de conceito. O assistente gera o esquema de exemplo nesta seção.

A viés desse esquema é que os documentos de pesquisa são construídos em torno de blocos de dados. Se um modelo de linguagem formular a resposta, como é típico para aplicativos RAG, você deseja um esquema projetado em blocos de dados.

A fragmentação de dados é necessária para permanecer dentro dos limites de entrada dos modelos de linguagem, mas também melhora a precisão na pesquisa de semelhança quando as consultas podem ser comparadas com blocos menores de conteúdo extraído de vários documentos pai. Finalmente, se você estiver usando a classificação semântica, o classificador semântico também tem limites de token, que são mais facilmente atendidos se o agrupamento de dados fizer parte da sua abordagem.

No exemplo a seguir, para cada documento de pesquisa, há um ID de bloco, bloco, título e campo vetorial. O chunkID e o ID pai são preenchidos pelo assistente, usando a codificação base 64 de metadados de blob (caminho). Chunk e title são derivados do conteúdo do blob e do nome do blob. Apenas o campo vetorial é totalmente gerado. É a versão vetorizada do campo chunk. As incorporações são geradas chamando um modelo de incorporaçã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 RAG e aplicativos no estilo de bate-papo

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

Campos do índice de chat que suportam a experiência de pesquisa generativa:

"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 suporta orquestração e histórico de bate-papo:

"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 Search Explorer para o índice de conversas. A pontuação da pesquisa é de 1,00 porque a pesquisa não foi qualificada. Observe os campos que existem para dar suporte à orquestração e aos fluxos de prompt. Um ID de conversação identifica um chat específico. "type" Indica se o conteúdo é do usuário ou do assistente. As datas são usadas para envelhecer os chats da história.

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

A dimensão e o conteúdo de um índice são determinados por:

• Quantidade e composição dos seus documentos
• Atributos em campos individuais. Por exemplo, é necessário mais armazenamento para campos filtráveis.
• Configuração de índice, incluindo configuração de vetor que especifica como as estruturas de navegação internas são criadas com base na escolha de HNSW ou KNN exaustivo para pesquisa de similaridade.

O Azure AI Search impõe limites ao armazenamento vetorial, 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 é rastreado 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. Este serviço em particular tem 24 pequenos índices, com um campo vetorial em média, cada campo consistindo de 1536 incorporações. O segundo bloco mostra a cota e o uso de índices vetoriais. Um índice vetorial é uma estrutura de dados interna criada para cada campo vetorial. Como tal, o armazenamento para índices vetoriais é sempre uma fração do armazenamento usado pelo índice em geral. Outros campos não vetoriais e estruturas de dados consomem o resto.

Os limites e estimativas do índice vetorial são abordados em outro artigo, mas dois pontos a enfatizar antecipadamente é que o armazenamento máximo varia de acordo com a camada de serviço e também com quando o serviço de pesquisa foi criado. Os serviços de mesma camada mais recentes têm significativamente mais capacidade para índices vetoriais. Por estas razões, tome as seguintes medidas:

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

• Escolha um nível escalável se você antecipar flutuações nos requisitos de armazenamento vetorial. A camada Básica é fixada em uma partição em serviços de pesquisa mais antigos. Considere o Padrão 1 (S1) e superior para obter mais flexibilidade e desempenho mais rápido, ou crie um novo serviço de pesquisa que use limites mais altos e mais partições em cada camada zero.

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

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

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

Todas as solicitações de indexação vetorial 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. Verifique se você tem permissões ou uma chave de acesso à API. A menos que esteja consultando um índice existente, você precisa 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 visualizar e gerir o serviço de pesquisa, incluindo a concessão de acesso a outras pessoas através da página Controlo de acesso (IAM).

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

   • Guia de início rápido: REST
   • Amostras vetoriais

Acesso seguro a dados vetoriais

O Azure AI Search 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. A gama completa de recursos de segurança corporativa é descrita em Segurança na Pesquisa de IA do Azure.

Gerenciar repositórios de vetores

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

• Ativar registo de diagnóstico
• Configurar alertas
• Analisar o desempenho da consulta e do índice

Consulte também

• Criar um repositório de vetores usando APIs REST (Guia de início rápido)
• Criar um repositório de vetores
• Consultar um índice vetorial