Для AI-пилота не нужен идеально очищенный корпоративный архив. Нужна ограниченная, законно доступная и репрезентативная выборка, которая отражает обычные случаи, ошибки и важные исключения. Сначала определите единицу входа и правильный выход, затем соберите данные за подходящий период, удалите лишние поля, проверьте права, устраните технические дубли и зафиксируйте правила разметки. Разделите наборы для настройки и независимой проверки до начала экспериментов. Храните происхождение каждого примера и все преобразования. Качество оценивайте не одной средней точностью, а по критичным полям, классам и цене ошибки. Массовую очистку всего архива стоит планировать только после того, как пилот подтвердит ценность процесса.
Оглавление
- Кому актуальна подготовка
- Что считать данными
- Экономика качества
- Как собрать выборку
- Разметка и эталон
- Готовый сервис или разработка
- План подготовки
- Ошибки
- Чек-лист
- FAQ
Кому актуальна подготовка
Материал нужен бизнес-владельцу, эксперту процесса, аналитикам, ИТ и безопасности. Подготовка данных — совместная задача. ИТ умеет выгрузить записи, но не всегда знает, какой ответ правильный. Эксперт понимает результат, но может не видеть дубли, смещение периода или нарушение разделения выборок. Безопасность определяет допустимый контур и минимизацию.
Данные начинают готовить после того, как определены процесс и KPI. Запрос «выгрузите всё для ИИ» создаёт риск и лишнюю работу. Запрос «нужны входящие спецификации, их подтверждённые строки и причины ручной корректировки за выбранный период» задаёт проверяемую связь.
Что считать данными пилота
Набор состоит не только из исходных файлов. Для каждого примера полезны четыре слоя:
- Вход. Письмо, PDF, таблица, запись разговора, карточка, изображение или набор полей.
- Контекст. Справочник, регламент, права, история и версия правил, которые использовал сотрудник.
- Эталон. Подтверждённая классификация, извлечённые значения, правильный маршрут или принятый черновик.
- Метаданные. Дата, источник, тип, сложность, статус, автор подтверждения и известные ограничения.
Если есть только входы без правильного результата, можно демонстрировать ответы, но нельзя надёжно оценить качество. Если эталон собран из старой системы, проверьте, действительно ли он отражает правильную работу, а не исторические ошибки.
Включайте исключения: плохие сканы, смешанные языки, пустые поля, новые формы, конфликтующие значения, редкие категории. Доля таких примеров в тесте должна позволять увидеть риск, даже если в потоке они встречаются редко.
Экономика качества данных
Не вся очистка одинаково полезна. Приоритизируйте дефекты по влиянию на целевой KPI.
Условный пример:
| Дефект | Частота в выборке | Модельная стоимость одного сбоя | Приоритет | |---|---:|---:|---| | Дубликат документа | 8% | 200 ₽ ручной проверки | средний | | Нечитаемый критичный реквизит | 3% | 4 000 ₽ повторной обработки | высокий | | Разный формат даты | 20% | 40 ₽ нормализации | низкий | | Неверная категория маршрута | 2% | 8 000 ₽ задержки | критичный |
Все числа условны. Для своих данных используйте фактическую частоту и стоимость последствий. Простой приоритет можно оценить как частота × стоимость ошибки × вероятность, что очистка устранит проблему. Иногда редкий дефект важнее массового, потому что связан с критичным действием.
Стоимость подготовки включает часы экспертов, выгрузку, обезличивание, разметку, контроль качества и инфраструктуру хранения. Не надо очищать поля, которые не используются сценарием. Минимизация снижает и бюджет, и риск.
Как собрать выборку
Определить генеральный поток
Опишите, откуда приходят все операции, как меняется объём по времени, какие подразделения и форматы участвуют. Выборка из удобной папки одного сотрудника может не представлять процесс.
Выбрать период
Период должен включать актуальные правила и достаточное разнообразие. Учитывайте сезонность, изменения шаблонов, кампании и переходы между системами. Старые записи полезны для редких случаев, но помечайте их версию.
Стратифицировать
Разделите данные по типам документов, каналам, отделам, сложности, качеству и важным категориям. Возьмите примеры из каждого слоя. Критичные редкие случаи можно намеренно усилить в тесте, а затем скорректировать агрегированную оценку по реальной частоте.
Зафиксировать происхождение
У каждого объекта должен быть стабильный идентификатор, источник, дата выгрузки и цепочка преобразований. Это позволяет найти причину ошибки, обновить набор и удалить данные по требованию.
Разделить наборы
Выделите данные для разработки и отдельный закрытый тест. Не меняйте правила по результатам закрытого теста, иначе оценка станет оптимистичной. Если проводится обучение, нужен дополнительный валидационный набор. Дубликаты и связанные версии одного документа не должны попадать в разные части.
Текстовая схема контура:
Системы-источники
↓ реестр происхождения
минимизация и контроль доступа
↓
очистка технических дефектов
↓
разметка → двойная проверка спорных случаев
↓
development set | закрытый test set
↓ ↓
настройка решения независимая приёмка
Как создать эталон
Сначала напишите инструкцию разметки. В ней должны быть определение каждого поля или класса, допустимые значения, работа с отсутствием данных, примеры и правило эскалации. Инструкция версионируется; изменение правила меняет смысл старых меток.
Разметчики проходят калибровку на небольшой общей выборке. Расхождения обсуждаются не ради согласия любой ценой, а чтобы обнаружить неоднозначность процесса. Если два эксперта системно дают разные ответы, модель не сможет воспроизвести «единственно правильное» правило, пока бизнес его не определит.
Критичные или спорные примеры проверяет второй эксперт. Сохраняйте не только итог, но и причину решения, если она важна для последующей объяснимости. Автоматическую предварительную разметку можно использовать для ускорения, но она должна быть явно отмечена и подтверждена человеком.
Метрики выбирайте по задаче. Для извлечения полей измеряйте каждое критичное поле и точное совпадение документа. Для классификации смотрите ошибки по классам, а не только общую долю. Для генерации черновика фиксируйте принятие, объём правок и критические нарушения. Время проверки является отдельным KPI.
Как способ решения влияет на данные
Готовый сервис может не требовать обучающего набора, но всё равно требует закрытой тестовой выборки. Проверьте условия загрузки, хранение, использование данных поставщиком, удаление и экспорт результатов. Загружайте только необходимые поля.
Интеграционное решение использует корпоративный контекст и обратную связь. Нужны устойчивые идентификаторы, схема обмена, версия справочников и место хранения подтверждений. Важно отделить исходный факт от результата модели.
Собственная разработка увеличивает требования к воспроизводимости: версии наборов, кода, модели, конфигурации, инструкции разметки и метрик. Но «собственный» не отменяет контроль третьих сторон, если используются внешние модели или инфраструктура.
План подготовки
- Назвать единицу входа и выхода. Один документ, обращение или карточка; конкретный правильный результат.
- Назначить владельцев. Бизнес отвечает за смысл, ИТ — за выгрузку, безопасность — за допустимость, проект — за набор.
- Составить паспорт источников. Формат, объём, период, качество, права, способ удаления.
- Минимизировать. Убрать поля и документы, не нужные для KPI.
- Собрать сырую выборку. Сохранить неизменяемую копию и контрольную сумму, если это допускает политика.
- Удалить технические дефекты. Дубли, битые файлы, неверные кодировки; не «исправлять» смысл без эксперта.
- Стратифицировать. Покрыть каналы, типы, сложность и критичные исключения.
- Разметить. По версии инструкции, с контролем спорных случаев.
- Разделить. Исключить утечку дублей между настройкой и тестом.
- Провести профиль качества. Пропуски, классы, перекосы, согласованность и риски.
- Утвердить приёмку. Метрики, пороги, критичные ошибки и ручной маршрут.
- Настроить обновление. Кто добавляет новые случаи и когда пересматривает качество.
Ошибки подготовки
Выгрузить всё. Растут риск, стоимость и число нерелевантных примеров. Нужна минимизация по сценарию.
Очищать весь архив до проверки. Команда тратит месяцы на данные, которые могут не понадобиться. Начните с выборки.
Считать исторический результат эталоном. Система могла хранить компромисс или ошибку. Нужна экспертная проверка.
Тестировать на данных настройки. Решение запоминает особенности набора, оценка становится завышенной.
Удалять сложные случаи. Демо выглядит лучше, но риск переносится в эксплуатацию. Исключения нужно маркировать и измерять.
Не версионировать правила. Новая трактовка смешивается со старой разметкой.
Не хранить источник. Ошибку нельзя расследовать, данные нельзя управляемо удалить.
Измерять только среднее. Высокий общий показатель скрывает провал критичного класса.
Чек-лист данных
- [ ] Единица входа и эталонный выход определены.
- [ ] Бизнес-владелец подтвердил смысл полей.
- [ ] Право обработки и контур согласованы.
- [ ] Лишние данные исключены или обезличены.
- [ ] Источник и дата каждого объекта известны.
- [ ] Выборка отражает подразделения, периоды и форматы.
- [ ] Критичные исключения представлены.
- [ ] Технические дубли удалены до разделения.
- [ ] Инструкция разметки имеет версию.
- [ ] Спорные примеры проходят контроль.
- [ ] Наборы разработки и теста разделены.
- [ ] Метрики считаются по важным классам и полям.
- [ ] Определены хранение, доступ и удаление.
- [ ] Есть процесс добавления обратной связи после пилота.
Связанные материалы
Перед подготовкой определите границу через AI Discovery. Для табличных и товарных данных изучите нормализацию каталогов, а для документов — обработку документов.
FAQ
Нужно ли очищать весь архив?
Нет. Сначала достаточно репрезентативной выборки, позволяющей проверить сценарий и цену дефектов. Массовую очистку планируют после подтверждения эффекта и только для используемой части данных.
Сколько примеров нужно?
Универсального числа нет. Оно зависит от разнообразия, числа классов, редкости критичных случаев и требуемой уверенности. Сначала строят профиль потока, затем определяют объём теста, достаточный для каждого важного слоя.
Можно ли использовать персональные данные?
Только в согласованном правовом и техническом контуре, в минимально необходимом составе и с назначенными правами. Если поле не влияет на задачу, его следует удалить или обезличить. Решение принимает ответственная сторона компании, а не модель.
Что делать, если эксперты расходятся?
Зафиксировать примеры и уточнить бизнес-правило. Согласованность разметки — показатель определённости процесса. Принуждать разметчиков к формальному совпадению без ясного правила опасно.
Следующий шаг
Подготовьте десять–двадцать обезличенных примеров разных типов и опишите правильный результат. Затем закажите разбор процесса, чтобы определить полную выборку, метрики и безопасный контур пилота.