Почему AI-бенчмарки не видят 90% реальной работы

Мой знакомый руководит операционным отделом средней логистической компании, и весной его команда три недели оценивала, может ли LLM взять на себя их процесс обработки исключений — рутинную работу по сверке счетов, которые не совпадают с заказами на закупку, между тремя системами, которые терпеть не могут друг друга. В презентации вендора были впечатляющие цифры: MMLU, GSM8K, HumanEval, пара агентных бенчмарков. Модель блестяще прошла все готовые тесты. Потом её натравили на реальную неделю исключений, и она уверенно сопоставила счёт на $14 000 не с тем заказом на закупку, потому что поставщик по-своему сократил собственное название. Ни один лидерборд такое не измеряет.

Этот разрыв теперь можно измерить. Недавнее сопоставление публичных AI-бенчмарков с таксономией O*NET министерства труда США — все 923 профессии и 18 797 задач, из которых состоит американская работа — показало, что 90% рабочих часов в США уходит на задачи, которые почти или совсем не покрыты бенчмарками. Только у 208 из 923 профессий есть хотя бы одна задача, подкреплённая пятью и более промптами из бенчмарков. У шести из 22 профессиональных семейств нет ни одной. Неприятный вывод не в том, что AI слаб. А в том, что наши инструменты измерения возможностей AI почти полностью направлены не на ту часть экономики.

Что на самом деле покрывают AI-бенчмарки

Методология этого сопоставления заслуживает внимания, она аккуратнее, чем следует из заголовка. Исследователи взяли 29 качественных, ненасыщенных агентных бенчмарков — тесты, в которых модели должны реально выполнять работу, а не отвечать на вопросы — и с помощью LLM-судьи (проверенного на экспертах-людях) разметили каждый промпт задачами O*NET, которые он проверяет. Задача считается «покрытой», если на неё приходится не меньше пяти промптов. Добавьте оценки того, сколько рабочего времени занимает каждая задача, и получите картину того, что наш набор оценок вообще способен увидеть по всей экономике.

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

Перечитайте это ещё раз: мы тестируем AI на престижной версии профессии, игнорируя ту версию, которую большинство людей реально занимает. Длинный хвост квалифицированной работы средней зарплаты — координаторы, клерки, специалисты и диспетчеры, чьи часы в сумме составляют огромную долю экономики, — почти не имеет никакой измерительной инфраструктуры. Когда кто-то заявляет, что AI может выполнять какой-то процент «интеллектуальной работы», спросите: какой именно интеллектуальной работы, как измерено и по какому списку задач. Честный ответ обычно такой: тонкий, нерепрезентативный срез, измеренный тестами, созданными для научных статей.

Насыщение бенчмарков — ошибка дизайна оценки

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

Насыщение — это видимый симптом. Когда каждая передовая модель набирает выше 90% на тесте, тест перестаёт различать модели, но глубже проблема в том, что мы реагируем, создавая очередной бенчмарк в том же стиле, про те же типы задач, потому что именно их умеем автоматически проверять. Вопросы с выбором ответа порождают более сложные вопросы с выбором ответа. Задачи по программированию порождают более сложные задачи по программированию. Тем временем никто не делает бенчмарк для такого: «заметить, что пункт о возмещении убытков в этом договоре тихо противоречит условиям term sheet от марта», потому что проверка такого требует юриста, времени и суждений, которые плохо поддаются автоматизации.

Поэтому я не согласен с трактовкой, что насыщение бенчмарка означает, что AI «решил» область. Насыщение означает, что инструмент упёрся в потолок, и точка. Термометр, который показывает максимум 40°C, не доказывает, что в комнате 40 градусов, — он доказывает, что нужен другой термометр. Если вы оцениваете модели для продакшена, особенно если строите системы принятия решений на основе LLM, где ошибки стоят реальных денег, то разница в лидербордах на насыщенных бенчмарках должна почти не влиять на ваше решение.

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

Эффект уличного фонаря в оценке AI

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

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

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

Модели генерируют, но никто не измеряет суждение

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

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

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

Взвешивание оценок по реальному распределению задач

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

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

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

Как оценивать AI на той работе, которую вы делаете на самом деле

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

• Берите задачи из логов, а не из воображения. Выгрузите неделю реальных тикетов, писем или исключений и выбирайте по частоте. Ваш набор оценок должен повторять гистограмму вашей нагрузки, включая скучный хвост — а скучный хвост и есть большая часть работы.
• Взвешивайте по времени или стоимости и показывайте оба числа. Плоское и взвешенное среднее задают границы истины. Если модель выигрывает по плоскому среднему, но проигрывает по взвешенному, значит, она хороша в тех задачах, которые легко тестировать, — и это как раз тот режим отказа, который вы ищете.
• Включайте задачи на верификацию. Возьмите реальные результаты, в том числе заведомо плохие, и оценивайте, сможет ли модель поймать подложенные и естественные ошибки. По моему опыту, навык обнаружения и навык генерации почти не коррелируют, а покупаете вы именно обнаружение.
• Держите закрытый набор и обновляйте его. Любая оценка, которую вы переиспользуете месяцами, становится обучающей мишенью, даже непреднамеренно, как только кто-то начинает подбирать промпты под неё. Меняйте кейсы ежеквартально.
• По возможности оценивайте сквозные результаты. Если задача — «сверить этот счёт», оценивайте сверку, а не промежуточный текст. Промежуточные метрики льстят моделям так же, как юнит-тесты льстят коду без интеграционного покрытия.

Есть и последний, более тихий эффект, который узнает каждый, кто ежедневно пользуется AI-инструментами для программирования: микроскопическая болезнь Баумоля. Когда генерация становится в двадцать раз быстрее, день вы проводите не в генерации. Вы тратите его на части, которые не ускорились: ревью, координацию, проверку, решения. Неизмеряемый остаток не сокращается по мере улучшения AI; он растёт, заполняя освободившееся время, и становится всё большей долей того, что определяет, стоило ли внедрять AI. Измерять автоматизируемую часть со всё большей точностью, игнорируя остаток, — это не просто неполно. Это переворачивает то, что важно.

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