El blog de Deska
Estrategias de reintento cuando el modelo devuelve basura
Aprende estrategias de reintento cuando el modelo devuelve basura, enfocándote en validación de esquemas y depuración multi-agente para mayor confiabilidad.
· 11 min de lectura
Construir agentes autónomos es un ejercicio de gestión de fallos no deterministas. Incluso con los mejores modelos, eventualmente enfrentarás una situación en la que la salida es inutilizable, está truncada o tiene una sintaxis rota. Implementar estrategias de reintento robustas cuando el modelo devuelve basura es esencial para pasar de simples interfaces de chat a una automatización confiable. Este artículo explora cómo identificar estos fallos y los patrones arquitectónicos específicos necesarios para recuperarse de ellos sin entrar en un bucle infinito de llamadas costosas a la API.
La anatomía de la salida basura
En el contexto de la ingeniería de agentes, la basura no es solo una respuesta incorrecta. Es una salida que viola las restricciones del sistema. Esto suele dividirse en tres categorías. Primero, están las violaciones de esquema, donde un modelo no logra producir un JSON válido o ignora campos obligatorios. Segundo, existen los errores de alucinación lógica, donde el código es sintácticamente correcto pero hace referencia a variables o librerías inexistentes. Tercero, están los desbordamientos de contexto, donde el modelo se corta a mitad de una frase, dejando un corchete suelto que rompe el procesador.
El software tradicional se basa en bloques catch para excepciones conocidas. Con los LLMs, la excepción suele ser silenciosa. El procesador falla y el agente se detiene. Para solucionar esto, debes tratar la salida del modelo como una entrada no confiable que requiere una capa de validación rigurosa antes de que llegue a tu entorno de ejecución.
La validación como primera línea de defensa
Antes de considerar un reintento, debes tener una definición clara del éxito. Una simple comprobación de texto rara vez es suficiente. Los desarrolladores deben usar librerías de validación de esquemas para asegurar que el modelo se adhiera a una estructura específica.
- Validación de Esquema: Usa herramientas como Pydantic o Zod para forzar una estructura estricta. Si el modelo debe devolver una lista de cambios de archivos, cualquier salida que no sea una lista debe activar un reintento.
- Comprobación de Sintaxis: Para agentes que generan código, ejecutar un linter o un comando básico de verificación de sintaxis es una forma rápida de filtrar alucinaciones.
- Consistencia Lógica: Si un agente afirma haber editado un archivo, verifica que el archivo exista en el sistema de archivos.
Cuando falla un paso de validación, lo peor que puedes hacer es simplemente reenviar el prompt original. Esto a menudo resulta en que el modelo repita el mismo error porque los pesos están sesgados hacia esa completación específica.
Estrategias de reintento en capas
No todos los reintentos son iguales. Dependiendo del tipo de error, debes elegir una estrategia que maximice la posibilidad de un segundo intento correcto mientras minimizas la latencia.
El patrón de bucle de retroalimentación
En lugar de un reintento a ciegas, debes devolver el mensaje de error al modelo. Si el procesador de JSON falló, envía el mensaje de error específico del procesador al modelo. Dile al agente exactamente dónde estaba la coma sobrante o qué campo faltaba. Esto permite que el modelo se autocorrija basándose en el rastreo del error.
El ajuste de temperatura
Si el modelo produce basura, podría deberse a ajustes de temperatura elevados que causan demasiada aleatoriedad. Una estrategia común es reducir la temperatura en 0.1 o 0.2 por cada reintento subsiguiente. Esto obliga al modelo a mantenerse más cerca de los tokens más probables y, por lo general, más estables.
El cambio de modelo
A veces, un tamaño o arquitectura de modelo específico tiene dificultades con una tarea concreta. Si un modelo pequeño falla tres veces al generar una consulta SQL compleja, el cuarto reintento quizás debería dirigirse a un modelo más capaz. Esto añade costo pero salva la sesión de un fallo total.
Monitoreo de reintentos en el espacio de trabajo
Depurar estos bucles es difícil en una terminal estándar. Cuando ejecutas agentes como Claude Code o Codex CLI, necesitas ver los flujos de entrada y salida sin procesar simultáneamente. Aquí es donde un entorno de desarrollo dedicado cobra valor.
Usando Deska, puedes colocar múltiples paneles de terminal lado a lado para monitorear cómo diferentes agentes manejan el mismo prompt. Por ejemplo, puedes ejecutar un agente local-first en un panel y uno basado en la nube en otro. El lienzo infinito te permite alejar la vista y ver todo el historial de la conversación, lo cual es crucial cuando un agente se queda atascado en un bucle devolviendo datos mal formados.
Si usas Ask Deska, el asistente puede ayudarte a gestionar estas sesiones. Puedes pedirle que revise el estado de una terminal específica o que resuma por qué un hilo de agente en particular está fallando la validación. Esta visibilidad evita el problema de la caja negra donde pagas por tokens de API sin saber por qué el agente está atascado.
Gestión del estado durante los reintentos
Un riesgo mayor con los reintentos es la corrupción del estado. Si un agente ejecuta parcialmente un comando y luego devuelve basura, un simple reintento podría causar que intente ejecutar ese comando nuevamente, duplicando datos o rompiendo archivos.
| Estrategia | Ideal para | Riesgo |
|---|---|---|
| Reintento sin estado | Errores de esquema | Riesgo bajo, solo regenera texto |
| Reversión y reintento | Errores de ejecución | Riesgo medio, requiere copias del estado |
| Intervención humana | Errores ambiguos | Latencia alta, confiabilidad muy alta |
Para el desarrollo local, mantener tu código y archivos git en un estado limpio es vital. Debes asegurar que tu entorno de agente pueda revertir cambios si falla una validación. Esta es una parte central de la filosofía local-first: tú eres el dueño del entorno y del estado, por lo que debes tener el poder de deshacer errores del agente al instante.
Flujos de trabajo de depuración multi-agente
A veces, la mejor manera de manejar una salida basura es que otro agente la revise. Esto a menudo se llama el patrón Crítico. Un agente genera el código y un segundo agente lo valida. Si el segundo agente encuentra un error, genera la retroalimentación para el primer agente.
En Deska, este flujo de trabajo es natural. Puedes tener a tu agente principal ejecutándose en un panel de terminal mientras usas el panel de notas y cuaderno para redactar reglas de validación. Si necesitas alejarte de tu escritorio mientras un agente realiza una tarea larga con múltiples reintentos, puedes usar la aplicación móvil para monitorear los registros. Como los dispositivos se emparejan directamente a través de un relevo seguro, puedes ver si el agente finalmente produjo una salida válida o si necesita intervención manual.
FAQ
¿Cuántos reintentos debo permitir antes de rendirme?
La mayoría de los desarrolladores encuentran que tres reintentos es el punto óptimo. El primer reintento corrige errores de sintaxis simples, el segundo maneja problemas de lógica con retroalimentación actualizada y el tercero sirve como intento final con una temperatura más baja. Más allá de tres, es probable que el modelo esté alcanzando un límite de razonamiento fundamental para ese prompt.
¿Es mejor usar inferencia gestionada o modelos locales para reintentos?
La inferencia gestionada suele ofrecer mayor calidad para lógica compleja, pero los costos pueden acumularse en bucles de reintento intensos. Los modelos locales son excelentes para validación de esquemas y correcciones simples porque no generan costo por token. Muchos usuarios eligen un enfoque híbrido, usando sus propias llaves para el trabajo pesado mediante planes de precios y modelos locales para tareas menores.
¿Cómo evito bucles infinitos en agentes autónomos?
Implementa siempre un límite estricto en el número de llamadas recursivas. Además, monitorea la similitud de la salida entre reintentos. Si el modelo devuelve exactamente la misma basura dos veces, detén el proceso y alerta al usuario. Puedes usar notificaciones para mantenerte informado cuando un agente requiera ayuda manual.
Comenzando con agentes confiables
Construir sistemas confiables con IA requiere las herramientas adecuadas para observar e intervenir cuando las cosas salen mal. Si estás cansado de depurar agentes en una sola terminal estrecha, prueba un enfoque más expansivo. Puedes descargar la aplicación de escritorio gratuita para Mac, Windows y Linux para comenzar a construir con un lienzo infinito. Al organizar tus terminales, editores y navegadores en un solo espacio de trabajo, obtendrás la visibilidad necesaria para convertir las salidas basura del modelo en despliegues exitosos.