Почему корпоративный ИИ начинается с данных, а не с модели

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

Заказчики часто удивляются, что выбор модели в корпоративной задаче — работа на день. Там, где нужен 152-ФЗ, берут то, что разворачивается on-premise в контуре: GigaChat или YandexGPT. Какую из двух — решает тест на реальных документах заказчика. Для типовых задач — извлечь поля из скана, найти нужное в документах, разметить отклонение — решения давно есть и доступны. Но судьбу проекта решают не модели, а данные, на которых они работают.

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

Почему rule-based раньше ML? На старте корпоративного проекта размеченной истории обычно нет, особенно там, где ИИ должен ловить редкие дорогие события — инциденты были, но их никто не собирал как датасет. Это закрывает два очевидных пути: supervised-модель обучать не на чем, а unsupervised на редких несбалансированных событиях выдаёт поток ложных срабатываний, и пользователь перестаёт ей верить на второй неделе. Отдать всё LLM тоже не выходит: без справочника, с которым сравнивать, она уверенно назовёт ошибочное значение нормальным. Упираются все три в одно — в отсутствие лейблов. Взять их неоткуда, пока живой человек не разметит хотя бы несколько случаев вручную. Поэтому начинают с детерминированного слоя на правилах: он даёт результат сразу и производит первые размеченные примеры через вердикты человека, который подтверждает или отклоняет срабатывания. На накопленных лейблах позже включается ML, а LLM садится сверху для объяснений и интерфейса. Порядок Rule-based → ML → LLM диктует состояние данных.

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

Пример — холдинг из девяти предприятий: переработка, агро, гостеприимство, юруслуги под общим управляющим контуром. Разные системы, разные 1С, Bitrix24, гора Excel, часть процессов вообще не записана нигде. Изучили сорок семь процессов, холдинг отобрал в аудит двенадцать. Самый показательный — контроль закупок: ловить злоупотребления — завышенные цены, покупки в обход тендера, «срочные» заявки мимо склада. Для сравнения нужны список закупок и эталон рыночных цен. Ни того, ни другого в пригодном для машины виде нет. Реестр закупок — Excel, который снабженец ведёт вручную: дата, инициатор, участок, позиции, поставщик, счёт, сумма. Взяли выборку за два месяца, пятьдесят...