Entrenamiento-Llm on lo0 — Blog Técnico

Retrain: cerrar el bucle entre el incidente en producción y el adapter que lo arregla

Fri, 22 May 2026 07:45:00 +0200

TL;DR

La etapa Retrain del pipeline LLMOps de seis etapas es la que cierra el ciclo. Sin ella, el sistema desplegado es un proyecto que termina; con ella, es una práctica viva que mejora cada trimestre. La mecánica a primer nivel encaja en cinco sub-procesos secuenciales: capturar feedback (explícito vía thumbs + implícito vía latencia, abandonment, retries), triajar incidentes por causa raíz (model issue, retrieval issue, prompt issue, infra issue), enriquecer el dataset con los casos donde el sistema falló y la respuesta correcta etiquetada por humano, decidir cadencia (scheduled trimestral por defecto + incident-driven cuando un patrón supera threshold), y promocionar el candidato pasándolo por Tune → Eval → Deploy con gates contra el modelo en producción. Las herramientas que el mercado ha consolidado en 2026: Langfuse para feedback collection en la UI, Argilla y Label Studio para anotación humana del dataset enriquecido, MLflow stages para promotion. La trampa más letal —y la más común— es el bucle abierto: tener todas las piezas pero sin canal estructurado que las conecte, con lo que la etapa Retrain se reduce a “ya retrenamos cuando haga falta” y por tanto nunca.

Estás aquí: Retrain (cierra el ciclo hacia Data)

Este post entra al detalle de la etapa 6 del pipeline LLMOps. Lo que sigue desmonta los cinco sub-procesos de Retrain a primer nivel completo, sin bajar a la mecánica interna de Tune (cubierta en el post de fine-tuning continuo) ni a la implementación de las suites de eval (cubierta en el post de evals).

La analogía maestra: el comité de mortalidad del hospital

Un hospital serio celebra reuniones periódicas de morbidity & mortality (M&M): los médicos revisan, sin culpa pero sin omitir nada, los casos donde un paciente murió o tuvo una complicación grave. Buscan causa raíz, identifican patrones, ajustan protocolos, y dejan registro. El comité no se reúne cuando “se acuerdan”; está calendarizado y es obligatorio. Y cuando hay un incidente catastrófico fuera de ciclo, se convoca M&M extraordinario en 48 h.

La etapa Retrain es exactamente eso para un sistema LLM:

El morbidity son los incidentes leves: respuestas que el usuario marcó con thumbs-down, sesiones donde reintentó la misma pregunta tres veces, ejemplos donde el eval score bajó pero no por debajo del threshold de alerta.
El mortality son los incidentes graves: el sistema dio una respuesta peligrosa, un cliente clave canceló por una serie de errores, el agente ejecutó una tool que no debía.
Las reuniones periódicas son el scheduled retrain trimestral: se mira la acumulación de feedback, se prioriza, se decide qué entra al dataset enriquecido para el próximo entrenamiento.
Los M&M extraordinarios son los incident-driven retrain: ante un patrón problemático que supera threshold, se dispara un mini-ciclo fuera de cadencia.

Sin esta disciplina, los incidentes son anécdotas que se olvidan y el sistema no aprende.

Sub-proceso 1 — Captura de feedback

El primer eslabón del bucle es observar lo que el sistema hace mal. Hay dos familias de feedback, complementarias.

Feedback explícito

El usuario te dice directamente que la respuesta fue mala. Mecanismos:

Thumbs up/down en la UI: el clásico, baja latencia (1 click). Cobertura: 1-5 % del tráfico típicamente. Sesgo: los usuarios votan más cuando están molestos que cuando están contentos.
Anotación por usuarios power: clientes internos o expertos que dejan comentarios estructurados (“la respuesta es correcta pero el formato no respeta nuestra guía de estilo”). Cobertura mucho menor pero calidad alta.
Formularios de “¿qué falló?” cuando el thumbs-down se clica: opciones predefinidas (alucinación, formato, tono, incompleta, fuera de tema) + texto libre opcional. Permite triaging automatizado.
Re-edición: si el sistema escribe un borrador (correo, código) y el usuario lo edita antes de enviarlo, esa edición es feedback rico. Diff entre lo generado y lo enviado = señal explícita del fallo.

Todos los feedbacks explícitos viajan etiquetados con trace_id, prompt_version, model, user_id (anonimizado si toca), timestamp, y entran al store de feedback. Langfuse, Phoenix y LangSmith tienen UI built-in para esto; lo importante es que cada thumbs-down se materialice como una fila en una tabla, no como un evento que se pierde.

Feedback implícito

El usuario no te dice nada pero su comportamiento delata el problema. Señales típicas:

Latencia anómala: el TTFT del sistema fue 8 s cuando la media es 800 ms. Indica overload, retrieval pesado, prefill grande inesperado. Cubierto a primer nivel en evals y ebpf+drift.
Abandonment rate: el usuario abandona la sesión antes de leer la respuesta completa. Si el ratio sube de 5 % a 15 % en un segmento, algo va mal.
Retries del usuario: el usuario hace la misma pregunta (o muy similar) 2-3 veces. Indica que la primera respuesta no le sirvió.
Sesiones abortadas: el usuario cierra el chat antes de que el modelo termine de generar. En streaming, ratio elevado de aborts es indicador fuerte.
Salida del workflow: en un agente, el usuario cancela el plan antes de la ejecución. La trayectoria del agente no convenció.
Drift estadístico en distribución de inputs o outputs (KS test, PSI, embedding-space shift). Cubierto a primer nivel en eBPF + drift.

Las señales implícitas son más ruidosas pero cubren el 100 % del tráfico, no el 1-5 % del feedback explícito. Combinarlas con el feedback explícito da el panorama completo.

Patrón típico de almacenamiento

Todo el feedback —explícito e implícito— acaba en una tabla común con schema mínimo:

CREATE TABLE feedback_signals (
 signal_id UUID PRIMARY KEY,
 trace_id UUID NOT NULL,
 request_id UUID NOT NULL,
 signal_type VARCHAR NOT NULL, -- 'thumbs', 'retry', 'abandon', 'drift', ...
 signal_value JSONB, -- payload del feedback (texto del thumbs-down, latency, etc.)
 prompt_id VARCHAR,
 prompt_version INT,
 model VARCHAR,
 user_segment VARCHAR, -- tenant, plan, geo
 occurred_at TIMESTAMPTZ NOT NULL,
 triaged BOOLEAN DEFAULT FALSE,
 triage_label VARCHAR -- llenado en sub-proceso 2
);

Postgres es más que suficiente para volúmenes razonables (millones de filas al mes). Langfuse usa Postgres por debajo. Para volúmenes altos puedes derivar a ClickHouse o BigQuery, pero rara vez merece la pena complicar.

Sub-proceso 2 — Triage por causa raíz

Tener feedback no es suficiente. Hay que categorizar cada incidente por su causa raíz antes de decidir qué hacer con él. Sin triage, el dataset enriquecido es un cajón desastre y el siguiente retrain no arregla nada en concreto.

Las cuatro categorías canónicas:

Categoría	Significa	Acción típica
Model issue	El modelo respondió mal a algo que sí estaba en su capacidad teórica.	Caso candidato a dataset enriquecido para el siguiente Tune.
Retrieval issue	El RAG no recuperó el contexto correcto. El modelo respondió razonablemente a partir de contexto pobre.	Ajustar reranker, chunking, indexing — etapa Data, no Tune.
Prompt issue	El system prompt no cubre el caso o lo cubre mal.	Nueva versión del prompt (etapa transversal de prompt versioning).
Infra issue	Latencia, timeout, error 5xx, overload.	Ajustar capacidad / autoscaler — etapa Deploy.

El triage puede hacerse:

Manual: un humano (typically: el equipo MLE / data scientist) revisa el feedback en la UI de Langfuse / Phoenix / LangSmith, mira el trace completo, etiqueta. Coste: 2-5 min por incidente. Sostenible hasta unos 50-100 incidentes/semana por persona.
Asistido por LLM-as-classifier: un LLM clasifica el incidente en una de las cuatro categorías con un prompt estructurado. Cobertura del 80-90 % automatizada, el resto se escala a humano. Estado del arte 2026: GPT-5, Claude 4, Llama 3 70B-instruct con prompt cuidado dan F1 > 0.85 sobre rúbricas internas calibradas.
Reglas heurísticas para los obvios: error 5xx siempre es infra; latencia > 5σ siempre es infra; thumbs-down sobre RAG con context_relevance < 0.3 es retrieval. Captura el 30-50 % del volumen con coste cero.

El patrón productivo es: reglas → LLM classifier → humano, en cascada, escalando sólo lo que el nivel anterior no resuelve con confianza.

Feedback nuevo
│
▼
[reglas heurísticas]
│
├── confianza alta → etiqueta automática
│
▼ (resto)
[LLM-as-classifier]
│
├── confianza alta → etiqueta sugerida
│
▼ (resto, o discrepancia con reglas)
[revisión humana]
│
└── etiqueta final → feedback_signals.triage_label

Sub-proceso 3 — Dataset enrichment

Una vez triajeados los incidentes con etiqueta model issue, esos casos son candidatos a entrar al dataset enriquecido que alimentará el siguiente Tune. Pero no entran tal cual: hace falta la respuesta correcta etiquetada por humano.

Cómo se construye un caso enriquecido

Cada caso enriquecido es una tupla mínima:

case_id: enrich-2026-05-22-0142
source_trace_id: trace-xyz
prompt_input:
 system: "Eres un asistente de soporte..."
 user: "Cancelé mi pedido el martes pero sigo viendo el cargo"
prompt_version_at_failure: customer_support_v3@v2
model_at_failure: llama-3-70b-instruct
failure_response: "Lamento las molestias. El cargo debería revertirse en 5-7 días hábiles."
human_corrected_response: "Lamento las molestias. He verificado tu cuenta y veo que el reembolso se procesó el miércoles. Aparecerá en tu cuenta en 24-48 h adicionales según tu banco. Aquí está el ID del reembolso: ABC123."
labeler: "agente_soporte_M3"
labeled_at: "2026-05-22T09:30:00Z"
quality_score: 4 # 1-5, eval por segundo humano antes de promover al dataset
notes: "El modelo dio respuesta genérica sin consultar el estado real del reembolso. Necesita el tool de account_lookup."

Lo importante es que el caso enriquecido tiene suficiente contexto para reproducirse: prompt original, prompt version, modelo, respuesta fallada, respuesta correcta. Sin esto, el caso es un dato suelto inútil para entrenar.

Herramientas de anotación

Tres opciones dominantes en 2026:

Argilla (OSS, mantenido por Hugging Face desde 2024). Diseñado específicamente para datasets de LLM: anotación de pares (input, output), preference data (DPO/RLHF), instruction tuning. UI Python-friendly. Integración nativa con datasets de HuggingFace y con MLflow.

Label Studio (OSS de Heartex). Más generalista, también sirve para LLM. UI rica, configurable, multi-modal. Mejor cuando el equipo ya lo usa para otras tareas.

Langfuse UI built-in. Permite anotar traces existentes directamente con thumbs + texto + categorical labels. Útil para feedback ligero; para construir datasets serios de preference o instruction tuning, Argilla y Label Studio son más adecuados.

Patrón típico: Langfuse para feedback de tráfico + Argilla para construir el dataset enriquecido formal que va al pipeline de Tune. Los traces marcados como candidates en Langfuse se exportan periódicamente a Argilla, donde un humano produce la respuesta correcta y valida calidad.

Validación de calidad antes de promover

No todo caso anotado entra al dataset. Una buena disciplina exige:

Doble anotación en al menos el 10-20 % de los casos críticos (dos anotadores independientes; si discrepan, un tercero resuelve).
Quality score por caso (1-5 o equivalente) — sólo casos con score ≥ 4 entran al dataset.
Versionado del dataset con DVC + lakeFS o equivalente, igual que el resto de datasets de la etapa Data.
Holdout reservado: una porción del dataset enriquecido se aparta para evaluar el adapter retraído, sin que entre al training. Si el dataset se enriquece con casos donde el modelo falló y el mismo dataset se usa para evaluar, se mide memorización, no aprendizaje.

Sub-proceso 4 — Cadencias: scheduled vs incident-driven

Una vez se acumula dataset enriquecido, queda decidir cuándo se lanza el retrain. Hay dos cadencias complementarias.

Scheduled retrain (trimestral por defecto)

Un proceso establecido en el calendario. Cada trimestre, en una semana específica, el equipo:

Cierra el ciclo de captura de feedback acumulado.
Cuenta los casos enriquecidos disponibles (típicamente decenas a cientos por trimestre).
Lanza el pipeline de fine-tuning con el dataset agregado (golden dataset + casos enriquecidos del trimestre).
Evalúa el candidato contra suite completa + holdout enriquecido.
Promociona si pasa eval gates.

Ventajas: capacity planning predecible, presupuesto cerrado, riesgo controlado, equipo no quemado. El default.

Incident-driven retrain

Cuando un incidente serio supera threshold, se dispara un mini-ciclo fuera de cadencia. Triggers típicos:

Drift detectado en distribución de inputs/outputs sobre threshold (KS p-value < 0.01, PSI > 0.25, embedding-space shift > 2σ).
Segmento que falla: un cluster de usuarios o un tipo de pregunta muestra tasa de error 3× sobre baseline durante > 48 h.
Ataque de prompt injection o jailbreak con éxito que supera severity threshold (cubierto en guardrails).
Cambio de dominio externo: el cliente cambia política, sale una nueva regulación, etc. El modelo entrenado contra la versión vieja deja de ser válido.

Mini-ciclo típico: feedback de los últimos 7-14 días, dataset focalizado en el segmento problemático, fine-tuning rápido sobre el adapter existente (no full retrain), eval gate específico al segmento, despliegue canary, promoción si pasa.

Coste: ~3-7 días de trabajo del equipo según severidad. No es opcional para casos críticos: si el segmento que falla es regulatorio o reputacional, el coste de no responder rápido es mucho mayor que el del mini-ciclo.

Anti-patrón: “ya retrenamos cuando haga falta”

La frase más letal en LLMOps. Sin calendarización explícita, el scheduled nunca llega; sin thresholds explícitos, el incident-driven tampoco se dispara. El sistema acumula deuda silenciosa hasta que un incidente catastrófico fuerza el retrain ya tarde.

La disciplina mínima: fecha en calendario para el próximo scheduled + 3-5 thresholds de incident-driven explícitos por escrito. Sin esto, la etapa Retrain es teatro.

Sub-proceso 5 — Promotion: el candidato entra a producción

Una vez el adapter candidato existe, no entra a producción directamente. Pasa por el mismo flow que cualquier release: Tune → Eval → Deploy con gates.

Adapter candidato (de Tune)
│
▼
[Eval suite completa]
- golden dataset histórico
- holdout enriquecido del trimestre
- regression vs producción
│
pasa? → no → bloqueo + alerta
│
sí
▼
[Eval gate de no-regresión]
- asegurar que no degrada
segmentos que ya funcionaban
│
pasa? → no → bloqueo + alerta
│
sí
▼
[Despliegue canary]
- 5-10% del tráfico al adapter
nuevo durante 24-72 h
- métricas online vs producción
│
métricas OK? → no → rollback
│
sí
▼
[Promotion full]
- mover label en model registry
- MLflow stages: Staging → Production
- El anterior pasa a Archived (preserva
reproducibilidad histórica)

Las herramientas del registry:

MLflow Model Registry stages (Staging, Production, Archived) es el patrón canónico. La promotion es una llamada API: mlflow.models.transition_stage(name, version, "Production"). Auditado, revertible.
Hugging Face Hub privado con repo per adapter es el equivalente “Git for models” — versionado por commit hash, branches para staging/production, deploy via PR.
vLLM multi-LoRA hot-swap (descrito en fine-tuning continuo) carga el adapter nuevo sin reiniciar el servidor — la promotion física dura segundos.

Aplicado a hardware on-premise típico

Retrain como etapa no necesita hardware grande. El cálculo:

Feedback collection: una pequeña tabla en Postgres. Trivial en cualquier nodo.
Triage manual / asistido: el LLM-as-classifier corre en el mismo motor de inferencia que sirve producción, en horas de baja demanda, con prioridad spot. Decenas de miles de incidentes al mes consumen del orden de minutos de GPU por día.
Dataset enrichment: anotación humana, sin coste GPU. Storage despreciable.
Tune (mini-ciclo o trimestral): aquí sí hay coste. Fine-tuning de un adapter LoRA sobre Llama 3 70B con un dataset de pocos miles de ejemplos cuesta del orden de 2-8 horas en una H100 single. Sobre 4 H100 con tensor parallel: 30-90 min. Cabe holgadamente en cualquier ventana nocturna de baja demanda.
Eval suite completa: minutos en un motor con prefix caching activo (cubierto en pagedattention deep-dive).
Despliegue canary: cero coste adicional — el adapter nuevo convive en el mismo motor vía multi-LoRA hot-swap.

Para una RTX 4090 sirviendo Llama 3 8B con equipo pequeño: scheduled retrain mensual o trimestral en una noche, dataset enriquecido con 50-100 casos por ciclo, anotación con Argilla autohospedado en el mismo nodo. Bastante.

Para un cluster 4×H100 SXM sirviendo a varios tenants: dataset enriquecido segregado por tenant (cada uno con su propio holdout y eval suite), pipeline de retrain orquestado con Argo Workflows o equivalente, MLflow registry centralizado, multi-LoRA hot-swap por tenant.

Trampas operativas comunes

El bucle abierto. El sistema captura feedback, lo guarda en una tabla, y ahí muere. Nadie triajea, nadie enriquece, nadie retrena. El modelo deployed envejece silenciosamente. Solución: SLO interno explícito (por ejemplo, “todo feedback >1 semana sin triajear se reporta en standup”), dueño asignado.

Feedback humano que se pierde. Thumbs-down sin captura estructurada (el evento se loggea pero el motivo no), o el motivo se loggea pero nadie lo indexa para queries. Solución: schema explícito como el de arriba, dashboard semanal de “top motivos de thumbs-down”.

Cadence sin definir. “Ya retrenamos cuando haga falta” — nunca. Solución: fecha en calendario + 3-5 thresholds escritos.

Sin holdout test set. El dataset enriquecido se mezcla con el golden dataset para entrenar Y para evaluar. El adapter parece haber mejorado porque “memorizó” los casos enriquecidos, pero generaliza mal a nuevos casos similares. Solución: holdout reservado antes de entrenar, eval contra holdout es la métrica que decide promotion.

Triage ad-hoc por persona. El data scientist senior triajea cuando puede; en vacaciones se acumula; vuelve y abandona porque hay 400 incidentes esperando. Solución: automatizar con LLM-as-classifier el 70-80 %, dejar humano sólo lo difícil; rotar el “oncall de triage” para no saturar a una persona.

Promotion sin canary. El adapter pasa eval offline y se despliega al 100 % directamente. Una regresión en producción tarda en detectarse hasta que las métricas online lo evidencian — para entonces el daño está hecho. Solución: canary 5-10 % durante 24-72 h obligatorio.

Sin reproducibilidad del incidente original. El equipo va a investigar por qué el modelo falló en el incidente del 22 de mayo y descubre que el prompt era distinto (se cambió hace dos semanas), el modelo también, y los logs no guardaron el contexto RAG. Solución: trazabilidad fuerte (cubierta en prompt versioning y MCP observability). Sin reproducibilidad, retrain es adivinanza.

El dataset enriquecido contamina los datos de Eval. El equipo confunde “casos donde falló” (que entran al training enriquecido) con “golden dataset de regresión” (que tiene que permanecer estable para detectar drift). Mezclarlos invalida el eval. Solución: dos datasets distintos, dos rutas distintas.

Patrón operativo recomendado: el ciclo trimestral en una pantalla

Un equipo serio con Retrain bien implementado tiene este flujo cada 3 meses:

Semana 1 (cierre de ciclo): bloqueo de captura nueva para el ciclo, snapshot de feedback acumulado. Reporte automatizado: cuántos thumbs-down, cuántos incidentes triajeados, distribución por categoría, top patrones.

Semana 2 (triage y anotación): el equipo MLE+anotadores procesa los casos model issue no triajeados. Anotación humana en Argilla. Validación cruzada en muestras.

Semana 3 (training y eval): pipeline lanzado con dataset = golden + enriquecido_de_este_trimestre - holdout. Fine-tuning del adapter en una noche. Eval contra suite completa + holdout. Si pasa gates, candidato v_new.

Semana 4 (canary y promotion): deploy del candidato como adapter alternativo en vLLM, routing del 5-10 % del tráfico al candidato durante 48-72 h. Métricas online: latencia, tasa de queja, eval implícito en producción. Si todo OK, promotion full; si no, rollback y análisis.

Semana 5+ (siguiente ciclo): el adapter v_new ahora es production. Empieza la captura de feedback del próximo trimestre. El anterior v_old pasa a Archived pero queda accesible para reproducibilidad histórica.

Trimestralmente, ese ciclo más los mini-ciclos incident-driven que aparezcan en medio. Operacional, predecible, auditable.

Lo que no hemos cubierto (próximos posts)

Online DPO y aprendizaje continuo on-policy: cómo se acorta el ciclo a horas o días (Fast-Slow Chasing, RLOO iterativo). Estado del arte 2026 — todavía emergente en producción.
Machine unlearning para GDPR: cuando un usuario ejerce derecho al olvido y sus interacciones formaron parte del dataset enriquecido de un adapter en producción. Negative LoRA, retrain selectivo.
Constitutional AI runtime: alignment continuo que sustituye o complementa retrain periódico.
Eval gates con metamorphic testing: evaluación de robustez frente a perturbaciones del input (typos, paraphrasing, idioma) como parte del gate de promotion.

Ver también

El pipeline LLMOps de seis etapas — el mapa maestro donde Retrain es la etapa 6. Este post entra al detalle de esa caja.
Fine-tuning continuo en producción — la mecánica de Tune que ejecuta el adapter nuevo del ciclo descrito aquí.
Evals: la capa después del tracing — las suites de eval que sirven de gate en el sub-proceso 5 de promotion.
Prompt versioning con Langfuse y MLflow Prompts — el componente transversal que asegura reproducibilidad del incidente original cuando se va a triajear.
Data versioning para LLMOps: DVC, lakeFS y golden dataset reproducible — el sub-proceso 3 de Retrain enriquece un dataset; este post entra al detalle de cómo versionarlo, su schema y su lineage.
eBPF en inferencia local y detección estadística de drift — las señales de drift que disparan el incident-driven retrain.
Guardrails y safety en LLMs — los incidentes de safety / jailbreak que también disparan incident-driven retrain.
MCP por dentro y su observabilidad profunda — el tracing OTel gen_ai.* que liga cada feedback con su trace completo, condición necesaria para triagear bien.

Referencias

Argilla documentation, Building Datasets for LLM Fine-Tuning: https://argilla.io/docs.
Label Studio documentation, LLM Annotation: https://labelstud.io/templates/llm.
Langfuse documentation, User Feedback and Dataset Management: https://langfuse.com/docs/scores/user-feedback.
MLflow Model Registry stages: https://mlflow.org/docs/latest/model-registry.html.
Ethayarajh et al., KTO: Model Alignment as Prospect Theoretic Optimization (2024) — referencia para el ciclo de feedback como señal de alineamiento.
Google Cloud, Continuous Training and MLOps for GenAI (2025).
DataRobot, MLOps Best Practices: Closing the Loop (2025).
Eugene Yan, Feedback Loops in LLM Systems (blog, 2025).

Fine-tuning continuo en producción: del tráfico real al adapter desplegado

Thu, 21 May 2026 10:00:00 +0200

TL;DR

Fine-tuning continuo no es “entrenar el modelo cada cierto tiempo”. Es un ciclo cerrado donde el tráfico real de producción genera los datasets, un pipeline corto entrena un adapter LoRA, una batería de evaluaciones decide si promociona, y vLLM lo carga sin reiniciar. El estado del arte en mayo de 2026 ha fragmentado el stack: ya no es DPO contra todo, sino una elección entre SFT, DPO, KTO, ORPO y SimPO según el tipo de señal que captura tu producto. Lo que ha consolidado el patrón es la combinación PostgreSQL 18 + pgvector 0.8 como sistema nervioso del pipeline —captura de tráfico, dataset versioning, eval results, registry de adapters—, junto a vLLM multi-LoRA hot-swap que convierte el despliegue en una llamada HTTP. Este artículo desmonta el ciclo con esquemas concretos, queries reales, y los números que cuestan en una RTX 4090 frente a un cluster 4×H100.

Estás aquí: Tune + Retrain

Este post cruza dos etapas del pipeline LLMOps de seis etapas: la decisión de entrenar un adapter nuevo (etapa Tune) está disparada por las señales de Observe que viajan por la etapa Retrain hasta cerrar el bucle. El post desmonta el circuito completo entre las dos cajas.

La analogía: el restaurante que afina su carta

Imagina un restaurante de barrio con un plato estrella que funciona, pero el chef sabe que se puede afinar. Cada noche pasan cosas:

Algunos comensales dejan parte del plato: señal débil de que algo no acabó de encajar.
Otros piden otra versión ("¿podrías ponerle menos sal?"): señal explícita y direccional.
Otros terminan el plato y vuelven la semana siguiente: la única señal que de verdad importa, pero llega tarde.
Y un grupo selecto opina sin que se les pregunte, normalmente para mal.

El chef no rehace su carta cada noche. Hace algo más interesante: anota en una libreta los platos servidos, las devoluciones, los cambios pedidos, las propinas. Cada cierto tiempo, lee la libreta entera, decide ajustes mínimos en una receta, prueba la nueva versión en mesa privada con su personal, y solo si la prueban favorablemente la incorpora a la carta del día siguiente. A veces incluso sirve dos versiones distintas del plato a distintas mesas durante una semana, mide qué pasa, y elige.

Eso es fine-tuning continuo. La libreta es Postgres. El plato es el modelo base. Las anotaciones son señales de feedback —explícitas y implícitas—. El “ajuste mínimo” es un LoRA adapter de 30 MB. La mesa privada es la batería de evaluaciones automatizadas. La carta del día siguiente es vLLM con multi-LoRA hot-swap, que carga el nuevo adapter sin reiniciar el servicio. El servir dos versiones a distintas mesas es A/B testing con tráfico real.

La analogía es exacta en un punto crítico: el chef no tira la receta original. Mantiene la receta base y guarda una libreta separada con las “modificaciones que dan buen resultado para los habituales del barrio”. Esa libreta es el adapter LoRA: encima del modelo base, no en su lugar.

El ciclo, desmontado

Antes de entrar en componentes, conviene fijar el flujo completo. Estos siete pasos son lo que cualquier equipo serio replica con variaciones:

El ciclo dura entre 1 y 4 semanas en producción real. Lo que cambia entre equipos es el ritmo (más rápido en chat asistente, más lento en banca regulada) y los detalles de cada paso. La estructura es la misma.

Por qué fine-tuning continuo (y por qué no es RAG)

Antes de profundizar, una distinción que se sigue confundiendo. Fine-tuning sirve para forma, no para hechos. Si tu problema es que el modelo no conoce las tarifas del cliente o el catálogo actualizado, no fine-tunees: usa RAG. Si tu problema es que el modelo responde con un tono que no encaja, no respeta tu formato JSON, rechaza casos legítimos o se inventa estructura, ahí sí es fine-tuning.

En 2026 el límite ya está bien establecido por la práctica de la comunidad:

Problema observado	Solución
El modelo no sabe X (X cambia semanalmente)	RAG
El modelo conoce X pero responde mal de tono o formato	Fine-tuning SFT
Hay dos formas de responder y prefiero una sobre otra	Fine-tuning con preferencias (DPO/KTO/ORPO/SimPO)
El modelo razona mal en un dominio verificable (código, mates)	RL con recompensa verificable (GRPO/DAPO)
El modelo es competente, solo necesita memoria de hechos	RAG, no fine-tuning

Fine-tuning continuo es la versión disciplinada del segundo y tercer caso. La palabra clave es continuo: no es un evento puntual de “alineamos el modelo”, es un proceso que toca cada vez que la distribución del tráfico se desvía lo suficiente, o que aparecen nuevos casos de uso.

Las cuatro técnicas según la señal que captures

El cambio más importante de los últimos 12 meses ha sido el fin del monopolio de DPO. En 2024 todo equipo que hacía alineamiento usaba DPO con pares (chosen, rejected). En 2026 la elección es más fina y depende de cómo es la señal que recoges en tu producto:

Señal real en producto	Técnica recomendada	Por qué
Ejemplos correctos etiquetados (input → output esperado)	SFT + LoRA	Sigue siendo la base. 500-5.000 ejemplos bastan para estilo.
Pares explícitos `(chosen, rejected)`	DPO o SimPO	SimPO elimina el modelo de referencia → 50 % menos VRAM en entrenamiento.
👍 / 👎 sueltos sobre respuestas	KTO	El método que más naturalmente encaja con la telemetría real.
SFT y preferencias en una sola pasada	ORPO	Un solo modelo en memoria, evita el drift entre fases.
Recompensa verificable (tests, soluciones)	GRPO / DAPO	Razonamiento, no chat. Otro mundo.

La regla práctica: diseña la captura de feedback en producto pensando en qué método podrás usar después. Si tu UI sólo tiene 👍/👎, fuerzas el camino a KTO. Si añades un botón “regenerar respuesta”, desbloqueas DPO desde el regenerate-as-rejected (lo veremos abajo). Si añades un botón “editar respuesta”, la respuesta editada se convierte en SFT directo de alta calidad.

Hay un detalle de coste que se publicita poco. DPO necesita mantener en memoria dos modelos: el que entrenas y el de referencia. SimPO elimina ese segundo modelo. ORPO también. Para un Llama 3 8B en BF16 esto es la diferencia entre necesitar ~32 GB de VRAM activos durante entrenamiento (DPO) o ~16 GB (SimPO/ORPO). Es la diferencia entre que el entrenamiento quepa en una RTX 4090 con QLoRA agresivo, o no quepa sin offload.

Postgres como sistema nervioso del pipeline

Aquí está la opinión técnica fuerte de este artículo, y es la que conviene defender con datos: Postgres 18 + pgvector 0.8 + un bucket S3/MinIO para los pesos es suficiente para todo el pipeline. No hace falta MLflow, no hace falta lakeFS, no hace falta DVC.

No se trata de minimalismo ideológico. Se trata de tres ventajas concretas que ningún stack alternativo iguala en el escenario on-premise con compliance:

Una sola fuente de verdad, un solo modelo de autorización. Las ACL que ya tienes para Postgres cubren los datos de entrenamiento, los resultados de eval, el registry de adapters y el log de auditoría. No multiplicas planos de control.
SQL como lenguaje universal del pipeline. El query que genera el dataset, el predicado del eval gate, la asignación de tráfico A/B, la decisión de promoción: todo es SQL. Tu equipo ya sabe SQL.
Audit y reproducibilidad criptográfica gratis. Las extensiones pg_audit y pgcrypto, combinadas con set_hash sobre el dataset, te dan trazabilidad criptográfica sin código adicional. Es un terreno que da para artículo propio.

Esquema concreto

Empezamos por la tabla de tráfico, particionada por semanas para que el DROP PARTITION sea barato:

CREATE TABLE obs.inference_log (
 id BIGSERIAL,
 request_id UUID NOT NULL,
 tenant_id INT NOT NULL,
 user_hash BYTEA, -- pseudonimización GDPR
 adapter_id TEXT NOT NULL, -- ej. "support-es-v4.1"
 experiment TEXT, -- ej. "rerank-v2-canary"
 variant CHAR(1), -- 'A' | 'B' | NULL
 messages JSONB NOT NULL,
 completion TEXT,
 ttft_ms INT,
 tokens_in INT,
 tokens_out INT,
 -- señales de feedback
 fb_explicit SMALLINT, -- -1/0/+1 (KTO-ready)
 fb_regen BOOLEAN DEFAULT false, -- usuario regeneró → DPO-rejected
 fb_edited BOOLEAN DEFAULT false, -- usuario editó → SFT golden
 parent_id BIGINT, -- autoreferencia regenerate
 -- vector y meta
 embedding HALFVEC(1024), -- pgvector 0.8, mitad de RAM
 pii_flags SMALLINT DEFAULT 0, -- bitmask
 created_at TIMESTAMPTZ DEFAULT now()
) PARTITION BY RANGE (created_at);

CREATE TABLE obs.inference_log_2026w21 PARTITION OF obs.inference_log
 FOR VALUES FROM ('2026-05-18') TO ('2026-05-25');

CREATE INDEX ON obs.inference_log_2026w21
 USING hnsw (embedding halfvec_cosine_ops);
CREATE INDEX ON obs.inference_log_2026w21
 (tenant_id, adapter_id, created_at);

Tres decisiones merecen una nota:

HALFVEC(1024). Vectores en FP16 nativos de pgvector 0.8. La mitad de RAM y disco con pérdida de precisión irrelevante para deduplicación semántica. Esto solo, a escala de millones de filas, ahorra entre 4 y 8 GB.

Particionado semanal por rango temporal. A los 90 días, DROP TABLE obs.inference_log_2026wXX libera espacio en milisegundos sin bloqueo prolongado. Autovacuum nunca vuelve a tocar particiones congeladas.

parent_id autoreferenciado. El usuario regenera la respuesta → se inserta una nueva fila con parent_id apuntando a la anterior. Eso nos dará un dataset DPO sin tocar la UX.

El registry de adapters

CREATE TABLE serve.adapter (
 id TEXT PRIMARY KEY,
 base_model TEXT NOT NULL,
 rank INT, alpha INT,
 target_modules JSONB,
 method TEXT, -- 'sft'|'dpo'|'kto'|'orpo'|'simpo'
 training_run_id UUID,
 dataset_snapshot_id UUID,
 weights_uri TEXT, -- s3://.../v4.2.safetensors
 eval_summary JSONB,
 status TEXT NOT NULL, -- 'training'|'canary'|'prod'|'retired'
 traffic_pct NUMERIC(5,2) DEFAULT 0,
 promoted_at TIMESTAMPTZ
);

El router de vLLM lee esta tabla con TTL de pocos segundos. Un UPDATE serve.adapter SET status='prod', traffic_pct=100 WHERE id='v4.2' es una promoción. Un UPDATE ... SET status='retired' es un rollback. La auditoría de quién hizo qué y cuándo la da pg_audit sin escribir una línea de código adicional.

Generar datasets DPO y KTO desde tráfico real

Aquí es donde la elegancia del esquema paga. El dataset no es un fichero estático: es una vista materializada que se construye con SQL sobre obs.inference_log.

Dataset KTO desde 👍/👎

KTO es el método que mejor encaja con la señal que captura cualquier producto de chat decente. La query:

CREATE MATERIALIZED VIEW train.kto_v3_candidate AS
SELECT
 messages AS prompt,
 completion AS response,
 CASE WHEN fb_explicit > 0 THEN true ELSE false END AS label,
 adapter_id, created_at
FROM obs.inference_log
WHERE fb_explicit != 0
 AND created_at > now() - interval '60 days'
 AND pii_flags = 0
 AND tenant_id IN (SELECT id FROM tenant WHERE consent_training);

Simple. Cada fila con feedback explícito se convierte en un ejemplo (prompt, response, deseable_sí_no). KTO entrena directamente sobre esta señal, sin necesidad de construir pares.

Dataset DPO desde “regenerar”

El truco que vale por sí solo este artículo. Cuando el usuario pulsa “regenerar respuesta”, está dando una señal extraordinariamente fuerte: la primera respuesta no le valió. Si la segunda no se regenera ni se valora negativamente, asumimos que sí. Eso es un par DPO sin un solo clic adicional en la UI:

CREATE MATERIALIZED VIEW train.dpo_v3_candidate AS
SELECT
 rej.messages AS prompt,
 cho.completion AS chosen,
 rej.completion AS rejected,
 rej.adapter_id
FROM obs.inference_log rej
JOIN obs.inference_log cho ON cho.parent_id = rej.id
WHERE rej.fb_regen = true
 AND cho.fb_explicit >= 0
 -- mitigación de length bias en DPO clásico
 AND cho.tokens_out BETWEEN rej.tokens_out * 0.5
 AND rej.tokens_out * 2.5;

La cláusula sobre longitudes es la cura barata al length bias documentado en DPO. Sin ella, el modelo aprende que “más largo = mejor” porque las respuestas que el usuario acepta tienden a ser ligeramente más largas. Con SimPO o ORPO este filtro es opcional; con DPO clásico es necesario.

Deduplicación semántica con pgvector

Antes de entrenar, dedup. Dos prompts casi idénticos en el dataset es ruido que sesga el modelo:

WITH ranked AS (
 SELECT id, embedding,
 row_number() OVER (
 PARTITION BY hashtext(messages::text)
 ORDER BY fb_explicit DESC, created_at DESC
 ) AS rn
 FROM obs.inference_log
 WHERE created_at > now() - interval '60 days'
)
DELETE FROM train.kto_v3_candidate kto
USING ranked r
WHERE r.rn > 1 AND kto.id = r.id;

Y para los duplicados semánticos (paráfrasis) usamos directamente pgvector 0.8 con iterative index scan:

-- Buscar near-duplicates de un ejemplo cualquiera
SELECT id, messages, embedding <=> $1 AS dist
FROM obs.inference_log
WHERE created_at > now() - interval '60 days'
 AND embedding <=> $1 < 0.05
ORDER BY embedding <=> $1
LIMIT 50;

El iterative scan es una mejora clave de pgvector 0.8: antes, el índice HNSW podía devolver menos resultados de los pedidos cuando había filtros adicionales (WHERE); ahora itera hasta cumplir el límite. Sin esa mejora, las queries de curación sobre datasets de millones de filas eran inviables sin un pre-filtro brutal.

Eval gates: tres etapas, todo SQL

El error más común al implementar fine-tuning continuo es saltarse o aligerar los eval gates. Eso convierte el ciclo en una ruleta. El patrón que funciona en 2026 son tres etapas, cada una con un trade-off latencia/cobertura distinto:

Y aquí es donde Postgres vuelve a brillar: el gate de promoción se expresa como un predicado SQL. Nada más:

CREATE TABLE train.eval_result (
 adapter_id TEXT REFERENCES serve.adapter(id),
 suite_id TEXT, -- 'safety-es', 'support-helpfulness'
 metric TEXT,
 score NUMERIC,
 judge_model TEXT,
 judged_at TIMESTAMPTZ DEFAULT now(),
 PRIMARY KEY (adapter_id, suite_id, metric)
);

CREATE OR REPLACE FUNCTION serve.can_promote(candidate TEXT, current TEXT)
RETURNS BOOLEAN AS $$
 SELECT NOT EXISTS (
 SELECT 1
 FROM train.eval_result c
 JOIN train.eval_result p USING (suite_id, metric)
 WHERE c.adapter_id = candidate
 AND p.adapter_id = current
 AND suite_id IN ('safety-es','support-helpfulness','refusal-rate')
 AND c.score < p.score * 0.98 -- tolerancia 2 %
 );
$$ LANGUAGE sql STABLE;

Una función SQL como gate. Aplicable desde el CI con psql -c "SELECT serve.can_promote('v4.2','v4.1')" y un exit code 0/1. No hace falta un orquestador, no hace falta una UI específica. La auditoría queda en el log de Postgres.

vLLM multi-LoRA: el deploy es un POST HTTP

Hace dos años, desplegar un fine-tune nuevo era rotar pods de inferencia. Hoy es una llamada HTTP. vLLM 0.7+ soporta cargar y descargar adapters LoRA en caliente, manteniendo varios residentes en VRAM y eligiendo el correcto por petición.

Configuración del servidor:

vllm serve meta-llama/Llama-3.1-8B-Instruct \
 --enable-lora \
 --max-loras 4 \
 --max-lora-rank 64 \
 --env VLLM_ALLOW_RUNTIME_LORA_UPDATING=True

Despliegue de un adapter nuevo:

curl -X POST http://localhost:8000/v1/load_lora_adapter \
 -H "Content-Type: application/json" \
 -d '{
 "lora_name": "support-es-v4.2",
 "lora_path": "/mnt/adapters/support-es-v4.2"
 }'

A partir de ese momento, las peticiones que incluyen "model": "support-es-v4.2" se sirven con ese adapter aplicado sobre el modelo base. El switch entre adapters tiene latencia despreciable (la investigación más reciente sobre Activated LoRA lleva esto a niveles donde el coste de cambio es invisible).

Esto cambia la operación de forma sustancial. El despliegue de un fine-tune nuevo deja de ser un evento de infraestructura para convertirse en un cambio de estado en Postgres. El router consulta la tabla serve.adapter, ve que v4.2 está en canary con traffic_pct=5, y dirige el 5 % de peticiones al nuevo adapter. La ruta exacta del 5 % se decide con hashing determinístico del user_id para que un mismo usuario siempre vea la misma variante (sticky):

-- Sin tabla de asignación, sin estado adicional
-- el variant se calcula in-place en SQL o en el router:
SELECT
 CASE WHEN hashtext($user_id || $experiment) % 100
 < (SELECT traffic_pct FROM serve.adapter WHERE id = $candidate)
 THEN $candidate ELSE $current END AS adapter_id;

A/B con tráfico real: medir o vivir engañado

Los eval gates miden contra benchmarks fijos. Eso es necesario pero insuficiente. La realidad solo se mide con tráfico real. Una vez el adapter está en canary, lo que importa son las métricas online medidas sobre obs.inference_log para cada variante:

SELECT
 adapter_id,
 COUNT(*) AS n,
 AVG(fb_explicit) AS mean_score,
 STDDEV(fb_explicit) / SQRT(COUNT(*)) AS sem,
 AVG(ttft_ms) AS ttft_avg,
 percentile_cont(0.5) WITHIN GROUP
 (ORDER BY ttft_ms) AS ttft_p50,
 percentile_cont(0.95) WITHIN GROUP
 (ORDER BY ttft_ms) AS ttft_p95,
 AVG(CASE WHEN fb_regen THEN 1 ELSE 0 END) AS regen_rate
FROM obs.inference_log
WHERE experiment = $1
 AND created_at > now() - interval '7 days'
GROUP BY adapter_id;

Lo que se mira: feedback explícito, latencia (TTFT, p50, p95), tasa de regeneración. Un adapter que sube el feedback medio pero también sube la tasa de regeneración es sospechoso —probablemente está respondiendo de forma más vistosa pero menos útil—. Un adapter que baja la latencia pero baja el feedback puede merecer estudio: puede que esté siendo más conciso de la cuenta.

La promoción a prod ocurre cuando, después de 24-72 horas en canary, el adapter candidato supera al actual en al menos una métrica clave sin degradar las demás. Otra vez: es un UPDATE en Postgres.

Aplicado a hardware on-premise típico

Bajemos a dos configuraciones representativas, una de iteración y otra de producción.

Caso 1 — RTX 4090 (24 GB) para iteración de desarrollo

Una RTX 4090 con QLoRA 4-bit puede entrenar adapters sobre un modelo 8B sin sobresalto. El presupuesto de VRAM combina cuatro componentes; el KV cache durante las evaluaciones intermedias no es despreciable y conviene reservarle margen explícito:

Modelo base 8B en 4-bit: ~5 GB
Activations + gradientes: ~8 GB (depende de batch y context)
Optimizer state (LoRA r=16): ~0.5 GB
KV cache durante eval: ~2 GB
Margen de seguridad: ~8 GB

Tiempos típicos (estimación basada en benchmarks comunitarios; conviene medir con el lab antes de prometer):

Dataset	Técnica	Adapter rank	Tiempo aproximado
1.000 ejemplos SFT	LoRA r=16	16	20-40 min
5.000 ejemplos SFT	LoRA r=32	32	2-4 h
2.000 pares DPO	LoRA r=16	16	1-2 h
5.000 ejemplos KTO	LoRA r=32	32	3-5 h

Esto pone el ciclo de iteración —cambio en dataset, retrain, eval, ver número— en franja de una jornada de trabajo. Suficiente para validar hipótesis antes de mover nada al cluster de producción.

Caso 2 — Cluster 4×H100 SXM (320 GB, NVLink) para producción

Con un cluster de este orden todo el escenario cambia. Se puede:

Entrenar LoRA sobre 70B en BF16 sin quantización con tensor parallel = 4.
Hacer DPO completo con modelo de referencia residente cuando se cuantiza la referencia a FP8, o pasarse a SimPO / ORPO que eliminan ese modelo intermedio y simplifican la planificación de VRAM (ver tabla de técnicas más arriba).
Soportar multi-tenant fine-tuning: varios adapters de clientes entrenándose en paralelo en pipelines lógicos separados, cada uno aislado en una partición distinta de Postgres con sus propias ACLs.
Servir multi-LoRA con --max-loras 8 sobre el modelo base sin que la concurrencia baje el throughput de forma perceptible.

La regla práctica de presupuesto: en horizonte de 12 meses, un equipo con este cluster puede ejecutar ~150-200 ciclos de fine-tuning continuo (training + eval + canary + promoción o descarte) si la disciplina del dataset y de los eval gates es estricta. Si no lo es, ejecutará el doble pero con la mitad de utilidad.

Posición dentro de la arquitectura: lo que cubre este artículo y lo que no

Para situar el alcance: el ciclo dibujado al principio tiene siete cajas, todas ellas cubiertas aquí en su mecánica. Quedan deliberadamente fuera tres capas transversales que son las que terminan separando un pipeline que funciona técnicamente de uno que sobrevive a una auditoría:

Provenance criptográfico y trazabilidad. Hemos mencionado dataset_snapshot y pg_audit, pero la mecánica completa —el set_hash sobre los ejemplos, la integración con EU AI Act, el query_sql congelado como prueba de qué entrenó al modelo— da para análisis entero.
Calibración del juez. Hemos asumido que LLM-as-judge funciona. Hace falta calibrarlo contra rúbrica humana en, al menos, 100 casos por suite crítica antes de fiarse. Sin esa calibración, los eval gates son teatro.
El problema del olvido. ¿Qué pasa si un usuario ejerce su derecho al olvido GDPR y sus interacciones formaron parte del dataset de un adapter ya en producción? No hay solución limpia. Hay opciones —retrain incremental, machine unlearning a nivel de muestra, negative LoRA— y conviene conocerlas antes de que un cliente pregunte.

Lo que no hemos cubierto (próximos artículos)

Provenance criptográfico sobre Postgres: cómo set_hash y query_sql congelado componen una cadena de custodia auditable bajo EU AI Act.
Judge calibration honesta: por qué score > 0.85 no significa nada sin baseline humana, y cómo construir esa baseline sin que cueste un mes de trabajo.
El problema del olvido en adapters: machine unlearning a nivel de muestra, retrain incremental y otras técnicas para responder a GDPR sin tirar el adapter.
Online DPO y aprendizaje continuo on-policy: estado de la investigación 2026 (Fast-Slow Chasing, RLOO, iterative on-policy) y por qué todavía no es producción.

Ver también

El pipeline LLMOps de seis etapas — el mapa maestro al que pertenecen las etapas Tune y Retrain. Este post es el deep-dive operativo de ese ciclo.
MLOps específico para LLMs en 2026: el panorama — apertura de la serie. Sitúa el fine-tuning continuo dentro del marco de tres modalidades (fine-tuning, RAG, agents) y siete diferencias estructurales con MLOps clásico.
PostgreSQL + Qdrant en la etapa de ingestión — la etapa Data que alimenta este ciclo: cómo entran los eventos en Postgres y los embeddings en Qdrant que después este post curaría como dataset.
Evals: la capa después del tracing — la etapa Eval del pipeline. Las eval gates que aquí se describen como predicados SQL son la materialización del framework genérico de aquel post.
El cluster GPU como plataforma multi-tenant — la etapa Deploy donde el multi-LoRA hot-swap descrito aquí convive con quotas, gateway y aislamiento.
KV cache: la memoria de trabajo que sostiene la inferencia LLM — los fundamentos del cache que entra en juego en cada eval intermedia del entrenamiento y en cada despliegue del adapter resultante.
PagedAttention por dentro — la mecánica del KV cache y el panorama de optimizaciones (vAttention, EvicPress, RadixAttention) que sostienen el throughput de las eval intermedias del pipeline de fine-tuning.
Disaggregated serving: prefill y decode en pods especializados — el patrón de serving al que se conecta el multi-LoRA hot-swap descrito aquí: cada pod especializado carga sus adapters por separado.
Data versioning para LLMOps: DVC, lakeFS y golden dataset reproducible — la posición opuesta. Este post defiende un stack minimalista (Postgres + pgvector + S3) sin DVC/lakeFS; el otro explica cuándo se cruza la línea y por qué.

Referencias

Hu et al., LoRA: Low-Rank Adaptation of Large Language Models (ICLR 2022).
Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs (NeurIPS 2023).
Rafailov et al., Direct Preference Optimization: Your Language Model is Secretly a Reward Model (NeurIPS 2023).
Meng, Xia, Chen, SimPO: Simple Preference Optimization with a Reference-Free Reward (NeurIPS 2024).
Hong et al., ORPO: Monolithic Preference Optimization without Reference Model (2024).
Ethayarajh et al., KTO: Model Alignment as Prospect Theoretic Optimization (2024).
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — vLLM original.
Documentación oficial de vLLM Multi-LoRA: https://docs.vllm.ai/en/stable/features/lora/.
Documentación oficial de pgvector 0.8: https://github.com/pgvector/pgvector.
TRL (HuggingFace) docs: https://huggingface.co/docs/trl.
EU AI Act, texto consolidado y calendario de aplicación: https://artificialintelligenceact.eu/.