Como Criei uma POC de Sistema de Recomendação com Vibe Coding no Replit - Parte 2
Sistematização da Experiência Vibe Coding utilizando o Replit
Introdução
Na Parte 1 escrevi sobre o que é o Vibe Coding, sobre os diferentes níveis de pensamento que o mesmo exige e como isso me ajudou no desenvolvimento do projeto final da Pós-graduação em Data Science for Business Strategy. Ainda dei alguns exemplos de como apliquei esses diferentes níveis de pensamento
Na PARTE 2 pretendo dar uma visão global daquilo que foi feito para o desenvolvimento do projeto e mostrar partes da aplicação prática para o desenvolvimento da POC.
CRISP-DM
A metodologia utilizada na elaboração do projeto foi a CRISP-DM - Cross Industry Standard Process - Data Mining.
- Entendimento do problema e do negócio – Na escolha do projeto defini o Problem statement para justificar a escolha deste tipo de projeto e os benefícios que poderia trazer para o negócio. E com isso, escolher um dataset que fosse possível ser trabalhado (se bem que à partida um data scientist não sabe o que vai encontrar).
- Entendimento dos dados – O dataset escolhido foi uma amostra representativa do Dataset da Amazon Reviews 2023 – Baby Products. Iniciou-se o trabalho inicial com 50 000 registos e depois 10 000.
- Preparação dos dados – Limpeza, remoção de duplicados, tratamento de descrições vazias e criação de stopwords específicas tendo em conta o objetivo do projeto e as necessidades do negócio
- Modelagem dos dados e Escolha do Modelo – Escolheu-se, com base nos estudos e em literatura a “Vetorização com TF-IDF (min_df=3, max_df=0.7, ~4 000 features) e cálculo de proximidade semântica através da Similaridade do Cosseno”
- Avaliação do Modelo – Algumas métricas que nos revelou o modelo foram uma diversidade de 0.542 e uma similaridade robusta na ordem dos 0.453.
- Deploy – Esta fase, por motivos óbvios, estava fora de âmbito. Mas como já sabem, houve a criação de um protótipo funcional Lo-Fi em Replit.
Cada uma das fases acima descritas correspondeu, grosso modo, a uma entrega/avaliação intermediária. Portanto, o que defini acima em cada uma das fases da CRISP-DM não revela metade do trabalho que foi produzido. Aliás, para terem uma ideia, que vale o que vale, o projeto final resultou numa entrega final de um PowerPoint com 108 slides, incluindo anexos.
Toda a parte referente aos diversos steps da metodologia foi desenvolvida e testada fora do Replit. Mas faltava, para proporcionar um momento mais UAU, uma interface funcional para explorar e mostrar resultados de forma simples.
O Ciclo Vibe Coding na prática com o Replit - App Builder
Ao longo do projeto, repeti o ciclo Prompt → Teste → Erro → Debug → Checkpoint dalgumas vezes. Neste artigo irei apenas frisar alguns dos desafios que me lembro que surgiram ao longo desse ciclo. Imagem retirada do website do Replit.
Exemplo de Prompt Inicla no Replit
Na realidade não me recordo exatamente de qual foi a prompt com que iniciei o projeto no Replit. Até porque não cheguei a optar pela versão paga. Mas, diria que foi um texto de prompt simples, claro, e do tipo Zero-shot prompt, uma vez que anexei os ficheiros .pkl gerados em Python no desenvolvimento do sistema de recomendação. A prompt inicial terá sido algo como:
"Cria uma interface de um sistema de recomendação com base em conteúdo, que permita ao utilizador escolher um produto (product_id + product_name), e vê devolvidos o TOP 5 produtos (product_id + product_name) mais similares, excluindo o próprio produto escolhido. Para o melhor output possível, analisa os ficheiros anexados referentes à função do sistema de recomendação (func_sist_rec.pkl) e ao dataset já limpo e trabalhado (dataset_clean_final.csv) que serve de base ao sistema."
Alguns Testes
Após a inserção da prompt, corria a aplicação no Replit. O Agente, e depois o Assistente do Replit faziam o seu trabalho e quando terminava lia e analisava (aquilo que conseguia perceber do código) o código gerado e visualizava o output. Ou seja, escolhia um product_id com o respetivo product_name associado no interface e via o resultado.
Os Erros
Obviamente que mesmo com a melhor prompt o sistema vai produzir erros. E temos de saber lidar com eles, corrigindo-os como mencionado na PARTE 1 do artigo. Alguns dos erros que me lembro do sistema ter produzido foram:
O produto escolhido pelo utilizador aparecia na lista de recomendações. O que até me deixada admirado ou frustrado, uma vez que há parâmetros no código que anexei onde se percebe claramente que o produto escolhido não pode ser recomendado. Ou seja, a lógica do threshold de similaridade por exemplo, foi ignorada. A tal importância dos diversos níveis de pensamento para se perceber o que o modelo está a implementar.
O HTML + CSS, ou seja a interface não saiu bem logo à primeira. Alguns dos problemas que me recordo foram:
-
- Muitos elementos presentes que não eram necessários
- Má conjugação de cores de texto e fundos das células da tabela
- O utilizador tinha que fazer roll-up/down e row-left/right na tabela para poder ver toda a informação
Debugging a little
Em termos de debug, o que ia fazendo era tentando melhorar o interface, analisando algumas coisas que percebia em termos do código, nomeadamente HTML + CSS e afinando as prompts. Por exemplo:
“Adiciona um filtro para excluir o produto atual do resultado. Ajusta as imagens para 150x150 px e centraliza o texto.”
"Filtra os resultados para remover o produto atual e só mostra produtos com score > 0.45. Ajusta o HTML+CSS tendo por base a seguinte paleta de cores: Color matching de 6 cores com #845EC2."
Os Checkpoints…só do Replit
Na realidade o Replit ao ser um App Builder ajuda-nos com o versionamento do código, na medida em que o agente que tem integrado cria frequentemente os checkpoints (pushes) na plataforma. E assim, podemos voltar ao código anterior, caso o output de atual ou da próxima prompt corra mal.
Como disse anteriormente, por ser uma POC e por ser um adicional ao projeto, não senti a necessidade de quando algo estava mesmo funcional, copiar o checkpoint do Replit para um ficheiro para salvaguardar o progresso. Até porque há muita coisa que pode ser melhorada, como verão mais adiante e recordando que estamos a falar da utilização de uma versão free.
Aquilo que aconteceu foi o ter de ir fazendo mais prompts de forma a que o assistente corrigisse alguns temas, como por exemplo:
Evitar a repetição de recomendações duplicadas e Diversificar as categorias – Filtragem explícita no código e garantir a variedade mínima nas recomendações. Isto através de prompts mais claros, com regras do negócio e com explícita indicação para análise da parte X do ficheiro respetivo onde essas regras estava implementadas.
O que poderiam ser os Próximos passos
Se considerarmos apenas este dataset, os próximos passos imediatos seriam:
Adaptar o interface para todo o dataset e não apenas para uma amostra de produtos
Criar uma Interface que cumpra melhor as best practices de usabilidade, de design, de responsavidade e de acessibilidade e pensar em como poderia ser mais atrativa e interativa. Por exemplo, integrando imagens ou clips dos produtos recomendados.
Conclusão
Como disse no PARTE 1 deste artigo, foi a primeira vez que “utilizei” o Vibe Coding. Embora conhecesse bem o termo, não tinha tido até então oportunidade de dar-lhe prática. E portanto teria tudo para correr mal, ou menos bem e levar a stresses e ansiedade desnecessária do que aquela que um projeto académico já acarreta.
Mas o facto de ter escolhido uma metodologia para elaborar o projeto académico revelou-se fundamental no processo de Vibe Coding. Isto porque obrigou-me a pensar no problema, no projeto mesmo antes de abrir qualquer ferramenta de Vibe Coding. Outra conclusão que retirei, em particular deste projeto é que uma prompt é importante, mas o contexto, que neste caso foi todo o trabalhado de desenvolver o modelo e o algoritmo, é fundamental.
Ou seja, dependendo do nosso objetivo, podemos ter diversos níveis de promtp e de “utilização” do Vibe Coding. E o nível que utilizei não sendo o avançado, também não foi nem de longe nem de perto o básico.
Portanto, Vibe Coding requer pensamento, metodologia e trabalho. Trabalho esse que é iterativo “Prompt → Teste → Erros → Debug → Checkpoint”, nomeadamente nas fases de Teste e de Checkpoint
Agradeço à Maria Antónia Marques que fez parte do grupo de trabalho
