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

Last reviewed 2025-01-16 UTC

Este documento fornece 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 poderosa 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 disponibilização de baixa latência. Para mais informações sobre as técnicas de modelagem , a definição de problemas 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 disponibilizaçã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 diferentes tarefas.
• Torres de consulta e candidatas registradas: depois que as torres são treinadas, cada uma é 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.
• Previsão em lote de embeddings: a torre candidata 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 de ANN: o Vector Search da Vertex AI é usado para criar um índice de disponibilização configurado para pesquisa de vizinho mais próximo aproximado (ANN, na sigla em inglês).
• Índice implantado: o índice de ANN é implantado em um endpoint de índice do Vector Search da Vertex AI.

Produtos usados

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

• Vertex AI Training: um serviço de treinamento totalmente gerenciado que permite operacionalizar treinamento de modelo em grande escala.
• Vector Search: um serviço de correspondência de similaridade de vetores 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 repositório de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e de fora Google Cloud, e são replicados em locais para redundância.

Caso de uso

Para atender aos requisitos de disponibilizaçã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 do primeiro estágio, 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 o treinamento de modelo, aprenda a melhor representação do problema ou tarefa a ser resolvida e compile essa representação em <query, candidate> embeddings.
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 de dois estágios:

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 recursos de consulta ou de item candidato e, em seguida, produz uma representação de embedding desses recursos. Cada torre é implantada separadamente, porque será usada para diferentes tarefas na produção:

• Torre candidata: a torre candidata é usada para pré-calcular embeddings para todos os itens candidatos. Os embeddings pré-calculados são implantados em um índice do Vector Search 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 embedding. 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 uma arquitetura de duas torres captura a relação semântica de entidades de consulta e candidatas, e as mapeia para um espaço de embedding compartilhado. Quando as entidades são mapeadas para um espaço de embedding compartilhado, entidades semanticamente semelhantes são agrupadas mais próximas. Portanto, se você calcular os embeddings de vetor de uma determinada consulta, poderá pesquisar o espaço de embedding para os itens candidatos mais próximos (mais semelhantes). O principal benefício dessa arquitetura é a capacidade de separar a inferência de representações de consulta e candidatas. As vantagens dessa separação são principalmente duas:

• É possível disponibilizar novos itens sem treinar um novo vocabulário de itens. Ao fornecer qualquer conjunto de recursos de itens 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. A execução desse cálculo ajuda a resolver o problema de inicialização a frio.
  • A torre candidata 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 conteúdo avançado e recursos de metadados sobre cada <query, candidate> par. 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 embeddings pré-calculados podem ser indexados e implantados em uma infraestrutura de disponibilizaçã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. O pré-cálculo 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 que atenda às suas necessidades de segurança e desempenho . Google Cloud 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

O Vector Search da Vertex AI oferece suporte a implantações de endpoints públicos e de nuvem privada virtual (VPC). Se você quiser usar uma rede VPC, comece seguindo as etapas em Configurar uma conexão de peering de rede VPC. Se o índice do Vector Search 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, será necessário criar a instância do workbench na mesma rede VPC que o endpoint de índice implantado. Da mesma forma, qualquer pipeline que deva 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 que atenda aos requisitos de desempenho das suas cargas de trabalho. Google Cloud

Criar perfil de jobs de treinamento

Para otimizar os pipelines de entrada de dados e o gráfico de treinamento geral, recomendamos que você crie 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 rastros da CPU do host e do hardware da GPU ou 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 TensorBoard da Vertex AI, consulte Criar perfil de desempenho de treinamento de modelo. Para práticas recomendadas de depuração, consulte Otimizar o desempenho da GPU. Para informações sobre como otimizar o desempenho, consulte Otimizar o desempenho do TensorFlow usando o Profiler.

Utilizar totalmente 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 os aceleradores 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 menor consumo geral de recursos.

Para manter um acelerador totalmente utilizado, normalmente você executa algumas iterações de localização do gargalo, otimização do gargalo e repetição dessas 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 muito grandes 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 o desempenho, 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 o desempenho do pipeline de entrada

• Leitura de dados do armazenamento: para melhorar as leituras de dados, tente usar o armazenamento em cache, 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 interleave transformação no pipeline de entrada de dados.
• Envio de 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

• 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 muito o tamanho do minilote, poderá ocorrer erros de memória insuficiente e divergência de modelo.
• Vetorizar 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 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ê escalonar verticalmente antes de escalonar horizontalmente. 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 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 de ANN, você pode medir a latência e o recall de uma determinada consulta. Para ajudar no ajuste do índice, o Vector Search da Vertex AI oferece a capacidade de criar um índice de força bruta. Os índices de força bruta vão realizar uma pesquisa exaustiva, com o custo de maior latência, para encontrar os verdadeiros vizinhos mais próximos de um determinado vetor de consulta. O uso de índices de força bruta não é destinado ao uso de produção, mas fornece uma boa linha de base ao calcular o recall durante o ajuste do índice.

Para avaliar o recall em relação à latência, implante os embeddings candidatos pré-calculados 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 normalmente leva mais tempo do que uma pesquisa de ANN. Talvez você queira sacrificar algum recall de recuperação para ganhar latência de recuperação, mas essa compensação precisa ser avaliada. Outras características que afetam o recall e a latência incluem o seguinte:

• Parâmetros de modelagem: muitas decisões de modelagem afetam o espaço de embedding, que acaba se tornando o índice de disponibilização. Compare os candidatos recuperados para índices criados a partir de modelos de recuperação rasos e profundos.
• Dimensões: as dimensões são outro aspecto que é, em última análise, determinado pelo modelo. As dimensões do índice de ANN precisam corresponder às dimensões dos vetores de consulta e da torre candidata.
• Tags de lotação e filtragem: as tags podem fornecer recursos poderosos para personalizar resultados para diferentes casos de uso de produção. É uma prática recomendada entender como as tags influenciam os candidatos recuperados e afetam o desempenho.
• 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 serem pesquisados é a opção mais importante para avaliar o recall em relação à compensação 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:

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

Outro colaborador: Kaz Sato | Defensor de desenvolvedores de equipe