Как выглядит эффективная среда для экспериментов в машинном обучении?

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

Давайте разберем ключевые свойства, которыми должна обладать эффективная среда для экспериментов. Как инженер MLOps, вы должны предоставлять их пользователям, а как Data Scientist – понимать, что именно вам необходимо.

🔸 Доступ к сырым данным
Хотя обработка сырых данных – зона ответственности Data Engineering, Data Scientist'ам важно иметь возможность исследовать и анализировать их, чтобы решать, какие данные необходимо продвигать по Data Value Chain (цепочке ценности данных).

🔸 Доступ к подготовленным (curated) данным
Подготовленные данные могут находиться в Data Warehouse, но при этом не быть доступны через Feature Store. Такие данные не должны использоваться для обучения моделей в продакшн-среде. Data Scientist'ы должны иметь возможность исследовать подготовленные данные и решать, что стоит продвигать дальше.

🔸 Источник данных для обучения моделей
Данные для обучения моделей должны поступать из Feature Store, если ML-тренировочный конвейер готов к переходу в продакшн.

🔸 Гибкость в развертывании вычислительных кластеров
Data Scientist'ы должны легко запускать различные типы вычислительных кластеров (Spark, Dask или другие технологии) для эффективного исследования сырых и подготовленных данных.

🔸 Возможность запуска продакшн-подобного ML-конвейера из ноутбука
Data Scientist'ы должны иметь возможность ад-хок развернуть тренировочный ML-конвейер в среде разработки прямо из Jupyter Notebook. Это значительно ускоряет итерации экспериментов.

🔸 Автоматизированное тестирование и продвижение кода
Должен быть автоматизированный процесс тестирования и деплоя в следующую среду при создании Pull Request в определенные ветки. Например, PR из feature/* в release/* может запускать CI/CD, который протестирует и развернет ML-конвейер в pre-prod.

🔸 Интеграция с Git
Ноутбуки и другой код, связанный с CI/CD, должны быть частью Git-репозитория. Важно четко определить, где должен храниться тот или иной тип кода. Хорошая практика – использование шаблонов репозиториев с понятной документацией.

🔸 Система отслеживания экспериментов и моделей
Она должна быть доступна как для локальных, так и для удаленных ML-конвейеров.

🔸 Соответствие окружения ноутбуков и продакшн-среды
Ноутбуки должны запускаться в том же окружении, что и продакшн-код, чтобы избежать проблем с несовместимыми зависимостями. Это можно реализовать с помощью контейнеризации

👉 @DataSciencegx

Сделайте свое RAG-приложение в 10 раз умнее

ColiVara — это уникальный метод извлечения документов, который не требует разбиения на фрагменты или текстовой обработки. Это все еще похоже на RAG, но без OCR, извлечения текста, сломанных таблиц или отсутствующих изображений.

То, что вы видите, — это то, что вы получаете.

Вот почему это прорыв:

🔸Индексация на основе визуальных данных
🔸 Поддержка более 100 форматов файлов
🔸 Передовое мультимодальное извлечение
🔸 API и SDK для Python/TypeScript
🔸 Нет необходимости в управлении векторной базой данных (pgVector используется "под капотом")

Но это еще не все:

🔸 Подробная документация
🔸 Быстрый запуск локально или в облаке
🔸 Встраивание с поздним взаимодействием для повышенной точности

И самое главное — это 100% open-source!

Ссылка на репозиторий GitHub

👉 @DataSciencegx | #ресурсы

Топ репозитории GitHub, которые нельзя пропустить на этой неделе:

1. Бесплатный курс по LLM (2025) — обновленный репозиторий с основами LLM, дообучением и квантизацией.
👉 GitHub

2. Qwen2.5-VL — мультимодальная языковая модель для обработки документов и реальных задач.
👉 GitHub

3. GPT Researcher — бесплатная альтернатива Deep Research для глубоких исследований с отчетами и цитатами.
👉 GitHub

4. Text Generation Web UI — интерфейс для работы с LLM, с простым подключением и поддержкой API.
👉 GitHub

5. Browser-use — агент для автоматизации браузера с командным управлением.
👉 GitHub

👉 @DataSciencegx | #ресурсы

Традиционный vs. Графовый RAG: понятное объяснение

Представьте, что у вас есть длинный документ, например, биография человека (X), где каждая глава посвящена одному из его достижений.

Например:

↳ Глава 1: Описывает Достижение-1.
↳ Глава 2: Описывает Достижение-2.
...
↳ Глава 10: Описывает Достижение-10.

Теперь внимательно разберём следующий момент

Допустим, вы создали традиционный RAG (Retrieval-Augmented Generation) на основе этого документа и хотите суммировать все достижения X.

Сделать это с помощью традиционного поиска может быть сложно, так как для полноценного ответа нужен весь контекст...

...но при этом вы, скорее всего, извлекаете только топ-k наиболее релевантных фрагментов из векторной базы данных.

Кроме того, традиционные RAG-системы извлекают каждый фрагмент отдельно, и LLM вынужден самостоятельно восстанавливать связи между этими частями (если они вообще были найдены).

— Графовый RAG решает эту проблему

Основная идея заключается в том, чтобы сначала создать граф (сущности и их связи) из документов, а затем выполнять обход этого графа на этапе извлечения информации.

Как Graph RAG устраняет проблемы традиционного подхода:

1. Генерация графа

🔸LLM анализирует биографию и строит граф, выявляя сущности и связи между ними.
🔸В результате получается полноценный граф, а его подграф, связанный с достижениями X, будет выглядеть так:

↳ X → <достиг> → Достижение-1.
↳ X → <достиг> → Достижение-2.
...
↳ X → <достиг> → Достижение-N.

2. Поиск по графу
🔸На этапе извлечения информации система выполняет обход графа, собирая все релевантные данные о достижениях X.
🔸Полученный контекст передаётся LLM, что позволяет сформировать логичный, полный и связный ответ, в отличие от традиционного RAG.

— Почему Graph RAG так эффективен?

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

👉 @DataSciencegx

В Python можно выполнить директорию проекта как скрипт

🔸Переименуйте основной файл в main[.]py.
🔸Запустите "python имя_директории".

Это удобно и позволяет другим легко идентифицировать основной файл

👉 @DataSciencegx

Следующая визуализация показывает 5 самых популярных шаблонов проектирования, используемых при создании ИИ-агентов

Давайте их разберём:

1. Шаблон рефлексии

ИИ анализирует свою работу, чтобы выявить ошибки, и повторяет процесс до тех пор, пока не создаст окончательный ответ.

2. Шаблон использования инструментов

Инструменты позволяют LLM собирать дополнительную информацию с помощью:
🔸Запросов к векторным базам данных
🔸Выполнения Python-скриптов
🔸Вызова API и т. д.

Это полезно, поскольку LLM не зависит исключительно от своего внутреннего знания.

3. Шаблон ReAct (Reason and Act):

ReAct сочетает два вышеописанных шаблона.

4. Шаблон планирования:

Вместо того чтобы решать задачу за один раз, ИИ создаёт план действий:
🔸Разбивает задачи на части
🔸Формулирует цели

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

5. Шаблон многократных агентов:

🔸Мы имеем несколько агентов.
🔸Каждый агент получает свою роль и задачу.
🔸Каждый агент может также использовать инструменты.

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

Это делает данный шаблон одним из самых мощных, используемых сегодня

👉 @DataSciencegx

Только что наткнулся на отличный разбор трансформеров от Брэндона Роэра и не могу не поделиться

Если вам когда-либо было сложно разобраться, как работают эти модели (и при этом не утонуть в формулах), обязательно прочитайте эту статью.

Автор объясняет всё максимально интуитивно — никаких сложных выкладок, только суть. Визуализации и аналогии помогают действительно понять такие концепции, как механизм внимания.

Если вы работаете с LLM, готовитесь к собеседованию или просто хотите лучше понять, как устроены модели вроде ChatGPT, этот материал — один из лучших, что я встречал

👉 https://www.brandonrohrer.com/transformers

👉 @DataSciencegx | #ресурсы

Нашёл мощную альтернативу Jupyter Notebook (с открытым исходным кодом)

marimo объединяет возможности Jupyter, Streamlit, ipywidgets (и не только) в реактивном интерфейсе.

Он также отображает интерактивные таблицы Pandas, и к ним можно выполнять SQL-запросы.

👉 @DataSciencegx | #ресурсы

⭐️ Шпаргалка из 40 методов NumPy, которые используются в 95% случаев

👉 @DataSciencegx

Пользователям Jupyter это точно понравится

Stickyland — это инструмент с открытым исходным кодом, который позволяет выйти за рамки линейного представления ноутбука.

🔸Создавайте плавающие ячейки
🔸Формируйте дашборды из ячеек
🔸Автоматически выполняйте ячейки при изменениях

👉 @DataSciencegx | #ресурсы

Используйте box plot с осторожностью. Они могут вводить в заблуждение

В этом примере три разных набора данных дают похожие box plot. Поэтому всегда проверяйте распределение данных с помощью гистограмм, KDE и других методов.

👉 @DataSciencegx

Альтернатива Pandas, работающая в 100 раз быстрее!

(Может даже обойти GPU-библиотеки для работы с DataFrame)

Хотя Pandas — самая популярная библиотека для работы с DataFrame, у нее есть серьезные ограничения:

🔸Использует только одно ядро процессора
🔸Часто создает громоздкие DataFrame.
🔸Немедленное (eager) выполнение мешает глобальной оптимизации.

Представляем FireDucksDev — высокоэффективную замену Pandas, которую можно использовать без изменений кода.

Достаточно просто заменить одну строку:

import fireducks.pandas as pd

На видео показано сравнение FireDucks с cuDF — GPU-библиотекой DataFrame.

В этом случае FireDucks оказался даже быстрее cuDF.

Однако в тесте использовались цепочки операций и все столбцы. После ручной оптимизации (работа только с нужными столбцами) время выполнения изменилось:

🔸Pandas: 14 секунд (было 48 секунд)
🔸FireDucks: 0,8 секунды (без изменений)
🔸cuDF: 0,9 секунды (было 2,6 секунды)

Это доказывает, что компилятор FireDucks автоматически выполняет те же оптимизации, которые в cuDF и Pandas пришлось бы настраивать вручную.

Важно отметить, что оптимизация не влияет на конечный результат

👉 Ссылка на Google Colab

👉 @DataSciencegx

Используйте эти репозитории на GitHub, чтобы прокачать свои навыки в Python и ML:

🔸 Homemade Machine Learning — Репозиторий содержит коллекцию алгоритмов машинного обучения, реализованных с нуля на Python, что помогает понять их внутреннюю работу.

🔸 Awesome Machine Learning — Подборка отличных фреймворков, библиотек и программного обеспечения для машинного обучения

🔸 Machine Learning Tutorial — Собрание обучающих материалов, статей и других ресурсов по машинному и глубокому обучению

🔸 Best Of ML With Python — Ранжированный список лучших библиотек Python для машинного обучения, обновляемый еженедельно

🔸 Machine Learning Interview — Репозиторий предоставляет ресурсы для подготовки к интервью по машинному обучению, включая примеры вопросов и советы

👉 @DataSciencegx | #ресурсы

Генеративные vs. дискриминативные модели в ML

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

Дискриминативные модели не обладают генеративными свойствами

👉 @DataSciencegx