Как подготовить данные для ИИ-пилота: что проверить за неделю до старта

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

В статье нет универсальных порогов вроде «нужно не меньше N документов»: размер зависит от задачи. Есть порядок проверки, чек-листы для трёх типовых задач (поиск по документам, извлечение данных из документов, прогноз по таблицам), таблица «симптом — что значит — что делать» и план по дням. Если вы ещё выбираете, что автоматизировать, начните со статьи с чего начать цифровизацию.

Что нужно знать о своих данных до пилота

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

1. Источники и владельцы. Где лежат данные и кто может разрешить с ними работать.
2. Права и ограничения. Есть ли персональные данные, коммерческая тайна, документы ограниченного доступа, что говорит служба безопасности.
3. Формат. Сканы или текст, Excel с объединёнными ячейками, выгрузки из 1С, письма, чаты.
4. Качество. Дубли, пропуски, разные названия одного и того же, устаревшие версии.
5. Объём и репрезентативность. Сколько данных и похожи ли они на реальный поток, включая плохие случаи.
6. Эталон. Кто и как разметит правильные ответы, по каким правилам.
7. База для сравнения. Как задача решается сейчас и по какому показателю поймём, что стало лучше.

Седьмой пункт часто забывают, а без него пилот нечем принять. Как считать выгоду, разобрано в материале про ROI от ИИ, а почему пилоты остаются в демо, — в разборе почему ИИ-пилоты не доходят до продуктива.

Где лежат данные и кто за них отвечает

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

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

Доступ и права: персональные данные и ограниченный доступ

Доступ — самая частая причина потерянных недель, и решается он не техникой, а согласованием. До пилота ответьте письменно:

• есть ли в данных персональные данные (ФИО, телефоны, паспортные и платёжные реквизиты, данные сотрудников) и что требует закон о персональных данных (152-ФЗ) для вашей обработки;
• есть ли коммерческая тайна и документы с ограничением доступа, и можно ли их показывать подрядчику, пусть даже на вашем оборудовании;
• можно ли выгрузить данные в тестовый контур или работать только внутри боевой системы;
• можно ли обезличить данные для пилота: заменить имена и реквизиты, сохранив структуру;
• кто в вашей организации подписывает допуск и сколько это занимает по времени.

Для поиска и ответов по документам есть ещё одна тема: права внутри данных. Сотрудник не должен получить через ассистента то, что ему нельзя открыть напрямую. Значит, нужно заранее выяснить, как права устроены в источнике (по папкам, по группам, по подразделениям) и можно ли их читать программно. Как это решается в поиске по документам, описано в материале про RAG. Если контур закрытый, работаем внутри него: доступ к системам и обследование согласуем на старте с вашей службой безопасности.

Формат и качество: дубли, пропуски, разные названия одного и того же

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

• Дубли. Одна и та же запись или документ несколько раз, иногда с небольшими отличиями. Для поиска дубли дают конфликтующие ответы, для прогноза искажают частоты.
• Пропуски. Пустые поля. Важно понять причину: поле не заполняют, не выгружают или оно не применимо к этой записи.
• Разные названия одного. Контрагент записан тремя способами, номенклатура по-разному в разных системах. Это вопрос нормативно-справочной информации, подробнее в материале про НСИ при внедрении ERP.
• Устаревшие версии. В папке лежат «положение_финал», «положение_финал2» и приказ о его отмене. Поиск без статуса вернёт любой из них.
• Технический формат. PDF без текстового слоя, Excel с объединёнными ячейками и многострочными заголовками, кодировки, названия столбцов в разных регистрах.
• Смешанные единицы и смысл. Килограммы и тонны в одном столбце, нуль вместо «нет данных», смена методики учёта посреди периода.

Для таблиц хватит Excel или pandas: число различных значений в справочных полях, доля пропусков по столбцам, диапазоны значений, даты вне допустимого периода. Для документов — ручной просмотр выборки и проверка, выделяется ли текст в PDF мышью. Если нет, нужен OCR, и качество сканов становится отдельным вопросом: подходы разобраны в статье OCR или LLM для распознавания документов.

Объём и репрезентативность: хватит ли данных

Вопрос «сколько нужно данных» не имеет общего ответа. Полезнее два других: хватает ли примеров каждого вида и похожи ли данные на реальный поток.

• Покрытие видов. Для извлечения из документов — все основные типы и поставщики, а не только самые частые. Для поиска — все основные темы, по которым люди задают вопросы. Для прогноза — все режимы и сезоны.
• Редкие события. Для прогноза редкого события (отказ, отток, дефект) важно число самих событий, а не число строк. Миллион строк с тремя отказами — это три примера отказа.
• Период. Если в бизнесе есть сезонность, данные должны покрывать несколько полных циклов. Иначе модель выучит одну весну и не узнает осень.
• Похожесть на реальность. Выборка из «чистых» документов, собранная для пилота, даёт хороший результат, а на потоке с мятыми сканами и фото с телефона даёт плохой. Берите документы так, как они приходят.
• Смещение. Если в выборку попали только случаи, которые кто-то уже разбирал вручную, она смещена: в ней обычно избыток сложных случаев или, наоборот, одни лёгкие. Выясните, как выборка собиралась.

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

Эталонная выборка: кто и как размечает правильные ответы

Эталон — это набор примеров, где правильный ответ известен: документы с вручную заполненными полями, вопросы с указанием документа, в котором есть ответ, строки с известным исходом. Без него нельзя ни настроить, ни принять пилот: результат придётся оценивать «на глаз».

Четыре решения принимаются до старта.

1. Кто размечает. Человек, который знает предметную область: бухгалтер, механик, юрист, оператор склада. Не ИТ-специалист и не подрядчик, которому придётся угадывать смысл.
2. По каким правилам. Письменная инструкция: что считать значением поля, как поступать с неразборчивым, что делать, если ответа в документе нет. Без инструкции два эксперта разметят по-разному.
3. Сколько времени это займёт. Разметка — работа людей, и её стоимость считается просто: число примеров × время на пример × ставка специалиста. Закладывайте её в бюджет пилота, а не надеетесь, что «разметим по ходу».
4. Как разделим. Часть эталона идёт на настройку, часть остаётся контрольной и не используется до приёмки. Если проверять на тех же примерах, на которых настраивали, результат будет завышен.

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

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

Данных мало или данные плохие: как отличить

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

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

Главное, что даёт этот эксперимент: он превращает спор «модель плохая» или «данные плохие» в измерение. И он же подсказывает, не пора ли остановиться: критерии описаны в материале когда останавливать ИИ-пилот.

Чек-листы для трёх типовых задач

Поиск и ответы по документам

• Список всех источников: файловые папки, wiki, система документооборота, почта, 1С.
• Форматы: у PDF есть текстовый слой или это сканы; что внутри Word и Excel; есть ли важное в таблицах и схемах.
• Актуальность: у документа есть версия, дата и статус; понятно, как отличить действующий от отменённого.
• Права: как устроен доступ и можно ли получить его программно, чтобы поиск показывал только разрешённое.
• Дубли и копии: одинаковые документы в разных папках, версии «финал».
• Терминология: сокращения, внутренние названия, синонимы.
• Набор реальных вопросов сотрудников с правильными ответами и указанием документа-источника: это и есть эталон.
• Владелец базы знаний: кто её обновляет и отвечает за актуальность после пилота.

Извлечение данных из документов

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

Прогноз по табличным данным

• Что именно предсказываем, на какой горизонт и что будет делать человек, получив прогноз. Если действия нет, пилот не нужен.
• История за период, покрывающий несколько циклов сезонности.
• Число событий (отказов, оттоков, срывов), а не только число строк.
• Метки времени: когда на самом деле произошло событие и когда его записали. Часто это разные даты.
• Только те признаки, которые известны на момент прогноза. Признак, появляющийся уже после события, даёт красивый результат на истории и не работает в жизни (утечка данных).
• Смены системы учёта, кодов и методики: на границе таких смен данные несопоставимы.
• База для сравнения: простое правило или «как в прошлом периоде». Если модель не лучше него, пилот провален независимо от красоты метрик.

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

Симптом, значение, действие: таблица диагностики данных

Если во время проверки вы видите что-то из левого столбца, вот что это обычно значит.

Что можно проверить за неделю без подрядчика

Рабочий план на пять дней. На каждом шаге — конкретный результат, а не «изучить данные».

1. День 1. Источники и владельцы. Заполните карточки источников, назначьте ответственных, соберите «теневые» источники. Результат: таблица с владельцами.
2. День 2. Права и безопасность. Отправьте запрос в службу безопасности, выясните, какие данные нельзя выносить и можно ли обезличить. Результат: письменное решение или список открытых вопросов.
3. День 3. Выборка и профилирование. Достаньте выборку, проверьте дубли, пропуски, форматы, названия, версии. Результат: список дефектов с примерами.
4. День 4. Эталон. Составьте письменную инструкцию разметки, соберите тридцать-пятьдесят вопросов или примеров (ориентир для старта) и разметьте их с предметным специалистом. Результат: первый эталон и список спорных случаев.
5. День 5. Паспорт данных. Одна страница: что есть, чего не хватает, что мешает, что можно решить до старта, с какой задачи начать. Результат: решение «идём в пилот», «сначала чистим данные» или «сначала собираем историю».

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

Что делаем мы и с чего начать

Если проверку данных хочется провести вместе с внешним специалистом, это входит в наше обследование: смотрим источники, форматы и качество, оцениваем эталон, говорим, на какой задаче пилот возможен. Обследование — 200 000 ₽ при одном-двух процессах (2–3 недели) и 350 000 ₽ при нескольких системах (3–4 недели); оно вычитается из следующего этапа. Для производства и оборудования — 500 000 ₽ и 4–6 недель. Дальнейшие ступени — пилот и вывод в продуктив — описаны на странице тарифов.

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