¿Por qué el chatbot de IA de mi web tarda tanto en responder?

Un cliente con una tienda de muebles nos escribió casi molesto porque el chatbot que le acabábamos de instalar “tardaba una eternidad” en contestar. Cogimos el móvil y cronometramos: 4,2 segundos desde que el usuario pulsaba enter hasta que aparecía la primera palabra. A nosotros, que llevamos meses mirando logs de estas cosas, no nos pareció mucho. Para alguien acostumbrado al chat de WhatsApp, donde la respuesta aparece casi al instante, sí lo es.

Por qué tarda en responder un chatbot de IA tiene una respuesta bastante concreta: depende del tamaño del modelo que uses, de cuánto contexto le mandas en cada petición y de si tiene que consultar alguna herramienta externa (una base de datos, un catálogo, otra API) antes de poder contestar. Un modelo grande, con mucho historial de conversación a cuestas y una llamada a un sistema de inventario de por medio, puede tardar más de tres segundos aunque todo esté funcionando exactamente como debería.

El tamaño del modelo pesa más de lo que parece. Cuando probamos el mismo flujo con GPT-4 y con un modelo más pequeño pensado para tareas sencillas, la diferencia fue de 4 segundos a 900 milisegundos para preguntas tipo “¿tenéis esta mesa en roble?”. El modelo grande seguía siendo necesario para las consultas raras, las que mezclan varias condiciones o requieren razonar un poco. Para el resto, era pagar de más por una precisión que nadie necesitaba en ese punto.

Lo que al cliente le importaba, de todas formas, no era el número exacto, sino la sensación. Y ahí hay un truco que cambia la percepción sin tocar la latencia real: mostrar la respuesta palabra a palabra en cuanto empieza a llegar (lo que en la jerga se llama streaming), en vez de esperar a tener el texto completo para pintarlo de golpe. Psicológicamente, ver que algo “ya está pasando” se tolera mucho mejor que una pantalla en blanco con un punto girando.

Hay otras cosas que sí reducen el tiempo real, no solo la percepción. Recortar el system prompt a lo imprescindible ayuda, porque cada token de más se procesa antes de generar nada. Cachear resultados de llamadas externas que no cambian cada minuto —precios, stock aproximado, políticas de envío— también quita de en medio la parte más lenta, que casi nunca es el modelo en sí, sino la red yendo y viniendo a otro sistema; es la misma lógica que explicamos al hablar de por qué a veces no se ven los cambios de una web, solo que aplicada a datos en vez de a páginas. Y usar un modelo rápido como primer filtro, que solo escale al modelo grande cuando detecta que la pregunta lo necesita, es básicamente lo que hicimos con la tienda de muebles: mismo buzón de entrada, dos velocidades según haga falta.

El cliente de los muebles sigue con esa configuración mixta meses después. Lo que no hemos resuelto del todo, y lo decimos sin maquillarlo, es dónde trazar la línea entre “esto es simple, va por el camino rápido” y “esto necesita el modelo grande”: cada vez que se afina esa regla aparece una pregunta nueva que no encaja bien en ninguno de los dos cajones.