Три главных разочарования при внедрении ИИ, и как их избежать

Начинается всегда одинаково - с восторга! 🤪

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

Разочарование приходит позже и почти всегда в одной из трёх форм.

1️⃣ «Система закрывает слишком мало случаев»

Работает, всё верно, но люди продолжают разбирать вручную большую часть потока. Эффекта не видно.

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

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

2️⃣ «Система неверно интерпретирует данные»

В базе физически лежит всё нужное, а ответ выходит кривой.

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

Это не проблема, а задача - обычная задача анализа и обработки данных. Дубли, пропуски, выбросы, нормализация справочников.

Отдельный случай - текстовые поля с произвольными описаниями: под них пишется алгоритм, который вытаскивает ключевое из разнородного и местами противоречивого текста. Работа трудоёмкая, но точность выдачи после неё растёт в разы. В одном проекте у нас ушло 90% разработки именно сюда, и ровно это дало результат.

Вывод практический: подготовку данных нужно планировать как отдельный этап со своим сроком и своими критериями готовности. Это важный этап в любом AI-проекте.

3️⃣ «Система ошибается и придумывает»

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

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

Работает это так. Сначала тесты, а затем опытная эксплуатация на реальном потоке, каждое расхождение попадает в реестр, каждое разбирается по причине. Дальше 90% закрывается технически, и не за счёт модели, а за счёт обвязки: ограничение источников, обязательная ссылка на конкретный документ или поле, запрет отвечать при недостатке данных, маршрутизация спорных случаев на человека. Модель, которая говорит «данных недостаточно», полезнее модели, которая всегда что-нибудь отвечает.

Все три разочарования - не про модель. Все три - про то, что вокруг неё.

А где не получилось у вас?