Implementar a recuperação de duas torres para a geração de candidatos em grande escala

Last reviewed 2025-01-16 UTC

Este documento apresenta uma arquitetura de referência que mostra como implementar um fluxo de trabalho completo de duas torres de geração de candidatos com a Vertex AI. O modelo de duas torres é uma técnica de recuperação poderosa para casos de uso de personalização, porque ele aprende a semelhança semântica entre duas entidades diferentes, como consultas da Web e itens candidatos.

Este documento é destinado a profissionais técnicos, como cientistas de dados e engenheiros de machine learning, que estão desenvolvendo aplicativos de recomendação em grande escala com requisitos de exibição de baixa latência. Para mais informações sobre as técnicas de modelagem, a definição do problema e a preparação de dados para criar um modelo de duas torres, consulte Como dimensionar a recuperação profunda com os recomendadores do TensorFlow e a Pesquisa Vetorial.

Arquitetura

O diagrama a seguir mostra uma arquitetura para treinar um modelo de duas torres e implantar cada torre separadamente para diferentes tarefas de implantação e exibição:

Uma arquitetura para treinar um modelo de duas torres e implantar cada torre separadamente.

A arquitetura no diagrama inclui os seguintes componentes:

  • Dados de treinamento: os arquivos de treinamento são armazenados no Cloud Storage.
  • Treinamento de duas torres: o modelo combinado de duas torres é treinado off-line usando o serviço de treinamento da Vertex AI. Cada torre é salva separadamente e usada para tarefas diferentes.
  • Torres de candidatos e de consulta registradas: depois que as torres são treinadas, cada uma delas é enviada separadamente para o Vertex AI Model Registry.
  • Torre de consulta implantada: a torre de consulta registrada é implantada em um endpoint on-line da Vertex AI.
  • Inserções de previsão em lote: a torre de candidatos registrada é usada em um job de previsão em lote para pré-calcular as representações de inserção de todos os itens de candidato disponíveis.
  • Embeddings JSON: os embeddings previstos são salvos em um arquivo JSON no Cloud Storage.
  • Índice ANN: o Vertex AI Vector Search é usado para criar um índice de exibição configurado para a pesquisa de vizinho mais próximo aproximado (ANN, na sigla em inglês).
  • Índice implantado: o índice ANN é implantado em um endpoint da Pesquisa de vetor da Vertex AI.

Produtos usados

Esta arquitetura de referência usa os seguintes Google Cloud produtos:

  • Treinamento da Vertex AI: um serviço de treinamento totalmente gerenciado que permite operar o treinamento de modelos em grande escala.
  • Pesquisa vetorial: um serviço de correspondência de similaridade vetorial que permite armazenar, indexar e pesquisar dados semanticamente semelhantes ou relacionados.
  • Vertex AI Model Registry: um repositório central em que é possível gerenciar o ciclo de vida dos modelos de ML.
  • Cloud Storage: um armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e de fora do Google Cloude são replicados entre locais para redundância.

Caso de uso

Para atender aos requisitos de veiculação de baixa latência, os recomendadores em grande escala geralmente são implantados na produção como sistemas de dois estágios ou, às vezes, como sistemas de vários estágios. O objetivo da primeira etapa, a geração de candidatos, é analisar uma grande coleção de itens candidatos e extrair um subconjunto relevante de centenas de itens para tarefas de filtragem e classificação posteriores. Para otimizar essa tarefa de recuperação, considere estes dois objetivos principais:

  1. Durante o treinamento do modelo, aprenda a melhor representação do problema ou tarefa a ser resolvida e compile essa representação em embeddings <query, candidate>.
  2. Durante a disponibilização do modelo, recupere itens relevantes com rapidez suficiente para atender aos requisitos de latência.

O diagrama a seguir mostra os componentes conceituais de um recomendador em dois estágios:

Os componentes conceituais de um recomendador de duas etapas.

No diagrama, a geração de candidatos filtra milhões de itens candidatos. A classificação filtra as centenas de itens candidatos resultantes para retornar dezenas de itens recomendados.

A arquitetura de referência neste documento treina um modelo de recuperação baseado em duas torres. Na arquitetura, cada torre é uma rede neural que processa a consulta ou os recursos do item candidato e produz uma representação de incorporação desses recursos. Cada torre é implantada separadamente, porque cada uma será usada para tarefas diferentes na produção:

  • Torre de candidatos: é usada para pré-calcular as embeddings de todos os itens candidatos. Os embeddings pré-calculados são implantados em um endpoint de índice da Pesquisa vetorial da Vertex AI otimizado para recuperação de baixa latência.
  • Torre implantada: durante a veiculação on-line, a torre de consulta implantada converte consultas brutas do usuário em representações de incorporação. As representações de embedding são usadas para procurar embeddings de itens semelhantes no índice implantado.

As arquiteturas de duas torres são ideais para muitas tarefas de recuperação porque capturam a relação semântica das entidades de consulta e candidatas, e as mapeiam para um espaço de inserção compartilhado. Quando as entidades são mapeadas para um espaço de embedding compartilhado, as entidades semanticamente semelhantes são agrupadas mais próximas. Portanto, se você calcular os embeddings de vetor de uma determinada consulta, poderá pesquisar no espaço de embedding os itens candidatos mais próximos (mais semelhantes). O principal benefício dessa arquitetura é a capacidade de separar a inferência de consultas e representações de candidatos. As vantagens desse desacoplamento são principalmente duas:

  • É possível veicular novos itens sem treinar novamente um novo vocabulário de itens. Ao fornecer qualquer conjunto de recursos de item para a torre de itens candidatos, você pode calcular as embeddings de itens para qualquer conjunto de candidatos, mesmo aqueles que não são vistos durante o treinamento. A realização dessa computação ajuda a resolver o problema de inicialização a frio.
    • A torre de candidatos pode oferecer suporte a um conjunto arbitrário de itens candidatos, incluindo itens que ainda não interagiram com o sistema de recomendação. Esse suporte é possível porque as arquiteturas de duas torres processam recursos de metadados e conteúdo rico sobre cada par de <query, candidate>. Esse tipo de processamento permite que o sistema descreva um item desconhecido em termos de itens que ele conhece.
  • É possível otimizar a inferência de recuperação com a pré-computação de todas as embeddings de itens candidatos. Essas representações internas pré-computadas podem ser indexadas e implantadas em uma infraestrutura de veiculação otimizada para recuperação de baixa latência.
    • O coaprendizado das torres permite descrever itens em termos de consultas e vice-versa. Se você tiver uma metade de um par, como uma consulta, e precisar procurar o outro item correspondente, é possível pré-calcular metade da equação com antecedência. A pré-computação permite que você tome o restante da decisão o mais rápido possível.

Considerações sobre o design

Esta seção fornece orientações para ajudar você a desenvolver uma arquitetura de geração de candidatos no Google Cloud que atenda às suas necessidades de segurança e desempenho. As orientações desta seção não são completas. Dependendo dos requisitos específicos, você pode considerar outros fatores de design e compensações.

Segurança

A Pesquisa de vetor do Vertex AI oferece suporte a implantações de endpoints públicos e de nuvem privada virtual (VPC). Se você quiser usar uma rede VPC, siga as instruções em Configurar uma conexão de peering de rede VPC. Se o índice de pesquisa vetorial for implantado em um perímetro da VPC, os usuários precisarão acessar os recursos associados na mesma rede VPC. Por exemplo, se você estiver desenvolvendo no Vertex AI Workbench, será necessário criar a instância do workbench na mesma rede VPC do endpoint de índice implantado. Da mesma forma, qualquer pipeline que precise criar um endpoint ou implantar um índice em um endpoint precisa ser executado na mesma rede VPC.

Otimização de desempenho

Esta seção descreve os fatores a serem considerados ao usar essa arquitetura de referência para projetar uma topologia no Google Cloud que atenda aos requisitos de desempenho das suas cargas de trabalho.

Jobs de treinamento de perfil

Para otimizar pipelines de entrada de dados e o gráfico de treinamento geral, recomendamos criar perfis de desempenho de treinamento com o Cloud Profiler. O criador de perfil é uma implementação gerenciada do TensorBoard Profiler de código aberto.

Ao transmitir o argumento –profiler no job de treinamento, você ativa o callback do TensorFlow para criar um perfil de um número definido de lotes para cada época. O perfil captura rastros da CPU do host e da GPU ou do hardware TPU do dispositivo. Os rastros fornecem informações sobre o consumo de recursos do job de treinamento. Para evitar erros de memória insuficiente, recomendamos que você comece com uma duração de perfil entre 2 e 10 etapas de treinamento e aumente conforme necessário.

Para saber como usar o Profiler com o Vertex AI Training e o Vertex AI TensorBoard, consulte Criar perfil de desempenho de treinamento de modelo. Para conferir as práticas recomendadas de depuração, consulte Otimizar o desempenho da GPU. Para saber como otimizar o desempenho, consulte Otimizar o desempenho do TensorFlow usando o Profiler.

Aproveitar totalmente os aceleradores

Ao anexar aceleradores de treinamento, como GPUs NVIDIA ou TPUs do Cloud, é importante mantê-los totalmente utilizados. A utilização completa de aceleradores de treinamento é uma prática recomendada para o gerenciamento de custos, porque eles são o componente mais caro da arquitetura. A utilização completa de aceleradores de treinamento também é uma prática recomendada para a eficiência do trabalho, porque a ausência de tempo ocioso resulta em menos consumo de recursos.

Para manter um acelerador totalmente utilizado, normalmente você executa algumas iterações para encontrar o gargalo, otimizar o gargalo e repetir essas etapas até que a utilização do dispositivo do acelerador seja aceitável. Como muitos dos conjuntos de dados desse caso de uso são grandes demais para caber na memória, os gargalos são normalmente encontrados entre o armazenamento, as VMs de host e o acelerador.

O diagrama a seguir mostra os estágios conceituais de um pipeline de entrada de treinamento de ML:

Os estágios conceituais de um pipeline de entrada de treinamento de ML.

No diagrama, os dados são lidos do armazenamento e pré-processados. Depois que os dados são pré-processados, eles são enviados para o dispositivo. Para otimizar o desempenho, comece determinando se o desempenho geral é limitado pela CPU do host ou pelo dispositivo de aceleração (GPU ou TPU). O dispositivo é responsável por acelerar o ciclo de treinamento, enquanto o host é responsável por fornecer dados de treinamento ao dispositivo e receber resultados dele. As seções a seguir descrevem como resolver gargalos melhorando a performance do pipeline de entrada e do dispositivo.

Melhorar a performance do pipeline de entrada
  • Ler dados do armazenamento: para melhorar a leitura de dados, tente armazenar em cache, pré-buscar, padrões de acesso sequencial e E/S paralela.
  • Pré-processamento de dados: para melhorar o pré-processamento de dados, configure o processamento paralelo para extração e transformação de dados e ajuste a transformação interleave no pipeline de entrada de dados.
  • Enviar dados para o dispositivo: para reduzir o tempo geral do job, transfira dados do host para vários dispositivos em paralelo.
Melhorar o desempenho do dispositivo
  • Aumento do tamanho do minilote. Os minilotes são o número de amostras de treinamento usadas por cada dispositivo em uma iteração de um ciclo de treinamento. Ao aumentar o tamanho do minilote, você aumenta o paralelismo entre as operações e melhora a reutilização de dados. No entanto, o minilote precisa caber na memória com o restante do programa de treinamento. Se você aumentar muito o tamanho do minilote, poderá ocorrer erros de falta de memória e divergência do modelo.
  • Vectorize funções definidas pelo usuário. Normalmente, as transformações de dados podem ser expressas como uma função definida pelo usuário que descreve como transformar cada elemento de um conjunto de dados de entrada. Para vetorizar essa função, aplique a operação de transformação em um lote de entradas de uma só vez, em vez de transformar um elemento por vez. Qualquer função definida pelo usuário tem uma sobrecarga relacionada à programação e execução. Ao transformar um lote de entradas, você incorre na sobrecarga uma vez por lote, em vez de uma vez por elemento do conjunto de dados.
Escalone verticalmente antes de escalonar horizontalmente

Ao configurar os recursos de computação para seus jobs de treinamento, recomendamos que você faça o escalonamento antes do escalonamento horizontal. Isso significa que você precisa escolher um dispositivo maior e mais potente antes de usar vários dispositivos menos potentes. Recomendamos que você faça o escalonamento da seguinte maneira:

  1. Um worker + um dispositivo
  2. Worker único + dispositivo mais potente
  3. Um worker + vários dispositivos
  4. Treinamento distribuído

Para avaliar os benefícios da pesquisa ANN, é possível medir a latência e a recuperação de uma determinada consulta. Para ajudar no ajuste de índice, o Vertex AI Vector Search oferece a capacidade de criar um índice de força bruta. Os índices de força bruta vão realizar uma pesquisa exaustiva, à custa de uma latência maior, para encontrar os vizinhos mais próximos verdadeiros de um determinado vetor de consulta. O uso de índices de força bruta não é destinado ao uso em produção, mas fornece uma boa referência ao calcular o recall durante o ajuste de índice.

Para avaliar o recall em relação à latência, implante as embeddings de candidato pré-calculadas em um índice configurado para pesquisa de ANN e em outro índice configurado para pesquisa de força bruta. O índice de força bruta vai retornar os vizinhos mais próximos absolutos, mas geralmente vai demorar mais do que uma pesquisa de ANN. Talvez você esteja disposto a sacrificar parte da recuperação para ganhar latência de recuperação, mas essa troca precisa ser avaliada. Outras características que afetam o recall e a latência incluem:

  • Parâmetros de estimativa: muitas decisões de estimativa afetam o espaço de incorporação, que se torna o índice de veiculação. Compare os candidatos recuperados para índices criados com base em modelos de recuperação superficiais e profundos.
  • Dimensões: as dimensões são outro aspecto que é determinado pelo modelo. As dimensões do índice ANN precisam corresponder às dimensões da consulta e dos vetores de torre candidatos.
  • Tags de aglomeração e filtragem: as tags podem oferecer recursos poderosos para personalizar os resultados de acordo com diferentes casos de uso de produção. É uma prática recomendada entender como as tags influenciam os candidatos recuperados e afetam a performance.
  • Contagem de ANN: aumentar esse valor aumenta o recall e pode aumentar proporcionalmente a latência.
  • Porcentagem de nós de folha a serem pesquisados: a porcentagem de nós de folha a pesquisar é a opção mais importante para avaliar a recuperação em relação ao compromisso de latência. Aumentar esse valor aumenta o recall e pode aumentar proporcionalmente a latência.

A seguir

Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.

Colaboradores

Autores:

Outro colaborador: Kaz Sato | Mediador de desenvolvedores