Qué es la anotación de datos (data labeling) y cuándo la necesitas

El dolor real detrás del etiquetado

Toda empresa que se mete a construir o ajustar un modelo de IA llega, tarde o temprano, al mismo cuello de botella: alguien tiene que decirle al sistema qué es correcto y qué no lo es, ejemplo por ejemplo. Ese trabajo suena simple en una reunión de planeación. En la práctica se convierte en semanas de personas revisando miles de casos, discutiendo entre ellas qué categoría aplica y corrigiendo criterios que cambiaron a mitad de camino.

Un caso real y anónimo: una empresa de retail mediana en Colombia quería clasificar automáticamente los comentarios de servicio al cliente en quejas, consultas y elogios. El equipo de datos armó una hoja de cálculo, repartió miles de comentarios entre cinco personas y les pidió que marcaran la categoría. Tres semanas después, al revisar una muestra, encontraron que dos anotadores usaban criterios distintos para separar una queja de una consulta con tono molesto. Hubo que rehacer una parte del trabajo y el proyecto se movió de fecha dos veces.

El problema no fue la cantidad de comentarios. Fue no tener claro, antes de empezar, qué significa cada categoría y cómo se resuelve un caso ambiguo. Ese vacío de criterio se paga después, con retrabajo, con desconfianza en los datos y con un modelo que termina aprendiendo inconsistencias en lugar de patrones reales.

Qué es la anotación de datos, en criterio de negocio

En criterio de negocio, anotar datos es el paso donde una empresa traduce su conocimiento tácito (lo que un agente de servicio reconoce con solo leer un mensaje, lo que un inspector de calidad ve con solo mirar una pieza) en ejemplos explícitos que un modelo puede usar para aprender. Es trabajo humano, manual en gran parte, y ocurre antes de que exista cualquier modelo entrenado.

Esto no es un paso técnico aislado que se delega sin mirar. Es la etapa donde se decide, en la práctica, qué va a considerar correcto el modelo el resto de su vida útil. Si la anotación arrastra un sesgo de criterio, ese sesgo queda incrustado en el modelo y sale caro de corregir después. Por eso la anotación de datos vive más cerca de la definición del negocio que de la ingeniería: antes de etiquetar hay que decidir, como empresa, qué cuenta como cada categoría y quién tiene la autoridad para resolver un caso dudoso.

Cuándo NO hace falta anotar (la pregunta que casi nadie hace)

La pregunta que casi nadie hace antes de contratar anotadores es la más barata de las tres: ¿esto realmente necesita un modelo entrenado con miles de ejemplos, o basta con darle instrucciones claras y algunos ejemplos a un modelo que ya entiende lenguaje natural? Hace unos años la respuesta casi siempre era que había que anotar. Hoy, con modelos generativos que ya vienen con una comprensión amplia del lenguaje y las imágenes, buena parte de esas tareas se resuelve escribiendo un buen conjunto de instrucciones y dos o tres ejemplos representativos, sin armar ningún pipeline de entrenamiento.

Esto cambia la conversación de presupuesto. Antes de aprobar un proyecto de anotación de datos, vale la pena probar primero si un modelo generativo bien instruido, con un puñado de ejemplos reales de la empresa, ya resuelve el problema con una calidad aceptable. Si la respuesta es sí, ese dinero y esas semanas de coordinación se ahorran completos. Estas son tareas donde, hoy, rara vez hace falta un proyecto de anotación desde cero:

• Clasificar el tono o la intención de un texto corto (queja, consulta, elogio) cuando las categorías son pocas y claras.
• Extraer un dato puntual de un documento (un monto, una fecha, un nombre) cuando el formato varía pero el criterio es simple de explicar.
• Resumir o reescribir contenido siguiendo un estilo definido por la empresa.
• Responder preguntas frecuentes con base en documentación existente, sin tener que enseñar con miles de ejemplos previos.
• Detectar duplicados o inconsistencias evidentes en un catálogo o una base de datos.

Cuando la tarea sí exige que el modelo cambie su comportamiento de fondo, ahí entra el fine-tuning (ver la entrada sobre qué es el fine-tuning), y ese proceso sí suele necesitar datos anotados con cuidado.

Cuándo sí hace falta anotar

Hay tareas donde anotar sigue siendo necesario y no hay atajo generativo que lo resuelva bien. La primera es la visión por computadora aplicada a un contexto específico del negocio (ver la entrada sobre qué es la visión por computadora): un modelo que tiene que detectar un defecto de fabricación particular, un vehículo en una calle local o un producto específico en un anaquel necesita ejemplos etiquetados de ese contexto exacto, porque ningún modelo genérico llegó entrenado viendo esa fábrica o esa calle.

La segunda es la clasificación muy específica del negocio: categorías que no existen en ningún estándar público porque las inventó la empresa. Un banco que quiere distinguir varios tipos de fraude según su propia tipificación interna, o una aseguradora que clasifica siniestros según sus propias reglas de suscripción, no va a encontrar ese criterio en ningún modelo genérico. Ahí sí hace falta que alguien del negocio etiquete ejemplos reales con ese criterio propio.

La tercera es la evaluación de calidad: incluso cuando se usa un modelo generativo sin entrenar nada, alguien tiene que revisar una muestra de sus respuestas y marcar si están bien o mal, para saber si el sistema realmente funciona antes de ponerlo en producción. Esa revisión también es anotación, aunque en la reunión no se le llame así.

• Visión por computadora sobre un contexto propio del negocio: una fábrica, una calle, un anaquel, un producto que ningún modelo genérico vio antes.
• Clasificación con categorías internas que inventó la empresa y que no aparecen en ningún estándar público del sector.
• Evaluación de calidad de un sistema ya en producción, revisando una muestra real de sus respuestas frente al negocio.
• Casos donde una decisión automática tiene consecuencia directa sobre una persona (crédito, seguro, salud) y hace falta evidencia de que el criterio es correcto.
• Escenarios donde ya se probó la vía de instrucciones y el modelo generativo sigue fallando de forma sistemática en un tipo de caso concreto.

El costo oculto de un proyecto de anotación

El costo que aparece en la cotización de un proyecto de anotación es el que menos duele: horas de anotador multiplicadas por volumen de ejemplos. El costo que de verdad se dispara y que casi nunca se presupuesta es la coordinación: escribir una guía de criterios que cualquier anotador pueda seguir igual, revisar muestras para detectar desacuerdos, resolver casos ambiguos con alguien que conozca el negocio, y repetir esa guía cada vez que aparece un caso nuevo que nadie previó.

Antes de aprobar un proyecto de anotación conviene mirar, además del volumen de ejemplos, estos costos que suelen quedar fuera del presupuesto inicial:

• El tiempo de escribir y mantener una guía de criterios clara, con ejemplos de casos límite ya resueltos.
• Las rondas de revisión para medir si los anotadores están de acuerdo entre ellos, no solo si trabajan rápido.
• El tiempo de alguien del negocio, no de tecnología, para resolver casos límite que la guía no cubrió.
• El retrabajo cuando cambia un criterio a mitad del proyecto y hay que volver a etiquetar lo ya hecho.
• La actualización constante cuando el negocio cambia (nuevas categorías, nuevos productos, nuevas reglas) y el dataset se queda viejo.

Este costo de coordinación es justo lo que casi ninguna propuesta comercial de un proveedor de anotación muestra por adelantado. Se cotiza el volumen porque es fácil de medir, y se calla la parte que realmente decide si el proyecto sale a tiempo o se atrasa dos meses.

El problema real es la coherencia, no el volumen

Se suele hablar de anotación de datos como un problema de cantidad: cuántos miles de ejemplos hacen falta. El problema real casi siempre es otro: si dos personas distintas, mirando el mismo caso, marcan lo mismo. A eso se le llama coherencia entre anotadores, y cuando es baja no importa cuántos miles de ejemplos se acumulen: el modelo termina aprendiendo el promedio de criterios contradictorios, que no es ningún criterio.

Esto conecta directo con qué es la calidad de datos (ver esa entrada): un dataset grande pero inconsistente vale menos que uno pequeño y coherente. Conecta también con el sesgo algorítmico (ver la entrada sobre qué es el sesgo algorítmico): si los anotadores comparten un mismo punto ciego, por ejemplo si etiquetan con más dureza los mensajes de cierto tipo de cliente, ese sesgo no se nota en el volumen, se nota solo cuando alguien audita una muestra con ojo crítico.

La forma barata de detectar esto no es contratar más gente, es hacer que dos o tres personas etiqueten el mismo lote sin verse entre ellas y comparar los resultados antes de escalar. Si el acuerdo es bajo ahí, escalar solo multiplica el ruido.

Mi criterio

Cuándo sí, cuándo no

Antes de armar un equipo de anotación o de contratar un proveedor externo, conviene revisar la situación real de la empresa contra estas señales. No son reglas absolutas, son las preguntas que yo hago primero.

Señales de que sí necesitas anotar datos

• El modelo tiene que reconocer algo visual muy específico del negocio (un defecto, un producto propio, un espacio físico) que ningún modelo genérico vio antes.
• Las categorías que usas para clasificar son propias del negocio y no existen en ningún estándar público.
• Ya probaste dar instrucciones claras a un modelo generativo y la calidad de sus respuestas sigue siendo inconsistente en los casos límite.
• Necesitas medir con evidencia si un sistema de IA que ya está en producción está acertando o fallando.
• Tienes, o puedes conseguir, a alguien del negocio, no solo de tecnología, capaz de escribir una guía de criterios y resolver casos ambiguos.

Señales de que todavía no la necesitas

• Nadie ha probado si un modelo generativo con buenas instrucciones y unos cuantos ejemplos ya resuelve la tarea.
• Las categorías que quieres usar cambian cada mes porque el negocio todavía no las tiene claras internamente.
• El volumen de casos es tan bajo que un proceso manual, sin modelo, sigue siendo más barato que construir un dataset.
• No hay nadie del negocio disponible para definir criterios ni para resolver casos límite, solo el equipo técnico.
• El objetivo real es automatizar un proceso mal diseñado y no enseñarle algo nuevo a un modelo (ver qué es machine learning para la diferencia).

El orden correcto para este término

El dolor de fondo nunca fue que hiciera falta anotar datos. Fue que el proceso de servicio, de calidad o de clasificación no tenía un criterio explícito y consistente, y alguien tenía que decidir si valía la pena convertir ese criterio en ejemplos etiquetados o si un modelo generativo bien instruido ya alcanzaba. El proceso es lo primero que hay que ordenar: quién decide cada categoría, cómo se resuelve un caso ambiguo, quién audita el resultado. Sin eso, ni el dataset más grande ni el mejor proveedor de anotación arreglan nada.

El dato viene después del proceso, no antes: solo cuando el criterio está claro tiene sentido convertirlo en ejemplos etiquetados, y solo entonces vale la pena medir si esos ejemplos son coherentes entre quienes los marcaron. La herramienta (el modelo, el proveedor de etiquetado, el pipeline de entrenamiento) va al final, y muchas veces ni siquiera hace falta: la pregunta que de verdad ahorra dinero es si el problema se resuelve con instrucciones bien escritas antes de pensar en anotar un solo ejemplo.