Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Протокол TCP: управление перегрузкой | Компьютерные сети 2025 - 35
Лекция по механизму управления перегрузкой в протоколе TCP.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Управление перегрузкой в TCP
Наверняка вы знаете, что скачивать что-то большое из интернета через одно TCP-соединение очень долго. Почему так происходит?
Протокол TCP проектировался в 80-е годы прошлого века, когда каналы связи были медленные и ненадежные. Поэтому TCP после установки соединения начинает передавать данные с низкой скоростью. Если данные не теряются, то скорость постепенно увеличивается. А если теряются - то скорость снижается. Таким образом со временем TCP определяет приемлемую скорость передачи данных.
Сейчас каналы связи стали более быстрыми и стабильными. Почему нельзя передавать по ним сразу много данных? Оказывается, не все так просто. Сетью одновременно может пользоваться много устройств и вместе они способны загрузить даже самые быстрые и широкие каналы.
Поэтому у TCP очень сложная задача. Если передавать в сеть мало данных, то канал связи не будет загружен полностью и скорость передачи будет низкая. С другой стороны, если передать слишком много данных, то может произойти перегрузка, часть данных будет отброшена и их придется передавать заново. В этом случае скорость тоже будет низкая.
Дополнительная сложность в том, что сетью пользуются другие устройства. В случае с интернет это миллионы других устройств. Как определить подходящую скорость с учетом всех остальных устройств в сети?
Об этом вкратце рассказано в новом видео по управлению перегрузкой в TCP.
Более подробно можно почитать в RFC:
- RFC 5681 TCP - Congestion Control.
- RFC 896 - Congestion Control in IP/TCP Internetworks.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Наверняка вы знаете, что скачивать что-то большое из интернета через одно TCP-соединение очень долго. Почему так происходит?
Протокол TCP проектировался в 80-е годы прошлого века, когда каналы связи были медленные и ненадежные. Поэтому TCP после установки соединения начинает передавать данные с низкой скоростью. Если данные не теряются, то скорость постепенно увеличивается. А если теряются - то скорость снижается. Таким образом со временем TCP определяет приемлемую скорость передачи данных.
Сейчас каналы связи стали более быстрыми и стабильными. Почему нельзя передавать по ним сразу много данных? Оказывается, не все так просто. Сетью одновременно может пользоваться много устройств и вместе они способны загрузить даже самые быстрые и широкие каналы.
Поэтому у TCP очень сложная задача. Если передавать в сеть мало данных, то канал связи не будет загружен полностью и скорость передачи будет низкая. С другой стороны, если передать слишком много данных, то может произойти перегрузка, часть данных будет отброшена и их придется передавать заново. В этом случае скорость тоже будет низкая.
Дополнительная сложность в том, что сетью пользуются другие устройства. В случае с интернет это миллионы других устройств. Как определить подходящую скорость с учетом всех остальных устройств в сети?
Об этом вкратце рассказано в новом видео по управлению перегрузкой в TCP.
Более подробно можно почитать в RFC:
- RFC 5681 TCP - Congestion Control.
- RFC 896 - Congestion Control in IP/TCP Internetworks.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
Эти пет проекты должен сделать каждый аналитик
Финальные 4 часа скидки на наши продвинутые курсы подходят к концу. В честь этого подготовили самые популярные проекты, еще больше пет проектов будут на нашем курсе аналитика хард.
1. Работа с данными
В новом продукте придется выстраивать аналитические процессы. Но для начала нужно просто привести данные к удобному виду. Так данные могут храниться не оптимально: например, есть база данных VK с одной таблицей, где хранятся посты и авторы этих постов. Скорее всего, постов будет намного больше, чем авторов, поэтому разумно создать новую таблицу, переместить туда посты, а из исходной удалить. Помимо такого не оптимального хранения, данные могут быть банально грязные: аномалии, дубликаты и пропуски, неудобный тип переменных. Для "очистки" данные пригодятся статистические методы и визуализация. Также уже на этом этапе можно формулировать какие-то гипотезы. Для выполнения такого задания достаточно открыть jupyter notebook взять любой сырой датасет c того же kaggle, имитирующий "большие данные", там же по запросу в духе "Exploratory Data Analysis" можно посмотреть примеры других пользователей.
2. Дашборды
Результаты предыдущей работы с данными нужно предоставить в удобном виде. Согласитесь, что ко всем важным показателям нашего продукта должен быть простой и быстрый доступ. Странно было бы если всей команде каждый раз приходилось писать запрос, чтобы узнать сколько у продукта пользователей. Поэтому выстраивание аналитики начинается с выведения ключевых метрик как DAU, WAU, MAU. Целевая задача состоит в визуализации и презентации, также можно повыдумывать свои метрики и сформулировать какие-то гипотезы, глядя на графики. Например, видим пик активных пользователей (маркетологи закупили рекламу), а потом видим отток — давайте посмотрим на retention и оценим насколько реклама эффективна. Также придется найти данные и настроить рабочее окружение, наиболее удачным для новичков мне кажется: ClickHouse, Redash, Superset, GitLab. Они интерактивны, к каждому есть туториал. На работе могут быть другие инструменты, но их освоения тоже не составит проблем.
3. AB тест
Здесь и пригодятся все гипотезы, сформулированные в предыдущих проектах: теперь их можно проверить. Сначала планируем эксперимент: рассчитываем необходимое кол-во пользователей, подобираем методы проверки. Огромный простор для воображения: можно подобрать более чувствительные метрики, можно потестить систему сплитования, можно использовать методы понижения дисперсии. Но лучше начать с самого простого: хоть как-то выбрать пользователей, разделить на тест и контроль и использовать t-тест, Манна - Уитни, проинтерпретировать результат + прикрутить все рабочее окружение из второго проекта. Если получится что-то рабочее, то прикручиваем хэширование с солью, АА-тест, бутстреп, cuped, бакетное преобразование и тд. Примеры AB тестов всякого качества можно посмотреть на том же kaggle, github.
4. Пайплан
Обычно данные хранятся в разных системах и в разных формах, аналитику нередко приходится перетаскивать данные в хранилище и выдавать их в виде графиков и табличек. Для имитации чего-то подобного можно взять данные из одной базы данных, возможно, эти источником будет также являться Kafka, положить в Hadoop, и поместить данные в другую базу данных, используя преобразования Spark, и запустить это все дело через Airflow. После нашего курса дата инженерия будете такое щелкать как орешки😎😎.
5. Система алертов
На работе придется писать отчеты, поэтому лучше автоматизировать этот процесс через тг бота. Создаем, пишем скрипт для сборки отчета по выбранной бд. Подумайте, какие метрики выбрать, за какой период и как лучше представить отчет. Автоматизируйте отправку отчета с помощью Airflow. В дополнение к отчетам можно реализовать поиск аномалий: детектировать необычное поведения метрик и отправлять в чат. Выбираем метрики, срезы, частоту для мониторинга, метод детектирования. Методы можно разделить на статистические (правило трех сигм) и на основе мл алгоритмов (DBSCAN, LOF). Как всегда для начала реализовываем самое простое.
@postypashki_old
Финальные 4 часа скидки на наши продвинутые курсы подходят к концу. В честь этого подготовили самые популярные проекты, еще больше пет проектов будут на нашем курсе аналитика хард.
1. Работа с данными
В новом продукте придется выстраивать аналитические процессы. Но для начала нужно просто привести данные к удобному виду. Так данные могут храниться не оптимально: например, есть база данных VK с одной таблицей, где хранятся посты и авторы этих постов. Скорее всего, постов будет намного больше, чем авторов, поэтому разумно создать новую таблицу, переместить туда посты, а из исходной удалить. Помимо такого не оптимального хранения, данные могут быть банально грязные: аномалии, дубликаты и пропуски, неудобный тип переменных. Для "очистки" данные пригодятся статистические методы и визуализация. Также уже на этом этапе можно формулировать какие-то гипотезы. Для выполнения такого задания достаточно открыть jupyter notebook взять любой сырой датасет c того же kaggle, имитирующий "большие данные", там же по запросу в духе "Exploratory Data Analysis" можно посмотреть примеры других пользователей.
2. Дашборды
Результаты предыдущей работы с данными нужно предоставить в удобном виде. Согласитесь, что ко всем важным показателям нашего продукта должен быть простой и быстрый доступ. Странно было бы если всей команде каждый раз приходилось писать запрос, чтобы узнать сколько у продукта пользователей. Поэтому выстраивание аналитики начинается с выведения ключевых метрик как DAU, WAU, MAU. Целевая задача состоит в визуализации и презентации, также можно повыдумывать свои метрики и сформулировать какие-то гипотезы, глядя на графики. Например, видим пик активных пользователей (маркетологи закупили рекламу), а потом видим отток — давайте посмотрим на retention и оценим насколько реклама эффективна. Также придется найти данные и настроить рабочее окружение, наиболее удачным для новичков мне кажется: ClickHouse, Redash, Superset, GitLab. Они интерактивны, к каждому есть туториал. На работе могут быть другие инструменты, но их освоения тоже не составит проблем.
3. AB тест
Здесь и пригодятся все гипотезы, сформулированные в предыдущих проектах: теперь их можно проверить. Сначала планируем эксперимент: рассчитываем необходимое кол-во пользователей, подобираем методы проверки. Огромный простор для воображения: можно подобрать более чувствительные метрики, можно потестить систему сплитования, можно использовать методы понижения дисперсии. Но лучше начать с самого простого: хоть как-то выбрать пользователей, разделить на тест и контроль и использовать t-тест, Манна - Уитни, проинтерпретировать результат + прикрутить все рабочее окружение из второго проекта. Если получится что-то рабочее, то прикручиваем хэширование с солью, АА-тест, бутстреп, cuped, бакетное преобразование и тд. Примеры AB тестов всякого качества можно посмотреть на том же kaggle, github.
4. Пайплан
Обычно данные хранятся в разных системах и в разных формах, аналитику нередко приходится перетаскивать данные в хранилище и выдавать их в виде графиков и табличек. Для имитации чего-то подобного можно взять данные из одной базы данных, возможно, эти источником будет также являться Kafka, положить в Hadoop, и поместить данные в другую базу данных, используя преобразования Spark, и запустить это все дело через Airflow. После нашего курса дата инженерия будете такое щелкать как орешки😎😎.
5. Система алертов
На работе придется писать отчеты, поэтому лучше автоматизировать этот процесс через тг бота. Создаем, пишем скрипт для сборки отчета по выбранной бд. Подумайте, какие метрики выбрать, за какой период и как лучше представить отчет. Автоматизируйте отправку отчета с помощью Airflow. В дополнение к отчетам можно реализовать поиск аномалий: детектировать необычное поведения метрик и отправлять в чат. Выбираем метрики, срезы, частоту для мониторинга, метод детектирования. Методы можно разделить на статистические (правило трех сигм) и на основе мл алгоритмов (DBSCAN, LOF). Как всегда для начала реализовываем самое простое.
@postypashki_old
Forwarded from Pavel Zloi
Поднять FRIDA API не просто
Несколько дней пытался поднять ai-forever/FRIDA в формате API сервера через существующие популярные решения для инференса с доступом аля OpenAI-подобное API. По понятным причинам вариант запуска через Ollama не рассматриваю из-за слабых метрик квантованных моделей.
Попробовал первым делом vLLM, но к сожалению модели архитектуры T5 авторы данного проекта уже два года добавляют, всё никак не добавят (подробнее тут, тут и тут), так что увы и ах, едем дальше.
Следующим в моём списке была Text Embedding Inference (TEI) от не абы кого, а самих Hugginп Face, однако, там тоже поддержки T5 пока ещё нет (смотри тут), а самый свежий билд (1.8) говорит при запуске Фриды что:
Далее пошёл смотреть справится ли Triton Inference Server (TIS) основанный на TensorRT-LLM, там судя по спецификациям эмбеддеры T5 поддерживаются, но запускается это всё с таким большим скрипом, что мне кажется странным, что этот бэкенд называют продакшен-реди. Немного пострадав с этим проектом побрёл искать обёртки, нашёл openai_trtllm, там обнаружил готовый docker-compose.yml, обрадовался, думал смогу всё красиво собрать, но контейнеры падают с ошибкой в процессе сборки.
После этой неудачи, словно Ийон Тихий, пошёл в отрыв и стал искать любой API сервер, который заявляет поддержку T5 эмбеддеров и предоставляет формат работы совместимый с OpenAI API клиентами, перерыл десятки проектов, маленьких и больших, и нашёл одни проект соответствующий всем критериям, называется он Infinity, очень легко настраивается, сам скачивает модели, сам всё запускает, может предоставить доступ сразу к нескольким эмбеддинговым моделям.
Вот мой docker-compose.yml конфиг для запуска FRIDA через Infinity сервер:
(учитывая наличие принудительно включенной телеметрии предположу, что возможно в будущем проект станет платным)
Данный сервер поддерживает разные движки (engine) для инференса:
- torch - это полноценная реализация обёртки над sentence-transformers, то есть почти все существующие эмбеддеры в данном режиме будут поддерживаться
- optimum - для запуска ONNX моделей
- ctranslate2 - только для BERT'очек
После запуска на него можно делать HTTP запросы вида:
В ответе будет извлеченный из текста вектор, бай зе вей, можно передать массив из строк в input, но это думаю вы все и так знаете.
Несколько дней пытался поднять ai-forever/FRIDA в формате API сервера через существующие популярные решения для инференса с доступом аля OpenAI-подобное API. По понятным причинам вариант запуска через Ollama не рассматриваю из-за слабых метрик квантованных моделей.
Попробовал первым делом vLLM, но к сожалению модели архитектуры T5 авторы данного проекта уже два года добавляют, всё никак не добавят (подробнее тут, тут и тут), так что увы и ах, едем дальше.
Следующим в моём списке была Text Embedding Inference (TEI) от не абы кого, а самих Hugginп Face, однако, там тоже поддержки T5 пока ещё нет (смотри тут), а самый свежий билд (1.8) говорит при запуске Фриды что:
unknown variant `t5`, expected one of `bert`, `xlm-roberta`, `camembert`, `roberta`, `distilbert`, `nomic_bert`, `mistral`, `gte`, `new`, `qwen2`, `qwen3`, `mpnet`, `modernbert`
Далее пошёл смотреть справится ли Triton Inference Server (TIS) основанный на TensorRT-LLM, там судя по спецификациям эмбеддеры T5 поддерживаются, но запускается это всё с таким большим скрипом, что мне кажется странным, что этот бэкенд называют продакшен-реди. Немного пострадав с этим проектом побрёл искать обёртки, нашёл openai_trtllm, там обнаружил готовый docker-compose.yml, обрадовался, думал смогу всё красиво собрать, но контейнеры падают с ошибкой в процессе сборки.
После этой неудачи, словно Ийон Тихий, пошёл в отрыв и стал искать любой API сервер, который заявляет поддержку T5 эмбеддеров и предоставляет формат работы совместимый с OpenAI API клиентами, перерыл десятки проектов, маленьких и больших, и нашёл одни проект соответствующий всем критериям, называется он Infinity, очень легко настраивается, сам скачивает модели, сам всё запускает, может предоставить доступ сразу к нескольким эмбеддинговым моделям.
Вот мой docker-compose.yml конфиг для запуска FRIDA через Infinity сервер:
x-shared-logs: &shared-logs
logging:
driver: "json-file"
options:
max-size: "100k"
services:
infinity:
image: michaelf34/infinity:0.0.76
restart: unless-stopped
command: >
v2
--model-id ai-forever/FRIDA
--engine torch
--port "7997"
environment:
- HF_HOME=/app/.cache
- HF_HUB_ENABLE_HF_TRANSFER=0
- DO_NOT_TRACK=1
- HF_HUB_DISABLE_TELEMETRY=1
- INFINITY_ANONYMOUS_USAGE_STATS=0
volumes:
- ./infinity_data:/app/.cache
ports:
- "7997:7997"
deploy:
resources:
reservations:
devices:
- driver: nvidia
device_ids: [ '1' ]
capabilities: [ gpu ]
<<: *shared-logs
Данный сервер поддерживает разные движки (engine) для инференса:
- torch - это полноценная реализация обёртки над sentence-transformers, то есть почти все существующие эмбеддеры в данном режиме будут поддерживаться
- optimum - для запуска ONNX моделей
- ctranslate2 - только для BERT'очек
После запуска на него можно делать HTTP запросы вида:
curl -s https://localhost:7997/embeddings \
-H 'Content-Type: application/json' \
-d '{"input":"Привет! Как дела?"}'
В ответе будет извлеченный из текста вектор, бай зе вей, можно передать массив из строк в input, но это думаю вы все и так знаете.
Forwarded from Pavel Zloi
Ну и само собой Фриду можно попробовать через моё публичное API вот такой командой:
И через любой openai клиент, например:
curl https://api.rpa.icu/embeddings \
-H "Content-Type: application/json" \
-H "Authorization: Bearer https://t.iss.one/evilfreelancer" \
-d '{
"model": "FRIDA",
"input": "Привет! Как дела?"
}'
И через любой openai клиент, например:
from openai import OpenAI
client = OpenAI(
api_key="https://t.iss.one/evilfreelancer",
base_url="https://api.rpa.icu"
)
response = client.embeddings.create(
model="FRIDA",
input="Привет! Как дела?"
)
print(response)
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Агентские фреймворки для работы
Поскольку вам больше нравятся всякие прикольные штуки с ссылками, чтобы их можно было разобрать, то разберемся сегодня с агентскими фреймворками, сразу с кодом. Трейсхолдом для меня стал гитхаб и 15к звездочек на нем, потому что разработок сейчас очень много.
1️⃣ Llamaindex
Основной фокус этого фреймворка всегда делался на работу с данными и индексацию разнородных источников. Не смотря на популярность, в нем нет нагромождения механизмов управления агентами, в отличие от того же Langchain.
Основные фишки:
2️⃣ Langchain
Самый известный и тяжелый фреймворк по количеству инстрментов: цепочки, агенты, память и тулы. Но, к сожалению, это медленно губит этот фреймворк, куча непонятных методов, огромная документация и боль для разработки
Фишечки:
3️⃣ Haystack
Наиболее продакшн ориентированный фреймворк, который предлагает готовые UI, устойчивые пайплайны, поддержку Elasticsearch/Weaviate в одном пакете. Заточенность на поиск данных и систем RAG.
Фишки:
4️⃣ Semantic-kernel
Разработочка от Microsoft, в которой вы сначала пишите целевую функцию, а затем разбиваете ее на шаги, применяя плагины. Подходит для тех, кто хочет интреграцию с C#/.NET сервисами, правда смущает множественное использование Azure.
Фишечки:
5️⃣ Meta GPT
Наше любимое MCP в полном понимании - у каждого агента своя роль и зона ответственности. Многое работает из коробки - получаешь готовые сценарии генераций требований, кода и тестов.
Фишечки:
6️⃣ Autogen
Еще одна разработка от ребят, которые очень любят обновлять окна. В целом, это мультиагенсткий фреймворк с гибкой маршрутизацией запросов.
Фишечки:
7️⃣ crewAI
Еще один для разработки мультиагентов, но без обилия зависимостей и сложных пайпланов - идеально, если демо через два часа
Фишечки:
8️⃣ Mastra
Очень крутой проект, так как помимо запуска и разрабокти агентов, предлает визуальные панели с метриками, трасировкой и алертами.
Фишечки:
Как вам такой пост?) Какие фреймворки вы еще используете в разработке?) Обязательно ставьте реакции и пишите комментарии💗
Поскольку вам больше нравятся всякие прикольные штуки с ссылками, чтобы их можно было разобрать, то разберемся сегодня с агентскими фреймворками, сразу с кодом. Трейсхолдом для меня стал гитхаб и 15к звездочек на нем, потому что разработок сейчас очень много.
Основной фокус этого фреймворка всегда делался на работу с данными и индексацию разнородных источников. Не смотря на популярность, в нем нет нагромождения механизмов управления агентами, в отличие от того же Langchain.
Основные фишки:
- Построение деревьев индексов (TreeIndex) и граф-индексов (GraphIndex).
- Автоматическая сегментация и аннотирование документов перед поиском.
- Встраиваемая система кэширования и переиспользуемых запросов
Самый известный и тяжелый фреймворк по количеству инстрментов: цепочки, агенты, память и тулы. Но, к сожалению, это медленно губит этот фреймворк, куча непонятных методов, огромная документация и боль для разработки
Фишечки:
- Построение многошаговых workflows: от простых question–answer до сложных бизнес-процессов.
- Встроенные шаблоны “ConversationChain”, “RetrievalQA”, “AgentExecutor”.
- Модули памяти: chat, vector, SQL, даже Redis.
Наиболее продакшн ориентированный фреймворк, который предлагает готовые UI, устойчивые пайплайны, поддержку Elasticsearch/Weaviate в одном пакете. Заточенность на поиск данных и систем RAG.
Фишки:
- “Document Store” (Elasticsearch, FAISS, Weaviate, Milvus).
- Конвейеры с логированием, кэшированием и Fallback-механизмами.
- Встроенная фронт-энд панель (Streamlit/Flask) для проверки качества и аналitika запросов.
Разработочка от Microsoft, в которой вы сначала пишите целевую функцию, а затем разбиваете ее на шаги, применяя плагины. Подходит для тех, кто хочет интреграцию с C#/.NET сервисами, правда смущает множественное использование Azure.
Фишечки:
- Planner API: создаёт план из нескольких вызовов LLM, выбирая их автоматически.
- Поддержка Python и C#, одинаковый SDK-стиль для обеих платформ.
Наше любимое MCP в полном понимании - у каждого агента своя роль и зона ответственности. Многое работает из коробки - получаешь готовые сценарии генераций требований, кода и тестов.
Фишечки:
- Сценарии коллаборативного генерирования: репорты, доски задач, документация.
- Визуализация этапов работы и hand-off между агентами.
Еще одна разработка от ребят, которые очень любят обновлять окна. В целом, это мультиагенсткий фреймворк с гибкой маршрутизацией запросов.
Фишечки:
- Синхронные и асинхронные сценарии – агенты могут разговаривать как в реальном времени, так и по расписанию.
- «Function calling» и кастомные утилиты — легко расширяется внешними API.
- Mock-режим: тренируете взаимодействие агентов без реальных LLM-вызовов.
Еще один для разработки мультиагентов, но без обилия зависимостей и сложных пайпланов - идеально, если демо через два часа
Фишечки:
- DSL для описания агентов, их навыков и целей.
- Автоматическое логирование каждого шага и возможность «перемотки» диалога.
Очень крутой проект, так как помимо запуска и разрабокти агентов, предлает визуальные панели с метриками, трасировкой и алертами.
Фишечки:
- Дашборд с графиками по latency, throughput, ошибкам агентов.
- Встроенный мониторинг SLA и оповещения через email/Slack.
Как вам такой пост?) Какие фреймворки вы еще используете в разработке?) Обязательно ставьте реакции и пишите комментарии
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Зависимость от Nikotin'a Chat
На работе заставляют использовать Langchain + langgraph, плюс спёрли фишки у agno
Вне работы люблю llamaindex)
Вне работы люблю llamaindex)
Forwarded from DziS Science | Data Science
Привет всем!👋
Держите handbook по поиску фродовых транзакции в финтехе.
Достаточно хорошая выжимка.
В ней вас проводят по полной постановке задачи, от возможных сценариев экспертной классификации фрода, погружая в проблематику, далее вводят метрики, активно используемые для решения задачи, затем погружают в моделью часть, вплоть до моделей Deep Learning.
Материал достаточно структурированный, подойдет как и начинающим, кто хочет начать работать в данном направлении, но не понимает что и как там делается, так и тем, кто уже работает в антифроде.
Из плюсов отмечу, что в каждой главе сначала теоретический минимум, за которым следует практический пример.
#ds_лайфхаки
Держите handbook по поиску фродовых транзакции в финтехе.
Достаточно хорошая выжимка.
В ней вас проводят по полной постановке задачи, от возможных сценариев экспертной классификации фрода, погружая в проблематику, далее вводят метрики, активно используемые для решения задачи, затем погружают в моделью часть, вплоть до моделей Deep Learning.
Материал достаточно структурированный, подойдет как и начинающим, кто хочет начать работать в данном направлении, но не понимает что и как там делается, так и тем, кто уже работает в антифроде.
Из плюсов отмечу, что в каждой главе сначала теоретический минимум, за которым следует практический пример.
#ds_лайфхаки
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DeepSchool
Диффузионные модели: пошаговый план изучения
Диффузионные модели, как и трансформеры, внесли весомый вклад в глубокое обучение и определили современное состояние ИИ. Они лежат в основе генерации изображений (Stable Diffusion, DALL·E), синтеза видео (Sora, Runway ML), дизайна молекул и даже управления роботами (Teslabot, 1X). Сегодня во многих областях от DL-инженеров всё чаще требуется глубинное понимание диффузионных моделей. Чтобы помочь детальнее разобраться в их устройстве, мы подготовили пошаговый план изучения, а также основные ресурсы.
План изучения
1. Основы теории вероятности и статистики
Диффузионные модели, как и все генеративные модели, основаны на принципах теории вероятности. Фундамент для их понимания — условные и маргинальные распределения, правила сложения и произведения, свойства нормального распределения, расстояние Кульбака-Лейблера, неравенство Йенсена.
Ресурсы: MML (главы 6.1-6.5); DLFC (глава 2); UDL (Appendix C), см. далее блок «Основные ресурсы».
2. Вариационные автоэнкодеры (VAE)
Диффузионные модели и VAE — вариационные подходы к генеративному моделированию. Оба используют evidence lower bound (ELBO) для получения обучаемой функции потерь. Поскольку VAE проще для понимания, рекомендуем изучить его перед переходом к диффузионным моделям.
Ресурсы: UDL (глава 17); DLFC (глава 19.2); ЯУМО (глава 8.2); Лекция Дмитрия Ветрова.
3. Denoising Diffusion Probabilistic Models (DDPM)
Переходим к изучению самих диффузионных моделей! Начните с основополагающей работы, которая впервые раскрыла потенциал диффузионных моделей, — DDPM.
Ресурсы: UDL (глава 18); DLFC (главы 20.1-20.3); ЯУМО (глава 8.5); Лекция Дмитрия Ветрова; Разбор статьи с кодом от Hugging Face.
4. Контролируемая генерация
Диффузионные модели выучивают полное распределение данных. Для направленной генерации используют classifier-free guidance и classifier guidance (они не меняют веса на этапе генерации, но требуют обучения модели с поддержкой таких режимов) или методы дообучения, как ControlNet и LoRA.
Ресурсы: DLFC (глава 20.4); ЯУМО (глава 8.5); CS492(D) (лекция 7).
5. Ускорение генерации
Основной недостаток DDPM — низкая скорость генерации. Для решения этой проблемы разработаны более эффективные методы: Denoising Diffusion Implicit Models (DDIM), стохастические диффузионные солверы и дистилляция.
Ресурсы: CS492(D) (лекции 5, 6, 14); Лекция Дмитрия Ветрова; Обзорная статья по быстрым диффузионным моделям.
6. Практическое программирование
Ничто не даёт такого понимания концепта в DL, как программирование. Поэтому для закрепления теории рекомендуем выполнить задания из курса CS492(D) и Diffusion Models Course от Hugging Face.
Основные ресурсы
- Mathematics for Machine Learning (MML)
- Understanding Deep Learning (UDL)
- Deep Learning Foundations and Concepts (DLFC)
- Учебник по машинному обучению от Яндекс (ЯУМО)
- Курс CS492(D): Diffusion Models and Their Applications
Автор: Шамиль Мамедов
Диффузионные модели, как и трансформеры, внесли весомый вклад в глубокое обучение и определили современное состояние ИИ. Они лежат в основе генерации изображений (Stable Diffusion, DALL·E), синтеза видео (Sora, Runway ML), дизайна молекул и даже управления роботами (Teslabot, 1X). Сегодня во многих областях от DL-инженеров всё чаще требуется глубинное понимание диффузионных моделей. Чтобы помочь детальнее разобраться в их устройстве, мы подготовили пошаговый план изучения, а также основные ресурсы.
План изучения
1. Основы теории вероятности и статистики
Диффузионные модели, как и все генеративные модели, основаны на принципах теории вероятности. Фундамент для их понимания — условные и маргинальные распределения, правила сложения и произведения, свойства нормального распределения, расстояние Кульбака-Лейблера, неравенство Йенсена.
Ресурсы: MML (главы 6.1-6.5); DLFC (глава 2); UDL (Appendix C), см. далее блок «Основные ресурсы».
2. Вариационные автоэнкодеры (VAE)
Диффузионные модели и VAE — вариационные подходы к генеративному моделированию. Оба используют evidence lower bound (ELBO) для получения обучаемой функции потерь. Поскольку VAE проще для понимания, рекомендуем изучить его перед переходом к диффузионным моделям.
Ресурсы: UDL (глава 17); DLFC (глава 19.2); ЯУМО (глава 8.2); Лекция Дмитрия Ветрова.
3. Denoising Diffusion Probabilistic Models (DDPM)
Переходим к изучению самих диффузионных моделей! Начните с основополагающей работы, которая впервые раскрыла потенциал диффузионных моделей, — DDPM.
Ресурсы: UDL (глава 18); DLFC (главы 20.1-20.3); ЯУМО (глава 8.5); Лекция Дмитрия Ветрова; Разбор статьи с кодом от Hugging Face.
4. Контролируемая генерация
Диффузионные модели выучивают полное распределение данных. Для направленной генерации используют classifier-free guidance и classifier guidance (они не меняют веса на этапе генерации, но требуют обучения модели с поддержкой таких режимов) или методы дообучения, как ControlNet и LoRA.
Ресурсы: DLFC (глава 20.4); ЯУМО (глава 8.5); CS492(D) (лекция 7).
5. Ускорение генерации
Основной недостаток DDPM — низкая скорость генерации. Для решения этой проблемы разработаны более эффективные методы: Denoising Diffusion Implicit Models (DDIM), стохастические диффузионные солверы и дистилляция.
Ресурсы: CS492(D) (лекции 5, 6, 14); Лекция Дмитрия Ветрова; Обзорная статья по быстрым диффузионным моделям.
6. Практическое программирование
Ничто не даёт такого понимания концепта в DL, как программирование. Поэтому для закрепления теории рекомендуем выполнить задания из курса CS492(D) и Diffusion Models Course от Hugging Face.
Основные ресурсы
- Mathematics for Machine Learning (MML)
- Understanding Deep Learning (UDL)
- Deep Learning Foundations and Concepts (DLFC)
- Учебник по машинному обучению от Яндекс (ЯУМО)
- Курс CS492(D): Diffusion Models and Their Applications
Автор: Шамиль Мамедов
Forwarded from Sinекура
Недавно вышла работа о безопасности AI с >40 авторов из OpenAI, Anthropic, DeepMind, METR, Redwood Research, Meta, UK AI Security Institute, Apollo Research... Среди авторов — Йошуа Бенджи, Войцех Заремба, знаменитые "AI-безопасники" Нил Нанда, Анка Драган, Дэн Хендрикс, Виктория Краковна, среди "expert endorsers" — Джеффри Хинтон, Сэм Боумэн, Джон Шульман и Илья Суцкевер... На чём же все они смогли сойтись? Написал об этом пост, сюда выкладываю сокращённую версию:
Не выключайте прослушку: о важности CoT для интерпретируемости
Весь смысл статьи "Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety" сводится к тому, чтобы сказать разработчикам LLM: не отказывайтесь от простого советского человекочитаемого CoT (chain of thought, "листочек для записей" у рассуждающих моделей)! Почему?
Для AI safety очень важна интерпретируемость; я недавно писал об этом большой пост, а Дарио Амодеи — эссе "The Urgency of Interpretability"; интересующимся рекомендую как минимум второе, но буду рад, если прочитаете и первое. Успехи там есть, но не полные, до понимания того, как большая нейронная сеть принимает решения, нам ещё очень далеко.
И вот появляется CoT, который даёт максимально прямой путь: если модель "думает" на человеческом языке, мы можем буквально читать её мысли! И оказывается, что эти мысли пока что действительно правдивы, и мы действительно видим, что модель думает, даже в тех случаях, когда она потом решает нас обмануть!
Мониторинг CoT — уникальная возможность для обеспечения безопасности AI-систем. Например, Meincke et al. (2024) рассказывают о том, что модели уже способны преследовать скрытые цели, не признаваясь в этом, но CoT всегда всё выдаёт (рис. 2), а Baker et al. (2025) написали целую статью про CoT monitoring, и там тоже постоянно встречаются примеры, когда модель просто честно думает, что собирается делать, даже если в итоге финальные действия выглядят безобидно (рис. 3).
Это прекрасная возможность, но довольно хрупкая. Korbak et al. (2025) предупреждают о нескольких факторах, которые могут её разрушить.
— Язык может стать непонятным из-за использования RL. При масштабировании обучения с подкреплением модели могут начать использовать всё менее понятные человеку "языки" для своих рассуждений (Korbak et al., 2022).
— Оптимизация CoT, и прямая, и непрямая, портит его. Например, бывают process reward models (модели, оценивающие путь к решению в RL, а не только ответ), которые следят за тем, чтобы LLM не совершали "мыслепреступлений"; результатом этого, разумеется, может стать то, что модели просто не будут думать лишнего в открытом виде. К обфускации CoT может привести даже непрямая оптимизация вроде "давайте покажем CoT людям, которые оценивают результат в RLHF, и это повлияет на их оценки" (Baker et al., 2025).
— Рассуждения в латентном пространстве не порождают CoT. Модели, способные проводить рассуждения в латентном пространстве без вербализации, могут полностью обойти необходимость в понятных человеку записях в "блокнотике". Это направление сейчас весьма активно развивается, кстати (Hao et al., 2024; Geiping et al., 2025).
Что же делать? Korbak et al. (2025) рекомендуют разработать эффективные метрики для того, насколько возможно следить за CoT (monitorability), а потом публиковать эти метрики и учитывать их. Кстати, в реальности не нужно, чтобы мониторинг срабатывал в 99% случаев, если его можно перезапускать несколько раз так, чтобы ошибки не слишком коррелировали; см., например, (Bhatt et al., 2025).
В философии сознания есть проблема: можем ли мы доверять тому, что кто-то говорит о своих мыслях? А здесь ещё и сами "мысли" являются результатом оптимизации. Модели могут порождать правдоподобные, но вводящие в заблуждение объяснения — и очень важно, чтобы мы никоим образом не пытались это поощрять. Скорее всего, человеческий язык — удобное, но не идеальное промежуточное представление, и для того, чтобы мониторинг CoT оставался возможным, нам нужно приложить нетривиальные усилия. Это окно в мышление LLM может закрыться быстрее, чем нам бы хотелось.
Не выключайте прослушку: о важности CoT для интерпретируемости
Весь смысл статьи "Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety" сводится к тому, чтобы сказать разработчикам LLM: не отказывайтесь от простого советского человекочитаемого CoT (chain of thought, "листочек для записей" у рассуждающих моделей)! Почему?
Для AI safety очень важна интерпретируемость; я недавно писал об этом большой пост, а Дарио Амодеи — эссе "The Urgency of Interpretability"; интересующимся рекомендую как минимум второе, но буду рад, если прочитаете и первое. Успехи там есть, но не полные, до понимания того, как большая нейронная сеть принимает решения, нам ещё очень далеко.
И вот появляется CoT, который даёт максимально прямой путь: если модель "думает" на человеческом языке, мы можем буквально читать её мысли! И оказывается, что эти мысли пока что действительно правдивы, и мы действительно видим, что модель думает, даже в тех случаях, когда она потом решает нас обмануть!
Мониторинг CoT — уникальная возможность для обеспечения безопасности AI-систем. Например, Meincke et al. (2024) рассказывают о том, что модели уже способны преследовать скрытые цели, не признаваясь в этом, но CoT всегда всё выдаёт (рис. 2), а Baker et al. (2025) написали целую статью про CoT monitoring, и там тоже постоянно встречаются примеры, когда модель просто честно думает, что собирается делать, даже если в итоге финальные действия выглядят безобидно (рис. 3).
Это прекрасная возможность, но довольно хрупкая. Korbak et al. (2025) предупреждают о нескольких факторах, которые могут её разрушить.
— Язык может стать непонятным из-за использования RL. При масштабировании обучения с подкреплением модели могут начать использовать всё менее понятные человеку "языки" для своих рассуждений (Korbak et al., 2022).
— Оптимизация CoT, и прямая, и непрямая, портит его. Например, бывают process reward models (модели, оценивающие путь к решению в RL, а не только ответ), которые следят за тем, чтобы LLM не совершали "мыслепреступлений"; результатом этого, разумеется, может стать то, что модели просто не будут думать лишнего в открытом виде. К обфускации CoT может привести даже непрямая оптимизация вроде "давайте покажем CoT людям, которые оценивают результат в RLHF, и это повлияет на их оценки" (Baker et al., 2025).
— Рассуждения в латентном пространстве не порождают CoT. Модели, способные проводить рассуждения в латентном пространстве без вербализации, могут полностью обойти необходимость в понятных человеку записях в "блокнотике". Это направление сейчас весьма активно развивается, кстати (Hao et al., 2024; Geiping et al., 2025).
Что же делать? Korbak et al. (2025) рекомендуют разработать эффективные метрики для того, насколько возможно следить за CoT (monitorability), а потом публиковать эти метрики и учитывать их. Кстати, в реальности не нужно, чтобы мониторинг срабатывал в 99% случаев, если его можно перезапускать несколько раз так, чтобы ошибки не слишком коррелировали; см., например, (Bhatt et al., 2025).
В философии сознания есть проблема: можем ли мы доверять тому, что кто-то говорит о своих мыслях? А здесь ещё и сами "мысли" являются результатом оптимизации. Модели могут порождать правдоподобные, но вводящие в заблуждение объяснения — и очень важно, чтобы мы никоим образом не пытались это поощрять. Скорее всего, человеческий язык — удобное, но не идеальное промежуточное представление, и для того, чтобы мониторинг CoT оставался возможным, нам нужно приложить нетривиальные усилия. Это окно в мышление LLM может закрыться быстрее, чем нам бы хотелось.
Forwarded from Sinекура
Хочется наслаждаться летом, но вместо этого постоянно дедлайн форсмажором погоняет. Нынешний форсмажор так и вовсе изрядно подрывает веру в человечество; с другой стороны, в итоге пришлось взять в руки шашки и попрограммировать самостоятельно, чем-то это даже и приятно.
В общем, несмотря ни на что (подобно Гомеру и Борхесу), наслаждаться летом всё равно стараюсь! И в этом направлении даже кое-что получается. :) Но писать много новых постов пока вряд ли буду, давайте вместо этого сегодня продолжим начатый в прошлый раз ностальгический обзор моего блога из Synthesis AI, который сейчас переезжает на мой сайт.
Driving Model Performance with Synthetic Data — большая серия, которая во многом потом вошла в книгу "Synthetic Data for Deep Learning" (естественно, в сильно расширенном виде). Здесь посты уже становятся побольше и посвящены разным вещам, так что перечислю их отдельно; серию я иллюстрировал через Мерилин Монро, но, кажется, в последнем посте что-то пошло не так.)
Part I: Augmentations in Computer Vision — про аугментации, Albumentations и всё такое прочее; самый простой, но и самый полезный на практике вид синтетических данных
Part II: Smart Augmentations — про то, как делать более умные аугментации, а именно о том, как автоматически настраивать лучшие возможные композиции аугментации, и о Mixup; состязательных аугментаций тогда ещё, кажется, не придумали, но они бы тоже попали именно сюда
Part III: Domain Adaptation Overview — какие бывают варианты того, как модель, обученную на одном виде данных, приспособить к другому; пути здесь (в 2021 году было) по сути два: refinement данных или adaptation самой модели
Part IV: Gaze Estimation and GANs — про статью от Apple, которая когда-то была фактически первым успешным примером именно synthetic-to-real data refinement: как GAN'ом перерисовать картинку так, чтобы синтетические картинки стали более реалистичными (и могли потом использоваться для gaze estimation, оценки направления взгляда)
Part V: Synthetic-to-Real Refinement — дальнейшее развитие этой идеи, обзор других подходов, тоже в то время почти неизбежно основанных на GAN'ах (да и сейчас в style transfer, кажется, GAN'ы ещё не умерли, в отличие от text-to-image)
Part VI: Real-to-Synthetic Data — а можно сделать и наоборот, реальные данные сделать более похожими на синтетику, чтобы лучше работала обученная на синтетике модель; этот сюжет, кажется, особого развития потом не получил, но переворот любопытный
Part VII: Model-Based Domain Adaptation — ну и собственно о том, как модель адаптировать; здесь в основном про основополагающую работу Ганина и Лемпицкого, где они обращали градиенты, и о том, как это потом развилось в domain separation networks
В общем, давно всё это было, но приятно было открыть ещё раз. В следующий раз анонсирую более "вечные" посты, надеюсь, будет интереснее.
В общем, несмотря ни на что (подобно Гомеру и Борхесу), наслаждаться летом всё равно стараюсь! И в этом направлении даже кое-что получается. :) Но писать много новых постов пока вряд ли буду, давайте вместо этого сегодня продолжим начатый в прошлый раз ностальгический обзор моего блога из Synthesis AI, который сейчас переезжает на мой сайт.
Driving Model Performance with Synthetic Data — большая серия, которая во многом потом вошла в книгу "Synthetic Data for Deep Learning" (естественно, в сильно расширенном виде). Здесь посты уже становятся побольше и посвящены разным вещам, так что перечислю их отдельно; серию я иллюстрировал через Мерилин Монро, но, кажется, в последнем посте что-то пошло не так.)
Part I: Augmentations in Computer Vision — про аугментации, Albumentations и всё такое прочее; самый простой, но и самый полезный на практике вид синтетических данных
Part II: Smart Augmentations — про то, как делать более умные аугментации, а именно о том, как автоматически настраивать лучшие возможные композиции аугментации, и о Mixup; состязательных аугментаций тогда ещё, кажется, не придумали, но они бы тоже попали именно сюда
Part III: Domain Adaptation Overview — какие бывают варианты того, как модель, обученную на одном виде данных, приспособить к другому; пути здесь (в 2021 году было) по сути два: refinement данных или adaptation самой модели
Part IV: Gaze Estimation and GANs — про статью от Apple, которая когда-то была фактически первым успешным примером именно synthetic-to-real data refinement: как GAN'ом перерисовать картинку так, чтобы синтетические картинки стали более реалистичными (и могли потом использоваться для gaze estimation, оценки направления взгляда)
Part V: Synthetic-to-Real Refinement — дальнейшее развитие этой идеи, обзор других подходов, тоже в то время почти неизбежно основанных на GAN'ах (да и сейчас в style transfer, кажется, GAN'ы ещё не умерли, в отличие от text-to-image)
Part VI: Real-to-Synthetic Data — а можно сделать и наоборот, реальные данные сделать более похожими на синтетику, чтобы лучше работала обученная на синтетике модель; этот сюжет, кажется, особого развития потом не получил, но переворот любопытный
Part VII: Model-Based Domain Adaptation — ну и собственно о том, как модель адаптировать; здесь в основном про основополагающую работу Ганина и Лемпицкого, где они обращали градиенты, и о том, как это потом развилось в domain separation networks
В общем, давно всё это было, но приятно было открыть ещё раз. В следующий раз анонсирую более "вечные" посты, надеюсь, будет интереснее.