Поделиться кейсом
Generation AI Awards
Поделиться кейсом
Generation AI Awards
2ГИС — российская IT-компания, разработчик городских карт со справочником, навигатора и сервиса бронирования отелей «Отелло». Ежемесячная аудитория продуктов 2ГИС — 84 млн пользователей, в компании работают более 1200 инженеров.
Когда MVP работает, а пользоваться не спешат
В 2ГИС команда AI-сервисов занимается автоматизацией внутренних процессов — от контроля качества в отделе продаж до классификации обращений в поддержке и модерации контента. Команда сэкономила тысячи человеко-часов с помощью AI, но к этому результату пришли не сразу — сначала столкнулись с тем, что сотрудники не были готовы использовать AI-инструменты.
Кейс 1. Контроль качества звонков: почему MVP не прижился
В отделе продаж 2ГИС есть контроль качества — сотрудники прослушивают звонки менеджеров и проверяют, насколько они следуют скрипту. По итогам дают обратную связь: например, если сотрудник не представился или не отработал возражения.
Команда сделала прототип, который транскрибирует звонки, классифицирует их по типам и анализирует по критериям качества с помощью промптов. В интерфейсе — список звонков, рядом с каждым галочки и крестики по критериям: поздоровался вежливо — галочка, не отработал возражения — крестик.
Из десятков потенциальных пользователей инструмент стали применять только трое руководителей. Почему? У этого оказалось три причины:
Новый интерфейс — это сложно
Люди годами работают в своем понятном интерфейсе, оперируют привычными терминами. Новые кнопки непонятны, переходить на них готовы не все.
Продукт не вписан в привычный процесс
У сотрудников годами отработанная схема: блокнот, CRM, понятная последовательность действий. Команда предложила полностью новый процесс, но сотрудники не были готовы перестраиваться.
Не было доверия к AI-оценкам
Система ставила оценки с помощью промптов: Вася хорошо проговаривает критерии, а Петя — плохо. Но руководитель не мог подойти к подчиненному и сказать «ты плохо работаешь по этому критерию», потому что на вопрос «а почему?» единственный ответ — «нейросеть решила». Руководители не считали это аргументом и не хотели использовать такие данные.
Кейс 2. Классификация тикетов саппорта: когда автоматизация масштабирует проблемы
Следующий кейс показал, что автоматизация не равняется оптимизации — даже если все хотят автоматизировать и подразумевают под этим экономию ресурсов.
В 2ГИС есть служба поддержки бронирования отелей, где операторы помогают клиентам. Команда решила автоматически классифицировать входящие тикеты по тематикам, чтобы выявлять категории и отслеживать время обработки.
Сделали прототип, отдали саппорту, ждали статистику. Вместо статистики пришли с проблемой: сотни похожих меток оказались в разных кластерах. Одна и та же тема превращалась в пять разных меток:
У сотрудников саппорта не было устоявшихся правил разметки, все работали и классифицировали так, как им было комфортно. Модель воспроизвела эти различия в масштабе без учета особенностей.
Как команда изменила подход: работа с рисками важнее работы с моделями
Из двух кейсов команда извлекла выводы, которые определили дальнейшую работу.
Усилия на внедрение = усилиям на разработку. Когда оцениваешь задачу, считаешь: написать код — X часов, на тесты уйдет N часов. Оказывается, это только половина пути. Чтобы сервис работал и экономил человеко-часы, нужно потратить еще столько же времени. Об этом надо думать заранее.
Если процесс неструктурирован сам по себе, автоматизация масштабирует проблемы, а не решает их. Сначала надо разобраться, как процесс устроен и есть ли смысл его ускорять.
После первых неудач у технических команд часто возникает соблазн взять самую последнюю модель — и точно получится. По опыту 2ГИС, это ловушка: человеческий фактор и риски не менее важны, чем мощь модели. В прототипе все понятно, но для реального внедрения самая сильная модель не сильно поможет.
Команда выработала четыре принципа снижения рисков.
Пилоты на ограниченных сегментах
Запускать на 1-5% доли, собрать метрики, понять проблемы.
Ограниченный ущерб от ошибки
Когда запускали AI-агента для поддержки клиентов, случалось, что что-то ломалось — реальный человек сидит далеко и ждет помощи, а агент не попал в нужный триггер. Важно заранее понимать, какой ущерб возможен, и ограничивать его.
Прозрачные метрики
Субъективные оценки типа «скорее работает, чем нет» — не метрики. Нужны конкретные цифры, собранные в параллельном режиме.
Shadow mode
Запускать AI параллельно с человеком, а не вместо него — так можно собирать данные без риска для реальных пользователей. Именно этот принцип команда применила в третьем кейсе.
Кейс 3. Модерация отзывов: shadow mode на практике
В 2ГИС модераторы читают отзывы к заведениям на карте и проверяют их на токсичность. Запускать AI сразу на большую аудиторию было рискованно, а просить модераторов давать обратную связь помимо основной работы — нереалистично.
Решение: AI работает параллельно с модератором. Если модератору нравится результат — он копирует и отправляет. Если нет — принимает свое решение. Каждый отказ от копирования становился сигналом для команды разработки, что нужно погрузиться и улучшить этот момент.
Работа с требованиями: три неудобных правды и конфликт метрик
Когда команда автоматизирует процессы, об этом узнают другие подразделения и начинают приносить свои заявки. У внутренних заказчиков при этом есть ожидания, которые надо корректировать сразу.
100% качества не будет
ML-модели — вероятностные по природе. С классическим ML люди за 10 лет это поняли, но с LLM ожидания снова взлетели: все хотят, чтобы AI работал как человек, но с идеальным качеством.
Мгновенно не будет
Сложный агентский pipeline — классификация запроса, маршрутизация, обращение к базе данных — занимает минуту-две. Заказчик говорит: «сделайте за 5 секунд». Но чем умнее агент, тем медленнее он работает.
Бесплатно не будет
У AI своя юнит-экономика: API-провайдер — платишь за токены, локальная модель — платишь за видеокарту. Эти затраты надо считать заранее.
Отдельная проблема в конфликте метрик. Заказчики хотят улучшить все сразу, но на практике метрики тянут в разные стороны:
Поэтому надо сразу определять с заказчиком, что в приоритете: время, конверсия, удовлетворенность, стоимость? Оптимизировать все одновременно не получится.
Скорость итераций побеждает перфекционизм: чем больше экспериментов, тем быстрее результат
На старте трудно понять, какого качества удастся добиться — 90% или 70%. Чем больше экспериментов и быстрее цикл, тем выше вероятность прийти к рабочему результату. Если итерации занимают месяцы — проблема может стать неактуальной раньше, чем вы ее решите.
Четыре фактора, которые влияют на скорость цикла.
Вовлеченные стейкхолдеры
Чем больше заказчик готов отдавать обратную связь и предоставлять данные, тем быстрее движется проект. Идеальный вариант — когда у заказчика стоит KPI на запуск: если проект не взлетит, он тоже рискует премией.
Доступ к реальным данным
Получить данные сложно. Бывает, что месяц разработки позади, а данных нет — и об этом надо думать заранее.
Интеграции
Существующие системы изначально не проектировались под AI. Бывает, что все готово, а система не умеет отображать результат из-за отсутствия интеграций. Тогда приходится ждать несколько месяцев доработке на стороне сервиса.
Информационная безопасность.
Если проект работает с данными, согласование с ИБ — отдельный класс работ, который может заблокировать все.
Итоги: чек-лист внедрения AI, который 2ГИС выработал на практике
Из опыта нескольких проектов команда сформировала чек-лист для каждого нового AI-проекта.
Требования важны не менее моделей
Есть соблазн сразу взяться за pipeline, но в реальном внедрении техническая часть — лишь половина работы.
Проектируйте процесс вместе с пользователями
Без этого получается продукт на своей терминологии, с которым пользователю сложно разобраться. Узнайте, как он работает, какие кнопки нажимает, удобно ли ему.
Планируйте работу по внедрению заранее
Нужна ли интеграция? Нагрузочное тестирование? Согласование с ИБ? Не нужен всеобъемлющий план — достаточно представить, какие шаги впереди.
Быстрые итерации и обратная связь
Чем быстрее цикл «гипотеза → эксперимент → обратная связь», тем выше вероятность сойтись к рабочему результату. Длинные итерации — риск, что проблема станет неактуальной раньше решения.
Опыт 2ГИС показывает, что главная сложность AI-проектов — не в технической части. Написать код, обучить модель, собрать pipeline — это примерно половина пути. Вторая половина — сделать так, чтобы решением реально пользовались: встроить в существующий процесс, заслужить доверие пользователей, выбрать правильную метрику и не пытаться автоматизировать хаос. Демо не приносят бизнес-эффекта — внедрения приносят.
