Singapore Airlines заменила сценарный чат-бот на LLM и вдвое подняла CSAT

Знакомая боль всех, кто делал клиентскую поддержку: чат-бот на сценариях. Каждый интент надо описать, каждую ветку нарисовать заранее, а человек пишет что-то вроде «рейс отменили, а у меня трансфер и отель, что делать?». Бот в ответ показывает меню из пяти пунктов. Singapore Airlines прошла через это и переписала своего бота Kris на LLM. Компания делится цифрами и архитектурными деталями, из которых можно кое-что вынести.

Что изменилось в Kris

В старой схеме на dialog-flow покрытие тем зависело от того, сколько диалогов успели описать вручную. Если нужного интента не было, разговор чаще всего уходил к оператору, хотя вопрос можно было закрыть самообслуживанием. Масштабировать такую систему тяжело: каждая новая тема означает новую ветку.

После перехода на OpenAI API бот сам разбирает намерение клиента в свободной форме, отвечает на основе базы знаний, держит разговор сразу о нескольких темах и передаёт чат живому сотруднику вместе с контекстом. Сейчас Kris отвечает на общие вопросы, обрабатывает особые просьбы, сообщает о сбоях рейсов в реальном времени и выполняет часть транзакций. Дальше в планах изменение бронирований, операции с багажом и более сложные агентные сценарии.

Результат по версии авиакомпании: CSAT вырос в 2 раза. Отдельно операторам дали инструмент суммаризации звонков на том же API, чтобы они меньше времени тратили на разбор после разговора. Среднее время обработки обращения сократилось примерно на 10%.

Flight Recommender: модель вызывает инструменты, а не выдумывает цены

Второй продукт — Flight Recommender. Клиент описывает поездку обычным языком, вместо того чтобы снова и снова крутить фильтры дат и направлений. Использование за год выросло почти втрое.

Устроено это не как «модель сама знает про рейсы». Между моделью и пользователем стоит оркестрационный слой, подключённый к данным о тарифах и доступности мест. Модель интерпретирует запрос, вызывает нужные инструменты и пересказывает результат человеческим языком. Цены и наличие мест приходят из систем авиакомпании, а не из памяти модели.

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

ИИ во всём цикле разработки, а не только в коде

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

Пример из текста: для одной коммерческой фичи команда сначала попросила модель оспорить допущения и найти неоднозначные требования. Только после этого ИИ помогал строить варианты дизайна, планы реализации, тесты и код. На выбранных активностях прирост продуктивности составил до 20%. Роль людей сместилась от производства артефактов к постановке задач, ревью и валидации.

Отдельно есть внутренняя платформа Jarvis с контролем доступа. Сотрудники работают в ней с PDF, Word, Excel и презентациями, собирают свои workflow и небольшие базы знаний. Ежемесячно ею пользуется больше 60% персонала.

Что учесть при чтении

Это кейс с сайта OpenAI, то есть материал с коммерческой целью. Методика измерения CSAT не раскрыта, неясно, с чем именно сравнивали и за какой период. Цифры по времени обработки (около 10%) и по разработке (до 20%) куда скромнее заголовочной «двойки». Их стоит считать реалистичным ориентиром, а не обещанием.

Практический вывод для команд, которые строят поддержку или поиск:

• Сценарные боты упираются в ручное покрытие тем. LLM с базой знаний снимает это ограничение, но требует качественной базы и аккуратной передачи оператору с контекстом.
• Факты (цены, наличие, статусы рейсов) нужно брать из инструментов, а модель оставлять для понимания запроса и формулировки ответа.
• Guardrails, контроль персональных данных и человеческое ревью закладывайте сразу, а не после первого инцидента.
• Проверку требований и генерацию edge cases имеет смысл внедрять раньше, чем автогенерацию кода: именно там команда Singapore Airlines описывает самую очевидную пользу.