Skip to content

Cómo evaluar sistemas multiagente

Una guía práctica para evaluar sistemas LLM multiagente, atribuir fallos al agente y traspaso responsables, revisar el grafo de interacción y puntuar a cada agente y al equipo.

Un sistema multiagente son varios agentes LLM (un planificador, un programador, un revisor, etc.) cooperando en una tarea. Evaluarlo significa algo más que puntuar la respuesta final, porque los fallos que importan ocurren entre agentes: una restricción perdida en un traspaso, el agente equivocado tomando el control, un equipo que nunca verifica su trabajo. La unidad de juicio útil es qué agente, qué paso y qué traspaso. Potato es una herramienta de código abierto para la evaluación humana de ejecuciones multiagente, con un conjunto de superficies de anotación creadas a medida para la estructura del equipo.

Aquí un sistema multiagente se refiere a un flujo de trabajo impulsado por LLM donde agentes distintos, cada uno con un rol, intercambian mensajes y se ceden el control. La investigación sobre por qué fallan estos sistemas (la taxonomía MAST, Why Do Multi-Agent LLM Systems Fail?) concluye que una gran parte de los fallos son entre agentes: problemas de especificación, desalineación entre agentes y verificación ausente. Una transcripción plana oculta precisamente esos.

¿Por qué no basta con la evaluación de un solo agente?

Cuando evalúas un agente, juzgas una única secuencia de pensamientos, llamadas a herramientas y observaciones. Un equipo añade modos de fallo que solo existen entre agentes:

  • Pérdida en el traspaso: el agente A conoce una restricción que el agente B nunca recibe.
  • Atribución errónea: la ejecución falla, pero el agente responsable está aguas arriba de donde el error salió a la superficie.
  • Fallo de coordinación: cada agente es competente por separado, pero el equipo entra en bucle, se estanca o nunca verifica.
  • Contención de recursos: dos agentes tocan la misma herramienta o archivo a la vez y se bloquean.

Puntuar solo la salida final te dice que el equipo falló, no dónde. La atribución es lo que hace que los datos sean útiles para depurar o entrenar.

¿Cómo atribuyo un fallo multiagente?

La literatura de atribución de fallos (Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025) plantea la etiqueta como una tripleta: el agente responsable, el paso decisivo y un motivo. En Potato, el esquema failure_attribution rellena los selectores de agente y paso a partir de la propia traza, de modo que el anotador elige entre agentes y pasos que realmente ocurrieron:

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

Combinar el esquema de resultado con la atribución significa que la tripleta solo se recoge en ejecuciones que realmente fallaron.

¿Cómo reviso la estructura del equipo, no solo la transcripción?

Dos superficies hacen visible la estructura. El grafo de interacción renderiza los agentes como nodos y los traspasos como aristas, y el anotador marca el camino crítico y señala las aristas problemáticas. La revisión de traspasos convierte cada transferencia de control en una ficha para señalar la desalineación y valorar la calidad:

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

Para la puntuación, la agent_scorecard valora a cada agente en fidelidad al rol, contribución y coordinación, y puntúa al equipo en sus propias dimensiones, de modo que un agente individualmente fuerte dentro de un equipo mal coordinado se hace visible en los números.

¿Qué método debería usar?

  • Depurar un pipeline: empieza con el grafo de interacción y la atribución de fallos para localizar dónde se rompen las ejecuciones.
  • Comparar patrones de orquestación: añade la ficha de puntuación para puntuar diseños secuenciales vs. jerárquicos vs. de chat grupal en las mismas tareas.
  • Construir datos de entrenamiento o recompensa: etiqueta los fallos con granularidad de paso usando los modos MAST (vía trajectory_eval) para que las etiquetas se vinculen al agente que actúa y al paso.
  • Errores de concurrencia: usa la línea de tiempo de contención de herramientas para detectar bloqueos mutuos y carreras que una transcripción no puede mostrar.

Mide la concordancia sobre la atribución igual que lo harías con cualquier etiqueta subjetiva; consulta Concordancia entre anotadores.

Lecturas adicionales