--- title: "Servir el tráfico de un asistente de IA" url: https://cv.tanghoong.com/es/work/ai-assistant-queue-architecture/ locale: es description: "Rediseñar un asistente de soporte con IA sobre una cola con sondeo desde el navegador, para que ningún tiempo de espera de pasarela gobierne una conversación y ningún cliente espere detrás de otro." --- # Servir el tráfico de un asistente de IA sin mantener una conexión abierta > Rediseñé la ruta de petición de un asistente de atención al cliente con IA para que una conversación se encole y se consulte por sondeo en lugar de mantenerse abierta en una conexión síncrona — entregado e integrado. - **Papel:** Senior Web Developer - **Capacidades:** IA aplicada · Arquitectura · Fiabilidad - **Ámbito:** Plataforma de comercio electrónico en producción con asistente de IA - **Cambio:** Ruta síncrona → cola con sondeo desde el navegador ## Contexto Una plataforma de comercio electrónico en producción con un asistente de atención al cliente con IA sirviendo a sus clientes, junto a los flujos de negocio ya asentados de la propia plataforma. ## Problema y ambigüedad Hay un desajuste estructural en el centro de todo producto con LLM: un turno de modelo de lenguaje tarda habitualmente decenas de segundos, y todo lo que atraviesa una petición web camino de ese modelo —pasarelas, cortafuegos, proxies— tiene un presupuesto de tiempo pensado para peticiones de milisegundos. Un diseño síncrono tiene por tanto dos modos de fallo a la vez. El evidente es que una respuesta lenta puede superar algún límite del camino. El que se pasa por alto es que, mientras se ejecuta, ocupa ese camino, así que el siguiente cliente espera detrás. Los dos se ven igual desde fuera: la IA va lenta. ⛔ Ninguno es un problema del modelo. ## Mi papel Mi papel: trabajo en el sistema de atención al cliente con IA de la empresa —estructura de conocimiento, enrutado de respuestas, integración de herramientas, gestión de sesiones, evaluación, controles de seguridad y escalado a una persona— y diseñé y entregué el cambio de la ruta de petición que se describe aquí. También mantengo la plataforma de comercio electrónico que lo rodea. ## Levantamiento La pregunta útil no era «cómo hacemos el modelo más rápido» sino «qué hay en este camino que espera que una petición termine pronto, y qué le pasa a todos los demás cuando una no termina». Responderla convierte el problema de ajustar un modelo en un problema de arquitectura de conexiones. ## Arquitectura y compromisos Salir del tratamiento síncrono. La petición se encola; el navegador consulta cada pocos segundos y muestra la respuesta cuando está lista. Nada mantiene una conexión abierta, así que ningún techo de tiempo del camino gobierna la conversación y los clientes se atienden en paralelo, ⛔ no en fila detrás unos de otros. El coste es un cliente algo más complejo y un estado de espera visible: un intercambio que volvería a hacer, porque la alternativa falla en silencio y de forma injusta. ## Implementación e integración Trabajadores de cola sobre el framework que ya usaba la plataforma, con sondeo desde el navegador y reintentos y manejo de errores alrededor de las llamadas al modelo. Vinieron con ello dos controles más: las sesiones inactivas caducan —una conversación en silencio recibe un aviso y, si no hay respuesta, se cierra y libera la capacidad que retenía— y las peticiones más ligeras se enrutan a niveles de modelo más pequeños en lugar de que todas vayan al modelo más grande, que es el control de coste de inferencia más simple que no degrada las respuestas que importan. ## Controles de producción Reintentos y manejo de errores alrededor de las llamadas al modelo; gestión del ciclo de vida de las sesiones; y un enfoque de evaluación que se está diseñando dentro del sistema, ⛔ no añadido después: incluye la corrección cuando una sola respuesta necesita recuperar y combinar varias piezas de información, y el comportamiento ante sondeos adversarios y de ingeniería social. Esa evaluación se está construyendo, ⛔ no es un endurecimiento ya entregado: estoy describiendo un diseño, ⛔ no reclamando un resultado. ## Impacto El rediseño está terminado e integrado en la plataforma. No se publican cifras de rendimiento de este trabajo, y no se publicarán: no tengo un resultado en producción que pueda reclamar honestamente. ## Aprendizaje reutilizable Cuando una función de IA se describe como lenta, mide el camino antes de tocar el modelo. En mi experiencia el modelo suele estar haciendo lo de siempre y lo que cambió la experiencia del usuario fue la arquitectura que lo rodea, y la solución casi siempre es dejar de mantener una conexión abierta. ## Evidencia pública No se publica nada del asistente del cliente: ni su estructura de conocimiento, ni sus prompts, ni su conjunto de evaluación, ni cifra alguna de rendimiento. Los mecanismos descritos arriba son genéricos y no son propiedad de ese cliente; una implementación independiente sobre contenido propio es un sistema distinto y ajeno al negocio de aquel empleador.