Короткий ответ

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

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

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

Что такое эталонный набор

Это не архив всех доступных данных и не случайная выгрузка из CRM. Эталонный набор — контролируемая выборка, на которой команда принимает решение «готово к следующему этапу».

В зависимости от сценария единицей может быть:

  • обращение клиента с правильной категорией и маршрутом;
  • вопрос к RAG с обязательным источником и допустимым отказом;
  • счёт с эталонными полями и арифметической проверкой;
  • звонок с правильной расшифровкой и итогом;
  • изображение с типом дефекта и областью на кадре;
  • действие агента с ожидаемым подтверждением или запретом.

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

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

Из чего складывается бюджет

Полная стоимость состоит минимум из семи частей.

1. **Проектирование правил.** Владелец процесса и аналитик формулируют классы, допустимые решения, примеры и порядок эскалации.
2. **Подготовка данных.** Команда выгружает записи, удаляет дубли, маскирует персональные данные, связывает вложения и фиксирует версии.
3. **Первая разметка.** Сотрудник применяет инструкцию ко всему набору.
4. **Перекрытие.** Второй человек независимо размечает часть примеров. Если он видит первый ответ, это проверка, а не независимая оценка.
5. **Разрешение разногласий.** Эксперт решает спорные случаи и одновременно исправляет инструкцию.
6. **Контроль набора.** Проверяются полнота классов, утечки между обучением и тестом, распределение по подразделениям и свежесть документов.
7. **Эксплуатация.** Набор версионируют, дополняют новыми ошибками и заново применяют к каждой значимой версии модели или процесса.

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

Зачем нужно согласие разметчиков

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

Документация Label Studio описывает overlap — повторную разметку одной задачи несколькими участниками — и метрики межэкспертного согласия. Низкое согласие может означать три разные проблемы:

  • инструкция допускает несколько трактовок;
  • людям не хватает контекста;
  • сам бизнес-процесс не имеет единого правильного решения.

В третьем случае нельзя лечить ситуацию новой моделью. Сначала руководитель процесса должен определить правило либо разрешить несколько допустимых ответов.

Выбор метрики зависит от задачи. Для простой классификации можно смотреть совпадение и матрицу ошибок. Для прямоугольников на изображении применим IoU, для расшифровки — расстояние редактирования, для извлечения сущностей — precision, recall и F1. Один общий процент согласия скроет различия между типами ошибок.

Полное двойное аннотирование всего массива редко нужно на старте. Разумнее удвоить:

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

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

Модельный расчёт для 1 000 примеров

Ниже не рыночная смета, а пример с явными допущениями. Пусть компания готовит 1 000 документов для проверки извлечения полей.

Допущения:

  • первая разметка занимает в среднем 2 минуты на документ;
  • 20% документов независимо размечает второй сотрудник, также по 2 минуты;
  • 10% документов требуют экспертного разбора по 4 минуты;
  • полная стоимость часа разметчика — 900 рублей;
  • полная стоимость часа эксперта — 1 800 рублей;
  • подготовка инструкции, выборки и контроля занимает 16 часов эксперта;
  • лицензии, инфраструктура и интеграция считаются отдельно.

Получается:

  • первая разметка: 1 000 × 2 минуты = 33,3 часа, или около 30 000 рублей;
  • перекрытие: 200 × 2 минуты = 6,7 часа, или около 6 000 рублей;
  • разбор: 100 × 4 минуты = 6,7 часа эксперта, или около 12 000 рублей;
  • инструкция и контроль: 16 часов эксперта, или 28 800 рублей.

Итого — около 76 800 рублей до стоимости инструмента, выгрузки, обезличивания и управления проектом.

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

Формула для своей таблицы:

**Бюджет = N × t₁ × C₁ + N × r × t₂ × C₂ + N × q × tₐ × Cₐ + подготовка + инструменты**, где время переводится в часы, `r` — доля независимого перекрытия, `q` — доля экспертного разбора.

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

Как не купить ложную экономию

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

Сравнивать подрядчиков или внутренние команды лучше по стоимости **принятого** примера после контроля. Для пилотной партии измеряют:

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

Важно отделить квалификацию. Специалисту предметной области не обязательно размечать все простые случаи. Он проектирует правила, готовит примеры, разбирает спорное и проверяет критический класс. Рутинную часть выполняет обученный разметчик или сотрудник процесса с более низкой полной стоимостью часа.

Локальный инструмент разметки уместен, когда в примерах есть договоры, обращения клиентов, производственные изображения или другие чувствительные данные. Но self-hosting не бесплатен: нужны учётные записи, резервные копии, аудит выгрузок, обновления и разделение проектов. Иногда обезличенная выборка в управляемом сервисе дешевле собственного контура; решение зависит от режима данных, а не от моды на локальность.

Как собрать набор за четыре недели

Первая неделя — выбрать один процесс, определить цену ключевых ошибок и написать инструкцию на 20–30 реальных примерах. Вторая — дать пилотную сотню двум людям независимо и разобрать расхождения. Третья — исправить правила, разметить основной массив и направлять спорное эксперту. Четвёртая — заморозить версию, проверить распределение и впервые сравнить модели.

До старта зафиксируйте критерии приёмки:

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

Эталонный набор не должен превращаться в музей. После запуска в него добавляют подтверждённые ошибки, новые форматы и изменившиеся правила, но не переписывают прошлую версию задним числом. Так команда видит, улучшилась ли модель или просто изменился экзамен.

Управленческий вывод

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

Для первого решения достаточно 500–1 000 хорошо отобранных примеров, если они отражают реальные категории и дорогие ошибки. Это не универсальный норматив, а рабочий диапазон для оценки пилота; нужный объём определяется разнообразием процесса и требуемой уверенностью.

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