ИИ-помощник для подбора туров и отелей по Узбекистану: архитектура решения
Турист спрашивает не «отель 4 звезды в Самарканде», а «куда поехать на четыре дня с детьми в октябре». Подбор в свободной формулировке — это ровно та задача, где LLM даёт преимущество.
В чём отличие от обычного фильтра
Классический поиск по сайту требует, чтобы пользователь уже знал параметры: город, даты, категорию. Значительная часть туристов, особенно иностранных, этих параметров не имеет и уходит, не заполнив первый фильтр.
ИИ-помощник принимает запрос как есть: бюджет, состав группы, интересы, ограничения по времени. Дальше он задаёт два-три уточняющих вопроса и превращает свободный текст в структурированный запрос к вашей базе.
Ключевое здесь то, что модель не выдумывает варианты, а формирует фильтр. Ответ собирается из ваших реальных туров и отелей, а модель отвечает за понимание запроса и объяснение выбора.
Источники данных и наличие
Нужны три слоя: справочник направлений и достопримечательностей, который меняется редко; каталог туров и отелей с описаниями; и оперативные данные о наличии и ценах, которые меняются ежедневно.
Первые два слоя ложатся в векторный индекс для семантического поиска. Третий слой — только прямые вызовы к API или базе в момент запроса. Кэшировать цены и наличие в векторном индексе нельзя: устаревшая цена в ответе означает конфликт при бронировании.
Если вы работаете с внешними системами бронирования, закладывайте деградацию: при недоступности API помощник показывает вариант без точной цены и предлагает запросить подтверждение у менеджера, а не молчит.
Многоязычие и культурный контекст
Аудитория здесь шире, чем у обычного локального сайта: русский, узбекский, английский как минимум. Для иностранных туристов важны вещи, которые местным не приходят в голову: наличие визы, обмен валюты, дресс-код в мечетях, работа транспорта между городами.
Заложите эти темы в базу знаний явно. Модель без данных ответит про визовый режим по памяти, а визовые правила меняются, и устаревший ответ здесь стоит дорого — вплоть до сорванной поездки.
Названия объектов пишите с вариантами: Registon, Registan, Регистан. Иностранный турист набирает их так, как услышал, и поиск должен это выдерживать.
От подбора к бронированию
Не пытайтесь довести бронирование внутри диалога до конца в первой версии. Реалистичная цель — довести до заявки с зафиксированным набором параметров и передать менеджеру или в систему бронирования.
Для местной аудитории финал сценария почти всегда Telegram: подбор на сайте, продолжение и оплата через бот. Для иностранной — email и карточная оплата, поскольку Telegram у части аудитории не установлен вообще.
Оплата: локальные карты через Payme или Click, зарубежные — через международный эквайринг. Это две разные интеграции, и делать вид, что одна закроет обе аудитории, не получится.
Защита от галлюцинаций
Жёсткое правило: любой факт в ответе должен иметь источник в ваших данных. Расстояние между городами, время в пути, стоимость входа, часы работы музея — всё из справочника, а не из памяти модели.
Реализуйте проверку на выходе: если ответ содержит название объекта, которого нет в вашей базе, ответ не отправляется, а перегенерируется с более жёстким ограничением.
Отдельно фиксируйте в интерфейсе, что окончательные цены и наличие подтверждает менеджер. Это не отказ от ответственности, а честное отражение того, как устроен рынок с динамическими ценами.
Что это стоит
Ориентир рынка: помощник с семантическим подбором по собственному каталогу и передачей заявки — 30 000 000 – 70 000 000 сум. С полноценной интеграцией бронирования и оплаты сумма растёт кратно.
Основная работа не в модели, а в данных: описания объектов, справочники, синхронизация с системами бронирования. Если каталог не структурирован, начинать нужно с него, иначе помощник будет подбирать из пустоты.
Операционные расходы на модель при туристическом трафике сезонны и в пике обычно укладываются в 1 000 000 – 3 000 000 сум в месяц при разумном ограничении контекста.