[Перевод] Разработка технических тестовых заданий, устойчивых к ИИ

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

С начала 2024 года наша команда инженеров по производительности использует тестовое задание для отбора, в котором кандидаты оптимизируют код для симулированного ускорителя. Его прошли более 1000 человек, и десятки из них теперь работают у нас — в том числе инженеры, которые запустили наш кластер Trainium и участвовали в выпуске каждой модели начиная с Claude 3 Opus.

Но каждая новая модель Claude вынуждала нас переделывать тест. При том же временном лимите Claude Opus 4 превосходил большинство кандидатов. Это ещё позволяло выделить сильнейших — но потом Claude Opus 4.5 догнал и их. Люди по-прежнему способны превзойти модели при неограниченном времени, но в рамках тестового задания мы больше не могли отличить результаты лучших кандидатов от результатов нашей самой мощной модели.

С каждой новой версией тестового задания я всё лучше понимал, какие форматы оценки устойчивы к ИИ, а какие — нет. В этой статье я расскажу об изначальном формате задания, о том, как каждая модель Claude его «побеждала», и о всё более нестандартных подходах, к которым мне пришлось прибегнуть, чтобы тест оставался сложнее возможностей нашей топовой модели.

Как появилось тестовое задание

В конце 2023 года мы готовились к обучению и запуску Claude Opus 3: новые TPU- и GPU-кластеры, запуск Trainium, резкий рост затрат на ускорители. При этом инженеров по производительности не хватало.

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

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

• Реалистичный временной горизонт: окно в 4 часа (позже в 2) ближе к реальной работе, чем 50-минутное интервью.

• Естественная среда: кандидаты работают в своём редакторе, без наблюдателей.

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

• Допустимость использования ИИ: мы прямо разрешили использовать ИИ-инструменты, как и на реальной работе.

При этом тестовое задание должно обеспечивать кандидатам множество возможностей показать свои способности — оставляя как можно меньше на волю случая.

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

Я создал Python-симулятор вымышленного ускорителя с характеристиками, похожими на TPU: вручную управляемая память, SIMD, VLIW и многопоточность. Кандидаты работали с трассировкой Perfetto, показывающей каждую инструкцию.

Задача — параллельный обход дерева. Она намеренно не была связана с глубоким обучением: большинство инженеров по производительности ещё не имели с ним дела, а специфику можно освоить уже на месте. Задача была вдохновлена безветвящимся SIMD-инференсом деревьев решений — классической задачей оптимизации ML.

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

Что показали первые полтора года

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

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

Многие кандидаты работали над тестом и после истечения лимита времени — просто из интереса. Лучшие решения включали неожиданные оптимизации и даже мини-компиляторы.

Затем Claude Opus 4 победил

К маю 2025 года Claude 3.7 Sonnet уже достиг уровня, при котором более 50% кандидатов выступили бы лучше, просто делегировав всё Claude Code. Предрелизный Claude Opus 4 за 4-часовой лимит выдал более оптимизированное решение, чем почти все кандидаты.

Я переработал тест: определил, где Claude начинает буксовать — и это стало новой стартовой точкой для версии 2. В новом тесте я:

• убрал многопоточность (её Claude уже решил, а циклы разработки она только замедляла, не добавляя информативности);

• добавил глубины в архитектуру;

• сделали стартовый код чище;

• сократили лимит до 2 часов.

Версия 2 делала акцент на интересных вариантах оптимизации, а не на отладке и объёме кода. Она хорошо нам послужила — несколько месяцев.

А затем победил уже Claude Opus 4.5

Предрелизный Claude Opus 4.5 за 2 часа справлялся с узкими местами теста, реализовывал все типичные микрооптимизации и достигал проходного порога менее чем за час.

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

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

Почему мы не запретили ИИ

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

Поднимать планку до «обогнать Claude» тоже казалось сомнительным решением: Claude работает слишком быстро, и человек, который его направляет, почти всегда оказывается в роли догоняющего.

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

Попытка 1: другая задача оптимизации

Я выбрал задачу на основе одной из самых хитрых оптимизаций ядер, которую делал в Anthropic: эффективная транспозиция данных в 2D-регистрах TPU с избеганием конфликтов банков памяти.

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

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

Попытка 2: нестандартная задача

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

Я вспомнил игры Zachtronics — программистские головоломки с необычными, сильно ограниченными наборами инструкций. По этому принципу разработал серию задач с крошечным набором инструкций, где нужно оптимизировать решения по минимальному их количеству. Затем реализовал одну головоломку средней сложности и протестировал на Claude Opus 4.5. Он провалился.

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

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

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

Открытый челлендж

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

Опубликованная версия начинается с нуля (как версия 1), но использует набор инструкций и одноядерный дизайн версии 2, поэтому количество тактов сопоставимо с версией 2.

Бенчмарки производительности (измерены в тактах симулированной машины):

• 2164 такта: Claude Opus 4 после многих часов в харнессе тест-тайм вычислений;

• 1790 тактов: Claude Opus 4.5 в обычной сессии Claude Code, примерно соответствует лучшему человеческому результату за 2 часа;

• 1579 тактов: Claude Opus 4.5 после 2 часов в нашем харнессе тест-тайм вычислений;

• 1548 тактов: Claude Sonnet 4.5 после значительно более чем 2 часов тест-тайм вычислений;

• 1487 тактов: Claude Opus 4.5 после 11,5 часов в харнессе;

• 1363 такта: Claude Opus 4.5 в улучшенном харнессе тест-тайм вычислений после многих часов.

Задание доступно на GitHub. Если вы получите результат ниже 1487 тактов, превзойдя лучший результат Claude на момент релиза, отправьте код на [email protected].

Наконец у нас есть устойчивое к Claude тестовое задание. И нам интересно, сколько оно продержится.

Источник