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

Среди них — умный поиск авиабилетов. На основе текстового запроса система распознает, куда хочет полететь пользователь, когда, на сколько дней, и применяет фильтры — прямой рейс, перелет с детьми и так далее. Или другой пример — подборки в сервисе Впечатлений. Авиасейлс предлагает редакторские подборки, а нейросеть может создать уникальную по запросу пользователя.

Примеры того, что закрывают GenAI-продукты в Авиасейлс:

Основная метрика для GenAI-фичей — это качество. Но проблема в том, что модели недетерминированы — их ответ может отличаться даже на один и тот же запрос в разный момент времени. При этом у каждого GenAI-продукта качество означает что-то свое. Для Умного поиска это может быть, например, корректность распознавания дат и направлений, для подборок с помощью нейросетей — точность ответа на вопрос и использование источников. Чтобы развивать все это многообразие, нужна система.

Авиасейлс разделил процесс оценки качества на три этапа. У каждого из них есть своя задача.

На этом этапе команда подбирает критерии, которые помогут оценить качество конкретного продукта, и сводит их к единой метрике в процентах.

Критерии различаются в зависимости от продукта, вот некоторые из них:

• Корректность распознавания ключевых сущностей: дат, локаций, фильтров, интентов
• Точность распознавания вопроса
• Релевантность ответа
• Полнота ответа
• Корректность используемых источников

Поверх этого — соблюдение ToV, модерация и соблюдение политик бренда.

Критерии имеют разный вес: если в умном поиске система не поняла даты, то неважно, поняла ли она все остальное, — пользователь точно получит неправильные билеты.

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

Далее прогоняет несколько моделей и сравнивает по итоговому скору, скорости и цене. Цена пока имеет консультативный характер, поскольку команда ожидает удешевления моделей.

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

Через неделю данных уже достаточно для разметки реальных запросов по критериям. Дальше процесс такой:

Когда большинство гипотез проверены и качество достигло уровня «хорошо», продукт раскатывают на всех. Но расслабляться нельзя: LLM периодически деградируют — то, что работало вчера, может не работать завтра. И любое продуктовое изменение — даже переименование фичи — меняет поведение пользователей и может повлиять на качество.

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

1. Автоматизация охватывает метрики, которые удалось достаточно хорошо автоматизировать.

2. Ручная разметка покрывает то, что автоматизировать не получилось. Авиасейлс привлекает разметчика с доменной экспертизой. Ему дают подробные инструкции и погружают в тональность бренда. Для проверки фактической точности — нужна ли виза в Китай, какие документы требуются — тоже важен разметчик. Фактическая информация и актуальные источники часто меняются и сложны для LLM, поэтому команда больше доверяет человеку, который может использовать нужные данные и убедиться, что учтен весь контекст.

После всех трех этапов Авиасейлс обычно приходит к качеству минимум 95%. Но означает ли это, что можно перестать работать над качеством? И что скрывается за оставшимися 5%?

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

Одни и те же 95% качества могут выглядеть по-разному:

Каждая ячейка матрицы — отдельная зона работы:

• Распознали и нашли — ключевая метрика, которую нужно растить.
• Не распознали и нашли — критичные ошибки, которые убирают в первую очередь. Пользователь видит неправильные билеты, понимает, что что-то не так, и доверие к нейросетям падает.
• Распознали, но не нашли — повод доработать бизнес-логику и фидбек. Например, пользователь ищет прямой рейс из Москвы в Париж — прямого нет, но система может сообщить об этом и предложить билеты с пересадкой. Или пользователь ищет билет через 5 лет — система может объяснить, в каких диапазонах реально можно искать. В обоих случаях пользователь в следующем запросе перетекает в нужную категорию.
• Не распознали и не нашли — некритичные баги, если их не слишком много.

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

Но самое ценное — кейсы, где команда считает ответ корректным, а пользователь говорит «нет». Именно на них калибруется понимание «правильного ответа».

Три примера из реальной практики в Умном поиске:

В ответ на запрос «хочу в Европу» — система выдала Белград, Мадрид, Берлин, Париж. Формально все корректно — это Европа. Но пользователь ответил: «А где Италия?» Скорее всего, он ожидал какой-то особый ответ, подразумевая в том числе Италию, при этом не дал никаких деталей модели. Поэтому ответ получился только отчасти релевантным.

В ответ на запрос «на море в ноябре» — система выдала Коломбо, Дубай, Доха, Гоа. Строго говоря, Коломбо — это океан, а не море. Но пользователю понравилось, потому что он хотел пляжный отдых, и такие нюансы его не интересовали.

«Заграницу, как можно дешевле» — система выдала Алматы, Бишкек, Астана. Формально корректно: за границу и дешево. Но пользователь сказал, что имел в виду совсем другое.

Еще одна сложность — неоднозначные запросы: «хочу улететь на Рождество» — декабрь или январь? «Примерно на недельку» — 5 дней или 10? Эти несовпадения используются, чтобы калибровать инструкцию разметки качества и убедиться, что она отражает реальные ожидания пользователей, а не представления команды.

Накопленные несовпадения привели к выводу: задача умного поиска — не только вытаскивать параметры (дату, направление, фильтры), но и понять, зачем человек пришел, и подобрать выдачу под то, что он реально ищет.

Команда провела эксперимент: выделила три сценария, в которых пользователю нужно принципиально разное:

1. Точная дата — «хочу улететь завтра». Пользователь знает, когда летит, ему нужны конкретные билеты.
2. Примерные даты — «хочу улететь на недельку в марте». Пользователь определился приблизительно, ему нужна гибкость.
3. Широкий запрос — «хочу улететь куда-нибудь зимой». Пользователь не определился, ему нужно вдохновение и варианты.

Для каждого сценария адаптировали выдачу: разные экраны, разная логика подбора результатов. И увидели, что ключевая метрика, напрямую связанная с букингами, выросла на 8-20% в зависимости от платформы.

Когда команда достигла качества ответов на уровне 95%, улучшения и багфиксинг перестали давать рост продуктовых метрик. Это показало, что следующая ступень качества — не только распознавать параметры поиска корректно, но и правильно распознать интент и направить пользователя к нужному результату.

Когда Авиасейлс достигла высокого уровня качества GenAI-ответов, дальнейшие улучшения распознавания не давали сопоставимого бизнес-эффекта. А переход к пониманию интента — зачем пользователь пришел и какой результат ему нужен — дал +8-20% прироста к ключевой метрике. Авиасейлс перешел от модели «корректно распознать параметры» к модели «понять интент и адаптировать результат» — и именно это сдвинуло бизнес-метрики.