Como o Amp na Amazon usou dados para aumentar o envolvimento do cliente, Parte 2: Construindo uma plataforma de recomendação de shows personalizada usando o Amazon SageMaker

Amplificador é um novo aplicativo de rádio ao vivo da Amazon. Com o Amp, você pode hospedar seu próprio programa de rádio e tocar músicas do catálogo da Amazon Music ou sintonizar e ouvir programas que outros usuários do Amp estão hospedando. Em um ambiente onde o conteúdo é abundante e diversificado, é importante adaptar a experiência do usuário ao gosto individual de cada usuário, para que eles possam encontrar facilmente os programas de que gostam e descobrir novos conteúdos de que gostariam.

O Amp usa aprendizado de máquina (ML) para fornecer recomendações personalizadas para shows Amp ao vivo e futuros na página inicial do aplicativo. As recomendações são calculadas usando um modelo Random Forest usando recursos que representam a popularidade de um programa (como ouvir e contagem de curtidas), popularidade de um criador (como o número total de vezes que os programas recentes foram reproduzidos) e afinidades pessoais de um usuário ao tópico e criador de um programa. As afinidades são calculadas implicitamente a partir dos dados comportamentais do usuário ou explicitamente a partir de tópicos de interesse (como música pop, beisebol ou política), conforme fornecido em seus perfis de usuário.

Esta é a parte 2 de uma série sobre como usar análise de dados e ML para Amp e criar uma plataforma personalizada de lista de recomendações de programas. A plataforma mostrou um aumento de 3% nas métricas de engajamento do cliente rastreadas (curtir um programa, seguir um criador, ativar notificações de próximos programas) desde seu lançamento em maio de 2022.

Consulte Parte 1 para saber como os dados comportamentais foram coletados e processados ​​usando os sistemas de dados e análises.

Visão geral da solução

O recomendador de show baseado em ML para Amp tem cinco componentes principais, conforme ilustrado no diagrama de arquitetura a seguir:

1. O aplicativo móvel Amp.
2. Serviços de back-end que coletam os dados comportamentais, como curtidas e seguidores, bem como transmitem informações relacionadas ao programa, como atualizações de status quando os programas são ao vivo.
3. Ingestão em tempo real de dados comportamentais e de exibição, e computação e armazenamento de recursos em tempo real (online).
4. Computação e armazenamento de recursos em lote (offline).
5. Um sistema de recomendação que lida com solicitações recebidas do back-end do aplicativo para obter uma lista de programas. Isso inclui inferência em tempo real para classificar shows com base em recursos personalizados e não personalizados.

Este post se concentra nas partes 3, 4 e 5 em um esforço para detalhar o seguinte:

O diagrama a seguir mostra a arquitetura de alto nível e seus componentes.

Nas seções a seguir, fornecemos mais detalhes sobre computação de recursos em tempo real, computação de recursos em lote, inferência em tempo real, integridade operacional e os resultados observados.

Computação de recursos em tempo real

Alguns recursos, como o número de curtidas e a contagem de ouvintes de um programa, precisam ser transmitidos continuamente e usados ​​como estão, enquanto outros, como o número de sessões de audição com mais de 5 minutos, também precisam ser transformados em tempo real como dados brutos para sessões é transmitido. Esses tipos de recursos em que os valores precisam ser calculados no momento da inferência são chamados de ponto no tempo (PIT). Os dados dos recursos PIT precisam ser atualizados rapidamente, e a versão mais recente deve ser gravada e lida com baixa latência (menos de 20 milissegundos por usuário para 1,000 programas). Os dados também precisam estar em um armazenamento durável, pois dados ausentes ou parciais podem causar recomendações deterioradas e experiência ruim do cliente. Além da latência de leitura/gravação, os recursos de PIT também exigem baixo tempo de reflexão. O tempo de reflexão é o tempo que leva para um recurso estar disponível para leitura depois que os eventos de contribuição foram emitidos, por exemplo, o tempo entre um ouvinte curtindo um programa e o recurso PIT LikeCount sendo atualizado.

As fontes dos dados são os serviços de back-end que atendem diretamente ao aplicativo. Alguns dos dados são transformados em métricas que são então transmitidas via Serviço de notificação simples da Amazon (Amazon SNS) para ouvintes downstream, como o pipeline de transformação de recursos de ML. Um banco de dados na memória, como o MemoryDB, é um serviço ideal para armazenamento durável e desempenho ultrarrápido em grandes volumes. O componente de computação que transforma e grava recursos no MemoryDB é o Lambda. O tráfego do aplicativo segue padrões diários e semanais de picos e quedas, dependendo da hora e do dia. O Lambda permite o dimensionamento automático para o volume de eventos de entrada. A natureza independente de cada transformação de métrica individual também torna o Lambda, que é um serviço sem estado por si só, uma boa opção para esse problema. Colocando Serviço de fila simples da Amazon (Amazon SQS) entre o Amazon SNS e o Lambda não apenas evita a perda de mensagens, mas também atua como um buffer para rajadas inesperadas de tráfego que os limites de simultaneidade pré-configurados do Lambda podem não ser suficientes para atender.

Computação de recursos em lote

Os recursos que usam dados comportamentais históricos para representar o gosto em constante evolução de um usuário são mais complexos de calcular e não podem ser calculados em tempo real. Esses recursos são calculados por um processo em lote que é executado de vez em quando, por exemplo, uma vez por dia. Os dados para recursos em lote devem oferecer suporte a consultas rápidas para filtragem e agregação de dados e podem abranger longos períodos de tempo, portanto, serão maiores em volume. Como os recursos de lote também são recuperados e enviados como entradas para inferência em tempo real, eles ainda devem ser lidos com baixa latência.

A coleta de dados brutos para computação de recursos em lote não tem o requisito de tempo de reflexão de subminuto que os recursos PIT têm, o que torna viável armazenar em buffer os eventos por mais tempo e transformar métricas em lote. Essa solução utilizou o Kinesis Data Firehose, um serviço gerenciado para ingerir rapidamente dados de streaming em vários destinos, incluindo Serviço de armazenamento simples da Amazon (Amazon S3) para métricas persistentes no data lake do S3 a serem utilizadas em cálculos offline. O Kinesis Data Firehose fornece um buffer de eventos e integração do Lambda para coletar, transformar em lote e persistir facilmente essas métricas no Amazon S3 para serem utilizadas posteriormente pela computação de recursos em lote. Os cálculos de recursos em lote não têm os mesmos requisitos de leitura/gravação de baixa latência que os recursos PIT, o que torna o Amazon S3 a melhor escolha porque oferece armazenamento durável e de baixo custo para armazenar esses grandes volumes de métricas de negócios.

Nosso modelo de ML inicial usa 21 recursos de lote calculados diariamente usando dados capturados nos últimos 2 meses. Esses dados incluem o histórico de reprodução e engajamento do aplicativo por usuário e crescem com o número de usuários e a frequência de uso do aplicativo. A engenharia de recursos nessa escala requer um processo automatizado para extrair os dados de entrada necessários, processá-los em paralelo e exportar o resultado para armazenamento persistente. A infraestrutura de processamento é necessária apenas para a duração dos cálculos. Processamento SageMaker fornece imagens pré-construídas do Docker que incluem Apache Spark e outras dependências necessárias para executar trabalhos de processamento de dados distribuídos em grande escala. A infraestrutura subjacente de um trabalho de processamento é totalmente gerenciada pelo SageMaker. Os recursos de cluster são provisionados durante o trabalho e limpos quando um trabalho é concluído.

Cada etapa do processo em lote - coleta de dados, engenharia de recursos, persistência de recursos - faz parte de um fluxo de trabalho que requer tratamento de erros, novas tentativas e transições de estado entre eles. Com Funções de etapa da AWS, você pode criar uma máquina de estado e dividir seu fluxo de trabalho em várias etapas de pré-processamento e pós-processamento, bem como uma etapa para persistir os recursos no SageMaker Feature Store ou os outros dados no Amazon S3. Uma máquina de estado no Step Functions pode ser acionada via Amazon Event Bridge para automatizar a computação em lote para ser executada em uma programação definida, como uma vez por dia às 10h UTC.

Depois que os recursos são calculados, eles precisam ser versionados e armazenados para serem lidos durante a inferência, bem como o retreinamento do modelo. Em vez de criar seu próprio serviço de armazenamento e gerenciamento de recursos, você pode usar o SageMaker Feature Store. O Feature Store é um repositório totalmente gerenciado e desenvolvido especificamente para armazenar, compartilhar e gerenciar recursos para modelos de ML. Ele armazena o histórico de recursos de ML na loja offline (Amazon S3) e também fornece APIs para uma loja online para permitir leituras de baixa latência dos recursos mais recentes. A loja offline pode servir os dados históricos para mais treinamento e experimentação do modelo, e a loja online pode ser chamada por suas APIs voltadas para o cliente para obter recursos para inferência em tempo real. À medida que evoluímos nossos serviços para fornecer conteúdo mais personalizado, prevemos treinar modelos adicionais de ML e, com a ajuda da Feature Store, pesquisar, descobrir e reutilizar recursos entre esses modelos.

Inferência em tempo real

A inferência em tempo real geralmente requer a hospedagem de modelos de ML por trás de endpoints. Você pode fazer isso usando servidores ou contêineres da Web, mas isso requer esforço de engenharia de ML e infraestrutura para gerenciar e manter. O SageMaker facilita a implantação de modelos de ML em endpoints em tempo real. O SageMaker permite treinar e fazer upload de modelos de ML e hospedá-los criando e configurando endpoints do SageMaker. A inferência em tempo real atende aos requisitos de baixa latência para classificação de programas conforme eles são navegados na página inicial do Amp.

Além da hospedagem gerenciada, o SageMaker oferece dimensionamento de endpoint gerenciado. A inferência do SageMaker permite definir uma política de dimensionamento automático com contagens mínimas e máximas de instâncias e uma utilização de destino para acionar o dimensionamento. Dessa forma, você pode expandir ou reduzir facilmente conforme a demanda muda.

Saúde operacional

O número de eventos que esse sistema manipula para computação de recursos em tempo real muda de acordo com o padrão natural de uso do aplicativo (tráfego maior ou menor com base na hora do dia ou dia da semana). Da mesma forma, o número de solicitações recebidas para inferência em tempo real é dimensionado com o número de usuários simultâneos do aplicativo. Esses serviços também obtêm picos inesperados de tráfego devido a autopromoções nas mídias sociais por criadores populares. Embora seja importante garantir que o sistema possa aumentar e diminuir para atender o tráfego de entrada com sucesso e economia, também é importante monitorar as métricas operacionais e alertar sobre quaisquer problemas operacionais inesperados para evitar a perda de dados e serviços aos clientes. O monitoramento da integridade desses serviços é simples usando Amazon CloudWatch. Métricas vitais de integridade do serviço, como falhas e latência de operações, bem como métricas de utilização, como memória, disco e uso de CPU, estão disponíveis imediatamente usando o CloudWatch. Nossa equipe de desenvolvimento usa painéis de métricas e monitoramento automatizado para garantir que possamos atender nossos clientes com alta disponibilidade (99.8%) e baixa latência (menos de 200 milissegundos de ponta a ponta para obter programas recomendados por usuário).

Medindo o resultado

Antes do recomendador de programas baseado em ML descrito neste post, um algoritmo heurístico mais simples classificava os programas Amp com base nos tópicos pessoais de interesse de um usuário que são auto-relatados em seu perfil. Configuramos um teste A/B para medir o impacto da mudança para os recomendadores baseados em ML com os dados de um usuário de suas interações anteriores no aplicativo. Identificamos melhorias em métricas como duração da audiência e número de ações de engajamento (curtir um programa, seguir um criador de programa, ativar notificações) como indicadores de sucesso. Testes A/B com 50% dos usuários que receberam recomendações de programas classificadas para eles por meio do recomendador baseado em ML mostraram um aumento de 3% nas métricas de engajamento do cliente e uma melhoria de 0.5% na duração da reprodução.

Conclusão

Com serviços criados especificamente, a equipe Amp conseguiu lançar a API de recomendação de show personalizada conforme descrito neste post para produção em menos de 3 meses. O sistema também se adapta bem às cargas imprevisíveis criadas por conhecidos apresentadores de programas ou campanhas de marketing que podem gerar um influxo de usuários. A solução utiliza serviços gerenciados para processamento, treinamento e hospedagem, o que ajuda a reduzir o tempo gasto na manutenção diária do sistema. Também podemos monitorar todos esses serviços gerenciados por meio do CloudWatch para garantir a integridade contínua dos sistemas em produção.

O teste A/B da primeira versão do recomendador baseado em ML do Amp em relação a uma abordagem baseada em regras (que classifica apenas os tópicos de interesse do cliente) mostrou que o recomendador baseado em ML expõe os clientes a conteúdo de alta qualidade de tópicos mais diversos , o que resulta em um número maior de seguidores e notificações ativadas. A equipe Amp está trabalhando continuamente para melhorar os modelos para fornecer recomendações altamente relevantes.

Para obter mais informações sobre a Feature Store, visite Loja de recursos Amazon SageMaker e confira outros casos de uso de clientes no Blog do AWS Machine Learning.

---

Sobre os autores

Tulipa Gupta é Arquiteto de Soluções na Amazon Web Services. Ela trabalha com a Amazon para projetar, criar e implantar soluções de tecnologia na AWS. Ela auxilia os clientes na adoção de práticas recomendadas durante a implantação de soluções na AWS e é entusiasta de Analytics e ML. Em seu tempo livre, ela gosta de nadar, caminhar e jogar jogos de tabuleiro.

David Kuo é Arquiteto de Soluções na Amazon Web Services. Ele trabalha com clientes da AWS para projetar, criar e implantar soluções de tecnologia na AWS. Ele trabalha com clientes de mídia e entretenimento e tem interesse em tecnologias de aprendizado de máquina. Em seu tempo livre, ele se pergunta o que deve fazer com seu tempo livre.

Manolya McCormick é um engenheiro de desenvolvimento de software sênior para Amp na Amazon. Ela projeta e cria sistemas distribuídos usando a AWS para atender a aplicativos voltados para o cliente. Ela gosta de ler e cozinhar novas receitas em seu tempo livre.

Jeff Christophersen é engenheiro de dados sênior da Amp na Amazon. Ele trabalha para projetar, criar e implantar soluções de Big Data na AWS que geram insights acionáveis. Ele auxilia equipes internas na adoção de soluções escaláveis ​​e automatizadas e é um entusiasta de Analytics e Big Data. Em seu tempo livre, quando ele não está em um par de esquis, você pode encontrá-lo em sua mountain bike.