🍓Инструмент недели. Как DVC может спасти ваш ML-проект

Кейс
Месяц назад выкатил модель, которая классифицирует котиков и собачек. Метрики - огонь, продакшн съел. Ты такой: «Оки-доки, теперь добавим ещё данных, особенно рыжих котиков 🐾🐾🐾, их не хватало».

Качаешь гигабайт новых картинок, кидаешь их в папку data/train, поверх старых. Запускаешь дообучение. Смотришь на графики — а метрики просели. «Странно... Может, я не те данные удалил? Или перезаписал не ту версию?» А вспомнить уже не можешь, потому что папка data/ теперь просто свалка из 50к файлов без истории 🦭.

Вот здесь начинается ад😵‍💫. Ты пытаешься откатиться к прошлому чекпойнту модели, но он был натренирован на «каких-то там данных», которых у тебя уже нет. Воспроизвести прошлый результат нельзя. Весь процесс превращается в лотерею 🎟️

DVC — это как «Гит» для данных и моделей. Он не тащит гигабайты в репозиторий, а кладёт их на удалённое хранилище (типа S3 или даже просто сервер в соседней комнате), а в сам git-реп коммитит только маленький файлик-указатель (`.dvc`), который говорит: «версия данных №1 лежит вот по такому хешу».

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

Так почему его мало кто использует?
Потому что на старте проекта, когда данных 100 МБ, всё и так работает. DVC — это инструмент для «взрослых», который начинает кричать о своей необходимости ровно тогда, когда хаус уже горит и все тонут в хаосе. Это не про «сделать круто», а про «перестать тратить нервы и время». Это скелет проекта, который не ломается при первом же изменении. Самый недооценённый труженик в нашем стэке.

#DVC #ВерсионированиеДанных #MLOps #Reproducibility #DataManagement #МашинноеОбучение #DataScience #GitForData #MLOpsTools #MLЭксперименты #УправлениеДанными #DataEngineering #DataVersionControl

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

Когда Pandas начинает «тормозить» на миллионах строк, на помощь приходит Polars - библиотека для анализа данных, написанная на Rust.

Почему стоит попробовать?
😛В разы быстрее Pandas на больших датасетах.
✌️Lazy API - можно строить вычислительные графы и оптимизировать запросы (как в SQL).
👑Поддержка многопоточности «из коробки».
🐰Совместимость с Arrow - легко интегрировать с ML-инструментами.

Кейс
У нас есть датасет vulners_web.csv с колонками cve_id, score, has_exploit, fetched_at.
Нужно понять распределение уязвимостей по уровням риска (Low/Medium/High/Critical) и посмотреть, сколько из них уже имеют эксплойт (на рисунке результат работы кода).

import polars as pl

df = pl.read_csv(
    "/content/vulners_web.csv",
    columns=["cve_id", "score", "has_exploit"],
    n_rows=20000
)

df = df.with_columns([
    pl.when(pl.col("score") < 4.0).then(pl.lit("Low"))
      .when(pl.col("score") < 7.0).then(pl.lit("Medium"))
      .when(pl.col("score") < 9.0).then(pl.lit("High"))
      .otherwise(pl.lit("Critical"))
      .alias("severity")
])

stats = (
    df.group_by("severity")
      .agg([
          pl.count().alias("n_total"),
          pl.sum("has_exploit").alias("n_with_exploit"),
          pl.mean("score").alias("avg_score"),
      ])
      .sort("avg_score", descending=True)
)

print(stats)

Такой кейс прям жизненный. Показывает, как Polars помогает быстро агрегировать и строить фичи для анализа киберугроз или для будущей ML-модели.
Polars в одну строчку даёт сводку: сколько уязвимостей в каждой категории, сколько из них имеют эксплойты, средний CVSS-балл.
Такой подход удобно использовать для генерации признаков перед обучением ML-модели (например, для прогноза риска эксплуатации).

⚡ Polars vs Pandas (на 1 млн строк).

import pandas as pd
import polars as pl
import numpy as np
import time

# Генерируем тестовый датасет
N = 1_000_000
scores = np.random.uniform(0, 10, N)
has_exploit = np.random.choice([0, 1], size=N)

# Pandas
df_pd = pd.DataFrame({"score": scores, "has_exploit": has_exploit})
t0 = time.time()
pd_stats = df_pd.groupby(pd.cut(df_pd["score"], [0,4,7,9,10])).agg(
    n_total=("score", "count"),
    n_with_exploit=("has_exploit", "sum"),
    avg_score=("score", "mean")
)
print("Pandas:", time.time() - t0, "сек")

# Polars
df_pl = pl.DataFrame({"score": scores, "has_exploit": has_exploit})
t0 = time.time()
pl_stats = (
    df_pl.with_columns([
        pl.when(pl.col("score") < 4.0).then(pl.lit("Low"))
          .when(pl.col("score") < 7.0).then(pl.lit("Medium"))
          .when(pl.col("score") < 9.0).then(pl.lit("High"))
          .otherwise(pl.lit("Critical"))
          .alias("severity")
    ])
    .group_by("severity")
    .agg([
        pl.count().alias("n_total"),
        pl.sum("has_exploit").alias("n_with_exploit"),
        pl.mean("score").alias("avg_score"),
    ])
)
print("Polars:", time.time() - t0, "сек")

⚡ На ноутбуке с 1 млн строк:
Pandas ≈ 1.5–2.0 сек
Polars ≈ 0.2–0.3 сек
Разница на больших датасетах ещё больше.

Выводы
Polars = скорость + простота + экономия памяти, времени и нервов.
Для ML-инженера это отличный инструмент для EDA и фичер-инжиниринга.

Киберугрозы перебрались в мир ML-библиотек

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

😞 Привычные инструменты — TensorFlow, PyTorch, Scikit-learn — могут стать лазейкой для атак, если бездумно загружать модели из ненадёжных источников.
Только за последнее время в ключевых библиотеках обнаружили критические уязвимости.

В Keras (CVE-2024-3660) нашли дыру, из-за которой модели с Lambda-слоями могли содержать вредоносный код, выполняемый сразу при загрузке. MLflow (CVE-2024-37057) не отставал — уязвимость в логике десериализации TensorFlow-моделей позволяла злоумышленнику получить полный контроль над системой. История с PyTorch (CVE-2025-32434) оказалась особенно показательной: казалось бы, безопасный режим weights_only=True можно было обойти, и специально подготовленный файл весов всё равно исполнял произвольный код. А затем выяснилось, что даже инструменты защиты уязвимы. 😂PickleScan (CVE-2025-1944), созданный для проверки моделей на безопасность, сам содержал дыру. Злоумышленник мог подделать архив так, чтобы обойти проверку, и успешно загрузить вредоносную модель.

К чему всё это? Вывод простой.

🍂 Загрузка чужих весов без проверки — это пупупу...

🦄Даже если в документации написано «безопасно», всегда есть шанс, что кто-то уже нашёл лазейку.
Корень проблем часто кроется в ненадёжной десериализации — использовании pickle, cloudpickle, исполняемых слоёв (Lambda) и пользовательского кода внутри моделей. Кроме того, атаки целятся не только в сами модели, но и во всю инфраструктуру вокруг (инструменты управления, системы трекинга, логирования и тд). Важно помнить, что не каждая уязвимость даёт полный доступ к системе или DoS, но и утечка данных или подрыв доверия к модели — тоже крайне серьёзные риски.

Что делать?
Относиться к моделям как к коду 🧑‍💻. Проверять их происхождение, использовать песочницы для запуска, сканировать артефакты и своевременно обновлять зависимости.

#MLбезопасность #AI #DevSecOps #TensorFlow #PyTorch

Инструмент недели. Weights & Biases (W&B)

Работать с ML-моделями значит запускать десятки экспериментов 🤪, менять гиперпараметры и пытаться всё это отслеживать.

С W&B всё вживую! Как меняется точность, как падает ошибка, какая модель оказалась лучшей. Удобная платформа для логирования экспериментов, визуализации метрик, управления моделями и коллаборации в ML-командах. Поддерживает PyTorch, TensorFlow, Keras, Scikit-Learn и другие фреймворки.

Почему стоит попробовать?
🐕‍🦺Простая интеграция — wandb.init() и у тебя уже дашборд
🐩 Красивые графики из коробки (loss, accuracy, ROC и др.).
🐕Совместная работа — можно шарить ссылку на эксперименты коллегам.
🦮 Версионирование моделей и датасетов.
🐶 Поддержка PyTorch, TensorFlow, Keras, HuggingFace, Sklearn и тд.

Кейс
Берём открытый датасет MNIST и обучаем простую модель на PyTorch. Тренируем и логируем метрики в W&B — через пару секунд в браузере появляется дашборд с loss и accuracy.

🐶Пример на MNIST (PyTorch + W&B):

import wandb, torch, torch.nn as nn, torch.optim as optim
from torchvision import datasets, transforms
from torch.utils.data import DataLoader

wandb.init(project="mnist-demo")
config = wandb.config
config.epochs, config.lr, config.batch_size = 3, 0.001, 64

train_loader = DataLoader(
    datasets.MNIST('.', train=True, download=True, transform=transforms.ToTensor()),
    batch_size=config.batch_size, shuffle=True
)

model = nn.Sequential(nn.Flatten(), nn.Linear(28*28, 128), nn.ReLU(), nn.Linear(128, 10))
opt, loss_fn = optim.Adam(model.parameters(), lr=config.lr), nn.CrossEntropyLoss()

for epoch in range(config.epochs):
    loss_total, correct = 0, 0
    for X, y in train_loader:
        opt.zero_grad()
        pred = model(X)
        loss = loss_fn(pred, y)
        loss.backward()
        opt.step()
        loss_total += loss.item()
        correct += (pred.argmax(1) == y).sum().item()
    acc = correct / len(train_loader.dataset)
    wandb.log({"epoch": epoch, "loss": loss_total/len(train_loader), "accuracy": acc})

Чем отличается от аналогов?
🕺Если коротко, W&B выигрывает там, где важно быстро стартовать, красиво визуализировать и работать в команде.
🦴TensorBoard хорош, если нужен простой просмотр метрик, графиков и тд в связке с TensorFlow. Но это скорее локальный инструмент для одиночной работы, без удобного шаринга и версионирования.
🦴🦴MLflow подходит, когда требуется полный контроль. Можно развернуть свой сервер, хранить модели и вести реестр экспериментов. Но за это платишь временем на настройку и более скромным интерфейсом.
🦴🦴🦴Neptune ориентирован на крупные команды и масштабные проекты. Он стабилен при огромном количестве экспериментов, но для большинства задач выглядит избыточным.
🦴🦴🦴🦴W&B сочетает простоту старта (wandb.init()), наглядный дашборд «из коробки», версионирование моделей и датасетов и лёгкий шаринг экспериментов.

#WB #инструментнедели #ml #machinelearning

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

Если ваша команда работает с 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

Уязвимости в дата-репозиториях. Обзорно главное

Репозитории для анализа данных и ML - зона повышенного риска ⚠️. Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак.
Вот ключевые из них:

1. 🤫 Секреты в коде.
Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.

Лечение
‘git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов.

2. 🧑‍💻 RCE через десериализацию
Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.

Лечение
yaml.safe_load(), ONNX, sandbox.

3. 💻 Открытые ноутбуки
Юпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.

Лечение
‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭.

4. 🙈

DoS через загрузку моделей. 
Эндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).

Data Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как "не спам").

Adversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)

Лечение
Pre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs).

#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps

🔗 Полезные ссылки:
1. TruffleHog— сканер секретов
2. nbstripout — очистка ноутбуков
3. OWASP Top 10 — главные уязвимости

Инструмент недели. Evidently AI

Представь, что у тебя в продакшене работает модель, ты доволен результатами, а через пару недель начинаешь замечать странности. Качество падает, предсказания уже не такие уверенные… 🤔 Оказывается, данные изменились, а ты об этом узнал слишком поздно.

Чтобы не попадать в такие ситуации, есть отличный инструмент — Evidently AI (там есть ссылка на гитхаб!) . Он словно whoop для модели (подписка дешевле и бесплатного функционала за глаза и за уши)! Постоянно следит за её состоянием, замечает сдвиги в данных, подсказывает, где метрики поползли вниз, и даже рисует красивые отчёты. Можно открыть их в браузере и сразу увидеть картину, где данные изменились, а где всё ещё стабильно:

🔹 замечает дрейф данных,
🔹 подсвечивает упавшие метрики,
🔹 строит понятные отчёты.

Посмотрим на любимых ирисах ;)

import pandas as pd
from sklearn import datasets

from evidently import Report
from evidently.presets import DataDriftPreset

iris = datasets.load_iris(as_frame=True)
df = iris.frame

# Разбиваем на reference и current
ref = df.sample(frac=0.5, random_state=42)
cur = df.drop(ref.index)

# Создаём отчёт
report = Report([DataDriftPreset()])
result = report.run(reference_data=ref, current_data=cur)

# В Jupyter достаточно вернуть объект result,
# и он отрендерится прямо в output ячейки
result

📊 В Jupyter он отрисует интерактивный отчёт, где данные остались стабильными, а где признаки «поплыли» (смотрим рисунок).

Это ощущается как ромашковый чай ☕️, который попиваешь следя за своим ML в продакшене. Не гадаешь, что пошло не так, а видишь конкретные сигналы. А значит, можешь быстро реагировать - переобучить модель, обновить пайплайн или просто зафиксировать изменения. Если у тебя модель уже живёт в проде - советую настроить мониторинг на старте, а не ждать сюрпризов 🤫.

#ИнструментНедели #SecretsManagement

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

CVE-2025-50709. Приватная инфа и URL — не лучшие друзья, особенно когда речь о нейросетях.

😳 В Perplexity AI нашли уязвимость CVE-2025-50709. Через обычный GET-запрос можно было вытянуть конфиденциальные данные.

Напоминание!!!

🕵️Приватная информация не должна передаваться в URL — особенно при работе с нейросетями. Передавать чувствительные данные через query string (?token=...&password=...) или допускать их в логи — это антипаттерн, но он встречается на практике чаще, чем хотелось бы… вспомните все случаи, когда нужно “быстро прикрутить” авторизацию или тестовый прототип, когда токен или ключ кидаешь в URL, потому что это проще. Не надо так… 😥

Что важно:
🔍 Уязвимость позволяет извлекать секреты через простые запросы.
⚠️ Проверь, не попадают ли чувствительные параметры в query string или логи.
🔐 Немедленно удаляй секреты из URL и используй безопасные каналы передачи (POST с телом, заголовки, шифрование, токены в хранилище).

Полезная ссылка.

🔥 CVE-2025-9906 — RCE в Keras даже с включённым safe_mode!

Если коротко, в .keras-архив можно подложить config.json, который отключит защиту, а затем вмонтировать Lambda-слой с произвольным кодом - при загрузке модели он выполнится.

🫰Если длинно, идем по ссылке и изучаем (там тоже не особо длинно).

В фиксе уже запрещена десериализация произвольных функций/классов и ужесточены правила для KerasSaveable 🐒.

🎯 Механизм эксплуатации
1. Злоумышленник создаёт вредоносную модель
2. В архиве подменяется config.json для отключения защиты
3. Добавляется лямбда-слой с произвольным питон-кодом
4. При загрузке модели код выполняется автоматически

Особенно критично для:
🙈Продакшен-систем с ML-моделями
🙈🙈Сервисов, загружающих модели от пользователей
🙈🙈🙈 Ресеча с обменом моделями

🤝Что делать?
Обновить Keras как можно скорее; не загружать модели из ненадёжных источников; избегать Lambda-слоёв (ссылка для мл-энтузиазтов-самоучек) из чужих архивов; при возможности проверять содержимое .keras перед загрузкой или загружать модели в песочнице.

#Keras #CVE2025 #RCE #MLSecurity

🫐 Инструмент недели. 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