Skill: ml-modeling
Machine learning con generalización, no memorización.
Trigger
- Tenés datos limpios y querés entrenar un modelo
- Necesitás comparar múltiples algoritmos y elegir el mejor
- Te pidieron explicar por qué el modelo predice lo que predice
- Hay que optimizar hiperparámetros
Workflow LEND
1. ANALIZAR
├── Baseline First: modelo simple (regresión lineal / dummy classifier)
│ → Si XGBoost no le gana al baseline, no vale la complejidad
├── Validación: Stratified K-Fold Cross Validation
│ → Nada de un solo train_test_split si los datos son chicos o desbalanceados
├── Desbalanceo: ¿hay 95% clase A y 5% clase B?
│ → Accuracy miente. Usá F1-Score, Precision-Recall, AUC-ROC
└── Feature leakage: ¿alguna feature usa información del futuro?
2. OFRECER (Menú del Senior)
├── A) Modelos interpretables — regresión logística, árboles chicos, explicables
├── B) Ensembles — Random Forest, XGBoost, LightGBM, máxima performance
└── C) Auto-tuning — Optuna/Hyperopt para exprimir el rendimiento
3. ELEGIR → el usuario confirma
4. HACER
├── Split: train_test_split con stratify si es clasificación
├── Escalar: StandardScaler para modelos basados en distancias
│ Tree-based (RF, LGBM) NO necesitan escalado
├── Entrenar baseline y modelo elegido
├── Evaluar: métrica correcta según el problema
│ Clasificación balanceada → Accuracy
│ Clasificación desbalanceada → F1, Precision-Recall, AUC-ROC
│ Regresión → RMSE, MAE, R2
├── Feature importance: SHAP values (direccionalidad + magnitud)
│ feature_importances_ dice qué, SHAP dice cómo
└── Guardar modelo con joblib + documentar métricas
5. VERIFICAR
├── El modelo generaliza (CV score ≈ test score)
├── No hay overfitting (train >> test)
└── Las predicciones tienen sentido de negocio
Patrones
- Baseline siempre: un modelo simple primero te da un piso. Si lo complejo no mejora, no vale la pena.
- Stratified K-Fold: preserva proporciones de clases en cada fold. Esencial en datos desbalanceados.
- SHAP > feature_importances_: SHAP te dice dirección + magnitud por predicción individual.
- Escalar después del split: nunca
fit_transform en el set completo — filtra información del test al train.
- Optuna > GridSearch: búsqueda inteligente, no fuerza bruta. 50 trials bien orientados > 10k combinaciones al pedo.
Anti-patrones
- ❌ No hacer train/test split — evaluar en los mismos datos que entrenaste es hacer trampa
- ❌ Feature selection antes del split — perdés información de la distribución del test
- ❌ Usar Accuracy con clases desbalanceadas — 95% accuracy no es bueno si una clase tiene 5%
- ❌ GridSearch con 10^4 combinaciones — 50 búsquedas inteligentes con Optuna rinden más
- ❌ Ignorar overfitting — si train >> test, el modelo memorizó, no aprendió
- ❌ No explicar el modelo — "porque el modelo lo dice" no es una respuesta válida
Source: LeandroBenjaminL/lend-ai — distributed by TomeVault.
1---2name: leandrobenjaminl-lend-ai-ml-modeling3description: Skill: ml-modeling4---56# Skill: ml-modeling78Machine learning con generalización, no memorización.910## Trigger1112- Tenés datos limpios y querés entrenar un modelo13- Necesitás comparar múltiples algoritmos y elegir el mejor14- Te pidieron explicar por qué el modelo predice lo que predice15- Hay que optimizar hiperparámetros1617## Workflow LEND1819```201. ANALIZAR21 ├── Baseline First: modelo simple (regresión lineal / dummy classifier)22 │ → Si XGBoost no le gana al baseline, no vale la complejidad23 ├── Validación: Stratified K-Fold Cross Validation24 │ → Nada de un solo train_test_split si los datos son chicos o desbalanceados25 ├── Desbalanceo: ¿hay 95% clase A y 5% clase B?26 │ → Accuracy miente. Usá F1-Score, Precision-Recall, AUC-ROC27 └── Feature leakage: ¿alguna feature usa información del futuro?28292. OFRECER (Menú del Senior)30 ├── A) Modelos interpretables — regresión logística, árboles chicos, explicables31 ├── B) Ensembles — Random Forest, XGBoost, LightGBM, máxima performance32 └── C) Auto-tuning — Optuna/Hyperopt para exprimir el rendimiento33343. ELEGIR → el usuario confirma35364. HACER37 ├── Split: train_test_split con stratify si es clasificación38 ├── Escalar: StandardScaler para modelos basados en distancias39 │ Tree-based (RF, LGBM) NO necesitan escalado40 ├── Entrenar baseline y modelo elegido41 ├── Evaluar: métrica correcta según el problema42 │ Clasificación balanceada → Accuracy43 │ Clasificación desbalanceada → F1, Precision-Recall, AUC-ROC44 │ Regresión → RMSE, MAE, R245 ├── Feature importance: SHAP values (direccionalidad + magnitud)46 │ feature_importances_ dice qué, SHAP dice cómo47 └── Guardar modelo con joblib + documentar métricas48495. VERIFICAR50 ├── El modelo generaliza (CV score ≈ test score)51 ├── No hay overfitting (train >> test)52 └── Las predicciones tienen sentido de negocio53```5455## Patrones5657- **Baseline siempre**: un modelo simple primero te da un piso. Si lo complejo no mejora, no vale la pena.58- **Stratified K-Fold**: preserva proporciones de clases en cada fold. Esencial en datos desbalanceados.59- **SHAP > feature_importances_**: SHAP te dice dirección + magnitud por predicción individual.60- **Escalar después del split**: nunca `fit_transform` en el set completo — filtra información del test al train.61- **Optuna > GridSearch**: búsqueda inteligente, no fuerza bruta. 50 trials bien orientados > 10k combinaciones al pedo.6263## Anti-patrones6465- ❌ No hacer train/test split — evaluar en los mismos datos que entrenaste es hacer trampa66- ❌ Feature selection antes del split — perdés información de la distribución del test67- ❌ Usar Accuracy con clases desbalanceadas — 95% accuracy no es bueno si una clase tiene 5%68- ❌ GridSearch con 10^4 combinaciones — 50 búsquedas inteligentes con Optuna rinden más69- ❌ Ignorar overfitting — si train >> test, el modelo memorizó, no aprendió70- ❌ No explicar el modelo — "porque el modelo lo dice" no es una respuesta válida7172---73> Source: [LeandroBenjaminL/lend-ai](https://github.com/LeandroBenjaminL/lend-ai) — distributed by [TomeVault](https://tomevault.io).74<!-- tomevault:4.0:skill_md:2026-05-22 -->