Важность нетворкинга в вашей жизни 🌐

Во время отпуска, я решил почитать достаточно известную книгу Кейта Феррацци "Никогда не ешьте в одиночку" 📚, которая произвела на меня большое впечатление.
В последний день перед рабочей неделей, я посетил мероприятие Selectel DayOff 2024, проходившее 14 июля. И что меня удивило и порадовало – идеи, изложенные в недавней новой для меня книге, нашли своё отражение в одном из докладов трека "Про карьеру" на этом событии: “Человеку нужен человек. Как развивать карьеру с помощью нетворкинга” 🤝.

Прочитав книгу ранее, я узнал много полезного о нетворкинге и его значении для личного и профессионального роста. И вот несколько ключевых идей из книги, которые также были затронуты на мероприятии:

1. Проактивность. Важно быть проактивным в установлении контактов, инициируя встречи и знакомства самостоятельно. Это ключ к успешному нетворкингу, так как ожидание, что кто-то сам подойдёт, редко приносит результаты.
2. Искренность и взаимопомощь. Успешный нетворкинг строится на искренних и взаимовыгодных отношениях. Проявление подлинного интереса к людям и готовность помогать им являются основой для долгосрочных связей.
3. Долгосрочные отношения. Быстрые и поверхностные знакомства редко приводят к значительным результатам. Важно строить долгосрочные отношения, основанные на доверии и уважении, и поддерживать уже существующие контакты.
4. Взаимная выгода. Наверное, самый важный и одновременно не сразу понятный пункт, который лучше изучить, прочитав книгу. Нетворкинг должен приносить пользу обеим сторонам. Успешные отношения строятся на принципе взаимной выгоды, где обе стороны помогают друг другу достигать своих целей.
Здесь стоит исходить из идеи “Чем я могу помочь тебе?”, нежели, “Что ты можешь для меня сделать?”.
Простыми словами, при одинаковой данной моральной установке с собеседником, вы сможете улучшать друг друга в разных аспектах, не упираясь в барьеры по типу “Я тебе помог, теперь твоя очередь”.

Посетив мероприятие и вспомнив идеи из книги, я еще раз убедился, что нетворкинг – это мощный инструмент для развития карьеры и личностного роста 🚀

Не забывайте, что человек нужен человеку. Стройте свои сети контактов, помогайте другим, и ваши усилия обязательно принесут плоды 🌱

#it_conferences

🛠️ Мануал по Agile: как количество людей влияет на производительность

Многие слышали о методологии Agile и имеют общее представление о том, что это такое. Если открыть учебники или статьи на Хабре про Scrum, часто можно увидеть, что оптимальный размер команды составляет около 8 человек. Но что происходит, если команда начинает расти?

💻 Работая в IT, я прошел через множество команд и различные этапы их развития. И хочу поделиться интересным наблюдением — как рост команды влияет на производительность.

Когда я начинал, мне посчастливилось работать в небольшой команде из 3 DevOps-инженеров. У нас было много преимуществ: мы работали быстро, решения принимались мгновенно, и каждый знал, кто за что отвечает.
Единственный минус — не всегда хватало рабочей силы для выполнения всех задач.

📈 Со временем наша команда начала расширяться. Это был интересный период: новые люди принесли свежие идеи и экспертизу в тех области технологий, в которых другие члены команды были менее компетентны.
Производительность действительно возросла, но вместе с этим увеличилось и количество процессов, которые требовали внимания. Нам пришлось не только правильно разделять задачи, но и обеспечивать эффективное взаимодействие, чтобы никто не выпадал из общей картины происходящего.

⚠️ Однако, в какой-то момент мы решили еще больше расширить команду, чтобы охватить еще больший объем задач. И это стало нашей ошибкой. Мы столкнулись с неожиданными проблемами: количество встреч резко возросло, многие члены команды перестали понимать, кто чем занимается, и эффективность снизилась. Появилось множество ненужных встреч и синков. Время, затрачиваемое на обсуждения, увеличилось — на примере дейликов большее количество человек стало тратить больше времени на высказывания и обсуждения.

Возникло ощущение, что вместо ускорения процесса разработки мы, наоборот, начали замедляться.

🤔 Какие же выводы можно сделать из этой истории?

1. Коммуникационные барьеры. В малых командах информация передается быстрее, решения принимаются оперативно. С увеличением числа участников растет количество коммуникационных каналов, что замедляет процесс согласования.

2. Сложность координации. По мере роста команды увеличивается количество задач и зависимостей. В результате, больше времени уходит на планирование и управление ресурсами, что замедляет процесс разработки.

3. Личная ответственность. В чрезмерно больших командах ответственность за конкретные задачи может стать размытой. Это снижает личную вовлеченность каждого участника, что негативно сказывается на сроках выполнения задач. Это приводит не только к потере общего направления развития, но и к усилению выгорания отдельных людей.

4. Принцип Брукса. Фредерик Брукс писал в своей книге "Мифический человеко-месяц", что добавление новых сотрудников к запаздывающему проекту делает его еще более запаздывающим. Этот принцип актуален и сегодня, особенно в контексте чрезмерного расширения команды.

Оптимальный размер команды и проработанность процессов — ключевые факторы для успешного выполнения проектов.
С увеличением числа участников нужно усложнять и процессы взаимодействия. Однако сложные процессы должны быть в меру сложными. Важно находить баланс в размерах и в случае огромных проектов, разделять команды на несколько отдельных.

А что вы думаете на этот счет? Какие меры принимались у вас в командах для повышения производительности?

💊 JupyterHub на стероидах: реализация KubeFlow-фич без масштабных интеграций

Долго думал над названием, так как было много интересных вариантов. Но если коротко — вчера вышла моя новая статья на Хабре, основанная на выступлении на DevOps Conf 2024.

В статье я рассказываю, как легко настроить динамическую аллокацию ресурсов Kubernetes в JupyterHub, а также внедрить полезные функции, такие как права доступа на основе групповой политики. Кроме того, вы найдете советы по сборке Jupyter/JupyterLab образов.

В конце статьи также есть ссылка на GitHub репозиторий, который можно запустить, следуя инструкции в readme.

Читать статью

Что такое JupyterLab и почему он так популярен в Big Data? 🚀

В мире машинного обучения и Big Data ключевую роль играют инструменты, которые помогают специалистам эффективно работать с огромными массивами данных и строить модели. Одним из таких инструментов является JupyterLab — интерактивная среда для разработки, которая позволяет выполнять код и анализировать данные в реальном времени.

JupyterLab стал особенно популярным среди дата-сайентистов, аналитиков и других специалистов в области машинного обучения благодаря своей простоте и гибкости. Он позволяет легко писать код в специальных файлах — Jupyter-ноутбуках, сразу видеть результаты выполнения, строить графики и добавлять пояснительный текст.
Такой подход делает процесс исследования данных и разработки моделей более наглядным и удобным 📊

Для сравнения: при работе с обычными скриптами в .py файлах, вам приходится писать код целиком, запускать его полностью и только потом видеть результат. Этот процесс может быть неудобным, особенно если требуется много итераций и частых изменений. JupyterLab решает эту проблему за счёт возможности выполнять код по частям (в ячейках) и мгновенно видеть результаты⚡

Преимущества разработки в JupyterLab 🔥

1. Интерактивная работа с кодом.
Когда вы работаете с обычным .py файлом, вы пишете весь код, затем запускаете его, ожидая результата. В случае ошибок или необходимости что-то изменить, вам нужно исправлять код и запускать его заново. В Jupyter Notebook вы можете запускать отдельные блоки кода и сразу видеть результат, что значительно ускоряет работу.
Это особенно полезно, когда вам нужно загрузить большой датасет, выполнить над ним операции, а затем, если что-то пойдёт не так, просто изменить нужный блок кода и запустить его заново, не перезапуская весь скрипт и не загружая данные снова 🔄

2. Визуализация данных.
В машинном обучении и анализе данных часто приходится строить графики и визуализировать результаты. Особенность JupyterLab заключается в том, что вы можете выводить все графики прямо в свой Notebook с помощью функций таких библиотек, как matplotlib, plotly, seaborn и тд 📈

3. Комбинирование кода и текста.
В Jupyter ноутбуках вы можете писать не только код, но и пояснительный текст с использованием Markdown — языка разметки. Это очень удобно для создания отчётов, презентаций или документирования своей работы.
В обычных .py файлах можно оставлять только комментарии, что не так наглядно и менее удобно для представления результатов и объяснений 📄

В итоге, JupyterLab стал незаменимым инструментом для специалистов по данным и машинному обучению, так как он существенно упрощает процесс разработки и анализа данных по сравнению с классическим подходом написания кода в .py файлах 🧠💻

В следующих постах я расскажу про различные платформы на базе Jupyter, их преимущества и о том, когда удобнее всего использовать каждую из них 🎯

Платформы на базе Jupyter: что выбрать и когда использовать? 💡

После того как мы обсудили популярность JupyterLab, давайте рассмотрим его аналоги — платформы, созданные на основе Jupyter ноутбуков. Каждая из них имеет свои особенности и преимущества, что делает их более подходящими для определённых задач. Разберём наиболее популярные варианты и поймём, когда их лучше использовать.


1. DataLore (JetBrains) 💻

DataLore — это облачная платформа от компании JetBrains, известной своими мощными IDE для разработки. Она позволяет работать с Jupyter ноутбуками, но предоставляет гораздо больше возможностей: интеллектуальная поддержка кода, совместная работа и удобное управление облачными ресурсами.

Особенности и преимущества:
1. Умное автодополнение и рефакторинг кода с ИИ. DataLore использует алгоритмы для подсказок и улучшений кода, что ускоряет процесс разработки.
2. Облачные вычисления и автоматическое управление ресурсами. Вы можете запускать свои задачи в облаке, что особенно полезно при работе с большими объёмами данных. Платформа автоматически управляет ресурсами, избавляя вас от необходимости настройки серверов.
3. Поддержка командной работы. Классная фича, которая позволяет нескольким пользователям одновременно редактировать и комментировать один и тот же ноутбук.
4. Интерактивный output ячеек. Можно взаимодействовать с результатами выполнения прямо в интерфейсе, используя встроенные инструменты для визуализации данных и анализа.
5. Управление данными через единый интерфейс. Работа с данными, SQL-запросами, S3-хранилищами и файлами доступна прямо в интерфейсе без необходимости переключения между разными инструментами.

Когда использовать:
DataLore лучше всего подходит для командных проектов, где важна возможность совместной работы. Также данный проект будет интересен тем, кто предпочитает работать в облаке с большими ресурсами и не хочет заниматься настройкой серверов и окружений.


2. Google Colab 🌐

Google Colab — это бесплатная облачная платформа для работы с Jupyter ноутбуками, интегрированная с Google Drive. Она позволяет запускать Python-код прямо в браузере и использовать бесплатные вычислительные мощности, включая GPU и TPU.

Особенности и преимущества:
1. Облачная работа. Нет необходимости устанавливать окружение — вы можете создать ноутбук и сразу начать работать.
2. Бесплатные вычислительные ресурсы. Google предоставляет бесплатный доступ к GPU и TPU для ускоренного выполнения задач (есть почасовая оплата для более мощных карт).
3. Интеграция с Google Drive. Вы можете легко делиться ноутбуками через облако, а также легко загружать и сохранять датасеты.
4. Простота использования. Идеально для быстрого старта и проведения экспериментов, для начинающих пользователей.

Когда использовать:
Google Colab отлично подходит для небольших проектов, обучения и тестирования моделей, где может потребоваться ускоренние от использования GPU. Это лучший выбор, если вам нужно быстро запустить эксперимент без настройки оборудования.


3. Kaggle Notebooks 🏆

Kaggle — платформа для соревнований по машинному обучению, и Kaggle Notebooks предлагают удобную среду для работы с данными прямо на сайте. Главная особенность заключается в возможности использовать ноутбуки для работы с реальными датасетами из соревнований, что делает его отличным инструментом для исследовательской работы.

Особенности и преимущества:
1. Готовые датасеты. Киллер фича платформы. Вы имеете прямой доступ к огромному количеству датасетов для анализа и экспериментов, а также можете изучить готовые решения от других пользователей.
2. Встроенные соревнования. Мгновенная интеграция с Kaggle Competitions для участия в соревнованиях по ML.
3. Облачные ресурсы. Бесплатные вычислительные мощности как и на Google Colab, включая GPU, для обучения сложных моделей.

Когда использовать:
Kaggle Notebooks лучше всего подходят для тех, кто участвует в соревнованиях по машинному обучению или просто хочет попробовать себя в работе с реальными данными. Это идеальный инструмент для прокачивания своих навыков, а также для исследований и учебных проектов.

4. Azure Notebooks ☁️

Azure Notebooks — облачная платформа от Microsoft, которая позволяет работать с Jupyter ноутбуками прямо в облаке Azure. Она интегрируется с другими сервисами Azure, что делает её полезной для масштабных корпоративных решений.

Особенности и преимущества:
1. Интеграция с Azure. Возможность использования других сервисов Microsoft Azure для работы с большими данными и их хранения.
2. Масштабируемость. Легко масштабировать вычислительные ресурсы в зависимости от требований проекта.
3. Поддержка различных языков. Помимо Python, поддерживаются и другие языки, такие как R и F#.

Когда использовать:
Azure Notebooks стоит выбирать, если ваш проект требует интеграции с облачными сервисами Microsoft или вам нужно масштабировать мощности в зависимости от нагрузки. Это классное решение для больших корпоративных проектов.


5. Kubeflow Notebooks 🧩

Kubeflow Notebooks — это часть платформы Kubeflow, разработанной для управления проектами в сфере машинного обучения на Kubernetes. Kubeflow Notebooks предлагают возможность запуска Jupyter ноутбуков на мощностях кластеров Kubernetes, что особенно полезно для масштабируемых и распределённых вычислений.

Особенности и преимущества:
1. Интеграция с Kubernetes. Автоматическое управление и масштабирование ресурсов с помощью Kubernetes, а также использование различных встроенных ресурсов (сущностей).
2. Распределение нагрузок. Вы можете распределить задачи на несколько узлов, что идеально подходит для работы с большими данными и тренировки крупных моделей.
3. Управление жизненным циклом ML-проектов. Сам проект Kubeflow позволяет управлять всем процессом разработки ML-проектов, начиная с экспериментов в ноутбуках и заканчивая развёртыванием моделей в production.

Когда использовать:
Kubeflow Notebooks отлично подходят для корпоративных проектов с большими требованиями к масштабируемости и распределённым вычислениям. Однако в отличии от облачных вычислений, для установки Kubeflow, вам потребуется достаточно сильный DevOps/MLOps специалист.
Если у вас есть штат MLOps-инженеров, сложные проекты машинного обучения, которые требуют интеграции с кластерами Kubernetes, возможность некоторой кастомизации и вы хотите автоматизировать рабочий процесс, Kubeflow — отличный выбор.


Давайте подытожим. Каждая платформа на базе Jupyter имеет свои сильные стороны и подходит для определённых задач:

1. DataLore — для командной работы и облачных проектов, требующих мощных инструментов разработки.
2. Google Colab — для быстрого старта, экспериментов с машинным обучением и использования бесплатных GPU.
3. Kaggle Notebooks — для участия в соревнованиях по ML и исследовательских проектов с готовыми датасетами.
4. Azure Notebooks — для корпоративных решений, которые требуют интеграции с облачными сервисами и масштабируемостью.
5. Kubeflow Notebooks — для сложных и масштабируемых проектов на базе Kubernetes с полным управлением жизненным циклом машинного обучения.

В зависимости от ваших задач, выбирайте инструмент, который поможет вам максимально эффективно работать с данными и моделями. 🔧


В следующих постах, я бы хотел достаточно сильно углубиться в сторону использования Kubeflow, как полноценной платформы для команд разработки. Однако из-за того, что он ставится поверх Kubernetes, то перед этим будет также будет некоторый цикл постов, посвященных обзору последнего.
Также я скоро планирую поделить посты на разный уровень сложности и настроить некоторую навигацию по тегам. 🎯

Всем привет!

Давно не было постов, но зато у меня накопилось много интересного, о чем рассказать! 🙌

Из последних новостей: на этих выходных я решил поучаствовать в хакатоне «Цифровой Прорыв. Сезон: Искусственный интеллект» вместе с друзьями из универа. Задача оказалась довольно интересной, а технологии, которые мы применили, настолько мощные, что хочется поделиться ими более подробно.

В ближайших постах я расскажу как раз о нашем подходе и технологии, которая позволила нам зайти немного нестандартным путем и сделать классное решение!

Следите за обновлениями — будет много полезного! 🚀

Иногда реальные результаты могут превысить ожидания 🍀

🚀 Недавно на хакатоне получилось занять первое место, хотя шел я туда, честно говоря, просто поизучать новую, интересную для себя технологию. Тем не менее, все получилось даже лучше, чем ожидалось. А теперь давайте расскажу поподробнее про технологию и наше решение.

Задача на хакатоне была сформулирована не суперчетко, но мы поняли её так: нужно как-то обработать большой список товаров и выделить их ключевые характеристики.

В таблицах, которые нам дали, было также поле с кодами ОКПД2 — это такой общероссийский классификатор, который присваивает каждому товару свою группу.

Но есть пара проблем:

1. ОКПД2 — это просто классификация товаров, никаких конкретных параметров типа размеров или веса он не содержит. Он просто говорит, что товар относится к определенной категории, и всё (пример кодов на картинке ниже).

2. Параметры товаров записаны в строках. В таблице было поле с параметрами, которое нам и нужно было как-то распарсить. Проблема в том, что эти параметры записаны в хаотичном виде.
Например, строка вроде "120х80 RPPD 20кг" — в ней можно увидеть, что у товара есть размеры и вес, но что такое RPPD? Известно только Богу (или читавшему ГОСТ, как мы поняли чуть позже) 🤷‍♂️

Так как хакатон был посвящен теме ИИ, первая идея — взять LLM и просто дать ей все эти строки. Но ведь LLM сама по себе не поймет, что такое, например, RPPD.

Из дополнительной информации: нам также дали несколько сайтов, которые содержат эти товары и могли бы помочь, если идти с идеей распарсинга данных.
Но это было бы долго и ненадежно: каждый сайт имеет свою разметку, а API предоставляют не все.

🎯 Наша идея

Зато в датасете мы нашли поле ГОСТ для каждого товара. И тут нас осенило! Ведь ГОСТы содержат в себе всю информацию о товаре, которая нам как раз и нужна.
Таким образом, наша идея заключалась в том, чтобы предоставить некий доступ к ГОСТам для LLM, чтобы она "знала" их и могла выдавать ответы, ориентируясь на эти данные.

Так мы решили подключить технологию RAG (Retrieval-Augmented Generation). О ней в следующем посте, но если коротко, то она позволяет передавать LLM нужный контекст на лету, не переобучая её.

Вот наш план:
1. Вытаскиваем из ГОСТов ключевые данные о товарах.
2. Передаем эти данные LLM — теперь она может понять контекст и работать более осмысленно.
3. Получаем ответ от LLM, который легко перевести в таблицу ведь ответ мы просим её сделать по шаблону, и данные становятся упорядоченными, готовыми для анализа.

Так мы сделали решение, которое было высоко оценено жюри, и его можно улучшать и масштабировать.
Вишенкой на торте стало то, что, чем больше другие команды будут улучшать обработку ГОСТов, добавлять функционал по парсингу или дорабатывать LLM, тем сильнее станет наш подход, ведь он гибок и может сочетать в себе все эти методы.

Подробности о том, что такое RAG и как мы решили использовать эту технологию — в следующем посте! 🎉

🚀 Продолжаем разбирать интересные технологии!

Как и обещал, давайте поговорим о том, что такое RAG (Retrieval-Augmented Generation) и почему эта технология оказалась такой полезной для нас на хакатоне.

🤔 Что такое RAG Pipeline?

RAG Pipeline — это гибридный подход, который совмещает два мощных инструмента: поиск информации (retrieval) и генерацию текста (generation).
Его суть в том, что модель генерации (LLM-ка) перед тем, как начать отвечать, получает дополнительный контекст с помощью поиска по внешним источникам данных. Это позволяет модели давать более точные и актуальные ответы, даже если у неё изначально нет всей нужной информации.

🔍 Где обычно используют RAG?

1. Чат-боты. Один из самых популярных сценариев использования RAG, когда модель может отвечать на вопросы пользователей, подтягивая свежие данные из базы знаний или документов.
2. Поиск знаний. Если у вас есть большая база знаний, то вы можете настроить осмысленный поиск по ней. Это значительно упрощает работу с информацией, особенно когда происходит ссылка между различными документами и проходится метаться между ними.

Как мы использовали RAG на хакатоне?

Обычно RAG применяется для поиска информации в текстах, статьях или базах знаний. Но мы решили пойти немного дальше и использовать его для решения более прикладной задачи — обработки данных.
Вместо того чтобы обучать модель на всех данных или заниматься классическим парсингом, мы дали нашей LLM возможность динамически "подсматривать" в ГОСТы и другие внешние источники перед каждым ответом.

Почему это круто?

1. Гибкость. С RAG нам не нужно переобучать модель на всём массиве данных или пытаться поместить их в память модели. Она подтягивает нужную информацию прямо в момент запроса.
2. Актуальность. Данные (как и ГОСТы в нашем примере) могут меняться. Если мы решим закладывать их в модель напрямую, то нам придется переобучать её каждый раз. С RAG pipeline модель всегда работает с актуальной информацией.

Таким образом, RAG позволяет нам не только создавать умные ответы, но и делать это с минимальными трудозатратами на обновление данных.

🎯 В следующем посте я расскажу, как устроен RAG изнутри — что такое векторные базы, embeddings и как они помогают находить нужные данные для LLM. Не пропустите!

🚀 Погружаемся в технику: как работает RAG Pipeline

В прошлом посте мы обсудили, что такое RAG (Retrieval-Augmented Generation) и как эта технология помогает моделям давать более точные ответы за счёт поиска информации в реальном времени. Теперь давайте углубимся в техническую сторону и разберём, как всё это работает под капотом. К тексту прилагаются ссылки на полезные источники с более подробным разбором терминов и технологий.

Как работает RAG Pipeline?

RAG Pipeline сочетает поиск информации и генерацию текста с помощью языковой модели (LLM). Процесс можно разбить на несколько ключевых шагов:

1. Векторизация запроса. Когда модель получает запрос, например, текстовое описание товара или вопрос пользователя, этот текст превращается в векторное представление с помощью нейросетевой модели embeddings. Векторы — это числовые представления текста, которые отражают его семантическое значение. Подробнее о векторизации и embedding-моделях можно почитать здесь.

2. Поиск по векторной базе. После того как запрос превращён в вектор, он сравнивается с векторами в векторной базе данных. В этой базе хранятся векторные представления всех доступных документов, статей или других данных. Сравнение происходит по схожести векторов — ищутся самые близкие к запросу векторы с помощью, например, косинусного сходства, Евклидова расстояния и других.

🧠 Векторная база — это не обычная база данных. Она оптимизирована для поиска по схожести векторов, что позволяет быстро находить нужные фрагменты информации даже в огромных массивах данных. Популярные технологии для таких баз:
- FAISS от Facebook — эффективный инструмент для поиска по векторным базам, который поддерживает миллионы векторов и различные методы оптимизации.
- HNSW (Hierarchical Navigable Small World) — ещё одна технология для поиска по векторным пространствам, которая используется в многих современных приложениях благодаря своей скорости и точности.

3. Извлечение релевантных данных. Как только найдены наиболее подходящие документы, они возвращаются модели в виде текстовых фрагментов. Эти фрагменты являются дополнительным контекстом, который помогает модели более точно ответить на запрос.

4. Генерация ответа. Теперь, используя как сам запрос, так и релевантные фрагменты из векторной базы, LLM формирует финальный ответ. Это может быть как полный текстовый ответ, так и результат в структурированном формате (как табличка в задаче на хакатоне из прошлых постов).

Что такое embedding и как он работает?

Пусть выше уже упоминалось данное слово, но дадим определение здесь. Embedding — это способ перевода текстовых данных в числовые вектора, которые содержат информацию о семантическом смысле текста. Чем ближе по смыслу два текста, тем более похожими будут их векторы.

Модели, такие как BERT, GPT или другие нейросетевые языковые модели, используются для создания этих embeddings. Каждый документ или текстовый фрагмент в базе данных также проходит через этот процесс. В результате все данные превращаются в векторные представления, которые можно быстро и эффективно сравнивать друг с другом. Далее это как раз и позволяет RAG находить документы, даже если они не содержат точных совпадений по ключевым словам, а основываются на семантической близости.

В заключение, RAG Pipeline — это мощная технология, которая объединяет несколько ключевых решений: векторные базы, embeddings и языковые модели. Она позволяет модели всегда работать с актуальной информацией, не требуя постоянного переобучения. Это делает RAG особенно полезной для задач, где важна гибкость и масштабируемость, ведь модель может быстро получать свежие данные и давать более точные ответы.

🚀 Друзья, вышло мое интервью про MLOps!

Если вы хотите понять, что такое MLOps, зачем он нужен и как работает на практике, особенно в таких масштабах, как у нас в AlfaBank, — это видео для вас.

Поговорили о том, какие вызовы решает MLOps, как его внедрить, и что нужно знать, чтобы уверенно шагнуть в эту сферу. Также в интервью есть полезные советы для тех, кто мечтает строить карьеру в MLOps.

Присоединяйтесь, смотрите — будет интересно! 🎥

Всем привет! 👋
Давно не было постов, но я не теряюсь 😉

За последние пару месяцев произошло много интересного, и сегодня я хочу поделиться некоторыми важными новостями.

🚀 Обновление пайплайна моделей
Самое главное и крутое: мы наконец обновили пайплайн вывода моделей! Теперь всё работает через ArgoWorkflow нативно в Kubernetes.
Причем на этом пайплайне мы запускаем не только отдельные модели, но и целые каскады, состоящие из 80 моделей одновременно. Да, это было вызовом, но результат впечатляет!

💻 Новый подход к запуску ноутбуков в кластере
Ещё одна важная тема, о которой расскажу подробнее в ближайшее время: мы обновили подход к запуску ноутбуков на кластере.
Напомню, что в прошлом году мы сделали кастомный спавнер для Jupyter, который позволял запускать ноутбуки в Kubernetes с выделением ресурсов для конкретных пользователей.

Теперь мы доработали концепцию: начали использовать resource quotas и отдельные namespace для каждой команды. Это показалось более перспективным решением, и первые результаты от фокус-группы подтвердили наши ожидания. Полные данные будут после завершения полного переезда, но пока всё выглядит многообещающе.

📊 Мониторинг и логирование
И третий момент, который хотелось бы затронуть, — это мониторинг и логирование. За последнее время мне прилетело много задач в этой области. Я хотел бы поделиться своими мыслями и подходами, которые, возможно, будут полезны и вам.

Оставайтесь на связи, скоро будет больше деталей!

🚀 Новый пайплайн деплоя моделей с помощью Argo Workflows

Сегодня хочу рассказать о нашей новой фиче — пайплайне для вывода моделей в прод с помощью Argo Workflows. Если кратко: теперь это быстро, прозрачно и воспроизводимо.

💡 Зачем вообще Argo?
Argo Workflow — это Kubernetes-native инструмент для управления workflow’ами. А для нас это значит: можно собирать весь процесс вывода модели от загрузки артефактов до деплоя только лишь используя всем привычные Helm чарты.

🛠 Что внутри пайплайна?
Базовая версия включает:

1. Хранение окружений и моделей в MLFlow/S3 без Docker
2. Поднятие моделей только лишь с использованием YAML
3. Запуск подов в соответствии с правилом: 1 Модель - 1 Pod
4. Все шаги изолированы, логируются, можно перезапустить с любого этапа.

🎯 Что это даёт?

1. Ускорение вывода моделей
2. Минимизация ручных ошибок
3. Полная трассировка всех изменений
4. Простота откатов, если что-то пошло не так

Подробнее об этом я рассказываю в докладе на DevOpsConf2025 о котором будет следующий пост.

📦 Скоро залью шаблон в open-source — будет удобно адаптировать под свои задачи.

Если интересно, могу сделать мини-гайд по настройке такого пайплайна — пиши в комменты 😉

🔄 Продолжаю рассказ про Argo Workflows: как построить пайплайн для обучения ML-модели

Я думал как лучше показать пайплайн. Однако у всех кластеры разные. Кто-то хочет использовать какие-то инструменты, а кто-то нет. В это же время у ArgoWF есть достаточно подробная документация и репозиторий с примерами.
Поэтому я решил не делать универсальный пример, который будет работать у всех, а скорее — разобрать ключевые шаги пайплайна и дать ссылки на официальные ресурсы ArgoWF, чтобы каждый мог адаптировать под себя.

Собственно разбор ключевых шагов пайплайна:

1. Загрузка кода модели из Git-репозитория
- - Как я говорил на одном из докладов: модель – это код+веса+зависимости. На этом этапе мы клонируем репозиторий с кодом модели. Argo предоставляет нам весь необходимый функционал, благодаря чему нам не требуется создавать скрипты, которые просто качают репу.

👉 Пример и официальная документация:
Git Example: https://github.com/argoproj/argo-workflows/blob/main/examples/input-artifact-git.yaml
Docs: https://argoproj.github.io/argo-workflows/workflow-templates/

2. Установка зависимостей
- - После загрузки кода модели мы переходим к установке зависимостей. Обычно это requirements.txt / conda.yaml или что-то подобное.
Для этого мы можем использовать отдельный шаг в виде контейнера, где устанавливаем нужные библиотеки. Так как зачастую окружение весит достаточно много и нам нужно его использовать во всех дальнейших шагах – его лучше сохранить в S3 хранилище. Argo нативно умеет паковать указанную папку в архив с нужным уровнем сжатия и загружать ее в S3.

👉 Примеры и документация:
Input Artifacts Example: https://github.com/argoproj/argo-workflows/blob/main/examples/input-artifact-s3.yaml
Python/Bash Scripts Example: https://github.com/argoproj/argo-workflows/blob/main/examples/scripts-python.yaml
Docs: *первый пункт*

3. Загрузка весов.
- - Этот этап нужен для инференса и вообще реализуется обычно в коде, так как идет работа с такими инстументами, как например MLFlow, однако веса и прочие данные, как и зависимости из второго шага можно загрузить напрямую из S3, Hadoop, FS, и других хранилок напрямую.
👉 Примеры и документация:
Docs Inputs: https://argo-workflows.readthedocs.io/en/latest/workflow-inputs/
Docs Artifacts: https://argo-workflows.readthedocs.io/en/latest/walk-through/artifacts/
Examples: все не накидать – Ctrl+F и вводим artifact в папке репы.

4. Обучение модели
- - Самый важный этап, как и выкладка. Здесь мы запускаем скрипт обучения, подгружая все ранее использованные артифакты.
По сути, нам можно воспользоваться шаблонами подгрузки из Git, S3 чтобы загрузить код, зависимости в виде архива, который будет автоматически распакован в нужную нам папку. И также запустить просто скрипт, через Bash.

Все примеры уже есть выше. Описание полей Input и Output шагов буквально идентичны: в случае input, путь - это откуда грузим, для output, путь - это куда. Подгружать можно практически все, что угодно и куда угодно.
Если у вас много оперативной памяти, то в K8s, все процессы работы с данными можно ускорить, использовав ее, как storage:

volumes:
  - name: fast-volume
    emptyDir:
      sizeLimit: 15Gi
      medium: Memory

Также хотелось упоминуть про прекрасные Docker образы mambaorg/micromamba, которые позволят юзать mamba (пакетный менеджер conda на C++), которые позволят поднимать модели на едином образе с любой версией питона и любым окружением, которое уже хранится в S3. Никаких образов на 2Gb+!


📌 Итого

Argo Workflows — это мощный инструмент для построения ML-пайплайнов в Kubernetes. Он гибко настраивается и имеет обширнейшую документацию. 95% всех моментов в ней описаны, оставшиеся 5% можно нарыть в API Doc, где показано, какие поля спецификаций имеются в инструменте. Все мелкие косяки, которые происходят фиксятся достаточно быстро, так как обновления идут почти каждые 2 месяца, если не быстрее.

Касательно реализации MLOps пайплайна: главное — понимать, какие этапы вам нужны, а с тем, как правильно описать в YAML, вам может помочь 100+ примеров на GitHub ну и строка поиска в доке.

🔍 Недавно наткнулся на интересный инструмент — OpenWebUI. Делюсь впечатлениями

Если вы следите за развитием локальных LLM (больших языковых моделей), то наверняка сталкивались с проблемой: как удобно и быстро запустить модель у себя на машине и при этом получить красивый веб-интерфейс?

Я столкнулся скорее не с этой проблемой, а с тем, что мне нужно было как-то юзать ChatGPT, который работает под VPN. Последний как раз не очень дружил с моим рабочим VPN’ом, а переключение ради одного запроса выкидывало из удаленной тачки или отрубало доступ к Jira и прочим инфровым ресурсам 💩

И тут на помощь приходит OpenWebUI — это базовый и удобный фронтенд с открытым исходным кодом, который превращает локально запущенные модели в полноценный чат-интерфейс, напоминающий аналогичный ChatGPT.

🧩 Что такое OpenWebUI?
OpenWebUI — это self-hosted веб-интерфейс для работы с локальными и удалёнными LLM. Он не требует сборки, так как уже есть готовый набор Docker образов и просто запускается через Docker с подключением к разным бэкендам:
- Ollama
- Llama.cpp
- и другим через API

🛠️ Как работает?
1. Устанавливаете Docker.
2. Запускаете контейнер OpenWebUI.
3. Подключаете его к выбранному бэкенду (например, Ollama).
4. Открываете браузер и начинаете общаться с моделью через красивый интерфейс.

В моем случае, решением проблемы стало подключение к OpenAI proxy серверу, который имеет доступ к ChatGPT и общение в чатике через API ключ. Так как я стал достаточно редко в последние время использовать ChatGPT (тем более Pro версию), использование ключа сократило расходы, так как теперь я плачу лишь за использованные токены, а не за условный безлимит на месяц.

💡 Основные фичи:
1. Поддержка нескольких моделей — можно переключаться между ними в один клик.
2. Чат-интерфейс — с историей, перепиской, вложениями и т.д.
3. Интеграция с API — если вы подключаете удалённые модели.
4. Работа с документами — можно загружать PDF, тексты и обрабатывать их через модель, создавая тем самым полноценный RAG по вашей документации.
5. Мультипользовательский режим — с ролями и правами.

Ключевым здесь является, на мой взгяд, возможность поднятия локально модели, например, через Ollama, и доступа к ней. Наличие видеокарты не будет убивать ваш проц, загрузкой 99%, как у меня.
К сожалению, на маки поддержку GPU пока что не завезли

📦 Где посмотреть?
GitHub: https://github.com/openwebui/openwebui
Документация: https://docs.openwebui.com

⚡️ Итого
OpenWebUI — это классный инструмент, который дает возможность локально поиграться с LLM через многим привычный интерфейс. Предоставляет GUI надстройку над, например, Ollama или других движков. И как одна из киллер фичей, позволяет делать полноценный RAG буквально за пару минут.

🔍 Сегодня утром проснулся — а в ленте уже GPT-5. OpenAI официально представила пятёрку.

7 августа 2025 года — дата, с которой можно начинать отсчёт новой эры ИИ-систем.
GPT-5 — это не просто апгрейд. Это интегрированная платформа с динамической маршрутизацией, многоуровневой безопасностью и адаптацией под задачу.

OpenAI явно сместила фокус: модель больше не просто «отвечает на вопросы», а встраивается в рабочие процессы — в бизнес, науку, медицину, разработку.

🧠 GPT-5 — это не одна модель, а семейство.

Внутри системы работает роутер, который в зависимости от запроса выбирает подходящую подмодель:

- gpt-5-main. Стандартная быстрая модель
- gpt-5-main-mini. Упрощённая и ещё более быстрая
- gpt-5-thinking. «Размышляющая» модель для сложных задач
- gpt-5-thinking-pro. Ускоренная reasoning-модель с параллельной обработкой
- gpt-5-thinking-nano. Компактная reasoning-модель для разработчиков

Роутер анализирует тип запроса и перенаправляет его в оптимальную модель.
Это снижает количество ошибок и повышает эффективность.

📉 Точность и безопасность

На реальных промптах:
- На 65% меньше галлюцинаций у gpt-5-thinking по сравнению с o3
- На 44% меньше серьёзных ошибок у gpt-5-main vs GPT-4o
- В медицинских задачах — снижение ошибок в 50 раз (HealthBench)

Появился механизм Safe Completions: модель не просто отказывает в генерации, а объясняет, почему запрос может быть опасным — особенно в dual-use сценариях (биология, химия, кибербезопасность).

GPT-5 Thinking отнесена к категории High Capability (обладающей потенциальным риском при злоупотреблении) — доступ к API только через Trusted Access Program.

💻 Программирование и Codex CLI

GPT‑5 полностью интегрирована в Codex CLI — инструмент, позволяющий использовать возможности модели в терминале. Пользователи ChatGPT с подпиской Plus, Pro или Team могут запускать Codex CLI без дополнительной платы за API.

Возможности:
- Генерирует код в вашем стиле (учитывает контекст и уже написанное)
- Отлаживает, пишет тесты, работает с файлами
- Интегрирована в Codex CLI — доступна через терминал
- Поддерживает контекст до 400K токенов


🔁 Как GPT-5 борется с «эффектом Бернулли»?

Это когда модель случайно выбирает неоптимальную цепочку рассуждений — и ошибается, хотя могла бы ответить правильно.

GPT-5 решает это несколькими способами:
- Динамическая маршрутизация — направляет запрос в подходящую модель
- Parallel Thought Sampling (в Pro) — запускает несколько цепочек рассуждений, выбирает лучшую
- Верификация логики — проверяет цепочку до финального ответа
- RLHF по reasoning — обучение на качественных рассуждениях, а не только на ответах

Результат: на 22% меньше критических ошибок в Pro-режиме.


💰 Цена и доступ
$1.25 за миллион входных токенов
$10 за миллион выходных
Для сравнения: GPT-4o был дороже при сопоставимой нагрузке.

Pro / Plus / Team — полный доступ к GPT-5 и GPT-5 Pro
Free — ограниченный reasoning (2–3 дня в неделю), потом переключается на gpt-5-mini
Enterprise / Edu — доступ открывается в течение недели
Codex CLI включён в подписку — отдельная оплата за API не нужна.

📌 Итого
GPT-5 — это переход от «умного чата» к интеллектуальной системе, встроенная в рабочие процессы.

Она:
- Рассуждает, а не просто генерирует
- Выбирает подходящую стратегию сама
- Безопасна, контролируема, точна
- Доступна разработчикам, аналитикам, учёным
- OpenAI больше не делает ИИ — они строят операционную среду для интеллектуальной работы.

🚀 Продолжая тему инструментов вокруг LLM, хочу поделиться впечатлениями про ещё одну интересную платформу — Dify.

Если OpenWebUI решает задачу удобного интерфейса для локальных или удалённых моделей, то Dify идёт дальше — это уже полноценный конструктор AI-приложений и MLOps-платформа.

🧩 Что такое Dify?

Dify — это open-source среда, ооочень сильно напоминающая N8n, которая помогает быстро создавать, тестировать и запускать приложения на базе LLM.
По сути, это Framework для разработки AI продуктов.

🛠️ Как работает?

1. Разворачиваем Dify (есть готовые Docker-образы).
2. Подключаете либо локально запущенную модель, либо через официальные API, например от OpenAI.
3. Собираете AI-приложение: чат-бот, ассистент, RAG-систему.
4. Тестируете и деплоите.

💡 Основные фичи:

1. Готовые блоки для сборки логики — накликиваем все через UI и сохраняем в JSON.
2. Управление пайплайнами — бесплатный аналог N8n.
3. Удобный редактор промптов — можно настраивать подсказки и тестировать их прямо в UI.
4. Поддержка RAG — загрузка и работа с собственными данными “из коробки”.
5. Маркетплейс шаблонов — есть уже готовые решения для быстрых запусков, доступные в Quick Start гайде.

⚡️ Почему это круто?

Если OpenWebUI — это удобный интерфейс, чтобы поиграться с моделями или использовать их локально, то Dify — это уже инструмент, чтобы строить полноценные AI-продукты: агенты, пайплайны.

По сути это некий аналог N8n, который однако имеет возможности делать не только пайплайны, но и просто ботов, как это предлагает OpenWebUI.

Как и в OpenWebUI, у нас есть так же возможность создать RAG пайплайн с Rerank моделями и подключением к разным векторным базам. Однако тут у нас есть также возможность и расширить его уже через полноценные пайплайны, которые будут загружать документы, более тщательно обрабатывая их и выдавать более релевантные результаты.

📦 Где посмотреть?
GitHub: https://github.com/langgenius/dify
Документация: https://docs.dify.ai

📊 Итог
Dify отлично дополняет OpenWebUI. Если первый даёт возможность и общаться с запущенными локально моделями (или внешними через API) через красивый UI, то второй помогает интегрировать эти модели в рабочие сервисы и продукты.