Подключить реальную задачу к EvoX — сложность вовсе не в том, чтобы «заменить оператор эволюции на более мощный», а в том, чтобы сначалаформализовать её как контракт: какие объекты допускается изменять (пространство поиска), какие результаты можно наблюдать (канал обратной связи) и какие изменения следует сохранять (критерий оценки). Эти три границы вместе определяют, сможет ли замкнуться эволюционный цикл, поэтому их нужно зафиксировать до запуска, а не постепенно прощупывать в процессе эволюции.
I. Граница изменяемых объектов: определение пространства поиска
Явно объявите переменные решения и их структуру (генотип), а также их отображение в реальные результаты (фенотип), одновременно отметив доступные только для чтения ограничения среды, данных, интерфейсов и аппаратного обеспечения. Слишком широкая граница приведёт к тому, что в поиск попадёт масса недопустимых кандидатов; слишком узкая — не оставит места для эволюции вовсе. Возьмём для примера конвейер обработки данных: изменять можно выбор операторов, порядок выполнения и гиперпараметры, тогда как структура входных данных и требования соответствия относятся к части «только для чтения».
II. Граница наблюдаемых результатов: настройка канала обратной связи
Каждый кандидат должен порождать сигнал, который способна зафиксировать программа. Нужно определить канал наблюдения, задержку, уровень шума и воспроизводимость. Измерения, которые невозможно наблюдать, не могут служить основой для оптимизации — только для посмертного объяснения. Включение ненаблюдаемых величин в функцию приспособленности лишь заставит эволюцию дрейфовать в сторону шума.
III. Критерии оценки и правила отбора: что достойно сохранения
Определите функцию приспособленности или вектор целей, ограничения и критерий допустимости, укажите, сводится ли всё к одному числу или сохраняется по принципу многокритериального Парето, а также пропишите, как наказывать, исправлять или досрочно останавливать кандидатов с ошибками, сбоями и тайм-аутами. Как только критерий оценки определён, фактически задано и то, в какую сторону будет сходиться эволюция.
IV. Такт оценки: параллелизм, стоимость и бюджет
Убедитесь, можно ли выполнять оценку пакетно или асинхронно, какова стоимость одной оценки и общий бюджет. Степень параллелизма и задержка одной оценки напрямую определяют такт эволюционного цикла и допустимое число поколений: последовательная оценка удлиняет цикл, и допустимое число поколений резко падает; пакетная или асинхронная оценка позволяет заметно ускорить итерации. Условия остановки и бюджет тоже нужно прописать чётко — задайте бюджет оценки, критерий сходимости и условия остановки, чтобы и не расходовать вычислительные ресурсы безгранично, и не прекращать слишком рано решение, которое ещё не сформировалось.
V. Достоверность оценки: остерегайтесь «метрику улучшили, а задачу не решили»
Следует опасаться трёх типов риска: расхождения прокси-метрики с реальной целью, утечки целевых данных и обратного использования оценщика кандидатами (накрутки баллов через уязвимости в оценке). Противоядие — независимая проверочная выборка или этап ручной проверки, а также стремление сделать процесс оценки по возможности без сохранения состояния и воспроизводимым, чтобы можно было воспроизводить сбои и объяснять результаты.
VI. Контракт подключения
В итоге оберните задачу в интерфейс, вызываемый из EvoX: на входе — один кандидат, на выходе — метрики и ограничения, при этом оценка должна быть по возможности без сохранения состояния и воспроизводимой. Стабилен контракт — стабилен и цикл. Если единственным критерием отбора сделать оценку на обучающей выборке, эволюция быстро переобучится под эту метрику — именно поэтому границу оценки нужно определять раньше границы поиска.
