TL;DR
TimeEvo — цикл самоулучшения агента. Он собирает свои неправильные ответы в группы по причине ошибки. Для каждой группы он пишет себе небольшой инструмент, который считает недостающие цифры. Инструмент попадает в набор только после парной проверки: на отложенных вопросах сравнивают ответы «до» и «после». Если починено заметно больше, чем сломано, инструмент принимают. Если нет, раунд отбрасывают.
Главная находка: «перепроверь свой ответ» почти ничего не меняет в итоговой точности, хотя ответы при этом меняются. Один проход самопроверки изменил 147 ответов. 49 он исправил, а 56 ранее верных сломал. Остальные 42 просто заменили одну ошибку другой. Среднее число правильных ответов осталось на месте, поэтому вред не виден. Тот же эффект повторился на всех трёх моделях. Второй неприятный результат: набор из 21 инструмента, собранный экспертами, помогал на одних задачах и вредил на других. Точность по обнаружению аномалий падала на всех моделях, хотя инструмент для аномалий в наборе был.
Суть метода в трёх шагах. Сначала ошибки группируются по недостающему умению, а не по типу вопроса. Затем для каждой группы пишется «контракт измерения»: что именно нужно посчитать и где это применять, а где нет. В конце идёт парная проверка. Поверх этого стоит правило: инструмент отдаёт только числа, не вердикт, а исходный ответ остаётся по умолчанию.
Схема метода
РАУНД (повторяется):
ШАГ 1: Прогнать агента на тренировочных вопросах → список ошибок
ШАГ 2: Сгруппировать ошибки по недостающему умению → корзины
(ошибки «инструмент сработал» и «инструмента не было» — отдельно)
ШАГ 3: Для каждой корзины → «контракт измерения»:
причина · что измерить · входы · критерий успеха · область + анти-область
+ действие: CREATE / REFINE / RESCOPE / RETIRE
ШАГ 4: Написать инструмент (до 3 попыток) → он выдаёт только числа, не вердикт
ШАГ 5: Быстрый фильтр на ≤32 ошибках корзины → нужен минимум 1 засчитанный ремонт
ШАГ 6: Парный допуск всей библиотеки на валидации:
helped (было неверно → стало верно) vs harmed (было верно → стало неверно)
→ допуск только если нижняя граница разницы > 0
ШАГ 7: Не прошла → один раз убрать явно вредные инструменты → повторить проверку
Не прошла снова → раунд отброшен, агент не меняется
ПРИ ОТВЕТЕ: агент отвечает как обычно → инструмент пересматривает ответ
только на вопросах из своей области → заменить ответ можно лишь явным решением
Шаги 1–3 можно сделать в чате вручную. Шаги 4–7 в оригинале требуют кода.
Пример применения
Задача: Вы сделали агента-аналитика для интернет-магазина на Ozon. Он смотрит выгрузку продаж по дням и отвечает на вопросы: «есть ли аномалия за эту неделю?», «тренд растёт или падает?», «это сезонность или акция?». На 40 тестовых вопросах с известными ответами он ошибся 14 раз. Метод здесь работает хорошо, потому что ответ можно проверить по эталону.
Промпт:
Ты — диагност ошибок аналитического агента. Ты не отвечаешь на вопросы
сам. Ты группируешь ошибки и составляешь планы измерений.
Ниже 14 вопросов, на которых агент ошибся. Для каждого: вопрос, ответ
агента, эталонный ответ, короткое описание данных.
1. «Есть ли аномалия 12–18 марта?» — агент: «нет», эталон: «да (скачок -40% 15 марта)»
2. «Тренд растёт?» — агент: «растёт», эталон: «падает после промоакции»
[...вставь остальные ошибки...]
Шаг 1. Определи 3–5 категорий ошибок по тому, КАКОГО УМЕНИЯ
не хватило агенту (а не по теме вопроса). Не используй названия задач.
Шаг 2. Отнеси каждую ошибку ровно в одну категорию. Категории с одной
ошибкой отложи в сторону.
Шаг 3. Для каждой категории выдай «контракт измерения»:
- причина: почему агент ошибается
- измерение: какое число или признак нужно вычислить из данных
- входы: что нужно для вычисления
- критерий успеха: как поймём, что измерение помогает
- область: когда применять
- анти-область: когда НЕ применять
- действие: CREATE (нового измерения не хватает) / REFINE (измерение есть,
но агент его игнорирует) / RESCOPE (срабатывает не там) / RETIRE (убрать)
Правило: контракт описывает ИЗМЕРЕНИЕ, а не правильный ответ.
Не пиши «если X, отвечай Y».
Результат: Модель вернёт 3–5 категорий с распределением ошибок по ним. К каждой категории прилагается контракт из семи полей. Контракты будут про то, что посчитать (например, отклонение от скользящего среднего или сравнение до и после даты), а не про готовые ответы. Дальше вы пишете эти измерения в виде правил или скриптов и проверяете парным сравнением на других вопросах (см. «Адаптации»).
Почему это работает
Слабость. Модель, которой сказали «проверь ответ», не получает новой информации, она только перечитывает свой текст. Часть ответов она меняет с верных на неверные, часть с неверных на верные. Итоговое среднее не двигается, и кажется, что «всё нормально». Эксперты тоже ошибаются в другую сторону: набор «полезных инструментов» оценивают по среднему, а полезность определяется вопрос за вопросом.
Сильная сторона. Модель хорошо группирует ошибки и формулирует диагноз («не хватало сравнения с базовой линией»). Ещё она неплохо пишет небольшие функции, которые считают числа. Объективные числа дают ей новую информацию, которой при перечитывании не было.
Как метод использует это. Модель делает то, что умеет: диагностику и генерацию вычислений. Решающее слово остаётся за парным счётом «починил / сломал» на вопросах, которых модель не видела. Инструмент выдаёт только числа. Ответ по умолчанию остаётся прежним, а заменить его можно только явным решением. Поэтому вне области инструмента вред невозможен.
Рычаги управления: - Порог допуска. Строгое «нижняя граница > 0» защищает от случайности, но на маленькой выборке отклоняет даже чистые 3:0. Для небольших проверок можно смягчить: разница не меньше 3 вопросов или 2% выборки, вред не выше 10%. - Область и анти-область. Чем уже область, тем меньше риск вреда. Узкий инструмент вмешивается реже. - Отдельные корзины для «инструмент сработал» и «инструмента не было». Первые говорят о плохом инструменте, вторые о пробеле в покрытии. - Один раунд убирания вредных частей. Повторные раунды подгоняют набор под валидацию, поэтому второго не делают. - Инструмент без вердикта. Если разрешить инструменту выдавать ответ, он начнёт подгонять константы под тест.
Что показали эксперименты
На десяти задачах про временные ряды и трёх моделях TimeEvo улучшил базового агента на каждой задаче и каждой модели. Средний прирост около 7–9 пунктов, на отдельных задачах до 14–16. Самопроверка, голосование из пяти ответов, пример-подсказки и экспертный набор такой стабильности не дали: у них пики сочетались с провалами. Набор, выращенный на дешёвой модели, продолжил помогать и на более сильных.
Шаблон промпта
Это оригинальный диагностический шаг (корзины и контракты). Парную проверку вы делаете сами по таблице.
Ты — диагност ошибок агента. Ты не решаешь задачи, ты находишь
недостающее умение и планируешь его измерение.
Агент решает: {задача_агента}
Формат вопросов: {формат_вопросов}
Как проверяется ответ: {эталон_или_правило_проверки}
{список_ошибок: вопрос | ответ агента | эталон | краткое описание входных данных}
1. Определи {число_категорий} категорий ошибок по НЕДОСТАЮЩЕМУ УМЕНИЮ,
а не по теме вопроса. Категории с одной ошибкой отложи.
2. Отнеси каждую ошибку ровно в одну категорию.
Ошибки, где агент пользовался {инструмент_или_правило}, и ошибки,
где ничего не применялось, разнеси по разным категориям.
3. Для каждой категории выдай контракт:
- root_cause
- required_measurement
- inputs
- success_criterion
- scope
- anti_scope
- action: CREATE | REFINE | RESCOPE | RETIRE
4. Контракт описывает ИЗМЕРЕНИЕ (число, признак, проверку), а не готовый
ответ. Никаких правил вида «если X — отвечай Y».
Предложи, как проверить кандидата парно на {валидационные_вопросы}:
сколько ответов было неверно и стало верно (helped),
сколько было верно и стало неверно (harmed).
Допуск: helped > harmed и разница статистически устойчива.
Иначе — отклонить.
Что подставлять:
- {задача_агента} и {формат_вопросов} — что агент делает и в каком виде приходят вопросы.
- {эталон_или_правило_проверки} — как вы узнаёте, что ответ верный.
- {список_ошибок} — минимум 10–15 реальных провалов.
- {число_категорий} — обычно 3–5.
- {валидационные_вопросы} — вопросы, которые агент не видел при диагностике.
🚀 Быстрый старт — вставь в чат:
Вот шаблон диагностики ошибок агента (TimeEvo). Адаптируй под мою задачу:
{опиши своего агента и что он делает}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно делает агент, как вы проверяете его ответы и какие ошибки у вас уже есть. Это нужно, потому что метод строится на реальных провалах и на эталоне, без них корзины получатся выдуманными. Модель возьмёт структуру из шаблона (корзины, контракт, парный допуск) и соберёт рабочий промпт под вашу задачу.
Адаптации (мои, не из статьи)
Отдельно от оригинала. Принцип «посчитай починено против сломано» можно применять без кода для любой правки: - Сделали агента с шагом самопроверки или поменяли системный промпт? Прогоните 30–50 вопросов с эталонами «до» и «после». Сведите в таблицу «ID | эталон | до | после». Попросите LLM посчитать, сколько ответов стало верным и сколько стало неверным, и только потом решайте. - Не загружайте агенту десятки инструментов «на всякий случай». Начните с пустого набора и добавляйте инструмент только под группу реальных ошибок.
Ограничения
⚠️ Нужен код. Полная версия TimeEvo пишет и запускает Python-инструменты в изолированной среде и ведёт парный прогон. В обычном чате воспроизводятся только шаги диагностики и ручной подсчёт.
⚠️ Нужны вопросы с эталонами. Метод работает, когда правильность ответа проверяется автоматически или по эталону. Для текстов, креатива и мнений парный счёт «починил / сломал» не посчитать.
⚠️ Одна область. Все эксперименты про вопросы по временным рядам и модели одного семейства. Перенос на другие задачи авторы не проверяли.
⚠️ Жёсткий допуск отбрасывает мелкие выигрыши. На малой выборке даже чистое 3 против 0 не проходит. Выигрыш на отдельных задачах небольшой (около 1–2 пунктов).
⚠️ Это не значит «самопроверка всегда вредна». Измерялся один проход общей самопроверки. Вывод: не верьте среднему, считайте починенное и сломанное отдельно.
Ресурсы
TimeEvo: Failure-Driven Self-Evolution of a Time Series Agent. Jie Yang, Yan Zheng, Jiarui Sun, Xiran Fan, Junpeng Wang, Liang Wang, Zelin Xu, Qinghua Liu, Zhengyu Fang, Yiwei Cai, Philip S. Yu. University of Illinois at Chicago, Visa Research, University of Florida, The Ohio State University, Case Western Reserve University. Код: https://github.com/Muyiiiii/TimeEvo. Связанные работы: Self-Refine (Madaan et al., 2023), TimeART (Wu et al., 2026), Chronos-2 (Ansari et al., 2025), TemporalBench (Weng et al., 2026).