Почему Polars blazingly-fast: дело не только в Rust

Когда данных много, pandas часто упирается в память и «однопоточность» Python, а множественные агрегации могут выполняться в течение часов или даже дней. Какие же существуют альтернативы? Давайте разберёмся, как устроен Polars и какие архитектурные решения делают его blazingly-fast.

Как оно работает

📌 Колоночный движок на Rust + Arrow-модель памяти
Polars использует модель памяти Apache Arrow для хранения данных в колоночных буферах — плотных, типизированных массивах без Python-объектов. Что важно: формат адаптирован под высокие кэш-хит-рейты и быстрое выполнение SIMD-инструкций. Ядро на Rust исполняется вне интерпретатора Python и не упирается в GIL, что позволяет эффективнее утилизировать CPU и распараллеливать вычисления.

📌 Lazy-режим и оптимизатор
Вы описываете всю трансформацию целиком, а движок сам решает порядок шагов: «проталкивает» фильтры к источнику, отбрасывает лишние столбцы ещё на чтении. По сути Python — это интерфейс, который помогает собрать программу на внутреннем оптимизированном DSL Polars. В итоге это сокращает I/O и использование памяти.

📌 Логический → физический план: как Polars оптимизирует запрос
Когда вы описываете запрос с использованием lazy frame и lazy computations, Polars строит логическое дерево и заранее проверяет типы/схему. Затем оптимизатор уплотняет работу: проталкивает select/filter к источнику, выкидывает лишнее, объединяет выражения. После этого выбираются конкретные алгоритмы и распараллеливание (какой join, как считать group_by), формируется физический план. На исполнении читаются только нужные столбцы и куски данных, при необходимости — потоково; в конце всё собирается одним collect(). Для диагностики полезно смотреть план через lf.explain() (при необходимости — с учётом движка) и включать POLARS_VERBOSE=1, чтобы видеть, как выглядит итоговое оптимизированное дерево.

Ключевые внутренние паттерны

📝 Predicate / projection / slice pushdown
Фильтры, выбор столбцов и срезы применяются максимально близко к моменту чтения (scan_parquet/scan_csv). Проще говоря, читаем ровно то, что нужно, а не «всё подряд». Это резко ускоряет последующие join и group_by и снижает нагрузку на память.

📝 Параллельные join и group_by
Polars разбивает данные на части и обрабатывает их на нескольких ядрах, используя быстрые хэш-джоины и продуманные стратегии агрегации. Ускорение особенно заметно на широких таблицах и конвейерах с множественными агрегациями. Конкретный тип join и форма пайплайна могут влиять на распараллеливание и потребление памяти — это видно в плане.

📝 Streaming / out-of-core
Длинные пайплайны можно исполнять «потоково»: данные обрабатываются батчами, не накапливаясь целиком в памяти — это уменьшает пики памяти и стабилизирует задержки. Включается это явно: lf.collect(engine="streaming"). Важно: не все операции поддержаны в стриминге; где это невозможно, движок прозрачно перейдёт к in-memory выполнению (это нормально, но стоит контролировать план).

📝 SQL поверх выражений
Нужен знакомый синтаксис — регистрируете фреймы и используйте SQL; внутри всё равно сработает оптимизатор выражений. Это возможно благодаря SQLContext/pl.sql, что удобно для смешанных команд (аналитики + инженеры).

Анти-паттерны «под капотом»

📎 Построчные apply/map_rows на Python
Любая функция, которая ходит по строкам в Python, возвращает вас к GIL и убирает параллелизм. Если нужна UDF — старайтесь выразить логику через выражения Polars или переносить вычисления ближе к движку.

📎 Постоянное использование read_* вместо scan_*
read_* сразу загружает всё в память и ограничивает оптимизатор в pushdown-приёмах. Для конвейеров и больших наборов данных предпочитайте scan_* с lazy-планом — это откроет путь для predicate/projection/slice pushdown и стриминга. Для быстрых «снимков» и интерактивной разведки read_* допустим, но указывайте columns=[...] и другие параметры чтения, чтобы не тянуть лишнее.

📎 dtype=object/pl.Object
Polars умеет хранить Python-объекты в специальных столбцах, но это вырывает данные из arrow колоночной модели и выключает многие векторные оптимизации. Используйте только при крайней необходимости и как можно раньше приводите к нативным типам Polars.

Скорость Polars — не «магия», а архитектура
Arrow-модель памяти, lazy-планирование с агрессивными оптимизациями, потоковое исполнение там, где это возможно, и ядро на Rust, обходящее GIL. Практический эффект зависит от формулировки запроса и формата данных — корректный выбор scan_*, выражений и режима исполнения часто даёт многократный выигрыш.

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

💜 Этот пост написал Всеволод Богодист, Data Scientist в Точка Банк.

#llm #petproject

Сегодня выступил на ИТМ с докладом про практики проектирования и разработки LLM-систем в медицине, а при подготовке доклада, естественно, использовал LLM. Рассказываю об этом, а также о других прикольных кейсах использования элэлэмок в работе в своём новом посте.

Ещё у моих друзей из издательства Питер вышло несколько новых книг об ML на бумаге, одну из них (Строим LLM с нуля) я читал на английском, вроде, даже в канале упоминал. У Рашки (хехе) всегда хорошие материалы, сейчас жду его Build a Reasoning Model (From Scratch). Если любите книги на бумаге или на русском - велком!

Обращаю ваше внимание, что как всегда рекомендую только бесплатно и только хорошие вещи) Теперь есть ещё одна веская причина не брать платную рекламу, если вы понимаете, о чём я.

#Жека #llm

Иногда древние технологии изумляют не хуже суперсовременных. Изумляют, например, изяществом. Про многотонных каменных идолов с острова Пасхи давно было известно, что жившие 800 лет назад (а культурно - в каменном веке) их создатели умудрялись как-то их перемещать на достаточно большие расстояния. И, на первый (и многие последующие) взгляд задачка казалась неразрешимой. Отсюда гипотезы про чудеса, пришельцев и тому подобное. Легенды, изустно передававшиеся веками из поколения в поколение, гласили, что статуи ходили сами — но как может ходить 90-тонный кусок камня?? Оказалось, легенды были достаточно точны. Пусть не сами, а с некоторой человечьей помощью статуи действительно «ходили» — внешне оно именно так и выглядело.
Археологи сначала погоняли компьютерные модели, а потом поставили и натурный эксперимент (со статуей полегче, весом в 4,35 т., а не в десятки). Оказалось, что правильно раскачивая истукана с помощью веревок, 18 человек за 40 минут переместили его на 100 метров. Посмотрите на видео, как камень «идет», переваливаясь, по специально подготовленной грунтовой дороге :)) Бодренько идет. Вот уж действительно пример экспериментальной истории.
https://arstechnica.com/science/2025/10/how-easter-islands-giant-statues-walked-to-their-final-platforms/

#llm #petproject

#dl #audio

Дошли руки прочитать пост про LoRA от Thinking Machines и Джона Шульмана (co-founder OpenAI; у него в личном блоге тоже есть интересные заметки, например, зашла такая: An Opinionated Guide to ML Research).

Главный посыл в том, что LoRA вполне может тягаться по качеству с фулл-файнтюном под новую задачу, если обучать адаптеры правильно:

*датасет для целевой задачи имеет small-to-medium размер;
*у адаптера достаточно ёмкости, и LoRA применяется не только к attention-матрицам, но и к MLP- и MoE-компонентам (в литературе же все еще популярен первый вариант);
*гиперпараметры подобраны корректно, в частности, большой batch size негативно влияет на сходимость;
*RL-тюнинг с LoRA-адаптерами работает так же хорошо, как и фулл-файнтюн.

В 2024 году, когда я ещё работал в Амазоне, мы обучали мультимодальные LLM, которые умели работать с текстом, изображениями и речью. Отдельно стояла задача поэкспериментировать: можно ли адаптировать модель под ситуации, где требуется эффективный файнтюн, чтобы заскейлить модальность. В качестве тестовой выбрали задачу Voice Cloning: есть N минут речи спикера (N варьируется от минут до часов), и хочется научиться клонировать его голос (тембр, интонацию, акцент, просодию). Задача идеальная: есть потенциальная выгода для бизнеса здесь и сейчас( например, озвучивание аудиокниг), а файнтюнить веса базовой модели каждый раз под новый голос — совсем не вариант. Поэтому всем было интересно посмотреть, что получится.

По большому счёту, мы прошли тот же путь экспериментов, что и команда Шульмана: перебирали гиперпараметры обучения, ранги, слои, в которых вставлять адаптеры, и веса, к которым их применять. Выводы сильно коррелировали: большой batch оказывает вредное влияние, а адаптеры нужно применять в первую очередь к FC-слоям трансформера. В итоге получили адаптируемый рецепт под разное количество обучающих данных.

Качество voice cloning оказалось достаточным для прода: реплики были в разы стабильнее, чем zero-shot voice cloning, и не уступали фулл-тюну (бэйзлайн), оставаясь при этом легко масштабируемыми, по крайней мере, с точки зрения ресерча. С точки зрения продакшена же адаптеры не достаются бесплатно (есть эффект на latency, плюс интеграция десятков тысяч адаптеров отдельная инфраструктурная задача). Но это уже другая история.

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

Также должна была выйти статья, чтобы зафиксировать эффективность метода LoRA для задачи voice cloning. Увы, вот она уже она утонула в потоке бюрократии и более глобальных перестановок в компании.

#dl #nlp #courses

А в курсе глубокого обучения в прошлый четверг обсуждали механизмы внимания:

СПбГУ — 2025.10.02 — Состязательные примеры и механизмы внимания
(слайды и доска на странице курса)

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

А потом перешли к понятию внимания; это очень интересная штука и с точки зрения нейробиологии (хотя там я мало что понимаю), и, как выясняется, с точки зрения искусственных нейросетей. Начали с первых работ о внимании (Larochelle, Hinton, 2010, например), потом обсудили рекуррентные модели внимания и где там возникает RL, а потом перешли к уже более современным архитектурам: encoder-decoder with attention вроде Show, Attend, and Tell.

В этот раз до self-attention не дошли, но на следующей лекции отступать будет уже некуда, будем о трансформерах говорить.)

#dl #nlp #courses

Прошедшую в четверг лекцию курса "Глубокое обучение" долго представлять не надо:

СПбГУ — 2025.10.09 — Self-attention и архитектура трансформера
(слайды и доска на странице курса)

Трансформер — буквально самая главная архитектура нейросетей практически с самого своего появления в 2017 году. В Google Scholar у статьи "Attention is All You Need" уже почти двести тысяч цитирований; это не абсолютный рекорд (есть статьи с сотнями тысяч цитирований про стандартные экспериментальные методы, которые везде потом применялись), но наверняка рекорд за прошедшие неполные восемь лет, и влияние трансформеров в 2025 пока не ослабевает.

В лекции я постарался максимально подробно и не торопясь обсудить всё, что можно было обсудить о самовнимании и архитектуре трансформера: от абстрактно-мотивационной идеи self-attention, приходящей из информационного поиска, до токенизации и позиционных вложений. Многое из того, что будет дальше, — это применения и развития идей этой лекции, так что пропускать её стоит только если вы и так уже всё это хорошо знаете.