ИИ-пилоты редко проваливаются из-за «плохой модели». В наших проектах модель честно показывает 80–90% качества, но проект всё равно не взлетает. Либо экономия оказывается меньше стоимости внедрения, либо автоматизируют не тот участок процесса или данные не подтверждают гипотезу. 

Привет, Хабр! Меня зовут Василий Мухин. Я развиваю направление внедрения искусственного интеллекта в К2Тех: отвечаю за прикладные ИИ-решения, пилотные проекты и оценку эффективности применения нейросетей в реальных задачах крупного бизнеса. 

Предлагаю посмотреть на несколько реальных кейсов, где на бумаге всё красиво, а в реальности вылезают грабли. Разберем, какие вопросы стоит задать до запуска пилота, где бизнес-польза, какие ресурсы нужны, что мешает дойти до прода. Это поможет сразу отсечь проекты, которые сжигают время, деньги и доверие к технологии.

Оглавление:

Кейс 1. Экономика не сходится

Кейс 2. Неправильно найдено узкое место

Кейс 3. Перенос ответственности

Кейс 4. Дорогой старт

Решение: конвейр вместо разовых инициатив

Какие кейсы чаще всего оказываются успешными

Заключение

Кейс 1. Экономика не сходится

На волне популярности ИИ многие компании начали отказываться от живых сотрудников в пользу цифровых агентов. В связи с этим в новостях не раз упоминались Amazon, Microsoft и IBM. У нас всё началось похожим образом, заказчики хотели заменить половину своих секретарей. Четверо сотрудников работали по двое в смену со средним потоком около 100 документов в день и точностью обработки входящих документов 90%. Оставшиеся 8% документов доходили до нужного подразделения только со второго раза, а 2% с третьей попытки. Поэтому гипотеза, что ИИ будет меньше ошибаться и быстрее выполнять данную работу выглядела логично.

Решили, что в смене останется один секретарь, который будет разбирать спорные случаи и обрабатывать некорректно отправленные документы. При средней зарплате 70000 рублей две ставки давали 140000 рублей экономии в месяц и 1 680 000 рублей в год без учёта налоговой нагрузки.

Для проверки гипотезы мы взяли архив входящих документов за год. В нём уже была история маршрутизации. Было понятно в какое целевое подразделение или к какому сотруднику попадал документ. Также мы использовали структуру компании, чтобы понимать, какие подразделения вообще участвуют в обработке и как они связаны между собой. По сути получилась размеченная история распределения входящего потока.

Далее мы обучили модель классификации и проверили её на выборке из нескольких сотен документов, которые она не видела ранее, чтобы оценить качество на данных, максимально похожих на реальный поток. В итоге получили точность на уровне 80%.

В итоге руководитель подразделения посмотрел расчёт и заморозил проект, так как стоимость работ не окупалась в течение 2-х лет, половина секретарей продолжала обслуживать процесс, а большей точности можно было не достичь даже после доработки.

Исходные данные

• ~100 документов в день

• текущая точность маршрутизации: ~90%

• гипотеза: ИИ позволит сократить часть секретарей

Ограничения

• точность модели на тесте: ~80%

• стоимость пилота: ~2 млн

• доработка до целевого качества: ещё 2–3 млн

Причина провала

Эффект меньше стоимости внедрения.

Результат

Проект заморожен.

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

Кейс 2. Неправильно найдено узкое место

К нам пришел запрос от поддержки клиентских продуктов финансовой компании на ускорение обработки инцидентов. В команде продукта — 9 человек, из которых 4 занимаются непосредственно клиентской поддержкой. Ежедневный поток заявок был существенным, и нагрузка на сотрудников ощущалась заметно. Логика заказчика была проста: сократить количество кликов при поиске информации, ускорить ответ клиенту. Дополнительного анализа не проводилось. Предполагалось, что основная задержка кроется именно в базе знаний.

В качестве проверки гипотезы сделали классический чат-бот для сотрудников поддержки. Сотрудник формулирует вопрос, бот ищет релевантную информацию в загруженной документации и предлагает ответ.

Загрузили документы, запустили пилот, но метрика изменилась в пределах погрешности, всего на 3-4%.

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

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

Исходные данные

• цель: ускорить поиск ответов через чат-бота

Ограничения

• база знаний неполная

• сотрудники чаще спрашивают коллег

Причина провала

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

Результат

Проект закрыт.

У меня был ещё один похожий случай, но с другим финалом. Заказчик тоже хотел чат-бота для поддержки с практически тем же сценарием. Мы согласовали детали, подготовили подробное ТЗ. Но несмотря на то, что закупка считалась мелкой, согласования заняли месяцы.

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

Сроки иногда решают всё. Ведь за время согласований могут поменяться люди, приоритеты и даже если останется тот же ЛПР, окно интереса закроется быстрее, чем закончится разработка.

Кейс 3. Перенос ответственности

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

В одном из проектов был реализован чат-бот с RAG, загрузили туда нормативную документацию и несколько недель настраивали ответы.

Оценку проводили сами юристы. Фактическое качество ответов по экспертной шкале оказалось на уровне 80-85%. Это означало, что в большинстве случаев текст нужно перепроверять, уточнять формулировки и переписывать фрагменты. Поэтому сокращение времени на подготовку ответа оказалось незначительным. Юрист по-прежнему нёс персональную ответственность за текст и тратил время на верификацию.

Исходные данные

• бот с RAG для подготовки юридических ответов

Ограничения

• фактическое качество ответов: 80–85%

• требуемое качество: ~100%. Услуга фирмы заключалась в подготовке готовых формулировок для отправки в госорганы. Ошибка или неточность недопустимы — клиент копирует ответ без правки. При фактических 80–85% юристу всё равно приходится перепроверять каждый текст, экономии времени не получилось.

Причина провала

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

Результат

Проект закрыт.

В подобных задачах допустимый порог качества почти равен 100%. При текущем уровне генеративных моделей гарантировать такой результат нельзя. ИИ пока остаётся инструментом для специалиста, а не его полной заменой.

Кейс 4. Дорогой старт

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

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

Заказчик хотел инструмент, который автоматически подбирал бы аналоги из базы складских остатков и предлагал их инженеру. Главная цель — утилизация остатков и снижение затрат на закупку новых позиций. При объёме склада около 100 тысяч позиций потенциальную экономию оценивали в десятки миллионов рублей на горизонте проекта.

Мы провели анализ структуры данных и состава остатков. Выяснилось, что для создания полноценной системы сопоставления аналогов требуется провести нормализацию данных и разработать кастомную логику сопоставления. Оценка полного проекта составила 10–15 миллионов рублей. При ожидаемой экономии срок окупаемости наступал через 1,2 года.

В ходе конкурсной процедуры заказчик выбрал более дешёвого подрядчика, который не был знаком со спецификой его деятельности, деталями задачи и ИТ-инфраструктурой. Пилот обошёлся в 1 миллион рублей. Однако без погружения в данные и контекст заказчика качество сопоставления аналогов оказалось низким, и проект не дал ожидаемого результата.

Исходные данные

• ~100 000 складских позиций

• цель: подбор аналогов и снижение закупок

Ограничения

• разнородные и неполные данные

• стоимость проекта: 10–15 млн

Причина провала

Слишком высокая стоимость входа.

Результат

Проект не запущен.

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

Решение: конвейер вместо разовых инициатив

Во всех кейсах проблема была не в технологиях, а в непроверенной гипотезе. Не были выполнены следующие условия:

1. Экономика подтверждена

2. Узкое место измерено

3. Порог качества реалистичен

4. Инвестиции соразмерны риску

5. Организационная среда готова

Если хотя бы одно из условий не выполняется, ИИ становится просто дорогим экспериментом и его дешевле закрыть на ранней стадии.

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

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

Время — главный враг пилотных проектов. Чем быстрее проверяется гипотеза, тем дешевле обходится ошибка.

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

Внутри себя мы выстроили структуру, которую назвали ИИ-офисом. В нашем представлении ИИ-офис — это:

1. Команда, которая занимается проработкой гипотез и дальнейшей реализацией инициатив.

2. Методология, по которой мы договорились работать — единые принципы для команды и всех сотрудников, участвующих в генерации и проработке гипотез.

3. Набор инструментов, которые позволяют автоматизировать работу в рамках этой методологии.

4. Инфраструктура, которая даёт возможность масштабировать решения и запускать их в продуктив.

Это среда, в которой гипотеза проходит путь от идеи до решения, не теряя прозрачности и не размазывая ресурсы. 

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

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

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

Для нас такой подход дал сокращение времени на агрегацию и отчётность по инициативам до 85% за первые три месяца. Но важнее другое: ИИ-офис перестал быть набором разовых пилотов и превратился в конвейер, где гипотезы либо подтверждаются и идут в промышленную эксплуатацию, либо закрываются быстро и с минимальными потерями.

Какие кейсы чаще оказываются успешными

У успешных проектов тоже есть общие признаки. Они повторяются в разных отраслях и практически не зависят от конкретной технологии.

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

• В системах построенных по принципу human-in-the-loop, когда ИИ работает вместе с человеком: предлагает варианты, сортирует информацию, делает предварительную обработку, но окончательное решение остаётся за специалистом.

• С задачами, где ошибка допустима и может быть исправлена: рекомендации товаров, ранжирование поиска, фильтрация спама, приоритизация заявок.

• Успешные проекты почти всегда связаны с системами, где уже накоплены большие массивы информации: история обращений клиентов, архив документов, транзакции, телеметрия, лог-данные.

• Те, где мы идём не от конкретной разрозненной гипотезы, а изначально задаём стратегический вопрос: как мы хотим целиком перестроить процесс так, чтобы искусственный интеллект выполнял максимум задач за человека. Далее подбираем набор задач, которые помогают сотрудникам получить максимальный эффект. В отличие от подхода «кто-то придумал идею, вкинул, посчитал экономику и пошёл», стратегический подход берёт за основу не гипотезу, а процесс. И вокруг этого процесса выстраивается решение.

В других случаях внедрение сложнее, поэтому многие проекты останавливаются ещё на стадии пилота.

Заключение

Когда появляется новая технология, сначала многие верят в чудо. Так было с колесом, электричеством, компьютером, интернетом. Теперь с ИИ. Кажется, что достаточно добавить новый инструмент в процесс, и всё поедет быстрее. Но волна хайпа проходит, и заказчики начинают спрашивать про ROI. Тогда вокруг новой технологии начинает формироваться культура использования.

Колесо не стало революцией после того, как его вырезали из ствола дерева. Оно стало полезной штукой, когда появились дороги, телеги, стандарты осей и люди, которые умели всё это обслуживать. Электричество не изменило промышленность в момент изобретения лампы. Оно стало прорывом, когда появились сети, правила эксплуатации и новые производственные процессы.

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