Este documento fornece uma arquitetura de referência que mostra como implementar um fluxo de trabalho de geração de candidatos de duas torres completo com o Vertex AI. A estrutura de modelagem de duas torres é uma técnica de obtenção eficaz para exemplos de utilização de personalização, porque aprende a semelhança semântica entre duas entidades diferentes, como consultas Web e itens candidatos.
Este documento destina-se a profissionais técnicos, como cientistas de dados e engenheiros de aprendizagem automática, que estão a desenvolver aplicações de recomendações em grande escala com requisitos de publicação de baixa latência. Para mais informações sobre as técnicas de modelagem, a formulação de problemas e a preparação de dados para criar um modelo de duas torres, consulte o artigo Escalar a obtenção detalhada com o TensorFlow Recommenders e a pesquisa vetorial.
Arquitetura
O diagrama seguinte mostra uma arquitetura para preparar um modelo de duas torres e implementar cada torre separadamente para diferentes tarefas de implementação e publicação:
A arquitetura no diagrama inclui os seguintes componentes:
- Dados de preparação: os ficheiros de preparação são armazenados no Cloud Storage.
- Preparação de duas torres: o modelo de duas torres combinado é preparado offline usando o serviço Vertex AI Training. Cada torre é guardada separadamente e usada para diferentes tarefas.
- Torres de consulta e candidatas registadas: depois de as torres serem preparadas, cada torre é carregada separadamente no Vertex AI Model Registry.
- Torre de consultas implementada: a torre de consultas registada é implementada num ponto final online da Vertex AI.
- Prever incorporações em lote: a torre candidata registada é usada num trabalho de previsão em lote para pré-calcular as representações de incorporação de todos os itens candidatos disponíveis.
- JSON de incorporações: as incorporações previstas são guardadas num ficheiro JSON no Cloud Storage.
- Índice ANN: o Vertex AI Vector Search é usado para criar um índice de publicação configurado para a pesquisa de vizinhos mais próximos aproximados (ANN).
- Índice implementado: o índice ANN é implementado num ponto final do índice do Vertex AI Vector Search.
Produtos usados
Esta arquitetura de referência usa os seguintes produtos Google Cloud :
- Vertex AI Training: um serviço de preparação totalmente gerido que lhe permite operacionalizar a preparação de modelos em grande escala.
- Vector Search: um serviço de correspondência de semelhanças vetoriais que lhe permite armazenar, indexar e pesquisar dados semanticamente semelhantes ou relacionados.
- Registo de modelos Vertex AI: um repositório central onde pode gerir o ciclo de vida dos seus modelos de ML.
- Cloud Storage: um serviço de armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acedidos a partir do interior e do exterior Google Cloud, e são replicados em várias localizações para redundância.
Exemplo de utilização
Para cumprir os requisitos de publicação de baixa latência, os sistemas de recomendações de grande escala são frequentemente implementados na produção como sistemas de duas fases ou, por vezes, como sistemas de várias fases. O objetivo da primeira fase, a geração de candidatos, é analisar uma grande coleção de itens candidatos e obter um subconjunto relevante de centenas de itens para tarefas de filtragem e classificação posteriores. Para otimizar esta tarefa de obtenção, considere estes dois objetivos principais:
- Durante a preparação do modelo, aprenda a melhor representação do problema ou da tarefa a resolver e compile esta representação em incorporações
<query, candidate>. - Durante a publicação de modelos, obtenha itens relevantes com rapidez suficiente para cumprir os requisitos de latência.
O diagrama seguinte mostra os componentes conceptuais de um sistema de recomendação de duas fases:
No diagrama, a geração de candidatos filtra milhões de itens candidatos. Em seguida, a classificação filtra os centenas de itens candidatos resultantes para devolver dezenas de itens recomendados.
A arquitetura de referência neste documento prepara um modelo de obtenção baseado em duas torres. Na arquitetura, cada torre é uma rede neural que processa as caraterísticas dos itens de consulta ou candidatos e, em seguida, produz uma representação de incorporação dessas caraterísticas. Cada torre é implementada separadamente, porque cada torre vai ser usada para diferentes tarefas na produção:
- Torre de candidatos: a torre de candidatos é usada para pré-calcular as incorporações de todos os itens candidatos. As incorporações pré-calculadas são implementadas num ponto final do índice do Vertex AI Vector Search otimizado para a obtenção de baixa latência.
- Torre implementada: durante a publicação online, a torre de consultas implementada converte as consultas de utilizadores não processadas em representações de incorporação. As representações de incorporação são usadas para procurar incorporações de itens semelhantes no índice implementado.
As arquiteturas de duas torres são ideais para muitas tarefas de obtenção, porque captam a relação semântica das entidades de consulta e candidatas, e mapeiam-nas para um espaço de incorporação partilhado. Quando as entidades são mapeadas para um espaço de incorporação partilhado, as entidades semanticamente semelhantes são agrupadas mais próximas. Por conseguinte, se calcular as incorporações de vetores de uma determinada consulta, pode pesquisar o espaço de incorporação dos artigos candidatos mais próximos (mais semelhantes). A principal vantagem desta arquitetura é a capacidade de separar a inferência das representações de consultas e candidatos. As vantagens desta desvinculação são principalmente duplas:
- Pode publicar itens novos sem voltar a formar um novo vocabulário de itens. Ao introduzir qualquer conjunto de caraterísticas do artigo na torre do artigo candidato, pode calcular as incorporações de artigos para qualquer conjunto de candidatos, mesmo aqueles que não são vistos durante a preparação. A realização deste cálculo ajuda a
resolver o problema de arranque a frio.
- A torre de candidatos pode suportar um conjunto arbitrário de itens candidatos, incluindo itens que ainda não interagiram com o sistema de recomendações. Este suporte é possível porque as arquiteturas de duas torres processam conteúdo multimédia e funcionalidades de metadados sobre cada par de
<query, candidate>. Este tipo de processamento permite que o sistema descreva um item desconhecido em termos de itens que conhece.
- A torre de candidatos pode suportar um conjunto arbitrário de itens candidatos, incluindo itens que ainda não interagiram com o sistema de recomendações. Este suporte é possível porque as arquiteturas de duas torres processam conteúdo multimédia e funcionalidades de metadados sobre cada par de
- Pode otimizar a inferência de obtenção pré-calculando todas as incorporações de itens candidatos. Estas incorporações pré-calculadas podem ser indexadas e implementadas
numa infraestrutura de publicação otimizada para obtenção de baixa latência.
- A aprendizagem conjunta das torres permite-lhe descrever itens em termos de consultas e vice-versa. Se tiver uma metade de um par, como uma consulta, e precisar de procurar o outro item correspondente, pode pré-calcular metade da equação antecipadamente. O pré-cálculo permite-lhe tomar o resto da decisão o mais rapidamente possível.
Considerações de design
Esta secção fornece orientações para ajudar a desenvolver uma arquitetura de geração de candidatos que satisfaça as suas necessidades de segurança e desempenho. Google Cloud As orientações nesta secção não são exaustivas. Consoante os seus requisitos específicos, pode optar por considerar fatores de design e compromissos adicionais.
Segurança
O Vertex AI Vector Search suporta implementações de pontos finais públicos e da nuvem virtual privada (VPC). Se quiser usar uma rede VPC, comece por seguir as instruções em Configure uma ligação de interligação de redes VPC. Se o índice de pesquisa vetorial for implementado num perímetro da VPC, os utilizadores têm de aceder aos recursos associados a partir da mesma rede VPC. Por exemplo, se estiver a desenvolver a partir do Vertex AI Workbench, tem de criar a instância do workbench na mesma rede VPC que o ponto final do índice implementado. Da mesma forma, qualquer pipeline que se espere que crie um ponto final ou implemente um índice num ponto final deve ser executado na mesma rede VPC.
Otimização do desempenho
Esta secção descreve os fatores a ter em conta quando usa esta arquitetura de referência para criar uma topologia no Google Cloud que cumpre os requisitos de desempenho das suas cargas de trabalho.
Tarefas de preparação de perfis
Para otimizar os pipelines de introdução de dados e o gráfico de formação geral, recomendamos que analise o desempenho da formação com o Cloud Profiler. O Profiler é uma implementação gerida do TensorBoard Profiler de código aberto.
Ao transmitir o argumento –profiler na tarefa de preparação, ativa a função de retorno de chamada do TensorFlow para criar perfis de um número definido de lotes para cada época. O perfil captura rastreios da CPU do anfitrião e do hardware da GPU ou TPU do dispositivo. Os rastreios fornecem informações sobre o consumo de recursos da tarefa de preparação. Para evitar erros de falta de memória, recomendamos que comece
com uma duração do perfil entre 2 e 10 passos de preparação e aumente conforme necessário.
Para saber como usar o Gerador de perfis com o Vertex AI Training e o Vertex AI TensorBoard, consulte o artigo Crie perfis do desempenho da preparação de modelos. Para ver as práticas recomendadas de depuração, consulte o artigo Otimize o desempenho da GPU. Para obter informações sobre como otimizar o desempenho, consulte o artigo Otimize o desempenho do TensorFlow com o Profiler.
Utilize totalmente os aceleradores
Quando anexa aceleradores de preparação, como GPUs NVIDIA ou TPUs na nuvem, é importante mantê-los totalmente utilizados. A utilização total dos aceleradores de preparação é uma prática recomendada para a gestão de custos, porque os aceleradores são o componente mais caro na arquitetura. A utilização total dos aceleradores de preparação também é uma prática recomendada para a eficiência das tarefas, porque não ter tempo de inatividade resulta num menor consumo geral de recursos.
Para manter um acelerador totalmente utilizado, normalmente, executa algumas iterações para encontrar o gargalo, otimizar o gargalo e, em seguida, repetir estes passos até que a utilização do dispositivo acelerador seja aceitável. Uma vez que muitos dos conjuntos de dados para este exemplo de utilização são demasiado grandes para caberem na memória, os gargalos encontram-se normalmente entre o armazenamento, as VMs do anfitrião e o acelerador.
O diagrama seguinte mostra as fases conceptuais de um pipeline de entrada de preparação de ML:
No diagrama, os dados são lidos do armazenamento e pré-processados. Depois de os dados serem pré-processados, são enviados para o dispositivo. Para otimizar o desempenho, comece por determinar se o desempenho geral está limitado pela CPU do anfitrião ou pelo dispositivo acelerador (GPU ou TPU). O dispositivo é responsável por acelerar o ciclo de aprendizagem, enquanto o anfitrião é responsável por fornecer dados de preparação ao dispositivo e receber resultados do dispositivo. As secções seguintes descrevem como resolver restrições melhorando o desempenho do pipeline de entrada e o desempenho do dispositivo.
Melhore o desempenho do pipeline de entrada
- Ler dados do armazenamento: para melhorar as leituras de dados, experimente o armazenamento em cache, a prefetching, os padrões de acesso sequenciais e a E/S paralela.
- Pré-processamento de dados: para melhorar o pré-processamento de dados, configure o
processamento paralelo
para a extração e a transformação de dados, e ajuste a
transformação
interleaveno pipeline de entrada de dados. - Enviar dados para o dispositivo: para reduzir o tempo total da tarefa, transfira dados do anfitrião para vários dispositivos em paralelo.
Melhore o desempenho do dispositivo
- Aumentar o tamanho do minilote. Os minilotes são o número de exemplos de preparação que são usados por cada dispositivo numa iteração de um ciclo de preparação. Ao aumentar o tamanho do minilote, aumenta o paralelismo entre operações e melhora a reutilização de dados. No entanto, o minilote tem de caber na memória com o resto do programa de treino. Se aumentar demasiado o tamanho do mini lote, pode ter erros de falta de memória e divergência do modelo.
- Vetorize funções definidas pelo utilizador. Normalmente, as transformações de dados podem ser expressas como uma função definida pelo utilizador que descreve como transformar cada elemento de um conjunto de dados de entrada. Para vetorizar esta função, aplica a operação de transformação a um lote de entradas de uma só vez, em vez de transformar um elemento de cada vez. Qualquer função definida pelo utilizador tem custos gerais relacionados com a programação e a execução. Quando transforma um lote de entradas, incorre nos custos gerais uma vez por lote, em vez de uma vez por elemento do conjunto de dados.
Aumente a escala antes de diminuir a escala
Quando configurar os recursos de computação para as tarefas de preparação, recomendamos que aumente a escala verticalmente antes de aumentar a escala horizontalmente. Isto significa que deve escolher um dispositivo maior e mais potente antes de usar vários dispositivos menos potentes. Recomendamos que aumente a escala da seguinte forma:
- Um trabalhador + um dispositivo
- Um único trabalhador + um dispositivo mais potente
- Um único trabalhador + vários dispositivos
- Preparação distribuída
Avalie a capacidade de memorização em função da latência para a pesquisa de vetores de ANN
Para avaliar as vantagens da pesquisa ANN, pode medir a latência e a capacidade de memorização de uma determinada consulta. Para ajudar no ajuste dos índices, a pesquisa vetorial da Vertex AI permite criar um índice de força bruta. Os índices de força bruta realizam uma pesquisa exaustiva, à custa de uma latência mais elevada, para encontrar os verdadeiros vizinhos mais próximos de um determinado vetor de consulta. A utilização de índices de força bruta não se destina à utilização em produção, mas fornece uma boa base quando calcula a capacidade de memorização durante o ajuste do índice.
Para avaliar a capacidade de memorização em comparação com a latência, implemente as incorporações de candidatos pré-calculadas num índice configurado para a pesquisa ANN e noutro índice configurado para a pesquisa de força bruta. O índice de força bruta devolve os vizinhos mais próximos absolutos, mas normalmente demora mais tempo do que uma pesquisa ANN. Pode estar disposto a sacrificar alguma capacidade de memorização da obtenção em troca de ganhos na latência de obtenção, mas esta compensação deve ser avaliada. Outras características que afetam a capacidade de memorização e a latência incluem o seguinte:
- Parâmetros de modelagem: muitas decisões de modelagem afetam o espaço de incorporação, que acaba por se tornar o índice de publicação. Compare os candidatos obtidos para índices criados a partir de modelos de obtenção superficiais e detalhados.
- Dimensões: as dimensões são outro aspeto que é, em última análise, determinado pelo modelo. As dimensões do índice ANN têm de corresponder às dimensões dos vetores da torre de consulta e candidatos.
- Tags de sobreposição e filtragem: as tags podem oferecer capacidades avançadas para personalizar os resultados para diferentes exemplos de utilização de produção. É uma prática recomendada compreender como as etiquetas influenciam os candidatos obtidos e afetam o desempenho.
- Contagem de ANN: aumentar este valor aumenta a evocação e pode aumentar proporcionalmente a latência.
- Percentagem de nós folha a pesquisar: a percentagem de nós folha a pesquisar é a opção mais crítica para avaliar a capacidade de memorização em função da compensação da latência. Aumentar este valor aumenta a evocação e pode aumentar proporcionalmente a latência.
O que se segue?
Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.
Colaboradores
Autores:
- Jordan Totten | Customer Engineer
- Jeremy Wortz | Customer Engineer
- Lakshmanan Sethu | Gestor de contas técnicas
Outro colaborador: Kaz Sato | Staff Developer Advocate