The latest articles on DEV Community by Adrian (@adrian_368e1d3e691afab697). https://dev.to/adrian_368e1d3e691afab697 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3983803%2F92991c8b-073d-44be-80c4-584f44d63100.jpg https://dev.to/adrian_368e1d3e691afab697 en Adrian Thu, 03 Sep 2026 10:00:03 +0000 https://dev.to/adrian_368e1d3e691afab697/value-betting-engine-del-modelo-de-probabilidad-a-la-apuesta-de-valor-con-el-criterio-de-kelly-a4n https://dev.to/adrian_368e1d3e691afab697/value-betting-engine-del-modelo-de-probabilidad-a-la-apuesta-de-valor-con-el-criterio-de-kelly-a4n <p>Hay un malentendido fundamental sobre las apuestas deportivas: la gente cree que se trata de <em>acertar</em> quién gana. No es así. Se trata de encontrar situaciones en las que la <strong>cuota del mercado está equivocada</strong> respecto a la probabilidad real. Eso es el <em>value betting</em>, y es matemáticamente idéntico a buscar activos infravalorados en bolsa.</p> <h2> El problema </h2> <p>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.</p> <h2> La probabilidad: reutilizar el Sports Engine </h2> <p>Las probabilidades vienen del modelo del <a href="https://dev.to/proyecto/sports-engine">Sports Performance Engine</a> (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.</p> <h2> Detectar valor: EV &gt; 0 </h2> <p>Para cada mercado consulto las cuotas de <strong>más de 350 casas</strong> vía OddsPapi. La señal de valor es simple pero implacable: el <strong>valor esperado</strong> de la apuesta, <code>EV = p · (cuota − 1) − (1 − p)</code>, donde <code>p</code> es mi probabilidad estimada. Solo entran las apuestas con <strong>EV positivo</strong>: aquellas donde el mercado paga más de lo que el riesgo justifica.</p> <h2> Dimensionar: el criterio de Kelly </h2> <p>Detectar valor no basta; hay que decidir <em>cuánto</em> apostar. El <strong>criterio de Kelly</strong> da la fracción del capital que maximiza el crecimiento geométrico a largo plazo: <code>f = (p · b − q) / b</code>. 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 <code>p</code>.</p> <h2> Validación: backtesting 2022–2024 </h2> <p>Toda la lógica se validó con <strong>backtesting sobre datos de 2022 a 2024</strong>, 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.</p> <h2> Qué aprendí </h2> <p>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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/value-betting-engine-kelly-criterion" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> finanzascuantitativas apuestasdeportivas kellycriterion backtesting Adrian Thu, 27 Aug 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/sports-performance-engine-predecir-futbol-con-datos-statsbomb-y-un-ensemble-lightgbmxgboost-d18 https://dev.to/adrian_368e1d3e691afab697/sports-performance-engine-predecir-futbol-con-datos-statsbomb-y-un-ensemble-lightgbmxgboost-d18 <p>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.</p> <h2> Los datos: StatsBomb </h2> <p>Usé los datos abiertos de <strong>StatsBomb</strong> (vía <code>statsbombpy</code>), 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.</p> <h2> Feature engineering: el corazón del proyecto </h2> <p>El modelo no mira un partido aislado, sino la <strong>forma reciente</strong> de cada equipo. Construí features <em>rolling</em>: 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.</p> <h2> Validación: TimeSeriesSplit, no K-Fold </h2> <p>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 <strong>filtrando el futuro</strong>. Usé <strong>TimeSeriesSplit</strong> (división temporal 70/15/15), de modo que el modelo siempre se evalúa sobre partidos posteriores a los de entrenamiento.</p> <h2> El modelo: ensemble + Optuna </h2> <p>Combiné <strong>LightGBM y XGBoost</strong> en un ensemble —dos implementaciones de gradient boosting con sesgos ligeramente distintos cuyas predicciones promediadas generalizan mejor— con hiperparámetros buscados por <strong>Optuna</strong> (30+25 trials).</p> <h2> Resultados </h2> <ul> <li><p><strong>AUC-ROC: 0.71</strong> — un número modesto en apariencia, pero <em>realista</em> para fútbol; desconfía de cualquiera que te prometa 0.95 prediciendo resultados de fútbol.</p></li> <li><p><strong>3.200 partidos</strong> analizados, <strong>25+ features</strong>.</p></li> <li><p>Explicabilidad <strong>SHAP</strong> por predicción.</p></li> </ul> <h2> Qué aprendí </h2> <p>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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/sports-performance-engine-statsbomb-ensemble" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> machinelearning deportes lightgbm xgboost Adrian Thu, 20 Aug 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/prediccion-de-precio-inmobiliario-por-que-un-ensemble-gbm-red-neuronal-bate-a-cualquiera-por-2b4k https://dev.to/adrian_368e1d3e691afab697/prediccion-de-precio-inmobiliario-por-que-un-ensemble-gbm-red-neuronal-bate-a-cualquiera-por-2b4k <p>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 <strong>ensemble</strong>.</p> <h2> El problema </h2> <p>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.</p> <h2> Los dos modelos del ensemble </h2> <ul> <li><p><strong>Gradient Boosting Machine:</strong> excelente capturando relaciones no lineales y "reglas" abruptas sobre datos tabulares. Es el caballo de batalla de los datos estructurados.</p></li> <li><p><strong>Perceptrón multicapa (MLP):</strong> 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.</p></li> </ul> <p>Las predicciones de ambos se combinan. El ensemble funciona porque sus errores están <strong>poco correlacionados</strong>: donde uno falla por su sesgo, el otro tiende a compensar.</p> <h2> Decisiones técnicas </h2> <p>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 <code>scikit-learn</code> para el GBM y <strong>PyTorch</strong> para el MLP, servido todo con <strong>FastAPI</strong>.</p> <h2> Resultados </h2> <ul> <li><p><strong>R² ≈ 0.90:</strong> el modelo explica alrededor del 90% de la varianza del precio.</p></li> <li><p><strong>MAE ≈ ±$62K:</strong> error medio absoluto.</p></li> <li><p><strong>~11% de error porcentual relativo.</strong></p></li> </ul> <h2> Qué aprendí </h2> <p>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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/prediccion-precio-inmobiliario-ensemble-gbm-mlp" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> machinelearning ensemble gradientboosting redesneuronales Adrian Thu, 13 Aug 2026 10:00:03 +0000 https://dev.to/adrian_368e1d3e691afab697/un-chatbot-rag-multilingue-sobre-tus-pdfs-con-faiss-y-reranking-coste-de-busqueda-0-eu-3bjc https://dev.to/adrian_368e1d3e691afab697/un-chatbot-rag-multilingue-sobre-tus-pdfs-con-faiss-y-reranking-coste-de-busqueda-0-eu-3bjc <p>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 <strong>qué fragmentos recuperas</strong> que del modelo que los redacta. Si recuperas el contexto equivocado, el mejor LLM del mundo te dará una respuesta equivocada con total seguridad.</p> <h2> El problema </h2> <p>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.</p> <h2> El pipeline de recuperación (donde está el truco) </h2> <ul> <li><p><strong>Embeddings multilingües:</strong> uso <code>intfloat/multilingual-e5-large</code> 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.</p></li> <li><p><strong>Búsqueda vectorial con FAISS:</strong> los vectores se indexan en <strong>FAISS</strong>, la librería de Facebook para búsqueda de similitud. Corre en CPU, en local, sin servicios gestionados: de ahí el <strong>coste de búsqueda de 0 €</strong>. Los índices estáticos se pre-generan por idioma; los PDFs que sube el usuario se indexan en RAM por sesión.</p></li> <li><p><strong>Reranking con cross-encoder:</strong> la búsqueda vectorial es rápida pero imprecisa. Por eso añado un segundo paso: un <strong>cross-encoder</strong> (<code>mmarco-mMiniLMv2</code>) que re-puntúa los candidatos leyendo pregunta y fragmento <em>juntos</em>. Es más lento, pero solo se aplica a un puñado de candidatos, y mejora drásticamente la precisión del contexto.</p></li> </ul> <h2> La generación </h2> <p>Solo entonces entra el LLM (<strong>Llama vía Groq</strong>, por su latencia bajísima), que redacta la respuesta a partir del contexto ya filtrado. El resultado: respuesta media <strong>por debajo de 3 segundos</strong>.</p> <h2> De demo a producto: SaaS multi-tenant </h2> <p>Por encima del motor RAG monté una capa <strong>SaaS multi-tenant</strong> con SQLite: clientes, planes (free/basic/pro/enterprise), autenticación por <code>X-API-Key</code> y registro de consumo de tokens con límites por plan. Lo que empezó como una demo es, en arquitectura, un producto.</p> <h2> Qué aprendí </h2> <p>Que la frase "RAG es solo meter documentos en un LLM" es engañosa. El valor está en el <strong>pipeline de recuperación</strong> —embeddings + búsqueda + reranking— y en hacerlo barato y rápido. El LLM es la última milla, no el motor.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/chatbot-rag-multilingue-faiss-reranking" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> nlp rag faiss embeddings Adrian Thu, 06 Aug 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/feliniai-un-triple-pipeline-vision-clinico-llm-para-detectar-alergias-felinas-con-f1-097-2jac https://dev.to/adrian_368e1d3e691afab697/feliniai-un-triple-pipeline-vision-clinico-llm-para-detectar-alergias-felinas-con-f1-097-2jac <p>Cuando el objetivo es algo tan delicado como un diagnóstico asistido, confiar en un único modelo es arriesgado. FeliniAI usa <strong>tres pipelines complementarios</strong> que se refuerzan entre sí, igual que un veterinario combina lo que ve, lo que mide y lo que sabe.</p> <h2> Pipeline 1 — Visión: MobileNetV2 </h2> <p>Una CNN <strong>MobileNetV2</strong> (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 <strong>93,4% de accuracy visual</strong>.</p> <h2> Pipeline 2 — Clínico: XGBoost + ICADA </h2> <p>El núcleo del sistema es un clasificador <strong>XGBoost</strong> que trabaja sobre <strong>33 features clínicas</strong> derivadas de los criterios <strong>ICADA</strong> (los criterios estandarizados de dermatitis atópica felina): estacionalidad, distribución de las lesiones, prurito, respuesta a tratamientos previos. Sobre un dataset de <strong>8.000 casos</strong>, este módulo logra un <strong>F1 macro de 0.9675</strong> en validación cruzada 5-fold. La búsqueda de hiperparámetros se hizo con Optuna y la explicabilidad con SHAP.</p> <h2> Pipeline 3 — LLM: la síntesis </h2> <p>Finalmente, un LLM (<strong>Llama 3.3 70B vía Groq</strong>) 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: <em>orquesta y comunica</em> lo que han calculado los modelos especializados.</p> <h2> Por qué tres pipelines y no uno </h2> <p>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 <strong>ensemble heterogéneo</strong> aplicado a datos de naturaleza distinta.</p> <h2> Resultados </h2> <ul> <li><p><strong>F1 macro (clínico): 0.9675</strong>, accuracy 0.9909.</p></li> <li><p><strong>Accuracy visual: 93,4%.</strong></p></li> <li><p><strong>4 tipos de alergia, 33 features clínicas, &lt;1s</strong> de inferencia.</p></li> </ul> <h2> Qué aprendí </h2> <p>Que en dominios sensibles, la arquitectura correcta no es "el modelo más grande", sino <strong>varios modelos especializados orquestados</strong>, cada uno haciendo aquello en lo que es bueno.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/feliniai-triple-pipeline-vision-clinico-llm" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> deeplearning visionporcomputador xgboost salud Adrian Thu, 30 Jul 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/separar-canciones-en-stems-con-htdemucs-v4-en-un-servidor-con-poca-ram-47nf https://dev.to/adrian_368e1d3e691afab697/separar-canciones-en-stems-con-htdemucs-v4-en-un-servidor-con-poca-ram-47nf <p>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 <strong>HTDemucs</strong> lo hacen sorprendentemente bien. El reto de este proyecto no fue el modelo, sino <strong>ponerlo a funcionar en un servidor modesto, sin GPU.</strong></p> <h2> El problema </h2> <p>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.</p> <h2> El modelo: HTDemucs v4 </h2> <p>Uso <strong>HTDemucs v4</strong> (variante <code>htdemucs_ft</code>), 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.</p> <h2> Las dos decisiones de ingeniería que lo hacen viable </h2> <ul> <li><p><strong>Segmentación (<code>--segment 5</code>):</strong> 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.</p></li> <li><p><strong>Procesado asíncrono:</strong> 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.</p></li> </ul> <p>El frontend usa <strong>WaveSurfer.js</strong> para visualizar las ondas y la <strong>Web Audio API</strong> para la remezcla en tiempo real: ajustar el volumen de cada stem, silenciar la voz para hacer karaoke, etc.</p> <h2> Detalle de despliegue </h2> <p>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.</p> <h2> Qué aprendí </h2> <p>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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/separar-stems-htdemucs-v4-cpu-ram-limitada" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> audioai htdemucs deeplearning procesadoasincrono Adrian Thu, 23 Jul 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/construir-un-sdk-de-musica-adaptativa-para-juegos-con-la-web-audio-api-2ao1 https://dev.to/adrian_368e1d3e691afab697/construir-un-sdk-de-musica-adaptativa-para-juegos-con-la-web-audio-api-2ao1 <p>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 <strong>indie</strong> de juegos web, con un SDK que se integre en menos de 10 líneas.</p> <h2> El problema </h2> <p>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 <strong>en el momento musical correcto.</strong></p> <h2> La arquitectura: capas + crossfade al beat </h2> <p>El SDK gestiona varias <strong>capas musicales</strong> (town, explore, combat, victory) que comparten tempo. Cuando el juego pide cambiar de estado, el motor no corta de golpe: programa un <strong>crossfade sincronizado al beat</strong> usando el reloj de alta precisión de la <strong>Web Audio API</strong>. 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.</p> <h2> Stack </h2> <p>Está escrito en <strong>TypeScript</strong> sobre <strong>Tone.js</strong> (que abstrae el scheduling de la Web Audio API), empaquetado con <strong>tsup</strong> en formatos ESM y CJS para que funcione en cualquier proyecto moderno. La demo es un mini-RPG en <strong>Phaser 3</strong> donde la banda sonora cambia al entrar en combate.</p> <h2> Diseño de API: la obsesión por la simplicidad </h2> <p>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 <strong>5 líneas</strong>: instanciar el motor, registrar las capas y llamar a <code>setState('combat')</code>. Todo lo complejo —el scheduling, el crossfade, la sincronía— queda escondido.</p> <h2> Qué aprendí </h2> <p>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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/sdk-musica-adaptativa-web-audio-api-juegos" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> typescript webaudioapi gamedev sdk Adrian Thu, 16 Jul 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/roomcraft-ai-optimizar-la-distribucion-de-una-habitacion-con-simulated-annealing-bj7 https://dev.to/adrian_368e1d3e691afab697/roomcraft-ai-optimizar-la-distribucion-de-una-habitacion-con-simulated-annealing-bj7 <p>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.</p> <h2> El pipeline de tres etapas </h2> <ul> <li><p><strong>Parser con LLM:</strong> 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 (<strong>Llama 3.1 vía Groq</strong>) lo convierte en una estructura de datos validada con <strong>Pydantic</strong>: dimensiones, aberturas, muebles deseados. Latencia: &lt;1s.</p></li> <li><p><strong>Optimizador con Simulated Annealing:</strong> aquí está el corazón del proyecto.</p></li> <li><p><strong>Visualización y export:</strong> los layouts se renderizan en 3D en el navegador con <strong>Three.js</strong> y se exportan como plano técnico en PDF con <strong>ReportLab</strong>.</p></li> </ul> <h2> Por qué Simulated Annealing </h2> <p>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 <strong>Simulated Annealing</strong> 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.</p> <p>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 <strong>top 5</strong> de layouts, no solo el mejor, para dar opciones.</p> <h2> Rendimiento </h2> <ul> <li><p>Parse: <strong>&lt;1s</strong>. Optimización: <strong>2–5s</strong>. Export PDF: <strong>&lt;1s</strong>.</p></li> <li><p>Footprint en reposo: <strong>~100 MB de RAM.</strong></p></li> </ul> <h2> Qué aprendí </h2> <p>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".</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/roomcraft-ai-simulated-annealing-distribucion-habitaciones" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> optimizacioncombinatoria simulatedannealing llm threejs Adrian Thu, 09 Jul 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/babymind-un-asistente-de-desarrollo-infantil-con-alertas-pediatricas-y-memoria-conversacional-1n16 https://dev.to/adrian_368e1d3e691afab697/babymind-un-asistente-de-desarrollo-infantil-con-alertas-pediatricas-y-memoria-conversacional-1n16 <p>Construir un asistente de IA sobre salud infantil obliga a una pregunta incómoda: <strong>¿qué pasa si se equivoca?</strong> 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.</p> <h2> El problema </h2> <p>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, <strong>sin pretender sustituir al pediatra</strong> y derivando a él cuando toca.</p> <h2> Conocimiento anclado: hitos OMS/AAP </h2> <p>El asistente no improvisa los hitos del desarrollo: trabaja sobre <strong>37 hitos tabulados</strong> 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 <em>sobre</em> esa base de conocimiento, no desde su memoria paramétrica, lo que reduce las alucinaciones.</p> <h2> El sistema de alertas de tres niveles </h2> <p>Esta es la parte de seguridad. Cada interacción se clasifica en uno de tres niveles:</p> <ul> <li><p><strong>Normal:</strong> respuesta informativa estándar.</p></li> <li><p><strong>Warning:</strong> ante palabras clave como "alerta" o señales de retraso, recomienda explícitamente consultar al pediatra.</p></li> <li><p><strong>Emergency:</strong> ante términos críticos ("convulsiones", "no respira"), corta el flujo conversacional normal y dirige de inmediato al 112.</p></li> </ul> <p>Este filtro determinista <em>envuelve</em> al LLM: no dependemos de que el modelo "decida bien" en una emergencia.</p> <h2> Memoria conversacional </h2> <p>Usa <strong>ConversationSummaryBufferMemory</strong> de LangChain: en vez de arrastrar todo el historial (caro y limitado por el contexto), mantiene un <em>resumen</em> 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 <strong>Llama 3.x 70B vía Groq</strong>, con respuesta &lt;1s.</p> <h2> Qué aprendí </h2> <p>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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/babymind-asistente-desarrollo-infantil-llm-memoria" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> llm langchain salud seguridadenia Adrian Thu, 02 Jul 2026 10:00:03 +0000 https://dev.to/adrian_368e1d3e691afab697/metacoach-generar-planes-de-entrenamiento-y-nutricion-a-partir-de-tu-hrv-y-tus-analiticas-2pj https://dev.to/adrian_368e1d3e691afab697/metacoach-generar-planes-de-entrenamiento-y-nutricion-a-partir-de-tu-hrv-y-tus-analiticas-2pj <p>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: <strong>adaptar el plan a tu fisiología real</strong>, medida con datos de wearable y analíticas de sangre.</p> <h2> El problema </h2> <p>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.</p> <h2> La arquitectura: reglas clínicas + LLM </h2> <p>Decidí <strong>no</strong> dejar que el LLM interpretara los valores médicos por su cuenta —demasiado riesgo. En su lugar, un motor de <strong>reglas basadas en rangos clínicos</strong> hace el análisis fisiológico:</p> <ul> <li><p>HRV &lt; 30ms → estado crítico de recuperación; &lt; 50ms → bajo.</p></li> <li><p>Sueño &lt; 5,5h → crítico; &lt; 7h → bajo.</p></li> <li><p>Ferritina, hemoglobina y vitamina D comparadas con sus rangos de referencia para detectar déficits.</p></li> </ul> <p>El LLM (<strong>Llama 3.3 70B vía Groq</strong>) entra <em>después</em>: 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.</p> <h2> Por qué reglas y no solo IA </h2> <p>Porque los umbrales clínicos son conocimiento establecido y <em>determinista</em>: 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.</p> <h2> Resultados de diseño </h2> <ul> <li><p><strong>5 herramientas de análisis</strong>, <strong>8 valores de analítica</strong> interpretados.</p></li> <li><p>Plan de <strong>7 días</strong> personalizado, generado en <strong>&lt;2s</strong>.</p></li> </ul> <h2> Qué aprendí </h2> <p>El mismo principio que en BabyMind: en salud, el LLM debe <strong>orquestar y comunicar</strong>, mientras que las decisiones sensibles se anclan en reglas verificables. Es la arquitectura "neuro-simbólica" en pequeño.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/metacoach-planes-salud-hrv-analiticas-sangre" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> llm healthtech hrv langchain Adrian Thu, 25 Jun 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/tutoria-un-tutor-con-ia-que-adapta-el-lenguaje-al-perfil-de-cada-nino-y-recuerda-entre-sesiones-425 https://dev.to/adrian_368e1d3e691afab697/tutoria-un-tutor-con-ia-que-adapta-el-lenguaje-al-perfil-de-cada-nino-y-recuerda-entre-sesiones-425 <p>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.</p> <h2> El problema </h2> <p>Que la explicación y los ejercicios se ajusten al <strong>perfil del alumno</strong> —rendimiento general, TDAH, dislexia— y que haya <strong>continuidad</strong>: que el tutor recuerde en qué andaba el niño la sesión anterior, sus dificultades y sus avances.</p> <h2> Adaptación al perfil </h2> <p>El perfil del alumno condiciona el <em>prompt</em> 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.</p> <h2> Memoria entre sesiones </h2> <p>Aquí está la diferencia con un chatbot del montón. La mayoría olvidan todo al cerrar la pestaña. TutorIA <strong>persiste el contexto del alumno entre sesiones</strong>, 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.</p> <h2> Stack </h2> <p>Construido con <strong>LangChain</strong> y un LLM servido por <strong>Groq</strong> (LLaMA) para respuestas rápidas, sobre <strong>FastAPI</strong>, e integrado en el portfolio Laravel. La recuperación de material de apoyo se apoya en un esquema RAG.</p> <h2> Qué aprendí </h2> <p>Que la "personalización" real en EdTech no es cosmética (poner el nombre del niño): es adaptar la <em>pedagogía</em> y mantener <em>memoria</em>. Sin continuidad entre sesiones, no hay aprendizaje, solo respuestas sueltas.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/tutoria-tutor-adaptativo-memoria-entre-sesiones" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> llm edtech langchain iaadaptativa Adrian Thu, 18 Jun 2026 10:00:02 +0000 https://dev.to/adrian_368e1d3e691afab697/orientaia-disenar-un-orientador-vocacional-conversacional-para-adolescentes-4bhl https://dev.to/adrian_368e1d3e691afab697/orientaia-disenar-un-orientador-vocacional-conversacional-para-adolescentes-4bhl <p>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: <strong>una conversación.</strong></p> <h2> El problema </h2> <p>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.</p> <h2> El enfoque: extracción conversacional </h2> <p>En lugar de preguntar directamente "¿qué quieres ser?", OrientaIA conduce una <strong>conversación guiada</strong> que va extrayendo, de forma indirecta, tres dimensiones: <strong>intereses</strong> (qué les engancha), <strong>valores</strong> (qué les importa) y <strong>habilidades</strong> (en qué destacan). El LLM no interroga: dialoga, y de ese diálogo infiere el perfil.</p> <h2> Del perfil al mapa de carreras </h2> <p>Con ese perfil, el sistema genera un <strong>mapa de carreras personalizado</strong>. Y añade algo que marca la diferencia frente a un test: una <strong>simulación de "un día en la vida"</strong> 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.</p> <h2> Stack </h2> <p>Pipeline conversacional con <strong>LangChain</strong> y LLaMA vía <strong>Groq</strong> sobre <strong>FastAPI</strong>, con apoyo de RAG para anclar la información de itinerarios formativos reales, integrado en el portfolio Laravel.</p> <h2> Qué aprendí </h2> <p>Que los LLMs brillan precisamente en lo que los formularios hacen mal: <strong>extraer estructura de una conversación no estructurada.</strong> 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.</p> <p><em>Publicado originalmente en <a href="https://adrianmoreno-dev.com/blog/orientaia-orientador-vocacional-conversacional" rel="noopener noreferrer">adrianmoreno-dev.com</a>.</em></p> llm edtech orientacionvocacional langchain