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).

Feedback on lo0 — Blog Técnico