Blog / Plataformas y migraciones
Webhooks o polling: cómo mantener fresco el contexto de tu IA
Un asistente de IA que lee los datos de ayer da las respuestas de ayer, con total seguridad. Cómo elegir entre webhooks, polling o ambos, y cómo mantener los datos que lee tu IA tan frescos como las decisiones que apoya.
Un asistente de IA solo puede estar tan al día como los datos que lee. Si un negocio se cerró hace una hora y el asistente todavía lo ve abierto, recomendará un seguimiento que nunca debería enviarse, y con mucha fluidez. El contexto desactualizado no se ve desactualizado. Se ve como una respuesta segura.
Si lideras el equipo: qué preguntar
- ¿Qué tan frescos tienen que estar los datos que lee la IA, y eso está escrito para cada fuente?
- Si se pierde una actualización de otro sistema, ¿qué la detecta y la corrige?
- ¿Los usuarios pueden ver cuándo se actualizaron por última vez los datos detrás de una respuesta?
Mantener fresco el contexto se reduce a cómo llevas los cambios desde los sistemas donde ocurre el trabajo hasta el lugar donde lee tu IA. Hay dos mecanismos básicos, y en producción casi siempre se usan los dos.
Empieza por el requisito de frescura
Antes de elegir un mecanismo, decide qué tan frescos deben estar los datos de cada tipo. La respuesta cambia según la fuente y el uso:
- Un asistente de soporte que informa el estado de un pedido puede necesitar los cambios en segundos.
- Un resumen diario de la actividad del pipeline funciona bien con datos de hace unas horas.
- Los datos de referencia, como catálogos o listas de precios, quizá cambian solo cada semana.
Escribe el requisito por fuente: “los cambios deben verse en menos de N minutos”. Así un deseo vago de “tiempo real” se convierte en una meta que puedes diseñar y monitorear.
Webhooks: la fuente te avisa
Con un webhook, el sistema de origen llama a tu endpoint cuando algo cambia. Los cambios llegan rápido y no gastas peticiones preguntando por registros que no se han movido. A cambio, asumes varias responsabilidades:
- Verifica la firma. Tu endpoint es público. Revisa la firma que el proveedor envía en cada petición, para aceptar solo eventos legítimos.
- Responde rápido, procesa después. Confirma el evento enseguida y ponlo en una cola. Las respuestas lentas hacen que el proveedor agote el tiempo y reenvíe.
- Cuenta con reintentos y duplicados. Los proveedores reenvían cuando no están seguros de que recibiste un evento. El procesamiento debe ser idempotente: procesar el mismo evento dos veces debe dejar el mismo resultado que procesarlo una, normalmente guardando el ID de cada evento.
- Cuenta con el desorden. Los eventos pueden llegar fuera de orden. Compara fechas o versiones antes de sobrescribir datos nuevos con datos viejos.
- Cuenta con eventos perdidos. Tu endpoint estará caído en algún momento, un despliegue perderá una petición o el proveedor se rendirá tras sus reintentos. Los webhooks solos no garantizan que tengas todo.
Polling: tú le preguntas a la fuente
Con polling, tu sistema le pregunta a la fuente con una frecuencia fija: “¿qué cambió desde la última vez?”. Es más simple de construir y de entender, funciona con sistemas que no ofrecen webhooks y no se pierde nada si tu lado se cae un rato, porque la siguiente ejecución retoma donde quedó la anterior.
El costo es el retraso y la carga. Los datos son tan frescos como el intervalo de consulta, y consultar muy seguido choca con los límites de peticiones del proveedor. El polling funciona mejor cuando la fuente permite filtrar por “modificado desde”, y cuando guardas un cursor o una fecha confiable de cada ejecución. Sin ese filtro, terminas leyendo todo de nuevo.
El híbrido: eventos para la rapidez, conciliación para la completitud
El patrón robusto combina los dos. Los webhooks entregan los cambios rápido. Un proceso programado de conciliación compara tu copia con la fuente a un ritmo más lento, por ejemplo cada noche, y repara lo que los eventos no trajeron: entregas perdidas, registros que cambiaron durante una caída, borrados que el proveedor nunca anunció.
Dos hábitos más lo hacen confiable. Guarda, para cada registro, cuándo se sincronizó por última vez. Y vigila los silencios: si una fuente lleva más tiempo de lo normal sin enviar eventos, avisa a alguien en vez de asumir que no pasó nada.
Lo que el contexto viejo le hace a las respuestas de la IA
Un reporte con datos viejos se nota fechado. Una respuesta de IA construida sobre datos viejos se lee como actual. Recomienda acciones que ya se hicieron, reporta problemas que ya se resolvieron y no ve lo que acaba de pasar. Quien lo detecta una vez empieza a revisar cada respuesta a mano, y el asistente pierde la confianza que debía ganarse.
Además de pipelines más frescos, ayudan dos defensas prácticas: pasa la hora de “última actualización” al contexto del modelo y muéstrasela al usuario junto a la respuesta. Así una persona ve qué tan actual es la información, y al modelo se le puede pedir que diga cuándo sus datos podrían estar desactualizados. Si quieres saber cómo están tus propios datos, nuestro chequeo de preparación para IA revisa justo esto.
Lista de frescura
- ¿Hay una meta de frescura escrita para cada fuente?
- ¿Se verifica la firma de los webhooks en cada petición?
- ¿Los eventos van a una cola y se procesan de forma idempotente, por ID de evento?
- ¿El polling usa un cursor de “modificado desde” y respeta los límites de peticiones?
- ¿Un proceso de conciliación repara los cambios perdidos de forma programada?
- ¿Se monitorean y alertan los silencios de una fuente?
- ¿La IA, y el usuario, ven cuándo se actualizaron los datos por última vez?
Escrito a partir del trabajo de nuestros ingenieros en sistemas en producción. ¿Quieres una segunda opinión sobre tu proyecto? Habla con un ingeniero.
Ver el trabajo →