Criterio · Machine learning · Madrid
¿Cuándo tiene sentido usar IA?
Estudio machine learning en Madrid y una de las cosas que más me interesa es el criterio: saber cuándo un problema merece un modelo, cuándo basta una regla simple y cuándo un LLM es un gasto sin retorno. Esta página resume lo que he aprendido evaluando mis propios proyectos.
Antes de entrenar un modelo
La mayoría de los proyectos de ML fracasan antes de empezar: objetivo mal definido, datos insuficientes o una métrica que no mide lo que importa. Me lo he encontrado en mis propios proyectos, y por eso ahora empiezo siempre por la pregunta y los datos, no por el algoritmo.
Revisar modelos, empezando por los míos
Reviso mis modelos buscando fugas de datos, métricas optimistas y umbrales mal elegidos. De esa práctica salieron varias de mis herramientas open-source: splitcheck para detectar fugas entre train y test, y evalgate para bloquear en CI una evaluación que empeora.
El baseline primero
Antes de probar nada sofisticado, una regla simple o un modelo lineal marcan el listón. Si el modelo complejo no gana al baseline con una diferencia que importe, no merece la complejidad. Es la lección que más veces he tenido que reaprender.
Sin humo
A veces la respuesta es que no hace falta un LLM, o que el modelo más simple gana. Prefiero documentar eso en el README, aunque haga el proyecto menos vistoso, porque el criterio se entrena igual que los modelos: con ejemplos honestos.
¿Hablamos de criterio, datos o una oportunidad?
Todo lo que afirmo aquí se puede comprobar en el código. Si quieres discutir un caso, darme feedback o contarme una oportunidad, escríbeme.
EscríbemeFAQ
¿Cuándo merece la pena el machine learning?
Cuando hay una decisión que se repite muchas veces, datos históricos que contienen la señal para tomarla mejor, y una métrica clara de qué significa mejorar. Si falta cualquiera de las tres cosas, un modelo no arregla el problema: lo esconde.
¿Y cuándo merece la pena un LLM?
Cuando la tarea es de lenguaje y de verdad necesita comprensión o generación: resumir, extraer, responder sobre documentos. Para clasificar texto en categorías fijas, un clasificador clásico entrenado con buenos ejemplos suele ser más barato y estable. En llm-eval-harness comparo ambas cosas con números, y escribí la conclusión en el blog.
¿Cómo se detecta una evaluación inflada?
Las señales típicas: métricas demasiado buenas para el problema, preprocesado ajustado fuera del pipeline (fuga clásica), test que se parece demasiado al train (duplicados o vecinos temporales), y umbrales elegidos mirando el propio test. Mis herramientas splitcheck y dsdiff nacieron para cazar justo eso.
¿Dónde puedo ver estos criterios aplicados?
En cada proyecto de github.com/delcenjo: los READMEs documentan qué funcionó, qué no y por qué. Y en el blog de esta web escribo las lecciones generales: fugas de datos, regresión real o ruido en una eval, cuándo vale la pena un LLM.
¿Puedo comentarte un caso o pedirte opinión?
Puedes, con una condición honesta: soy estudiante, no consultor. Te diré lo que sé y lo que no. Si buscas conversación técnica, feedback mutuo o a alguien junior con este criterio para tu equipo, escríbeme por el formulario.