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 de geração de candidatos de duas torres de ponta a ponta com a Vertex AI. A estrutura de modelagem de duas torres é uma técnica de recuperação eficiente para casos de uso de personalização porque aprende a similaridade 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 veiculaçã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 escalonar a recuperação profunda com os recomendadores do TensorFlow e a pesquisa de vetores.

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:

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 Vertex AI Training. Cada torre é salva separadamente e usada para tarefas diferentes.
• Torres de consulta e candidata registradas: depois que as torres são treinadas, cada uma é enviada separadamente para o Vertex AI Model Registry.
• Torre de consultas implantada: a torre de consultas registrada é implantada em um endpoint on-line da Vertex AI.
• Previsão em lote de embeddings: a torre de candidatos registrada é usada em um job de previsão em lote para pré-calcular as representações de embedding de todos os itens candidatos disponíveis.
• JSON de embeddings: os embeddings previstos são salvos em um arquivo JSON no Cloud Storage.
• Índice ANN: a pesquisa vetorial da Vertex AI é usada para criar um índice de exibição configurado para pesquisa aproximada do vizinho mais próximo (ANN, na sigla em inglês).
• Índice implantado: o índice ANN é implantado em um endpoint de índice do Vector Search da Vertex AI.

Produtos usados

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

• Vertex AI Training: um serviço de treinamento totalmente gerenciado que permite operar treinamento de modelo em grande escala.
• Pesquisa de vetor: um serviço de correspondência de similaridade de vetor 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 seus 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 fora 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 duas etapas ou, às vezes, como sistemas de várias etapas. O objetivo da primeira etapa, a geração de candidatos, é analisar uma grande coleção de itens candidatos e recuperar um subconjunto relevante de centenas de itens para tarefas de filtragem e classificação downstream. Para otimizar essa tarefa de recuperação, considere estes dois objetivos principais:

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

O diagrama a seguir mostra os componentes conceituais de um recomendador de duas etapas:

No diagrama, a geração de candidatos filtra milhões de itens candidatos. Em seguida, 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 recursos de consulta ou de item candidato e produz uma representação de incorporação desses recursos. Cada torre é implantada separadamente porque será usada para tarefas diferentes na produção:

• Torre de candidatos: usada para pré-calcular incorporações de todos os itens candidatos. Os embeddings pré-calculados são implantados em um endpoint de índice da Pesquisa de vetor da Vertex AI otimizado para recuperação de baixa latência.
• Torre implantada: durante a exibiçã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 pesquisar 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 incorporaçã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 desacoplar a inferência das representações de consulta e de candidatos. As vantagens desse desacoplamento são principalmente duas:

• É possível veicular itens novos sem treinar um novo vocabulário de itens. Ao transmitir qualquer conjunto de recursos de item para a torre de itens candidatos, é possível calcular os embeddings de itens para qualquer conjunto de candidatos, mesmo aqueles que não são vistos durante o treinamento. Realizar essa 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 aqueles que ainda não interagiram com o sistema de recomendação. Esse suporte é possível porque as arquiteturas de duas torres processam conteúdo avançado e recursos de metadados 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 pré-calculando todos os embeddings de itens candidatos. Esses encodings pré-calculados podem ser indexados e implantados em uma infraestrutura de exibição otimizada para recuperação de baixa latência.
  • O aprendizado conjunto das torres permite descrever itens em termos de consultas e vice-versa. Se você tiver metade de um par, como uma consulta, e precisar procurar o outro item correspondente, poderá 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 seus requisitos específicos, você pode considerar outros fatores de design e compensações.

Segurança

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

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar 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 os pipelines de entrada de dados e o gráfico de treinamento geral, recomendamos criar um perfil de desempenho de treinamento com o Cloud Profiler. O Profiler é uma implementação gerenciada do TensorBoard Profiler de código aberto.

Ao transmitir o argumento –profiler no job de treinamento, você permite que o callback do TensorFlow crie um perfil de um número definido de lotes para cada época. O perfil captura rastreamentos da CPU do host e do hardware de GPU ou TPU do dispositivo. Os rastreamentos 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 TensorBoard da Vertex AI, 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 ao máximo os aceleradores

Ao anexar aceleradores de treinamento, como GPUs NVIDIA ou Cloud TPUs, é importante mantê-los totalmente utilizados. A utilização total dos 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 total dos aceleradores de treinamento também é uma prática recomendada para a eficiência do job, porque não ter tempo ocioso resulta em menos consumo geral de recursos.

Para manter um acelerador totalmente utilizado, normalmente você realiza algumas iterações de descoberta e otimização do gargalo e repete essas etapas até que a utilização do dispositivo acelerador seja aceitável. Como muitos dos conjuntos de dados para esse caso de uso são grandes demais para caber na memória, os gargalos geralmente são 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:

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 a performance, comece determinando se o desempenho geral é limitado pela CPU do host ou pelo dispositivo acelerador (GPU ou TPU). O dispositivo é responsável por acelerar o loop 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 o desempenho do pipeline de entrada e do dispositivo.

Melhorar a performance do pipeline de entrada

• Leitura de dados do armazenamento: para melhorar as leituras de dados, tente usar o armazenamento em cache, o prefetching, 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.
• Envio de dados para o dispositivo: para reduzir o tempo total do job, transfira dados do host para vários dispositivos em paralelo.

Melhorar o desempenho do dispositivo

• Aumentar o tamanho do minilote. Os minilotes são o número de amostras de treinamento usadas por cada dispositivo em uma iteração de um loop 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 demais o tamanho do minilote, poderá ter erros de falta de memória e divergência do modelo.
• Vetorize 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 ao agendamento e à execução. Ao transformar um lote de entradas, você incorre no custo fixo 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ê escalonar verticalmente antes do horizontal. Isso significa que você precisa escolher um dispositivo maior e mais potente antes de usar vários dispositivos menos potentes. Recomendamos que você reduzir escalonamento horizontal seguinte maneira:

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

Avaliar o recall em relação à latência para a pesquisa de vetor de ANN

Para avaliar os benefícios da pesquisa ANN, meça a latência e o recall de uma determinada consulta. Para ajudar no ajuste do índice, o Vertex AI Vector Search permite criar um índice de força bruta. Os índices de força bruta realizam 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 à produção, mas fornece uma boa base ao calcular o recall durante o ajuste do índice.

Para avaliar o recall em relação à latência, implante os encodings candidatos pré-calculados em um índice configurado para pesquisa de ANN e em outro configurado para pesquisa de força bruta. O índice de força bruta retorna os vizinhos mais próximos absolutos, mas geralmente leva mais tempo do que uma pesquisa de ANN. Talvez você queira sacrificar um pouco do recall de recuperação para ganhar em 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 acaba se tornando o índice de veiculação. Compare os candidatos recuperados para índices criados com modelos de recuperação superficial e profunda.
• Dimensões: outro aspecto determinado pelo modelo. As dimensões do índice ANN precisam corresponder às dimensões dos vetores de consulta e de torre de candidatos.
• Tags de lotação e filtragem: as tags podem oferecer recursos avançados para personalizar resultados em 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 a latência proporcionalmente.
• Porcentagem de nós de folha a serem pesquisados: a porcentagem de nós de folha a serem pesquisados é a opção mais importante para avaliar a compensação entre recall e latência. Aumentar esse valor aumenta o recall e pode aumentar a latência proporcionalmente.

A seguir

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

Colaboradores

Autores:

• Jordan Totten | Engenheiro de clientes
• Jeremy Wortz | Engenheiro de clientes
• Lakshmanan Sethu | Gerente técnico de contas

Outro colaborador: Kaz Sato | Mediador de desenvolvedores