«У нас мало данных» — самая частая причина, по которой компании откладывают ИИ-проект. Обычно она основана на представлении, что моделям нужны миллионы примеров. Для обучения с нуля это верно, но с нуля сегодня почти никто не учит. Разберём реальные ориентиры по типам задач и что делать, если данных действительно не хватает.
Почему требования снизились
Современный подход — не обучение с нуля, а дообучение предобученной модели. Модель уже понимает изображения или язык в целом; ваши данные нужны, чтобы объяснить ей специфику задачи. Это меняет требуемый объём на порядки.
Аналогия простая: научить человека, который умеет читать, разбираться в ваших документах — это дни. Научить читать с нуля — годы. Предобученная модель находится в положении первого.
Ориентиры по типам задач
Классификация изображений и поиск дефектов
Обычно достаточно нескольких сотен размеченных примеров на класс. Для простых, визуально очевидных дефектов может хватить и меньше; для тонких различий, которые и человек различает не сразу, потребуется больше. Наш проект контроля брака на конвейере построен именно в этой логике — точность 92% достигнута дообучением, а не обучением с нуля.
Извлечение полей из документов
От нескольких сотен документов на тип. Важнее объёма разнообразие: пятьсот документов от одного контрагента дадут хуже, чем двести от двадцати разных. В проекте по оценке дипломов мы работали с документами сорока стран — именно разнообразие обучающей выборки позволило системе не ломаться на новых формах.
Классификация текста
От сотни примеров на класс при использовании предобученных языковых моделей. Часть задач вообще решается без обучения — инструкцией с несколькими примерами прямо в запросе. Проверять надо именно этот вариант первым.
Прогноз временных рядов
Здесь считаются не примеры, а периоды. Для сезонных процессов нужно минимум два полных года, иначе модель не увидит годовой цикл. Год пригоден, но качество будет заметно ниже, и это надо закладывать в ожидания, а не обнаруживать после.
Поиск по документам
Обучающая выборка не нужна вовсе: документы индексируются как есть. Нужен другой набор — проверочный, из 50–100 реальных вопросов с эталонными ответами. Он не для обучения, а для измерения качества, и без него проект остаётся неизмеримым.
Качество разметки важнее количества
Тысяча примеров, размеченных внимательно и по единым правилам, даёт лучший результат, чем десять тысяч, размеченных небрежно. Противоречивая разметка не просто бесполезна — она активно мешает: модель учится противоречию и становится неуверенной там, где могла бы быть точной.
Практическая проверка перед разметкой: дайте двум специалистам одинаковые сто примеров и сравните результаты. Если они расходятся в четверти случаев, проблема не в данных, а в определении задачи — и никакой объём разметки этого не исправит. Сначала договоритесь о правилах, потом размечайте.
Отдельно про редкие классы. В задачах контроля качества дефектов мало — это хорошо для производства и плохо для обучения. Здесь работает не наращивание общей выборки, а целенаправленный сбор редких случаев и обучение на отклонении от нормы вместо классификации.
Что делать, если данных не хватает
- Аугментация: из одного изображения получаются десятки вариантов поворотом, изменением освещения, шумом. Для изображений это стандартная и эффективная практика.
- Синтетика: генерация примеров программно. Хорошо работает для документов с известной структурой, хуже — для естественных сцен, где синтетика заметно отличается от реальности.
- Перенос с похожей задачи: модель, обученная на смежных данных, дообучается на вашей малой выборке. Часто даёт больше, чем сбор дополнительных примеров.
- Активное обучение: размечать не всё подряд, а то, в чём модель наименее уверена. Это сокращает объём разметки в разы при том же результате.
- Сузить задачу: вместо двадцати типов дефектов взять три самых дорогих. Данных хватит, эффект будет измерим, а расширение пойдёт после.
Данные, которые у вас уже есть
Компании часто не замечают, что часть разметки уже существует. Отклонённые заявки — это размеченные примеры. Исправления, внесённые операторами в распознанные документы, — тоже. История решений в учётной системе, теги в тикетах, результаты выборочного контроля качества.
Первый шаг диагностики у нас обычно именно такой: не «соберите данные», а «покажите, что уже накоплено». Довольно часто выясняется, что данных достаточно, просто они лежат в трёх разных системах и никем не рассматривались как обучающая выборка.
Как понять, что данных хватило
Ответ даёт не расчёт, а измерение. Обучите модель на половине доступных данных, потом на всех и сравните качество на отложенной выборке. Если прирост от удвоения объёма заметный — данных мало, сбор окупится. Если прирост в пределах погрешности — дело не в количестве, и добавлять примеры бессмысленно: узкое место в другом.
Эта проверка занимает часы и делается на прототипе. Она избавляет от двух дорогих ошибок: месяцев разметки там, где она не нужна, и запуска проекта на заведомо недостаточных данных.
Как организовать разметку
Разметка — самая недооценённая часть ИИ-проекта. Её объём предсказуем, а вот качество зависит от организации, и здесь легко потерять недели.
Сначала инструкция, потом разметка
Письменная инструкция с примерами и разбором пограничных случаев обязательна. Разметка «по здравому смыслу» силами нескольких человек даёт противоречивый результат, на котором модель учится плохо. Инструкция пишется, проверяется на небольшой выборке двумя людьми независимо, и дорабатывается по расхождениям.
Размечать должны те, кто понимает предмет
Дефекты на детали, юридические формулировки, медицинские записи — это работа специалиста, а не подрядчика на аутсорсе. Их время дороже, но неправильная разметка обесценивает весь проект, и экономия здесь ложная.
Двойная разметка на спорном
Не всё подряд, а выборочно: часть примеров размечают два человека независимо. Расхождения показывают, где инструкция неоднозначна, и одновременно дают оценку того, насколько вообще достижима высокая точность. Если люди расходятся в 15% случаев, ожидать от модели 98% бессмысленно.
Размечать порциями и проверять на модели
Не стоит размечать всё, а потом обучать. Разумнее: разметить небольшую часть, обучить, посмотреть на прирост, продолжить. Часто выясняется, что данных уже достаточно, — и оставшиеся недели разметки не нужны.
Сколько это стоит по времени
Точные цифры зависят от задачи, но порядок оценить можно и нужно — до начала, а не в процессе.
Возьмите десять типичных примеров и засеките, сколько занимает разметка одного специалистом. Умножьте на нужный объём, прибавьте треть на организацию, обсуждение спорных случаев и исправления. Получится честная оценка в человеко-часах, которую можно поставить в план и согласовать с руководителем этих людей.
Отдельно предупредим: у разметки есть свойство останавливаться. Специалисты заняты основной работой, и разметка уходит в фон. Поэтому её надо ставить как задачу с сроком и ответственным, а не как просьбу «когда будет время». Половина сорванных сроков в ИИ-проектах приходится именно на это.
Данные, которые нельзя использовать
Не всё, что есть, годится для обучения, и лучше выяснить это до, а не после.
- Персональные данные без подходящего основания. Обучение модели обычно не покрывается согласием, полученным под учётные цели, — нужно либо обезличивание, либо пересмотр оснований.
- Данные, полученные от контрагентов с ограничением на использование. Договор может прямо запрещать применение для обучения.
- Данные, сформированные предыдущей версией модели, если это не учтено. Модель, обучающаяся на собственных выводах, закрепляет свои ошибки.
- Данные из периода, когда процесс работал иначе. Формально это история, фактически — другая реальность, и модель выучит устаревшие закономерности.
Последний пункт — самый коварный, потому что технически с данными всё в порядке. Полезная привычка: перед обучением спросить у владельца процесса, что менялось за период выборки. Ответ «два года назад сменили поставщика» или «в прошлом году поменяли регламент» экономит недели непонимания, почему модель ведёт себя странно.
Признаки, что дело не в количестве данных
Иногда добавление примеров не помогает, и продолжать разметку бессмысленно. Несколько признаков, по которым это видно.
- Удвоение выборки дало прирост в пределах погрешности. Узкое место в другом месте.
- Модель ошибается на тех же примерах, на которых расходятся ваши специалисты. Это предел задачи, а не модели.
- Ошибки сосредоточены в одном классе или типе входа. Нужны не данные вообще, а данные конкретно этого вида.
- Качество на обучающей выборке отличное, а на отложенной плохое. Это переобучение — лечится не объёмом, а изменением подхода.
Что делать, пока данных нет
Частая ситуация: задача понятна, а данных для обучения не накоплено, потому что процесс никогда не оцифровывался. Ждать год, пока накопится, — не единственный вариант.
Первое, что стоит сделать, — начать собирать данные правильно прямо сейчас, даже без проекта. Если контролёр отбраковывает деталь, пусть снимок и решение сохраняются. Если оператор исправляет распознанное поле, пусть исправление логируется. Через несколько месяцев у вас будет размеченная выборка, полученная бесплатно как побочный продукт работы.
Второе: проверить, решается ли задача без обучения вовсе. Значительная часть текстовых задач закрывается языковой моделью с хорошей инструкцией и парой примеров — без единого размеченного примера. Это не всегда даёт лучшее качество, но даёт работающее решение сегодня и заодно набирает данные для будущего обучения.
Третье: сузить постановку до того объёма, который данные позволяют. Вместо двадцати типов дефектов — три самых дорогих. Вместо всех документов — один самый массовый тип. Узкая задача с достаточными данными даёт измеримый результат, а широкая с недостаточными не даёт ничего.
И общий принцип: сбор данных — это инфраструктурная работа, которая окупается независимо от конкретного проекта. Компания, у которой процессы логируются, может запустить ИИ-проект за недели. Компания, у которой их нет, начинает с полугода накопления, и никакая технология этот срок не сокращает.
Качество данных: на что смотреть перед стартом
Объём — не единственный и не главный параметр. Перед началом проекта данные стоит оценить по нескольким признакам, и делается это за день-два.
- Полнота: какая доля записей содержит нужные поля заполненными. Массовые пропуски в ключевом признаке обесценивают выборку сильнее, чем её малый размер.
- Согласованность: одна и та же сущность записана одинаково или в десяти вариантах написания. Разнобой в справочниках приходится приводить в порядок, и это отдельная работа.
- Актуальность: за какой период данные и что менялось в процессе за это время. Данные из другой эпохи процесса учат модель неверным закономерностям.
- Сбалансированность: как распределены классы. Редкие случаи требуют особого подхода, и знать об этом надо до, а не после обучения.
- Наличие правильных ответов: есть ли вообще разметка или её предстоит делать. От этого зависит половина сроков проекта.
Практический приём: попросите выгрузку и посмотрите на неё до того, как обсуждать архитектуру. Пять минут в таблице дают больше понимания о реалистичности проекта, чем час обсуждения технологий. И довольно часто выясняется, что первым этапом должен быть не ИИ, а наведение порядка в данных, — это честный вывод, и лучше сделать его в начале.
Коротко
- Современные модели дообучаются, а не учатся с нуля, — требования к объёму на порядки ниже привычных.
- Ориентиры: сотни примеров на класс для изображений и документов, сотня для текстовой классификации, два года истории для сезонного прогноза.
- Согласованность разметки важнее её объёма; расхождение между разметчиками — признак нечётко поставленной задачи.
- При нехватке данных работают аугментация, синтетика, перенос с похожей задачи, активное обучение и сужение задачи.
- Проверить достаточность можно за часы: сравнить качество на половине данных и на всех.