Подбор персонала для ручной проверки в операциях с ИИ без догадок

Почему подсчёт токенов даёт неверный ответ

Объём токенов выглядит простым для измерения, поэтому команды берутся за него в первую очередь. Но это упрощение обычно ломает планы по штату.

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

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

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

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

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

• Сколько задач вообще доходит до человека?
• Сколько требует более одного ревью?
• Сколько уходит в другую команду?
• Насколько быстро нужно действовать?

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

Что создаёт работу для ревью

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

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

Для каждого типа задач отслеживайте пять показателей:

• сколько элементов приходит в обычный день или неделю
• как часто ИИ отправляет их человеку
• как часто ревьюеры возвращают их до доработки
• как часто подключается менеджер или специалист
• как быстро команда должна их закончить

Третий пункт важнее, чем многие ожидают. Первичное ревью и доработка — это разные нагрузки. Если пришло 100 элементов, 20 нуждаются в ревью, и 8 из них вернулись после правок, ревьюеров не 20 касаний — а 28. Добавьте ещё слой, если некоторые из этих 8 затем переходят в юротдел, безопасность или к старшему оператору.

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

Крайние сроки также формируют размер очереди. Две команды могут обрабатывать одинаковый суточный объём и при этом требовать очень разного штата. Если у одной команды 24 часа на завершение ревью, работу можно растянуть. Если команда обещает ответ за 15 минут, пики важнее.

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

Картируйте поток прежде чем оценивать штат

Большинство ошибок штатирования происходят ещё до математики. Команды бросаются к объёму модели, среднему времени обработки или подсчёту токенов и пропускают то, что реально создаёт работу: путь задачи после попадания в систему.

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

Нарисуйте полный путь на одной странице. Держите его простым. Достаточно коробок и стрелок.

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

Хорошая карта обычно отмечает по пять пунктов на каждой ветке:

• какое событие отправляет задачу туда
• кто её ревьюит
• сколько обычно занимает это ревью
• что завершает путь
• куда уходит задача дальше, если ревьюер отклоняет её

Метка ревьюера важнее, чем кажется. Общий ревьюер, аналитик по мошенничеству и тим‑лид не добавляют ёмкость одинаково. Если только один человек может решать исключения, эта ветка становится лимитирующей даже когда основная очередь выглядит в порядке.

Пропишите правило остановки для каждой ветки. Не оставляйте ветви открытыми с расплывчатыми окончаниями вроде «отправить на ещё одну проверку». Скажите точно, когда задача закрывается, когда возвращается к модели и когда уходит к старшему ревьюеру. Чёткие правила сокращают скрытые повторы.

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

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

Как по шагам оценить размер очереди

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

1. Замерьте суточный объём для каждого типа задач. Разделяйте типы, если у них разные времена обработки или уровни риска.
2. Умножьте каждый тип на его частоту ревью. Если пришло 1000 задач и 12% нуждаются в ревью, это даёт 120 первичных проверок.
3. Добавьте повторные проверки после провалов. Если 20% из этих 120 не проходят и каждая возвращается один раз — добавьте ещё 24 проверки.
4. Добавьте эскалации как отдельные элементы очереди. Если 10% проверенных задач уходят к старшему ревьюеру, это дополнительная работа, а не часть первичного ревью.
5. Сравните почасовые приходы с временем обработки. Суточные итоги могут выглядеть безопасно, даже когда один загруженный час переполняет команду.

Простая формула: элементы очереди в день = первичные проверки + повторные проверки + эскалации.

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

Почасовая проверка обычно меняет план. Допустим, вы ожидаете 180 ревью‑элементов в день со средним временем 6 минут. Это 1080 минут работы, или 18 человеко‑часов. На бумаге три ревьюера покрывают это в стандартный день. Но если половина элементов приходит между 10:00 и 13:00, очередь всё равно пикует, если в это окно нет достаточного количества людей.

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

Используйте реальные числа за одну‑две недели, затем пересчитайте. Большинство команд сначала пропускают повторные проверки и эскалации. Эти две строки часто объясняют, почему очередь кажется гораздо больше, чем первый прогноз.

Превращаем размер очереди в покрытие смен

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

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

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

Используйте реальные продуктивные часы

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

Практическая проверка покрытия выглядит так:

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

Скажем, модель очереди предсказывает 240 проверок в день. Если 75% занимают по 3 минуты и 25% по 12 минут, сырой объём работы — 540 минут плюс 720 минут, итого 1260 минут. Добавьте 20% накладных — получаем 1512 минут.

Если один ревьюер даёт примерно 6,5 продуктивных часов за смену, это 390 минут. Разделите 1512 на 390 и получится 3,9 — нужно четыре человека, чтобы покрыть ожидаемый день.

Планируйте под пики, а не под среднее

Среднее скрывает дни, которые ломают команду. Если по понедельникам объём на 30% выше, планируйте под понедельник, а не под недельное среднее. Если срочные эскалации должны решаться за 15 минут, держите небольшой буфер вместо того, чтобы грузить каждого ревьюера по максимуму.

Этот буфер не должен быть большим. Один ревьюер‑резерв по ротации, общий ревьюер между двумя очередями или тим‑лид с 60–90 свободными минутами могут быть достаточными. Оставляйте место для неожиданной работы — она всегда появляется.

Простой пример из службы поддержки

Возьмём команду поддержки с 1000 обращений в день. ИИ пишет большинство первых ответов, но люди всё равно проверяют часть потока. Объём токенов здесь почти ничего не говорит. Нагрузка на ревью возникает от того, какие задачи доходят до человека, как часто они не проходят и куда идут дальше.

Предположим такой состав:

• 700 стандартных чатов. Команда случайно проверяет 10% из них, каждая такая проверка занимает около 2 минут.
• 220 запросов на возврат. Из‑за денег 60% идут на ревью, и каждое занимает около 6 минут.
• 80 случаев вызывают сигнал по мошенничеству. Каждый идёт к старшему ревьюеру примерно на 8 минут.

Это даёт 70 точечных чеков, 132 ревью возвратов и 80 старших ревью в день. Во времени это 140 минут на чаты, 792 минуты на возвраты и 640 минут на старшую очередь. До разговоров о штатировании команде уже нужно 1572 минуты ревью, или чуть больше 26 человеко‑часов.

Добавим провалы и эскалации. Если 12% ревью возвратов проваливаются с первого раза, около 16 кейсов отскакивают. Каждое такое дело часто даёт два дополнительных касания: один ревьюер проверяет исправленный ответ, затем старший подтверждает финальное действие, если случай всё ещё рискованный. Если эти дополнительные касания занимают 4 и 5 минут, команда добавляет ещё около 144 минут. Один плохой первый проход редко остаётся одной задачей.

План смены должен отталкиваться от самого загруженного часа, а не от дневного среднего. Если 15% дневной работы по ревью приходится на 10:00–11:00, этот час приносит порядка 236 базовых минут ревью. Добавьте примерно 22 минуты на перепроверки и старшие доработки — и команде нужно около 258 ревью‑минут в рамках 60 минут.

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

Ошибки, искажающие планы штатирования

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

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

Доработки — ещё один распространённый провал. Провал ревью редко равен одной лишней минуте. Кто‑то отправляет задачу назад, модель или оператор правят её, и ревьюер снова проверяет. Если небольшая доля задач падает дважды, очередь может разрастись даже при стабильном приходе новых задач.

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

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

Эти минуты быстро складываются. В бережливой AI‑операции стоимость передачи может быть не менее значима, чем само ревью.

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

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

Быстрая проверка перед изменением команды

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

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

Пара проверок ловит большинство ошибок планирования:

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

Повторы заслуживают особого внимания, потому что они скрыты на виду. Если черновик от ИИ провалился, был исправлен и вернулся — это создаёт больше работы, чем простое одобрение. Команды часто считают это одной задачей, потому что она пришла от одного запроса. Считайте каждое ревью‑касание отдельно и помечайте, какие из них были доработками.

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

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

Что делать дальше с вашими данными

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

Вытяните количество созданных задач, долю отправленных на ревью, долю провалившихся и вернувшихся, а также пути, вызвавшие эскалацию. Разбейте эти данные по часам и дням. Команда, выглядящая нормально по суточному среднему, может тонуть между 10:00 и 13:00.

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

Базовый эскиз должен показывать:

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

Эта картина важна, потому что очереди растут в петлях, а не по прямым линиям. Если 8% задач провалились один раз и 2% эскалировали дважды, ваша модель штатирования должна учитывать эти дополнительные касания.

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

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

Один простой, но эффективный фикс: затянуть первое решение. Отправляйте на ревью только неуверенные или высоко‑влияющие кейсы, а простые закрывайте раньше. Это экономит время ревьюеров для работы, которая действительно требует суждения.

Если хотите второе мнение по цифрам, Oleg Sotnikov на oleg.is помогает стартапам и небольшим командам пересматривать дизайн очереди, правила эскалации и предположения штатирования как Fractional CTO или советник. Две недели чистых данных и одностраничная карта процесса обычно достаточно, чтобы заметить реальные точки давления.