Разработка с AI в начале 2025. Ограничения и решения (1/2)
Нет инструментов без своих минусов, так что в этой, финальной части, обсудим текущие проблемы и ограничения, которые чаще всего встречаются в AI-разработке, а также способы их обойти или решить.
Ограниченность длины контекста
Проявляется в том, что не весь ваш код и документация могут быть "осознаны" и учтены, так что в ответ модель запросто может начать фантазировать о тех частях проекта, которые она "не видит", забывать тот код, который сама же написала и терять логические связи между разными участками кода.
Последнее особенно ярко заметно на очень длинных контекстах, которые не являются "честными" (см. прошлый пост с подробностями).
Что делать?
* не пытаться засунуть в контекст сразу весь проект, если размер контекста этого не позволяет;
* дробить проект на модули и разрабатывать их по отдельности - это в целом полезная практика;
* иметь четко прописанные контракты между модулями (Swagger/OpenAPI, JSON Schema, интерфейсы в коде и т.п.), которые нужно класть в контекст; а также полезно иметь интеграционные тесты.
Слишком длинные чаты
Если вы пишете код в том же Cursor (и даже если почему-то до сих пор в веб-интерфейсе ChatGPT), вы наверняка сталкивались с тем, что спустя некоторое время модель начинает путаться в показаниях и отвечать все хуже и хуже, а иногда даже удалять нужный код.
Это, во-первых, может быть связано с тем, что весь ваш чат перестал влезать в контекст, а во-вторых, если вы переиспользуете один и тот же чат для разных задач, то происходит замусоривание контекста и модель может начать пытаться связать между собой какие-то не относящиеся друг к другу факты, попавшие в этот контекст.
Что делать?
* по-хорошему, один чат в Cursor Chat - один мелкий фикс или серия фиксов связанного функционала;
* в Cursor Composer - один чат на фичу / большое изменение;
* если чат даже по одной фиче стал слишком большим - просите модель описать те изменения, которые были сделаны в рамках этого чата, идите с этим описанием в новый чат и продолжайте работу там.
Устаревший код
Нередко бывает, что для какой-то либы LLM предлагает поставить её старую версию и/или пишет код для старой версии.
Тут дело в том, что у каждой LLM есть knowledge cutoff date - та дата, которой ограничен собранный для нее датасет.
Ну т.е. для тренировки условной ChatGPT 4o данные могли собрать из Интернета еще года полтора назад, потом полгода ее на этих данных учили, выпустили, а мы до сих пор ей пользуемся. Добросить в неё новые знания - вычислительно и финансово весьма накладно, так что модели не так часто обновляются.
Что делать?
* если документация не очень большая (помним про размер контекста), можно прям целиком её копипастнуть в чат с LLM или, что удобнее, дать ссылку на страницу документации в том же Cursor Composer - он сам ее скачает, распарсит и положит в контекст для модели;
* попробовать использовать символ @Web в Cursor - он запускает поиск релевантной вашему сообщению инфы в сети и потом включает результаты поиска в текущий контекст;
* переключиться на модель поновее - как правило, у недавно вышедших моделей cutoff date позднее и знания более актуальные;
* не использовать самые новые версии библиотек :) Не, ну кроме шуток - это нередко себя оправдывает.
К примеру, Angular и в прошлом году уже был достаточен для подавляющего большинства проектов, и большого профита от его свежего релиза скорее всего не получить, а вот бороться с LLM придется.
Конечно, нужно выбирать те версии, которые не совсем заброшены и хотя бы всё ещё получают обновления безопасности.
Языки программирования тоже лучше выбирать как можно более массовые и стабильные, по тем же причинам.
В особо тяжелых случаях модель вообще может не знать конкретного языка / фреймворка или иметь очень мало по нему данных для того, чтобы писать рабочий код.
В этом случае придётся либо все-таки писать код самому, либо креативно сочетать подходы выше.
#ai #work #development
Нет инструментов без своих минусов, так что в этой, финальной части, обсудим текущие проблемы и ограничения, которые чаще всего встречаются в AI-разработке, а также способы их обойти или решить.
Ограниченность длины контекста
Проявляется в том, что не весь ваш код и документация могут быть "осознаны" и учтены, так что в ответ модель запросто может начать фантазировать о тех частях проекта, которые она "не видит", забывать тот код, который сама же написала и терять логические связи между разными участками кода.
Последнее особенно ярко заметно на очень длинных контекстах, которые не являются "честными" (см. прошлый пост с подробностями).
Что делать?
* не пытаться засунуть в контекст сразу весь проект, если размер контекста этого не позволяет;
* дробить проект на модули и разрабатывать их по отдельности - это в целом полезная практика;
* иметь четко прописанные контракты между модулями (Swagger/OpenAPI, JSON Schema, интерфейсы в коде и т.п.), которые нужно класть в контекст; а также полезно иметь интеграционные тесты.
Слишком длинные чаты
Если вы пишете код в том же Cursor (и даже если почему-то до сих пор в веб-интерфейсе ChatGPT), вы наверняка сталкивались с тем, что спустя некоторое время модель начинает путаться в показаниях и отвечать все хуже и хуже, а иногда даже удалять нужный код.
Это, во-первых, может быть связано с тем, что весь ваш чат перестал влезать в контекст, а во-вторых, если вы переиспользуете один и тот же чат для разных задач, то происходит замусоривание контекста и модель может начать пытаться связать между собой какие-то не относящиеся друг к другу факты, попавшие в этот контекст.
Что делать?
* по-хорошему, один чат в Cursor Chat - один мелкий фикс или серия фиксов связанного функционала;
* в Cursor Composer - один чат на фичу / большое изменение;
* если чат даже по одной фиче стал слишком большим - просите модель описать те изменения, которые были сделаны в рамках этого чата, идите с этим описанием в новый чат и продолжайте работу там.
Устаревший код
Нередко бывает, что для какой-то либы LLM предлагает поставить её старую версию и/или пишет код для старой версии.
Тут дело в том, что у каждой LLM есть knowledge cutoff date - та дата, которой ограничен собранный для нее датасет.
Ну т.е. для тренировки условной ChatGPT 4o данные могли собрать из Интернета еще года полтора назад, потом полгода ее на этих данных учили, выпустили, а мы до сих пор ей пользуемся. Добросить в неё новые знания - вычислительно и финансово весьма накладно, так что модели не так часто обновляются.
Что делать?
* если документация не очень большая (помним про размер контекста), можно прям целиком её копипастнуть в чат с LLM или, что удобнее, дать ссылку на страницу документации в том же Cursor Composer - он сам ее скачает, распарсит и положит в контекст для модели;
* попробовать использовать символ @Web в Cursor - он запускает поиск релевантной вашему сообщению инфы в сети и потом включает результаты поиска в текущий контекст;
* переключиться на модель поновее - как правило, у недавно вышедших моделей cutoff date позднее и знания более актуальные;
* не использовать самые новые версии библиотек :) Не, ну кроме шуток - это нередко себя оправдывает.
К примеру, Angular и в прошлом году уже был достаточен для подавляющего большинства проектов, и большого профита от его свежего релиза скорее всего не получить, а вот бороться с LLM придется.
Конечно, нужно выбирать те версии, которые не совсем заброшены и хотя бы всё ещё получают обновления безопасности.
Языки программирования тоже лучше выбирать как можно более массовые и стабильные, по тем же причинам.
В особо тяжелых случаях модель вообще может не знать конкретного языка / фреймворка или иметь очень мало по нему данных для того, чтобы писать рабочий код.
В этом случае придётся либо все-таки писать код самому, либо креативно сочетать подходы выше.
#ai #work #development