Команда обучила агента на чужих партиях и заняла 436-е место в Kaggriculture

Новая версия агента заработала больше денег. Можно отправлять её пользователям? Пока рано: возможно, ей достался более выгодный рынок. Участники Kaggriculture столкнулись именно с этой проблемой. Они сравнивали версии на одинаковых партиях, а затем учили модель повторять решения сильных игроков. Такой порядок работы полезен разработчикам агентов: сначала нужен способ измерять изменения, затем можно выбирать архитектуру.

В опубликованном на Habr разборе команда сообщает о 436-м месте среди 10 148 команд и серебряной медали. За два месяца участники проверили шесть подходов — от правил до трансформера примерно на 20 млн параметров. Сильнейшей моделью, по их оценке, стал трансформер, обученный методом behavior cloning: по состоянию игры он учился выбирать действия из записанных партий.

Сначала отделили качество агента от удачного рынка

В Kaggriculture два агента управляют соседними фермами и продают продукцию на общий рынок. Через 30 игровых дней выигрывает тот, у кого больше денег. Если оба производят много молока, его цена падает. Если открывается магазин пряжи, появляется дополнительный спрос на шерсть. Производить больше недостаточно: нужно понимать, что удастся продать.

Набор магазинов случаен и сильно влияет на доход. В исследованной командой выборке на саму партию пришлось 88,8% дисперсии итоговой кассы. Это не означает, что случайность определяет 88,8% побед: показатель описывает разброс заработанных сумм.

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

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

Копировать примеры оказалось полезно, но ненадолго

Первый способ имитации обходился без обучения нейросети. Команда собрала 782 записи партий одного сильного игрока. Агент искал похожую ситуацию по расположению объектов, магазинам и недавним ценам, затем повторял действие из подходящей записи.

В начале игры это работало хорошо: дебюты часто повторялись. Позже состояния расходились, подходящих продолжений становилось меньше. При проверке в точных состояниях оригинального игрока копия повторяла его действия в 85% случаев в дни 6–14, а с 15-го дня — лишь в 2,5%.

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

Нейросети потребовались согласованные решения

Следующим шагом стал трансформер. Состояние фермы представили 197 токенами: клетки, работники, товары, рынок и другие сущности. Модель получала сведения об обеих фермах, а память между ходами помогала учитывать предыдущие наблюдения и действия.

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

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

Этот кейс даёт рабочую последовательность для экспериментов с агентами: собрать простой базовый вариант, подготовить повторяемые сценарии, проверить согласованность демонстраций и разобрать ошибки по этапам. Серебро в игровой симуляции не доказывает готовность метода к бизнес-задачам. Но описанные проверки помогают понять, почему очередное усложнение модели действительно сработало — или только выглядело убедительно.