TL;DR
Learning to Wait — метод, где LLM-агент предсказывает сколько времени займёт задача и активно ждёт через time.sleep(t), вместо того чтобы постоянно проверять "готово ли?". Агент использует семантическое понимание задачи (например, "скачать тяжёлый файл дольше чем лёгкий") и учится на истории прошлых попыток.
LLM сталкивается с дилеммой двух типов потерь: проверять статус слишком часто — тратишь запросы и забиваешь контекст ненужными "ещё не готово", ждать слишком долго — теряешь время. Блокирующие обёртки (когда система сама ждёт) не масштабируются. Постоянные проверки каждые N секунд съедают токены и размывают контекст. Идеальное решение — агент сам понимает "этой задаче нужно примерно 40 секунд" и ждёт нужное время.
Метод использует двухфазную стратегию: сначала агент даёт консервативную оценку с запасом (чтобы не проверить слишком рано), потом на основе обратной связи (сколько реально заняло vs сколько предсказал) калибрует оценки для следующих попыток. Каждый раунд агент получает информацию: задача X заняла Y секунд, ты проверил Z раз — и корректирует внутренние представления о времени.
Схема метода
ЭПИЗОД 1 (без истории):
1. Получить задачу → семантическая оценка времени (консервативная)
2. time.sleep(предсказанное_время)
3. Проверить статус → запомнить: реальное время, сколько проверок
ЭПИЗОД 2+ (с историей):
1. Получить задачу + историю прошлых попыток
2. Проанализировать: прошлая оценка vs реальность
3. Скорректировать предсказание
4. time.sleep(улучшенное_время)
5. Проверить статус → запомнить для следующего раунда
Всё выполняется в отдельных запросах. История передаётся как часть промпта в следующем эпизоде.
Пример применения
Задача: Планируешь несколько задач для ассистента, хочешь реалистично оценить время
Промпт:
Мне нужно оценить сколько времени займут эти задачи для копирайтера Маши:
A) Написать 10 постов для соцсетей про новый курс (средний размер поста 1000 знаков)
B) Переписать лендинг (3 экрана, сейчас 5000 знаков)
C) Создать email-серию на 5 писем с нуля (концепция + тексты)
Оцени время на каждую задачу. Объясни свою логику: на основе чего оцениваешь, какие факторы учитываешь.
Потом я дам тебе реальное время которое заняла задача A, и ты скорректируешь оценки для B и C.
Результат: Модель выдаст оценки с обоснованием (например: посты — стандартный формат, быстрее; лендинг — нужна архитектура, дольше; серия писем — концептуальная работа, долго). После обратной связи по задаче A модель скорректирует оценки: если Маша сделала посты за 3 часа вместо предсказанных 4, модель пересчитает что лендинг займёт ~4 часа вместо 5.
Почему это работает
Слабость LLM: Модель не чувствует реальное время. Она генерирует мгновенно, а в реальном мире задачи имеют латентность. Без механизма оценки времени агент либо проверяет слишком часто (тратит запросы), либо ждёт наугад.
Сильная сторона LLM: Модель хорошо понимает семантику задач и может рассуждать о факторах сложности. Она знает что "скачать 5GB дольше чем 50MB", "рестарт статичного сервиса быстрее чем масштабирование кластера", "написать 10 коротких постов быстрее чем одну концептуальную статью". Эти знания — из обучающих данных.
Как метод использует силу: Вместо слепого ожидания или постоянных проверок, агент активно предсказывает время на основе описания задачи. Добавляя историю (прошлые предсказания vs реальность) в промпт, модель калибрует оценки через In-Context Learning — видит паттерн своих ошибок и корректирует.
Рычаги управления: - Консервативность первой оценки — можно явно просить "дай оценку с запасом 20%" или "будь оптимистичен" - Тип обратной связи — можно давать не только "сколько заняло", но и "почему заняло больше/меньше" для лучшей калибровки - Количество исторических примеров — больше истории → точнее калибровка, но больше токенов
Шаблон промпта
Базовая версия (одна задача):
Задача: {описание_задачи}
Оцени сколько времени займёт эта задача. Объясни факторы которые влияют на длительность.
Дай оценку в формате:
- Минимум: X минут
- Реалистично: Y минут
- С запасом: Z минут
С калибровкой (несколько попыток):
Задача: {описание_задачи}
История прошлых попыток для похожих задач:
{задача_1}: предсказал {время_1}, реально заняло {реальное_время_1}
{задача_2}: предсказал {время_2}, реально заняло {реальное_время_2}
Проанализируй:
1. Какой паттерн в моих ошибках оценки?
2. Что я недооценивал или переоценивал?
3. Как скорректировать оценку для текущей задачи с учётом истории?
Дай улучшенную оценку времени для текущей задачи.
Что подставлять:
- {описание_задачи} — конкретное описание с деталями (объём, сложность, что именно делать)
- {задача_N} — краткое название прошлой задачи
- {время_N} — твоя прошлая оценка (число + единица измерения)
- {реальное_время_N} — сколько реально заняло
Почему это работает (детальнее)
Исследование показало три ключевых находки:
1. Семантическое понимание времени LLM может оценить длительность по смысловым признакам задачи. Модель знает что "обновить лёгкий образ nginx быстрее чем скачать CUDA образ на 5GB", "рестарт сервиса быстрее чем масштабирование кластера". Это работает без специального обучения — знания из корпуса.
2. Динамическая калибровка Модели с сильным reasoning (Gemini-3-Pro) и специализацией на коде (Claude-Sonnet-4.5) показали явную кривую обучения: начинали с консервативных оценок (большой запас), потом через 3-5 эпизодов сходились к точным предсказаниям. GPT-5.1 показал точные оценки с первой попытки — сильнее zero-shot понимание.
3. Ловушка жёстких эвристик
Qwen3-next показал конкурентные цифры, но анализ траектории выявил отсутствие адаптации — модель использовала статичный time.sleep(60), который случайно покрывал максимальную латентность задач. В реальной среде с другими временными диапазонами такая стратегия провалится.
Метрика эффективности: Исследователи измеряли Regret Score = количество проверок × exp(избыточное время ожидания). Чем меньше проверок при точном времени ожидания — тем лучше. Лучшие модели достигали 1 проверки при отклонении 5-10 секунд от реального времени.
Ограничения
⚠️ Нужна обратная связь: Метод работает итеративно — без информации о реальном времени выполнения калибровка невозможна. Для разовых уникальных задач эффект ограничен начальной семантической оценкой.
⚠️ Зависимость от описания задачи: Качество оценки прямо зависит от детальности описания. Расплывчатое "сделай что-то с сервером" даст хуже оценку чем "обнови образ nginx с версии 1.20 до 1.23, кэш образов присутствует".
⚠️ Симулированная среда: Исследование использовало контролируемые распределения времени (Gamma distribution). В реальном мире могут быть скачки (сетевые задержки, конкуренция за ресурсы), которые сложнее предсказать.
Как исследовали
Команда создала симулированный Kubernetes кластер с тремя типами задач разной "тяжести": обновление лёгкого образа (среднее время 35 секунд), рестарт stateful сервиса (45 секунд), масштабирование etcd кластера (55 секунд). Время выполнения моделировали Gamma-распределением с фиксированной дисперсией — это отражает многоэтапность реальных операций (проверка API → остановка пода → скачивание → запуск), в отличие от простого экспоненциального распределения для атомарных событий.
Агенту давали только бинарную обратную связь: PENDING или DONE, без подсказок о прогрессе. Два доступных действия: time.sleep(t) для активного ожидания и check() для проверки статуса. Каждый следующий эпизод получал краткую сводку предыдущего: какая команда, сколько раз проверял, сколько реально заняло.
Тестировали четыре модели: Gemini-3-Pro (reasoning-enhanced), Claude-Sonnet-4.5 (code-specialized), GPT-5.1 (general SOTA), Qwen3-next-80B (mid-size open-weights). Это позволило проверить универсальность способности к темпоральной калибровке.
Удивительная находка: Модели разделились на три стратегии. Reasoning-модели (Gemini, Claude) показали явное обучение — начали консервативно, быстро скорректировали. GPT-5.1 сразу дал точные оценки, минуя фазу калибровки — superior zero-shot grounding. Qwen3-next использовал "защитную" эвристику (sleep(60) для всех задач), что сработало только потому что максимум был ~55 секунд — не настоящая адаптация, а удачное совпадение.
Почему Gamma-распределение важно: Авторы объясняют что kubectl операции — это цепочки подзадач (валидация → терминация → скачивание → старт). Сумма нескольких независимых экспоненциальных стадий даёт Gamma-распределение. Это точнее отражает реальность чем одно экспоненциальное распределение.
Метрика Regret Score специально использует ground-truth время, потому что цель — измерить способность агента к темпоральному выравниванию, не создать практический тренировочный рецепт. Это фундаментальное исследование возможностей, не production-ready система.
Адаптации и экстраполяции
🔧 Техника: Добавить промежуточные чекпоинты для длинных задач
Для задач с очень большой неопределённостью (например, первая оценка "от 30 минут до 2 часов") можно разбить ожидание на интервалы:
Задача займёт от 30 минут до 2 часов.
Вместо одного долгого ожидания, спланируй стратегию проверок:
1. Дай консервативную оценку минимального времени
2. После первой проверки — уточни оценку на основе того что задача ещё не готова
3. Запланируй следующий интервал ожидания
Формат ответа:
- Первая проверка через: X минут (обоснование)
- Если не готово, следующая через: Y минут (обоснование)
- Максимум проверок: Z
Эффект: Вместо слепого 2-часового ожидания или 40 проверок каждые 3 минуты, агент адаптивно сужает диапазон.
🔧 Техника: Сравнительная калибровка через референсные задачи
Если нет прямой истории для конкретной задачи, можно калибровать через аналоги:
Мне нужно оценить время на {новая_задача}.
У меня есть референсные точки (задачи которые я хорошо знаю):
- {референс_1}: обычно занимает {время_1}
- {референс_2}: обычно занимает {время_2}
Сравни новую задачу с референсными:
1. Что общего / в чём отличия?
2. Какие факторы делают новую задачу быстрее/медленнее?
3. Дай оценку относительно референсов ("примерно как {референс_1}, но на 30% дольше потому что...")
Итоговая оценка времени: ____
Эффект: Используешь существующую внутреннюю калибровку для новых контекстов.
Ресурсы
Learning to Wait: Synchronizing Agents with the Physical World — исследование темпорального выравнивания LLM-агентов с асинхронными средами через активное предсказание времени ожидания. Использует Code-as-Action парадигму (time.sleep(t)) и In-Context Learning для калибровки.
Авторы: Yifei She, Ping Zhang, He Liu, Yanmin Jia, Yang Jing (Infrawaves), Zijun Liu (Tsinghua University), Peng Sun (Shanghai Qiji Zhifeng Co., Ltd.), Xiangbin Li, Xiaohe Hu (Infrawaves)
Ключевые концепции из работы:
- Temporal Gap ( _T_act ≪ _T_true) — разрыв между инициацией действия и его завершением в асинхронных средах
- Cognitive Timeline vs Physical Timeline — внутренние часы агента vs реальное время внешнего мира
- Code-as-Action paradigm — использование программного синтаксиса (time.sleep()) как инструкций для агента
- Regret Score — метрика эффективности: количество проверок × exp(избыточное ожидание)