Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
How we built fast UPDATEs for the ClickHouse column store
▫️Part 1: Purpose-built engines
▫️Part 2: SQL-style UPDATEs
В первой части автор Том Шрайбер поясняет, как ClickHouse обходится без традиционного обновления строк, превращая UPDATE/DELETE в вставки с помощью специальных движков вроде ReplacingMergeTree, CollapsingMergeTree и др., которые позднее сливаются фоновым процессом, обеспечивая высокую скорость и масштабируемость на аналитических нагрузках. Это решение позволило объединить эффективность вставок и возможность правки данных без ущерба для быстрого чтения.
Вторая статья рассказывает о новой архитектуре патч‑партиций (patch parts), благодаря которым ClickHouse наконец поддерживает классический синтаксис UPDATE … WHERE, но без затрат на перестройку колонок: патч‑партиции содержат только изменённые значения и сливаются в фоновом режиме, обеспечивая мгновенную видимость изменений и высокую производительность. Автор подробно описывает эволюцию от тяжёлых мутаций до экономных, декларативных обновлений на основе SQL, вдохновлённых механизмами MergeTree.
#ClickHouse
▫️Part 1: Purpose-built engines
▫️Part 2: SQL-style UPDATEs
В первой части автор Том Шрайбер поясняет, как ClickHouse обходится без традиционного обновления строк, превращая UPDATE/DELETE в вставки с помощью специальных движков вроде ReplacingMergeTree, CollapsingMergeTree и др., которые позднее сливаются фоновым процессом, обеспечивая высокую скорость и масштабируемость на аналитических нагрузках. Это решение позволило объединить эффективность вставок и возможность правки данных без ущерба для быстрого чтения.
Вторая статья рассказывает о новой архитектуре патч‑партиций (patch parts), благодаря которым ClickHouse наконец поддерживает классический синтаксис UPDATE … WHERE, но без затрат на перестройку колонок: патч‑партиции содержат только изменённые значения и сливаются в фоновом режиме, обеспечивая мгновенную видимость изменений и высокую производительность. Автор подробно описывает эволюцию от тяжёлых мутаций до экономных, декларативных обновлений на основе SQL, вдохновлённых механизмами MergeTree.
#ClickHouse
ClickHouse
How we built fast UPDATEs for the ClickHouse column store – Part 1: Purpose-built engines
ClickHouse is a column store, but that doesn’t mean updates are slow. In this post, we explore how purpose-built engines like ReplacingMergeTree deliver fast, efficient UPDATE-like behavior through smart insert semantics.
Forwarded from LLM под капотом
Новые материалы по SGR - Schema-Guided Reasoning
Я собрал воедино и структурировал материалы про SGR для LLM, выделил паттерны (их всего три) в отдельные статьи (english). Получилась краткая методичка "собери сам свою reasoning систему":
- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.
Сейчас я работаю над еще одним дополнением - минимальным примером бизнес-ассистента, который может использовать несколько инструментов для распутывания сложных задачек. Он создается без сторонних библиотек, исключительно на OpenAI SDK, Pydantic и всего с одним промптом.
Как думаете, в сколько строчек Python можно уложить такое демо-решение?
Ваш, @llm_under_hood 🤗
Я собрал воедино и структурировал материалы про SGR для LLM, выделил паттерны (их всего три) в отдельные статьи (english). Получилась краткая методичка "собери сам свою reasoning систему":
- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.
Сейчас я работаю над еще одним дополнением - минимальным примером бизнес-ассистента, который может использовать несколько инструментов для распутывания сложных задачек. Он создается без сторонних библиотек, исключительно на OpenAI SDK, Pydantic и всего с одним промптом.
Как думаете, в сколько строчек Python можно уложить такое демо-решение?
Ваш, @llm_under_hood 🤗
Forwarded from Заскуль питона (Data Science)
A/B-тесты кажутся простыми: разделили аудиторию, сравнили метрики, сделали вывод. Но на практике можно легко допустить ошибку, которая приведёт к неправильным решениям. Собрал полезные статьи с Хабра, которые помогут разобраться в нюансах экспериментов и избежать классических фейлов и узнать что-то новое.
Топ постов от IT-компаний, в которых активно используется 🆎.
Ставьте
@zasql_python
Что-то забыл? Пишите в комментариях!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artem Ryblov’s Data Science Weekly
The Prompt Report: A Systematic Survey of Prompt Engineering Techniques
Generative Artificial Intelligence (GenAI) systems are increasingly being deployed across diverse industries and research domains. Developers and end-users interact with these systems through the use of prompting and prompt engineering.
Although prompt engineering is a widely adopted and extensively researched area, it suffers from conflicting terminology and a fragmented ontological understanding of what constitutes an effective prompt due to its relatively recent emergence.
Authors establish a structured understanding of prompt engineering by assembling a taxonomy of prompting techniques and analyzing their applications. They present a detailed vocabulary of 33 vocabulary terms, a taxonomy of 58 LLM prompting techniques, and 40 techniques for other modalities.
Additionally, authors provide best practices and guidelines for prompt engineering, including advice for prompting state-of-the-art (SOTA) LLMs such as ChatGPT. They further present a meta-analysis of the entire literature on natural language prefix-prompting. As a culmination of these efforts, this paper presents the most comprehensive survey on prompt engineering to date.
Link: ArXiv
Navigational hashtags: #armarticles
General hashtags: #promptengineering #prompts #prompt #llm
@data_science_weekly
Generative Artificial Intelligence (GenAI) systems are increasingly being deployed across diverse industries and research domains. Developers and end-users interact with these systems through the use of prompting and prompt engineering.
Although prompt engineering is a widely adopted and extensively researched area, it suffers from conflicting terminology and a fragmented ontological understanding of what constitutes an effective prompt due to its relatively recent emergence.
Authors establish a structured understanding of prompt engineering by assembling a taxonomy of prompting techniques and analyzing their applications. They present a detailed vocabulary of 33 vocabulary terms, a taxonomy of 58 LLM prompting techniques, and 40 techniques for other modalities.
Additionally, authors provide best practices and guidelines for prompt engineering, including advice for prompting state-of-the-art (SOTA) LLMs such as ChatGPT. They further present a meta-analysis of the entire literature on natural language prefix-prompting. As a culmination of these efforts, this paper presents the most comprehensive survey on prompt engineering to date.
Link: ArXiv
Navigational hashtags: #armarticles
General hashtags: #promptengineering #prompts #prompt #llm
@data_science_weekly
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
Автор: Шамиль Мамедов