Alguns meses atrás, tentei me desafiar a empreender uma jornada para transitar de uma formação em análise de dados para engenharia de dados. Até agora, construí um total de dois projetos impactantes no mundo real que realmente me ensinaram algo útil. Construí um pipeline ET L do Git Hub que extrai repositórios do Git Hub e os carrega em um banco de dados SQLite — isso rodava em um cronograma usando Git Hub Actions.

Também construí um pipeline RSS que extrai artigos de feeds RSS e os armazena em um banco de dados Kestra — orquestrado pelo Kestra para rodar em um cronograma horário. Agora que entendi ET L até certo ponto, queria tentar algo novo. Queria continuar praticando tudo o que aprendi no passado enquanto construía algo novo.

Sempre fui fascinado pelo campo de aprendizado de máquina, mas nunca tive a coragem de entrar porque achava que tinha matemática complexa. Não mais. Recentemente, construí um modelo de previsão de churn para uma empresa de telecomunicações fictícia que chamo de Northline Mobile (P.

S. Estou usando uma empresa fictícia porque entendo as coisas melhor com cenários do mundo real). Forneçi a ele dados de 7043 clientes, dizendo se haviam se inscrito em um contrato de 1 ano ou planos mensais, tempo de cliente, cobranças mensais, complementos, etc. Além disso, disse quem eventualmente deixou a Northline Mobile.

Validei o modelo de forma cruzada com clientes que ele ainda não tinha visto. Alcançou 81% de precisão. Isso me ensinou tudo o que entra na construção de um modelo.

Obviamente, não entendi todo o código complexo, porque prefiro interfaces intuitivas de arrastar e soltar em vez de código complexo. Mas entendi os blocos de construção essenciais para construir um modelo; explicarei mais abaixo com uma arquitetura simplificada. Então, construir esse modelo pareceu uma vitória do ponto de vista de aprendizado de máquina; meu modelo funcionava.

Mas ainda havia um problema: ainda não era realmente útil. Assumindo que um funcionário da Northline que precisava de uma previsão viesse a mim, eu teria que abrir o Jupyter, carregar o notebook certo, executar as células na ordem correta e fazer uma chamada manual para predict_churn(). Sim, o modelo existe, mas eu era o único que sabia como usá-lo.

Ninguém mais na Northline poderia simplesmente enviar informações sobre um cliente para o modelo e recuperar uma previsão e ele também não podia se comunicar com nenhum outro aplicativo. Este artigo cobrirá isso. Recentemente, aprendi que há uma diferença entre ter um modelo e ter um serviço.

Se um modelo apenas fica em um notebook, apenas a pessoa que o construiu pode usá-lo. Mas torná-lo um serviço torna possível para todos usá-lo, outras equipes, aplicativos, painéis e sistemas que não precisam saber ou se importar como a previsão é feita. Acontece que construir o modelo de aprendizado de máquina foi a parte mais fácil, mas torná-lo útil é outro elemento crucial que vale a pena explorar.

O que 'Concluído' significava antes da APIAqui está aproximadamente como era a construção do modelo: É basicamente isso. Nada muito sofisticado. No final disso, eu tinha um classificador de churn treinado, um pipeline de pré-processamento que limpava e codificava os dados brutos, e números de avaliação com os quais eu estava confortável (mais sobre esses números em breve, eles não são perfeitos e não vou fingir que são).

Mas como eu disse. Assumindo que a equipe de retenção da Northline construa um painel, e queiram que ele sinalize automaticamente clientes em risco. O painel deles não pode razoavelmente abrir meu notebook Jupyter e executar minhas células.

Precisa de algo totalmente diferente. Algo assim: Essa é a mudança que este artigo cobre. Uma rápida ressalva, no entanto: este não é um tutorial de Fast API.

Fast API é simplesmente a ferramenta que usei para expor o modelo como...