Да, вы правы. Плюс я пишу в статье выше про SLM. Условно маленькие языковые модели, на основе которых как раз и будут делать специализированных агентов. Это действительно явный тренд и многие уже так и делают.
>>Можете подсказать, с вашей, личной точки зрения, на сколько % увеличилась скорость выполнения задач с LLM? Зависит от задач. Так тяжело прям точно сказать. Какие-то задачи, которые ранее невозможно было выполнить разработчику одному, теперь стали возможными. Также всё зависит от стэка, размера репозитория, объема необходимого контекста (доменных знаний) для понимания в целом задачи.
>>Были ли у вас джуниоры до LLM? Если да то, остались ли они с сопоставимой нагрузкой? Да, конечно в ВК ТЕХ были и есть джуниоры, и останутся далее) Насчет нагрузки на них, не подскажу.
>>Субъективно процесс работы с LLM воспринимается как более легкий, более сложный, чем без LLM. Воспринимается как другой. В чем то сложнее, в чем то легче. Представьте, что вы тимлид команды ai джуниоров, которые постоянно делают ошибки и норовят всё сломать, если за ними не присматривать и не ставить четкие задачи и границы.
>>Внедрение LLM изменило радикально или очередной более мощный калькулятор? По моему мнению, LLM это точно не очередной более мощный калькулятор. LLM это новая атомная бомба. Вещь/событие, которое разделило мир на до и после.
Сравнивать подобные сервисы между собой - это неблагодарное занятие. Больше времени уйдет на интеграции с описанными вами решениями. При этом внутри будут тонкости, которые приведут к некорректному сравнению и невоспроизводимым результатам. Разные настройки промптов, пайплайнов и не только. Необходимо открытое API и единый прозрачный процесс доступа.Например, как OpenRouter, но для перечисленных сервисов.
Pythia-12B взял по нескольким причинам: - полностью Open source с возможностью коммерческого использования; - оптимальное число параметров с учетом доступных на тот момент ресурсов для обучения; - поддержка из коробки данной модели в различных библиотеках как при fine tunning, так и при serving; Смотрел еще множество разных моделей. Все сейчас не вспомню. Они не подходили, либо по модели лицензирования, либо по числу параметров, уровню поддержки в популярных библиотеках.
Относительно датасета. Это датасет в формате Вопрос/Ответ. Собран был частично из датасетов Dolly и Alpaca на русском языке, далее дополнен по модели Alpaca по требуемым темам и задачам.
MLflow и Kubeflow позиционируют себя как платформы полного цикла при решения MLOps задач. Поэтому и сравнивают) При этом инструменты сильно отличаются по функционалу между собой.
Делают акцент на разные фичи. MLflow больше про воспроизводимость и трекинг экспериментов, единый реестр моделей, а Kubeflow больше про пайплайны внутри кубера плюс управление ресурсами внутри кубера под задачи DS.
Kubeflow, скорее всего, не поможет вам в решении задачи. По умолчанию Kubeflow не распараллелит за вас data science эксперименты. Нужно смотреть какой фреймворк используете. Умеет ли он работать в кластерном режиме. Предлагаю вам для начала посмотреть в сторону Spark. Его кстати тоже можно запускать в кубере. www.youtube.com/watch?v=fYGc4elKW-g
Да, вы правы. Плюс я пишу в статье выше про SLM. Условно маленькие языковые модели, на основе которых как раз и будут делать специализированных агентов.
Это действительно явный тренд и многие уже так и делают.
Python
>>Можете подсказать, с вашей, личной точки зрения, на сколько % увеличилась скорость выполнения задач с LLM?
Зависит от задач. Так тяжело прям точно сказать. Какие-то задачи, которые ранее невозможно было выполнить разработчику одному, теперь стали возможными.
Также всё зависит от стэка, размера репозитория, объема необходимого контекста (доменных знаний) для понимания в целом задачи.
>>Были ли у вас джуниоры до LLM? Если да то, остались ли они с сопоставимой нагрузкой?
Да, конечно в ВК ТЕХ были и есть джуниоры, и останутся далее)
Насчет нагрузки на них, не подскажу.
>>Субъективно процесс работы с LLM воспринимается как более легкий, более сложный, чем без LLM.
Воспринимается как другой. В чем то сложнее, в чем то легче. Представьте, что вы тимлид команды ai джуниоров, которые постоянно делают ошибки и норовят всё сломать, если за ними не присматривать и не ставить четкие задачи и границы.
>>Внедрение LLM изменило радикально или очередной более мощный калькулятор?
По моему мнению, LLM это точно не очередной более мощный калькулятор. LLM это новая атомная бомба. Вещь/событие, которое разделило мир на до и после.
в боте есть контакты поддержки. Плюс, если ему задать вопрос как обратиться в поддержку, он тоже ответит.
Сравнивать подобные сервисы между собой - это неблагодарное занятие. Больше времени уйдет на интеграции с описанными вами решениями. При этом внутри будут тонкости, которые приведут к некорректному сравнению и невоспроизводимым результатам. Разные настройки промптов, пайплайнов и не только.
Необходимо открытое API и единый прозрачный процесс доступа.Например, как OpenRouter, но для перечисленных сервисов.
Руслан, с помощью промптинга. Дополнительных инструкций на этапе HyDE и последующих этапах.
Pythia-12B взял по нескольким причинам:
- полностью Open source с возможностью коммерческого использования;
- оптимальное число параметров с учетом доступных на тот момент ресурсов для обучения;
- поддержка из коробки данной модели в различных библиотеках как при fine tunning, так и при serving;
Смотрел еще множество разных моделей. Все сейчас не вспомню.
Они не подходили, либо по модели лицензирования, либо по числу параметров, уровню поддержки в популярных библиотеках.
Относительно датасета. Это датасет в формате Вопрос/Ответ.
Собран был частично из датасетов Dolly и Alpaca на русском языке, далее дополнен по модели Alpaca по требуемым темам и задачам.
MLflow и Kubeflow позиционируют себя как платформы полного цикла при решения MLOps задач. Поэтому и сравнивают)
При этом инструменты сильно отличаются по функционалу между собой.
Делают акцент на разные фичи. MLflow больше про воспроизводимость и трекинг экспериментов, единый реестр моделей, а Kubeflow больше про пайплайны внутри кубера плюс управление ресурсами внутри кубера под задачи DS.
github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/docs/user-guide.md#specifying-deployment-mode
A SparkApplication should set .spec.deployMode to cluster, as client is not currently implemented. The driver pod will then run spark-submit in client mode internally to run the driver program. Additional details of how SparkApplications are run can be found in the design documentation.
Если через spark-submit, то можно client и cluster режим использовать.
Подробнее можно здесь почитать
www.lightbend.com/blog/how-to-manage-monitor-spark-on-kubernetes-introduction-spark-submit-kubernetes-operator
Насчет jupyter не подскажу. Есть подробная документация, надеюсь будет полезна
zero-to-jupyterhub.readthedocs.io/en/latest
www.youtube.com/watch?v=fYGc4elKW-g