Описание функциональных характеристик программного обеспечения «ИИ – отельный консьерж»

1. Назначение и общая модель

Программное обеспечение «ИИ – отельный консьерж» (далее — ПО) — программная система взаимодействия с гостями отелей и иных объектов размещения на основе больших языковых моделей (LLM). ПО ведёт диалог с гостем на естественном языке в мессенджерах и на площадках объявлений, отвечает на вопросы о номерах, питании, услугах и инфраструктуре объекта на основе базы знаний, а при отсутствии ответа в базе знаний передаёт вопрос сотруднику объекта размещения вместе с контактом гостя.

Модель поставки: один экземпляр ПО обслуживает один объект размещения (для управляющих компаний — одну управляющую компанию с её объектами). Экземпляр развёртывается в облачном контуре Лицензиата на платформе cloud.ru и конфигурируется под объект без изменения кода ПО. Состав включённых каналов и опций (витрина номерного фонда, фотокаталог, режим передачи диалогов) определяется конфигурацией экземпляра.

2. Каналы коммуникации с гостями

Диалог с гостями ведётся на естественном языке в круглосуточном режиме, без участия сотрудника — до момента передачи диалога человеку (раздел 6). Все включённые каналы работают на одном экземпляре ПО одновременно и используют общую базу знаний, общую диалоговую подсистему и общую административную панель.

2.1. Мессенджер MAX

• Приём сообщений гостя через вебхук с подтверждением обработки и дедупликацией повторных доставок; подписка вебхука настраивается автоматически при запуске экземпляра.
• Ответы бота доставляются в тот же диалог; длинные ответы автоматически разбиваются на несколько сообщений с учётом ограничений мессенджера.
• В канал MAX доставляются также ответы сотрудников из административной панели (раздел 6).

2.2. Мессенджер Telegram

• Приём сообщений гостя через вебхук по HTTPS с проверкой подлинности каждого обновления секретным токеном.
• Бот работает в личных диалогах с гостем; групповые чаты и каналы Telegram не обслуживаются.
• Ответы доставляются в тот же чат с автоматическим разбиением длинных сообщений и корректной обработкой разметки; при невозможности применить разметку сообщение доставляется обычным текстом.
• В канал доставляются ответы сотрудников из административной панели, поддерживается отправка фотографий (раздел 9).

2.3. Авито

• Обслуживание чатов покупателей по объявлениям краткосрочной аренды на аккаунте Лицензиата: приём сообщений через вебхук, ответы средствами API Авито.
• Зона работы бота ограничивается настраиваемым списком объявлений; чаты вне списка (продажа, долгосрочная аренда, чаты без привязки к объявлению) ПО не обслуживает.
• Бот определяет объект размещения по карточке объявления и отвечает на основе раздела базы знаний соответствующего объекта.
• В первом ответе бот представляется цифровым помощником владельца аккаунта и не выдаёт себя за человека.
• Если в чате отвечает сотрудник (сообщение отправлено не ПО), бот в этом чате автоматически прекращает отвечать («стоп-бот»); вопросы без ответа в базе знаний передаются в административную панель (раздел 6).

3. Диалоговая подсистема

3.1. Маршрутизация запросов

Каждое сообщение гостя обрабатывается классификатором-маршрутизатором: реплика с учётом истории диалога приводится к самодостаточному вопросу (разрешение местоимений и отсылок к предыдущим сообщениям), после чего выбирается способ обработки:

• вопрос про объект размещения и пребывание — ответ на основе базы знаний;
• вопрос о стоимости и наличии номеров — витрина номерного фонда (раздел 8, при включённой опции);
• просьба показать фотографии — фотокаталог (раздел 9, при включённой опции);
• просьба позвать человека — передача вопроса сотруднику;
• вопрос о возможностях самого бота — справочный ответ;
• вопрос вне компетенции (погода, события города, другие объекты, общие знания) — корректный отказ с пояснением, чем бот может помочь.

3.2. Ответы на основе базы знаний (RAG)

Ответы на вопросы о объекте размещения формируются по схеме Retrieval-Augmented Generation: по вопросу гостя из индексированной базы знаний (раздел 4) извлекаются наиболее релевантные фрагменты документов Лицензиата, и языковая модель формирует ответ строго на их основе.

3.3. Защита от недостоверных ответов

Контракт генерации запрещает модели сообщать сведения, не подтверждённые фрагментами базы знаний:

• ответ формируется только из извлечённых фрагментов; сведения «из общих знаний» модели в ответ не допускаются;
• если фрагменты не содержат ответа, генерация возвращает служебный маркер, и ПО не отправляет гостю сформированный текст: гость получает сообщение, что вопрос передан сотруднику, а вопрос с контактом гостя передаётся персоналу (раздел 6);
• при пустом результате поиска ответ не генерируется вовсе — вопрос сразу передаётся сотруднику;
• отрицательный ответ, подтверждённый базой знаний (например, ограничение по весу питомца), является полноценным ответом и не подменяется отказом;
• модель не даёт медицинских рекомендаций и не называет лекарственные препараты.

Каждый обмен фиксируется в журнале исходов (ответ / передача сотруднику / отказ) с основаниями ответа — журнал служит для контроля качества и офлайн-проверки доли неподтверждённых ответов на эталонном наборе вопросов.

4. База знаний и индексирование материалов

• База знаний формируется из документов и материалов Лицензиата об объекте размещения (описания номеров и услуг, меню, правила, инфраструктура) в форматах Markdown и PDF с текстовым слоем.
• Индексирование и векторный поиск выполняются средствами сервиса Managed RAG платформы cloud.ru в облачном контуре Лицензиата.
• Подготовка, первичная загрузка и обновление материалов базы знаний выполняются в рамках внедрения и сопровождения ПО; порядок актуализации базы знаний определяется соглашением сторон.
• Для экземпляров, обслуживающих несколько объектов (профиль управляющей компании), поддерживается изоляция разделов базы знаний по объектам: в ответ по конкретному объекту попадают только его документы и общие документы.

5. Обработка запросов LLM-моделями

• Обработка запросов гостя (маршрутизация и генерация ответов) выполняется большими языковыми моделями каталога Evolution Foundation Models платформы cloud.ru, размещёнными на территории Российской Федерации.
• Используемая модель задаётся параметром конфигурации экземпляра ПО и может быть заменена на иную модель каталога при конфигурировании экземпляра без изменения кода ПО.
• Текст диалогов обрабатывается моделями внутри облачного контура Лицензиата и не передаётся за его пределы.

6. Передача вопроса и диалога сотруднику

6.1. Эскалация вопроса

Если ответа в базе знаний нет (или гость попросил позвать человека), ПО передаёт персоналу карточку эскалации: вопрос гостя, контекст диалога и контакт гостя для связи. Гость получает сообщение о том, что вопрос передан сотруднику. Ответ сотрудника доставляется гостю в тот канал, откуда пришёл вопрос; бот при этом продолжает обслуживать диалог.

6.2. Режимы работы с персоналом

Режим определяется конфигурацией экземпляра:

• Веб-панель (административная панель, раздел 7) — эскалации поступают в очередь панели, сотрудник отвечает из неё; там же доступны перехват диалога и возврат его боту.
• Открытые линии Битрикс24 — экземпляр подключается к порталу Битрикс24 Лицензиата как бот Открытых линий: диалог передаётся оператору Открытых линий, ответы оператора доставляются гостю, по завершении работы оператора диалог возвращается боту. Дополнительные каналы Открытых линий (Telegram, VK и другие) подключаются и обслуживаются средствами Битрикс24.

7. Административная панель

Веб-приложение для персонала объекта размещения, входящее в состав экземпляра ПО. Доступ — по HTTPS под учётной записью персонала.

• Единое рабочее место по всем каналам: эскалации и диалоги всех включённых каналов экземпляра (MAX, Telegram, Авито) собраны в одной панели; ответ сотрудника доставляется гостю в исходный канал диалога.
• Очередь эскалаций: карточки с вопросом, контекстом и контактом гостя; подсветка времени ожидания ответа; обновление очереди в реальном времени без перезагрузки страницы.
• Мониторинг диалогов: список активных сессий и просмотр транскриптов диалогов в реальном времени.
• Перевод диалога на сотрудника и возврат боту: сотрудник может перехватить любой активный диалог — на время перехвата бот в диалоге не отвечает, сообщения сотрудника доставляются гостю от имени объекта; по завершении сотрудник возвращает диалог боту. Если сотрудник не завершил перехват, блокировка снимается автоматически по настраиваемому тайм-ауту бездействия (по умолчанию 15 минут), и бот возобновляет работу.

8. Витрина номерного фонда (интеграция с TravelLine Booking Engine)

Опция экземпляра; включается конфигурацией при наличии у Лицензиата TravelLine.

• На вопросы о стоимости проживания и наличии мест ПО запрашивает актуальные предложения в TravelLine Booking Engine по датам и числу гостей и отвечает перечнем доступных вариантов номеров с ценами за период.
• Если гость не указал даты, бот уточняет их отдельным вопросом; поддерживаются запросы на период до 30 ночей.
• При недоступности сервиса TravelLine гость получает корректное сообщение о временной недоступности сведений, вопрос может быть передан сотруднику.

9. Фотокаталог

Опция экземпляра; включается конфигурацией при наличии подготовленного фотокаталога объекта.

• По запросу гостя («покажите фото номера») ПО отправляет в диалог фотографии номера или объекта инфраструктуры из фотокаталога объекта размещения.
• Фотокаталог — структурированные данные экземпляра (перечень позиций с названиями, синонимами и снимками); формируется при внедрении и обновляется в рамках сопровождения.
• Выбор позиции каталога по запросу гостя выполняется детерминированно, без обращения к языковой модели; в журнале исходов фиксируется показанная позиция.

10. Размещение и эксплуатация

• Экземпляр ПО функционирует в облачном контуре Лицензиата на платформе cloud.ru: виртуальная машина с контейнерным развёртыванием (приложение, СУБД PostgreSQL, Redis) и сервисы платформы (Managed RAG, Evolution Foundation Models).
• Конфигурация экземпляра (объект размещения, включённые каналы и опции, ключи доступа к сервисам) задаётся единым конфигурационным файлом при установке.
• В состав дистрибутива входят сценарий установки, конфигуратор экземпляра и регулярное резервное копирование базы данных по расписанию.
• Данные диалогов (переписка, эскалации, журнал исходов) хранятся в базе данных экземпляра в облачном контуре Лицензиата и за его пределы не передаются.

11. Шифрование передаваемых данных

Все внешние взаимодействия экземпляра выполняются по защищённым каналам с шифрованием TLS (HTTPS): вебхуки и API каналов (MAX, Telegram, Авито), сервисы платформы cloud.ru (Managed RAG, Evolution Foundation Models), TravelLine Booking Engine, REST API Битрикс24, а также доступ персонала к административной панели. Входящие вебхуки дополнительно защищены проверкой подлинности отправителя (секретные токены, постоянное по времени сравнение).