Корпоративный ИИ: почему модель подключают последним, а данные готовят месяц
В мире прикладного искусственного интеллекта существует золотое правило, которое часто противоречит ожиданиям заказчиков: детерминированные правила и подготовка данных приходят раньше машинного обучения. Опыт разработчиков показывает, что без приведения данных к единому стандарту даже самая совершенная модель выдаст уверенно ложные результаты. В статье разбирается методология, где «грязная» работа со справочниками и реестрами становится фундаментом, на котором строится надежность бизнес-систем.
# Почему модель подключают последней: стратегия данных в корпоративном ИИ
Разработка искусственного интеллекта для бизнеса часто подается публичность как магия: загрузил данные, получил результат. Однако в реальности внедрение ИИ в крупные холдинги — это прежде всего работа с информацией, а не с алгоритмами. Опыт команды, реализующей прикладные решения для бизнеса, показывает, что выбор модели занимает не больше дня, тогда как подготовка данных требует от месяца до нескольких лет.
Фундамент из правил перед нейросетями
Самая распространенная ошибка в корпоративных проектах — попытка сразу применить сложные модели машинного обучения (ML) или крупные языковые модели (LLM) к хаотичным данным. Проблема в том, что корпоративные данные редко готовы к анализу. Они разбросаны по разным системам, живут в неструктурированных форматах (Excel, рукописные записи) или вообще существуют лишь в головах сотрудников в виде устных договоренностей.
Стандартная практика успешных проектов выстраивается по принципу «Справочники — перед — Модель». Прежде чем подключать любую интеллектуальную систему, необходимо свести разрозненные справочники в единую модель данных. Это означает, что один и тот же показатель на разных предприятиях холдинга должен иметь одинаковое значение и имя, а учетные данные должны полностью коррелировать с первичными документами.
Если на входе в систему будут несопоставимые цифры, модель выдаст красивый и уверенный отчет, который на деле будет ошибочным. Такая ошибка опаснее явной, так как отчет будет выглядеть аккуратно, и никто не захочет сверять его с первичкой. Именно поэтому детерминированные правила (детерминированный слой) работают раньше ML. Они не самые «умные», но дают мгновенный результат и, что критически важно, помогают собирать первичные размеченные примеры (лейблы) для последующего обучения моделей.
*«Плата за такой порядок честная: первый месяц не дает эффектного демо, потому что уходит на данные, — зато то, что выходит в прод, не разваливается на первом нестандартном вводе».*
Три пути реализации и роль человека
В проектах, где нужно выявлять редкие и дорогие события (например, инциденты или злоупотребления), существуют три основных подхода, каждый из которых сталкивается с одной проблемой — отсутствием готовых разметок для обучения.
1. Supervised-модели: Не на чем обучать, так как история размеченных случаев отсутствует. 2. Unsupervised-модели (обучение без учителя): На редких и несбалансированных событиях часто выдают поток ложных срабатываний. Пользователи теряют доверие к системе уже на второй неделе работы. 3. LLM (большие языковые модели): Без надежного справочника для сверки модель уверенно назовет ошибочное значение нормальным.
Решение кроется в гибридной архитектуре: Rule-based → ML → LLM. На старте работу берет детерминированный слой на правилах. Он производит первые размеченные примеры, а человек подтверждает или отклоняет срабатывания. Только накопив достаточно данных, подключаются ML-алгоритмы, а LLM добавляются сверху для объяснений результатов и работы с интерфейсом. Финальный контроль на редких и критических событиях всегда оставляют за сотрудником, так как цена ошибки в обе стороны крайне высока.
Кейс: Холдинг из девяти предприятий
Практический пример иллюстрирует масштаб задачи. Команда взяла проект крупного холдинга, включающего перерабатывающие предприятия, агробизнес, гостеприимство и юридические услуги. Заказчики хотели ИИ-аудит, но когда попросили проследить происхождение каждого показателя отчетности, были встречены отказом: глубокий анализ потребовал бы месячной работы, а данные в текущем виде неструктурированы.
Одним из ключевых процессов стал контроль закупок. Цель — выявлять злоупотребления: завышенные цены, обходы тендеров. Для этого нужны два элемента: реестр самих закупок и эталон рыночных цен.
Анализ реестра показал шокирующую картину: * Закупки часто согласовывались устно или по телефону без документального следа. * Почти две трети записей не имели формального регистрационного номера. * Отсутствие единого эталона рыночной цены, который хранился только в голове снабженцев.
Модель не могла быть подключена сразу. Первой фазой стало приведение заявок к единому формату и создание канала ввода данных. Только после этого запускался слой правил на порогах, который копил лейблы. ML и LLM последовали позже.
Аналогичная ситуация с управленческой отчетностью. Из ста семидесяти восьми метрик правила меняются каждый период, а у каждого из девяти предприятий — свой справочник. Названия помещений или артикулов запчастей различаются в разных системах. Без предварительного маппинга и приведения к единому стандарту RAG-агент консолидировал бы несопоставимые цифры, выдавая «правильно ошибочный» отчет.
Риски и версионирование справочников
Основной риск при масштабировании ИИ-решений связан с тиражированием правил на новые предприятия. Пилот на одной структуре может пройти идеально, но на другой всплывет статья учета, которая не учитывается в общей модели данных. Маппинг может проглотить такую статью без ошибки, и консолидация пойдет неверно.
Для предотвращения этого применяются следующие меры: * Версионирование справочной модели. * Проверка полноты маппинга перед подключением каждого нового предприятия. * Внедрение алертов на неизвестные статьи, которые не легли ни в одну категорию.
Отдельной нерешенной задачей остается поиск стабильного эталона рыночных цен и частота его обновления. Готового универсального ответа пока нет, что требует постоянного внимания к data-слою.
Вывод: данные определяют судьбу проекта
Опыт нескольких десятков проектов демонстрирует, что трудозатраты и риски сосредоточены в data-слое, которого на входе обычно нет. По тому, какую модель предлагает подрядчик, о проекте почти ничего нельзя судить. Критически важно посмотреть на происхождение данных и то, кто будет поддерживать их в порядке.
Пока не будет проделана работа со справочниками и не прослежен путь показателей от первоисточника до дашборда, любые попытки внедрить ИИ обречены на провал или, что хуже, на создание иллюзорной системы отчетности. Проект либо состоится благодаря фундаментальной работе с данными, либо развалится через полгода после эффектного запуска.
Пояснение терминов
* Детерминированные правила (Rule-based): Алгоритмы, работающие по жестко заданным инструкциям (если А, то Б). В отличие от нейросетей, они предсказуемы и прозрачны, но менее гибки. * Размеченные примеры (Лейблы): Набор данных, куда вручную вписаны правильные ответы или вердикты для обучения искусственного интеллекта. * RAG-агент (Retrieval-Augmented Generation): Система, которая ищет информацию в внешних источниках и использует её для генерации ответа, вместо того чтобы опираться только на свои внутренние знания.