Привет! Меня зовут Женя Андриевская. Я — NLP-инженер в лаборатории R&D red_mad_robot. Сегодня расскажу, как мы призвали на помощь эволюцию, чтобы улучшить качество данных в задачах классификации текстов. Да-да, ту самую эволюцию, с мутациями и скрещиваниями — только в мире данных, промптов и LLM.
Проблема: когда данных мало и синтетика не помогает
Перед нами стояла задача: обучить модель классифицировать тексты по нескольким категориям. Разметка была только на тестовом наборе, а для обучения требовалось много примеров. Первые шаги по очевидному пути — синтезу данных через LLM — не принесли результата. Сгенерированный датасет из открытых источников не помог: модель, обученная на нём, показывала F1-score заметно ниже ожидаемого.
Замена архитектуры и подбор гиперпараметров не принесли результата. Дело было в примерах, слишком отличавшихся от реальных текстов на тестировании. Переписывать промпты вручную, перебирая варианты для улучшения генерации — долго и не гарантирует успеха.
И тут мы вспомнили про генетический алгоритм. А что, если дать «эволюционировать» инструкциям, по которым генерируются данные? Пусть промпты меняются, мутируют и скрещиваются, а критерием качества будет итоговая метрика классификатора на фиксированном тесте. Так мы автоматически найдём промпт, который создаёт максимально полезные для задачи данные.
Как работает генетический алгоритм
Генетический алгоритм — это метод оптимизации, вдохновлённый биологической эволюцией. Представьте популяцию, где у каждой особи свой особый геном и место в общей иерархии, только в нашем случае это промпты с уникальными характеристиками и значениями fitness.
Процесс идёт циклами:
-
Отбор — выбираем лучших особей по fitness.
-
Скрещивание (кроссовер) — комбинируем геномы нескольких родителей, чтобы получить потомка.
-
Мутация — случайно изменяем геном потомка, чтобы внести разнообразие.
Поколение за поколением популяция эволюционирует в сторону более приспособленных особей. Нам остаётся только адаптировать эту схему под промпты.
Как мы построили эволюцию промптов
Особь хранит system-prompt, по которому LLM генерирует обучающие примеры. Если промпт удачный, он создаёт полезные примеры. Если данные полезные, модель на них учится лучше. Значит, fitness можно считать по качеству модели на внешнем тесте.
Это важный сдвиг: мы не пытаемся вручную чинить датасет, а ищем генератор датасета, который сам будет производить качественные примеры.
Ядро пайплайна
В основе системы — несколько базовых сущностей, через которые проходит весь эволюционный цикл.
Центральный объект — State. Это единый контейнер состояния эксперимента: текущая популяция, метрики, артефакты и история шагов. Благодаря тому, что State полностью сериализуется в JSON, любой прогресс можно сохранить и продолжить после падения.
Каждая особь популяции описывается объектом Individual. Он хранит id, genes, scores и дополнительные теги. При этом genes в ядре никак не ограничены доменной схемой: это может быть промпт, датасет или любая другая JSON-структура. Такой подход позволяет использовать один и тот же пайплайн для разных задач.
Эволюционные операции описываются через контракт Step — минимальную единицу работы пайплайна: мутацию, обучение, оценку или скрещивание. Каждый шаг получает предыдущий state и возвращает новый, а порядок их выполнения задаёт Pipeline, который хранит структуру процесса как последовательность шагов.
Оркестрацией занимается Runner. Он загружает конфигурацию, инициализирует State, последовательно запускает шаги и обновляет историю выполнения. Если происходит ошибка, Runner сохраняет failed-state и позволяет продолжить работу с последнего успешного шага.
Результаты: от промптов к датасету
Генетический алгоритм направленно улучшал промпты, но со временем мы упёрлись в плато. Тогда мы сменили объект эволюции: зафиксировали промпт и перешли к эволюции датасета. Мы начали постепенно перегенерировать только часть данных — от 2% до 5% на каждом цикле. Если на тесте был прирост F1 — оставляли этот вариант. В итоге метрики снова пошли вверх, а суммарный прирост составил около 10% по сравнению с исходным датасетом.
Этапы процесса
Процесс начинается с начальной популяции. В нашем случае всё стартовало с одного seed-промпта — исходной формулировки, от которой дальше разворачивалась вся эволюция.
На этапе мутации мы берём лучшую особь текущего поколения и с помощью той же LLM создаём на её основе несколько новых вариантов. Модель может перефразировать инструкцию, добавить детали или изменить стиль, сохраняя исходную задачу, но изменяя способ её постановки.
После этого все получившиеся варианты проходят оценку. Для каждого мутанта мы генерируем обучающие пары «текст + разметка», обучаем классификатор и проверяем его на тестовой выборке. Значение F1 в этом цикле и выступает в роли fitness-функции: чем выше метрика, тем сильнее особь.
При скрещивании сортируем особей по убыванию fitness, выбираем лучших родителей и просим LLM объединить их черты в один или несколько новых промптов-потомков. Эти потомки пополняют популяцию вместе с мутантами и становятся основой следующего поколения.
Дальше цикл повторяется заданное число раз или до тех пор, пока качество перестаёт заметно расти. Так, шаг за шагом, эволюционируют сами промпты, а вместе с ними улучшается качество данных и итоговой модели.
Второй рычаг: эволюция текстового шума
Синтетические тексты часто получаются слишком «чистыми». В реальности пользователи пишут с опечатками, используют сленг и забывают про пробелы и знаки препинания. Чтобы модель не жила в «лабораторных условиях», мы добавили ещё один контур генетического алгоритма — поиск лучшего «рецепта» аугментаций.
Мы собрали набор мутаций, которые имитируют реальный шум в текстах и позволяют аугментировать данные без LLM: опечатки при нажатии соседних клавиш, перестановку слов, удаление пробелов между словами и другие. Генетический алгоритм сам отбирал комбинации подобных мутаций и проверял, какие из них действительно помогают модели лучше справляться с реальными запросами.
На нескольких датасетах это дало прирост F1 на 0.025–0.035. Например, если baseline на тесте составлял 0.8095, лучший найденный вариант поднимал метрику до 0.8396. При этом неудачные комбинации аугментаций, наоборот, могли уронить результат ниже базового уровня.
Это ещё раз показывает — «рецепты» аугментации нельзя выбирать на глаз — их нужно подбирать и проверять.
Роль Claude Code агента
В эксперименте помог автоматический контур с агентом Claude Code. Он выступал в роли «лаборанта»: анализировал результаты цикла, предлагал гипотезы, менял параметры генетического алгоритма и запускал следующий прогон. По сути это был управляемый поиск по конфигурации эволюции на основе метрик, а не ручной тюнинг «на глаз».
Когда работает эволюционный подход
Этот метод — не «серебряная пуля». Он требует времени и вычислительных ресурсов. Но это воспроизводимая процедура поиска, которая заменила нам ручной подбор промптов и дала осмысленную генерацию данных.
Важно учитывать риск подстройки под тест. Если многократно выбирать лучшего кандидата по одному и тому же набору, модель может начать оптимизироваться именно под него. Поэтому финальную проверку лучше проводить на отдельном наборе данных.
Подход имеет смысл, если:
-
у вас есть внешний размеченный тест;
-
обучающих данных мало или их качество низкое;
-
данные можно синтезировать по инструкции.
Эволюция помогает превратить ручную настройку в измеримый процесс. Попробуйте — возможно, вашему проекту тоже пора немного «мутировать».
Если остались вопросы или хотите обсудить детали реализации — пишите в комментарии, с радостью ответим.
Над материалом работали:
Текст — Женя Андриевская
Редактура — Игорь Решетников
Иллюстрации — Саша Буяк
Это статья от команды R&D. Если интересно больше исследований, экспериментов и инженерных деталей — заглядывайте в наш канал: t.me/rmr_rnd
А в основном канале red_mad_robot — новости, анонсы и всё, что происходит вокруг компании: t.me/redmadnews
ссылка на оригинал статьи https://habr.com/ru/articles/1027238/