Cómo trabajo
Estudio en Madrid. Aprendo machine learning construyendo.
Proyectos completos, del dato crudo al modelo servido: pipelines reproducibles, APIs de inferencia, monitorización. Que nada se quede en el notebook.
Soy estudiante de inteligencia artificial y machine learning. Descubrí pronto que los cursos por sí solos no me enseñaban lo que quería saber, así que aprendo construyendo: si el modelo funciona en validación pero no sé servirlo, reentrenarlo ni monitorizarlo, todavía no lo he entendido del todo.
Con esa idea he construido, como proyectos personales, una plataforma de riesgo de crédito con calibración y umbral por coste, un transformer desde cero en PyTorch, asistentes RAG sobre documentos, agentes que escriben SQL y una suite de herramientas open-source para flujos de ML que está publicada en PyPI.
Madrid es mi base. Ahora mismo colaboro en Cylstat y sigo estudiando; me interesa cualquier sitio donde pueda aprender de gente que sabe más que yo.
No tengo un stack fijo: intento elegir la herramienta según el problema. Lo que sí procuro que sea constante es el método: entender los datos antes de modelar, evaluar sin fugas, calibrar, decidir por coste, monitorizar.
Los datos antes que el modelo. El problema antes que los datos.
De mis primeros proyectos aprendí que la mayoría fallan antes de llegar al modelo: objetivo mal definido, datos insuficientes o una métrica que no mide lo que importa. Empezar por el problema real, no por el algoritmo, es la diferencia entre un proyecto que termina y uno que no.
Intento aplicar la misma exigencia si el proyecto es un modelo de clasificación tabular, un sistema RAG sobre documentos o una API de inferencia. El dominio cambia, el rigor que persigo no.
Me apoyo en las matemáticas detrás del ML — álgebra lineal, probabilidad, optimización — y en la ingeniería que convierte un notebook en algo que se puede ejecutar dos veces. Procuro elegir lo que cada caso necesita, no lo más complejo.
Primero las matemáticas. Luego las herramientas.
Estudio con libros técnicos serios antes que con cursos de alto nivel: Mathematics for Machine Learning, Elements of Statistical Learning, Pattern Recognition and Machine Learning. Esa base importa cuando algo falla y hay que entender por qué, no solo probar hiperparámetros.
Esa forma de estudiar deja huellas: prefiero entender qué hace el modelo antes que ajustarlo a ciegas, busco la explicación más simple que sea correcta y no me da pereza descartar una arquitectura si los datos no la justifican.
Madrid y su comunidad técnica alimentan buena parte de esa curiosidad. Hay un punto de orgullo en construir algo que aguante el escrutinio de alguien que sabe más que tú.
Desplegar, no solo demos. Quiero que el modelo aguante en real.
Aprendí a programar mirando cómo funciona el código por dentro — qué hace el optimizer, cómo se propaga el gradiente, por qué el preprocesado dentro del pipeline evita las fugas. Hoy uso FastAPI, Docker, Prometheus y Grafana en mis proyectos porque quiero aprender la parte que va después del notebook, no como adornos del README.
Cuando un proyecto me pide ir más allá — CI/CD completo, registro de versiones, monitorización de drift, fine-tuning de un LLM — lo intento aunque me cueste, porque ahí es donde más aprendo. Cuando no lo pide, no lo fuerzo. La complejidad es una decisión, no una bandera.
Aprendizaje continuo. Código abierto. Criterio propio.
Contribuyo a proyectos open source — traducciones al español en HuggingFace y FastAPI, respuestas técnicas en foros de la comunidad ML, y colaboro en Cylstat. Es la forma más directa de aprender cómo se construye software serio y de devolver algo a los proyectos que uso a diario.
También publico mis propias herramientas: una suite de utilidades de línea de comandos para flujos de ML — chequeo de fugas entre train y test, conteo de tokens, gates de evaluación, serving — con tests, CI y releases en PyPI. Mantenerlas me está enseñando más que muchos cursos.
Todo mi código es público. Prefiero que cualquiera pueda mirar cómo hago las cosas y decirme dónde me equivoco: el feedback directo es la manera más rápida de mejorar que conozco.
Si quieres hablar de datos o de ML, darme feedback o contarme una oportunidad — escríbeme.
Preguntas frecuentes
Proyectos personales, construidos de principio a fin, donde los datos se usan para tomar una decisión. Modelos de clasificación y regresión para datos tabulares (riesgo de crédito, fuga de clientes), NLP con transformers (clasificación, extracción, búsqueda semántica), aplicaciones con LLMs (RAG sobre documentos, agentes SQL), y la parte MLOps de mis propios modelos: API de inferencia, versionado, CI/CD y monitorización de drift. Todo está público en GitHub, con el código, la evaluación y las partes que no funcionaron.
Estudio. Soy estudiante de inteligencia artificial y machine learning, y en paralelo colaboro en Cylstat y en proyectos open source (traducciones al español de HuggingFace y FastAPI, respuestas en foros de la comunidad). El porfolio es donde pongo en práctica lo que aprendo: si leo sobre calibración, calibro un modelo de verdad; si leo sobre drift, monto la monitorización yo mismo.
Sí. Estoy abierto a prácticas y a un primer puesto junior en datos o machine learning, en Madrid o en remoto. Lo que puedo enseñar hoy: proyectos end-to-end con el código público, una suite de herramientas CLI publicada en PyPI con tests y CI, contribuciones open source, y ganas de aprender de gente que sabe más que yo. Escríbeme por el formulario y te respondo.
Python como base. scikit-learn y PyTorch para modelar, pandas para los datos, FastAPI y Pydantic para servir, Docker y GitHub Actions para la reproducibilidad, Prometheus y Grafana para monitorizar. Para aplicaciones con LLMs: embeddings, vector stores y evaluación del propio pipeline. Dicho esto, intento no casarme con las herramientas: elige el problema, no la costumbre.
Claro. Están publicadas en PyPI e instalables con pip, con licencia MIT. Cada una hace una cosa pequeña bien: comprobar fugas entre train y test, contar tokens y estimar costes de LLM, gates de evaluación para CI, servir modelos. Si encuentras un bug o tienes una idea, abre un issue o un pull request. Ese tipo de feedback es exactamente la razón por la que las publico.
Todo está en GitHub: mis proyectos personales en github.com/delcenjo y las herramientas open-source en github.com/jmweb-org. Cada proyecto de esta web enlaza a su repositorio, y la sección Open Source documenta cada herramienta. Prefiero enseñar código antes que adjetivos: si quieres saber cómo trabajo, los repositorios responden mejor que yo.
Cinco fases, sin misterio. 1. Datos y problema — entender los datos, definir la variable objetivo y una métrica que mida lo que importa. 2. Pipeline — preprocesado dentro del pipeline, validación cruzada sin fugas. 3. Modelado y evaluación — comparación de modelos, calibración, umbral por coste, análisis de error por segmento. 4. Despliegue — API de inferencia, Docker, registro de versiones, monitorización. 5. Documentación — README con las decisiones y los resultados, para que el proyecto se pueda repetir sin mí. Es el método que me estoy enseñando a seguir en cada proyecto, precisamente porque saltarse pasos es fácil cuando nadie te lo revisa.
Por favor. El feedback sobre cualquier proyecto o herramienta es la vía más rápida que tengo para mejorar: un issue en GitHub, un pull request o un mensaje por el formulario, lo que prefieras. Para colaboraciones, me apunto a proyectos donde pueda aportar y aprender — sobre todo si tocan evaluación, calidad de datos o sacar modelos del notebook.
Porque me obliga a hacer las cosas mejor. Un notebook privado lo perdona todo; un repositorio público con tests, CI y un README que dice qué funciona y qué no, perdona bastante menos. Además permite comprobar lo que afirmo: si esta web dice que un proyecto tiene monitorización de drift, el código que lo demuestra está a un clic. Y sinceramente, el feedback que recibo al publicar es el mejor profesor que tengo.