Mir Kvestov lanza el bot de IA Kvestosha y evalúa cinco modelos en 12 gates

Desde el tercer trimestre de 2026, el agregador de escape rooms «Mir Kvestov» ha encargado la primera línea de su chat al bot Kvestosha. Los clientes escriben para elegir un juego y reservarlo, y ahora les responde primero una IA. El equipo publicó en Habr un análisis de la arquitectura. Incluye una wiki de archivos markdown en lugar de fine-tuning, el enmascaramiento de datos personales antes de llegar al modelo, el acceso al catálogo del sitio mediante MCP y la comparación de cinco modelos en doce gates de seguridad.

El conocimiento vive en archivos, no en los pesos

La decisión principal del equipo fue no ajustar el modelo con fine-tuning y mantener la base de conocimiento como una wiki de archivos markdown. Este enfoque tiene consecuencias prácticas. Los archivos se leen a simple vista y se versionan, y no solo los edita un ingeniero de ML. El conocimiento tampoco depende de un modelo concreto: si aparece un LLM más potente o más barato, la wiki sigue igual. Para un proyecto que compara cinco modelos a la vez, esto es fundamental.

Otro elemento del sistema es el ciclo nocturno de correcciones con examen. Según la descripción, la base de conocimiento no permanece estática. Se revisa y se amplía con regularidad, y el resultado se comprueba con una prueba. El autor dejó los detalles del mecanismo para el artículo completo. La idea, en cualquier caso, está clara: los cambios en la fuente de conocimiento deben pasar una verificación igual que los cambios en el código.

Privacidad y actualidad del catálogo

Los datos personales de los clientes se enmascaran antes de que la consulta llegue al modelo. Es una protección a nivel de arquitectura, no una petición al LLM para que «no revele de más». Un chat de reservas recoge inevitablemente datos de contacto, y la pregunta de qué ve un modelo externo es aquí la primera que hay que resolver.

Para los datos del producto se usa otro canal. El catálogo del sitio se conecta por MCP, de modo que el bot lo consulta como una herramienta. La wiki guarda las reglas, el tono y los escenarios típicos; el catálogo, los juegos vigentes. La separación tiene lógica: el calendario y la disponibilidad de franjas cambian más rápido de lo que se puede actualizar cualquier wiki.

Cinco modelos, doce gates

Antes del lanzamiento, el equipo comparó cinco modelos en doce gates de seguridad. Aquí un gate es, en esencia, una comprobación obligatoria: el modelo que no la supera no llega a la primera línea. El anuncio no revela qué modelos participaron ni cómo quedaron en la clasificación. Esos datos serán el mayor valor de la versión completa.

Lo que se sabe por el anuncio:

• lanzamiento: tercer trimestre de 2026, el bot responde primero en el chat;
• conocimiento: wiki de archivos markdown, sin fine-tuning;
• datos de los clientes: enmascaramiento antes de llegar al modelo;
• integración: catálogo del sitio por MCP;
• mantenimiento: ciclo nocturno de correcciones con examen;
• elección del modelo: 5 candidatos, 12 gates de seguridad.

La segunda parte del material no trata de código, sino de organización. Incluye el mapa de stakeholders, las expectativas de los equipos adyacentes y cinco lecciones para un tech lead. En las implantaciones de atención al cliente, esto suele pesar más que la elección del modelo, porque el bot afecta a la vez a soporte, producto, el equipo legal y los operadores.

Qué llevarse a tu proyecto

El enfoque de «Mir Kvestov» se puede trasladar con facilidad. Empieza por una base de conocimiento en markdown: se puede versionar y mostrar a los compañeros de soporte. Conecta los datos en vivo mediante herramientas en lugar de copiarlos en el prompt. Enmascara los datos personales antes de llamar al modelo. Elige los modelos según gates de seguridad definidos de antemano, no por la impresión de una demo. Y dibuja con antelación el mapa de stakeholders: cuando se lance, el bot en la primera línea tendrá más partes interesadas que cualquier otra función del sitio.