« Mir Kvestov » lance son chatbot IA Questocha et teste cinq modèles sur 12 portes critiques

« Mir Kvestov », agrégateur d'escape games en réalité physique, utilise depuis le troisième trimestre 2026 un chatbot IA baptisé Questocha dans son centre de contact. Il sélectionne des escape games selon la demande du client, répond avec des faits issus du catalogue, explique les règles, collecte les informations nécessaires à la réservation et transfère le client à un opérateur humain si besoin.

Pour l'entreprise, le centre de contact est une source de revenus : le client écrit, reçoit une recommandation, puis réserve. Le bot doit donc vendre, pas seulement réduire les coûts. La prévision pour le T4 2026 est la suivante : un quart des messages seront résolus sans opérateur, et le délai de première réponse passera de cinq minutes à une minute et demie.

Un wiki en fichiers markdown comme fondation

Le cœur du système est un « LLM-wiki » : une base de connaissances composée de fichiers markdown contenant règles et procédures. Ces règles n'ont pas été rédigées à la main : des agents IA ont analysé 7,5 millions de dialogues historiques d'opérateurs (anonymisés), en ont extrait des scripts et des bonnes pratiques, et y ont ajouté les contraintes juridiques de l'entreprise.

Le wiki est divisé en trois couches : la politique (HSB — interdictions strictes, interdits absolus comme le contenu érotique, les armes, les restrictions de liberté ; règles liées à l'âge et au consentement), les scénarios (réservation, prépaiement/paiement, sélection d'escape game) et les procédures (format des recommandations, algorithmes, réponses aux demandes spéciales).

Le wiki ne contient que des procédures et des formulations, sans prix, adresses ni horaires. Les faits concernant chaque escape game sont récupérés par le bot dans la base du site avant de répondre, via des outils : search_quests (recherche par ville, thème, âge, nombre de joueurs, prix, durée), get_quest, list_cities, platform_info, calcul de prix, recommandations.

Masquage des données et cycle nocturne

Les données personnelles ne quittent jamais les services externes. Le modèle ne reçoit que des pseudonymes (PERSON_1, PHONE_1, EMAIL_1), la correspondance étant stockée localement. La reconnaissance utilise des expressions régulières, la bibliothèque Natasha et pymorphy3, avec une suppression des faux positifs.

Chaque nuit à 3 heures, un modèle avancé analyse les 300 messages de la journée et met à jour le wiki : il corrige le texte, ajoute des exemples, et teste les nouveaux scénarios lors d'un examen (seuil de 70/100 ; un fait inventé rapporte au maximum 20 points). Les erreurs sont classées en six catégories : panne technique, règle non affichée, contexte trop long (>100K tokens), contradiction dans le wiki, ambiguïté de règle, erreur du modèle. À la troisième récidive d'une même erreur, un ticket de développement est automatiquement rédigé.

Comparaison de cinq modèles sur des scénarios critiques

Cinq configurations ont été testées sur 25 dialogues réels (12 « portes » correspondant à des scénarios critiques, dont l'échec est considéré comme un incident). Le juge, le prompt et les outils utilisés sont identiques, avec une température de 0.

Résultats par portes et par sécurité :

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

Les meilleurs résultats sur les portes critiques sont obtenus par deux modèles à 12/12 : Qwen3 0.6B (local, gratuit, rapide) et Qwen3-235B-A22B (cloud, plus lent, plus coûteux). YandexGPT Pro obtient 11/12 tout en affichant la meilleure vitesse (3,3 s par réponse). T-Pro 2.0 enregistre le pire résultat : 8/12 portes pour la réponse la plus lente (23 s). Le choix dépend donc des priorités : l'hébergement local exige des ressources de calcul importantes, tandis que les services cloud ajoutent du coût et de la latence, mais offrent davantage de flexibilité d'échelle.