Какие данные нужны для внедрения корпоративного ИИ: подготовка и аудит

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

Как бизнес-задача определяет требования к данным

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

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

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

Три задачи и три разных набора данных

Чтобы разница стала наглядной, сравним три типовых запроса, которые чаще всего приходят от бизнеса.

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

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

Почему формулировка задачи важнее выбора модели

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

Какие типы данных нужны ИИ-системе

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

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

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

Что делать с данными, которых формально нет

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

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

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

Где искать данные внутри компании

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

• Учётные и финансовые системы на платформе 1С, где хранятся продажи, закупки, склад, кадры и бухгалтерия.
• Системы управления продажами и клиентами вроде Битрикс24 или amoCRM, где лежат сделки, этапы воронки, причины потерь и история касаний.
• Корпоративный портал, вики и файловые хранилища с регламентами, шаблонами и инструкциями разной степени актуальности.
• Сервисы технической поддержки и обращений, где накапливается переписка с клиентами вместе с категориями и сроками решения.
• Телефония и записи разговоров, которые после расшифровки дают огромный массив текстов о реальных возражениях и запросах.
• Почта и корпоративные мессенджеры, где обсуждаются согласования и нестандартные случаи.
• Веб-аналитика и логи приложений, показывающие поведение пользователей до обращения в компанию.
• Телеметрия оборудования и датчиков на производстве, в логистике и в рознице.
• Таблицы и файлы на компьютерах сотрудников, где ведётся учёт того, что не поместилось в основные системы.

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

Карта данных как первый результат проекта

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

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

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

Сколько данных нужно и за какой период

Вопрос об объёме задают почти всегда, и универсального ответа на него нет. Зависимость идёт не от общего количества строк, а от числа примеров на каждый вариант ответа, от однородности процесса и от допустимой точности. Тем не менее, ориентиры существуют, и они полезны хотя бы для того, чтобы отличить нереалистичный проект от выполнимого.

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

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

Глубина истории и срок актуальности

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

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

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

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

Как оценить качество данных до старта проекта

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

Что проверять: полнота, точность, дубли, пропуски, противоречия

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

Точность оценить сложнее, потому что эталона обычно нет. Работающий приём состоит в выборочной сверке. Берётся сто случайных записей, и сотрудник, знающий процесс, подтверждает или опровергает значения вручную. Такая проверка выявляет систематические искажения, которые невозможно увидеть в агрегатах. На одном проекте по складской аналитике сверка показала, что поле даты поставки заполняется моментом внесения документа в систему, а не фактическим прибытием груза, и расхождение достигало четырёх дней.

Дубли бывают явные и смысловые. Явные находятся по совпадению идентификаторов и удаляются механически. Смысловые требуют внимания, потому что один и тот же контрагент заведён трижды с разным написанием названия, а один и тот же товар существует под четырьмя артикулами из разных поставочных партий. Для модели это четыре разных объекта с короткой историей вместо одного с полной.

• Пропуски в середине временного ряда, которые означают либо сбой выгрузки, либо отсутствие события. Эти два случая требуют разной обработки, и различить их можно только разговором с владельцем системы.
• Значения-заглушки вроде нулевой даты, прочерка, цифры 999 или текста не указано, которые формально заполняют поле, но не несут информации.
• Логические противоречия, когда дата закрытия сделки раньше даты её создания, а сумма отгрузки превышает остаток на складе.
• Несогласованность единиц измерения, когда часть записей в штуках, часть в упаковках, а признак, который их различает, появился в системе позже самих данных.
• Расхождение справочников между системами, при котором одно и то же подразделение называется по-разному в кадровом учёте и в финансовом.
• Сдвиг во времени, когда событие попадает в данные с задержкой и на момент прогноза его там физически не было. Это самая опасная категория, потому что на исторических данных модель показывает отличные результаты, а в работе проваливается.

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

Метрики качества и допустимый порог ошибок

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

Показатель	Как считается	Рабочий порог
Заполненность критичного поля	Доля записей с непустым значением	Не ниже 95 процентов
Заполненность вспомогательного поля	Доля записей с непустым значением	Не ниже 70 процентов
Доля дублей	Повторяющиеся записи к общему числу	Не выше 1 процента
Доля логических противоречий	Записи, нарушающие правила проверки	Не выше 2 процентов
Согласованность справочников	Доля значений, сопоставленных с эталоном	Не ниже 98 процентов
Задержка поступления данных	Разница между событием и его появлением в системе	В пределах цикла принятия решения

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

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

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

Разметка и сборка обучающего датасета

Разметка нужна для задач, где модель учится воспроизводить решение. В одних случаях разметка уже есть внутри данных, потому что сотрудники годами присваивали категории и указывали итоги. В других её приходится создавать с нуля, и это самая трудоёмкая часть подготовки. По моему опыту, на разметку уходит от сорока до шестидесяти процентов всего времени проекта, и попытка сэкономить здесь обходится дороже всего.

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

1. Определить целевую переменную в терминах, которые не допускают толкований. Обращение решено означает закрытие без повторного контакта в течение семи дней, а не статус закрыто в системе.
2. Зафиксировать состав категорий или полей для извлечения. Список должен быть полным, непересекающимся и включать вариант прочее для случаев, которые не попадают ни в одну группу.
3. Собрать обучающую выборку так, чтобы в ней встречались все варианты, включая редкие. Случайная выборка пропустит редкие случаи, поэтому их добавляют целенаправленно.
4. Разметить небольшой пилотный набор из пятидесяти-ста примеров силами двух независимых людей и сравнить результаты. Расхождения показывают, где инструкция неоднозначна.
5. Доработать инструкцию, затем разметить основной объём.
6. Отложить контрольную часть набора до начала обучения и не показывать её модели ни на каком этапе.

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

Кто размечает: сотрудники, подрядчик, предразметка моделью

Выбор исполнителя зависит от того, насколько глубокие знания нужны для правильного ответа. Здесь нет универсально лучшего варианта, а есть сочетание, которое обычно работает лучше любого из вариантов по отдельности.

• Внутренние сотрудники незаменимы там, где решение требует понимания бизнеса. Классификация причин брака, оценка юридических рисков в договоре, определение правильной категории расхода. Ограничение простое, потому что у этих людей есть основная работа, и больше двух-трёх часов в неделю на разметку они не выделят.
• Внешние исполнители подходят для задач, которые объясняются инструкцией на две страницы. Извлечение полей из накладных, определение тональности отзыва, выделение упоминаний товаров в тексте. Требуют вложений в инструкцию и систему приёмки, а также решения вопроса с доступом к данным.
• Предразметка моделью ускоряет работу в несколько раз. Готовая языковая модель проходит по всему массиву и предлагает вариант, человек подтверждает или исправляет. Проверка идёт быстрее разметки с чистого листа примерно втрое, и для текстовых задач это сейчас стандартный подход.

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

Инструкция для разметчиков и контроль согласованности

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

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

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

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

Из этого следует практический порядок действий при низкой согласованности. Категории пересматриваются и объединяются, из набора убираются примеры, по которым эксперты не могут прийти к согласию, а спорная зона выносится в отдельный класс требует проверки человеком. Такое решение честнее, чем попытка выжать точность из противоречивой разметки, и в эксплуатации работает лучше, потому что система сама отправляет неоднозначные случаи специалисту.

Где хранить данные и как поддерживать их в актуальном состоянии

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

Хранилище, озеро данных, векторная база: что под какую задачу

Три типа хранилищ решают разные задачи и в зрелых проектах используются вместе.

• Аналитическое хранилище подходит для структурированных данных с понятной схемой. Внутри лежат подготовленные таблицы продаж, остатков, клиентов и операций, приведённые к единым справочникам. Это основа для прогнозных задач и отчётности. На российском рынке обычно разворачивают PostgreSQL для умеренных объёмов или ClickHouse там, где нужна скорость по большим таблицам.
• Озеро данных нужно, когда поступают файлы, записи разговоров, документы и логи в исходном виде без жёсткой структуры. Данные складываются как есть, а структура придаётся позже, при обработке под конкретную задачу. Разворачивается на объектном хранилище, в том числе в Yandex Cloud или VK Cloud.
• Векторная база обслуживает поиск по смыслу и работу языковых моделей с корпоративными документами. В ней хранятся не сами тексты, а их числовые представления, по которым находятся фрагменты, близкие к вопросу пользователя. Из распространённых вариантов используют расширение pgvector к PostgreSQL, что удобно, если база уже есть, либо отдельные решения вроде Qdrant.

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

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

Регламент обновления, версионирование, мониторинг дрейфа

Данные устаревают, процессы меняются, а модель продолжает отвечать по старым закономерностям и делает это уверенно. Чтобы это не обнаруживалось случайно, нужны три вещи.

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

Версионирование означает, что для каждого результата модели можно восстановить, на каком наборе данных она обучалась и какая версия справочников использовалась. Без этого невозможно разобраться, почему качество изменилось. Достаточно хранить снимки обучающих наборов с датой и описанием изменений, а также фиксировать версию набора в журнале обучения.

Мониторинг дрейфа отслеживает расхождение между тем, что модель видела при обучении, и тем, что приходит сейчас. Наблюдают за несколькими вещами одновременно.

• Распределение входных признаков по сравнению с обучающим набором, где рост доли новых значений в справочниках или сдвиг средних величин сигнализирует об изменении процесса.
• Распределение ответов модели, потому что резкое изменение доли одной категории почти всегда означает проблему на входе, а не изменение реальности.
• Доля обращений к варианту прочее и к очереди ручной проверки, рост которой говорит о появлении случаев, не предусмотренных при обучении.
• Фактическая точность на свежих данных, которая считается по выборочной проверке силами сотрудников, обычно от пятидесяти до двухсот случаев в месяц.
• Доля исправлений, внесённых пользователями в ответы системы, что одновременно служит метрикой и источником новой разметки.

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

Персональные данные, доступы и права на использование

Юридическая сторона подготовки данных обычно всплывает позже технической, и это создаёт неприятные ситуации. Команда собрала набор обращений клиентов, обучила модель, показала результат, после чего служба безопасности задаёт вопрос об основании обработки, и проект останавливается. Разбираться с этим правильнее на этапе карты источников, потому что часть данных придётся обрабатывать иначе, а часть вообще исключить, и это меняет оценку выполнимости.

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

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

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

Обезличивание и разграничение доступа

Для большинства задач персональные идентификаторы не нужны. Модель прогноза оттока работает с историей покупок и обращений, а имя и телефон клиента не несут предсказательной силы. Значит их можно убрать до начала работы, и тогда объём юридических согласований сокращается радикально.

Практически обезличивание выполняется несколькими приёмами, которые применяются вместе.

1. Замена прямых идентификаторов на обратимые технические ключи, при которой таблица соответствия хранится отдельно с ограниченным доступом. Модель работает с ключом, а привязка к человеку восстанавливается только на стороне бизнес-системы при выдаче результата.
2. Удаление полей, которые не участвуют в задаче. Это самый надёжный способ, потому что удалённые данные невозможно раскрыть.
3. Обобщение значений, когда точная дата рождения превращается в возрастную группу, а полный адрес в район или город.
4. Поиск и замена персональных сведений внутри текстов. В переписке и расшифровках разговоров телефоны, имена и адреса встречаются в свободной форме, и для их удаления нужен отдельный проход обработки.
5. Проверка на возможность обратного определения личности по совокупности признаков. Набор из города, года рождения, должности и подразделения может однозначно указывать на одного сотрудника даже без имени.

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

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

Требования 152-ФЗ и внутренние политики

Обработка персональных данных в России регулируется законом 152-ФЗ, и для проектов с искусственным интеллектом важны несколько практических следствий. Я не юрист и не даю правовых заключений, поэтому изложу то, что обычно требуется согласовать, а окончательные формулировки следует получить у своего юридического подразделения.

• У обработки должна быть законная цель, зафиксированная в документах. Цель вроде обучение прогнозной модели требует проверки на соответствие тому, что указано в согласии клиента или в договоре с ним.
• Объём данных должен соответствовать цели. Избыточный сбор нарушает принцип минимизации, и это аргумент в пользу обезличивания на входе.
• Передача обработки третьему лицу, включая облачные сервисы и подрядчиков по разметке, оформляется поручением на обработку с указанием состава данных и мер защиты.
• Хранение персональных данных россиян должно вестись на территории Российской Федерации, что прямо влияет на выбор площадки для хранилища и для запуска моделей.
• Для сроков хранения нужен определённый предел, а обучающие наборы с персональными данными не могут лежать бессрочно просто потому, что могут понадобиться.
• Изменения 2025 года усилили ответственность за нарушения в области персональных данных, и штрафы для компаний выросли существенно, поэтому цена небрежности в этом вопросе стала заметно выше, чем несколько лет назад.

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

Чек-лист аудита готовности данных к внедрению ИИ

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

Постановка и смысл

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

Состав и доступность данных

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

Качество

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

Разметка

• Есть достаточное число примеров на каждый вариант ответа, включая редкие.
• Составлена инструкция с примерами и разбором спорных случаев.
• Измерена согласованность двух независимых разметчиков на пилотном наборе.
• Контрольная часть набора отложена до начала экспериментов и не используется в работе.

Эксплуатация и право

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

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

Частые ошибки при подготовке данных

Перечисленные ниже ситуации встречались в моей практике неоднократно, и почти все они обнаруживались уже после того, как в проект вложили время и деньги.

• Сбор данных до постановки задачи. Компания строит хранилище на всё, что есть, и через год выясняется, что для конкретной задачи не хватает одного поля, которое никто не догадался собирать.
• Опора на агрегаты вместо исходных записей. Отчёты удобны для чтения, но в них потеряны разрезы и отдельные события, а восстановить детализацию из суммы невозможно.
• Молчаливое заполнение пропусков средним значением. Пропуск нередко сам по себе информативен, и его замена усреднением уничтожает сигнал.
• Обучение на периоде с другими правилами игры. Данные за время, когда действовала иная система скидок или иной ассортимент, описывают процесс, которого больше нет.
• Признаки, заполняемые после события. Самая коварная ошибка, дающая отличные результаты на истории и нулевые в работе.
• Выборка только по успешным случаям. Если в данные попали лишь одобренные заявки, модель не имеет представления о том, как выглядят отклонённые.
• Разметка одним человеком без проверки согласованности. Личные представления исполнителя становятся эталоном, и модель воспроизводит их, включая систематические перекосы.
• Исключение неудобных случаев из обучающего набора. Нестандартные документы и сложные обращения убирают ради чистоты, а в работе именно они встречаются постоянно.
• Отсутствие регламента обновления. Система месяцами отвечает по устаревшей базе знаний, потому что человек, который обновлял её вручную, перешёл в другой отдел.
• Ручная подготовка данных для пилота, которую невозможно повторить. Набор собран героическими усилиями за две недели, результат впечатляет, а воспроизвести процесс никто не может.
• Перенос ошибок процесса в модель. Если менеджеры годами указывали неверную причину отказа, потому что так быстрее закрывалась форма, модель научится именно этому.

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

Что делать, если данных мало или они разрозненны

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

Синтетика, дообучение готовых моделей, RAG на документах

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

• Дообучение готовой модели на небольшом наборе даёт работающий результат при объёмах, которые раньше считались недостаточными. Сотня-две размеченных примеров на категорию в текстовых задачах нередко достаточны, если примеры подобраны осмысленно, а не случайно.
• Поиск по корпоративным документам с генерацией ответа, известный как RAG, вообще не требует обучающего набора. Нужны актуальные документы, разбиение их на фрагменты и проверочный список вопросов. Это самый быстрый способ получить пользу от языковых моделей при пустой истории решений.
• Расширение набора через преобразования исходных примеров работает, когда данные есть, но их мало. Для текстов это перефразирование, для изображений документов это изменение наклона, яркости и качества, имитирующее реальные сканы.
• Синтетические данные, сгенерированные моделью, применимы для редких категорий и для проверки устойчивости системы. Ограничение существенное, потому что синтетика воспроизводит представления генератора, а не реальность, и доля таких примеров выше двадцати-тридцати процентов начинает ухудшать качество.
• Правила вместо модели остаются недооценённым вариантом. Для редких категорий с небольшим числом примеров набор явных правил работает надёжнее и объясняется проще. Гибридная схема, где правила закрывают редкие случаи, а модель массовые, часто оказывается лучшим решением по совокупности затрат и результата.

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

План сбора данных с нуля

Если нужных данных нет, их начинают накапливать, и это отдельная работа с понятными шагами. Результат появляется через три-девять месяцев, поэтому запускать сбор лучше одновременно с первым пилотом на тех данных, что уже есть.

1. Определить минимальный состав полей, который нужен для будущей задачи. Чем короче список, тем выше шанс, что его будут заполнять.
2. Встроить фиксацию решений в существующий процесс так, чтобы она не добавляла сотруднику заметной работы. Выбор из списка вместо свободного текста, значение по умолчанию, автоматическое заполнение там, где это возможно.
3. Сделать заполнение обязательным для продолжения операции, если поле критично. Добровольное заполнение даёт неслучайные пропуски, с которыми потом нечего делать.
4. Добавить журналирование событий в приложениях и сервисах, даже если сейчас эти логи никому не нужны. Хранение дёшево, восстановление прошлого невозможно.
5. Настроить сохранение результатов работы людей в машиночитаемом виде, включая расшифровки разговоров, итоги согласований и причины решений.
6. Через месяц проверить, что данные действительно накапливаются и выглядят осмысленно. Эта проверка пропускается чаще всего, а обнаруживать сбой сбора через полгода особенно обидно.
7. Поставить контрольную точку на горизонте трёх месяцев для оценки объёма и качества собранного, после чего уточнить сроки по основной задаче.

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

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