El método PoS detecta a los agentes de IA atrapados en un bucle de creencias falsas: 36 repeticiones en ALFWorld

La tarea parece de niños: coger una taza, calentarla y guardarla en el armario. En el simulador ALFWorld, uno de los agentes no fue capaz de resolverla. Metió la taza en el microondas, la pasó al armario y después se asomó 36 veces seguidas al armario, hasta agotar su presupuesto de acciones. La tarea quedó sin completar: el agente se había saltado el paso de calentar. Investigadores chinos usaron este episodio para ilustrar el fenómeno Belief Trapping, y el medio Jiqizhixin ha contado en qué consiste el método PoS, que debe reconocer estos casos y romperlos.

Cómo es una trampa de creencias

Lo esencial de este ejemplo es que el agente no se rompió ni se bloqueó. Actúa, y lo hace todo el tiempo. Cada paso es formalmente válido, el entorno no devuelve errores y, visto desde fuera, parece trabajo. Pero no hay progreso, porque la representación interna que el agente tiene del estado de la tarea no coincide con la realidad. Cree que ya ha hecho todo lo necesario, así que verifica el resultado en lugar de buscar lo que se le ha pasado.

De ahí el nombre. Belief Trapping puede traducirse como «trampa de creencia»: una hipótesis errónea sobre el avance de la tarea se fija y deja de revisarse. Cuanto más tiempo da vueltas el agente en el bucle, más registros hay en su contexto que confirman la misma imagen. Treinta y seis repeticiones en un solo episodio muestran que, por sí solo, no sale de ese estado.

Por qué el historial completo no ayuda

El ejemplo del artículo corresponde a un agente que usa el historial completo de interacción, es decir, el enfoque Raw Trajectory. Intuitivamente parece que cuanto más contexto, mejor: el modelo ve todas sus acciones y las respuestas del entorno. El caso de la taza demuestra lo contrario. Un historial largo y en bruto no garantiza que el modelo vuelva a la condición inicial y detecte el paso que nunca se dio. Puede, simplemente, afianzar una línea de conducta errónea.

Esta es una conclusión mía a partir del ejemplo descrito, no una cita del trabajo. Pero concuerda con lo observado: aquí el error no se corrige añadiendo tokens. Hace falta un mecanismo que mire la trayectoria desde fuera y distinga el movimiento del progreso.

Qué se sabe de PoS

El fragmento disponible del material solo revela lo esencial: PoS está pensado para identificar el Belief Trapping y sacar al agente de él. El texto no deja ver cómo está construido exactamente, con qué modelos y benchmarks se probó ni qué mejora logró. Esos datos habrá que consultarlos en el propio artículo. Por ahora es pronto para evaluar las cifras.

Lo que ya se puede dejar establecido:

• entorno: ALFWorld, un simulador de texto de tareas domésticas para agentes;
• tarea: calentar una taza y guardarla en el armario;
• fallo: se omitió el paso de calentar y el agente repitió 36 veces la comprobación del armario;
• resultado: presupuesto de acciones agotado, tarea no resuelta;
• enfoque base en el ejemplo: Raw Trajectory, es decir, el historial completo de interacción;
• solución propuesta: el método PoS para detectar y romper la trampa.

Qué deben hacer con esto los desarrolladores de agentes

Incluso sin los detalles de PoS, el caso deja lecciones prácticas. Quienes construyen agentes sobre LLM deberían comprobar si sus sistemas sufren un fallo similar.

Primero: cuenten las repeticiones. La misma acción con el mismo resultado más de dos o tres veces seguidas es casi siempre señal de bucle, no de diligencia. Un detector de bucles sencillo sale más barato que un presupuesto de acciones malgastado.

Segundo: separen «hecho» de «objetivo alcanzado». Antes de terminar, o tras una serie de pasos infructuosos, conviene obligar al agente a contrastar de nuevo con la condición inicial y a enumerar las subtareas. En la historia de la taza, esa verificación habría revelado el calentamiento omitido.

Tercero: no den por hecho que un contexto largo es la cura. Si el agente se apoya en el historial completo, evalúen si ese historial refuerza sus propios errores.

Cuarto: incluyan en las pruebas tareas con dependencias de varios pasos, donde importan el orden y la integridad de los pasos. Es justo ahí donde afloran estas trampas. Cuando se conozcan los detalles del trabajo, comparen PoS con estas defensas sencillas. El valor real del método depende de cuánto mejora respecto a ellas.