Если речь о бэкенде, то никакой проблемы, конечно, в фреймворках нет. Только я не понимаю как наличие фреймворка противоричит работе с LLM, насколько я знаю, все PHP-фреймворки отлично знакомы всем популярным LLM.
Если речь о том, зачем вообще LLM для бэкенд-фреймворков? Ну как зачем? Скорость освоения, построения прототипа. Можно использовать практически любой стек не тратя время на заучивание документации, а выучить всё в процессе, на практике. Написание бойлерплейта. На любом фреймворке вам всё равно придётся писать бойлерплейт, просто он будет короче, пусть и в несколько раз, но это всё равно бойлерплейт.
"Толковый фреймворк" с "толковой LLM" в умелых руках на многое способны. LLM и тут добавляет гибкости и скорости работы.
Нет открытого прайса ни у одного LLM-провайдера, там всегда что-то навроде "contact us for details". Слишком хаотичная бизнес-модель для точного ценообразования.
Зачем, когда я могу за два часа для небольшого проекта, написать свой микро-фреймворк, т.е., отсутствие огромной неиспользуемой кодовой базы в рантайме на машине пользователя, где уже несколько сотен вкладок нередко открыто (простыми словами - ничего не лагает). Для бэкенда это ложится на сервер, для фронтенда - критично. Плюс ваниль гибче, можно сделать качественный кастомный интерфейс, а все реактоподобные фреймворки очень сильно ограничивают работу с CSS вследствие своей архитектуры. Опять-таки, больше высвободившихся ресурсов на машине пользователя - больше простора для разработки. Реактоподобные фреймворки - очень сильно тормозят страницу при условии загруженности машины пользователя. Да и в целом, с появлением LLM - их время ушло (пока нет, но это дело времени).
Обычная логика создания проекта - изучение языка/чтение документации и прочее, потом уже создание кода.
Так называемый "вайб-кодинг" - это когда ты за полчаса делаешь кривой, но работающий прототип, а потом тупо разбираешь его при помощи всё тех же LLM и допиливаешь. Разницу по скорости работы улавливаете?
LLM это следующее поколении информационных провайдеров, следующее после классических поисковиков, которые все давно мертвы и забиты инфоцыганством (отсюда и появление LLM).
Стоит отметить, что в некоторых сферах публичные LLM мало-применимы из-за большого количества уникального контекста и выход либо за покупкой большого контекстного окна у LLM-провайдера, либо создание локальной LLM.
Очень сильно зависит от используемого языка, мощности модели, поставленных задач и контекстного окна - я могу привести не менее ста реальных, постоянно встречающихся задач, которые большинство современных LLM с успехом решают.
Я тут нарисовал простую схему, исходя из собственного опыта (может отличаться от вашего, так как LLM и способов и сфер их применения - сотни и тысячи).
Вопрос в выделенном контекстном окне LLM-провайдером. Скормить можно всё, что угодно, а какое по размеру контекстное окно выделено на бэкенде LLM-провайдера? Или LLM просто галлюционирует за его пределами? В случае с локальной LLM - ок (можно какое-угодно контекстное окно создать, вопрос только в скорости выполнения запроса), в случае с провайдером это всегда вопрос жадности или личных договоренностей. "Развитие" - тут (в большинстве случаев) только вопрос выделенной серверной мощности.
Речь шла о принципах лежащих в основе всех LLM, а не об эффективности различных моделей, которых на данный момент десятки тысяч.
При условии
правильного изначального процесса обучения LLM, т.е., базовые принципы программирования, документация языка/фреймворка/бибилиотеки и прочее (а тут надо сказать, что с этим проблем нет и практически все основные LLM модели себя зарекомендовали как абсолютно надёжные в этом вопросе)
достаточной базы знаний
достаточного контекстного окна
достаточной информации в запросе к LLM
то возможность ошибки LLM стремится к нулю. Она не абсолютно нулевая, но околонулевая, где-то в районе одного шанса на гугол () (абстрактно, точное число мне неизвестно, но с каждой новой итерацией новых поколений LLM - вероятность падает экспоненциально, сейчас можно сказать уже практически нулевая).
Конкретно в случае с используемой вами моделью, выделенным ей контекстным окном (т.е., в случае с LLM-провайдерами - выделенной под вашего пользователя серверной мощностью), базой обучения, базой знаний, изначальным качеством модели, качеством кода скормленных ей проектов - всё это неизвестные параметры. Если вам выделено малое контекстное окно и LLM не хватает информации в запросе - то даже самая лучшая LLM не даст правильный ответ, просто начнёт галлюционировать с разной степенью вероятности успеха (иногда очень даже удачно, надо отметить). Если же вы используете даже LLM пятилетней давности, даже если установленную локально (дома, в серверной, на выделенном сервере, в облаке или в дата-центре - не важно), с достаточной базой знаний и достаточным контекстным окном - это будет более эффективно, при наличие всех необходимых данных в запросе к LLM.
Ну хорошо, "скорость работы как самого программиста возросла экспоненциально"
при условии использования популярного языка на базовых задачах
при условии отсутствия редких языков/фреймворков/библиотек для которых малая база знаний
при условии достаточного контекстного окна
Т.е., если LLM отвечает двум простым требованиям:
Достаточная база знаний
Достаточное контекстное окно
То она не может ошибиться, тупо исходя из базовых законов*/принципов информатики. Это как смена ламп на кремний, а точнее смена гугла на нейронки, потому что нейронка, по большому счёту, это информационный провайдер, чем и являлись поисковики.
* - например: "Любую проблему в компьютерной науке можно решить с помощью еще одного уровня косвенности, за исключением, конечно, проблемы слишком большого количества косвенностей"
Конкретно про SVG - структура SVG сама по себе такова, что под неё надо отдельную нейронку писать, с одной стороны, простейшая геометрия, с другой стороны, нейронок понимающих геометрию пока что - и нет! Как с чертежами в автокаде. Пока ещё - ручной труд.
б) глубокое понимание архитектуры языка на котором генерируется код
Т.е., не мидл-разработчик не может выполнять мидловские задачи. Вопрос в том, что теперь скорость работы как самого программиста возросла экспоненциально (здесь можно привести много исключений, но исключения, как известно, подтверждают правило), так и путь от джуна к мидлу - сократился (опять-таки, здесь можно привести множество исключений, но ... ) раз так в десять, то есть, примерно на порядок. Сделаем ремарку - сократился в плане скиллов, а не в плане "уверенности их практического применения". Просто, когда ты получаешь рабочий код, идеально соответствующий твоим запросам - скилл растёт молниеносно. Так же сократился и путь от мидла к сеньору, ну и так далее...
Если речь о бэкенде, то никакой проблемы, конечно, в фреймворках нет. Только я не понимаю как наличие фреймворка противоричит работе с LLM, насколько я знаю, все PHP-фреймворки отлично знакомы всем популярным LLM.
Если речь о том, зачем вообще LLM для бэкенд-фреймворков? Ну как зачем? Скорость освоения, построения прототипа. Можно использовать практически любой стек не тратя время на заучивание документации, а выучить всё в процессе, на практике. Написание бойлерплейта. На любом фреймворке вам всё равно придётся писать бойлерплейт, просто он будет короче, пусть и в несколько раз, но это всё равно бойлерплейт.
"Толковый фреймворк" с "толковой LLM" в умелых руках на многое способны. LLM и тут добавляет гибкости и скорости работы.
Смотря на каких задачах.
Отечественные LLM весьма не плохи, между прочим, и, думаю, договорится об увеличении контекстного окна можно очень даже за приемлемые деньги.
Возможно вы удивитесь, но LLM работают с фреймворками точно так же, как и с ванильными языками.
Нет открытого прайса ни у одного LLM-провайдера, там всегда что-то навроде "contact us for details". Слишком хаотичная бизнес-модель для точного ценообразования.
Зачем, когда я могу за два часа для небольшого проекта, написать свой микро-фреймворк, т.е., отсутствие огромной неиспользуемой кодовой базы в рантайме на машине пользователя, где уже несколько сотен вкладок нередко открыто (простыми словами - ничего не лагает). Для бэкенда это ложится на сервер, для фронтенда - критично. Плюс ваниль гибче, можно сделать качественный кастомный интерфейс, а все реактоподобные фреймворки очень сильно ограничивают работу с CSS вследствие своей архитектуры. Опять-таки, больше высвободившихся ресурсов на машине пользователя - больше простора для разработки. Реактоподобные фреймворки - очень сильно тормозят страницу при условии загруженности машины пользователя. Да и в целом, с появлением LLM - их время ушло (пока нет, но это дело времени).
Там, вроде, не какие-то космические деньги, да и у отечественных LLM-провайдеров цены очень демократичные.
Фреймворк - это ещё один уровень абстракции, я думаю, нет смысла объяснять последствия добавления лишнего уровня абстракции.
LLM, в целом и в общем - не про безопасность. LLM - это скорость проектирования. Безопасность лежит на самом разработчике.
Вообще мимо!
Обычная логика создания проекта - изучение языка/чтение документации и прочее, потом уже создание кода.
Так называемый "вайб-кодинг" - это когда ты за полчаса делаешь кривой, но работающий прототип, а потом тупо разбираешь его при помощи всё тех же LLM и допиливаешь. Разницу по скорости работы улавливаете?
LLM это следующее поколении информационных провайдеров, следующее после классических поисковиков, которые все давно мертвы и забиты инфоцыганством (отсюда и появление LLM).
Стоит отметить, что в некоторых сферах публичные LLM мало-применимы из-за большого количества уникального контекста и выход либо за покупкой большого контекстного окна у LLM-провайдера, либо создание локальной LLM.
Очень сильно зависит от используемого языка, мощности модели, поставленных задач и контекстного окна - я могу привести не менее ста реальных, постоянно встречающихся задач, которые большинство современных LLM с успехом решают.
Я тут нарисовал простую схему, исходя из собственного опыта (может отличаться от вашего, так как LLM и способов и сфер их применения - сотни и тысячи).
Вопрос в выделенном контекстном окне LLM-провайдером. Скормить можно всё, что угодно, а какое по размеру контекстное окно выделено на бэкенде LLM-провайдера? Или LLM просто галлюционирует за его пределами? В случае с локальной LLM - ок (можно какое-угодно контекстное окно создать, вопрос только в скорости выполнения запроса), в случае с провайдером это всегда вопрос жадности или личных договоренностей. "Развитие" - тут (в большинстве случаев) только вопрос выделенной серверной мощности.
Речь шла о принципах лежащих в основе всех LLM, а не об эффективности различных моделей, которых на данный момент десятки тысяч.
При условии
правильного изначального процесса обучения LLM, т.е., базовые принципы программирования, документация языка/фреймворка/бибилиотеки и прочее (а тут надо сказать, что с этим проблем нет и практически все основные LLM модели себя зарекомендовали как абсолютно надёжные в этом вопросе)
достаточной базы знаний
достаточного контекстного окна
достаточной информации в запросе к LLM
то возможность ошибки LLM стремится к нулю. Она не абсолютно нулевая, но околонулевая, где-то в районе одного шанса на гугол (
) (абстрактно, точное число мне неизвестно, но с каждой новой итерацией новых поколений LLM - вероятность падает экспоненциально, сейчас можно сказать уже практически нулевая).
Конкретно в случае с используемой вами моделью, выделенным ей контекстным окном (т.е., в случае с LLM-провайдерами - выделенной под вашего пользователя серверной мощностью), базой обучения, базой знаний, изначальным качеством модели, качеством кода скормленных ей проектов - всё это неизвестные параметры. Если вам выделено малое контекстное окно и LLM не хватает информации в запросе - то даже самая лучшая LLM не даст правильный ответ, просто начнёт галлюционировать с разной степенью вероятности успеха (иногда очень даже удачно, надо отметить). Если же вы используете даже LLM пятилетней давности, даже если установленную локально (дома, в серверной, на выделенном сервере, в облаке или в дата-центре - не важно), с достаточной базой знаний и достаточным контекстным окном - это будет более эффективно, при наличие всех необходимых данных в запросе к LLM.
Моделей сотни, зависит от задачи.
Хорошая идея.
Ну хорошо, "скорость работы как самого программиста возросла экспоненциально"
при условии использования популярного языка на базовых задачах
при условии отсутствия редких языков/фреймворков/библиотек для которых малая база знаний
при условии достаточного контекстного окна
Т.е., если LLM отвечает двум простым требованиям:
Достаточная база знаний
Достаточное контекстное окно
То она не может ошибиться, тупо исходя из базовых законов*/принципов информатики. Это как смена ламп на кремний, а точнее смена гугла на нейронки, потому что нейронка, по большому счёту, это информационный провайдер, чем и являлись поисковики.
* - например: "Любую проблему в компьютерной науке можно решить с помощью еще одного уровня косвенности, за исключением, конечно, проблемы слишком большого количества косвенностей"
Конкретно про SVG - структура SVG сама по себе такова, что под неё надо отдельную нейронку писать, с одной стороны, простейшая геометрия, с другой стороны, нейронок понимающих геометрию пока что - и нет! Как с чертежами в автокаде. Пока ещё - ручной труд.
Что бы эффективно пользоваться LLM нужно
а) глубокое понимание работы с LLM
б) глубокое понимание архитектуры языка на котором генерируется код
Т.е., не мидл-разработчик не может выполнять мидловские задачи. Вопрос в том, что теперь скорость работы как самого программиста возросла экспоненциально (здесь можно привести много исключений, но исключения, как известно, подтверждают правило), так и путь от джуна к мидлу - сократился (опять-таки, здесь можно привести множество исключений, но ... ) раз так в десять, то есть, примерно на порядок. Сделаем ремарку - сократился в плане скиллов, а не в плане "уверенности их практического применения". Просто, когда ты получаешь рабочий код, идеально соответствующий твоим запросам - скилл растёт молниеносно. Так же сократился и путь от мидла к сеньору, ну и так далее...
Skill issue