"Mundo de Quests" lanza el bot de IA Questosha y prueba cinco modelos en 12 puertas críticas

"Mundo de Quests" —un agregador de escape rooms reales— utiliza desde el tercer trimestre de 2026 un bot de IA llamado Questosha en su centro de contacto. El bot recomienda quests según la solicitud del cliente, responde con datos del catálogo, explica las reglas, recoge información para la reserva y transfiere al cliente a un operador humano cuando es necesario.

Para la compañía, el centro de contacto es una fuente de ingresos: el cliente escribe, recibe una recomendación y reserva. Por eso el bot debe vender, no solo reducir costes. La previsión para el cuarto trimestre de 2026: una cuarta parte de los mensajes se resolverán sin operador, y el tiempo hasta la primera respuesta caerá de cinco minutos a un minuto y medio.

Una wiki de archivos markdown como base

El sistema se sostiene sobre una wiki para LLM: una base de conocimiento formada por archivos markdown con reglas y procedimientos. Las reglas no se escribieron a mano: agentes de IA analizaron 7,5 millones de diálogos históricos de operadores (anonimizados), extrajeron guiones y mejores prácticas, y añadieron las restricciones legales de la empresa.

La wiki se divide en tres capas: política (HSB —prohibiciones estrictas, vetos absolutos como contenido erótico, armas o restricción de libertad; reglas sobre edad y consentimiento—), escenarios (reservas, prepago/pago, selección de quest) y procedimientos (formato de las recomendaciones, algoritmos, reacciones ante peticiones especiales).

La wiki solo contiene procedimientos y formulaciones, sin precios, direcciones ni horarios. El bot obtiene los datos de cada quest desde la base de datos del sitio antes de responder, mediante herramientas: search_quests (búsqueda por ciudad, temática, edad, número de jugadores, precio, duración), get_quest, list_cities, platform_info, cálculo de precios y recomendaciones.

Enmascaramiento de datos y ciclo nocturno

Los datos personales no salen hacia servicios externos. Al modelo solo llegan seudónimos (PERSON_1, PHONE_1, EMAIL_1), y la vinculación se almacena localmente. El reconocimiento utiliza expresiones regulares, la biblioteca Natasha y pymorphy3, con supresión de falsos positivos.

Cada noche, a las 3:00, un modelo avanzado analiza los 300 mensajes del día y actualiza la wiki: corrige el texto, añade ejemplos y pone a prueba nuevos escenarios mediante un examen (umbral de aprobación 70/100; un dato inventado limita la puntuación a 20 como máximo). Los errores se clasifican en seis categorías: fallo técnico, regla no mostrada, contexto largo (>100K tokens), contradicción en la wiki, ambigüedad de regla y error del modelo. Al tercer error repetido, se genera una solicitud de corrección de código.

Comparación de cinco modelos en escenarios críticos

Se probaron cinco configuraciones en 25 diálogos reales (12 puertas, es decir, escenarios críticos cuyo fallo se considera un incidente). El juez, el prompt y las herramientas fueron idénticos, con temperature = 0.

Resultados por puertas y seguridad:

• Qwen3 0.6B (Ollama, local): 12/12 puertas, 7/7 seguridad, 6,3 s de respuesta, 0 ₽ • Qwen3-235B-A22B (Yandex AI Studio): 12/12 puertas, 6/7 seguridad, 7,0 s de respuesta, 12,10 ₽ • YandexGPT Pro (Yandex Cloud): 11/12 puertas, 7/7 seguridad, 3,3 s de respuesta, 5,36 ₽ • GigaChat-2 Lite (Sber): 10/12 puertas, 5/7 seguridad, 5,2 s de respuesta, 3,42 ₽ • T-Pro 2.0 (A100, local): 8/12 puertas, 5/7 seguridad, 23,0 s de respuesta, 0 ₽

Los mejores en puertas fueron dos modelos con 12/12: Qwen3 0.6B (local, gratuito, rápido) y Qwen3-235B-A22B (en la nube, más lento, más caro). YandexGPT Pro obtuvo 11/12 con la mejor velocidad (3,3 s por respuesta). T-Pro 2.0 mostró el peor resultado: 8/12 puertas con la respuesta más lenta (23 s). La elección depende de las prioridades: el alojamiento local exige recursos de cómputo, mientras que los servicios en la nube añaden coste y latencia, pero ofrecen flexibilidad de escalado.