¿Y si el cuento de la GPU solo está frenando tu proyecto de ML, mientras unos árboles de gradiente en tu laptop lo superan calladitos?
Eres un practicante de ML en solitario, metido en un equipo que ve el ‘machine learning’ como polvo de hadas mágico. Sin clúster. Sin mina de datos etiquetados. Solo un mandato vago de “haz ML”, un tier gratis en la nube y colegas que confunden pandas con animales salvajes. Hacer ML a oscuras no es glamoroso: es pura supervivencia. Y aquí va el cambio de arquitectura: no se trata de escalar hacia arriba, sino de recortar sin piedad hasta lo que se despliega.
Los datos malos no son tu peor problema. Definir bien el problema sí lo es. Arréglalo primero, o nada importa.
Esa es la verdad cruda desde las trincheras. La mayoría de guías asumen que tienes recursos. Esta es para lanzar antes de que se evapore el interés.
Restricciones: ¿Cuáles murallas son de papel?
El cómputo parece un muro de ladrillos… hasta que lo auditas. ¿Datos tabulares a escala? Menos de 10 millones de filas, 1000 features? XGBoost en un solo núcleo de CPU aplasta al deep learning y entrena en minutos. ¿Embeddings? Los tiers gratis de la nube manejan cargas MVP. ¿LLMs? Las llamadas a la API de gpt-4o-mini son baratísimas por inferencia.
Territorio solo para GPU: entrenar transformers desde cero. Raro para solteros. Si es lo tuyo, pilla Colab Pro o un spot instance. Si no, “no tengo GPU” solo tapa al verdadero enemigo: un problema mal planteado.
¿Datos? Claro, son un lío: etiquetas inconsistentes, logs que no cuadran con lo que necesitas. No es volumen, es calidad. Arréglalo hackeando proxies o etiquetas sintéticas desde el principio.
¿Ingeniería? El asesino silencioso. Los modelos se pudren sin monitoreo. Limítate a lo que puedas mantener solo, o soborna a un dev de una.
Aquí va una idea que el original se salta: esto es como los coders de garaje en los 80, armando imperios en Commodores mientras los VC financiaban fracasos. El ML en solitario no es una desventaja; es la forja lean para victorias asimétricas.
¿Por qué armar el Eval Harness primero? Siempre
Los notebooks mienten. Te venden “90% de accuracy” en datos de juguete y luego la cagan en prod.
Disciplina: codifica la evaluación antes de entrenar. Aquí el snippet que me lo cambió todo: flexible, sirve desde heurísticas hasta LLMs:
def evaluate( predict_fn: Callable, test_df: pd.DataFrame, label_col: str = "label", threshold: float = 0.5 ) -> dict: """Minimal <a href="/tag/evaluation-harness/">evaluation harness</a>..."""
Pásale cualquier predictor. Empieza con una heurística tonta: random, basada en reglas. ¿La superas? Progreso. ¿No? Cambia de rumbo.
Esto invierte la arquitectura: la eval como estrella polar, el modelo como hipótesis. Adiós a las fosas de notebooks.
¿Se puede dejar la GPU de lado de verdad?
Respuesta corta: para el 90% de ML que se despliega, sí.
La canción de sirena del deep learning es excesiva para la mayoría de problemas de negocio. ¿Detección de fraude? Árboles. ¿Predicción de churn? Regresión logística. ¿Recomendaciones? Factorización de matrices en CPU.
Cuándo brillan las GPUs: visión a escala, ajustes finos en NLP. Pero los solteros triunfan con el modelo más pequeño desplegable. Cuantiza. Destila. Sirve vía FastAPI en una instancia de $5.
Guión para presionar a los jefes: “¿Pides GPU? Muéstrame primero la baseline de eval.” Fuerza claridad.
Definición del problema: El guardián poco sexy
Mandatos vagos matan más rápido que datos malos. “Mejora el forecasting”? No. “Reduce el MAPE un 20% en ventas del próximo trimestre, usando transacciones logueadas.”
Truco: co-crea una métrica con los stakeholders. Átala a algo que mueva la aguja del negocio. ¿Sin buy-in? Sal corriendo.
Algunos “ML” gritan heurísticas: umbrales simples superan a las redes neuronales, cero drift. Rechaza la trampa brillante.
