Potato 2.11: el motor de etiquetado y las etiquetas de máquina certificadas
Potato 2.11 etiqueta datos con modelos, prueba sus etiquetas con una muestra humana ciega y emite un certificado. Las sesiones inactivas caducan a las 8 horas.
Potato 2.11 incorpora el motor de etiquetado, que etiqueta un conjunto de datos con modelos y usa una muestra aleatoria y ciega de etiquetas humanas para medir con qué frecuencia se equivocan los modelos. Tú declaras qué deben cumplir las etiquetas finales, por ejemplo que como mucho el 10% de las etiquetas de máquina aceptadas sean incorrectas, con un 90% de confianza. El motor acepta las etiquetas de máquina que respalda una prueba estadística, envía los ítems restantes a personas y escribe un certificado que registra qué se probó y con cuántas etiquetas humanas. La versión también amplía el informe de acuerdo a objetos 3D, temporal grounding, anotación por niveles y trazas de agentes, y corrige un error de imagen que podía contar como respondidos ítems que nadie había tocado.
pip install --upgrade potato-annotationNotas de actualización
Las sesiones inactivas ahora se cierran, por defecto a las 8 horas. Antes de 2.11, session_timeout_minutes no tenía ningún efecto en una aplicación en servicio, porque la comprobación se registraba en un objeto de aplicación que potato start descarta. Ahora se borra una sesión que lleva inactiva más tiempo del indicado, y su siguiente petición va a la página de inicio de sesión. Los quioscos y los ordenadores compartidos de laboratorio que se quedan con la sesión abierta toda la noche empezarán a ver cierres de sesión, así que sube session_timeout_minutes allí donde un estudio dependa de mantener la sesión abierta. Las anotaciones ya guardadas no se ven afectadas.
Tres claves antiguas muestran un aviso al arrancar. icl_labeling, judge_calibration y pre_annotation siguen funcionando exactamente igual que antes, y cada una escribe en stderr una línea que empieza por NOTE: y nombra su equivalente en el motor. Los avisos son informativos, así que potato validate --strict no falla por ellos. Está previsto retirar estas claves en 3.0, y potato label migrate-config escribe por ti el bloque labeling_engine equivalente.
El motor de etiquetado
El motor está pensado para estudios con más ítems de los que pueden etiquetar las personas y un modelo que acierta la mayoría de las veces. Trata los modelos como fuentes, que se prueban en cascada en el orden en que las enumeras, y envía un ítem a una persona después de la última fuente. Las fuentes pueden ser LLM, modelos de visión y lenguaje, modelos de decisión como Laya, detectores YOLO, jueces LLM, jurados, modelos entrenados con las propias etiquetas del estudio o etiquetas que ya tengas.
Un contrato es lo que pone a prueba el motor. El principal, selective_risk, acota la proporción de etiquetas de máquina aceptadas que son incorrectas. El motor elige un umbral de confianza con la mitad de la muestra ciega y lo prueba con la otra mitad mediante una prueba binomial unilateral, usando Learn-then-Test de secuencia fija. Cada nueva prueba se hace con un nivel más estricto, así que volver a certificar hasta que una prueba se supere no infla la confianza. El contrato ppi informa de la prevalencia de cada etiqueta con un intervalo construido mediante inferencia potenciada por predicciones, que sigue siendo válido sea cual sea la calidad del modelo. no_worse_than_human ejecuta la prueba del anotador alternativo para sustituir a una persona o a un juez, y distributional compara la distribución de etiquetas del modelo con cómo se reparten las personas en ítems subjetivos.
Una configuración que certifica un LLM en un esquema de sentimiento añade dos claves a un estudio normal:
assignment_strategy: engine
labeling_engine:
enabled: true
sources:
- id: gemma
kind: llm
endpoint_type: vllm
model: google/gemma-4-12B-it-qat-w4a16-ct
base_url: http://localhost:8001/v1
confidence: {method: logprob}
contracts:
- id: accuracy
kind: selective_risk
schema: sentiment
error: 0.1
confidence: 0.9
budgets:
human_labels: 400confidence: {method: logprob} lee la confianza del modelo a partir de las probabilidades de sus tokens, lo que requiere una llamada por ítem y suele ser el mejor calibrado de los métodos de confianza del motor. El contrato admite como mucho un 10% de etiquetas aceptadas incorrectas, y su confianza del 90% es la que Potato usa por defecto. budgets.human_labels limita cuántas peticiones a personas puede abrir el motor, y 400 es el límite que usa el ejemplo de texto incluido.
El ejemplo de texto que viene con Potato procesa 481 reseñas con una cascada que pone a Laya por delante de Gemma 12B. En esa ejecución, el contrato del 10% se cumplió con 165 etiquetas humanas, y el motor aceptó 316 etiquetas de máquina, todas de Gemma, porque el umbral de Laya nunca llegó a fijarse. Su error medido frente a las etiquetas de referencia fue del 7.6%. El ejemplo de trazas de agentes tiene 288 trazas sintéticas con resultados de referencia. El juez acertó en el 80% de ellas, pero dio una confianza de 1.0 a todos sus veredictos, así que selective_risk no tenía nada sobre lo que fijar un umbral y siguió siendo inviable. El intervalo PPI para el éxito de la tarea con los mismos datos, [0.57, 0.76], cubrió la tasa de referencia de 0.60, mientras que el juez por sí solo decía 0.76.
Los límites de un contrato cumplido
Un contrato cumplido es una afirmación sobre el acuerdo con las personas que etiquetaron la muestra. El motor no comprueba que esas personas acierten, así que un contrato probado con anotadores descuidados certifica el acuerdo con anotadores descuidados. Tres reglas hacen que esa afirmación se sostenga. Las peticiones de calibración son ciegas, así que la página no muestra ninguna preanotación, veredicto de juez ni ayuda de IA mientras una persona tiene una asignada. Los umbrales se eligen con una mitad de la muestra y se prueban con la otra. Solo certifican las etiquetas humanas, y cualquier cambio en una fuente, un prompt o un esquema marca los contratos afectados como stale hasta que se vuelvan a probar.
Interfaces del motor
El mismo archivo engine.sqlite respalda todas las interfaces, así que puedes empezar un estudio en una y certificar en otra:
potato label run|status|certify|certificate|export|calls|distill|optimize|migrate-configen la línea de comandos;- una REST API bajo
/api/engine/v1; - cinco herramientas
engine_*en el servidor MCP; potato.labeling_engine.sdk.Studyen Python; y- una página de administración en
/admin/labeling-enginecon el estado de los contratos, la curva de error frente a cobertura, un diagrama de fiabilidad por fuente y el registro de llamadas a modelos.
potato label export escribe las etiquetas con su procedencia, el certificado en JSON, Markdown y HTML, una ficha del conjunto de datos y el registro de llamadas. El motor de etiquetado recorre un primer estudio, y Contratos del motor de etiquetado explica qué prueba cada contrato y cómo falla.
Solo Mode
Solo Mode ahora puede ocultar su sugerencia. solo_mode.suggestions retiene la etiqueta del LLM en todos los ítems o en una muestra aleatoria. Una sugerencia en pantalla atrae la respuesta hacia ella, así que el traspaso lee el acuerdo en los ítems ciegos. Los modelos de decisión (laya y cualquier servidor /v1/systemone) pueden servir como primer nivel rápido, y Solo Mode comprueba el ai_budget.cap_usd del proyecto antes de empezar a etiquetar y antes de cada lote. También son nuevos un conjunto de referencia, un jurado de etiquetado y la ordenación por currículo. Cuando el motor está activado, Solo Mode escribe sus predicciones en el almacén del motor, para que el motor pueda calibrarlas y certificarlas. Solo Mode tiene las configuraciones.
Acuerdo
/admin/iaa ahora informa del acuerdo en spatial_annotation, temporal_grounding, tiered_annotation y los cinco esquemas de trazas de agentes, que antes omitía por no estar admitidos. Los objetos 3D y los segmentos temporales reciben un acuerdo medio sobre conjuntos emparejados, que no está corregido por azar, y los pasos de las trazas de agentes reciben el alfa de Krippendorff y el kappa de Cohen, con cada paso de cada traza como unidad. /admin/api/agreement ya no informa de esquemas estructurados y remite a /admin/iaa, porque, reducidos a nombres de etiqueta, esos esquemas mostraban un acuerdo perfecto entre cada par de anotadores. Dos segmentos idénticos de longitud cero ahora cuentan como coincidentes. La publicación y Paper Mode excluyen a los evaluadores de máquina de las etiquetas de referencia y de las cifras de acuerdo.
Correcciones que afectan a estudios con 2.10
Tres correcciones pueden cambiar cifras que ya hayas recogido o publicado:
- Una página de imagen guardaba sola una respuesta prerrellenada. En un esquema
image_annotationconpre_annotation, el lienzo guardaba las formas prerrellenadas como respuesta del anotador al recalcular su diseño tras cargarse, así que un ítem sin tocar contaba como respondido. En un estudio de imágenes con 2.10 y preanotaciones, puede que nadie tocara nunca un ítem cuyas formas guardadas coinciden exactamente con su preanotación, así que trata esos ítems como no revisados, salvo que tus datos de tiempos indiquen otra cosa. - Paper Mode calculaba kappa con su propio código. Paper Mode y el módulo de acuerdo ahora calculan el kappa de Cohen con la misma función que
/admin/iaa, así que un kappa publicado desde Paper Mode antes de 2.11 puede diferir del que muestra/admin/iaapara los mismos datos. - La adjudicación y el autoescalado de Prolific contaban a los evaluadores de máquina. Los anotadores de máquina podían enviar un ítem a adjudicación, se ignoraba
min_human_annotationsy el autoescalado de Prolific contaba las anotaciones de máquina frente a los topes por ítem.
Las demás correcciones cambian lo que puede hacer un estudio. Ahora cargan las imágenes de hosts que no envían cabeceras CORS, como cocodataset.org. En una imagen así, el relleno de regiones, SAM y la segmentación por prompt de texto ahora explican por qué no pueden leerla. Una forma preanotada sin color toma el color de su etiqueta en lugar de descartarse. «Generate prompt» de Solo Mode ahora pide al modelo de revisión que escriba el primer prompt. Los rechazos a través de potato mcp connect vuelven como errores de herramienta en lugar de como éxitos. El descubrimiento de casos límite ahora funciona con vLLM, que no devolvía los campos de casos límite hasta que se añadieron al esquema de respuesta.
Instalar 2.11
Actualiza con pip install --upgrade potato-annotation o descarga ghcr.io/davidjurgens/potato:2.11.0. El modelo de decisión Laya, que se ejecuta dentro del proceso, necesita el nuevo extra decision, pip install 'potato-annotation[decision]', que queda fuera de all porque arrastra torch. Las notas de la versión enumeran todos los cambios, y Novedades tiene el resumen de cada versión 2.x.