Чат-боты в ресторанном бизнесе чаще всего начинают с простой задачи: снять часть нагрузки с менеджеров и отвечать гостям на типовые вопросы. На практике многие такие решения быстро упираются в ограничения. Бот отвечает шаблонно, не понимает свободный текст, не учитывает контекст гостя, не видит актуальные данные ресторана и при нестандартном запросе просит переформулировать вопрос или вручную переключает диалог на сотрудника.

В проекте для ресторанной сети задача была другой: сделать не справочного бота, а AI-метрдотеля, который работает как цифровой сотрудник. Он должен понимать свободный текст, учитывать историю гостя, работать с бронированиями, обращаться к меню и базе знаний, проверять актуальные данные в ресторанных системах, принимать платежи, собирать отзывы и передавать диалог менеджеру в сценариях, где требуется участие человека.

Такой продукт требует не только языковой модели. В основе должны быть база знаний, профиль гостя, интеграции с операционными системами ресторана, RAG, сценарная маршрутизация, контроль доступа, логирование и техническая архитектура, рассчитанная на работу с реальными бронями, оплатами и персональными данными.

Что должен уметь AI-метрдотель

AI-метрдотель закрывает часть функций, которые обычно находятся на стыке сервиса, бронирования, консультаций и коммуникации с гостем.

Он должен помнить, что гость любит, когда был в ресторане последний раз, какие блюда заказывал, по какому поводу приходил, какой формат посадки ему подходит и какие рекомендации уже получал. При этом система должна работать не по фиксированному набору шаблонов, а адаптировать ответ под конкретный контекст.

Для ресторана это важно по нескольким причинам. Менеджер или хостес одновременно работают с бронированиями, звонками, мессенджерами, гостями в зале, изменениями по меню, платежами и внутренними задачами. В такой нагрузке легко потерять сообщение, забыть уточнение, не учесть предпочтение гостя или ответить не в том тоне.

AI-метрдотель должен снижать эту нагрузку за счёт автоматизации повторяемых сценариев. При этом он не должен полностью заменять менеджера. В нестандартных ситуациях система должна корректно передавать диалог сотруднику, сохраняя контекст переписки и параметры запроса.

Данные, на которых строится AI-сервис

Для персонального AI-сервиса нужны три группы данных.

Первая группа — знания о ресторане. Это описания блюд, рекомендации, винные пары, гастросочетания, форматы ресторанов, правила сервиса, FAQ, ограничения, особенности коммуникации, информация о меню и внутренних стандартах. Эти данные формируют корпоративную базу знаний, к которой AI обращается при ответе гостю.

Вторая группа — данные о госте. Через интеграцию с профильной базой данных AI-метрдотель получает историю визитов, заказы, предпочтения, частоту посещений, любимые блюда, особенности коммуникации и другие параметры, которые позволяют персонализировать ответ.

Третья группа — актуальные операционные данные ресторана. IIKO даёт информацию о наличии блюд, ценах и исключениях. Remarked отвечает за реальные бронирования и статусы. RocketData используется для работы с отзывами. Платёжный контур нужен для билетов, депозитов и предзаказов.

В результате AI работает не только с текстовой базой знаний, а с текущей операционной картиной: что есть в меню, какие слоты доступны, какой статус брони, прошла ли оплата, какие отзывы оставил гость и какие действия должен увидеть менеджер.

Сценарии первой версии

В первой версии продукта были реализованы сценарии, которые чаще всего встречаются в коммуникации ресторана с гостем.

Первый сценарий — бронирование, изменение и отмена. AI понимает свободный текст, например запрос на тихий столик ближе к окну, извлекает параметры, уточняет недостающие данные, проверяет доступность, предлагает альтернативы и фиксирует бронь через Remarked. Если гость меняет планы, система обновляет бронь. Если возникает конфликт или нестандартная ситуация, диалог передаётся менеджеру.

Второй сценарий — интеграция платежей. AI генерирует платёжную ссылку, принимает webhook, проверяет статус оплаты и фиксирует транзакцию. Этот сценарий используется для билетов, депозитов и предзаказов. После успешной оплаты система уведомляет менеджеров ресторана о новом заказе или изменении статуса.

Третий сценарий — консультации по меню и напиткам. Гость может написать в свободной форме: попросить блюдо с рыбой, подобрать красное вино к стейку, уточнить гастросочетание или попросить рекомендацию под конкретные предпочтения. AI обращается к базе знаний, сверяет наличие в IIKO, учитывает данные о госте и формирует рекомендацию с объяснением.

Четвёртый сценарий — получение и обработка отзывов. После визита AI может классифицировать тональность отзыва и передавать данные в RocketData, где с ними дальше работают менеджеры ресторана.

Пятый сценарий — работа в Telegram. На текущем этапе AI-метрдотель работает в Telegram. В следующих итерациях предполагается расширение на сайт и другие мессенджеры.

Персонализация и база знаний

Ключевое отличие AI-метрдотеля от обычного чат-бота — работа с персональным контекстом и корпоративной базой знаний.

Если гость просит рекомендацию, система не должна выдавать одинаковый ответ всем пользователям. Она может учитывать прошлые визиты, заказы, любимые блюда, предпочтения по напиткам, частоту посещений, повод визита и стиль общения.

При этом персонализация должна быть ограничена правилами доступа и безопасностью данных. Гость не должен получать внутреннюю или конфиденциальную информацию, даже если она есть в базе знаний. Для этого база должна быть разделена по типам данных и сценариям использования.

RAG в этом проекте используется как универсальный слой знаний. AI обращается к структурированным данным и документам, получает релевантные фрагменты и формирует ответ на их основе. Это снижает риск произвольных ответов и позволяет связать коммуникацию с актуальными материалами ресторана.

Непрерывное улучшение ответов

Для повышения качества ответов был реализован механизм доработки и обучения на обратной связи.

Тестовая группа получает ответы AI-метрдотеля и может оценить их через две кнопки: «Лайк» и «Доработать». Если тестировщик ставит «Лайк», ответ сохраняется как успешный пример. Если выбирает «Доработать», он оставляет комментарий, по которому ответ можно улучшить.

Все доработки логируются в отдельную базу данных. Это позволяет анализировать, какие ответы требуют корректировки, какие комментарии чаще всего оставляют тестировщики и какие типы сценариев нуждаются в дополнительной настройке.

Для управления этим процессом была собрана админка. В ней главный менеджер может видеть предложения изменений от тестировщиков и принимать или отклонять их. Такой подход позволяет не отдавать процесс улучшения полностью модели, а сохранять управляемый редакторский и сервисный контроль.

В исходной статье этот механизм описан как файнтюнинг. По сути, речь идёт о накоплении качественных примеров, разборе неудачных ответов и управляемом улучшении поведения модели в стиле конкретного ресторана.

Переключение на менеджера

Второй критичный механизм — передача диалога сотруднику.

Для ресторанного сервиса важно, чтобы AI не пытался закрывать все сценарии самостоятельно. Если гость задаёт вопрос вне базы знаний, описывает конфликтную ситуацию, требует нестандартного решения, уточняет чувствительные детали или система не уверена в корректности ответа, диалог должен переходить менеджеру.

Передача должна происходить без потери контекста. Сотрудник должен видеть историю переписки, параметры запроса, текущий статус бронирования или оплаты и причину, по которой AI передал диалог.

Такой подход делает систему безопаснее. AI обрабатывает повторяемые сценарии, а менеджер подключается там, где требуется человеческое решение.

Техническая архитектура

В проекте сознательно не использовались no-code-инструменты вроде n8n. Для системы, которая работает с бронями, платежами и персональными данными, нужна предсказуемая и масштабируемая архитектура с прямыми интеграциями.

Система подключается к внешним и внутренним сервисам через API:

• Remarked — бронирования и статусы;

• IIKO — наличие блюд, цены, исключения;

• RocketData — отзывы;

• платёжный контур — ссылки, webhooks, статусы транзакций;

• Qdrant — векторное хранилище;

• PostgreSQL — структурированные данные, логи, служебные сущности.

Технический стек проекта:

• Fastify;

• TypeScript;

• OpenAI-модели;

• Qdrant;

• PostgreSQL;

• собственный оркестратор;

• маршрутизация сценариев;

• нагрузочные тесты;

• UAT;

• моки;

• изолированные сервисы.

RAG используется как рабочий слой знаний, а не как отдельная функция поиска по документам. На практике это ядро, из которого AI получает информацию для консультаций, рекомендаций и ответов по правилам ресторана.

Собственный оркестратор отвечает за маршрутизацию сценариев: когда нужно обратиться к базе знаний, когда проверить IIKO, когда создать или изменить бронь в Remarked, когда сформировать платёжную ссылку, когда принять webhook, когда передать диалог менеджеру.

Почему прямые интеграции важны

Для прототипа можно использовать no-code или low-code-связки, но в продакшн-сценарии с платежами, бронями и персональными данными этого обычно недостаточно.

AI-метрдотель должен стабильно работать с несколькими типами операций:

• читать актуальные данные;

• создавать и обновлять бронирования;

• проверять наличие блюд;

• генерировать платёжные ссылки;

• принимать webhook;

• фиксировать транзакции;

• логировать действия;

• передавать диалог менеджеру;

сохранять историю взаимодействия.

В такой системе важны наблюдаемость, контроль ошибок, предсказуемость интеграций и изоляция сервисов. Если один внешний сервис недоступен, система должна корректно обработать сбой: не потерять запрос, не создать конфликтную бронь, не подтвердить неоплаченную операцию и не дать гостю некорректный ответ.

Поэтому архитектура должна быть рассчитана не только на успешные сценарии, но и на отказоустойчивость, повторные попытки, проверку статусов и ручную эскалацию.

Что получает ресторан

После внедрения AI-метрдотель становится не отдельным чат-ботом, а частью цифрового контура ресторана.

Он помогает не терять сообщения, снижает количество ручных ответов, работает с бронированиями, учитывает данные гостя, консультирует по меню, проверяет актуальное наличие, принимает платежи, собирает отзывы и передаёт нестандартные ситуации менеджеру.

Для бизнеса результат заключается не в том, что появился новый интерфейс коммуникации, а в том, что часть сервисных операций становится управляемой, логируемой и масштабируемой.

AI-метрдотель может:

• обрабатывать типовые запросы 24/7;

• сохранять контекст общения;

• работать с историей гостя;

• давать рекомендации на основе базы знаний и данных о наличии;

• фиксировать бронирования и изменения;

• поддерживать платежные сценарии;

• передавать диалог менеджеру при нестандартных запросах;

• работать в стиле бренда;

• масштабироваться без пропорционального роста штата.

Вывод

AI-метрдотель для ресторанной сети — это не чат-бот с набором шаблонных ответов. Это система, которая объединяет языковую модель, RAG, профиль гостя, операционные данные ресторана, интеграции с Remarked, IIKO, RocketData, платёжным контуром, Qdrant и PostgreSQL, а также сценарную маршрутизацию и передачу диалога менеджеру.

Ключевое условие работоспособности такого продукта — связка трёх типов данных: корпоративной базы знаний, данных о госте и актуальных операционных данных ресторана. Без этой связки AI будет отвечать обобщённо и нестабильно. С ней он может выполнять роль цифрового сотрудника, который закрывает повторяемые сервисные сценарии и передаёт человеку те ситуации, где требуется управленческое или сервисное решение.

Для ресторанного бизнеса такая система имеет смысл там, где важно не просто автоматизировать ответы, а сохранить качество сервиса, персонализацию и контроль над процессами.