AIRI

GigaEvo

Эволюционный фреймворк для автоматизации ML и LLM-ориентированных задач

Боков Алексей Александрович Волкова Ольга Алексеевна Глазков Никита Олегович Галичин Андрей Владимирович Трамбовецкий Игорь Евгениевич Беспалов Ярослав Радионович Хрульков Валентин Андреевич
Platform Core
En

Описание

GigaEvo — эволюционный фреймворк для автоматизации ML и LLM-ориентированных задач.

Фреймворк создан для автоматизации задач машинного обучения, включающих оптимизацию моделей, параметров, признаков и LLM-ориентированных методов. Решение минимизирует участие специалистов, ускоряет цикл экспериментов и повышает качество итоговых моделей.

Архитектура решения и эксплуатация

Архитектура реализует модульный эволюционный подход, в котором каждая программа — это уникально идентифицированная эволюционная единица, содержащая исходный код, состояние жизненного цикла, метрики, информацию о родословной и результаты выполнения. Все данные хранятся в слое Redis с поддержкой конкурентного доступа и отслеживания в реальном времени.

Исполнение программ организовано с помощью асинхронного фреймворка на основе направленного ациклического графа (DAG), реализованного в Python с использованием asyncio, что обеспечивает параллельное выполнение как между программами, так и внутри отдельных программных потоков.

Каждая стадия DAG выполняет самостоятельные операции:

  • Исполнение кода — выполнение программ
  • Валидация — проверка корректности результатов
  • Анализ сложности — оценка вычислительных характеристик
  • Вызовы LLM — интеграция с языковыми моделями

Стадии соединены через зависимости передачи данных и порядка выполнения. Планировщик управляет кэшированием и условным пропуском стадий.

Асинхронный эволюционный движок реализует алгоритм MAP-Elites, поддерживающий разнообразный архив высокоэффективных программ по показателям приспособленности и корректности, включая одно- и многоостровные конфигурации с периодической миграцией решений.

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

Управление конфигурацией и экспериментами выполняется с помощью Hydra, использующей иерархические YAML-файлы для воспроизводимости и быстрой настройки экспериментов.

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

Architecture

Система позволяет запустить несколько экспериментов благодаря одновременной работе нескольких экземпляров RunnerAPI, управляемых главным модулем под названием Master API. Получая запрос, управляющий сервис сохраняет все метаданные и датасет эксперимента для поддержки воспроизведения результатов.

GigaEvo реализует микросервисную архитектуру с тремя основными компонентами, которые работают совместно для обеспечения масштабируемого управления экспериментами машинного обучения:

  • Master API работает на порту 8000 и служит центральным сервисом оркестрации, отвечающим за координацию и управление экспериментами.
  • Множественные экземпляры Runner API работают на портах 8001 и далее, предоставляя распределенные сервисы выполнения задач, которые запускают фактические эксперименты.
  • WebUI работает на порту 7860, предлагая пользователям браузерный интерфейс для создания экспериментов и мониторинга их прогресса в реальном времени.

PostgreSQL служит основной базой данных для хранения конфигураций экспериментов и информации о статусе на протяжении их жизненного цикла. Она управляет метаданными экземпляров runner, включая статус здоровья и доступность, поддерживая комплексный реестр всех компонентов системы. База данных хранит полную историю выполнения задач для целей аудита и анализа производительности. Системные журналы аудита сохраняются для обеспечения полной прослеживаемости всех операций и изменений состояния.

Redis обеспечивает высокопроизводительное кэширование и возможности координации по всей системе. Он управляет очередями задач и координацией воркеров, обеспечивая эффективное распределение рабочих нагрузок и отслеживание статуса задач в реальном времени. Кэширование статуса в реальном времени обеспечивает быстрый доступ к информации о состоянии экспериментов и системы, в то время как управление сессиями поддерживает пользовательский контекст и состояние аутентификации. Временное хранение данных в Redis поддерживает промежуточные вычислительные результаты и временное состояние системы.

MinIO обеспечивает S3-совместимое объектное хранилище для всех файловых данных в системе. Входные файлы данных и наборы данных хранятся эффективно с метаданными для легкого извлечения и организации. Результаты экспериментов и генерируемые артефакты сохраняются с комплексной индексацией для будущего анализа. Генерируемые визуализации и графики хранятся в стандартных форматах, доступных через WebUI, в то время как контрольные точки моделей и выходные данные обучения поддерживают воспроизводимость экспериментов и обеспечивают дальнейший анализ.

Локальная файловая система обеспечивает временное хранение рабочих данных во время выполнения эксперимента. Клоны репозитория GigaEvolve поддерживаются локально для быстрого доступа и для поддержки контролируемых версиями сред экспериментов. Временные файлы экспериментов создаются и управляются во время выполнения, предоставляя рабочее пространство для промежуточных вычислений. Локальные вычислительные результаты кэшируются для снижения сетевого трафика и улучшения производительности для часто запрашиваемых данных.

Параллельное выполнение с несколькими Runner

Master API автоматически развертывает и управляет экземплярами Runner API в качестве Docker-контейнеров, обеспечивая бесшовное масштабирование. Каждый экземпляр Runner работает независимо с собственным выделенным набором рабочих процессов, обеспечивая изоляцию и управление ресурсами. Новые экземпляры могут быть добавлены динамически через изменения конфигурации без необходимости перезапуска системы, что позволяет гибко масштабироваться в зависимости от спроса.

Пример конфигурации runner:

runner_config:
max_workers_per_instance: 5  # Воркеры на экземпляр runner
auto_initialize: true        # Автоматическое развертывание контейнеров
instances:
    local:
        host: "runner-api-1"
        is_local: true
    remote-1:
        host: "remote-server.example.com"
        is_local: false
    remote-2:
        host: "another-server.example.com"
        is_local: false

Master API отслеживает информацию о статусе в реальном времени для всех экземпляров Runner, обеспечивая интеллектуальное назначение экспериментов. Эксперименты автоматически назначаются доступным экземплярам с достаточной ёмкостью, обеспечивая оптимальное использование ресурсов. Алгоритм балансировки нагрузки учитывает текущую рабочую нагрузку и статус здоровья экземпляра при принятии решений о назначении. Неисправные экземпляры автоматически обнаруживаются и удаляются из активной ротации, поддерживая надёжность системы.

Система реализует непрерывные проверки здоровья каждые 30 секунд для мониторинга статуса всех экземпляров Runner. Механизмы автоматического восстановления экземпляров запускаются при обнаружении сбоев, минимизируя время простоя и обеспечивая доступность системы. Поддерживается синхронизация статуса в реальном времени между Docker-контейнерами и базой данных, предоставляя точную и актуальную информацию о состоянии системы.

Каждый экземпляр Runner API может выполнять несколько экспериментов одновременно, обеспечивая горизонтальное масштабирование. Количество воркеров на экземпляр настраивается, со значением по умолчанию в пять воркеров, которое может быть скорректировано на основе доступных ресурсов и требований рабочей нагрузки. Воркеры независимо опрашивают глобальную очередь задач, что обеспечивает оптимальное распределение нагрузки по всем доступным ресурсам в системе.

Мониторинг

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

Преимущества GigaEvo

Benefits

Возможности

Фреймворк GigaEvo — обеспечивает полный автоматизированный цикл ML-экспериментирования — от загрузки данных до получения оптимального решения — используя эволюционный поиск стратегий обучения с LLM-мутациями и строгой валидацией. Платформа предлагает удобную визуализацию прогресса в реальном времени, значительно сокращает ручные трудозатраты: пользователь формулирует цель и предоставляет данные, а система выполняет все этапы автоматически. GigaEvo легко интегрируется с корпоративной инфраструктурой через Master API и S3/MinIO, масштабируется за счёт распределённых Runner-инстансов, очередей задач и изолированных рабочих пространств, а также поддерживает экспорт результатов в JSON, предоставляет оптимальную программу с метаданными и сохраняет артефакты в S3.

  • Автоматизация полного цикла: GigaEvo обеспечивает автоматизацию полного цикла ML-экспериментов — от загрузки данных до получения оптимального решения, включая автоматическую эволюцию стратегий обучения, при которой система самостоятельно находит и улучшает наиболее результативные подходы.
  • Визуализация и контроль: Платформа предоставляет визуализацию и контроль прогресса в реальном времени, минимизирует влияние человеческого фактора — разработчик формулирует задачу, а система полностью берет на себя процесс экспериментов.
  • Интеграция и масштабируемость: Решение интегрируется с существующими AutoML- и MLOps-платформами, поддерживает простое развёртывание и масштабирование в облачных и корпоративных средах, а также обеспечивает бесшовное подключение к инфраструктуре организации через модуль MasterAPI.

Решение эффективно применяется в широком спектре задач, где требуется быстрое и качественное создание, тестирование и улучшение моделей машинного обучения. В центрах разработки и лабораториях Data Science оно автоматизирует цикл экспериментов и сокращает время исследований; в аналитических и прогнозных подразделениях ускоряет построение моделей и повышает точность прогнозов; на платформах тестирования гипотез обеспечивает оперативную проверку научных и бизнес-предположений; а в корпоративных системах поддержки принятия решений служит основой для интеллектуальных модулей, улучшающих управленческие процессы. GigaEvo легко масштабируется и одинаково эффективно подходит как для научных задач, так и для прикладных решений в бизнесе, промышленности и финансовой сфере.

API предоставляет REST-интерфейс для интеграции GigaEvo с внешними корпоративными системами. Через него доступны операции по созданию экспериментов — регистрация конфигурации, данных и метаданных — а также запуск, остановка и получение актуального статуса. API поддерживает просмотр списка и истории экспериментов, а также публикацию событий в Kafka (получение конфигурации, подготовка, запуск, остановка).

Runner API предназначен для непосредственного управления выполнением экспериментов: инициализации, запуска и остановки процессов, получения статусов и логов, формирования визуализации, выдачи лучшей программы (код, фитнес, метаданные) и работы с загруженными артефактами, включая сканирование S3-префиксов. Полный перечень доступных эндпоинтов приведён в docs/api_endpoints.md.

GigaEvoML особенно хорошо подходит для рабочих процессов машинного обучения, которые выигрывают от параллельного выполнения и масштабируемого экспериментирования. Команды разработки ML-моделей могут использовать систему для параллельного обучения и оценки нескольких моделей одновременно, драматически сокращая время разработки. Оптимизация гиперпараметров становится более эффективной через одновременное выполнение экспериментов по различным конфигурациям параметров. Сценарии A/B-тестирования выигрывают от параллельного сравнения различных конфигураций моделей в идентичных условиях. Исследовательские рабочие процессы в академии и отделах R&D могут использовать масштабируемое выполнение экспериментов для крупномасштабных исследовательских проектов ML, которые были бы непрактичны при последовательном выполнении.

Система служит различным отраслям со специфическими потребностями в машинном обучении. Организации финансовых услуг используют GigaEvoML для разработки и валидации моделей рисков, обеспечивая быструю итерацию на сложных финансовых моделях. Медицинские организации используют платформу для разработки и тестирования медицинских ML-моделей, поддерживая разработку диагностических систем и систем оптимизации лечения. Компании электронной коммерции выигрывают от оптимизации систем рекомендаций через параллельное экспериментирование с различными алгоритмами и параметрами. Производственные организации используют систему для разработки моделей прогнозного обслуживания, обеспечивая создание систем, которые предвидят сбои оборудования и оптимизируют графики технического обслуживания.

Пример проекта на GigaEvo

Создаём эксперимент

Create Experiment UI
  1. Введите название и краткое описание цели эксперимента.
  2. Загрузите датасет.
  3. Выберите тип задачи (classification, regression или clustering), укажите целевые метрики и параметры (для supervised-задач — целевой столбец).
  4. Настройте дополнительные параметры — количество поколений, тип LLM-модели и другие опции.
  5. Создайте эксперимент по кнопке Create Experiment — система автоматически присвоит ему идентификатор формата.
  6. Можете выбрать шаблонный эксперимент из списка — система автоматически заполнит необходимые поля и загрузит данные, останется только запустить.

Запускаем эксперимент

Start Experiment UI
  1. Во вкладке «Эксперименты» ознакомьтесь со списком доступных экспериментов и их статусами (PENDING, INITIALIZED, RUNNING, COMPLETED и др.).
  2. При необходимости обновите список по кнопке Refresh.
  3. Выберите эксперимент из списка.
  4. Запустите процесс эволюции по кнопке Start.
  5. При необходимости остановите эксперимент заранее по кнопке Stop.
  6. Можете удалить все текущие эксперименты по кнопке Drop All Experiments, если нужно очистить список.

Отслеживаем эксперимент

Track Experiment UI
  1. Выберите эксперимент из списка доступных — данные загрузятся автоматически.
  2. Отслеживайте ключевые метрики эволюции (лучшая метрика, лучшее поколение, количество итераций и программ) — значения обновляются в реальном времени.
  3. Просматривайте график динамики эволюции — он обновляется автоматически.
  4. При необходимости нажмите кнопку Refresh results, чтобы обновить данные вручную.

Смотрим результаты эксперимента

Experiment Result UI
  1. Выберите эксперимент из списка.
  2. Ознакомьтесь с текущей лучшей программой — она отображается в реальном времени.
  3. Скачайте архив с лучшей программой и кодом модели, использованной для тестирования.
  4. При необходимости нажмите кнопку Refresh results, чтобы обновить результаты вручную.

Отслеживаем статус RunnerAPI

Runner Experiment UI

В данном разделе можно отслеживать состояние всех запущенных RunnerAPI-воркеров. Пользователю доступны:

  • Список инстансов RunnerAPI с их статусом, endpoint, последним heartbeat и текущим выполняемым экспериментом;
  • Базовые операции управления: Initialize, Stop, Restart;
  • Просмотр логов каждого инстанса и сводки его здоровья;
  • API-эндпоинты master-api для получения списка инстансов, деталей, логов и общей health-сводки;
  • Прямые health-checks RunnerAPI (/health) и запрос статуса выполнения эксперимента на конкретном Runner (/api/v1/experiments/{id}/status).

Отслеживаем статус системы

Monitoring UI

Раздел мониторинга отображает текущее состояние всех компонентов GigaEvo: от API до фоновых воркеров. Пользователю доступны:

  • health-check эндпоинты (/health) сервисов master-api, runner-api, web-ui;
  • журналы фоновых задач и экспериментов;
  • состояние очередей и статусов задач в Redis;
  • проверки доступности S3-хранилища и базы данных.

Используем результаты эксперимента

Experiment Result Usage UI
  1. Загрузите эксперимент, запустите эволюцию и дождитесь получения лучшего решения по метрикам.
  2. Выгрузите результаты эксперимента вместе с кодом для feature engineering и примером обучения модели.
  3. Объедините полученные скрипты с необходимыми библиотеками и встройте их в свои рабочие процессы.

Установка фреймворка

Быстрый старт

см. также README.md

  • Требования: Docker, Docker Compose, Python 3.12+ (для локальной разработки), uv или pip.
  • Запуск всего стека:
make deploy
# или
./deploy.sh deploy
  • Отдельно инфраструктура:
make deploy-infrastructure
  • Отдельно приложения:
make deploy-applications

Сервисы и порты (см. docker-compose.yml):

  • postgres (5432), redis (6379), minio (9000/9001)
  • master-api (8000), runner-api (8001), web-ui (7860)

Проверка здоровья:

  • http://localhost:8000/health
  • http://localhost:8001/health
  • http://localhost:7860

1. Установка Эволюционного Ядра GigaEvo

Установка Эволюционного Ядра GigaEvo -- установка Python-пакета с полным набором зависимостей: Redis-клиент, интеграция с локальными/удаленными LLM, реализация основных компонентов пайплайна, инструменты анализа (pandas/matplotlib).

Необходимые зависимости для работы с GigaEvo включают в себя:

  • Базовые библиотеки: Redis-клиент, Hydra для управления конфигурацией
  • Интеграция с LLM: OpenAI/OpenRouter API клиенты, LangChain для работы с LLM, утилиты для форматирования промптов
  • Компоненты эволюции: реализация MAP-Elites, движок выполнения DAG, автоматический пайплайн оценки программ
  • Инструменты анализа: Pandas для экспорта данных, Matplotlib/Seaborn для визуализации

Пример выполнения:

pip install -e .

После установки проверьте настройку, убедившись, что gigaevo можно импортировать: python -c "import gigaevo; print('OK')". Запуск экспериментов производится из корня репозитория.

Подробнее: См. раздел "Quick Start" в README.md

2. Настройка Redis

Redis -- централизованная база данных для системы эволюции, хранящая состояния программ (FRESH → PROCESSING_STARTED → PROCESSING_COMPLETED → EVOLVING), метаданные и результаты выполнения. Поддерживает безопасную координацию между движком эволюции и графом выполнения через атомарные операции, сохраняет прогресс для возможности восстановления. Содержит независимые базы данных — каждый новый запуск должен использовать отдельную БД, которая задается через параметр redis.db=N.

Redis служит централизованной базой данных для всей системы эволюции. Он хранит:

  • Состояние программ: Все программы проходят через состояния (FRESH → PROCESSING_STARTED → PROCESSING_COMPLETED → EVOLVING)
  • Архивы островов: Каждый эволюционный остров хранит свою MAP-Elites сетку в Redis с программами, индексированными в зависимости от качества и других метаданных
  • Метаданные: Номера поколений, качество программ, дополнительные метрики, результаты выполнения
  • Индексы состояний: Эффективный поиск по состоянию с использованием ключей вида state:FRESH:* для программ, ожидающих оценки

Множественные базы данных: Redis поддерживает до 16 независимых баз данных (индексы 0-15). Каждый эксперимент должен использовать свою БД для изоляции данных. Указывайте номер через параметр redis.db=N при запуске эволюции. Это позволяет запускать параллельные эксперименты без конфликтов и сохранять результаты разных запусков для последующего сравнения.

Пример выполнения:


# Запустите Redis-сервер 
redis-server

Redis должен работать на протяжении всего процесса эволюции. При прерывании эволюция может возобновиться с последнего сохраненного состояния, так как весь прогресс сохранен в Redis.

Устранение проблем:

  • Если база данных не пуста: отчистите БД: redis-cli -n 0 FLUSHDB; или используйте другую БД: python run.py redis.db=1
  • Connection refused: Убедитесь, что Redis запущен на порту 6379 по умолчанию

Подробнее: См. разделы "Quick Start" и "Troubleshooting" в README.md для управления состоянием Redis

3. Создание задачи для эволюции

Создание задачи -- каждая задача для эволюции задается через директорию в problems/<название_задачи>/. Директория должна содержать:

  • task_description.txt: описание задачи для LLM
  • metrics.yaml: спецификация целевой метрики и дополнительных
  • validate.py: логика подсчета метрик для новой программы
  • initial_programs/: начальные программы эволюции
  • helper.py (опционально): вспомогательные функции для программ
  • context.py (опционально): дополнительный контекст на вход для программ

Структура директории задачи: Каждая задача в problems/<название_задачи>/ требует:

  • task_description.txt: Описание задачи, показываемое LLM во время мутаций (генераций новых программ) для понимания контекста и целей задачи
  • metrics.yaml: Определяет конфигурацию целевых и вспомогательных метрик с границами, точностью и размерностями их поведенческого пространства. Ровно одна метрика должна быть целевой и иметь is_primary: true флаг
  • validate.py: Реализует логику валидации, возвращающую словарь со всеми метриками из metrics.yaml и is_valid: 1/0 (валидна программа или нет)
  • initial_programs/: Директория с Python-файлами, каждая из которых содержит функцию entrypoint() с начальной программой. Они формируют начальную популяцию для эволюции
  • helper.py (опционально): Вспомогательные функции для программ
  • context.py (опционально): Дополнительный контекст на вход для программ

Методы создания:

  • Визард (рекомендуется): Создайте директорию при помощи специального визарда (tools/wizard.py):
    1. Создайте и заполните для задачи YAML-конфиг в tools/config/wizard/ (См. tools/config/wizard/heilbron.yaml для примера)
      • YAML файл описывает задачу декларативно: название, описание задачи, список метрик с границами и типом, параметры валидации, сигнатуру программы для эволюции, а также список начальных программ.
      • Визард генерирует все необходимые файлы с TODO-комментариями.
    2. Запустите создание директории задачи через python -m tools.wizard tools/config/wizard/my_config.yaml. От пользователя требуется реализовать:
      • Логику подсчета метрик в validate.py
      • Код начальных программ в initial_programs/*.py
  • Вручную: Создайте и заполните директорию и файлы самостоятельно. См. problems/heilbron/ для полного рабочего примера.

Оба подхода создают идентичные структуры — визард автоматизирует создание однотипных программ и гарантирует консистентность.

Методы создания:

Вариант A: Использование визарда (рекомендуется)

# Генерация из существующего конфига
python -m tools.wizard heilbron.yaml

# Или создание пользовательского конфига (см. tools/README.md для формата)
python -m tools.wizard my_problem.yaml

Сгенерированная структура:


problems/my_problem/
├── validate.py              # TODO: Реализовать оценку приспособленности
├── metrics.yaml             # Спецификация метрик
├── task_description.txt     # Описание задачи
└── initial_programs/
    └── strategy1.py         # TODO: Реализовать функцию entrypoint()
Вариант B: Создание вручную

mkdir -p problems/my_problem/initial_programs
# Создайте validate.py, metrics.yaml, task_description.txt, initial_programs/*.py
# Следуйте структуре, описанной выше, и используйте problems/heilbron/ в качестве примера

Подробнее: См. раздел "Advanced Usage" (подразделы "Generate Problem with Wizard" и "Create Your Own Problem Manually") в README.md, а также tools/README.md для формата YAML-конфига визарда

4. Запуск эволюции

Запуск эволюции -- итеративный процесс оптимизации: загрузка начальных программ → оценка через DAG-пайплайн → выбор лучших решений → мутация с помощью LLM → повторение для нескольких поколений. Пайплайн использует Hydra для модульного управления конфигурацией эволюции с подготовленными шаблонами. Результаты логируются в outputs/, в то время как данные хранятся в Redis БД.

Запуск эволюции производится через задание yaml конфигов в config/ директории. Пайплайн использует Hydra для модульного управления конфигами. Все настройки в директории config/ можно компоновать и переопределять. Конфиги экспериментов (config/experiment/) предоставляют предварительно настроенные шаблоны для эволюции.

Доступные эксперименты:

  • base - Эволюция на одном острове (по умолчанию)
  • multi_island_complexity - Два острова: производительность + простота
  • multi_llm_exploration - Несколько LLM для разнообразных мутаций
  • full_featured - Multi-island + multi-LLM вместе

Примеры других параметров для переопределения:

  • max_generations=N - Количество итераций эволюции
  • temperature=0.0-2.0 - Креативность LLM (выше = более креативно)
  • redis.db=N - Номер базы данных Redis (полезно для параллельных запусков)
  • model_name=anthropic/claude-3.5-sonnet - Конкретная LLM-модель

Финальные результаты логируются в outputs/YYYY-MM-DD/HH-MM-SS/, все данные программ хранятся в Redis БД.

Пример выполнения:


# Базовый запуск
python run.py problem.name=heilbron

# С выбором эксперимента
python run.py problem.name=heilbron experiment=multi_island_complexity

# С переопределением параметров
python run.py problem.name=heilbron max_generations=50 temperature=0.8 redis.db=5

Подробнее: См. разделы "Customization" и "Configuration" в README.md для всех доступных параметров и экспериментов

5. Анализ результатов

Анализ результатов -- набор инструментов для экспорта и визуализации данных эволюции. Содержится в директории tools/. redis2pd.py извлекает программы из Redis в CSV-формат с метриками и метаданными для анализа в pandas/Excel; comparison.py создает график процесса эволюции целевой метрики одного или нескольких экспериментов в PNG формате. Работают напрямую с Redis БД, требуют совпадения параметров redis.db и problem.name с запуском эволюции(й).

  • Экспорт в CSV (redis2pd.py): Извлекает все данные программ из Redis, включая целевую метрику, дополнительные метрики, номера поколений и метаданные. Выводит плоский CSV-файл с одной строкой на оцененную программу, готовый для анализа в pandas, Excel или статистических инструментах. Должен совпадать с redis.db и названием задачи (префиксом) из вашего запуска эволюции.
  • Сравнение запусков (comparison.py): Генерирует график, сравнивающий эволюции целевой метрики в одном или нескольких экспериментах в PNG формате. Показывает скользящее среднее и стандартное отклонения для иллюстрации трендов сходимости. Полезно для сравнения различных конфигураций экспериментов (base vs multi-island), LLM-моделей или гиперпараметров.

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

Пример использования:

  • Экспорт в CSV-формат

# Экспорт одного запуска (соответствует redis.db и problem.name из run.py)
python tools/redis2pd.py \
--redis-db 0 \
--redis-prefix "heilbron" \
--output-file results/results.csv
  • Визуализация эволюции целевой метрики одного или нескольких запусков (PNG)

# Запустите несколько экспериментов с разными номерами БД
python run.py problem.name=test redis.db=10 experiment=base
python run.py problem.name=test redis.db=11 experiment=multi_island_complexity
python run.py problem.name=test redis.db=12 experiment=full_featured

# Сравните с графиками
python tools/comparison.py \
--annotate-frontier \
--run "test@10:Baseline" \
--run "test@11:Multi_Island" \
--run "test@12:Full_Featured" \
--smooth-window 10 \
--iteration-rolling-window 10 \
--output-folder results/comparison

Подробнее: См. tools/README.md для полной документации по инструментам анализа и визуализации

Эволюция промптов для языковых моделей

(скоро - декабрь 2025)

GigaEvo получит функцию автоматического улучшения промптов для работы с языковыми моделями.

Вам нужно будет:

  1. Создать начальный промпт с переменными для входных данных
  2. Загрузить примеры данных с правильными ответами
  3. Выбрать критерии оценки качества ответов

Система автоматически извлечёт нужную часть из ответа языковой модели и оценит его качество в соответствии с вашей задачей.

Метод работает для любых LLM-ориентированных задач с проверяемыми результатами, например:

  • Классификация текстов — настройка промптов для сортировки документов по категориям
  • Извлечение информации — улучшение промптов для выделения ключевых данных из текста
  • Этапы многошаговых агенты — оптимизация промптов для сложных систем с несколькими этапами работы

Вы сможете выбрать удобный формат проверки вывода LLM:

  • Структурированные форматы (JSON, XML)
  • Регулярные выражения
  • Сравнение похожести текстов
  • Оценка другой языковой моделью (LLM-as-a-judge)
  • Свои собственные метрики на Python

Функция находится в разработке.

Смотрите дорожную карту проекта и следите за обновлениями!

Дорожная карта

Roadmap

Команда

Auto 1
Боков Алексей Александрович

Инженер-исследователь

AIRI

Auto 1
Волкова Ольга Алексеевна

Младший научный сотрудник

AIRI

Auto 1
Глазков Никита Олегович

Младший научный сотрудник

AIRI

Auto 1
Галичин Андрей Владимирович

Младший научный сотрудник

AIRI

Auto 1
Хрульков Валентин Андреевич

Ведущий научный сотрудник, руководитель группы "Генеративное проектирование"

AIRI

Auto 1
Трамбовецкий Игорь Евгениевич

Системный аналитик

AIRI

Auto 1
Беспалов Ярослав Радионович

Научный сотрудник, руководитель группы "Мультимодальные архитектуры ИИ"

AIRI