Комментарии 8
Зачем делигировать LLM то, что вы можете сделать лучше неё сами, вручную?
Да, зачем вообще брать LLM если я могу это сделать лучше её сам, вручную?
Ручная работа всегда была лучше. Но дольше и дороже.
Тогда как отличить какую часть -- автоматизировать, а какую -- самопалить? Почему "тут" а не "здесь"? Где грань?
Например вопрос "вкатывания" в язык. Раньше на изучения языка тратились годы, сейчас, при помощи LLM - месяцы, а то и недели. Я бы даже сказал, что если ты уже знаком с каким-либо языком схожего назначения на хорошем уровне, то при помощи LLM вкатиться в новый язык можно... за неделю смело. Пишешь прототип, просишь LLM тебе всё объяснить, прогоняешь раз десять все мелочи, и считай уже освоил практику. Я до появления LLM года три учил документацию по JS, в свободное время, что бы в него "вкатиться", с появлением LLM процесс, можно сказать, на порядок упростился. Сразу пишешь - ничего не понимаешь - потом разбираешь. Всё равно, что с сеньором работать рядом, сами понимаете разницу по скорости изучения языка. Мой личный прогноз - через пять-десять лет все фулстеками будут, потому что, например, зная JS, я ноду освоил за несколько дней, ну и так далее. Написать мобильное приложение, если ты знаешь только веб? Не проблема. Написать веб, если ты знаешь только десктоп - не проблема. LLM подвинули это всё на принципиально новый уровень. Этакий супер-гугл. А гугл уже давно "мёртв". Почти всё забито инфоцыганством до невозможности. Найти что-то толковое, как 20 лет назад - стало в разы сложнее. Гугл из инструмента превратился в развлекательный ресурс. Я считаю, что это и стало основой для зарождения среды появления LLM.
"при помощи LLM вкатиться в новый язык можно... за неделю смело."
Ей бы кто объяснил язык, при переводе функции составления regexp с python на pascal Deepseek r1 мне вмандюрила переменную I как итератор по вектору найденных строк и сразу ниже i как счётчик в цикле по этой строке, функция всего 6 строк, у нас любой школьник знает, что Паскаль регистронезависим
Качественный контекст и декомпозиция — это база работы с LLM, а не откровение. Без этого ничего не работает в принципе, и это знают все, кто использовал LLM дольше пяти минут.
Фактически, сегментируя задачи и повышая концентрацию контекста, можно заставить даже самые базовые модели работать на уровне мощнейших и лучших.
Нет, нельзя. Хоть опляшысь ты с бубном — если работаешь с 7B моделью, которая двух слов связать не может, ты получишь шлак.
Выбор качественной модели — это первое правило хорошей генерации. Часто это означает: взять лучшую из доступных топовых, а не пытаться выжать что-то осмысленное из модели, которая обучалась на "трёх рецептах борща".
Ещё один, немного необычный совет для работы с LLM — купите хорошую игровую мышку.
И коврик не забудьте.
Пост родился из диалогов на хабре, я в нём просто изложил, можно сказать, то что, на мой взгляд упущено многими, а именно - возможность устойчивой безошибочной генерации практически на любом языке на любой современной модели. Касательно возможностей "базовых моделей" - это уже вопрос личного понимания этого термина. Фактически всё что я написал было верно ещё несколько лет назад, т.е., любая актуальная качественная модель соответствует всему вышесказанному. Понятно, что под базовой тут понимается "любая модель из актуальных". Ну не усложняйте, это как с дистрибутивами линукс, понятно, что под базовой имеется ввиду "что угодно нормальное".
Касательно 7B моделей, ну вот, вроде, неплохо справляющаяся с генерацией кода 7B модель [ https://www.promptingguide.ai/ru/models/mistral-7b ]. Опять-таки, это очень широкий вопрос, и тут нельзя прямо вот так сказать: "годится или не годится". Вопрос базы знаний и много чего ещё. Опять-таки, если вы понимаете базу информатики, то думаю, для вас очевидно - что код это попросту точная текстовая абстракция. Соответственно что? Соответственно работа с кодом - это минимальная нагрузка на LLM. Поэтому, если, например, при работе с "логическим мышлением" справляются только лучшие LLM - то с генерацией кода запросто справляются даже самые "базовые" (опять-таки, не стоит абсолютировать этот термин, давайте воспринимать его адекватно).
Моя мысль и тут заключалась в простом посыле, который, опять-таки, у меня родился после многочисленных диалогов на Хабре на данную тематику. Немногие понимают, что работа с кодом, в силу базовых принципов информатики - является самой простой задачей для LLM, а значит и самой сильной их стороной. Код это не просто текстовая абстракция, код это точная текстовая абстракция с наборов устойчивых правил, а значит при наличие данных правил в базе знаний и самых базовых библиотек в составе модели - модель не может ошибаться чисто "информатически". Это всё равно что прогонять её по усложнённой таблице умножения. В отличие от работы с текстом, логикой и прочим - это абсолютно элементарная задача для LLM, на уровне базовой математики. Вы понимаете о чём я говорю? Это для LLM просто, как прогонять математическую формулу по базовым принципам, то есть это сверх-простая задача даже для простейших LLM. Там уже дальше качество генерации - вопрос базы знаний и прочих условий, коих великое множество, то есть даже обсуждать это в одном комментарии не имеет смысла, тут на две статьи тема и это только вступление будет.
Про коврик классная идея, надо бы подумать. Без стёба. Когда мне нужно что-то сгенерировать - я просто ищу в своём проекте все необходимые для генерации зависимости, копирую их в текстовый файл и подготавливаю запрос (этакий супер-промпт), который содержит все необходимые для LLM данные, сами понимаете сколько текста, хороший коврик тут действительно может помочь. При качественной подготовке "запроса" ещё ни разу ни одна LLM не выдавала мне неверный ответ. В этом и была основная мысль статьи. Просто хотелось поделиться с хабровчанами, потому что я накопал с этого ресурса немало полезной информации, полезно, знаете ли, когда выбираешь фреймворк - знать мнение людей, которые не одну декаду в индустрии.
Будни вайбкодинга: лайфхаки при работе с LLM