autoresearch
disclaimer, это моя интерпретация того что Karpathy называет autoresearch. я в то же время думал о схожей идее, но его setup был красиво сделан, поэтому много идей позаимствовал
в прошлом посте первый метод был про то, чтобы думать об LLM как о функции: на входе текст, на выходе структура. второй метод идёт дальше: не использовать LLM в приложении вообще, а брать её только для того, чтобы она написала вам код. в итоге у вас есть функция, у которой вы точно знаете вход и выход и можете проверить, насколько правильно она работает.
у Karpathy это устроено просто. агент выдвигает гипотезу, тестирует её за пять минут, смотрит что получилось и придумывает следующую. человека из цикла убирают, ибо он в нём самая медленная часть. у агента достаточно интеллекта, чтобы посмотреть на результаты и решить куда идти дальше. и это правда работает: с каждой итерацией результат растёт, хотя через какое-то время stagnates.
мой опыт
проект, над которым я работаю уже 3 года: надо по данным собрать модель здания, то есть понять, как в нём управляется отопление и охлаждение. AI системы, которые ставят поверх building management систем, требуют, чтобы пришёл человек и разметил, какой сенсор чему соответствует и что надо крутить, чтобы поменять температуру. в многоэтажке таких сенсоров бывает больше десяти тысяч, и раньше их размечали руками.
этим у нас занимался Bart. он открывал метаданные сенсоров и разбирал их по одной строке, а метаданные это открытые поля, куда при постройке здания писали кто что хотел. поэтому AI, который должен был лишить его работы, мы назвали Bartender.
собрать все ключевые слова нереально, слишком много способов сказать одно и то же. тем более они на голландском, на языке на котором еле говорю. на id опереться тоже не получается: единой схемы нумерации нет, в каждом здании нумеровали по-своему.
до этого задачу решали совсем иначе, через корреляции значений сенсоров. а потом мы попробовали пускать живого агента по метаданным, чтобы он собирал модель на ходу, и это просто не работало. иногда агент делает то, что ты хочешь, иногда нет. и сам промпт придумать сложно, потому что непонятно, по каким правилам он вообще должен разбирать эти строки.
и тут autoresearch всё сложил.
не надо пускать агента по метаданным в runtime, надо чтобы он написал алгоритм, который собирает модель здания.
пусть напишет кучу regex, оценит их, посмотрит где ошибся и попробует снова. я собрал это за один вечер.
агент начал итерировать regex, и модель стала собираться примерно наполовину, причём вторая половина была скорее угадана. потом он поставил сверху gradient boosting, и то, что раньше угадывалось, стало попадать почти каждый раз. это результат, которого я не ожидал. и подход по метаданным в итоге оказался в разы лучше, чем корреляции.
а по дороге он нашёл в id скрытый сигнал, о котором никто из нас не знал. id выглядели случайными, но сенсоры, которые ставили в одно устройство, получали номера рядом друг с другом, и близость по номеру оказалась хорошим признаком того, что они относятся к одному контуру. Bart, который размечал такие здания руками годами, тоже про это не знал.
как проводить autoresearch?
чтобы это сработало, задачу надо уметь изолировать и вытащить из проекта наружу. когда я вытащил свою, мне стало намного легче о ней думать, потому что перестали отвлекать ненужные детали. а главное, что после такой абстракции задачу можно поставить как написание одной функции: задаёшь агенту строгие типы, с которыми он работает, и говоришь улучшать эту функцию до предела.
весь код я держу в одном файле, чтобы агент видел его целиком, а запуск свёл к одной команде, которая гоняет eval и выдаёт цифры. и лучше завести под это новый repo, а не работать внутри рабочего проекта, потому что агент читает то, что уже написано, и начинает предлагать примерно то же самое вместо новых идей.
ещё важно, чтобы каждый результат был привязан к состоянию кода. поэтому eval сам делает git commit до прогона и после, а в json складывает commit hash вместе с метриками. любой результат после этого можно откатить и посмотреть, что там было.
heuristics
вообще подход очень напоминает то, как раньше ML задачи решали через hard-coded rule-based heuristics. со временем это стало уступать машинному обучению, где алгоритм сам находит закономерности. но агенту намного проще перебрать варианты и подобрать то, что работает лучше. более того, можно взять best of both worlds и разрешить ему поставить классический ML поверх этих heuristics, и так же перебрать, какой алгоритм и какие параметры подходят лучше.
в итоге агенты позволяют использовать решения, которые мы раньше просто не брали. не потому что они сложные, а потому что работа в них монотонная и повторяющаяся. разобрать десять тысяч строк, каждую по своим правилам, человек в принципе может, но у него на это уйдут годы. собственно, поэтому и был нужен Bart.
как позже сформулировал мой коллега,
это не обычный software engineering и не ML training, а что-то посередине, что стало возможным только сейчас. можно просто взять большую языковую модель и поставить её оптимизировать deterministic программу, чтобы она hill-climb какую-то задачу