Разработка с AI в начале 2025. Выбор 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