Данные — это то, что ограничивает проект, а не модель

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

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

Третий блок — целевая переменная. Модель учится на том, что произошло в прошлом, поэтому нужно, чтобы результат операции где-то фиксировался. Часто выясняется, что фиксируется только положительный результат: успешные сделки есть, а отказы нет; подтверждённые дефекты есть, а пропущенные нет. Это искажает обучение и требует дополнительной работы с данными.

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

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

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

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

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

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

Третий аспект — сроки хранения и доступ. Данные, собранные для проекта, не должны храниться бессрочно «на всякий случай»; нужен регламент удаления. Доступ к ним ограничивается ролями, а действия фиксируются в журнале. Эти требования кажутся бюрократическими, но именно они позволяют проекту пройти внутренний аудит без переделок на финальной стадии.