Планировщик ИИ: 3 структурные ошибки, которые не исправит новая модель

Почему планировщик ИИ продолжает ошибаться, даже с новой моделью

Вы когда-нибудь замечали, что ваш ИИ-агент, который отлично пишет планы, всё равно проваливает сложные задачи? Я провёл полевой тест с 157 целями и обнаружил, что планировщик систематически допускает одни и те же структурные ошибки. И хуже того — смена модели на более мощную не помогла. В этой статье я разберу три дефекта, которые не лечатся увеличением параметров, и покажу, как детерминированная проверка может устранить половину проблем.

Три семейства дефектов: как планировщик ИИ ломает планы

Анализ 132 конкретных блокеров в 63 строгих целях выявил чёткую закономерность. Каждый сбой относился к одному из трёх типов. Давайте разберём их на реальных примерах из моего проекта.

Непроверенные зависимости: 57 блокеров

Планировщик объявляет предварительное условие, которое не устанавливает ни одна предыдущая задача. Он знает, что должно быть правдой, но не выстраивает шаги для её достижения. Вот пример из ai-03-model-serving-migration:

[БЛОКЕР] unverified_dependencies — задача=cutover_traffic_100
  "Переключение трафика с SageMaker на vLLM (100%) зависит от
  предыдущих этапов переключения, но нет подтверждения стабильности
  перед продолжением."

План говорит «переключить 100% трафика», но ни одна задача не проверяет, что этапы 10% и 50% прошли успешно.

Небезопасный порядок: 46 блокеров

Задачи выполняются до своих жёстких предпосылок. Переключение происходит до проверки, а резервное копирование — после миграции. Из ai-02-embedding-index-migration:

[БЛОКЕР] unsafe_sequencing — задача=backfill_vectors
  "Операция обратного заполнения не может начаться, пока индекс не
  проверен на качество; она упорядочена неправильно."

План ставит обратное заполнение раньше проверки качества, которая должна его контролировать.

Слабый откат: 18 блокеров

Шаги с высоким радиусом поражения не имеют отката. Планировщик добавляет откат для рутинных шагов, но забывает о переключении, демонтаже и возврате. Пример из db-10-multi-tenant-split:

[БЛОКЕР] weak_rollback — задача=dual_write_setup
  "Откат задачи настройки двойной записи переключает только на
  одиночную запись, не устраняя возможные несоответствия во время
  перехода."

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

Почему увеличение модели не решает проблему

Естественная реакция — попробовать более мощную модель, например gpt-4o. Я тестировал её в двух вариантах: как планировщик с мини-критиком и в обеих ролях. Результат: те же дефекты, только более связный текст. Непроверенные зависимости, небезопасный порядок, слабый откат.

Это был момент, когда я перестал винить размер модели. Планировщик не был глупым. Он знал правильные шаги, но не мог замкнуть граф зависимостей и обеспечить порядок. Проблема была не в меньшей модели, а в структуре планирования.

Почему цикл ревизии не исправляет ситуацию

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

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

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

Решение: не параметры, а детерминированная проверка

Самый эффективный фикс — замыкатель предусловий: детерминированный линтер, который после черновика планировщика проверяет, что каждое предусловие установлено предыдущей задачей. Если задача требует replica_verified, должна быть предшествующая задача, которая это производит. Этот один проход устранил бы 64 из 132 блокеров (48%) без запроса к LLM стать умнее.

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

Что говорят исследования

Это не только моё наблюдение. Академическая литература сходится на том же выводе. Статья «Почему рассуждения не справляются с планированием» (arXiv 2601.22311) показывает, что LLM-агенты выбирают действия на основе локальной оценки, не учитывая будущие последствия. При обходах графа знаний жадные политики выбирают ловушки более чем в 55% случаев. Авторы доказывают, что пошаговые рассуждения недостаточны для долгосрочного планирования.

Обзор PlanGenLLMs (arXiv 2502.11221) оценивает LLM-планирование по четырём критериям: полнота, исполнимость, оптимальность, представление. LLM стабильно не обеспечивают исполнимость планов: предусловия не выполняются, шаги не в том порядке.

Поле сходится к гибридным подходам: LLM плюс детерминированная валидация плюс классические методы планирования. Не LLM в одиночку.

Практические выводы: что делать прямо сейчас

Если вы создаёте агентов, которые планируют несколько шагов, сделайте следующее:

• Тестируйте планировщик на реальном корпусе. Прогон на 157 целях выявил закономерность, которую не показали бы 3 демо-цели.
• Измеряйте типы дефектов, а не только pass/fail. Если все сбои в одной семье — у вас конкретный пробел.
• Не ждите, что большая модель исправит структурные проблемы. Пробел в планировании — это ограничение рассуждения, а не языковой способности.
• Добавьте детерминированную валидацию, прежде чем доверять LLM самокоррекции. Цикл ревизии полезен, но не замена структурным проверкам.

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