"Разработка с 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"