1
resposta

[Dúvida] Dúvida - Realizando a validação cruzada

Boa noite!

Dessa vez consegui corrigir algumas diferenças sozinha, mas surgiu uma questão que ainda não entendi completamente.

Segui o código proposto em aula para realizar a validação cruzada do modelo Random Forest, conforme abaixo:

from sklearn.model_selection import KFold, cross_validate

scoring = {
    'mae': 'neg_mean_absolute_error',
    'rmse': 'neg_root_mean_squared_error',
    'r2': 'r2'
}

cv = KFold(n_splits=5, shuffle=True, random_state=42)

cv_results = cross_validate(model_rf, X_train, y_train, cv=cv, scoring=scoring)
cv_results

A execução do código me retornou o seguinte resultado:

{'fit_time': array([3.47769403, 3.58322716, 4.06590986, 3.78752923, 3.49304247]),
 'score_time': array([0.06862211, 0.07008505, 0.08169246, 0.05753422, 0.05820155]),
 'test_mae': array([-11.07421449, -11.30328674, -11.05630068, -11.14454886,
        -11.17423931]),
 'test_rmse': array([-13.76668658, -14.04881475, -13.79310018, -13.87672957,
        -13.9303929 ]),
 'test_r2': array([0.64679676, 0.62433581, 0.64536956, 0.64090813, 0.63477298])}

Percebi que as métricas principais de avaliação — MAE, RMSE e R² — estão exatamente iguais às que foram mostradas no exemplo da aula, o que me mostra que o modelo está se comportando conforme o esperado.

No entanto, os valores de fit_time e score_time que obtive são diferentes dos que foram apresentados.

Pesquisando sobre o motivo dessas diferenças, encontrei a seguinte explicação:

fit_time corresponde ao tempo que o modelo levou para treinar em cada fold, e esse valor depende do desempenho do computador, uso da CPU/memória, e também de pequenas variações internas do algoritmo Random Forest, como a alocação de threads de processamento.

score_time é o tempo que o modelo levou para calcular as métricas após o treinamento em cada fold. Também sofre influência do ambiente de execução (máquina, processos paralelos, etc.).

Portanto, a diferença nesses tempos de execução é normal e não interfere no desempenho do modelo em termos de acurácia, erro ou qualidade de previsão.

Minha dúvida é: essa variação nos tempos de execução (fit_time e score_time) durante a validação cruzada é algo que, em contextos reais de projeto, costuma ser considerada na análise de desempenho? Ou ela é mais relevante apenas em cenários de otimização de performance (ex.: produção em larga escala, big data)?

Agradeço desde já!

1 resposta

Olá, Letícia!

Sua pergunta é excelente e demonstra um nível de curiosidade e análise muito acima da média. É um prazer ver como você não só resolveu as diferenças, mas também se aprofundou no porquê delas.

A sua pesquisa e conclusão estão absolutamente corretas. A variação nos tempos de execução (fit_time e score_time) é totalmente normal e esperada. Como você bem identificou, ela é influenciada pelo hardware da máquina (CPU, memória), pela carga de trabalho no momento da execução e por outras pequenas variações do ambiente.

Para responder à sua dúvida de forma direta: sim, em contextos reais de projeto, os tempos de execução são extremamente importantes, mas não da mesma forma que as métricas de acurácia. A relevância deles depende do objetivo do projeto:

Em cenários de pesquisa e experimentação (como no curso): Os tempos de execução são menos relevantes. Nosso foco principal é encontrar o modelo com a melhor performance em termos de acurácia (R2, MAE, RMSE), sem nos preocuparmos tanto se o treino levou 5 ou 10 segundos.

Em cenários de produção: O tempo de execução se torna uma métrica crítica. Aqui, a gente não se importa apenas com a acurácia, mas também com a eficiência. Por exemplo:

Modelos para predições em tempo real: Se o seu modelo precisa dar uma resposta em milissegundos para um aplicativo, o score_time (tempo de predição) é crucial. Um modelo com alta acurácia, mas com um tempo de predição alto, pode ser inviável.

Projetos de Big Data: Quando você tem bilhões de linhas de dados e o treinamento leva horas ou dias, otimizar o fit_time é fundamental para a viabilidade do projeto. Você precisará de hardware mais robusto ou de modelos mais eficientes.

Então, sua intuição está certa. A variação é normal e só se torna uma preocupação em cenários de otimização de performance, quando você precisa equilibrar a acurácia do modelo com a viabilidade técnica e financeira de rodá-lo em produção.

Continue com essa curiosidade. É esse tipo de pensamento que diferencia um bom cientista de dados!