DEV Community: Adrian

Bienestar digital con IA: por qué los bloqueadores fallan y cómo hacerlo predictivo, adaptativo y con coach

Adrian — Thu, 15 Oct 2026 10:00:02 +0000

El mercado de las apps de control de pantalla está saturado —Screen Time, Digital Wellbeing, Freedom, Opal— y casi todas comparten las mismas tres debilidades: límites estáticos que pones una vez y luego ignoras, alertas reactivas que llegan cuando ya te has pasado, y un muro de bloqueo que desactivas en dos clics. Desconecta es un ejercicio sobre lo que de verdad falta ahí: no más "contar minutos", sino una capa de inteligencia.

Predictivo en vez de reactivo

El primer modelo es un forecaster (XGBoost) que aprende tu patrón —lags, medias móviles, día de la semana, tendencia— y predice los minutos de mañana por app. De ese forecast, proyectado sobre tu perfil horario, sale algo accionable: a qué hora cruzarás el límite. "A este ritmo llegarás a tu tope de TikTok hacia las 20:08." La intervención llega antes del atracón, no después.

Riesgo explicable, no caja negra

Un segundo modelo estima el riesgo de atracón del día como un score, y con SHAP expone por qué: fin de semana, racha de uso al alza, uso nocturno reciente, perfil impulsivo. Diseñé el generador de datos con esa estructura causal precisamente para que el modelo aprendiera señal real y SHAP la pudiera atribuir. Cuando seleccionas "fin de semana" en la demo, el trigger dominante que aparece es justo ese.

Límites adaptativos con glide-path

Un límite fijo que no puedes cumplir es un límite que abandonas. En vez de eso, un controlador transparente parte de tu uso real y desciende hacia tu objetivo (p.ej. −30%) de forma sostenible, sin recortes de más del 10% por semana. Nada de RL opaco: una política explicable que puedes auditar.

Un coach que negocia, no un muro

En el momento crítico interviene un coach LLM (Groq, Qwen3.8 27B) en tres modos: reflexionar (una pregunta que te hace notar por qué sigues), negociar una prórroga consciente a cambio de un motivo, o cerrar con una micro-acción alternativa. Breve, empático, sin sermones.

Una arquitectura, dos clientes

El detalle de ingeniería que más me gusta: el backend FastAPI es el cerebro, y lo consumen dos clientes. La demo web enseña la inteligencia sobre datos sintéticos de uso de móvil; y una app Android nativa hace la monitorización y el bloqueo reales del sistema (UsageStatsManager) delegando todo el análisis a esa misma API. Un cerebro, dos caras.

Honestidad con las métricas

Aquí viene la parte incómoda y, para mí, la más importante. El forecasting de uso por app da R²≈0.77 (batiendo a un baseline naïve de 0.57) y el riesgo de atracón AUC≈0.79. Están por debajo del listón que me pongo para problemas como predicción de precios (R²≥0.88). ¿Por qué no los subí? Porque hacerlo habría implicado limpiar artificialmente los datos, y el uso humano del móvil es intrínsecamente ruidoso: la misma persona pasa de 10 a 90 minutos en una app según el día. Inflar el número falseando los datos es justo lo contrario de lo que un portfolio técnico debería enseñar. El atracón, además, es un evento probabilístico: lo correcto es tratarlo como un score de riesgo (AUC), no como una clasificación dura. Prefiero un 0.77 honesto y defendible que un 0.9 de laboratorio que no sobreviviría al mundo real.

Publicado originalmente en adrianmoreno-dev.com.

Glosarios para traductores con IA: cola asíncrona, map-reduce y un agente que se autocritica

Adrian — Thu, 08 Oct 2026 10:00:03 +0000

Cuando un traductor profesional recibe un manual técnico o un contrato de decenas de páginas, el primer trabajo —el que el cliente no ve— es construir el glosario: identificar los tecnicismos, siglas y expresiones que deben traducirse exactamente igual a lo largo de todo el documento. Si "API Gateway" se traduce de tres formas distintas en tres capítulos, la traducción pierde calidad y consistencia. Hacer ese glosario a mano lleva horas. Esta herramienta lo automatiza conservando algo que las soluciones simples pierden: el contexto en el que aparece cada término.

El problema real no es el prompt, es la arquitectura

Es fácil escribir un prompt que extraiga terminología de un párrafo. Lo difícil es hacerlo con un documento pesado sin que se rompa nada: los límites de tokens del LLM, los rate limits de la API y la experiencia de usuario (nadie quiere una petición HTTP colgada dos minutos). Por eso el núcleo del proyecto es un flujo asíncrono desacoplado.

Al subir el documento, FastAPI lo almacena, crea una tarea en estado PENDING en SQLite e inyecta su ID en una cola Redis. Un consumidor recoge la tarea, la procesa por fases y va actualizando el progreso, mientras el frontend hace polling y muestra una barra real (fragmento 3 de 12…). El detalle de ingeniería que me gusta: ese consumidor no es un daemon aparte, sino una tarea asyncio dentro del propio servicio FastAPI. Un solo proceso, cero RAM residente de más, y compatible con el sistema de arranque bajo demanda del portfolio.

Map → Reduce → Reflect

La extracción no es un único prompt, sino un pipeline de tres fases:

Map: el texto se divide en fragmentos de ~1.800 palabras (respetando los límites de párrafo) y cada fragmento se envía a Groq (Qwen3.8 27B) con un prompt especializado en localización que devuelve JSON estricto: término, contexto exacto, traducción propuesta y justificación.
Reduce: se deduplican los términos que aparecen repetidos en páginas distintas.
Reflect: aquí está la diferencia. Un segundo paso agéntico recibe el glosario consolidado y se autocritica: elimina falsos positivos (palabras comunes que se colaron), fusiona variantes del mismo concepto ("API Gateway" y "gateway de API") y unifica traducciones inconsistentes.

Esa fase de reflexión es lo que convierte un extractor mecánico en algo que se acerca al criterio de un lingüista jefe revisando el trabajo. No es marketing: es una segunda llamada con un rol y una tarea de control de calidad distintos.

Respetar los rate limits es parte del diseño

Procesar 25 fragmentos en paralelo es la forma rápida de comerse el rate limit y recibir 429. La herramienta usa concurrencia acotada (dos llamadas simultáneas), backoff exponencial cuando aparece un 429 y una cadena de modelos (70B → 8B) como red de seguridad. Es más lento que disparar todo a la vez, pero es lo que hace que la demo no se caiga bajo carga.

Export en formatos que el sector usa de verdad

Un glosario que no se puede importar no sirve. La herramienta exporta en CSV (universal) y en TBX — TermBase eXchange, ISO 30042 —, el estándar de intercambio de bases terminológicas que importan SDL Trados, memoQ y el resto de herramientas CAT. Generar TBX-Basic válido (con su langSet por idioma de origen y destino) es lo que separa un juguete de una herramienta que un traductor puede meter en su flujo de trabajo real.

Honestidad sobre los límites

La extracción la hace un LLM: el resultado es un punto de partida de alta calidad, no una verdad absoluta. El profesional debe revisarlo antes de usarlo en producción. Y en la demo se procesan solo los primeros fragmentos de documentos muy largos, para mantener el coste y los tiempos acotados. Pero la arquitectura —cola, fases, reflexión, export estándar— es exactamente la que usarías en producción.

Publicado originalmente en adrianmoreno-dev.com.

Voice-to-SQL: hablarle a tu base de datos con un LLM (y por qué la seguridad es lo difícil)

Adrian — Thu, 01 Oct 2026 10:00:03 +0000

Las preguntas sobre datos casi nunca las hace quien sabe SQL. Las hace alguien de negocio, marketing o dirección, que tiene que pedírselas a un analista y esperar. Voice-to-SQL ataca justo esa fricción: que cualquiera pueda preguntarle a la base de datos hablando, y obtener la respuesta al instante.

El problema

Quería una demo que tradujera lenguaje natural —por voz o texto— a SQL, lo ejecutara sobre una base de datos real y devolviera la tabla, mostrando el SQL generado. Tres requisitos no negociables: que la voz no costara dinero, que fuera seguro dejar que un LLM tocara la base de datos, y que la respuesta llegara en menos de un segundo.

La voz: en el navegador, no en el backend

La tentación es mandar el audio al servidor y transcribirlo con Whisper o un servicio de pago. Lo descarté: añade latencia, coste y complejidad. En su lugar uso la Web Speech API, que viene integrada en Chrome, Edge y Safari. La transcripción ocurre en el dispositivo del usuario; el backend solo recibe texto. Coste de transcripción: cero. El precio a pagar es la dependencia del navegador, un compromiso razonable para una demo web.

De texto a SQL: el esquema es el prompt

El corazón del sistema es la conversión texto→SQL con un LLM (Qwen3.8 27B vía Groq, por su latencia muy baja). La clave no es el modelo, sino lo que se le da: junto a la pregunta, le paso el esquema exacto de la base de datos —tablas, columnas, tipos, valores posibles de los enums y un par de reglas del dialecto SQLite—. Sin ese contexto, el modelo inventa columnas. Con él, genera JOINs y GROUP BY correctos a la primera.

La parte difícil: que sea seguro

Aquí está el verdadero reto de ingeniería. Dar a un LLM una conexión a tu base de datos es una receta para el desastre: una pregunta mal interpretada (o malintencionada) podría acabar en un DROP TABLE. La regla de oro es no confiar nunca en el SQL generado.

Por eso, antes de ejecutar nada, el SQL pasa por un sanitizador que:

Solo acepta sentencias que empiecen por SELECT o WITH.
Rechaza por lista negra INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, PRAGMA, ATTACH y REPLACE.
Bloquea el encadenamiento de varias sentencias con punto y coma (un clásico vector de inyección).
Impone un tope absoluto de 100 filas por respuesta.

Es una defensa en capas, deliberadamente conservadora: prefiero rechazar una consulta legítima rara antes que permitir una destructiva. El LLM propone; el sanitizador dispone.

La base de datos demo

Para que las preguntas tengan sentido, generé con un script una base SQLite que imita el back-office de una empresa SaaS: 200 clientes (país, sector, plan, churn), 8 productos (planes y add-ons) y 5.000 ventas del último año con su aporte al MRR. Así se pueden hacer preguntas analíticas de verdad —ingresos por país, MRR por plan, churn— y no juguetes.

Resultado

De la pregunta a la tabla, en torno a medio segundo (la mayor parte es la generación del LLM; SQLite ejecuta en local en milisegundos). Y cada respuesta enseña el SQL que se generó, lo que convierte la demo en algo didáctico además de útil.

Qué aprendí

Que en un sistema "LLM + base de datos", el modelo es la parte fácil. Lo que de verdad decide si esto se puede poner delante de un usuario es la capa de seguridad y la calidad del contexto (el esquema) que le das al modelo. La inteligencia genera el SQL; la ingeniería hace que sea seguro ejecutarlo.

Publicado originalmente en adrianmoreno-dev.com.

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.