Исходя из моего опыта, лучший способ работы с LLM - это написание "скелета архитектуры" (так как в таком случае LLM хватает контекстного окна даже для сложных задач). Если вам надо улучшить свой собственный проект, то помогает декомпозиция/сегментация, либо же просто на LLM пишете чистую логику, а потом разворачиваете все необходимые зависимости из своего проекта на логике написанной LLM. Работа с LLM в чистом виде в разы менее эффективна.
Я уже много лет использую текстовые LLM для генерации кода (ещё до появления AI ассистентов в IDE), и могу вам так сказать: если язык/фреймворк/библиотека популярные, а весь контекст максимально сжат (удалены все лишние зависимости, из базы данных убраны все значения кроме необходимых для примера), т.е., вы скармливаете LLM ровно необходимый ей для работы контекст и не байтом больше, при условии задания правильных текстовых инструкций (стек, задачи, архитектура и прочее, при необходимости - получаемые ошибки), то LLM генерируют код безошибочно, любой сложности и любого объёма (при наличие достаточной базы знаний у LLM). Главную проблему составляет контекстное окно, просовывать контекст через контекстное окно и обратно выдачу - это целое искусство, обычно помогает декомпозиция и сегментация, при нехватке контекстного окна в любую из сторон (к LLM/от LLM) вы получаете галлюцинацию вместо генерации. Насколько я понимаю, при работе с локальной моделью тут достаточно увеличить контекстное окно, просто запрос будет выполняться медленнее.
Я так ещё на ChatGPT3.5 ради интереса написал полноценный фронтенд для небольшого интернет-магазина, не имея серьёзного практического опыта работы с JS. По классическим языкам и популярным фреймворкам - у нейронок огромные базы знаний (переработанная алгоритмами бигдата), и они крайне хорошо генерируют выдачу, при умелой работе. LLM так хорошо пишут на JS, что скорее всего лет через пять JS-фреймворки уйдут в прошлое (как ушёл jQuery), потому что сейчас уже проще свой микро-реакт собрать под целевой проект, получив минималистичную кодовую базу вместо тонны лишнего кода в рантайме на машине пользователя, где уже открыто пятьдесят вкладок и у вас в распоряжении 30 мегабайт ОЗУ и 2% процессорной мощности для работы вашего фронтенда.
Ниже в комментариях ответил уже на эти вопросы. Контроль легко приобретается простейшими лайфхаками, описанными в статье и комментариях и вместо вероятностных предсказаний мы получаем точную генерацию согласно заданной инструкции.
Потому что увлекаюсь генерацией кода при помощи LLM ("вайбкодингом") уже много лет, задолго до появления Курсора и прочих и попросту высказываю свои наблюдения. "Предсказывания" это тоже алгоритм, причем, если его разобрать - очень простой. Попробуйте напишите простенький бэкенд на node.js/sqlite. Там нет вариативности решений, всегда есть только одно, соответственно, LLM выдает только один вариант всегда. Символ в символ. Это и показывает явно суть работы LLM с кодом. Простые алгоритмы, угадывание только в том что и как лучше делать. Но если мы скормим LLM запрос содержащий точные инструкции, не дающие возможность отклониться от способа выполнения задачи, то LLM генерирует 100% точный ответ, при наличии нужной информации в базе знаний. Т.е. угадывание мы, при помощи простейших лайфхаков, таких как "сложный запрос" (скармливание LLM всего необходимого контекста и инструкций) заменяем исполнением инструкций. В целом - если мы можем заставить LLM вместо "предсказаний" исполнять инструкцию, а вместо галлюцинаций выдавать генерацию, прибавьте сюда лайфхаки описанные мной в статье и комментариях - и мы получаем стопроцентную точность генерации кода на любом популярном языке/фреймворке/библиотеке. А то что "все LLM - форки друг друга", я не писал, это вы невнимательно читаете, я написал, что они "плюс-минус форки друг друга", так как созданы из одних и тех же опенсорсных библиотек, даже лучшие коммерческие модели.
Мы с вами уже неделю спорим общаемся, причём это происходит в формате: я пытаюсь объяснить базовые вещи, вы в ответ упорно аргументируете. Ладно попробуем упростить аргументацию:
LLM это попросту набор алгоритмов и база знаний (с этим спорить вы не можете, так как это технические факты)
если у LLM библиотеки позволят работать с кодом безошибочно, то при наличие достаточной базы знаний - LLM не может ошибаться (сейчас у всех популярных LLM библиотеки на хорошем уровне и база знаний по популярным языкам отличная)
возникает вопрос только контекстного окна, это огромная тема для дискуссии, поэтому скажем так - если вам хватает контекстного окна, то при условии соблюдения других условий - LLM не может ошибаться, потому что в её основе точные алгоритмы и точная база знаний, а рандомность выдачи это настраиваемая опция
при нехватке контекстного окна действует краткая инструкция изложенная мной здесь [ https://habr.com/ru/articles/903618/comments/#comment_28215552 ] (фронтенд, но применимо ко всему), при применении данной инструкции, вы получаете 99.99% точную генерацию, например, за несколько лет экспериментирования с генерацией JS - я получил всего один случай, когда LLM с трудом справилась, и этот случай - недостаток архитектуры самого JS, описал эту ситуацию тут [ https://habr.com/ru/articles/903618/comments/#comment_28214944 ]
Вы ошибаетесь, работа LLM с кодом подчиняется точным алгоритмам. LLM это не "искусственный интеллект", как их принято называть, это попросту набор алгоритмов + база знаний, ничего больше.
Читаю на английском на уровне native speaker. Просто рассказываю, что происходит в англоязычной (т.е., глобальной, так как английский уже много лет как международный язык) среде разработки.
Именно это я и пытаюсь развеять, потому что все LLM модели - это по большому счёту форки друг друга (всё собрано из общедоступных опесорсных баз на Hugging Face, т.е., примерно та же ситуация, что и с Linux). Ещё несколько лет назад LLM вышли на уровень когда они, в силу хорошо обученных базовых библиотек 100% точно генерируют код. Безошибочно. Соответственно, добавляем качественную базу знаний (есть теневой рынок с "известными" ценами, да и опенсорс тут поспевает за индустрией, буквально~~~через полгода догоняя коммерческие разработки) - и получаем безошибочную генерацию (согласно базовым принципам информатики). Т.е., LLM уже вышли на "стадию безошибочной генерации" кода. О чём и речь. И уже давно, сейчас просто их все опробовали в работе и, можно сказать, ревью пишут.
Так о чём я и говорю! Что LLM перешагнули этот порог! LLM сфера это как Linux-сфера, то есть есть постоянно растущий общий уровень, так как все копируют друг друга, простыми словами - всё это форк, даже само ядро форкают у форков. Как в JS добавляют функционал из фреймворков, сначала jQurey (почти полностью добавили в спецификацию), сейчас TypeScript подъехал, уже процесс идёт, скоро будет в JS опциональная строгая типизация, скоро React подвезут (htmx и ему подобные фреймворки, уже идут официальные обсуждения о включении в спецификацию). Потом ещё pug приплывёт - крутейшая штука. Так, я немного отвлёкся, суть в том, что общий уровень сферы - растёт синхронно. Все LLM за год примерно на один уровень подтягиваются, а что там подтягиваться, скопировал c Hugging Face последние библиотеки и здрасьте-пожалуйста (почему я и настаиваю, что отечественные LLM вполне себе пригодные к работе, они обычные форки, на обычном для индустрии уровне, точно не хуже). Так вот, LLM перешагнули уровень "непонимания" кода ещё ~лет пять назад (очень примерно). То есть сейчас все, абсолютно все LLM на 100% понимают работу с кодом на любом актуальном языке/фреймворке/библиотеке (при наличие достаточной базы знаний). Я уже неделю пытаюсь донести эту мысль до хабровчан, а мне не верят, "потому что DeepSeek не конвертирует в Паскаль". Откуда по Паскалю бигдате взяться? Глобально язык уже тридцать лет не применяется в крупномасштабной коммерческой разработке. Не хочется на Паскаль наговаривать, хороший язык, но надеяться на работу с Паскалем через LLM попросту наивно.
Я специально потратил полчаса на то, что бы найти хоть один реальный пример применения Паскаля, и не нашёл. Есть отрывистые комментарии на тему "на нём микроконтроллеры пишут", но ни одного реально примера применения за полчаса гугления найти не удалось. Могу в свою очередь рассказать про COBOL, на нём, понятное дело уже не пишут, но так как на нём огромные кодовые базы, исправно работающие, то оптимизируют и переписывают будь здоров. Паскаль-то - он реально применяется, или это уже из разряда "просто по фану писать пет проекты"?
Если максимально концентрировать контекст - то хватает даже мизерного контекстного окна. Например, если у вас фронтенд, то тупо убираете все стили кроме необходимых, это как спорт, счёт идёт на байты буквально. Все лишние зависимости, абсолютно всё. Оставляете только чистую логику. Потом уже на готовую логику вешаете обратно всё. При таком подходе даже базовая LLM с минимальным контекстным окном "тащит" будь здоров, выдавая на 99.99% верный код. Даже верстку можно перелопатить ради упрощения логики, удалив все лишние блоки. Потом её обратно "раскрыть" на написанной логике - не проблема.
Я ни вижу причины, почему если в базе знаний есть библиотеки с языком и библиотеки генерации кода и LLM способна понять запрос, то, чисто с точки зрения базовых принципов информатики - как она может ошибиться? Это невозможно просто "информатически". По моим наблюдениям, LLM модели за последние несколько лет стали лучше понимать сложные запросы и композировать сложные задачи, но в целом, как они писали безошибочный код при качественном промпте, так и пишут, ничего не поменялось, обычно в языке есть два-три способа решить задачу и не более, максимум четыре-пять. LLM все эти способы известны и они их выдают, этот функционал не меняется из года в год.
Ну уж как называют, не я придумал. Я наблюдаю тенденцию просто, что это слово ушло в народ. По крайней мере в англоязычной среде это уже абсолютно устойчивое понятие, я бы даже сказал, зарождающаяся научная дисциплина, как уже устоявшийся, в качестве научной дисциплины, промпт-инжиниринг. Мне в целом нравится название, вайб (vibe) просто благозвучное слово, оттуда и популярность его использования в сленге и терминах.
В масштабах big data это примерно нисколько. Фортран на сороковом. Есть хоть один пример чего-то хоть сколько-нибудь серьёзного написанного на Паскале? Для индустрии это мертвый язык. Уже как лет тридцать. Два с половиной НИИ пишущих по традиции - не в счёт. Исключение подтверждает правило, как известно.
Я готов поспорить, что мои выводы подтвердятся через несколько лет. Это просто наблюдения сделанные за годы использования LLM для генерации кода (или "вайбкодинга", как сейчас говорят). Любая сложная проблема - разбивается на части и успешно решается. Если решение не находится - дело может быть исключительно в нехватке базы знаний, это значит что речь идёт либо об очень специфичной проблеме, либо об очень специфичном языке/фреймворке/библиотеке.
Исходя из моего опыта, лучший способ работы с LLM - это написание "скелета архитектуры" (так как в таком случае LLM хватает контекстного окна даже для сложных задач). Если вам надо улучшить свой собственный проект, то помогает декомпозиция/сегментация, либо же просто на LLM пишете чистую логику, а потом разворачиваете все необходимые зависимости из своего проекта на логике написанной LLM. Работа с LLM в чистом виде в разы менее эффективна.
TDD и LLM это два синонима.
Я уже много лет использую текстовые LLM для генерации кода (ещё до появления AI ассистентов в IDE), и могу вам так сказать: если язык/фреймворк/библиотека популярные, а весь контекст максимально сжат (удалены все лишние зависимости, из базы данных убраны все значения кроме необходимых для примера), т.е., вы скармливаете LLM ровно необходимый ей для работы контекст и не байтом больше, при условии задания правильных текстовых инструкций (стек, задачи, архитектура и прочее, при необходимости - получаемые ошибки), то LLM генерируют код безошибочно, любой сложности и любого объёма (при наличие достаточной базы знаний у LLM). Главную проблему составляет контекстное окно, просовывать контекст через контекстное окно и обратно выдачу - это целое искусство, обычно помогает декомпозиция и сегментация, при нехватке контекстного окна в любую из сторон (к LLM/от LLM) вы получаете галлюцинацию вместо генерации. Насколько я понимаю, при работе с локальной моделью тут достаточно увеличить контекстное окно, просто запрос будет выполняться медленнее.
Я так ещё на ChatGPT3.5 ради интереса написал полноценный фронтенд для небольшого интернет-магазина, не имея серьёзного практического опыта работы с JS. По классическим языкам и популярным фреймворкам - у нейронок огромные базы знаний (переработанная алгоритмами бигдата), и они крайне хорошо генерируют выдачу, при умелой работе. LLM так хорошо пишут на JS, что скорее всего лет через пять JS-фреймворки уйдут в прошлое (как ушёл jQuery), потому что сейчас уже проще свой микро-реакт собрать под целевой проект, получив минималистичную кодовую базу вместо тонны лишнего кода в рантайме на машине пользователя, где уже открыто пятьдесят вкладок и у вас в распоряжении 30 мегабайт ОЗУ и 2% процессорной мощности для работы вашего фронтенда.
Ниже в комментариях ответил уже на эти вопросы. Контроль легко приобретается простейшими лайфхаками, описанными в статье и комментариях и вместо вероятностных предсказаний мы получаем точную генерацию согласно заданной инструкции.
Потому что увлекаюсь генерацией кода при помощи LLM ("вайбкодингом") уже много лет, задолго до появления Курсора и прочих и попросту высказываю свои наблюдения. "Предсказывания" это тоже алгоритм, причем, если его разобрать - очень простой. Попробуйте напишите простенький бэкенд на node.js/sqlite. Там нет вариативности решений, всегда есть только одно, соответственно, LLM выдает только один вариант всегда. Символ в символ. Это и показывает явно суть работы LLM с кодом. Простые алгоритмы, угадывание только в том что и как лучше делать. Но если мы скормим LLM запрос содержащий точные инструкции, не дающие возможность отклониться от способа выполнения задачи, то LLM генерирует 100% точный ответ, при наличии нужной информации в базе знаний. Т.е. угадывание мы, при помощи простейших лайфхаков, таких как "сложный запрос" (скармливание LLM всего необходимого контекста и инструкций) заменяем исполнением инструкций. В целом - если мы можем заставить LLM вместо "предсказаний" исполнять инструкцию, а вместо галлюцинаций выдавать генерацию, прибавьте сюда лайфхаки описанные мной в статье и комментариях - и мы получаем стопроцентную точность генерации кода на любом популярном языке/фреймворке/библиотеке. А то что "все LLM - форки друг друга", я не писал, это вы невнимательно читаете, я написал, что они "плюс-минус форки друг друга", так как созданы из одних и тех же опенсорсных библиотек, даже лучшие коммерческие модели.
Мы с вами уже неделю
споримобщаемся, причём это происходит в формате: я пытаюсь объяснить базовые вещи, вы в ответ упорно аргументируете. Ладно попробуем упростить аргументацию:LLM это попросту набор алгоритмов и база знаний (с этим спорить вы не можете, так как это технические факты)
если у LLM библиотеки позволят работать с кодом безошибочно, то при наличие достаточной базы знаний - LLM не может ошибаться (сейчас у всех популярных LLM библиотеки на хорошем уровне и база знаний по популярным языкам отличная)
возникает вопрос только контекстного окна, это огромная тема для дискуссии, поэтому скажем так - если вам хватает контекстного окна, то при условии соблюдения других условий - LLM не может ошибаться, потому что в её основе точные алгоритмы и точная база знаний, а рандомность выдачи это настраиваемая опция
при нехватке контекстного окна действует краткая инструкция изложенная мной здесь [ https://habr.com/ru/articles/903618/comments/#comment_28215552 ] (фронтенд, но применимо ко всему), при применении данной инструкции, вы получаете 99.99% точную генерацию, например, за несколько лет экспериментирования с генерацией JS - я получил всего один случай, когда LLM с трудом справилась, и этот случай - недостаток архитектуры самого JS, описал эту ситуацию тут [ https://habr.com/ru/articles/903618/comments/#comment_28214944 ]
Вы ошибаетесь, работа LLM с кодом подчиняется точным алгоритмам. LLM это не "искусственный интеллект", как их принято называть, это попросту набор алгоритмов + база знаний, ничего больше.
Читаю на английском на уровне native speaker. Просто рассказываю, что происходит в англоязычной (т.е., глобальной, так как английский уже много лет как международный язык) среде разработки.
Индустрия перешагнула все проблемы LLM обсуждаемые на Хабре уже лет как пять назад. Тут у большинства мнение, как будто мы в 2020-ом.
Ну так было пару месяцев назад, сейчас уже термин плотно "ушёл в народ".
Промптинг это уже целая индустрия с зарплатами на уровне с разработчиками.
Касательно "вайбкодинга" - просто описал применение термина в англоязычной среде.
Shopify уже официально не нанимает людей не умеющих работать с AI.
Именно это я и пытаюсь развеять, потому что все LLM модели - это по большому счёту форки друг друга (всё собрано из общедоступных опесорсных баз на Hugging Face, т.е., примерно та же ситуация, что и с Linux). Ещё несколько лет назад LLM вышли на уровень когда они, в силу хорошо обученных базовых библиотек 100% точно генерируют код. Безошибочно. Соответственно, добавляем качественную базу знаний (есть теневой рынок с "известными" ценами, да и опенсорс тут поспевает за индустрией, буквально ~~~через полгода догоняя коммерческие разработки) - и получаем безошибочную генерацию (согласно базовым принципам информатики). Т.е., LLM уже вышли на "стадию безошибочной генерации" кода. О чём и речь. И уже давно, сейчас просто их все опробовали в работе и, можно сказать, ревью пишут.
Так о чём я и говорю! Что LLM перешагнули этот порог! LLM сфера это как Linux-сфера, то есть есть постоянно растущий общий уровень, так как все копируют друг друга, простыми словами - всё это форк, даже само ядро форкают у форков. Как в JS добавляют функционал из фреймворков, сначала jQurey (почти полностью добавили в спецификацию), сейчас TypeScript подъехал, уже процесс идёт, скоро будет в JS опциональная строгая типизация, скоро React подвезут (htmx и ему подобные фреймворки, уже идут официальные обсуждения о включении в спецификацию). Потом ещё pug приплывёт - крутейшая штука. Так, я немного отвлёкся, суть в том, что общий уровень сферы - растёт синхронно. Все LLM за год примерно на один уровень подтягиваются, а что там подтягиваться, скопировал c Hugging Face последние библиотеки и здрасьте-пожалуйста (почему я и настаиваю, что отечественные LLM вполне себе пригодные к работе, они обычные форки, на обычном для индустрии уровне, точно не хуже). Так вот, LLM перешагнули уровень "непонимания" кода ещё ~лет пять назад (очень примерно). То есть сейчас все, абсолютно все LLM на 100% понимают работу с кодом на любом актуальном языке/фреймворке/библиотеке (при наличие достаточной базы знаний). Я уже неделю пытаюсь донести эту мысль до хабровчан, а мне не верят, "потому что DeepSeek не конвертирует в Паскаль". Откуда по Паскалю бигдате взяться? Глобально язык уже тридцать лет не применяется в крупномасштабной коммерческой разработке. Не хочется на Паскаль наговаривать, хороший язык, но надеяться на работу с Паскалем через LLM попросту наивно.
Я специально потратил полчаса на то, что бы найти хоть один реальный пример применения Паскаля, и не нашёл. Есть отрывистые комментарии на тему "на нём микроконтроллеры пишут", но ни одного реально примера применения за полчаса гугления найти не удалось. Могу в свою очередь рассказать про COBOL, на нём, понятное дело уже не пишут, но так как на нём огромные кодовые базы, исправно работающие, то оптимизируют и переписывают будь здоров. Паскаль-то - он реально применяется, или это уже из разряда "просто по фану писать пет проекты"?
Если максимально концентрировать контекст - то хватает даже мизерного контекстного окна. Например, если у вас фронтенд, то тупо убираете все стили кроме необходимых, это как спорт, счёт идёт на байты буквально. Все лишние зависимости, абсолютно всё. Оставляете только чистую логику. Потом уже на готовую логику вешаете обратно всё. При таком подходе даже базовая LLM с минимальным контекстным окном "тащит" будь здоров, выдавая на 99.99% верный код. Даже верстку можно перелопатить ради упрощения логики, удалив все лишние блоки. Потом её обратно "раскрыть" на написанной логике - не проблема.
Я ни вижу причины, почему если в базе знаний есть библиотеки с языком и библиотеки генерации кода и LLM способна понять запрос, то, чисто с точки зрения базовых принципов информатики - как она может ошибиться? Это невозможно просто "информатически". По моим наблюдениям, LLM модели за последние несколько лет стали лучше понимать сложные запросы и композировать сложные задачи, но в целом, как они писали безошибочный код при качественном промпте, так и пишут, ничего не поменялось, обычно в языке есть два-три способа решить задачу и не более, максимум четыре-пять. LLM все эти способы известны и они их выдают, этот функционал не меняется из года в год.
Ну уж как называют, не я придумал. Я наблюдаю тенденцию просто, что это слово ушло в народ. По крайней мере в англоязычной среде это уже абсолютно устойчивое понятие, я бы даже сказал, зарождающаяся научная дисциплина, как уже устоявшийся, в качестве научной дисциплины, промпт-инжиниринг. Мне в целом нравится название, вайб (vibe) просто благозвучное слово, оттуда и популярность его использования в сленге и терминах.
https://madnight.github.io/githut/#/pull_requests/2024/1
Q1 2024
Python: 16.925% (-0.284%)
Java: 11.708% (+0.393%)
Go: 10.262% (-0.162%)
JavaScript: 9.859% (+0.306%)
C++: 9.459% (-0.624%)
TypeScript: 7.345% (-0.554%)
PHP: 5.665% (+0.357%)
Ruby: 4.706% (-0.307%)
C: 4.616% (+0.208%)
C#: 3.442% (+0.300%)
...
50. Pascal: 0.026%
В масштабах big data это примерно нисколько. Фортран на сороковом. Есть хоть один пример чего-то хоть сколько-нибудь серьёзного написанного на Паскале? Для индустрии это мертвый язык. Уже как лет тридцать. Два с половиной НИИ пишущих по традиции - не в счёт. Исключение подтверждает правило, как известно.
Я готов поспорить, что мои выводы подтвердятся через несколько лет. Это просто наблюдения сделанные за годы использования LLM для генерации кода (или "вайбкодинга", как сейчас говорят). Любая сложная проблема - разбивается на части и успешно решается. Если решение не находится - дело может быть исключительно в нехватке базы знаний, это значит что речь идёт либо об очень специфичной проблеме, либо об очень специфичном языке/фреймворке/библиотеке.