Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Сложные ИИ-системы можно улучшать точнее, если учитывать всю историю попыток и проверять правки в рабочем окружении до их сохранения. CoCoEvolve обошёл все методы сравнения в шести задачах обработки данных в работе, которая не прошла рецензирование и приводит замеры самих авторов. Для команд это переносит центр оптимизации с формулировки инструкций на устройство инструментов, архив экспериментов и проверочный контур.
Как история поиска становится рабочей памятью
При эволюционной оптимизации система хранит несколько вариантов инструкции, программы или конфигурации, оценивает их и выбирает один как основу для следующей правки. Обычно LLM видит этот вариант, его ошибки и за один вызов предлагает замену.
Такой подход работает, когда ошибка сразу указывает на исправление. В составной системе причина может находиться в другом месте: в схеме инструмента, запросе к данным, порядке вызовов или вычислении, которое LLM выполняет внутри контекста. Локальная правка тогда устраняет один сбой, но возвращает ошибку, уже исправленную в другой ветке поиска.
CoCoEvolve добавляет метарефлексию (meta-reflection): перед правкой агент получает краткий журнал последних стратегий и может запрашивать подробности из всего архива. Он находит вариант, который первым решил нужную задачу, смотрит внесённое тогда изменение и проверяет, какие задачи после него ломались вместе.
Архив не загружают целиком в контекст. CoCoEvolve сначала показывает Cortex Code сжатую сводку, а затем разрешает точечно запрашивать линии происхождения вариантов, результаты отдельных задач и связанные откаты. Это удерживает объём контекста в границах, но оставляет доступ к точной причине прежнего успеха.
Вторая часть метода — работа с целевой системой до фиксации правки. Агент запускает код, делает пробные запросы, разворачивает временную версию и проверяет гипотезу. Только после этого внешний цикл оценивает новый вариант и решает, сохранить ли его в архиве.
На DABStep прежний агент вычислял комиссии по одной транзакции, сделал для одного ответа 26 вызовов инструмента и поручил LLM сложить результаты. CoCoEvolve проверил запросы на живых данных и перенёс расчёт в пакетную процедуру, где арифметику выполняет детерминированный компонент. Это не редактура инструкции, а изменение архитектуры инструмента.
Где проверка среды дала преимущество
На сложной части отложенной выборки DABStep CoCoEvolve достиг точности 92,8% против 78,4% у Meta-Harness. GEPA, который менял прежде всего инструкции по локальным ошибкам, отстал ещё сильнее. Результат также поставили на первое место публичной таблицы DABStep, но на момент подачи владельцы бенчмарка не подтвердили его независимо.
На data-eng-bench доля решённых задач выросла до 77,4%, тогда как лучший метод сравнения достиг 73,6%. В конвейерах обработки данных с LLM CoCoEvolve выиграл на каждой проверенной нагрузке. Раздельные эксперименты показали, что вклад дают и журнал стратегий, и запросы к архиву, и самостоятельная проверка правки в окружении.
Метод проверяли на агентах DABStep, конвейерах обработки текста, процессах инженерии данных, HotpotQA, а также на математических и системных задачах. Финальные показатели считали на отложенных наборах; при поиске оптимизатор видел обучающие примеры и мог использовать оценки проверочной выборки, но не её содержимое. Методы сравнивали при одинаковых разбиениях и бюджетах там, где это было применимо.
Наибольшая разница проявилась в задачах, где отдельный сбой не раскрывает первопричину и поиск надолго останавливается. На стандартных задачах, для которых достаточно поправить один фрагмент программы или инструкции, CoCoEvolve оставался конкурентоспособным, но не получал столь же заметного преимущества.
Когда команде стоит менять контур оптимизации
Работа не предлагает новую базовую модель и не заменяет оценочный набор. CoCoEvolve — это контур вокруг модели, который хранит варианты системы, связывает их с результатами отдельных задач и даёт агенту безопасную среду для экспериментов. Поэтому внедрение затрагивает инфраструктуру разработки, а не только выбор LLM.
Если команда оптимизирует одну короткую инструкцию, а ошибки однозначны, переход на такой контур может не оправдать сложности. Одна правка по одному предшественнику требует меньше инструментов и не нуждается в подробной истории происхождения решений.
Планы стоит пересматривать, когда продукт состоит из инструкций, кода, схем данных и нескольких инструментов, а исправления регулярно вызывают откаты. В таком случае нужно сохранять не только итоговую оценку кандидата, но и вызовы инструментов, промежуточные результаты, ошибки выполнения и связь между версиями.
Второе изменение — проверочная среда должна стать частью оптимизатора. Агенту нужен доступ к запуску чернового кода, тестовым запросам и временным экземплярам системы до того, как новая версия попадёт во внешний цикл оценки. Без этого CoCoEvolve превращается в более сложный поиск по архиву и теряет возможность находить структурные исправления.
Третье изменение касается дорогих проверок. CoCoEvolve умеет выбирать задачи, которые похожи на ещё не решённые и могут дать больше информации о переносе исправления. Это позволяет не прогонять полный набор после каждой правки, хотя окончательный вариант всё равно требуется оценить целиком.
Практический вывод работы — историю экспериментов стоит проектировать как доступную агенту базу доказательств, а не как журнал для человека. Такой подход полезен там, где качество зависит от взаимодействия нескольких частей системы и локальная оптимизация инструкций уже вышла на плато.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
