DEV Community: Adrian

Detección de fraude: por qué el AUC-ROC engaña y el AUC-PR no (datos reales)

Adrian — Thu, 24 Sep 2026 10:00:02 +0000

En detección de fraude hay una trampa estadística que infla currículums: el AUC-ROC. Sobre datos extremadamente desbalanceados es fácil presumir de un 0.99 que no significa casi nada. Este proyecto está construido alrededor de la métrica que sí importa —el AUC-PR— y de no esconder los fallos del modelo.

El problema

El objetivo: marcar transacciones fraudulentas en tiempo real y, sobre todo, de forma honesta y explicable. Un analista necesita saber por qué se marca una operación, no un número opaco.

Los datos: ULB, reales y brutalmente desbalanceados

Entrené sobre el dataset ULB Credit Card Fraud Detection: 284.807 transacciones reales de tarjetas europeas, con features anonimizadas por PCA (V1–V28) más importe y tiempo. El detalle clave es el desbalanceo: solo el 0,17% son fraude (unas 492 de 284.807). Esa rareza es justo lo que hace difícil —y honesto— el problema.

Por qué el AUC-ROC engaña (y el AUC-PR no)

Sobre datos tan desbalanceados, el AUC-ROC sale altísimo casi sin esfuerzo (aquí ~0,91) porque premia clasificar bien la clase mayoritaria, que es trivial. El AUC-PR (precisión-recall) cuenta la verdad: mi modelo logra 0,67 frente a un baseline de 0,0012 — es decir, ~550× mejor que el azar en lo que de verdad cuesta. Por eso la demo muestra el AUC-PR, no el ROC inflado.

El modelo

Un clasificador LightGBM con scale_pos_weight para penalizar más los errores sobre la clase fraude, hiperparámetros buscados con Optuna y umbral de decisión calibrado (0,9) para equilibrar precisión y recall según el coste real de cada error.

Resultados (honestos)

AUC-PR: 0,67 (baseline 0,0012 → ~550× sobre el azar) — la métrica que importa.
AUC-ROC: 0,91 — alto, pero engañoso en desbalanceo; lo reporto solo para contraste.
Precisión 0,88 · Recall 0,71 · F1 0,79 · MCC 0,79 sobre el fraude real.

No hay 0,99 de fantasía: el modelo acierta mucho y falla algo, y la demo lo enseña tal cual.

Explicabilidad con SHAP

Cada predicción se acompaña de un desglose SHAP: cuánto empujó cada feature (V11, importe, etc.) hacia "fraude" o "legítimo". Eso convierte el modelo en una herramienta que un equipo humano puede auditar.

Qué aprendí

Que en problemas desbalanceados elegir bien la métrica es un acto de honestidad. Es fácil publicar un AUC-ROC de 0,99 y parecer un genio; es más útil —y más honrado— reportar el AUC-PR real y explicar por qué. Un modelo que conoce y muestra sus límites vale más que uno que presume de una cifra vacía.

Publicado originalmente en adrianmoreno-dev.com.

Detectar volatilidad anómala en los mercados con un Temporal Fusion Transformer

Adrian — Thu, 17 Sep 2026 10:00:02 +0000

Predecir el precio de una acción es casi imposible y, francamente, poco útil. Hay una pregunta más alcanzable y más valiosa: ¿cuándo está a punto de volverse anormalmente inestable un activo? Los picos de volatilidad suelen preceder a las noticias, no seguirlas. Ese era el objetivo de este "sensor de mercado".

El problema

En lugar de estimar un único número (el retorno esperado), quería estimar la distribución completa de retornos para cada activo y horizonte, y marcar como anómalos los momentos en los que la realidad se sale de los cuantiles que el modelo considera plausibles.

La arquitectura: TFT + regresión cuantílica

Elegí el Temporal Fusion Transformer porque combina tres cosas que necesitaba:

Variable Selection Networks que aprenden qué inputs importan en cada momento, dándome interpretabilidad sin renunciar a la potencia.
Atención multi-cabeza sobre la ventana temporal, que captura dependencias largas (un patrón de hace semanas) mejor que una LSTM.
Salida de regresión cuantílica: en vez de un valor, predice varios cuantiles (p10, p50, p90...). La distancia entre cuantiles es la incertidumbre estimada.

Cuando un retorno real cae fuera del intervalo cuantílico esperado, salta la alerta de anomalía.

La métrica que de verdad valida el modelo

Un modelo cuantílico solo sirve si está bien calibrado: si dice que algo ocurre el 90% de las veces, debe ocurrir el 90% de las veces. La calibración cuantílica de este modelo resultó prácticamente perfecta, lo que significa que sus intervalos de incertidumbre son fiables, no decorativos.

Resultados

F1-score (detección de anomalías): 0.82
MCC: 0.80
Calibración cuantílica: ≈ perfecta

Qué aprendí

Que reformular el problema —de "predecir el precio" a "predecir la incertidumbre"— lo vuelve tratable y útil. Y que en finanzas, un modelo que conoce sus propios límites (su calibración) vale más que uno que da respuestas precisas y falsas.

Publicado originalmente en adrianmoreno-dev.com.

Regímenes de mercado con Hidden Markov Models: un score de riesgo que bate al buy-and-hold

Adrian — Thu, 10 Sep 2026 10:00:02 +0000

Los mercados no se comportan igual todo el tiempo. Hay periodos de calma alcista, periodos neutrales y periodos de pánico. El problema es que ese "régimen" es un estado oculto: no viene etiquetado en los datos, solo lo intuimos por cómo se comportan los retornos y la volatilidad. Es el escenario perfecto para un Hidden Markov Model.

El problema

Quería un score de riesgo en tiempo real que no se limitara a mirar la volatilidad pasada, sino que identificara en qué régimen está el mercado ahora y ajustara la exposición en consecuencia.

La arquitectura: Gaussian HMM

Entrené un GaussianHMM (con hmmlearn) sobre 5 años de datos reales de cinco activos representativos: SPY, IBEX35, STOXX50E, TLT (bonos) y GLD (oro). El modelo asume que en cada momento el mercado está en uno de 3 estados ocultos —Bull, Neutral, Bear— y que los retornos observados se generan a partir de una gaussiana distinta según el estado. El algoritmo de Baum-Welch aprende las matrices de transición y las distribuciones de emisión sin que yo etiquete nada.

Del régimen a la decisión

Una vez el modelo infiere el régimen actual (vía el algoritmo de Viterbi/forward), la estrategia ajusta la exposición: plena en Bull, reducida en Neutral, defensiva en Bear. Sobre esa base calculo además VaR al 95%, Sortino y un score de riesgo normalizado de 0 a 100.

Resultados (HMM vs. buy-and-hold)

Sharpe: 2.12 frente a 1.11 del comprar-y-mantener.
CVaR (riesgo de cola): reducido un 32%.
Máximo drawdown: de -21,9% a -7,5%.

Lo interesante no es solo el mayor Sharpe, sino la brutal reducción del drawdown: el modelo se sale a tiempo de los regímenes bajistas.

Qué aprendí

Que los modelos de estados latentes son una forma honesta de capturar algo que los traders saben intuitivamente —"esto ha cambiado de tono"— sin caer en el sobreajuste de intentar predecir el precio exacto. El HMM no adivina el futuro; reconoce el presente mejor que la media móvil.

Publicado originalmente en adrianmoreno-dev.com.

Value Betting Engine: del modelo de probabilidad a la apuesta de valor con el criterio de Kelly

Adrian — Thu, 03 Sep 2026 10:00:03 +0000

Hay un malentendido fundamental sobre las apuestas deportivas: la gente cree que se trata de acertar quién gana. No es así. Se trata de encontrar situaciones en las que la cuota del mercado está equivocada respecto a la probabilidad real. Eso es el value betting, y es matemáticamente idéntico a buscar activos infravalorados en bolsa.

El problema

Necesitaba dos cosas: (1) una estimación propia y fiable de la probabilidad de cada resultado, y (2) una forma de compararla con las cuotas del mercado para detectar valor y dimensionar la apuesta sin arruinarme.

La probabilidad: reutilizar el Sports Engine

Las probabilidades vienen del modelo del Sports Performance Engine (ensemble LightGBM + XGBoost sobre datos StatsBomb). Reutilizar ese motor fue una decisión de arquitectura: un buen modelo de predicción deportiva es la base sobre la que se construye el value betting.

Detectar valor: EV > 0

Para cada mercado consulto las cuotas de más de 350 casas vía OddsPapi. La señal de valor es simple pero implacable: el valor esperado de la apuesta, EV = p · (cuota − 1) − (1 − p), donde p es mi probabilidad estimada. Solo entran las apuestas con EV positivo: aquellas donde el mercado paga más de lo que el riesgo justifica.

Dimensionar: el criterio de Kelly

Detectar valor no basta; hay que decidir cuánto apostar. El criterio de Kelly da la fracción del capital que maximiza el crecimiento geométrico a largo plazo: f = (p · b − q) / b. En la práctica uso un Kelly fraccional (una fracción de lo que recomienda) porque el Kelly puro es demasiado agresivo y muy sensible a errores en la estimación de p.

Validación: backtesting 2022–2024

Toda la lógica se validó con backtesting sobre datos de 2022 a 2024, simulando el bankroll a lo largo del tiempo para comprobar que la estrategia sobrevive a las rachas malas —que las hay, incluso con EV positivo.

Qué aprendí

Que la gestión del riesgo (Kelly) es tan importante como la detección de la oportunidad (EV). Un buen modelo con mal sizing quiebra; un modelo modesto con sizing disciplinado sobrevive. La misma lección que en cualquier mesa de trading.

Publicado originalmente en adrianmoreno-dev.com.

Sports Performance Engine: predecir fútbol con datos StatsBomb y un ensemble LightGBM+XGBoost

Adrian — Thu, 27 Aug 2026 10:00:02 +0000

El fútbol es uno de los deportes más difíciles de predecir: tiene pocos goles, mucho azar y un equipo inferior gana con sorprendente frecuencia. Eso lo convierte en un banco de pruebas honesto para el machine learning, porque no puedes esconderte detrás de métricas infladas.

Los datos: StatsBomb

Usé los datos abiertos de StatsBomb (vía statsbombpy), que van mucho más allá del marcador: eventos por partido, posición de cada acción, expected goals (xG), presiones, pases progresivos. Cuando faltaban datos, completé con un generador sintético calibrado de partidos de LaLiga y Champions, hasta unos 3.200 partidos analizados.

Feature engineering: el corazón del proyecto

El modelo no mira un partido aislado, sino la forma reciente de cada equipo. Construí features rolling: medias móviles de xG a favor y en contra, de presiones, de rendimiento, en ventanas de los últimos N partidos. Esto captura "este equipo llega en racha" sin que el modelo haga trampa mirando el futuro.

Validación: TimeSeriesSplit, no K-Fold

Este es el error más común en ML deportivo y financiero: usar validación cruzada aleatoria. Si entrenas con partidos de mayo y validas con partidos de enero, estás filtrando el futuro. Usé TimeSeriesSplit (división temporal 70/15/15), de modo que el modelo siempre se evalúa sobre partidos posteriores a los de entrenamiento.

El modelo: ensemble + Optuna

Combiné LightGBM y XGBoost en un ensemble —dos implementaciones de gradient boosting con sesgos ligeramente distintos cuyas predicciones promediadas generalizan mejor— con hiperparámetros buscados por Optuna (30+25 trials).

Resultados

AUC-ROC: 0.71 — un número modesto en apariencia, pero realista para fútbol; desconfía de cualquiera que te prometa 0.95 prediciendo resultados de fútbol.
3.200 partidos analizados, 25+ features.
Explicabilidad SHAP por predicción.

Qué aprendí

Que un AUC de 0.71 honesto vale más que un 0.95 fruto de fugas de datos. La integridad de la validación temporal es lo que separa un modelo que funciona en producción de uno que solo brilla en el notebook.

Publicado originalmente en adrianmoreno-dev.com.

Predicción de precio inmobiliario: por qué un ensemble GBM + red neuronal bate a cualquiera por separado

Adrian — Thu, 20 Aug 2026 10:00:02 +0000

El precio de una vivienda depende de factores que se comportan de formas muy distintas. Algunos son cuasi-reglas ("más de 3 baños dispara el precio en esta zona"); otros son interacciones suaves y continuas (la relación entre metros, antigüedad y barrio). Ningún tipo de modelo captura bien ambas cosas a la vez. Por eso usé un ensemble.

El problema

Estimar el precio de mercado de una vivienda a partir de sus características, con un error lo bastante bajo como para ser útil en una valoración real, y exponerlo como una API de predicción en tiempo real.

Los dos modelos del ensemble

Gradient Boosting Machine: excelente capturando relaciones no lineales y "reglas" abruptas sobre datos tabulares. Es el caballo de batalla de los datos estructurados.
Perceptrón multicapa (MLP): una red neuronal que modela bien las interacciones suaves y continuas entre variables, algo donde los árboles, por su naturaleza escalonada, son más toscos.

Las predicciones de ambos se combinan. El ensemble funciona porque sus errores están poco correlacionados: donde uno falla por su sesgo, el otro tiende a compensar.

Decisiones técnicas

El preprocesado trató con cuidado las variables sesgadas (el precio y la superficie se distribuyen log-normalmente, no normalmente) y las categóricas de localización. El stack es scikit-learn para el GBM y PyTorch para el MLP, servido todo con FastAPI.

Resultados

R² ≈ 0.90: el modelo explica alrededor del 90% de la varianza del precio.
MAE ≈ ±$62K: error medio absoluto.
~11% de error porcentual relativo.

Qué aprendí

Que el ensembling no es hacer trampa: es reconocer que distintos modelos tienen distintos puntos ciegos, y que combinarlos es casi siempre más robusto que pelearse por exprimir el último 0,5% de un único modelo.

Publicado originalmente en adrianmoreno-dev.com.

Un chatbot RAG multilingüe sobre tus PDFs con FAISS y reranking (coste de búsqueda: 0 €)

Adrian — Thu, 13 Aug 2026 10:00:03 +0000

En un sistema RAG (Retrieval-Augmented Generation), todo el mundo se fija en el LLM. Es un error. La calidad de las respuestas depende muchísimo más de qué fragmentos recuperas que del modelo que los redacta. Si recuperas el contexto equivocado, el mejor LLM del mundo te dará una respuesta equivocada con total seguridad.

El problema

Construir un asistente que responda preguntas sobre documentos PDF —manuales, normativas, catálogos— en varios idiomas, con respuestas fundamentadas en el documento y no inventadas, y a coste de infraestructura cercano a cero.

El pipeline de recuperación (donde está el truco)

Embeddings multilingües: uso intfloat/multilingual-e5-large para vectorizar los fragmentos. El modelo entiende que "precio" y "price" están cerca en el espacio vectorial, lo que da soporte multilingüe de serie.
Búsqueda vectorial con FAISS: los vectores se indexan en FAISS, la librería de Facebook para búsqueda de similitud. Corre en CPU, en local, sin servicios gestionados: de ahí el coste de búsqueda de 0 €. Los índices estáticos se pre-generan por idioma; los PDFs que sube el usuario se indexan en RAM por sesión.
Reranking con cross-encoder: la búsqueda vectorial es rápida pero imprecisa. Por eso añado un segundo paso: un cross-encoder (mmarco-mMiniLMv2) que re-puntúa los candidatos leyendo pregunta y fragmento juntos. Es más lento, pero solo se aplica a un puñado de candidatos, y mejora drásticamente la precisión del contexto.

La generación

Solo entonces entra el LLM (Llama vía Groq, por su latencia bajísima), que redacta la respuesta a partir del contexto ya filtrado. El resultado: respuesta media por debajo de 3 segundos.

De demo a producto: SaaS multi-tenant

Por encima del motor RAG monté una capa SaaS multi-tenant con SQLite: clientes, planes (free/basic/pro/enterprise), autenticación por X-API-Key y registro de consumo de tokens con límites por plan. Lo que empezó como una demo es, en arquitectura, un producto.

Qué aprendí

Que la frase "RAG es solo meter documentos en un LLM" es engañosa. El valor está en el pipeline de recuperación —embeddings + búsqueda + reranking— y en hacerlo barato y rápido. El LLM es la última milla, no el motor.

Publicado originalmente en adrianmoreno-dev.com.

FeliniAI: un triple pipeline (visión + clínico + LLM) para detectar alergias felinas con F1 0.97

Adrian — Thu, 06 Aug 2026 10:00:02 +0000

Cuando el objetivo es algo tan delicado como un diagnóstico asistido, confiar en un único modelo es arriesgado. FeliniAI usa tres pipelines complementarios que se refuerzan entre sí, igual que un veterinario combina lo que ve, lo que mide y lo que sabe.

Pipeline 1 — Visión: MobileNetV2

Una CNN MobileNetV2 (PyTorch, transfer learning) clasifica imágenes de la piel/pelaje del gato en categorías visuales. Elegí MobileNetV2 por su equilibrio entre precisión y ligereza: corre rápido en CPU, lo que mantiene la inferencia por debajo de 1 segundo. Alcanza un 93,4% de accuracy visual.

Pipeline 2 — Clínico: XGBoost + ICADA

El núcleo del sistema es un clasificador XGBoost que trabaja sobre 33 features clínicas derivadas de los criterios ICADA (los criterios estandarizados de dermatitis atópica felina): estacionalidad, distribución de las lesiones, prurito, respuesta a tratamientos previos. Sobre un dataset de 8.000 casos, este módulo logra un F1 macro de 0.9675 en validación cruzada 5-fold. La búsqueda de hiperparámetros se hizo con Optuna y la explicabilidad con SHAP.

Pipeline 3 — LLM: la síntesis

Finalmente, un LLM (Llama 3.3 70B vía Groq) integra las salidas de los dos modelos anteriores y las traduce en una recomendación legible: qué tipo de alergia es más probable, con qué confianza y qué pasos sugerir. El LLM no diagnostica solo: orquesta y comunica lo que han calculado los modelos especializados.

Por qué tres pipelines y no uno

Porque cada uno cubre el punto ciego del otro. La visión capta lo que una foto muestra pero un cuestionario no; el modelo clínico capta el historial que una foto no puede mostrar; el LLM convierte ambos en algo accionable. Es un patrón de ensemble heterogéneo aplicado a datos de naturaleza distinta.

Resultados

F1 macro (clínico): 0.9675, accuracy 0.9909.
Accuracy visual: 93,4%.
4 tipos de alergia, 33 features clínicas, <1s de inferencia.

Qué aprendí

Que en dominios sensibles, la arquitectura correcta no es "el modelo más grande", sino varios modelos especializados orquestados, cada uno haciendo aquello en lo que es bueno.

Publicado originalmente en adrianmoreno-dev.com.

Separar canciones en stems con HTDemucs v4 en un servidor con poca RAM

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

La separación de fuentes musicales —descomponer una canción mezclada en sus pistas individuales— parecía ciencia ficción hace pocos años. Hoy, modelos como HTDemucs lo hacen sorprendentemente bien. El reto de este proyecto no fue el modelo, sino ponerlo a funcionar en un servidor modesto, sin GPU.

El problema

Separar cualquier canción en 4 stems (voces, batería, bajo y melodía) y permitir remezclarla en el navegador. Todo ello en una máquina con CPU y RAM limitada, donde un proceso descuidado tumba el servidor.

El modelo: HTDemucs v4

Uso HTDemucs v4 (variante htdemucs_ft), un modelo híbrido transformer/convolucional que opera tanto en el dominio de la forma de onda como en el espectrograma. Es el estado del arte abierto en separación de fuentes, con licencia MIT.

Las dos decisiones de ingeniería que lo hacen viable

Segmentación (--segment 5): procesar una canción entera de golpe dispara el uso de memoria. Trocear el audio en segmentos cortos mantiene el pico de RAM bajo control, a costa de algo más de tiempo. Sin esto, el proceso muere por OOM.
Procesado asíncrono: la separación tarda decenas de segundos. Bloquear la petición HTTP sería inaceptable, así que el trabajo se encola y procesa en segundo plano (sin necesidad de Celery: una solución asíncrona ligera), y el frontend consulta el progreso.

El frontend usa WaveSurfer.js para visualizar las ondas y la Web Audio API para la remezcla en tiempo real: ajustar el volumen de cada stem, silenciar la voz para hacer karaoke, etc.

Detalle de despliegue

El modelo (~400 MB) se descarga en el primer uso. El servicio corre con límites de memoria de systemd y, como otras demos pesadas del portfolio, arranca bajo demanda y se apaga tras un periodo de inactividad para no malgastar RAM.

Qué aprendí

Que desplegar IA en hardware limitado es una disciplina en sí misma. El modelo es solo el principio; la segmentación, el procesado asíncrono y la gestión de memoria son lo que separa una demo que funciona de una que tumba el servidor.

Publicado originalmente en adrianmoreno-dev.com.

Construir un SDK de música adaptativa para juegos con la Web Audio API

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

En los grandes juegos, la música cambia de forma fluida según lo que ocurre: explorar, combatir, ganar. Esa "música adaptativa" suele requerir middleware caro y complejo (FMOD, Wwise). Quise llevar esa capacidad a los desarrolladores indie de juegos web, con un SDK que se integre en menos de 10 líneas.

El problema

Cambiar de pista musical en respuesta al estado del juego sin que se note el corte. Un crossfade ingenuo suena fatal porque rompe el compás; la transición debe ocurrir en el momento musical correcto.

La arquitectura: capas + crossfade al beat

El SDK gestiona varias capas musicales (town, explore, combat, victory) que comparten tempo. Cuando el juego pide cambiar de estado, el motor no corta de golpe: programa un crossfade sincronizado al beat usando el reloj de alta precisión de la Web Audio API. Las transiciones esperan al siguiente tiempo musical, de modo que el cambio suena intencionado, no accidental. La latencia percibida del crossfade es prácticamente nula.

Stack

Está escrito en TypeScript sobre Tone.js (que abstrae el scheduling de la Web Audio API), empaquetado con tsup en formatos ESM y CJS para que funcione en cualquier proyecto moderno. La demo es un mini-RPG en Phaser 3 donde la banda sonora cambia al entrar en combate.

Diseño de API: la obsesión por la simplicidad

La métrica de éxito de un SDK no es su potencia, sino lo poco que tienes que escribir para usarlo. El objetivo de diseño fue que añadir música adaptativa cueste 5 líneas: instanciar el motor, registrar las capas y llamar a setState('combat'). Todo lo complejo —el scheduling, el crossfade, la sincronía— queda escondido.

Qué aprendí

Que escribir una librería para otros desarrolladores es un ejercicio de empatía: cada decisión de API es un compromiso entre flexibilidad y simplicidad. Y que el audio en el navegador, con su reloj propio, exige pensar el tiempo de otra manera.

Publicado originalmente en adrianmoreno-dev.com.

RoomCraft AI: optimizar la distribución de una habitación con Simulated Annealing

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

Colocar los muebles de una habitación es un problema de optimización con muchas restricciones: la cama no va delante de la puerta, el escritorio quiere luz natural, hay que poder circular. Hay un número enorme de disposiciones posibles. RoomCraft AI las explora automáticamente a partir de una descripción en lenguaje natural.

El pipeline de tres etapas

Parser con LLM: el usuario describe su habitación en texto libre ("un dormitorio de 4x3 con la puerta al norte y una ventana al este"). Un LLM (Llama 3.1 vía Groq) lo convierte en una estructura de datos validada con Pydantic: dimensiones, aberturas, muebles deseados. Latencia: <1s.
Optimizador con Simulated Annealing: aquí está el corazón del proyecto.
Visualización y export: los layouts se renderizan en 3D en el navegador con Three.js y se exportan como plano técnico en PDF con ReportLab.

Por qué Simulated Annealing

El espacio de disposiciones posibles es combinatorio y lleno de óptimos locales. Una búsqueda voraz se queda atascada en la primera solución "decente". El Simulated Annealing imita el enfriamiento de un metal: al principio acepta movimientos malos con cierta probabilidad (alta "temperatura"), lo que le permite escapar de óptimos locales; según baja la temperatura, se vuelve cada vez más exigente y converge. Es una metaheurística ideal cuando el espacio de soluciones es irregular y no tienes gradiente.

La función objetivo puntúa cada disposición de 0 a 100 según ergonomía: espacio de circulación, relaciones entre muebles, acceso a luz y aberturas. El sistema devuelve el top 5 de layouts, no solo el mejor, para dar opciones.

Rendimiento

Parse: <1s. Optimización: 2–5s. Export PDF: <1s.
Footprint en reposo: ~100 MB de RAM.

Qué aprendí

Que combinar un LLM (para entender lenguaje) con una metaheurística clásica (para optimizar de verdad) es un patrón potentísimo: el LLM traduce el problema humano a uno formal, y un algoritmo determinista y barato lo resuelve mejor —y de forma más explicable— que pedirle al propio LLM que "coloque los muebles".

Publicado originalmente en adrianmoreno-dev.com.

BabyMind: un asistente de desarrollo infantil con alertas pediátricas y memoria conversacional

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

Construir un asistente de IA sobre salud infantil obliga a una pregunta incómoda: ¿qué pasa si se equivoca? Un LLM genérico, por capaz que sea, puede dar consejos peligrosos con total seguridad. BabyMind está diseñado alrededor de esa preocupación, no a pesar de ella.

El problema

Ayudar a madres y padres a seguir el desarrollo de su bebé (0–36 meses), comparándolo con hitos médicos reconocidos y respondiendo dudas, sin pretender sustituir al pediatra y derivando a él cuando toca.

Conocimiento anclado: hitos OMS/AAP

El asistente no improvisa los hitos del desarrollo: trabaja sobre 37 hitos tabulados de la OMS y la Academia Americana de Pediatría (AAP), organizados en 4 categorías —motor, lenguaje, social y cognitivo— por franja de edad. El LLM razona sobre esa base de conocimiento, no desde su memoria paramétrica, lo que reduce las alucinaciones.

El sistema de alertas de tres niveles

Esta es la parte de seguridad. Cada interacción se clasifica en uno de tres niveles:

Normal: respuesta informativa estándar.
Warning: ante palabras clave como "alerta" o señales de retraso, recomienda explícitamente consultar al pediatra.
Emergency: ante términos críticos ("convulsiones", "no respira"), corta el flujo conversacional normal y dirige de inmediato al 112.

Este filtro determinista envuelve al LLM: no dependemos de que el modelo "decida bien" en una emergencia.

Memoria conversacional

Usa ConversationSummaryBufferMemory de LangChain: en vez de arrastrar todo el historial (caro y limitado por el contexto), mantiene un resumen de la conversación más los últimos turnos literales. Así recuerda lo importante de un diálogo largo sin disparar el coste. El motor es Llama 3.x 70B vía Groq, con respuesta <1s.

Qué aprendí

Que en aplicaciones de salud, la ingeniería de seguridad (conocimiento anclado + filtros deterministas de alertas) importa más que la elocuencia del modelo. El LLM aporta la conversación; la arquitectura aporta la responsabilidad.

Publicado originalmente en adrianmoreno-dev.com.