Control de calidad para la anotación crowdsourced

Ninguna verificación por sí sola detecta todos los tipos de anotación deficiente, así que conviene combinar cuatro: verificaciones de atención para los anotadores que no leen, estándares de referencia para los que leen y aun así se equivocan, solapamiento para los elementos ambiguos y tiempos para el trabajo enviado demasiado rápido como para haberse hecho de verdad. Cada una tiene su propia clave de configuración en Potato, y cada una reporta por separado en el panel de administración.

El control de calidad es más barato antes de la recolección y más caro después. Una verificación de atención que bloquea a un anotador en su quinto fallo no cuesta nada configurarla y ahorra los elementos que ese anotador habría llenado; el mismo problema detectado con un script a posteriori te cuesta repetir la recolección. Los controles que siguen están ordenados según el momento en que actúan.

Control de calidad a lo largo del proyecto

Qué detecta cada control

Los cuatro controles fallan en direcciones distintas, y por eso conviene usar más de uno.

El acuerdo, en particular, no lo detecta todo. Cuando los anotadores revisan preetiquetas de un modelo, aceptar una sugerencia sin leerla sube el acuerdo en lugar de bajarlo, de modo que el anotador que aprueba sin mirar parece el mejor según esa medida. El acuerdo no puede detectar la aprobación sin revisión explica qué registrar en su lugar.

Verificaciones de atención

Las verificaciones de atención son elementos con una respuesta conocida, insertados en el flujo de anotación según un calendario, que comprueban que un anotador lee antes de responder. Potato los inserta, los califica, advierte al anotador y lo bloquea al llegar al umbral que fijes, así que todo el ciclo se ejecuta en el servidor y no en un script a posteriori.

Fija la frecuencia según cuánto tardan tus elementos. Una verificación cada 10 elementos basta para detectar a un anotador que se desconcentra dentro de una misma sesión sin gastar mucho presupuesto en elementos que no son datos. El mínimo min_response_time es lo que detecta a quien hace clic en lugar de leer, y una respuesta más rápida que ese mínimo falla, diga lo que diga:

attention_checks:
  enabled: true
  items_file: "data/attention_checks.json"
  frequency: 10              # one check every 10 items
  min_response_time: 3.0     # seconds; faster than this fails the check
 
  failure_handling:
    warn_threshold: 2
    warn_message: "Please read items carefully before answering."
    block_threshold: 5
    block_message: "You have been blocked due to too many incorrect responses."

El archivo de elementos asigna a cada verificación un id, el texto que ve el anotador y la respuesta esperada para cada esquema:

[
  {
    "id": "attn_001",
    "text": "Please select 'Positive' for this item to verify you are reading carefully.",
    "expected_answer": {
      "sentiment": "positive"
    }
  }
]

Los resultados sobreviven a un reinicio. Potato los escribe en quality_control_results.json dentro del directorio de salida a medida que se registran y los vuelve a leer al arrancar, así que un despliegue no borra el historial de fallos de un anotador ni desbloquea a alguien que estaba bloqueado.

Estándares de referencia

Los estándares de referencia (gold standards) son elementos etiquetados por expertos que se mezclan en el flujo para medir la exactitud, no la atención. Por defecto son silenciosos, así que los resultados van al panel de administración y el anotador no recibe retroalimentación, lo que permite medir la calidad sin alterar el comportamiento que se está midiendo. Activa la retroalimentación cuando estés formando a los anotadores y no seleccionándolos.

Los elementos de referencia se insertan cada frequency elementos, así que este ajuste equilibra la precisión de la medición con la parte del presupuesto que se va en elementos cuyas etiquetas ya tienes. Uno de cada 20 da unos 25 elementos calificados en un turno de 500 elementos:

gold_standards:
  enabled: true
  items_file: "data/gold_standards.json"
  mode: mixed                # mixed injects into the stream; this is the implemented mode
  frequency: 20
 
  accuracy:
    min_threshold: 0.7       # annotators below this are named in the dashboard
    evaluation_count: 10     # evaluate once an annotator has seen 10 gold items
 
  feedback:
    show_correct_answer: false
    show_explanation: false

El archivo de elementos contiene la anotación correcta para cada esquema, más una explicación opcional para el caso con retroalimentación:

[
  {
    "id": "gold_001",
    "text": "The service was absolutely terrible and I will never return.",
    "gold_label": {
      "sentiment": "negative"
    },
    "explanation": "Strong negative language indicates negative sentiment.",
    "difficulty": "easy"
  }
]

Elige elementos de referencia que no sean ambiguos para un experto. Un elemento sobre el que tu propio equipo discute mide las directrices y no al anotador, y empujará a anotadores competentes por debajo del umbral. Potato también puede promover elementos a referencia cuando los anotadores coinciden en ellos por unanimidad, mediante gold_standards.auto_promote, lo que amplía el conjunto sin más etiquetado experto.

La exactitud por anotador aparece en /admin/api/quality_control, que reporta configured_correct y configured_total junto a los totales. Cita los números configurados al comparar anotadores, porque el conjunto configurado es el mismo para todos, mientras que el conjunto autopromovido depende de cuándo llegó cada anotador.

Solapamiento y acuerdo

Asignar varios anotadores por elemento es el control que encuentra elementos ambiguos, no anotadores deficientes. Tres por elemento es el valor habitual, porque tres dan una mayoría para la agregación y suficiente solapamiento para un coeficiente. Fija el objetivo y activa los reportes:

num_annotators_per_item: 3
 
agreement_metrics:
  enabled: true
  min_overlap: 2
  refresh_interval: 60

El alfa de Krippendorff aparece entonces en el panel de administración a medida que llegan las anotaciones, por esquema. Medir el acuerdo entre anotadores explica qué coeficiente reportar y qué significan los umbrales.

Tiempos y telemetría

Potato registra cuánto tardó cada elemento, no solo qué se respondió. Cada instancia lleva un objeto behavioral_data cuyo total_time_ms es el tiempo dedicado a ese elemento, junto con los eventos de interacción, el historial de cambios de la anotación y el ciclo de vida de las sugerencias de IA. Este campo es lo que permite distinguir a un anotador que es rápido porque el corpus es fácil de otro que es rápido porque no está mirando:

def flag_fast_annotations(export, min_seconds=2.0):
    """Instances submitted faster than a floor, from an exported annotation file."""
    flagged = []
    for instance in export:
        bd = instance.get("behavioral_data") or {}
        seconds = bd.get("total_time_ms", 0) / 1000
        if seconds < min_seconds:
            flagged.append((instance["id"], seconds))
    return flagged

Interpreta los tiempos como una distribución dentro de tu propio proyecto y no frente a un número fijo de segundos, ya que el mismo umbral que detecta la aprobación sin revisión en un corpus difícil detecta la competencia en uno fácil. Para las anotaciones dibujadas, annotation_telemetry registra la misma idea con más detalle. Su señal más fuerte es la latencia entre la aparición de una sugerencia de IA y su aceptación por parte del anotador. Seguimiento del comportamiento y telemetría de dibujo describen los campos y las alertas que alimentan.

Una configuración con los cuatro controles

Las cuatro claves son independientes, así que un proyecto puede adoptarlas de una en una. Juntas se ven así:

annotation_task_name: "Sentiment Annotation with Quality Control"
task_description: "Classify the sentiment of short texts."
 
data_files:
  - data/items.json
 
item_properties:
  id_key: id
  text_key: text
 
annotation_schemes:
  - annotation_type: radio
    name: sentiment
    description: "What is the sentiment of this text?"
    labels:
      - Positive
      - Negative
      - Neutral
 
num_annotators_per_item: 3
 
attention_checks:
  enabled: true
  items_file: data/attention_checks.json
  frequency: 15
  min_response_time: 3.0
  failure_handling:
    warn_threshold: 2
    block_threshold: 5
 
gold_standards:
  enabled: true
  items_file: data/gold_standards.json
  mode: mixed
  frequency: 25
  accuracy:
    min_threshold: 0.7
    evaluation_count: 10
 
agreement_metrics:
  enabled: true
  min_overlap: 2
  refresh_interval: 60
 
output_annotation_dir: annotation_output

Empieza con umbrales permisivos. Un umbral de bloqueo de 5 y un mínimo de exactitud de 0.7 te dejan ver la distribución real de tu grupo de anotadores antes de decidir qué cuenta como fallo, y endurecerlos más tarde no cuesta nada. Fijarlos estrictos desde el primer día expulsa anotadores en función de directrices que todavía no se han probado en un piloto.

Controles a nivel de plataforma

Las plataformas de crowdsourcing filtran el grupo antes de que nadie llegue a tu tarea. Es una función distinta de la de las verificaciones anteriores, y vale la pena hacerla además de ellas.

• Preselección. Prolific filtra por tasa de aprobación y trabajo completado previamente, así como por datos demográficos e idioma.
• Pruebas de cualificación. Una prueba breve en la fase de entrenamiento de Potato condiciona el acceso a la tarea principal en cualquier plataforma.
• Revisión antes del pago. Aprueba rápido cuando el trabajo está bien, porque la lentitud en la aprobación es la queja más frecuente de los anotadores, y usa el rechazo con moderación porque perjudica la reputación del trabajador en la plataforma.

La preselección de la plataforma y las verificaciones propias de Potato se complementan. La preselección decide quién llega a la tarea; las verificaciones de atención y los estándares de referencia miden lo que hicieron una vez allí.

Antes de recolectar nada

Hay dos decisiones difíciles de revertir una vez iniciada la recolección, así que tómalas primero. Decide qué campos necesitas en la exportación, porque un análisis de tiempos planeado a posteriori necesita que behavioral_data se haya registrado durante la ejecución. Y haz un piloto de unas pocas decenas de elementos con todos los controles activados, ya que en el piloto descubres que tus verificaciones de atención son ambiguas o que tus elementos de referencia son discutibles, y cuesta una tarde en lugar de un conjunto de datos.

Lecturas adicionales

• Estándares de referencia y verificaciones de atención
• Referencia de la función de control de calidad
• Fase de entrenamiento para formar a los anotadores antes de la tarea real
• Cómo escribir directrices de anotación eficaces
• Cómo realizar un estudio de crowdsourcing
• La documentación fuente de control de calidad de Potato