Разработка с AI в декабре 2024. Выбор LLM (1/3)
Теперь поговорим про выбор LLM-моделей для разработки.
На текущий момент я сам активно пользуюсь такими моделями:
Рабочая лошадка - Claude 3.5 Sonnet (20241022), модель по умолчанию в Cursor у меня, 99% сгенеренного кода пишется именно ею.
Для обсуждения или решения чего-то сложного - ChatGPT o1:
* построение планов - с ней неплохо пообсуждать то, что предстоит делать в рамках проекта/задачи и в итоге получить развернутый и подробный план с брейкдауном;
* архитектура - обсудить верхнеуровневую структуру проекта, контракты между модулями, особенности имплементации, ограничения подходов и т.п.;
* нетривиальные задачи - те, в которых решение не лежит на поверхности и требуется "подумать", а не просто закодить. Как правило, это какие-то алгоритмы или базовая имплементация архитектуры.
В качестве справочника и замены поисковика - ChatGPT 4o, Gemini 2.0 Experimental.
На что обращать внимание при выборе моделей?
Бенчмарки для разработки
К ним можно по-разному относиться, но в целом, если мы говорим про разработку, то я бы больше смотрел на те, которые тестируют не способность модели что-то написать с нуля и за один раз, а способность корректно отредактировать существующий код, т.к. это куда чаще нужно делать в реальной работе.
Есть вот такие бенчмарки, которые это проверяют:
* SWE-bench
* Aider Polyglot
* Aider Refactoring
В конечном счете всегда нужно тестировать модели на ваших задачах.
Если есть время и возможности, то, конечно, составляйте свои бенчмарки или хотя бы чек-листы с любимыми типовыми задачами - так будет куда проще отделить хайп от рабочей необходимости, когда выходит какая-то новая модель :)
Длина контекста
Это, грубо говоря, сколько существующего кода модель может принять во внимание, чтобы делать на его основе выводы для его редактирования или написания нового.
Очень сильно влияет на то, с насколько большими проектами вам получится работать, т.к. если код всего проекта не влезает в контекст LLM - будут проблемы с тем, что модель что-то может нафантазировать и/или написать код, который не будет совместим с не влезшими частями проекта.
Есть техники в тулинге (Cursor, Aider, etc) по тому, чтобы "ужимать" код так, чтобы передавать в контекст его не в сыром виде, а его высокоуровневое представление - куски AST, к примеру, или передавать интерфейсы вместо конкретных реализаций, но это все равно чревато проблемами, т.к. часть информации теряется.
Также длинный контекст модели не всегда бывает "честным", т.к. контекст длиной N требует N^2 GPU RAM для обработки в наивной реализации трансформеров, и его довольно дорого поддерживать, так что применяются разного рода техники для оптимизации расходов памяти, которые могут ощутимо влиять на качество работы модели.
Есть тесты "поиска иголки в стоге сена", которые показывают то, насколько точно модели способны помнить и связывать информацию, находящуюся в разных местах контекста. Так вот на супердлинных контекстах особенно сильно проявляется падение метрик на этих тестах.
А нам нужна точность в разработке :)
#ai #work #development
Теперь поговорим про выбор LLM-моделей для разработки.
На текущий момент я сам активно пользуюсь такими моделями:
Рабочая лошадка - Claude 3.5 Sonnet (20241022), модель по умолчанию в Cursor у меня, 99% сгенеренного кода пишется именно ею.
Для обсуждения или решения чего-то сложного - ChatGPT o1:
* построение планов - с ней неплохо пообсуждать то, что предстоит делать в рамках проекта/задачи и в итоге получить развернутый и подробный план с брейкдауном;
* архитектура - обсудить верхнеуровневую структуру проекта, контракты между модулями, особенности имплементации, ограничения подходов и т.п.;
* нетривиальные задачи - те, в которых решение не лежит на поверхности и требуется "подумать", а не просто закодить. Как правило, это какие-то алгоритмы или базовая имплементация архитектуры.
В качестве справочника и замены поисковика - ChatGPT 4o, Gemini 2.0 Experimental.
На что обращать внимание при выборе моделей?
Бенчмарки для разработки
К ним можно по-разному относиться, но в целом, если мы говорим про разработку, то я бы больше смотрел на те, которые тестируют не способность модели что-то написать с нуля и за один раз, а способность корректно отредактировать существующий код, т.к. это куда чаще нужно делать в реальной работе.
Есть вот такие бенчмарки, которые это проверяют:
* SWE-bench
* Aider Polyglot
* Aider Refactoring
В конечном счете всегда нужно тестировать модели на ваших задачах.
Если есть время и возможности, то, конечно, составляйте свои бенчмарки или хотя бы чек-листы с любимыми типовыми задачами - так будет куда проще отделить хайп от рабочей необходимости, когда выходит какая-то новая модель :)
Длина контекста
Это, грубо говоря, сколько существующего кода модель может принять во внимание, чтобы делать на его основе выводы для его редактирования или написания нового.
Очень сильно влияет на то, с насколько большими проектами вам получится работать, т.к. если код всего проекта не влезает в контекст LLM - будут проблемы с тем, что модель что-то может нафантазировать и/или написать код, который не будет совместим с не влезшими частями проекта.
Есть техники в тулинге (Cursor, Aider, etc) по тому, чтобы "ужимать" код так, чтобы передавать в контекст его не в сыром виде, а его высокоуровневое представление - куски AST, к примеру, или передавать интерфейсы вместо конкретных реализаций, но это все равно чревато проблемами, т.к. часть информации теряется.
Также длинный контекст модели не всегда бывает "честным", т.к. контекст длиной N требует N^2 GPU RAM для обработки в наивной реализации трансформеров, и его довольно дорого поддерживать, так что применяются разного рода техники для оптимизации расходов памяти, которые могут ощутимо влиять на качество работы модели.
Есть тесты "поиска иголки в стоге сена", которые показывают то, насколько точно модели способны помнить и связывать информацию, находящуюся в разных местах контекста. Так вот на супердлинных контекстах особенно сильно проявляется падение метрик на этих тестах.
А нам нужна точность в разработке :)
#ai #work #development