Сбор и разметка данных для машинного обучения

Стоимость разметки данных зависит от типа данных, сложности ТЗ, объема проекта и требований к квалификации разметчиков и контролю качества.

Обычно мы рассчитываем цену по прозрачной процедуре через пилот: измеряем фактическое время работы специалистов и переводим его в стоимость одной единицы разметки.

Для большинства проектов мы организуем работу в три этапа:

1. Изучаем ТЗ и тестовые сэмплы, чтобы дать предварительную экспертную оценку: понять примерную вилку бюджета, сроки и сверить их с ожиданиями заказчика.

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

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

3. С учетом финализированных и согласованных параметров подписываем договор и запускаем основной датасет в работу.

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

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

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

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

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

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

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

Формат результата зависит от задачи и инструмента разметки. Обычно передаем данные в таблицах, JSON, CSV, COCO, YOLO, XML или в формате платформы клиента. Для пилота заранее согласуем структуру полей, названия классов, правила экспорта и пример итогового файла.

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

Качество разметки мы контролируем на нескольких уровнях: сначала уточняем ТЗ и примеры правильной разметки на пилоте, затем обучаем команду на этих примерах и дальше проверяем результат в процессе работы.

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

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

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

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

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

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

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

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

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

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