Investigadores proponen el marco PAPAV: solo 3 de 64 benchmarks evalúan la verificación

Cuando un agente multimodal pasa de manejar un navegador a controlar un brazo robótico, además del entorno cambia el coste de equivocarse. Un nuevo trabajo publicado en Hugging Face Daily Papers intenta describir esa transición con un lenguaje común. Los autores introducen el concepto de agentes multimodales encarnados (MMEA) y proponen el marco PAPAV, formado por cinco funciones. La conclusión empírica principal: de los 64 benchmarks analizados, solo 5 evalúan la capacidad de prever las consecuencias de las acciones y apenas 3 comprueban si se ha alcanzado el resultado. Casi todos los demás miden si la tarea se llegó a completar.

Tres clases de sistemas y un denominador común

Los autores empiezan por distinguir tres categorías. Los agentes multimodales (MMA) sostienen la interacción mediante razonamiento, memoria, herramientas y retroalimentación. El ejemplo más visible son los agentes que trabajan en un ordenador. Los sistemas robóticos (RS) conectan la percepción con la ejecución en condiciones de dinámica física. Los MMEA se sitúan en la intersección: son sistemas orientados a objetivos que combinan el razonamiento multimodal sobre la tarea con la acción física y revisan sus decisiones según el resultado.

La pregunta central del trabajo es sencilla: ¿qué cambia cuando un agente pasa del computer-use al robot-use? Para responderla hace falta una escala de comparación que no dependa de una arquitectura concreta. Los autores optan por describir funciones, no el diseño del modelo.

PAPAV: cinco funciones en lugar de una sola métrica

La sigla se desglosa así:

• Perceive: percibir el estado actual;
• Anticipate: prever los efectos de las acciones;
• Plan: construir un plan viable;
• Act: actuar a través de una interfaz o de un cuerpo;
• Verify: verificar el resultado.

Esta definición permite identificar lo que tienen en común las tres clases y, después, comparar los MMEA con los MMA convencionales y con la robótica clásica. Un agente que hace clic en botones y un manipulador en una fábrica ejecutan las cinco funciones. Lo que varía es la dificultad de cada una y lo caro que resulta un fallo.

Dónde la física recorta la libertad

Los autores señalan cinco restricciones físicas. La lista va desde la observabilidad parcial hasta los resultados no verificables. El efecto global es el mismo: en el mundo físico se pueden fijar menos decisiones de antemano, y también hay menos posibilidades de deshacer un error. Un clic equivocado en una interfaz suele poder revertirse. Un objeto que se cae o un movimiento incorrecto, no.

De ahí el peso de las funciones Anticipate y Verify. Un agente que no puede evaluar las consecuencias de antemano ni comprobar con honestidad el resultado resulta peligroso en un entorno físico, aunque planifique bien.

Qué mostró el análisis de 64 benchmarks

La cifra principal del trabajo describe el estado de la evaluación en el sector:

• se analizaron 64 benchmarks en total;
• la evaluación explícita se concentra en la función Act;
• solo 5 benchmarks evalúan Anticipate;
• solo 3 evalúan Verify;
• ambas funciones quedan ocultas, en su mayoría, tras el indicador final de éxito de la tarea.

El problema es que el éxito de la tarea mezcla las cinco capacidades en una sola cifra. Un modelo pudo completar la tarea gracias a una buena percepción y no a una buena predicción. O pudo fracasar por una verificación débil, aunque el plan fuera correcto. Sin mediciones separadas, es difícil saber qué ha mejorado entre versiones de un sistema y qué hay que corregir.

Sobre estas mismas restricciones, los autores construyen una lista de problemas abiertos. Entre ellos figuran el diseño de agentes físicos fiables y la medición del progreso en las cinco capacidades.

Cómo usar el marco en la práctica

Para los equipos que desarrollan agentes para robots, el trabajo tiene una aplicación práctica. El marco PAPAV puede servir como lista de verificación para una auditoría: para cada función, hay que definir qué prueba la mide y detectar las que quedan sin cubrir. Si el pipeline no incluye una comprobación independiente del resultado tras la acción, conviene añadirla antes de escalar.

Para quienes desarrollan benchmarks, la conclusión es aún más concreta. Hacen falta tareas que evalúen por separado la predicción de consecuencias y la verificación del resultado, y no solo el éxito final. Para inversores y clientes, es una referencia a la hora de ver demos: un buen porcentaje de tareas completadas aún no dice cómo se comporta el sistema cuando el resultado no se puede verificar o el error no se puede deshacer.

El trabajo no propone un modelo nuevo ni promete una mejora en ninguna prueba concreta. Es un intento de ordenar términos y métricas en la intersección entre agentes y robótica, mientras la frontera entre ambos se difumina a gran velocidad.