Изначальный смысл статьи как раз заключался в описании методов получения безгаллюционной генерации. Разбиение на подзадачи обычно помогает, плюс если LLM "затупила", то это обычно какой-то действительно специфичный момент, например проблема отсутствия возможности обращения к псевдоклассам из JS. Эта задача ставит в ступор даже опытных разработчиков (решается либо аттрибутными селекторами, либо прямой записью в таблицу стилей). Но тут достаточно немножко погуглить, и всё сразу находится, да и сама LLM обычно понимает в чём может быть проблема, просто по специфичным задачам мало базы знаний и она "боится" выдавать выдачу с малым количеством примеров в базе (так настроены практически все LLM). Тут надо заставить её дать все возможные варианты и самому прогонять их, включая самые неочевидные, либо же с самой LLM их поочерёдно разбирать. По той же проблеме с псевдоклассам - LLM предполагает что это может быть проблемой, но в её приоритетах возможных проблем она занимает третье-четвертое место, т.е., надо сначала отсеять два-три неверных варианта и тогда натыкаешься на правильное решение. Это единственный серьёзный затуп в работе с JS, который мне встретился за очень долгое время, как сейчас говорят, "вайбкодинга", или простыми словами - использования LLM для генерации кода.
Есть такой "мем" в среде англоязычных любителей картографии: "не используй Меркатор" (don't use mercator). Когда кто-нибудь постит что-то связанное с картографией и использует карту с проекцией Меркатора - неизбежно появляются комментарии навроде: "it's all good, but don't use mercator". У меня уже рефлекторно, когда увидел пост появилась мысль: "всё хорошо, но не используй проекцию Меркатора", а оказывается пост как раз-таки про недостатки проекции.
Пост родился из диалогов на хабре, я в нём просто изложил, можно сказать, то что, на мой взгляд упущено многими, а именно - возможность устойчивой безошибочной генерации практически на любом языке на любой современной модели. Касательно возможностей "базовых моделей" - это уже вопрос личного понимания этого термина. Фактически всё что я написал было верно ещё несколько лет назад, т.е., любая актуальная качественная модель соответствует всему вышесказанному. Понятно, что под базовой тут понимается "любая модель из актуальных". Ну не усложняйте, это как с дистрибутивами линукс, понятно, что под базовой имеется ввиду "что угодно нормальное".
Касательно 7B моделей, ну вот, вроде, неплохо справляющаяся с генерацией кода 7B модель [ https://www.promptingguide.ai/ru/models/mistral-7b ]. Опять-таки, это очень широкий вопрос, и тут нельзя прямо вот так сказать: "годится или не годится". Вопрос базы знаний и много чего ещё. Опять-таки, если вы понимаете базу информатики, то думаю, для вас очевидно - что код это попросту точная текстовая абстракция. Соответственно что? Соответственно работа с кодом - это минимальная нагрузка на LLM. Поэтому, если, например, при работе с "логическим мышлением" справляются только лучшие LLM - то с генерацией кода запросто справляются даже самые "базовые" (опять-таки, не стоит абсолютировать этот термин, давайте воспринимать его адекватно).
Моя мысль и тут заключалась в простом посыле, который, опять-таки, у меня родился после многочисленных диалогов на Хабре на данную тематику. Немногие понимают, что работа с кодом, в силу базовых принципов информатики - является самой простой задачей для LLM, а значит и самой сильной их стороной. Код это не просто текстовая абстракция, код это точная текстовая абстракция с наборов устойчивых правил, а значит при наличие данных правил в базе знаний и самых базовых библиотек в составе модели - модель не может ошибаться чисто "информатически". Это всё равно что прогонять её по усложнённой таблице умножения. В отличие от работы с текстом, логикой и прочим - это абсолютно элементарная задача для LLM, на уровне базовой математики. Вы понимаете о чём я говорю? Это для LLM просто, как прогонять математическую формулу по базовым принципам, то есть это сверх-простая задача даже для простейших LLM. Там уже дальше качество генерации - вопрос базы знаний и прочих условий, коих великое множество, то есть даже обсуждать это в одном комментарии не имеет смысла, тут на две статьи тема и это только вступление будет.
Про коврик классная идея, надо бы подумать. Без стёба. Когда мне нужно что-то сгенерировать - я просто ищу в своём проекте все необходимые для генерации зависимости, копирую их в текстовый файл и подготавливаю запрос (этакий супер-промпт), который содержит все необходимые для LLM данные, сами понимаете сколько текста, хороший коврик тут действительно может помочь. При качественной подготовке "запроса" ещё ни разу ни одна LLM не выдавала мне неверный ответ. В этом и была основная мысль статьи. Просто хотелось поделиться с хабровчанами, потому что я накопал с этого ресурса немало полезной информации, полезно, знаете ли, когда выбираешь фреймворк - знать мнение людей, которые не одну декаду в индустрии.
Например вопрос "вкатывания" в язык. Раньше на изучения языка тратились годы, сейчас, при помощи LLM - месяцы, а то и недели. Я бы даже сказал, что если ты уже знаком с каким-либо языком схожего назначения на хорошем уровне, то при помощи LLM вкатиться в новый язык можно... за неделю смело. Пишешь прототип, просишь LLM тебе всё объяснить, прогоняешь раз десять все мелочи, и считай уже освоил практику. Я до появления LLM года три учил документацию по JS, в свободное время, что бы в него "вкатиться", с появлением LLM процесс, можно сказать, на порядок упростился. Сразу пишешь - ничего не понимаешь - потом разбираешь. Всё равно, что с сеньором работать рядом, сами понимаете разницу по скорости изучения языка. Мой личный прогноз - через пять-десять лет все фулстеками будут, потому что, например, зная JS, я ноду освоил за несколько дней, ну и так далее. Написать мобильное приложение, если ты знаешь только веб? Не проблема. Написать веб, если ты знаешь только десктоп - не проблема. LLM подвинули это всё на принципиально новый уровень. Этакий супер-гугл. А гугл уже давно "мёртв". Почти всё забито инфоцыганством до невозможности. Найти что-то толковое, как 20 лет назад - стало в разы сложнее. Гугл из инструмента превратился в развлекательный ресурс. Я считаю, что это и стало основой для зарождения среды появления LLM.
Они не "урезанные". В основе всех LLM - всё те же бесплатные общедоступные библиотеки, даже самые мощные LLM собраны на них. Мощная LLM просто за вас разгребает контекст и из него строит генерацию, в случае с использованием опенсорсных LLM вы просто делаете эту работу вручную и получаете идентичный результат.
Все модели, даже самые мощные - собраны на базе общедоступных бесплатных библиотек и в корне они все ничем не отличаются. "Выжать" из них высококачественную генерацию труда не составляет. Практически все опробованные мной модели, при использовании вышеприведённых в посте методик - выдают безошибочный JavaScript и Node.JS (например Fastify) и SQL. Включая вышеупомянутый GigaChat.
У вас очень слабые познания в LLM. Существует множество форков с низким потреблением VRAM, есть отдельные модели написанные под низкое количество видеопамяти. Существуют модели использующие исключительно CPU/RAM. Для работы с кодом, который является простой текстовой абстракцией, многие из них прекрасно сгодятся.
Популярных LLM около двадцати, из них большая часть это локальные модели, которые практически не уступают моделям от крупнейших LLM-провайдеров, так как все LLM это форки друг друга, как в случае с дистрибутивами Linux. При грамотной работе они ни в чём не уступают тем, что не открываются из РФ.
Давайте прогоним тест любой популярной LLM и посмотрим наличие ошибок. Подобные нюансы в работе всех популярных LLM были пофикшены ещё многие годы назад. Либо неправильная работа с LLM.
Либо приложение проходит успешно проверку по всем поставленным задачам либо нет - так и определяется работоспособность. Зачем усложнять, когда можно упрощать?
Приложение либо работоспособное либо нет. Один или ноль. Тут не может быть третьего параметра. Касательно всего того, что IDE хорошо умеют справляется с этими задачами - конечно, никто не спорит. Просто LLM умеет ещё лучше и расширяет эти возможности. Иногда кардинально. Зачастую кардинально.
Смотря как спрашивать, и далеко не каждый ответ LLM это галлюцинация. При условии соблюдения двух простых параметров: достаточное контекстное окно и достаточная база знаний - LLM выдаёт не галлюцинацию, а генерацию. Есть множество способов повысить качество выдачи от галлюцинаций до генерации.
Изначальный смысл статьи как раз заключался в описании методов получения безгаллюционной генерации. Разбиение на подзадачи обычно помогает, плюс если LLM "затупила", то это обычно какой-то действительно специфичный момент, например проблема отсутствия возможности обращения к псевдоклассам из JS. Эта задача ставит в ступор даже опытных разработчиков (решается либо аттрибутными селекторами, либо прямой записью в таблицу стилей). Но тут достаточно немножко погуглить, и всё сразу находится, да и сама LLM обычно понимает в чём может быть проблема, просто по специфичным задачам мало базы знаний и она "боится" выдавать выдачу с малым количеством примеров в базе (так настроены практически все LLM). Тут надо заставить её дать все возможные варианты и самому прогонять их, включая самые неочевидные, либо же с самой LLM их поочерёдно разбирать. По той же проблеме с псевдоклассам - LLM предполагает что это может быть проблемой, но в её приоритетах возможных проблем она занимает третье-четвертое место, т.е., надо сначала отсеять два-три неверных варианта и тогда натыкаешься на правильное решение. Это единственный серьёзный затуп в работе с JS, который мне встретился за очень долгое время, как сейчас говорят, "вайбкодинга", или простыми словами - использования LLM для генерации кода.
Паскаль не используется в индустрии - нет кодовой базы - нет обучающей выборки.
Насколько мне известно, самая точная по соотношению площадей объектов, при этом минимально искажающая форму объектов - это проекция Мольвейде
https://ru.wikipedia.org/wiki/Проекция_Мольвейде
Мне лично нравится проекция Гуда, она на мой взгляд максимально "логичная", но она непригодна для навигации
https://ru.wikipedia.org/wiki/Проекция_Гуда
Есть такой "мем" в среде англоязычных любителей картографии: "не используй Меркатор" (don't use mercator). Когда кто-нибудь постит что-то связанное с картографией и использует карту с проекцией Меркатора - неизбежно появляются комментарии навроде: "it's all good, but don't use mercator". У меня уже рефлекторно, когда увидел пост появилась мысль: "всё хорошо, но не используй проекцию Меркатора", а оказывается пост как раз-таки про недостатки проекции.
Пост родился из диалогов на хабре, я в нём просто изложил, можно сказать, то что, на мой взгляд упущено многими, а именно - возможность устойчивой безошибочной генерации практически на любом языке на любой современной модели. Касательно возможностей "базовых моделей" - это уже вопрос личного понимания этого термина. Фактически всё что я написал было верно ещё несколько лет назад, т.е., любая актуальная качественная модель соответствует всему вышесказанному. Понятно, что под базовой тут понимается "любая модель из актуальных". Ну не усложняйте, это как с дистрибутивами линукс, понятно, что под базовой имеется ввиду "что угодно нормальное".
Касательно 7B моделей, ну вот, вроде, неплохо справляющаяся с генерацией кода 7B модель [ https://www.promptingguide.ai/ru/models/mistral-7b ]. Опять-таки, это очень широкий вопрос, и тут нельзя прямо вот так сказать: "годится или не годится". Вопрос базы знаний и много чего ещё. Опять-таки, если вы понимаете базу информатики, то думаю, для вас очевидно - что код это попросту точная текстовая абстракция. Соответственно что? Соответственно работа с кодом - это минимальная нагрузка на LLM. Поэтому, если, например, при работе с "логическим мышлением" справляются только лучшие LLM - то с генерацией кода запросто справляются даже самые "базовые" (опять-таки, не стоит абсолютировать этот термин, давайте воспринимать его адекватно).
Моя мысль и тут заключалась в простом посыле, который, опять-таки, у меня родился после многочисленных диалогов на Хабре на данную тематику. Немногие понимают, что работа с кодом, в силу базовых принципов информатики - является самой простой задачей для LLM, а значит и самой сильной их стороной. Код это не просто текстовая абстракция, код это точная текстовая абстракция с наборов устойчивых правил, а значит при наличие данных правил в базе знаний и самых базовых библиотек в составе модели - модель не может ошибаться чисто "информатически". Это всё равно что прогонять её по усложнённой таблице умножения. В отличие от работы с текстом, логикой и прочим - это абсолютно элементарная задача для LLM, на уровне базовой математики. Вы понимаете о чём я говорю? Это для LLM просто, как прогонять математическую формулу по базовым принципам, то есть это сверх-простая задача даже для простейших LLM. Там уже дальше качество генерации - вопрос базы знаний и прочих условий, коих великое множество, то есть даже обсуждать это в одном комментарии не имеет смысла, тут на две статьи тема и это только вступление будет.
Про коврик классная идея, надо бы подумать. Без стёба. Когда мне нужно что-то сгенерировать - я просто ищу в своём проекте все необходимые для генерации зависимости, копирую их в текстовый файл и подготавливаю запрос (этакий супер-промпт), который содержит все необходимые для LLM данные, сами понимаете сколько текста, хороший коврик тут действительно может помочь. При качественной подготовке "запроса" ещё ни разу ни одна LLM не выдавала мне неверный ответ. В этом и была основная мысль статьи. Просто хотелось поделиться с хабровчанами, потому что я накопал с этого ресурса немало полезной информации, полезно, знаете ли, когда выбираешь фреймворк - знать мнение людей, которые не одну декаду в индустрии.
Например вопрос "вкатывания" в язык. Раньше на изучения языка тратились годы, сейчас, при помощи LLM - месяцы, а то и недели. Я бы даже сказал, что если ты уже знаком с каким-либо языком схожего назначения на хорошем уровне, то при помощи LLM вкатиться в новый язык можно... за неделю смело. Пишешь прототип, просишь LLM тебе всё объяснить, прогоняешь раз десять все мелочи, и считай уже освоил практику. Я до появления LLM года три учил документацию по JS, в свободное время, что бы в него "вкатиться", с появлением LLM процесс, можно сказать, на порядок упростился. Сразу пишешь - ничего не понимаешь - потом разбираешь. Всё равно, что с сеньором работать рядом, сами понимаете разницу по скорости изучения языка. Мой личный прогноз - через пять-десять лет все фулстеками будут, потому что, например, зная JS, я ноду освоил за несколько дней, ну и так далее. Написать мобильное приложение, если ты знаешь только веб? Не проблема. Написать веб, если ты знаешь только десктоп - не проблема. LLM подвинули это всё на принципиально новый уровень. Этакий супер-гугл. А гугл уже давно "мёртв". Почти всё забито инфоцыганством до невозможности. Найти что-то толковое, как 20 лет назад - стало в разы сложнее. Гугл из инструмента превратился в развлекательный ресурс. Я считаю, что это и стало основой для зарождения среды появления LLM.
Они не "урезанные". В основе всех LLM - всё те же бесплатные общедоступные библиотеки, даже самые мощные LLM собраны на них. Мощная LLM просто за вас разгребает контекст и из него строит генерацию, в случае с использованием опенсорсных LLM вы просто делаете эту работу вручную и получаете идентичный результат.
Все модели, даже самые мощные - собраны на базе общедоступных бесплатных библиотек и в корне они все ничем не отличаются. "Выжать" из них высококачественную генерацию труда не составляет. Практически все опробованные мной модели, при использовании вышеприведённых в посте методик - выдают безошибочный JavaScript и Node.JS (например Fastify) и SQL. Включая вышеупомянутый GigaChat.
У вас очень слабые познания в LLM. Существует множество форков с низким потреблением VRAM, есть отдельные модели написанные под низкое количество видеопамяти. Существуют модели использующие исключительно CPU/RAM. Для работы с кодом, который является простой текстовой абстракцией, многие из них прекрасно сгодятся.
Популярных LLM около двадцати, из них большая часть это локальные модели, которые практически не уступают моделям от крупнейших LLM-провайдеров, так как все LLM это форки друг друга, как в случае с дистрибутивами Linux. При грамотной работе они ни в чём не уступают тем, что не открываются из РФ.
Что "это"? Давайте создадим нормальный контекст, нормальный запрос и посмотрим как Deepseek справится.
Ваше видео не прогружается из РФ
Давайте прогоним тест любой популярной LLM и посмотрим наличие ошибок. Подобные нюансы в работе всех популярных LLM были пофикшены ещё многие годы назад. Либо неправильная работа с LLM.
Либо приложение проходит успешно проверку по всем поставленным задачам либо нет - так и определяется работоспособность. Зачем усложнять, когда можно упрощать?
Вы сами нарушили собственное условие: "независимо от вводных даёт ответ 42" - тут же прямая зависимость.
Мы говорим о реальных примерах.
Калькулятор выдающий неправильные значения - по умолчанию работоспособным не является.
Приложение либо работоспособное либо нет. Один или ноль. Тут не может быть третьего параметра. Касательно всего того, что IDE хорошо умеют справляется с этими задачами - конечно, никто не спорит. Просто LLM умеет ещё лучше и расширяет эти возможности. Иногда кардинально. Зачастую кардинально.
Смотря как спрашивать, и далеко не каждый ответ LLM это галлюцинация. При условии соблюдения двух простых параметров: достаточное контекстное окно и достаточная база знаний - LLM выдаёт не галлюцинацию, а генерацию. Есть множество способов повысить качество выдачи от галлюцинаций до генерации.
Все LLM-провайдеры до единого, отечественные и иностранные, предоставляют услуги по выделению частных конфигураций.