Когда ИИ дешевеет, узким местом становится проверка

Самой дорогой частью ИИ-процесса вскоре может оказаться человек — или система, — ожидающий в его конце.

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

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

Дешёвый черновик — ещё не дешёвая завершённая задача

17 июля OpenAI прямо сформулировала этот принцип в своей scorecard для эпохи ИИ. Она предлагает измерять стоимость успешной задачи, включая затраты на модель, время сотрудников, проверку людьми, повторные попытки и переделки, — и засчитывать только работу, прошедшую нужный порог качества. Это важная поправка к учёту ИИ. Токен — входной ресурс. Сгенерированный артефакт — промежуточный результат. Ни то ни другое не является итогом, пока результат не принят для предполагаемого применения.

Январский Economic Index 2026 от Anthropic приходит к близкому выводу с другой стороны. Он рассматривает успешность задачи как экономически значимую и для вопроса о возможности автоматизации, и для числа попыток, которые она требует. Смоделированный эффект на производительность резко снижается, когда автоматизированные профессиональные задачи зависят от более медленных взаимодополняющих задач, не охваченных автоматизацией. При одном из допущений о такой взаимодополняемости его иллюстративные оценки с поправкой на успех снижаются до 0,8 процентного пункта для Claude.ai и до 0,6 пункта для API. Это зависимые от модели оценки, а не наблюдаемые результаты по производительности экономики. Но сам механизм существенен: ускорение одного этапа не устраняет работу вокруг него.

METR даёт практическое предостережение против подмены измерения уверенностью. В рандомизированном исследовании 246 задач, выполненных 16 опытными разработчиками open-source в условиях начала 2025 года, доступ к ИИ-инструментам увеличил измеренное время выполнения на 19 процентов. При этом участники считали, что инструменты их ускорили. Этот результат не означает, что ИИ в целом замедляет разработку ПО. Речь идёт о небольшой специфической группе, работавшей со зрелыми репозиториями и доступными тогда инструментами. Однако исследование показывает, что ощущаемая локальная скорость может расходиться со временем до завершения работы целиком.

Генерация повышает входящий поток; мощность проверки остаётся фиксированной

Операционный механизм здесь — обычная теория очередей. Результат Литтла связывает средний объём незавершённой работы, интенсивность поступления и среднее время в устойчивой системе. Если ИИ увеличивает поток кандидатов на входе этапа проверки, а мощность проверяющих не меняется, система должна уступить в чём-то: растёт очередь проверки, увеличивается цикл или ограничивается входящий поток. Нередко происходит всё сразу. Команда может праздновать десятикратный рост числа сгенерированных pull request или черновиков ответов клиентам, незаметно создавая запас работы, которому никто не успевает доверять.

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

“Производственную функцию следует проектировать вокруг дефицитного валидатора, а не вокруг доступного генератора.

Измеряйте пропускную способность с поправкой на проверку

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

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

Три режима проверки

Процессы следует классифицировать по способу приёмки их результатов. Это выбор экономического дизайна ещё до выбора инструмента.

1. Машинно проверяемая работа имеет исполнимые критерии приёмки. Это могут быть ограниченные преобразования, расчёты с заданными входными данными, проверка схем, детерминированные бизнес-правила и сверка с авторитетными записями. Здесь нужно улучшать тесты, ограничения и эталонные данные, чтобы приёмка масштабировалась вместе с генерацией.
2. Статистически проверяемая работа допускает выборочный контроль, потому что цена ошибок ограничена, а выборка даёт достаточную уверенность для конкретного применения. Важно определить метод выборки, допустимый уровень ошибок и реакцию на сбой в выборке, а не просто назвать выборку «автоматизацией».
3. Экспертно проверяемая работа зависит от дефицитного профессионального суждения. Сюда могут относиться юридическое толкование, сложное ревью кода, решения по клиентам с богатым контекстом и новый анализ. ИИ всё ещё способен готовить и сужать такую работу, но пропускная способность останется ограниченной, пока не снизится потребность в экспертной проверке или не вырастет экспертная мощность.

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

Снижайте потребность в проверке до масштабирования генерации

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

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

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