Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Поиск программ с помощью LLM научился быстрее улучшать многокомпонентные конвейеры, если сохраняет связь между правкой и изменением метрик. В работе Santa Clara University, которая ещё не прошла рецензирование, а все числа получили сами авторы, новый подход достиг итогового качества сильнейшего базового метода примерно за треть бюджета. Для команд это повод менять не модель и не контроллер поиска, а формат памяти между итерациями.
Память связывает правку с изменением метрик
Обычный эволюционный поиск хранит программы и их итоговые оценки. Чтобы предложить следующую версию, LLM получает исходный код нескольких кандидатов и историю результатов, а затем сама пытается понять, какие функции изменились и почему оценка выросла или упала.
По мере роста программы эта задача усложняется. Одна мутация может затронуть получение кандидатов, повторное ранжирование и число обращений к модели. Общая оценка не показывает, какой компонент повлиял на качество, полноту или расход токенов.
Component-aware feedback добавляет после оценки программы отдельный шаг наблюдения. Система разбирает родительскую и дочернюю версии на именованные функции и константы уровня модуля, сравнивает их и записывает, какие компоненты добавили, удалили или изменили. Рядом сохраняется разница по каждой метрике, которую вернул оценщик.
Такая запись строится программно из исходного кода и уже выполненной оценки. Для неё не нужна ещё одна LLM, дополнительный прогон программы или текстовое объяснение, точность которого пришлось бы отдельно проверять.
Если одна мутация затронула несколько компонентов, память связывает результат со всем набором правок, но не разделяет вклад каждой из них. Это не точное причинное объяснение, а более структурированный след эксперимента, чем полный код рядом с одной итоговой оценкой.
Две точки отсчёта показывают шаг и направление
Каждую правку система сохраняет в локальном и глобальном представлении. Локальная запись сравнивает новую программу с её непосредственным родителем. Она отвечает на практический вопрос следующей итерации: помог ли последний шаг и какие показатели он сдвинул.
В запрос к модели попадают десять последних локальных записей. Поэтому контекст не превращается в длинную последовательность полных программ, которые модели пришлось бы заново сопоставлять между собой.
Глобальная запись сравнивает текущую программу с исходной. Её используют, когда поиск перестаёт улучшать результат и должен выбрать другую стратегию. Такая точка отсчёта позволяет сопоставить целые ветви поиска: какие компоненты накопились в каждой ветви и что они дали относительно общего начала.
Локальная и глобальная оценки могут расходиться. Последняя правка способна ухудшить сильного родителя, хотя вся ветвь всё ещё заметно превосходит исходную программу. Без двух представлений поиск рискует отказаться от перспективного направления после одного неудачного шага или, наоборот, продолжать серию мелких улучшений, которая не даёт общего прогресса.
Выигрыш проявился там, где цели конкурируют
Подход проверяли на всех 12 наборах Bright для поиска и повторного ранжирования документов. Один локально запускаемый Qwen использовали и для изменения программы, и внутри найденных конвейеров. Все методы начинали с одного исходного решения, получали одинаковый бюджет и работали с одним оценщиком; главным соперником был AdaEvolve с неизменённым контроллером поиска.
Итоговый nDCG@10 вырос на 7,2% относительно AdaEvolve. Эта метрика оценивает порядок документов и сильнее учитывает релевантные результаты ближе к началу первой десятки. Преимущество проявилось в большинстве наборов, а разброс между повторными запусками сократился.
Если поиск максимизировал только качество, он выбирал более дорогие конвейеры: расширение списка кандидатов улучшало ранжирование, но требовало дополнительных обращений к модели. Когда целевая функция одновременно учитывала качество и расход, найденные программы оказались точнее и использовали на 11% меньше токенов на запрос, чем результат AdaEvolve.
Для планов разработки важен не сам прирост на Bright, а место, где он возник. Подход подходит агентам, которые переписывают исполняемую программу, получают несколько метрик после каждого запуска и тратят основную часть бюджета на оценку кандидатов. В такой архитектуре стоит сохранять не только победившие версии, но и журнал вида «набор изменённых компонентов — сдвиг метрик».
Работа не показывает универсального ускорения для любой задачи. Помимо ранжирования метод проверили на упаковке окружностей и обработке сигнала: в задаче с одной итоговой оценкой он лишь сравнялся с AdaEvolve, а преимущество появилось при конфликтующих целях. Значит, перед перестройкой агента нужно проверить, можно ли выделить устойчивые компоненты программы и возвращает ли оценщик достаточно подробные показатели, чтобы такая память содержала больше информации, чем общий балл.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
