Instrumentar la reunión de calibración

Hay dos cosas que todo equipo de anotación hace mal, porque sus herramientas no ayudan: la reunión de calibración, que ocurre por pantalla compartida y no deja rastro, y entender por qué un anotador eligió una etiqueta, que suele reducirse a una caja de texto libre que nadie rellena. Potato 2.7 instrumenta las dos: una sala de normalización en vivo con un medidor de acuerdo en tiempo real, y un grabador de pensamiento en voz alta que ejecuta el paso de voz a texto en local. Ninguna de las dos necesita un LLM.

La reunión que no deja pruebas

Si has llevado un proyecto de anotación con más de dos personas, has hecho una sesión de normalización. Todo el mundo etiqueta el mismo puñado de elementos, os metéis en una llamada, discutís sobre los desacuerdos y al final convergéis en qué significa realmente la directriz.

Funciona. También carece por completo de instrumentación. Los votos que cada uno tenía antes de la discusión se pierden. Quién cambió de opinión, y si lo hizo por convencimiento o porque un colega veterano habló primero, se pierde. Y si la reunión mejoró el acuerdo o no es una pregunta que nadie puede responder, porque nadie lo midió.

Las salas multijugador llevan esa sesión a la herramienta.

Una sala de normalización a mitad de sesión

rooms:
  enabled: true
  who_can_create: any
  persist_votes: true
  schema: sarcasm

Abre /rooms, crea una y recibirá un código de seis letras que puedes leer en voz alta durante la llamada. El flujo es deliberado:

1. Todo el mundo vota a ciegas. Los miembros ven quién ha votado, nunca qué. Esto se aplica en el servidor, así que las primeras impresiones son de verdad independientes.
2. El anfitrión revela. En ese momento los votos a ciegas quedan inmutables.
3. El grupo discute, en un chat aparte o en vuestra llamada.
4. Cualquiera puede cambiar su voto. Cada cambio posterior a la revelación se registra con el voto de partida, el voto de llegada y cuál era la mayoría en ese momento.

El cuarto paso es el interesante. Un cambio de voto tras la revelación no es el mismo suceso que un voto; es un cambio en presencia de una mayoría conocida. Registrarlo te da un registro de conformidad por miembro, que es como te enteras de que hay un anotador que se pasa a la mayoría absolutamente siempre. Conviene saberlo antes de tratar su acuerdo como evidencia independiente.

El medidor de acuerdo responde a «¿ha valido la pena?»

El α de Krippendorff se calcula dos veces, en vivo, sobre los elementos revelados: una con los votos a ciegas y otra con los votos actuales. La diferencia entre ambos es la mejora de normalización de la sesión, y está en pantalla mientras la sesión ocurre.

Este es el número que hace que la reunión rinda cuentas. Si una hora de discusión movió el α de 0,61 a 0,78, sabes que esa hora compró algo. Si lo movió de 0,61 a 0,62, has aprendido que el desacuerdo no va de interpretación. Va de la directriz, y ninguna cantidad de conversación lo va a arreglar. Vete a reescribir la directriz.

Conviene conocer dos variantes. Las salas huddle se llenan exactamente con los elementos en los que tu equipo discrepa ahora mismo, calculados en vivo a partir del estado de la anotación, lo que las convierte en una versión síncrona de la adjudicación. Las salas shadow permiten que quien está en formación vea trabajar a un anotador veterano en tiempo real, incluido qué tramo de texto está resaltando. Es lo más parecido a sentarse al lado de alguien mientras anota.

Las salas usan event sourcing sobre un registro JSONL, así que una sala en vivo sobrevive a un reinicio del servidor, y ese registro sirve además como pista de auditoría de la sesión. No hay WebSockets de por medio; los clientes consultan con un cursor, lo que significa que las salas funcionan bajo cualquier despliegue WSGI.

El razonamiento que nunca capturaste

El otro fallo silencioso son las justificaciones. La mayoría de herramientas ofrecen una caja de texto libre, y la mayoría de anotadores escriben «obvio» en ella, o nada.

No es pereza. Escribir tu razonamiento es de verdad más lento que tenerlo, y si la tarea tiene 400 elementos, la caja de justificación es lo primero que se cae.

El modo Think-Aloud elimina esa fricción cambiando de modalidad: los anotadores simplemente hablan mientras trabajan.

Think-Aloud, con una etiqueta detectada

thinkaloud:
  enabled: true
  schema: politeness
  model: tiny.en

El paso de voz a texto se ejecuta en local con faster-whisper, que va en tiempo real sobre CPU con el modelo tiny.en de 39 MB. El audio nunca sale de la máquina, y no hay ninguna API en la nube que llamar ni factura por token que pagar. Para muchos datos sensibles esa es la diferencia entre «podemos usar esto» y «el departamento jurídico ha dicho que no».

El protocolo de pensamiento en voz alta fue la referencia para estudiar cómo toma decisiones la gente mucho antes de que nada de esto fuera computacional. Nunca llegó a las herramientas de anotación, porque pedirle a alguien que narre a una grabadora y luego transcribirlo a mano no es un flujo de trabajo que nadie sostenga.

Literal, a propósito

La transcripción se guarda exactamente como se dijo y deliberadamente sin resumir. Es una decisión de diseño de verdad, no dejadez: parafrasear un protocolo de pensamiento en voz alta contamina el artefacto. Las vacilaciones, las autocorrecciones, el «bueno, podría ser sarcástico, pero…»: eso son los datos. Un resumen ordenado de todo eso es otro objeto distinto y mucho menos útil.

Los anotadores también pueden confirmar una etiqueta por voz, usando fórmulas fijas que detecta un analizador basado en reglas:

• "I label this Polite"
• "My answer is impolite"
• "Final answer: neutral"

Solo esas fórmulas confirman. Todo lo que se dice mientras piensas se ignora, y eso es lo que hace suficiente a un analizador basado en reglas. No hay ningún LLM en toda la cadena, ni ningún modelo decidiendo qué querías decir. Di una fórmula nueva más adelante y gana la última confirmación.

También obtienes señales deterministas de vacilación (recuento de fragmentos en silencio, recuento de muletillas) calculadas con aritmética y no con un modelo. Las pausas largas en un elemento son un indicio razonable de dificultad, y recogerlas no cuesta nada.

Por qué esto importa más allá de las justificaciones

Aquí está la parte que conecta con el resto de Potato 2.7.

Think-Aloud es un grabador de la cadena de razonamiento humana. Captura cómo razona realmente una persona hasta llegar a una etiqueta: no una justificación pulida escrita después, sino el razonamiento según ocurre, con arranques en falso incluidos.

La anotación de recompensa de proceso de Potato hace lo mismo con un modelo: segmenta la cadena de razonamiento de un modelo y la puntúa paso a paso.

El mismo elemento, dos cadenas de razonamiento, una humana y una del modelo. Puedes ponerlas una al lado de la otra y mirar dónde diverge el razonamiento. Eso es algo genuinamente nuevo, y es la materia prima de mejores datos de recompensa de proceso, porque «el modelo acertó la respuesta por el motivo equivocado» es justo el fallo que la puntuación de la respuesta final no puede ver.

Potato te da las dos superficies de captura. No calcula un diff entre ellas por ti. Eso es una pregunta de investigación y no una función, y preferimos darte el artefacto antes que una métrica que nos hayamos inventado.

Lecturas adicionales

• Salas multijugador y modo Think-Aloud — configuración completa
• La concordancia entre anotadores — qué está midiendo en realidad el α
• Adjudicación y resolución del desacuerdo
• Etiquetas con barras de error — la psicometría marca los fallos del manual de codificación; las salas son donde los arreglas
• Modelos de recompensa de proceso — la cadena de razonamiento del lado del modelo