Reasoning-модели: бюджет и доказательства¶
Это сгенерированные тренировочные задания по темам опубликованного радара требований, а не свидетельства вопросов конкретного работодателя. Статьи и документация ниже объясняют техническую основу, но не подтверждают, что вопросы задавали на интервью. Источники проверены 2026-09-29.
Что меняется при обучении и инференсе¶
Обучение может менять способ решения задач, а при инференсе можно потратить дополнительные вычисления на конкретный запрос. Это разные решения. В исходном отчёте DeepSeek-R1 описан RL без предварительного SFT для R1-Zero, тогда как R1 добавляет данные для «холодного старта» (cold-start) и многоэтапную схему. Определение любой reasoning-модели как «RL без обучения на размеченных данных» теряет это различие.
В задании об обучающем сигнале разделите предмет обратной связи и момент её применения. Контроль по результату (outcome supervision) оценивает итог, контроль процесса (process supervision) — промежуточные шаги. Проверяющая модель также может выбирать кандидатов при инференсе без обновления генератора. Let's Verify Step by Step сравнивает методы обучения на математике. Работа обосновывает это ограниченное сравнение, а не универсальный рейтинг. В ответе объясните, как обнаружить проверяющего, который принимает убедительные, но неверные решения.
Расходуйте вычисления там, где они помогают¶
В задании о бюджете сравните один длинный запуск с несколькими кандидатами и отбором. Снелл и соавторы обнаружили в своих экспериментах зависимость полезного распределения вычислений от сложности задачи. Маршрутизатору запросов в продакшене приходится оценивать сложность по информации, доступной до того, как известен ответ.
Как предложение для формата собеседования, составьте таблицу: успех, полное время, нарушения срока и суммарная стоимость каждой стратегии. При расчёте расходов на успешную задачу включайте в числитель неудачные попытки и проверку. Параллельный запуск может сокращать время, но расходовать больше вычислений. Выберите политику по ограничениям сервиса и проверьте, не съедают ли выигрыш ошибки маршрутизации.
В задании о незавершённом ответе до повтора проверьте статус и расход. По документации OpenAI, выходной лимит включает reasoning-токены и может закончиться до появления видимого текста. Увеличение лимита — один из вариантов, но не диагноз для любого пустого ответа. Предложите общий бюджет восстановления и защиту от повторных действий инструментов.
Покажите причину улучшения¶
Задание о контролируемом сравнении проверяет, что произошло бы на тех же задачах при другой конфигурации. Зафиксируйте набор заданий и независимую оценку. Рекомендации OpenAI по оценке качества (evals) описывают последовательность: цель, данные, метрики и сравнение.
В предлагаемом эксперименте сначала сохраните инструменты и промпты при сравнении моделей, затем проверьте их изменения отдельно. Если важны взаимодействия, проверьте и комбинации. Покажите результат при равном бюджете и результат системы, которую собираетесь выпускать: это ответы на разные вопросы. Повторные прогоны и отдельные срезы выявят нестабильные или дорогие ошибки, скрытые средним улучшением.
Объяснения — диагностическое свидетельство¶
В задании о достоверности объяснения оценивайте ответ отдельно от объяснения. Чен и соавторы показали случаи, когда reasoning-модели использовали подсказки, не признавая этого в отображаемом рассуждении. Поэтому внешне безупречное объяснение не исключает влияния ложной подсказки.
Сравните парные задачи с подсказкой и без неё; отдельно учитывайте изменение ответа и признание влияния подсказки. Это проверка наблюдаемого поведения, а не доступ к скрытой цепочке рассуждений. Резюме провайдера, отображаемое рассуждение и журнал вызовов инструментов — разные объекты. Используйте доступные данные для разбора ошибок, а успех определяйте независимой проверкой результатов и действий.