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

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

Недавно к нам пришел проект – холдинг из девяти предприятий: переработка, агро, гостеприимство, юруслуги под общим управляющим контуром. Пришли за ИИ-аудитом. Когда мы попросили показать, откуда берётся каждый показатель отчётности, нам так и сказали: «Если вы начнёте слать запросы — откуда этот показатель, с какой системы, потом глубже, — мы погрязнем». Но легких путей мы не ищем, пришлось погрязнуть.

Модель — самая дешёвая часть проекта

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

Но если бы выбор модели решал на судьбу проекта…Как правило, все спотыкается именно о данные, на которых эта модель должна работать.

Почему справочники раньше модели

Корпоративные данные почти никогда не готовы к тому, чтобы их прочитала модель. Они разбросаны по системам, живут в разных справочниках, а часть вообще держится в головах и в устной договорённости. Один и тот же показатель на двух предприятиях называется по-разному; управленческий и бухгалтерский контуры расходятся между собой.

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

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

Почему rule-based раньше ML

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

Это сразу закрывает два очевидных пути реализации проекта. Supervised-модель обучать не на чем. Unsupervised на редких несбалансированных событиях выдаёт поток ложных срабатываний, и пользователь перестаёт ей верить на второй неделе. Отдать всё LLM тоже не выходит: без справочника, с которым сравнивать, она уверенно назовёт ошибочное значение нормальным.

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

Эту роль берёт на себя детерминированный слой на правилах. Он не самый умный, зато даёт результат сразу и, что важнее, производит первые размеченные примеры — через вердикты человека, который подтверждает или отклоняет срабатывания. На накопленных лейблах позже включается ML. LLM садится сверху, для объяснений и интерфейса. Так что порядок Rule-based → ML → LLM у нас диктует состояние данных.

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

Пример: холдинг из девяти предприятий

Вернусь к нашему проекту –холдингу из 9 предприятий.
Разные системы, разные 1С, Bitrix24, гора Excel, часть процессов вообще не записана нигде. Изучили сорок семь процессов, холдинг отобрал в аудит двенадцать. И там мы будем делать всё в том же порядке.

Самый показательный процесс — контроль закупок. Задача — ловить злоупотребления: завышенные цены, покупки в обход тендера, «срочные» заявки мимо склада. По сути, это работа на аномалии: у каждой закупки есть цена, её надо сравнить с рыночной и подсветить, если кто-то переплатил или провёл покупку в обход правил.

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

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

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

И здесь мы тоже начинаем не с модели.
Первая фаза — собрать рыночные ориентиры, привести заявки к единому формату, завести единый канал ввода, чтобы каждая закупка вообще попадала в данные. Дальше rule-based на порогах, который заодно копит лейблы через вердикты экономиста. ML — потом, когда лейблов накопится достаточно. Финальный контроль остаётся за человеком: цена ошибки в обе стороны высокая.

Второй пример — управленческая отчётность, сквозная на все девять предприятий. Классификатор показателей — порядка ста семидесяти восьми метрик, правила меняются примерно на десять процентов от периода к периоду, и у каждого предприятия свой справочник.

«Свой справочник» — не фигура речи. В управленческом учёте цифры не сходятся с системами и госотчётностью: где-то по учёту семьсот вагонов, а по факту восемьсот двадцать, и это три разных источника, которые между собой нигде не встречаются. Складские артикулы в одной системе не совпадают с 1С, синхронизации между справочниками нет вообще. У одной запчасти — оригинальный номер и десяток неофициальных дублей к нему. Одно и то же помещение на одном предприятии заведено как «помещение 1, 2, 3», на соседнем — под собственными именами, «Ромашка», «Огонёк».

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

Что на таком проекте может пойти не так

Этот проект пока еще не вышел в прод. Но мы уже заранее готовимся, зная по другим проектам, где обычно рвётся. Самый вероятный способ провалиться связан со справочниками на тиражировании. Пилот на одном предприятии сойдётся идеально. А на седьмом всплывёт статья учёта, которой нет в общей модели данных; маппинг проглотит её молча, и консолидация поедет — без ошибки, просто цифры перестанут биться с первичкой.

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

Что из этого следует

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