ИИ не прощает иллюзий: почему большинство проектов не доходят до внедрения

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

Эксперты Академии АйТи (кластер fabricaONE.AI ГК Softline) Даниил Монахов и Наталья Елисеева разбирали главные причины провалов и вели честный разговор о ИИ проектах на вебинаре «ИИ-проект ≠ ИТ-проект: что должен знать руководитель до старта».

		Наталья Елисеева, ведущий менеджер по развитию технологической экспертизы SLSoft
		Даниил Монахов, руководитель комплексных проектов ИИ SLSoft

Причины, по которым ИИ-проекты разбиваются еще на пути к внедрению

По статистике, подтвержденной практикой наших заказчиков, только пятая часть ИИ-проектов доходит до промышленного внедрения. Остальные закрываются на пути от пресейла до пилота или останавливаются во фронте. Из тех, что все же дошли, масштабируется едва ли половина. Цифры не в пользу внедрения искусственного интеллекта, но дело не в его качестве. Проблема в том, что классический проектный менеджмент ориентирован на детерминированный результат с самого старта, жесткий треугольник «сроки – бюджет – качество» и линейное выполнение работ. ИИ-проект является своего рода «исследовательской деятельностью», упакованной в проектные ограничения. Результат достигается через итерации, эксперименты и уточнения при максимальной неопределенности. Однако по инерции к нему часто применяют те же методы управления, что и при разработке обычного софта.

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

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

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

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

Четвертое измерение: почему классический треугольник не работает

Принципиальное различие между ИТ и ИИ-проектами не ограничивается ожиданиями. В классическом ИТ‑проекте действует треугольник «сроки – бюджет – качество», где выбирают два из трех. В ИИ‑проектах добавляются данные. И именно они становятся четвертым измерением: от их качества и количества зависит достижимая точность модели.

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

Приведем пример. В одном проекте для крупной нефтяной компании объем данных достигал около десяти миллионов документов, уже встроенных в рабочий периметр. Но даже при таком объеме качество данных может оказаться низким: на старте заказчик вместо структурированной выгрузки предоставил склейку диалогов для обучения модели. Диалоги оказались плохо структурированы.

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

Другой случай из практики: внедрение системы, оцифровывающей судебное делопроизводство. На вход подавался пакет из примерно десяти документов: постановление о штрафе, нарушение ПДД, доверенности, выписки. Все в формате PDF, с картинками. Стояла задача обработать пакет, выделить из каждого документа атрибуты: имя, фамилию, отчество, номер, тип, наличие подписи. Решение отработали на тестовом пакете и передали заказчику. Тот искусственно изменил один документ в пакете, убрал дату, ожидая, что она не будет считана. Однако временная отметка все равно появилась. Выяснилось: она присутствовала на фотографии нарушителя. Та же дата, что была в протоколе, оказалась и на фото, и модель смогла ее различить. Так обнаружили скрытую связь документ, казавшийся безупречным, содержал информацию, о которой разработчики не подозревали.

Итерационность как единственный способ не уйти не в ту степь

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

Следующий пример из практики. Стояла задача заменить оператора первой линии поддержки для производителя бытовой техники. Пользователи обращались через мессенджер, сайт и электронную почту. Первый вопрос: чем руководствуется отвечающий сотрудник? Какими уникальными знаниями он обладает и где их получил? Выяснилось, что оператор использует внутреннюю базу знаний, около 50 инструкций по технике и 30 по сопровождению претензий. Заказчик предоставил эту базу. Сложилось впечатление, что информация исчерпывающая. Аналитики приняли датасет, изучили и признали достаточным. Модель обучили. На тестовых вопросах она стала давать приемлемые ответы. Результат показали заказчику. Однако аналитик с его стороны указал на ошибку: в одном из вопросов предусмотрено три варианта ответа. Модель или оператор должны переспросить, что именно имеет в виду пользователь. Например, кнопка не работает в каком режиме, включена или выключена машина? Уточняющих запросов могло потребоваться от двух до пяти, чтобы выяснить причину. Во внутренней базе знаний эта информация отсутствовала.

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

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

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

Метрики успеха: точность, полнота и F-мера вместо принципа «сдал-принял»

В классическом проекте достижение цели фиксируется однозначно: уложились в сроки, бюджет и качество. В ИИ-проектах успех представляет собой связку бизнес-KPI и ML-метрик, точности (precision), полноты (recall) и F1. Компания подсчитывает сэкономленные средства за счет вывода операторов из рутины, и к этому добавляется точность работы модели.

Например, есть 100 кредитных заявок, в каждой нужно выделить 10 атрибутов: сумма, срок, заемщик, обеспечение. Итого 1 000 атрибутов. Система правильно извлекла 800, точность 80 %. Если система должна найти все фамилии «Иванов», но выдает «Иванова» вместо «Иванов», то падает точность (precision). Если же система пропускает половину реальных «Ивановых», то падает полнота (recall). F-мера (F1) – это среднее гармоническое между точностью и полнотой, позволяющее сбалансированно оценить модель.

На практике не встречались решения со стопроцентной точностью. Первичный подход на удачной модели дает около 75%. С итерациями точность повышается до 80%, затем до 85 и до 90%. Шаг с 75 до 80% проходит довольно быстро, ошибки уже понятны и устранимы. С 80 до 85% ошибки не очевидны, но обнаружимы. Между 85 и 90% – огромный объем работы. Тем более до 95%. Данный момент необходимо зафиксировать в техническом задании до начала работ. Заказчик и исполнитель обязаны согласовать приемлемую точность, метод ее измерения и порядок тестирования.

Дрейф данных: когда после сдачи все ломается

В классическом ИТ-проекте жизненный цикл завершается приемкой продукта. В ИИ-проекте после сдачи начинается непрерывный мониторинг, иначе данные могут «уплыть». Пример из практики: разрабатывался помощник для торгового агента. Данные о продажах хранились в PostgreSQL внутри периметра заказчика. Агент задавал вопрос на естественном языке: «Сколько нужно донести продукции до точки?» Система переводила запрос в SQL и выдавала ответ. В определенный момент сервис начал показывать неверные цифры. Причина была в том, что заказчик по требованиям информационной безопасности не мог предоставить разработчику доступ в свой периметр и ежедневно реплицировал базу данных. При репликации возникали ошибки: битые данные, неполные выгрузки. Модель обучалась на одной картине мира, а в боевой среде данные изменились. Это и есть дрейф данных. Мониторинг таких дрейфов должен быть заложен в жизненный цикл проекта еще до его старта.

Руководитель проекта как переводчик между мирами

Согласно стандарту PMI, руководитель проекта не обязан быть профильным специалистом. В ИИ‑проектах этот принцип пересматривается. Ключевая роль – связующее звено между командой и заказчиком, инженерами и бизнесом. Руководитель должен обсуждать с аналитиком дрейф данных и объяснять заказчику, почему модель извлекла дату из фотографии, а не из текста документа.

Желательно, чтобы руководитель проекта имел базовое представление о том, как работает ИИ, чем LLM отличается от ML, что такое RAG и почему мультимодальность решает задачу с рукописными справками. Программировать он не обязан, но должен понимать когда тимлид сообщает об ограничении контекста модели двадцатью страницами, а заказчик загружает сто, то возникает проблема.

В рабочих коммуникациях руководитель проекта выступает мостом и переводчиком. Если он находится внутри заказчика, то доносит мнение своей команды до функциональных заказчиков, разъясняя бизнесу суть технических терминов. Именно на него ложится коммуникация между неподготовленным заказчиком и командой. Руководитель должен оценивать: проблема, озвученная тимлидом, принципиальна или устранима? Такое понимание приходит только с опытом.

Вывод

Большинство ИИ-проектов не доходят до промышленного внедрения не из‑за несовершенства технологий, а по причине того, что управление ими продолжают выстраивать по образцу обычной разработки. Классический проектный менеджмент с детерминированным результатом и жестким треугольником «сроки – бюджет – качество» не применим там, где данные становятся четвертым измерением, а итог достигается через эксперименты. Жесткое техническое задание, фиксированные сроки, пренебрежение оценкой качества данных на старте, отсутствие формализованных процессов – вот действительные причины неудач.

Билл Гейтс справедливо заметил: «Успех – плохой учитель. Он заставляет умных людей думать, что они не могут проиграть». Поэтому учиться нужно на ошибках. Заказчик и исполнитель обязаны с самого начала согласовать не внешний вид чат‑бота, а количество планируемых итераций работы над проектом, приемлемую точность, зоны ответственности за приведение исходных данных в порядок и алгоритм действий на тот случай, когда (не «если», а «когда») модель начнет генерировать недостоверные ответы.