brunovilar / desafio-data-science-elo7 Goto Github PK

Apesar de o projeto ter uma versão inical entregável, os modelos criados continuam sendo os criados e avaliados usando cross-validation. É interessante criar a versão final do modelo, criada com os dados completos de treinamento e fazer a avaliação final usando os dados de teste.

Uma possibilidade interessante para melhorar a confiança sobre os resultados é usar o Nested Cross Validatio, conforme:

• https://arxiv.org/abs/2104.00673
• https://towardsdatascience.com/your-cross-validation-error-confidence-intervals-are-wrong-heres-how-to-fix-them-abbfe28d390

A identificação do vendedor (seller_id) não é usada atualmente no projeto. Entretando, é possível que alguns vendedores tenham um perfil mais especializado em categorias de produtos, como pessoas que trabalham especificamente com bijuterias ou decoração. Em alguns casos, mesmo que o vendedor trabalhe com múltiplas categorias, é provável que elas sejam relacionadas. Assim, pode compensar utilizar algo como um OHE para as categorias do vendedor. Para os dados completos, a criação de um modelo de embedding poderia ser útil sem aumentar muito a dimensionalidade dos dados.

Como o projeto foi criado se aproximando de uma prova de conceito, alguns cuidados relevantes não foram tomados. Testes unitários são um deles. É preciso fazer a criação dos testes, sobretudo para as funções desenvolvidas em pipeline, para garantir o correto funcionamento do código e poder evoluir o projeto garantindo que não ocorram erros não aparentes.

O modelo de classificação de categorias é baseado em dois atributos: título e peso. Isto, para simplificar a criação e permitir o uso para a predição da categoria de busca, como se ela fosse um produto.

Para avaliar se o uso de outros atributos (e.g., preço, tags concatenadas e perfil de vendas do vendedor) trariam contribuições, é interessante fazer novos experimentos. Caso a melhoria seja relevante, é preciso lidar com a necessidade de uso para a classificação de categoria. Algumas possibilidades são:

• Ter um modelo simples e um complexo para classificar categorias. O simples poderia ser usado para a classificação da busca e, também, ter seu resultado usado como entrada para o modelo complexo, criando um ensemble.
• Usar uma segmentação maior dos produtos para estabelecer valores médios das características de cada segmento de produto.

Atualmente o projeto faz a segmentação de produtos com o uso de Gaussian Mixture Model e 50 clusters. É interessante analisar melhor os critérios para determinar o número de cluster e analisar formas alternativas de fazer o agrupamento. Algumas possibilidades:

• LDA
• DBScan

Ainda que seja uma prova de conceito, é interessante melhorar a capacidade do sistema de realizar uma busca ou recomendação de forma mais eficiente, reduzindo o tempo de resposta. Para isso, é interessante usar algum sistema que permita a comparação de embeddings, como:

• Faiss
• Haystack
• Sklearn BallTree ou KDTree

També é possível focar apenas na paralelização do processo, seja de modo mais artesanal, como por Joblib, ou automática, como pelo Dask ou Vaex ou similar.

Como a CLI é a representação do uso do modelo em produção, é preciso tomar cuidados adicionais para garantir que os dados de entrada estejam sendo corretamente fornecidos. Para isso, é possível usar uma ou mais técnicas de validação:

• JSON Validate: estabelecer um esquema e validar a adequação do JSON de entrada a esse esquema;
• Pydantic/Marshmallow: estabelecer regras de validação (especialmente relacionadas a dataclass) e validá-las ao fazer a conversão de JSON para um objeto Python.

O projeto usa estatísticas sobre todos os produtos (e.g., média, mediana e desvio padrão) para fazer o preenchimento de atributos não preenchidos. Como não é possível usar a categoria para fazer a segmentação desses produtos, por ser o rótulo do modelo supervisionado, é preciso criar uma segmentação alternativa. Algumas opções para isso:

• Usar o modelo de agrupamento, criado a partir dos embeddings de títulos de produtos, para fazer a segmentação.
• Criar um modelo KNN para estimar valores a partir dos produtos mais similares.

Para aproximar o projeto de uma solução realmente produtizada e final, é importante incorporar um mecanismo de registro de logs, com diferentes níveis de informação, para ajudar a registrar interações com o sistema e, quando necessário, identificar problemas. Por ser uma prova de conceito, o registro dos logs em arquivo deve ser o suficiente.