Ilustración editorial original generada con IA para SPKE. Es una metáfora conceptual, no un diagrama de ingeniería ni un resultado medido.
El comprobante que no llegó
Imaginemos un asistente de atención al cliente que prepara un envío de sustitución. La aplicación envía la solicitud de envío aprobada, pero la conexión se interrumpe antes de que llegue el comprobante. Una rutina de recuperación cambia a otro modelo, le proporciona la conversación y le pide que termine la tarea. El modelo de respaldo no ve ningún mensaje de éxito y propone otro envío.
Es posible que el primer envío ya exista. Un mensaje de recuperación bien redactado podría ocultar una operación duplicada. El paso peligroso es la decisión de la aplicación de volver a ejecutar la acción, no la nacionalidad de ninguno de los modelos.
Para los equipos que combinan servicios de IA estadounidenses y chinos, esto sugiere una pregunta útil para la aceptación del sistema: tras cambiar al proveedor de respaldo, ¿puede el sistema determinar qué ocurrió realmente? Un segundo proveedor añade otra vía para generar contenido. No conserva automáticamente el estado del flujo de trabajo que lo rodea.
Comparar comportamientos, no solo formatos de solicitud
Tres fuentes primarias ayudan a situar el límite. El SDK actual de Python de OpenAI documenta dos reintentos automáticos por defecto para determinados fallos de solicitud y permite configurar los reintentos; la recepción de un flujo interrumpido no se reintenta automáticamente. SDK oficial
DeepSeek documenta límites de concurrencia por cuenta, además del uso de líneas vacías o comentarios SSE para mantener activas las conexiones en espera. El cierre documentado a los diez minutos se aplica cuando la inferencia no ha comenzado, no como plazo universal para completar una tarea. Rate Limit & Isolation
La explicación de AWS sobre las API idempotentes describe el problema de sistemas distribuidos que subyace a todo esto: si falta la respuesta, la finalización puede quedar en duda; la seguridad de un reintento requiere un contrato del servicio. Cómo hacer seguros los reintentos
Son hechos documentados que comprobamos el 26 de octubre de 2026, no un informe sobre una interrupción reciente ni una prueba comparativa de fiabilidad. Describen capas distintas: el comportamiento del SDK, la gestión de conexiones del proveedor y la semántica del servicio de negocio. Ninguno demuestra que se pueda repetir con seguridad cualquier herramienta de IA.
Antes de combinar proveedores, documenta el endpoint exacto, el modelo y la versión del SDK, los formatos de entrada y de herramientas admitidos, la configuración de reintentos, el comportamiento de los tiempos de espera y los permisos para tratar los datos. Un formato de solicitud familiar no basta. Comprueba también si el proveedor de respaldo puede recibir los mismos documentos: cambiar de proveedor no debe ampliar silenciosamente quién recibe datos confidenciales.
Separar un intento de una operación
El diseño de recuperación que proponemos parte de dos registros. Un intento registra una solicitud concreta a un modelo: proveedor, modelo, hora de inicio, resultado e identificador de solicitud disponible. Una operación registra la acción de negocio autorizada por el usuario: su finalidad, los parámetros exactos aprobados, su estado y las pruebas de su finalización. Varios intentos pueden servir a una sola operación.
En el envío ficticio, la operación debe conservar su identidad cuando otro modelo toma el relevo. Un identificador de llamada a herramienta recién generado no debe interpretarse como permiso para crear un segundo envío. A la inversa, dos envíos idénticos autorizados por separado deben seguir siendo distinguibles.
Mantén el estado operativo fuera de la conversación. Un modelo puede resumir el registro, pero el ejecutor debe consultarlo antes de actuar. Haz que esa comprobación y la reserva del derecho a ejecutar formen una única operación atómica, para que los procesos principal y de respaldo no puedan continuar ambos a la vez. Un conjunto mínimo útil de estados es: planificada, enviada, confirmada, rechazada y resultado desconocido. Desconocido es un estado real, con un responsable y una vía de resolución; no debe convertirse en fallida solo para simplificar un bucle de reintentos.
Si el servicio de destino ofrece un mecanismo de idempotencia, respeta su alcance documentado, sus reglas sobre parámetros y su periodo de retención. Un identificador local, por sí solo, no puede volver idempotente un efecto remoto. Sin un contrato de servicio adecuado o una conciliación fiable, retén las escrituras inciertas para su revisión en lugar de prometer una ejecución exactamente una vez.
Recuperar en el punto donde se produjo el fallo
Utiliza tres vías de recuperación distintas.
Solo generación. Si el paso fallido únicamente redactaba texto y no se envió ninguna acción, otro modelo puede generar un reemplazo dentro del presupuesto de tiempo y coste permitido. Mantén la salida parcial separada de la nueva; no unas silenciosamente dos respuestas incompatibles para que parezcan un único resultado continuo.
Rechazo confirmado. Si una prueba procedente de una fuente competente y fiable establece que el servicio de negocio rechazó la operación sin aplicarla, resuelve la causa antes de cualquier nuevo intento autorizado. Un destino inválido o un permiso ausente no se arreglan eligiendo un modelo más dispuesto a actuar.
Escritura incierta. Si se envió una acción pero falta su comprobante, consulta el registro oficial de operaciones del destino cuando exista. Reutiliza el resultado registrado si está confirmado. Si el resultado sigue sin resolverse, comunica esa incertidumbre y detén las escrituras automáticas de esa operación. Una búsqueda sin resultados no demuestra necesariamente que no hubo ejecución cuando la visibilidad puede demorarse.
El modelo de respaldo puede ayudar a explicar qué está pendiente o preparar un borrador para revisión. No debe inventar una confirmación, reinterpretar una aprobación ni decidir que un envío de resultado desconocido nunca ocurrió.
Dar a la recuperación un único presupuesto compartido
Los reintentos pueden ser útiles, pero las capas independientes pueden multiplicarlos. En una configuración hipotética, tres intentos de la aplicación, cada uno con tres intentos permitidos en el SDK, pueden producir nueve solicitudes antes de cualquier cambio adicional de proveedor. Es la aritmética de esa configuración, no una traza medida del SDK ni un límite máximo universal.
Asigna a un solo componente la responsabilidad sobre el plazo total, el presupuesto de intentos y la política de escalado. Cuenta los intentos reales hacia los servicios subyacentes, no solo la tarea de nivel superior. Respeta las indicaciones del servicio para reintentar, aplica esperas progresivas adecuadas y evita reproducir inmediatamente una cola sobrecargada contra el proveedor de respaldo. No utilices credenciales nuevas para eludir un límite por cuenta.
Mide por separado el tiempo hasta obtener una respuesta utilizable y el tiempo hasta confirmar una acción. Una señal de mantenimiento de conexión demuestra actividad de la conexión, no progreso de la tarea. Del mismo modo, que venza el tiempo de espera mostrado al usuario no demuestra que se haya cancelado una acción remota. La recuperación debe tener en cuenta los resultados tardíos, en lugar de permitir que desencadenen otra ejecución.
Probar la pérdida del comprobante antes de atender al cliente real
Utiliza un entorno aislado con acciones externas simuladas. Escribe los resultados esperados antes de ejecutar las pruebas. Como mínimo, prueba estos casos:
- Una solicitud de generación falla antes de que se envíe cualquier acción de negocio.
- El destino aplica una acción, pero su respuesta se pierde.
- El proveedor principal termina después de que el de respaldo ya haya producido una respuesta.
- Un flujo se detiene después de mostrar parte del texto.
- El respaldo propone cambiar los parámetros de una operación ya aprobada.
- Una operación permanece brevemente invisible en la interfaz de consulta del destino.
- La ventana de deduplicación del destino caduca antes de la recuperación.
En cada caso, inspecciona el efecto externo y el registro de la operación, no solo la última frase del asistente. Cuando se pierde el comprobante, un resultado aceptable puede ser una acción confirmada o una suspensión explícita por resultado no resuelto. Un segundo envío no es una recuperación satisfactoria. Un mensaje de éxito falso tampoco.
Informa de los efectos duplicados, las operaciones sin resolver y el tiempo de recuperación junto con la tasa de finalización. Mantén como denominador las tareas originales de los usuarios; los reintentos son intentos, no tareas exitosas adicionales. Registra también la carga de revisión y los costes de los proveedores, para que un diseño que aplaza todo no parezca ofrecer una automatización sin esfuerzo.
Qué debería aportar un segundo proveedor
Un respaldo útil conserva las restricciones de la tarea original mientras ofrece otra oportunidad de completarla. Para una tarea de redacción, eso puede significar una respuesta de reemplazo. Para un flujo de trabajo con efectos externos, puede significar un relato fiable de lo que está confirmado, lo que aún se desconoce y lo que debe ocurrir a continuación.
Empieza con una acción de consecuencias importantes y una prueba controlada de pérdida del comprobante. Si el sistema no puede recuperarse de ese caso sin duplicaciones ni certezas inventadas, añadir más modelos hará más complejo el diagrama de enrutamiento antes de volver fiable el flujo de trabajo.
Este artículo es un análisis de ingeniería original de SPKE basado en las fuentes primarias enlazadas. El escenario del envío, el modelo de estados propuesto y el plan de pruebas son ilustrativos. No ejecutamos pruebas comparativas de proveedores, no inyectamos fallos en sistemas de producción ni medimos mejoras de fiabilidad. Antes del despliegue, verifica la documentación vigente y los contratos de las herramientas que realmente utilizas.