#rl

Вот скажите мне - эволюционные методы это же не рл уже?

Неужели мы наблюдаем возрождение эволюционных стратегий как альтернативы RL? Я помню ту работу 2017 года от OpenAI и Суцкевера в частности "Evolution Strategies as a Scalable Alternative to Reinforcement Learning" (https://arxiv.org/abs/1703.03864), где впервые ES показали себя достойной альтернативой RL. Я сам писал про это в начале 2017 года (https://moocaholic.medium.com/2017-the-year-of-neuroevolution-30e59ae8fe18). Но в мир LLM эти подходы так и не пришли, возможно потому что на миллиардах параметров оно сходу не работало. Свежая работа "Evolution Strategies at Scale: LLM Fine-Tuning Beyond Reinforcement Learning" (https://arxiv.org/abs/2509.24372) устраняет этот пробел. Реализация настолько простая, что непонятно, почему это сделали только в 2025-м...

https://t.me/gonzo_ML_podcasts/936

#softskills #books

#ml #dl #gpu #courses

#audio #courses

#llm #petproject

Как я использовал SGR, не подозревая об этом, и почему советую вам

Сколько бы ты ни работал в какой-либо сфере, уследить за всем просто нереально. В AI буквально каждый день появляются новые инструменты и методы работы с моделями, в частности с LLM. И иногда так бывает, что ты самостоятельно приходишь к чему-то, гордишься этим, а оказывается - про это уже написаны статьи. Так случилось и со мной.

Поле применения LLM довольно широкое, но одной из самых частых задач я бы назвал ускорение производства текстового результата: от оптимизации продуктового ресерча с анализом рыночных и пользовательских данных до частичной автоматизации с помощью AI-ассистентов.

Глобально у нас есть несколько стратегий достижения результата:
- можно просто задать задачу LLM, применяя базовый промптинг или продвинутые техники типа CoT;
- можно использовать RAG, чтобы доставать релевантный контекст из базы знаний;
- можно вдохнуть в LLM агентское поведение, добавив инструменты, и аппрувить промежуточные результаты.

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

Снижение температуры модели помогает, но не решает проблему полностью. Работая с комплексными задачами, когда нужно поэтапно извлечь данные, структурировать и принять решения в рамках одного диалога, я нашёл метод, который позволяет “придушить” модель и получать более релевантный, контролируемый результат.

Как это сделать?
Метод прост - в системных промптах я включаю не только описание задачи, но и детальное описание процесса и критериев результата. Потом даю LLM не просто произвольный текст, а чётко типизированный шаблон вывода, например, в формате JSON Schema, где указываю строгое поле для каждого шага.

Далее этот структурированный вывод я использую как вход в следующий шаг в цепочке. То есть вместо свободного CoT я задаю схему рассуждений - последовательность этапов, типы и формат данных, которые модель должна сгенерировать на каждом этапе. Эта схема заставляет модель придерживаться логики и правил, помогает избежать ошибок и галлюцинаций.

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

Это называется SRG
Так я радовался своему “открытию”, пока у Валеры в канале @neuraldeep не наткнулся на аббривеатуру SGR, которая обещала все то же самое 😄 Оказалось, что Schema-Guided Reasoning изобрели еще до меня 😁 Более того, про него еще статейки написали и есть куча холивара на тему того, тру это или не тру 😄 У метода есть сторонники и критики, но на мой взгляд, если нужна предсказуемость, воспроизводимость и контроль над качеством вывода LLM, это лучший подход.

Плюс SGR играет хорошо с RAG и агентскими инструментами: схема помогает управлять, когда и какой контекст доставать, как валидировать промежуточные шаги и принимать решения о следующем действии. Это снижает пропуск важного контекста и улучшает общую надежность.

Если вам надо системно и стабильно получать результат от LLM, рекомендую обратить внимание на SGR. Это не просто продвинутый промптинг - это работа с моделью на уровне структурированных данных и схем рассуждений, что кардинально повышает качество и удобство работы.

Почему 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