Как держать ноутбуки в чистоте и не сойти с ума от мерджей

Если ваша команда работает с Jupyter Notebooks и использует Git, вы наверняка сталкивались с этим. 🙈 Коммиты превращаются сон при температуре 39 из-за тысяч изменённых строк в диффах. Виноваты вы и аутпуты ячеек — графики, результаты print() (кто же не отлаживает код принтами), большие датафреймы. Они маскируют реальные изменения кода и делают историю нечитаемой.

nbstripout (там даже есть видеодемонстрация) автоматически очищает ваши .ipynb файлы от:

📤Выходных данных! Все эти графики, картинки и текстовый вывод, которые генерируются при выполнении ячеек.
📉Лишних метаданных! Служебная информация от различных расширений (например, execution time, состояния виджетов), которая тоже меняется каждый раз и создаёт шум.

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

Вот так выглядит diff, если коммитить ноутбук с аутпутами и с нбстрипаут:

-   "execution_count": 2,
-   "outputs": [
-     ... 200 строк мусора ...
-   ],
+   "execution_count": null,
+   "outputs": [],

🔻 До — сотни строк JSON ради одного графика.
🔺 После nbstripout — только код.

Как это использовать? Есть два основных пути:
1️⃣ настроить nbstripout как фильтр для Git. Это значит, что в вашей рабочей директории файлы остаются с аутпутами (удобно для работы), но при коммите гит автоматически применяет очистку перед сохранением версии. 
2️⃣ интегрировать с фреймворком прекоммит. Перед каждым коммитом хук запускается и проверяет, что ноутбуки чистые. Если нет — он их очищает и добавляет изменения в коммит.

А есть подводные камни?

Конечно! Главный из них — мерджи.
Вы тянете изменения из основной ветки, где ноутбуки чистые. А у вас локально эти ноутбуки выполнены и полны аутпутов. Гит попытается смерджить изменения в коде, но запутается в тех частях файла, где хранятся аутпуты. Это может привести к конфликтам слияния, которые придётся разрешать вручную. 😳 Нет, ну может, конечно, это только у меня так было… Решением будет договориться в команде, что все используют такой фильтр. Тогда и в основной ветке, и у всех локально ноутбуки будут в одинаковом «чистом» состоянии, и проблем с мерджами будет минимум.

#python #jupyter #git #datascience #ml #productivity #nbstripout

Awesome AI Apps - технический гид по созданию LLM-приложений

🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..

Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте 🤪.
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)

Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
🫰 LangChain + LangGraph для оркестрации агентов.
🫰 Agno как фреймворк для построения agentic workflows.
🫰 CrewAI для мультиагентных исследований.
🫰 LlamaIndex как основа RAG и документных ассистентов.
🫰 Memori для хранения контекста и долгосрочной памяти.
🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.

Установка (единый паттерн):

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt

🧘‍♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать.

Этот репозиторий в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌

#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI

🫐 Инструмент недели. Pydantic

В проде больше половины инцидентов про «кривые данные» 📊 - строка там, где ждём число, емэйл без домена, перепутанные координаты, пустые обязательные поля... Пока латаешь всё ручными if по коду, получаешь еще три проблемы разом:
- правила валидации расползаются по пайплайнам и сервисам;
- ошибки получаются шумные и неструктурированные;
- откат/повторение экспериментов ломается из-за невидимых изменений в схеме данных.

В ML/DS это особенно больно, так как один «NaN как строка» — и метрики едут; одна «категория не из словаря» — и онлайн-фичи расходятся с офлайн. Нам нужен явный «контракт данных», что считается валидным, какие типы и диапазоны, какая нормализация применяется - и всё это в одном месте, с понятными сообщениями об ошибках и автогенерацией схем.

Решение
Pydantic превращает аннотации типов в реальную валидацию и автокаст прямо при подаче события/JSON. 👿 В отличие от библиотек (однажды обсудим еще marshmallow), которые валидируют данные только в отдельных точках (например, при вызове load()), Pydantic проверяет и приводит типы прямо при создании объекта и, при желании, при каждом присваивании полю. Это превращает модель не просто в контейнер, а в исполняемый «контракт данных», так как любые несоответствия ловятся там, где объект рождается или меняется.

🎯 Цель Pydantic - сопровождать объекты валидацией на всём их жизненном цикле. Если включить validate_assignment=True, то некорректное присваивание полю вызовет ошибку сразу, а не через несколько хопов по коду. Такой подход существенно снижает «дрейф» данных, когда объект успевает разойтись с контрактом задолго до сериализации.

👨‍🦽По умолчанию Pydantic аккуратно преобразует данные без потери - строка "42" превратится в число 42 🌌. Там, где требуется строгая дисциплина, используются «строгие» типы (StrictInt, StrictStr) или валидаторы в режиме before. Можно точно выбирать места, где допустим автокаст, а где критична точность.

🧅 Еще Pydantic построен на pydantic-core (Rust) и заметно выигрывает на больших объёмах валидации. Это особенно чувствуется в потоковых пайплайнах и сервисах, принимающих крупные JSON-массивы.

⌛ Как внедрить за час
1. Поставь pydantic>=2.
2. Оберни входящие объекты (advisory, feed, webhook) в модели.
3. Вынеси ручные if в Field(...)/валидаторы.
4. Возвращай наружу e.errors() и генерируйте model_json_schema() для контрактов.

#Pydantic #Python #DataContracts #DataValidation #DataQuality #ML #DataScience #MLOps #FastAPI #Pandas #JSONSchema #TypedPython