Большинство ресторанных чат-ботов решают одну задачу: отвечать на типовые вопросы и снимать нагрузку с менеджера. Как только гость пишет что-то нестандартное, бот просит переформулировать или переключает на человека вручную. Российская команда попыталась выйти за эти рамки и построила систему, которую назвала ИИ-метрдотелем.
Отличие от обычного бота — в глубине интеграций и персонализации. Система получает данные из трёх источников: корпоративная база знаний ресторана (меню, рекомендации, винные пары, FAQ, стандарты сервиса), профиль гостя (история визитов, любимые блюда, частота посещений, стиль общения) и операционные данные в реальном времени. За последние отвечают три внешних сервиса: IIKO сообщает о наличии блюд и ценах, Remarked управляет бронированиями и их статусами, RocketData хранит отзывы.
| Сценарий | Внешняя система | Что делает AI |
|---|---|---|
| Бронирование | Remarked | Извлекает параметры из свободного текста, проверяет слоты, фиксирует бронь |
| Платежи | Платёжный контур | Генерирует ссылку, принимает webhook, проверяет статус, уведомляет менеджера |
| Консультации по меню | IIKO + база знаний | Формирует рекомендацию с учётом наличия блюд и профиля гостя |
| Отзывы | RocketData | Классифицирует тональность, передаёт данные менеджерам |
Для связи базы знаний с языковой моделью используется RAG — подход, при котором модель не держит все данные в памяти, а в момент запроса получает релевантные фрагменты из структурированного хранилища. Это снижает риск произвольных ответов и позволяет актуализировать информацию без переобучения модели. Персонализация при этом ограничена правилами доступа: гость не получает внутренние или конфиденциальные данные, даже если они есть в базе.
Персонализация строится на истории визитов, заказах и предпочтениях гостя из профильной базы данных.
В первой версии продукта реализованы пять сценариев. Бронирование: ИИ понимает свободный текст («тихий столик ближе к окну»), извлекает параметры, уточняет недостающие данные, проверяет доступность слотов через Remarked и фиксирует бронь. Платежи: система генерирует платёжную ссылку, принимает webhook, проверяет статус транзакции и уведомляет менеджера — сценарий используется для депозитов, билетов и предзаказов. Консультации по меню: гость пишет в свободной форме, ИИ обращается к базе знаний, сверяет наличие в IIKO и формирует рекомендацию с объяснением. Отзывы: после визита система классифицирует тональность и передаёт данные в RocketData. Все сценарии работают через Telegram; расширение на сайт и другие мессенджеры запланировано в следующих итерациях.
Критичный механизм системы — передача диалога менеджеру без потери контекста. Если гость описывает конфликтную ситуацию, задаёт вопрос вне базы знаний или требует нестандартного решения, ИИ передаёт переписку сотруднику вместе с историей диалога, параметрами запроса и текущим статусом брони или оплаты. Это принципиально отличает систему от ботов, которые либо пытаются закрыть любой сценарий самостоятельно, либо просто обрывают диалог.
Для улучшения качества ответов реализован механизм обратной связи. Тестовая группа оценивает ответы через две кнопки: «Лайк» сохраняет ответ как успешный пример, «Доработать» открывает поле для комментария. Все пометки логируются в отдельную базу данных. Главный менеджер через админку просматривает предложения и принимает или отклоняет изменения. Авторы называют это файнтюнингом, хотя по сути речь идёт о накоплении качественных примеров и управляемой корректировке поведения модели — без передачи контроля над стилем коммуникации самой модели.
С технической точки зрения команда сознательно отказалась от no-code-инструментов вроде n8n. Для системы, которая работает с реальными бронями, платежами и персональными данными, авторы выбрали прямые интеграции и кастомную архитектуру с предсказуемым поведением и возможностью масштабирования. Это типичный выбор для продуктов, где цена ошибки высока: шаблонный no-code-конструктор плохо справляется с нестандартными сценариями и сложной логикой маршрутизации.