¿Cuántos ejemplos etiquetados necesita realmente un clasificador de texto? Lo medí.

Los equipos de preguntas se saltan

“Simplemente use un LLM para ello” se ha convertido en la respuesta predeterminada a casi cualquier problema de clasificación de texto: enrutar tickets de soporte, etiquetar comentarios y clasificar solicitudes entrantes. La clasificación de tiro cero con un LLM moderno no necesita ningún dato de capacitación, lo que la convierte en una opción predeterminada fácil cuando comienza un proyecto.

Pero esa conveniencia tiene un costo que la mayoría de los equipos nunca miden: la clasificación LLM significa una llamada de red y un cargo por solicitud en cada artículo, para siempre. Una línea de base clásica como TF-IDF más un clasificador lineal no cuesta nada para ejecutarla una vez entrenada: sin API, sin red de ida y vuelta, inferencia de menos de un milisegundo. La pregunta que vale la pena responder antes de optar por un LLM no es “qué método es mejor” en abstracto. La pregunta es: ¿cuántos datos etiquetados tengo realmente y qué tan buena es la opción instantánea y gratuita?

Realicé un experimento pequeño y concreto para responder a eso en un caso común (enrutar tickets de soporte en categorías) y medí exactamente cómo la precisión aumenta a medida que los ejemplos etiquetados aumentan de apenas nulos a modestos.

La configuración

Tarea: clasifique los tickets de soporte en una de cinco categorías: facturación, error_técnico, solicitud_de_función, acceso_cuenta, pregunta_general.

Conjunto de datos: 70 tickets, 14 por categoría, que escribí yo mismo como ejemplos sintéticos; no hay datos de clientes reales o extraídos en ninguna parte de este experimento. Deliberadamente mezclé ejemplos claros (“Me cobraron dos veces por mi suscripción”) con otros ambiguos que posiblemente podrían dividirse en dos categorías (“¿Hay un descuento para estudiantes disponible?”: ¿facturación o pregunta de política general?). Las colas de soporte reales se ven así; un punto de referencia creado únicamente a partir de ejemplos inequívocos no le dice nada útil sobre el rendimiento de la producción.

Conjunto de prueba fijo: 20 boletos (4 por categoría), retenidos y nunca utilizados para entrenamiento, por lo que cada configuración se juzga con los mismos ejemplos invisibles.

Método: vectorización TF-IDF (unigramas + bigramas) que alimenta un clasificador de regresión logística, entrenado en tres volúmenes de datos diferentes (2, 5 y 10 ejemplos etiquetados por categoría) para aislar la única variable que realmente cambia durante la vida de un proyecto: la cantidad de datos etiquetados que ha acumulado.

(El script ejecutable completo (conjunto de datos, división de entrenamiento/prueba y bucle de evaluación en un solo archivo) está vinculado al final).

Los resultados

Destacan tres cosas.

La precisión aumenta bruscamente al principio y luego se aplana. Pasar de 2 a 5 ejemplos por categoría obtuvo +15 puntos de precisión: el movimiento de mayor apalancamiento en todo este experimento. Pasando de 5 a 10 compré solo +5 más. Esa es la clásica curva de rendimientos decrecientes de un clasificador lineal en un vocabulario pequeño, y vale la pena saberlo antes de comprometer el presupuesto a etiquetar cientos de tickets más: el primer puñado de ejemplos por categoría importa mucho más que el siguiente puñado.

La inferencia es efectivamente instantánea y gratuita. Submilisegundo, en el dispositivo, sin llamada API, sin línea de pedido por solicitud. En cualquier volumen de tickets significativo, eso no es un error de redondeo: es la diferencia entre un paso de enrutamiento sin costo recurrente y uno que escala linealmente con cada solicitud que procesa.

Incluso con una precisión del 60%, este no es un territorio de “desplegarlo y marcharse”. Un enrutador que clasifica erróneamente 2 de cada 5 tickets es un problema real del producto. Lo interesante no es que TF-IDF “gane” o “pierda”, sino dónde se ubica la curva en relación con lo que su producto puede tolerar.

Dónde estallaron realmente los casos ambiguos

La precisión agregada oculta el diagnóstico más útil: qué tickets se equivocó el clasificador y si más datos realmente lo solucionan. Registré cada clasificación errónea en cada tamaño de entrenamiento y aparecieron dos patrones de falla distintos.

Algunos errores son pura falta de datos: más etiquetas los solucionan. En 2 ejemplos/categoría, tickets como “¿Puedes restablecer mi contraseña? El correo electrónico de restablecimiento nunca llega” (verdadero: acceso_cuenta, previsto: facturación) y “¿Cómo elimino mi cuenta y todos los datos asociados?” (verdadero: acceso_cuenta, previsto: pregunta_general) ambos estaban equivocados. Por 10 ejemplos/categoría, ambos fueron clasificados correctamente. El modelo simplemente no había visto suficiente vocabulario de acceso a cuentas todavía en volúmenes de datos bajos.

Otros errores son estructurales: nunca desaparecieron, sin importar cuántos datos agregué. Se clasificaron erróneamente dos tickets en cada tamaño de entrenamiento, de 2 a 10 ejemplos/categoría:

“¿Hay un descuento para estudiantes disponible en el plan profesional?” – facturación verdadera, error_técnico previsto en n=2, luego pregunta_general tanto en n=5 como en n=10. El modelo nunca se decidió por la respuesta correcta; simplemente se movió entre los equivocados. “Descuento” y “plan” no eliminan la ambigüedad de una cuestión de política de precios de una disputa sobre cargos reales; eso requiere comprender la intención, no sólo el vocabulario.

“La aplicación móvil cierra mi sesión cada pocos minutos”. – error_técnico verdadero, solicitud_de_característica prevista en cada tamaño de entrenamiento. Nada en la redacción superficial (“aplicación móvil”, “desconectarme”) señala a TF-IDF hacia un “error” en lugar de una “solicitud de función”; esa distinción vive enteramente en el tono y la urgencia implícita, a los que un modelo de bolsa de palabras no tiene acceso.

Ese es el verdadero hallazgo, no sólo el número de precisión: más datos etiquetados corrigen de manera confiable los errores de falta de datos, pero no hacen nada por los errores arraigados en la intención que el vectorizador literalmente no puede ver. Esas dos categorías de fallas requieren soluciones diferentes: una requiere más etiquetas, la otra requiere un enfoque fundamentalmente diferente del texto (o un paso de revisión humana, o un modelo que razona sobre la intención en lugar de la frecuencia de las palabras).

Este es exactamente el tipo de ambigüedad que la clasificación LLM de tiro cero es adecuada para manejar, ya que puede razonar sobre la intención en lugar de simplemente hacer coincidir el vocabulario, razón por la cual “cuántos datos etiquetados tienes y qué tipo de errores estás viendo realmente” es la primera pregunta correcta, no “qué método es más inteligente”. Con datos etiquetados cercanos a cero, no existe una línea de base clásica con la que comparar en primer lugar. El umbral interesante es donde un modelo clásico, entrenado con los datos que realmente tienes, comienza a cerrar esa brecha, y donde estructuralmente no puede hacerlo, sin importar cuántos datos le arrojes.

Donde este enfoque se queda corto

Datos sintéticos: yo mismo escribí los 70 tickets, los tickets reales tienen errores tipográficos, frases desiguales y volúmenes de categorías sesgados que tienden a dañar más un modelo de bolsa de palabras que un LLM. Vale la pena validarlo con una pequeña muestra de tickets reales antes de confiar en esta curva.

División única: estos números provienen de una división aleatoria de tren/prueba, que cambiaría con una reorganización, especialmente en 2 ejemplos/categoría. Promediar unas pocas semillas sería más riguroso.

Conjunto de pruebas pequeño: 20 ejemplos significa que una predicción invertida cambia la precisión en 5 puntos. Lea la tabla como si mostrara la forma de la curva, no un punto de referencia preciso.

El marco de decisión real

La elección correcta no es “TF-IDF vs. LLM” como una decisión arquitectónica fija; es una función de tres cosas que cualquier equipo puede responder en su propio caso:

¿Cuántos datos etiquetados tienes en este momento? Casi cero, y un modelo clásico aún no se puede utilizar: 2 ejemplos por categoría solo te dan el 40% aquí. Unas pocas docenas de ejemplos por categoría y el panorama cambia considerablemente; este experimento solo probó hasta 10.

¿Cuál es su volumen y qué efecto tiene eso en la línea de costos? El costo de un modelo clásico se fija una vez entrenado. Todo lo que se cobra por solicitud aumenta linealmente con cada ticket que procesa; vale la pena modelarlo explícitamente según su volumen real, no juzgado por un único número por llamada.

¿Cuál es su presupuesto de latencia? La inferencia local de menos de un milisegundo frente a un viaje de ida y vuelta en la red es una limitación real del producto para cualquier cosa orientada al usuario o en tiempo real, y en gran medida irrelevante para un trabajo por lotes en segundo plano.

Un patrón que vale la pena considerar directamente: use la clasificación de disparo cero para generar etiquetas cuando no tenga ninguna, luego entrene un modelo clásico en esas etiquetas una vez que haya acumulado suficientes. Obtiene un sistema que funciona desde el primer día sin problemas de arranque en frío y con un costo marginal cercano a cero una vez que tiene los datos, los cuales, según este experimento, podrían llegar más rápido de lo esperado, ya que incluso 5 a 10 ejemplos por categoría dieron un salto de precisión real.

la comida para llevar

El número que debería impulsar una decisión sobre la arquitectura de clasificación no es “qué método obtiene una puntuación más alta en abstracto”. Lo importante es la cantidad de datos etiquetados que tiene hoy, la rapidez con la que crece ese número y lo que una clasificación errónea realmente le cuesta a su producto. La curva de rendimientos decrecientes anterior es específica de este conjunto de datos y esta tarea, pero la forma de la pregunta, “¿cuánto me comprará realmente mi próximo lote de etiquetas?”, es una que cada equipo que construye un clasificador debería medir con sus propios datos antes de optar por cualquiera de las respuestas de forma predeterminada.

El punto de referencia completo (conjunto de datos, división de entrenamiento/prueba y bucle de evaluación) es un script único e independiente, no se requieren claves API ni archivos externos.