Три ассистента в проде: Слетать.ру — о том, что реально работает в ИИ-автоматизации
Читайте в Telegram
|
Руководитель по внедрению ИИ Слетать.ру Александр Быстров — о том, как travel-tech компания выстраивает внутреннюю ИИ-инфраструктуру и какие сценарии уже работают в проде.
Тема ИИ-ассистентов в туризме сегодня звучит практически везде — от технологических конференций до отраслевых чатов. Но за громкими анонсами и демо легко потерять главное: речь идет не о еще одном чат-боте, а о формировании нового слоя инфраструктуры, который влияет на то, как travel-tech компания обрабатывает знания, ускоряет рутинные операции и повышает качество внутренних и клиентских процессов.
Мы в Слетать.ру прошли через первые грабли, запустили несколько ассистентов в прод и готовы рассказать, что реально работает, а что нет.
На первый взгляд такие сценарии могут показаться сугубо внутренними — встречи, тексты, база знаний. Но именно через них в итоге меняется и клиентский контур. Когда компания быстрее фиксирует решения, точнее работает со знаниями и снижает число ошибок в повторяемых процессах, это отражается и на скорости изменений, и на качестве сервиса, и на устойчивости клиентского опыта.
Почему мы вообще пошли в ассистентов
Есть два способа прийти к ИИ-ассистентам: следовать тренду или решать уже накопившуюся операционную проблему. Мы пришли через второй.
В какой-то момент объем встреч, внутренних запросов, контента и регламентов становится слишком большим для ручной обработки без потери скорости и качества. На практике это означает, что менеджеры перестают удерживать весь контекст, а редакционные и операционные задачи начинают упираться в ручную пропускную способность команды. И тогда приходится либо масштабировать ее, либо менять архитектуру процессов.
Главная причина внедрения для нас — не хайп, а конкретная задача: снять с команд рутину, исключить ошибки в повторяемых задачах, высвободить время сотрудников на работу, где нужна живая экспертиза.
Принципиальное решение, которое мы приняли на старте: сначала внутри, потом снаружи. Прежде чем ставить ассистента в клиентский контур, нужно понять, как он ведет себя на реальных данных, цепочках, и получить честный фидбэк без репутационных рисков.
Как это устроено
Вся работа с ассистентами строится на единой корпоративной платформе. Это не набор разрозненных интеграций с разными API, а централизованная инфраструктура для управления моделями, контекстом, источниками данных и логикой ассистентов.
Ассистент итогов встреч
На входе — транскрипт встречи, на выходе — структурированный итог: решения, договоренности, ответственные и следующие шаги. Раньше на это уходило 10-20 минут после каждой встречи.
На первый взгляд это базовый кейс. Но качество здесь определяется деталями: ассистент должен не просто пересказать транскрипт, а учитывать участников и контекст встречи. Без этого на выходе получается шумный пересказ, а не полезный итог.
Что дало в реальности: договоренности перестали теряться. Звучит банально, но потеря решений — это реальная операционная боль в любой растущей команде.
Ассистент подготовки текстов
Посты, анонсы, новости — все, что требует соответствия редполитике и фирменному стилю.
Здесь важный технический момент: мы не просто сделали промпт «пиши в нашем стиле». Ассистент работает на основе редакционной политики, примеров реальных текстов и заданных форматов. Без них модель фактически галлюцинирует корпоративный стиль: текст выглядит правдоподобно, но не совпадает с тем, как компания говорит и пишет.
Результат: скорость подготовки материалов выросла кратно, убрали провалы качества, когда человек в дедлайн пишет что-то наспех, и это потом живет в медиапространстве.
Ассистент по базе знаний в Confluence
Ассистент отвечает на вопросы сотрудников, опираясь на внутренние регламенты, страницы отделов, инструкции.
Архитектура — классический RAG (Retrieval-Augmented Generation): ассистент не знает ответы наизусть, а в реальном времени делает поиск по корпусу документов и генерирует ответ на основе найденного контекста. В отличие от дообученной модели, RAG позволяет работать с живыми, обновляемыми источниками без переобучения.
Проблема, через которую мы прошли: Confluence — живой организм. Документы устаревают, переезжают, дублируются. Первые версии ассистента отвечали убедительно даже в тех случаях, когда опирались на устаревшие документы. С точки зрения пользователя это плохо: человек получает неправильный ответ и идет делать что-то не так.
Отсюда следующий шаг: мы строим библиотеку корпоративных БД со словарями и описаниями, чтобы связка «ИИ - данные» работала как инфраструктура, а не как разовая интеграция, которую приходится чинить при каждом обновлении.
Как мы считаем эффект
Скорость — очевидная метрика, она действительно кратно растет. Но мы смотрим глубже: оцениваем корректность ответа с учетом нескольких источников и контекста задачи, снижение ошибок в повторяемых процессах и долю задач, где результат не требует доработки человеком.
Последний показатель самый честный. Если ИИ-ассистент выдает результат, который менеджер все равно переделывает, это не автоматизация, а генерация черновиков.
По стоимости идем прагматично: стартуем с более сильной и дорогой моделью, смотрим на качество результата, а затем проверяем, где можно перейти на более дешевую без деградации метрик. Разные задачи требуют разного уровня моделей, и использовать самую мощную модель во всех сценариях обычно просто нерационально.
