DEV Community: Adrian

MetaCoach: generar planes de entrenamiento y nutrición a partir de tu HRV y tus analíticas

Adrian — Thu, 02 Jul 2026 10:00:03 +0000

La mayoría de planes de entrenamiento son genéricos: no saben si dormiste mal, si tu sistema nervioso está agotado o si tienes la ferritina por los suelos. MetaCoach parte de la idea contraria: adaptar el plan a tu fisiología real, medida con datos de wearable y analíticas de sangre.

El problema

Tomar señales fisiológicas heterogéneas —variabilidad de frecuencia cardíaca (HRV), sueño, pasos, frecuencia cardíaca en reposo, y valores de sangre como ferritina, hemoglobina, vitamina D, glucosa o TSH— y traducirlas en un plan semanal de entrenamiento, nutrición y suplementación que tenga sentido clínico.

La arquitectura: reglas clínicas + LLM

Decidí no dejar que el LLM interpretara los valores médicos por su cuenta —demasiado riesgo. En su lugar, un motor de reglas basadas en rangos clínicos hace el análisis fisiológico:

HRV < 30ms → estado crítico de recuperación; < 50ms → bajo.
Sueño < 5,5h → crítico; < 7h → bajo.
Ferritina, hemoglobina y vitamina D comparadas con sus rangos de referencia para detectar déficits.

El LLM (Llama 3.3 70B vía Groq) entra después: toma las conclusiones del motor de reglas y las convierte en un plan concreto y legible —7 días de entrenamiento con tipo y descripción, macros nutricionales y, si se detecta déficit, suplementación. La memoria conversacional permite seguir afinando el plan en diálogo.

Por qué reglas y no solo IA

Porque los umbrales clínicos son conocimiento establecido y determinista: no hay razón para que un modelo probabilístico los reinvente cada vez. Las reglas garantizan que "HRV de 28ms" siempre se trate como crítico. El LLM aporta la personalización y la comunicación, no el juicio médico.

Resultados de diseño

5 herramientas de análisis, 8 valores de analítica interpretados.
Plan de 7 días personalizado, generado en <2s.

Qué aprendí

El mismo principio que en BabyMind: en salud, el LLM debe orquestar y comunicar, mientras que las decisiones sensibles se anclan en reglas verificables. Es la arquitectura "neuro-simbólica" en pequeño.

Publicado originalmente en adrianmoreno-dev.com.

TutorIA: un tutor con IA que adapta el lenguaje al perfil de cada niño y recuerda entre sesiones

Adrian — Thu, 25 Jun 2026 10:00:02 +0000

La promesa de la educación personalizada es tan antigua como difícil. Un buen tutor humano adapta su forma de explicar a cada alumno: simplifica para uno, reta a otro, da estructura al que la necesita. TutorIA intenta llevar esa adaptación a una IA conversacional para niños de 6 a 14 años.

El problema

Que la explicación y los ejercicios se ajusten al perfil del alumno —rendimiento general, TDAH, dislexia— y que haya continuidad: que el tutor recuerde en qué andaba el niño la sesión anterior, sus dificultades y sus avances.

Adaptación al perfil

El perfil del alumno condiciona el prompt y la estrategia pedagógica. Para un perfil con TDAH, el tutor da instrucciones más cortas, divide las tareas y refuerza con frecuencia. Para dislexia, ajusta el lenguaje y evita muros de texto. El mismo contenido se entrega de formas distintas según quién esté al otro lado.

Memoria entre sesiones

Aquí está la diferencia con un chatbot del montón. La mayoría olvidan todo al cerrar la pestaña. TutorIA persiste el contexto del alumno entre sesiones, de modo que puede retomar donde lo dejó y construir sobre lo anterior. Esa continuidad es lo que convierte una conversación en un proceso de aprendizaje. Además, un panel de seguimiento da visibilidad a los padres.

Stack

Construido con LangChain y un LLM servido por Groq (LLaMA) para respuestas rápidas, sobre FastAPI, e integrado en el portfolio Laravel. La recuperación de material de apoyo se apoya en un esquema RAG.

Qué aprendí

Que la "personalización" real en EdTech no es cosmética (poner el nombre del niño): es adaptar la pedagogía y mantener memoria. Sin continuidad entre sesiones, no hay aprendizaje, solo respuestas sueltas.

Publicado originalmente en adrianmoreno-dev.com.

OrientaIA: diseñar un orientador vocacional conversacional para adolescentes

Adrian — Thu, 18 Jun 2026 10:00:02 +0000

La orientación vocacional clásica suele reducirse a un test de respuestas cerradas que escupe tres profesiones. Pero a los 16 años casi nadie sabe lo que quiere, y un formulario no lo descubre. OrientaIA aborda el problema desde otro ángulo: una conversación.

El problema

Ayudar a adolescentes de 14 a 18 años a descubrir itinerarios formativos y profesionales que encajen con ellos, sin que tengan que articular de antemano lo que ni ellos saben.

El enfoque: extracción conversacional

En lugar de preguntar directamente "¿qué quieres ser?", OrientaIA conduce una conversación guiada que va extrayendo, de forma indirecta, tres dimensiones: intereses (qué les engancha), valores (qué les importa) y habilidades (en qué destacan). El LLM no interroga: dialoga, y de ese diálogo infiere el perfil.

Del perfil al mapa de carreras

Con ese perfil, el sistema genera un mapa de carreras personalizado. Y añade algo que marca la diferencia frente a un test: una simulación de "un día en la vida" de cada profesión sugerida. Leer "podrías ser ingeniero ambiental" dice poco; vivir narrativamente cómo sería una jornada de esa profesión ayuda al adolescente a proyectarse de verdad.

Stack

Pipeline conversacional con LangChain y LLaMA vía Groq sobre FastAPI, con apoyo de RAG para anclar la información de itinerarios formativos reales, integrado en el portfolio Laravel.

Qué aprendí

Que los LLMs brillan precisamente en lo que los formularios hacen mal: extraer estructura de una conversación no estructurada. El reto de diseño no fue técnico, sino pedagógico: cómo guiar el diálogo para que revele el perfil sin que parezca un interrogatorio.

Publicado originalmente en adrianmoreno-dev.com.

Portfolio de IA open source: 20+ proyectos con LLMs self-hosted en producción

Adrian — Sun, 14 Jun 2026 14:16:29 +0000

Este portfolio no es una página estática con capturas de pantalla. Es una infraestructura de IA open source y self-hosted corriendo en producción: más de 20 proyectos de Machine Learning, cada uno con su demo interactiva real, sobre un único VPS. Este artículo explica cómo está montado y qué decisiones técnicas lo sostienen — porque la parte interesante no es la lista de proyectos, sino que todos funcionan a la vez sin reventar un servidor de 7,6 GB de RAM.

Por qué self-hosted y open source

La alternativa fácil era encadenar APIs de pago (OpenAI, Pinecone, servicios gestionados) y enseñar pantallazos. Pero quería demostrar algo distinto: que se puede construir IA aplicada controlando el stack completo, con costes marginales y código abierto. El repositorio del chatbot RAG es público, y cada demo es ejecutable, no un vídeo.

El stack de recuperación: RAG sin servicios gestionados

El chatbot documental usa una arquitectura RAG enteramente self-hosted:

Vector store: FAISS en disco, no una base vectorial gestionada. Índices pre-generados por idioma + índices dinámicos en RAM para los PDFs que sube el usuario.
Embeddings: intfloat/multilingual-e5-base (768 dimensiones), corriendo localmente. Se eligió la variante base sobre large tras un incidente de memoria: la calidad extra no justificaba el consumo de RAM en un servidor compartido por 20 servicios.
Reranker: cross-encoder mMiniLMv2 para reordenar los candidatos antes de pasarlos al LLM.
LLM: Groq (Llama 3.1/3.3) como motor principal, con Ollama local como alternativa. El failover entre ambos es automático.

El resultado: un pipeline de recuperación que no depende de ninguna factura mensual por consultas vectoriales.

20+ servicios FastAPI en un solo VPS

Cada proyecto de ML es un proceso FastAPI independiente en su propio puerto, con su propio modelo y artefactos. Predicción de precio inmobiliario, calidad del aire, detección de fraude, separación de pistas musicales, detección de alergias felinas por visión por computador… cada uno aislado, cada uno desplegado como servicio systemd.

El problema obvio: 20 modelos cargados en memoria a la vez no caben. La solución fue un sistema lazy-load: las demos pesadas están detenidas por defecto y arrancan on-demand cuando un visitante pulsa "Activar demo", apagándose solas tras 30 minutos sin tráfico. Eso liberó ~2 GB de RAM y permite que el portfolio entero conviva en una máquina modesta.

NeuralOps: el sistema multi-agente que lo mantiene vivo

La pieza que más disfruto: el portfolio se mantiene, promociona y mejora a sí mismo mediante un sistema de agentes autónomos. Monitores que vigilan latencia y reinician servicios caídos, un reparador de errores que escala a GitHub Issues lo que no puede arreglar solo, agentes de contenido que sindican los artículos del blog, y un ecosistema "darwiniano" donde cada agente acumula una puntuación de rendimiento y los mejores se reproducen con mutaciones de sus parámetros.

Todo corre con el mismo principio de coste marginal: razonamiento en Groq cuando importa la calidad, modelo local para las tareas baratas, y timers de systemd en lugar de procesos residentes para no malgastar RAM.

El frontend

Laravel + MySQL para la capa web, nginx con HTTPS, Tailwind compilado y auto-alojado (sin CDN). Cada proyecto tiene su ficha, su demo y su artículo técnico en este blog explicando las decisiones reales: qué arquitectura elegí, qué descarté y qué métricas conseguí.

Qué puedes mirar

Si te interesa la IA aplicada construida sin atajos de pago: explora las demos, lee el resto de artículos técnicos donde detallo cada proyecto, o revisa el código del chatbot RAG en GitHub. Todo lo que se describe aquí está funcionando ahora mismo en producción.

Publicado originalmente en adrianmoreno-dev.com.

Generador de imágenes con FLUX.1-schnell: text-to-image en producción

Adrian — Sun, 14 Jun 2026 11:33:05 +0000

Este proyecto nació de una necesidad propia: generar las imágenes de portada de los demás proyectos del portfolio con un estilo coherente, sin depender de bancos de imágenes ni de herramientas de pago. La solución fue desplegar mi propio generador text-to-image.

El modelo: por qué FLUX.1-schnell

La familia FLUX.1 es de lo mejor que hay hoy en generación de imágenes abierta. Elegí la variante schnell ("rápido" en alemán) por una razón práctica: está destilada para generar en muy pocos pasos de difusión, lo que la hace mucho más ligera y veloz que las variantes de máxima calidad. En un portfolio que corre sobre recursos modestos, esa diferencia entre "tarda 3 segundos" y "tarda un minuto" es la diferencia entre una demo usable y una que nadie espera.

Estilos predefinidos

Para mantener coherencia visual, el generador ofrece estilos predefinidos orientados a categorías (tech, educación, finanzas, IA). Detrás, cada estilo es esencialmente un prompt template cuidado que envuelve la petición del usuario con los modificadores adecuados de composición, paleta y acabado. Es una capa fina pero muy efectiva: convierte un prompt mediocre del usuario en uno bueno.

Arquitectura

El modelo se sirve desde el ecosistema HuggingFace a través de una API FastAPI, con post-procesado de imagen vía Pillow y descarga directa en PNG, integrado en el frontend Laravel.

Una reflexión sobre los modelos de difusión

Un modelo de difusión genera partiendo de ruido puro y "quitándolo" iterativamente hasta revelar una imagen coherente con el texto. Las variantes destiladas como schnell comprimen ese proceso de decenas de pasos a unos pocos, sacrificando algo de fidelidad a cambio de velocidad. Para iconografía y portadas, ese intercambio es claramente favorable.

Qué aprendí

Que "usar el mejor modelo" no siempre es la decisión correcta: el mejor modelo para tu contexto tiene en cuenta la latencia, los recursos y el uso real. Y que una buena capa de prompt templating aporta más calidad percibida que saltar a un modelo más pesado.

Publicado originalmente en adrianmoreno-dev.com.