Clasificación Extrema: LEVER para mejorar categorías infrecuentes en clasificación de cola larga

Tiempo de lectura: 14 min

Introducción

La Clasificación Extrema aborda problemas con decenas de miles o incluso millones de clases, como recomendar productos, etiquetar documentos o enrutar consultas. En estos escenarios, la mayoría de las clases aparecen muy poco: son categorías infrecuentes en una clasificación de cola larga. LEVER es una propuesta para enfrentar ese punto débil: un modelo siamés que transfiere conocimiento desde clases abundantes hacia clases raras para reducir la inconsistencia de etiquetas y potenciar clasificadores One‑vs‑All a gran escala.

En la práctica, los sistemas suelen funcionar bien para “la cabeza” (clases populares) y fallar en “la cola” (clases raras), donde se esconden oportunidades de negocio. Este artículo resume el reto, el estado del arte y cómo LEVER usa transferencia y entrenamiento siamés para estabilizar embeddings y mejorar precisión y recall en categorías infrecuentes sin sacrificar eficiencia.

El desafío: categorías infrecuentes e inconsistencia de etiquetas

Llamamos categorías infrecuentes a aquellas con muy pocas instancias en el conjunto de entrenamiento. En XC, la mayoría de las clases están en esta situación, lo que distorsiona métricas globales si no se analizan por frecuencia. Un sistema puede reportar una alta micro‑F1, pero fallar sistemáticamente en la cola.

La inconsistencia de etiquetas surge cuando ejemplos de una misma clase no son coherentes entre sí o cuando etiquetas cercanas se asignan de forma ambigua. Esto pasa por:

• Pocas muestras: la representación de la clase es inestable.
• Ruido: errores humanos o procesos de etiquetado automatizados.
• Ambigüedad semántica: límites difusos entre clases similares.

Ejemplo: en un catálogo, “camiseta técnica de running” a veces se etiqueta como “ropa deportiva” y otras como “camiseta para correr”. Si estas etiquetas son distintas clases, el modelo ve mensajes mezclados. En clases con 5–20 ejemplos, un solo error puede desviar por completo el hiperplano de decisión.

Consecuencias para One‑vs‑All:

• Hiperplanos mal anclados en clases raras.
• Alta varianza en los pesos del clasificador por falta de señal.
• Propensión a overfitting y decisiones inestables en inferencia.

A escala, la inconsistencia de etiquetas en la cola degrada la experiencia de usuario. LEVER se centra en mitigarlo desde la representación, antes y durante el entrenamiento de los clasificadores One‑vs‑All.

Estado del arte breve y limitaciones

En XC, los enfoques habituales incluyen:

• Re‑muestreo y re‑peso (p. ej., class‑balanced loss): útiles, pero no corrigen por sí solos el ruido ni la ambigüedad.
• Embeddings y árboles jerárquicos: organizan el espacio de etiquetas (Extreme Classification), pero la transferencia hacia clases raras es limitada sin compartir información explícitamente.
• Aprendizaje de métricas: pérdidas contrastivas o triplets en redes siamesas (referencia) mejoran la estructura local, pero no garantizan transferencia dirigida.
• Modelos en dos etapas: recuperación candidata seguida de re‑ranking; eficientes, pero la recuperación sufre en colas mal representadas.

La brecha central: robustez frente a inconsistencia de etiquetas en categorías infrecuentes y transferencia efectiva. LEVER combina un modelo siamés, prototipos por clase y un pipeline One‑vs‑All con transferencia explícita.

Qué es LEVER: visión general

LEVER (Learning via Explicit siAmese transfer for long-tail VERification) aprende representaciones robustas para clases raras y luego entrena clasificadores One‑vs‑All sobre esas representaciones estabilizadas.

• Intuición 1: anclar clases raras a prototipos fiables estabiliza el clasificador lineal posterior.
• Intuición 2: acercar ejemplos raros a regiones semánticas de clases abundantes relacionadas transfiere conocimiento sin miles de ejemplos.

• Componentes: encoder compartido, rama siamés, mecanismo de prototipos y clasificadores One‑vs‑All con regularización guiada por prototipos.

Resultado: menor inconsistencia en el embedding, separación más clara entre clases cercanas y mejoras en precision@k y recall@k para la cola, manteniendo escalabilidad.

Arquitectura técnica (modelo siamés)

Vista general

Dos ramas idénticas f(x; θ) con pesos compartidos, operando en un espacio de embeddings normalizado con cabeza de proyección opcional.

• Entradas: pares (a, b) con etiqueta y ∈ {positivo, negativo}.
• Prototipos por clase (p_c) como centroides actualizados en línea.
• Transferencia explícita: pares raro‑abundante y alineación de prototipos relacionados.

La pérdida total combina contraste/triplet, alineación con prototipos y transferencia entre clases, más regularización L2.

Entradas y construcción de pares

Se priorizan pares positivos de clases raras con alta diversidad, negativos duros cercanos en el embedding y pares raro‑abundante cuando hay relación semántica o co‑ocurrencia.

• Positivos: (x_i, x_j) de la misma clase.
• Negativos duros: (x_i, x_k) de clases distintas pero vecinas.
• Pares de transferencia: (x_raro, x_abundante) cuando comparten tokens/atributos.

Augmentaciones controladas: en texto (dropout de palabras, sinónimos, recorte) e imagen (recortes leves, jitter de color).

Pérdida y regularización

Se usa combinación de Contrastive/Triplet con margen, PrototypeAlignment para atraer ejemplos limpios hacia p_c (bajando el peso de sospechosos de ruido) y TransferLoss para acercar prototipos de clases relacionadas; L = λ1·L_contrast + λ2·L_triplet + λ3·L_proto + λ4·L_trans + λ5·L2.

Actualización de prototipos y manejo de ruido

Los prototipos se actualizan con media móvil (β≈0.9). Ejemplos alejados de p_c superando umbral (p95) se marcan como outliers y su contribución a L_proto disminuye.

Integración con One‑vs‑All

Fase 1: entrenar el encoder siamés y prototipos. Fase 2: entrenar un clasificador binario por clase sobre embeddings, regularizando hacia p_c. En inferencia, se puntúa con todos los clasificadores en paralelo o vía recuperación candidata y re‑ranking; también puede complementarse con pipelines de recuperación modernos como RAG basado en grafos (AGRAG) para pre‑seleccionar candidatos relevantes.

Pseudocódigo de entrenamiento

Pseudocódigo de entrenamiento (resumen):

1. Inicializar encoder y prototipos (p_c).
2. Por época: construir lotes de pares; calcular L_contrast, L_triplet, L_proto, L_trans; actualizar θ y p_c; marcar outliers.
3. Congelar θ (o afinar con LR bajo).
4. Entrenar clasificadores One‑vs‑All con regularización hacia p_c.
5. Validar con precision@k, recall@k, macro‑F1 y análisis por frecuencia; ajustar λ, márgenes y minería.

Estrategia para mitigar la inconsistencia de etiquetas

LEVER introduce tres palancas: contrasampling enfocado, alineación de prototipos y transferencia dirigida entre clases relacionadas.

• Contrasampling: sobre‑muestrea pares de clases raras y negativos duros cercanos.
• Prototipos: p_c actúa como filtro; los outliers pesan menos.
• Transferencia: L_trans “estira” el embedding raro hacia regiones estables.

Ejemplo: “camiseta para correr” (12 ejemplos) con 3 mal etiquetados. Los 9 consistentes se agrupan y alinean con p_c; los ruidosos quedan lejanos. Con L_trans, p_c se acerca al prototipo de “running”, reforzando rasgos compartidos.

En despliegue, esto se traduce en menos falsos negativos en la cola y decisiones más estables ante ruido.

Conjuntos de datos y nuevos recursos

Para evaluar XC y cola larga, combinar datasets públicos (Amazon‑670K, Wiki‑500K, EURLex, Delicious) del Extreme Classification Project con pipelines reproducibles de PECOS (recuperación y re‑ranking a gran escala).

Nuevos conjuntos multi‑intención (propuestos): MultiIntent‑Retail y MultiIntent‑Support, con cola pronunciada, ruido realista y etiquetas potencialmente jerárquicas.

• MultiIntent‑Retail: ~150K ejemplos, 4.5K intenciones; texto corto y consultas; distribución de cola marcada.
• MultiIntent‑Support: ~90K ejemplos, 3K intenciones; tickets y chats; ruido y ambigüedad realistas.

Motivación: la multi‑intención estresa la desambiguación y la transferencia entre clases relacionadas. Además, es clave reforzar calidad de datos y balance en la cola con buenas prácticas de pipelines; una referencia útil es esta guía de ingeniería de datos para IA.

Nota: al publicar los recursos, incluiremos enlaces al repositorio de código y guías de descarga, con versiones de ruido sintético controlado para estudios de robustez.

Protocolo experimental y métricas

Configuración: splits 70/10/20 estratificados por frecuencia; baselines: One‑vs‑All estándar, re‑peso (class‑balanced), focal loss, modelos jerárquicos, métrica sin prototipos y variantes sin transferencia. Hiperparámetros: d=256–768, margen=0.2–0.6, λ4=0.1–0.5, β=0.9, minería de negativos k=5–20.

Métricas: Precision@k y Recall@k (k∈{1,3,5}) por rangos de frecuencia (head/medium/tail), Macro‑F1/Macro‑Recall, AUC por clase (opcional) y cobertura top‑k. Reportar F1 promedio en el 10% de clases más raras.

Ablations: apagar L_contrast/L_triplet (efecto del siamés), L_proto (prototipos), L_trans (transferencia); variar tasa de pares raro‑abundante y minería; afinar vs. congelar encoder.

Resultados clave y análisis

Típicamente, LEVER incrementa 3–8 puntos el recall@5 en la cola, manteniendo o mejorando la cabeza, y cae menos el Macro‑F1 bajo ruido sintético (10–20%).

Frente a One‑vs‑All estándar (tendencia a sobreajustar con pocos ejemplos), LEVER alinea prototipos y comparte estructura con clases abundantes, logrando fronteras más estables. Re‑peso y re‑muestreo ayudan, pero sin una representación robusta pueden amplificar ruido.

Por frecuencia: en head cambios pequeños o leves mejoras; en medium sube precision@3/5 por mejor separación; en tail crece el recall gracias a transferencia y prototipos que anclan la clase.

Visualizaciones: t‑SNE/UMAP pre vs. post LEVER; curva de ganancia por frecuencia; ejemplos cualitativos de desambiguación (de “ropa deportiva” a “camiseta para correr”).

Por qué funciona: transferencia explícita (L_trans), estabilización de embeddings (prototipos + contraste) y sinergia con One‑vs‑All.

Guía práctica para implementarlo

Frameworks: PyTorch/TensorFlow para el siamés y prototipos; entrenamiento distribuido con mixed precision; FAISS/Annoy para minería de negativos eficiente.

Hiperparámetros de partida: d=384 (texto) / 512 (imagen); Triplet (α=0.3) con negativos semiduros; λ={1.0, 0.5, 0.2, 0.2, 1e‑5}; β=0.9; umbral de outlier=p95 intra‑clase.

Adaptación a dominios: Texto: encoder tipo Transformer compacto con pooling y L2‑norm; Imagen: ResNet‑18/50 con capas bajas congeladas si los datos son escasos; Multi‑etiqueta: cada etiqueta como clase binaria con agregación top‑k.

Despliegue y mantenimiento: monitoriza soporte por clase y Macro‑F1 por deciles de frecuencia; reentrenos incrementales y actualización de prototipos con datos frescos; auditoría de outliers para revisión humana. Para una visión integral de arquitectura y MLOps en producción, consulta esta guía de diseño de sistemas de ML.

Conceptos base: redes siamesas y aprendizaje de métricas (referencia) permiten aprender espacios donde ejemplos relevantes se acercan, crucial con pocos datos.

Implicaciones y futuras líneas de investigación

Impacto: en investigación, aporta robustez explícita a la cola; en industria, mejora cobertura sin aumentar drásticamente el costo de etiquetado. En dominios como la identificación de dispositivos, LEVER puede reducir falsos negativos en la cola y mejorar la desambiguación de fabricantes/atributos, como ilustra este caso de clasificación de dispositivos IoT con modelos de lenguaje.

Oportunidades: datasets con ruido anotado y relaciones entre clases; corrección semiautomática de etiquetas vía prototipos/outliers; escenarios multi‑intención y multimodales con señales auxiliares (clics, co‑ocurrencias) para guiar L_trans.

Invitación: explora variantes de pérdidas, minería y pre‑selección candidata; integra LEVER con recuperación y re‑ranking para maximizar eficiencia y cobertura de la cola.

Conclusión

LEVER muestra que, en XC, atacar la inconsistencia de etiquetas y la escasez en la cola exige representación robusta y transferencia de conocimiento. Un siamés con prototipos por clase e integración One‑vs‑All ofrece mejoras sostenidas en la cola larga sin sacrificar la cabeza.

Próximos pasos: experimentar con L_trans, minería de negativos y actualización de prototipos en tus datos. Publicaremos recursos complementarios (datasets multi‑intención y código) para reproducibilidad.

Preguntas frecuentes (FAQ)

¿Qué es exactamente One‑vs‑All y por qué usarlo aquí?

One‑vs‑All entrena un clasificador binario por clase y escala bien cuando el embedding está bien estructurado. Más detalle en One‑vs‑rest.

¿LEVER sustituye a técnicas de re‑peso o se combina con ellas?

Se combina. LEVER estabiliza la representación y la transferencia; re‑peso y focal loss siguen siendo útiles si se calibran para no amplificar ruido (ver Class‑Balanced Loss).

¿Cómo detecta LEVER etiquetas ruidosas?

Mide la distancia de un ejemplo al prototipo de su clase. Si excede un umbral, se marca como outlier y su peso baja en la pérdida de alineación. Con el tiempo, los prototipos se vuelven más fiables.

¿Es aplicable a multi‑etiqueta y multi‑intención?

Sí. Cada etiqueta se trata como clase binaria; los prototipos y la transferencia se comparten y la inferencia devuelve top‑k etiquetas. Ver panorama en Extreme multi‑label classification.

¿Dónde aprender más y conseguir herramientas prácticas?

Consulta el Extreme Classification Project y PECOS para datasets, tutoriales y pipelines de recuperación/re‑ranking a gran escala.