Como escalar modelos de Machine Learning para diferentes contextos
Entendendo o problema
Uma das fases mais importantes na vida de uma empresa é o momento de expansão: após algum tempo atuando e aprendendo no mercado de origem, muitas empresas vêem na expansão para outros mercados uma oportunidade de gerar mais receita e aumentar sua participação no mercado.
Na Loft não é diferente e, no nosso contexto, expansão significa primordialmente começar a atuar em novas cidades. No momento da escrita deste artigo, a Loft atua em 5 cidades (São Paulo, Rio de Janeiro, Belo Horizonte, Guarulhos e Porto Alegre), mas o nosso objetivo é atuar no maior número possível de cidades.
Para que isso ocorra da melhor maneira, é necessário que tanto os times de operação quanto os times de tecnologia estejam preparados para realizar a expansão com pouco esforço. Do ponto de vista de tecnologia, estar preparado é construir uma infraestrutura que precise de pouca ou nenhuma intervenção manual. Mais especificamente, para o time de Ciência de Dados, precisamos garantir que nossos modelos estejam treinados e preparados para realizarem boas previsões nas novas cidades de atuação. Mas a pergunta é: como podemos deixar modelos preparados se para cada cidade teremos dados e hiperparâmetros distintos?
Requisitos
Antes de começar a pensar em possíveis soluções, listamos alguns requisitos que devemos garantir:
Um código, múltiplas configurações
O primeiro passo para encontrar a solução ideal foi perceber que, independente de dados ou hiperparâmetros diferentes, o código era exatamente o mesmo para as diferentes cidades. Por exemplo, um dos modelos principais do time de Ciência de Dados é o modelo de recomendação de apartamentos similares.
No entanto, as recomendações de apartamentos no Rio de Janeiro podem depender de variáveis diferentes do que imóveis de São Paulo, como distância até a praia, por exemplo. Ou podemos também querer recomendar um número diferente de imóveis similares em cada cidade, o que seria um novo parâmetro da expansão do modelo. Acontece que, independente dos dados que passamos ou dos hiperparâmetros que configuramos, o código do modelo em si é basicamente o mesmo. É daí que vem a nossa primeira ideia: vamos separar código e configurações, de forma que o mesmo código rode para diferentes cidades sem precisar de alterações.
Gerenciando múltiplos arquivos
Apesar de fazer muito sentido, essa solução gera um novo problema: como lidamos com a criação, atualização e remoção de tantos arquivos de configuração? Quando temos poucas cidades, o gerenciamento é até simples. Mas quando atingirmos dezenas ou centenas de cidades no nosso portfólio, o custo de gerenciar tantos arquivos pode se tornar maior do que simplesmente criar novos modelos.
Pensando nisso, criamos um framework de expansão para gerenciamento de configurações. A ideia é simples: com um único comando, podemos expandir para novas cidades, atualizar alguma configuração ou mesmo remover alguma cidade do modelo. Esse framework consiste em scripts Python que já vem configurados para uso sempre que criamos um novo projeto a partir do boilerplate (um projeto padrão que seguimos sempre que iniciamos um novo modelo) criado pelo nosso time MLOps.
A ideia foi criar arquivos “base”, com algumas configurações pré definidas. Sempre que quisermos expandir para uma nova cidade, basta rodarmos um comando no terminal e um novo arquivo padrão para aquela cidade é gerado. Se, por um acaso, as configurações padrão não forem adequadas, temos total liberdade para modificar o arquivo posteriormente, ele só nos dá uma estrutura pré definida. Da mesma forma, criamos scripts de atualização e remoção de cidades.
Expansão automática
Essa solução, do jeito que está até aqui, já resolveria bem o nosso problema. Mas percebemos mais uma oportunidade, pensando no requisito de padronização para simplificar ainda mais o processo de expansão.
Dado que fizemos um esforço de migração do nosso ecossistema de modelos para o mesmo framework, o modo como a expansão é feita em todos os modelos é exatamente o mesmo. Dessa forma, podemos aproveitar essa padronização para criar um sistema que verifique automaticamente quais cidades estão no portfólio da Loft e se já temos dados suficientes para cada uma delas, dependendo da necessidade de cada modelo. Por exemplo, fazendo uma análise do modelo de recomendação de apartamentos similares, vimos que um valor mínimo para um bom resultado do modelo são 350 apartamentos na cidade.
Nesse sentido, outros modelos podem ter outras regras, dependendo dos dados necessários (mas isso já dá assunto para outro artigo). Quando atingimos a quantidade que julgamos ideal, esse sistema de monitoramento já realiza o treinamento dos modelos para cada cidade. Dessa forma, uma vez definidas as regras de expansão, não precisamos mais nos preocupar em como ou quando novas cidades entrarão no portfólio, os nossos modelos já estão preparados para isso.
Para finalizar, se você gostou do conteúdo deste artigo e quer saber mais sobre como usamos tecnologia para transformar o mercado imobiliário, basta se inscrever no nosso blog do Medium.
E para você que quer fazer parte da Loft, estamos com vagas abertas no nosso time de Ciência de Dados!#VemPraLoft Confira aqui nossas vagas e acesse: carreiras.loft.com.br para saber mais!! #TransformeComAGente #OJeitoLoft
