Forwarded from БОГДАНИСССИМО
1/2. Как не терять фокус, когда много проектов?
Буду потихоньку нарезать вебинар на посты
Поступил вопрос "как не терять фокус и не распыляться, если много проектов?". У меня на пике было 4 проекта (основная работа, книга, 2 курса). Сейчас у меня проектов, требующих моего внимания тоже больше одного (мы не берём в расчёт консультации). Чтобы за всем успевать, я тогда и сейчас распределяю проекты по дням недели, кажется, это называется Day Theming.
Идея в чём: когда ты Maker, т.е. работаешь руками (разработчик, дизайнер, контент-creator), ты продуктивен, когда у тебя есть большое количество часов (4-6 подряд или больше), во время которых ты можешь заниматься одной задачей, погрузиться в нирвану Deep Work✨. Тебе важно не отвлекаться, иметь один контекст. Тебе клёво видеть в календаре пустой день или половину дня – ты можешь заняться своим делом и сделать его хорошо
Когда ты Manager, ты по-другому смотришь на свой календарь. Тебе ок созваниваться, переключаться между десятью контекстами. Каждые незаполненные полчасика в календаре для тебя впустую потраченное время. Для Maker наоборот, свободные полчаса-час-два – это настолько мало для того, чтобы что-то сделать полезное, что за важные задачи лучше и не браться, максимум, пофиксить баги, почитать статьи
Подробнее про Maker Schedule vs Manager Schedule в знаменитом эссе Пола Грэма, также есть классный видос от Алекса Хормози If You Struggle with Focus, Try My Productivity System с более бизнесовым пересказом Пола Грэма
Я инженер, поэтому мой контрибьюшн – почти всегда через deep work. Мне важно иметь Maker Schedule, когда есть большие куски времени без отвлечений. Если у меня больше одного проекта, которые конкурируют за мое внимание каждый день, каждый час, мне нужно придумать, как предотвратить context switching, переключение контекста
Буду потихоньку нарезать вебинар на посты
Поступил вопрос "как не терять фокус и не распыляться, если много проектов?". У меня на пике было 4 проекта (основная работа, книга, 2 курса). Сейчас у меня проектов, требующих моего внимания тоже больше одного (мы не берём в расчёт консультации). Чтобы за всем успевать, я тогда и сейчас распределяю проекты по дням недели, кажется, это называется Day Theming.
Идея в чём: когда ты Maker, т.е. работаешь руками (разработчик, дизайнер, контент-creator), ты продуктивен, когда у тебя есть большое количество часов (4-6 подряд или больше), во время которых ты можешь заниматься одной задачей, погрузиться в нирвану Deep Work✨. Тебе важно не отвлекаться, иметь один контекст. Тебе клёво видеть в календаре пустой день или половину дня – ты можешь заняться своим делом и сделать его хорошо
Когда ты Manager, ты по-другому смотришь на свой календарь. Тебе ок созваниваться, переключаться между десятью контекстами. Каждые незаполненные полчасика в календаре для тебя впустую потраченное время. Для Maker наоборот, свободные полчаса-час-два – это настолько мало для того, чтобы что-то сделать полезное, что за важные задачи лучше и не браться, максимум, пофиксить баги, почитать статьи
Подробнее про Maker Schedule vs Manager Schedule в знаменитом эссе Пола Грэма, также есть классный видос от Алекса Хормози If You Struggle with Focus, Try My Productivity System с более бизнесовым пересказом Пола Грэма
Я инженер, поэтому мой контрибьюшн – почти всегда через deep work. Мне важно иметь Maker Schedule, когда есть большие куски времени без отвлечений. Если у меня больше одного проекта, которые конкурируют за мое внимание каждый день, каждый час, мне нужно придумать, как предотвратить context switching, переключение контекста
Forwarded from БОГДАНИСССИМО
2/2. Как не терять фокус, когда много проектов?
Решение: оба этих вводных приводят нас к логичной идее выделять целые дни под тот или иной контекст, кажется, это называется Day Theming. Я коммуницирую, мол, такие-то дни недели я занимаюсь таким-то проектом, в остальные дни по этому проекту я недоступен (максимум, могу в конце дня посмотреть, прочитать, отписаться). У меня в календарике прям заведены регулярные Full Day ивенты под каждый. Важно что это эксплицитно проговаривается, чтобы контролировать ожидания всех, с кем работаешь (например, мои последние начальники и кого я консультирую подтвердят, что все созвоны я ставлю на понедельники, чтобы все остальные дни я мог фокусироваться на deep work)
Если, когда я не занят каким-то проектом что-то ломается, случается какой-то пожар – это подождёт как минимум до конца дня, как максимум, несколько дней, пока я не вернусь обратно к этому проекту (чаще всего "пожары", если внимательно на них посмотреть, не такие критичные и срочные, какими кажутся на первый взгляд)
В крайнем случае, если это действительно необходимо, можно бить дни на пополам (4-6 часов первая половина дня на один проект, зал/обед, 4-6 часов половина дня на другой проект) или выделять 1-2 часа в начале или в конце дня на какую-то определённую активность (контент/книга/курс)
P.S. Знаю, такой стратегии придерживается Илон у которого 5+ компаний (SpaceX, Tesla, X, xAI, DOGE, Neurolink). Львиная доля времени у него выделена под SpaceX, Tesla, где пока он ими занимается, он прилетает на завод, погружается в текущие дела, находит главный боттлнек прямо сейчас и в считанные дни его решает (крайне советую посмотреть https://www.youtube.com/watch?v=FQ4wBv0w9ew), после чего он переключается на другие компании и не мешает гениальным инженерам продолжать работу
Решение: оба этих вводных приводят нас к логичной идее выделять целые дни под тот или иной контекст, кажется, это называется Day Theming. Я коммуницирую, мол, такие-то дни недели я занимаюсь таким-то проектом, в остальные дни по этому проекту я недоступен (максимум, могу в конце дня посмотреть, прочитать, отписаться). У меня в календарике прям заведены регулярные Full Day ивенты под каждый. Важно что это эксплицитно проговаривается, чтобы контролировать ожидания всех, с кем работаешь (например, мои последние начальники и кого я консультирую подтвердят, что все созвоны я ставлю на понедельники, чтобы все остальные дни я мог фокусироваться на deep work)
Если, когда я не занят каким-то проектом что-то ломается, случается какой-то пожар – это подождёт как минимум до конца дня, как максимум, несколько дней, пока я не вернусь обратно к этому проекту (чаще всего "пожары", если внимательно на них посмотреть, не такие критичные и срочные, какими кажутся на первый взгляд)
В крайнем случае, если это действительно необходимо, можно бить дни на пополам (4-6 часов первая половина дня на один проект, зал/обед, 4-6 часов половина дня на другой проект) или выделять 1-2 часа в начале или в конце дня на какую-то определённую активность (контент/книга/курс)
P.S. Знаю, такой стратегии придерживается Илон у которого 5+ компаний (SpaceX, Tesla, X, xAI, DOGE, Neurolink). Львиная доля времени у него выделена под SpaceX, Tesla, где пока он ими занимается, он прилетает на завод, погружается в текущие дела, находит главный боттлнек прямо сейчас и в считанные дни его решает (крайне советую посмотреть https://www.youtube.com/watch?v=FQ4wBv0w9ew), после чего он переключается на другие компании и не мешает гениальным инженерам продолжать работу
Forwarded from Tensor Banana
T-one STT (распознавание речи на русском) под виндой (без WSL и докера) на CPU
- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.
Установка под виндой
(для linux или wsl - используйте официальную инструкцию)
По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md
гитхаб: https://github.com/voicekit-team/T-one
HF: https://huggingface.co/t-tech/T-one
- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.
Установка под виндой
(для linux или wsl - используйте официальную инструкцию)
git clone https://github.com/voicekit-team/T-one.git
cd T-one
python -m venv .venv
.venv\Scripts\activate
в файле pyproject.toml удаляем или комментируем (#) строчку 16:
"kenlm (>=0.2.0,<1.0.0)",
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
bootstrap-vcpkg.sh
vcpkg integrate install
vcpkg install kenlm
cd ..
pip install poetry
poetry lock
poetry install -E demo
pip install kenlm
uvicorn --host 127.0.0.1 --port 8081 tone.demo.website:app --reload
открываем 127.0.0.1:8081 в браузере
По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md
гитхаб: https://github.com/voicekit-team/T-one
HF: https://huggingface.co/t-tech/T-one
Forwarded from Start Career in DS
👩💼 Как развить бизнес видение?
Бесспорно, для аналитиков любого грейда крайне важно помимо хард скиллов, также и бизнес видение. Не зря бигтехи проверяют и то, и другое на разных этапах собеса. Поэтому прокачивать его так же нужно, как и нарешивать литкод или задачки по терверу.
Небольшой список общих советов:
👉 Ходите на конференции, где разбираются реальные кейсы: матемаркетинг, aha!, датафест
👉 Читайте каналы по интересующей вас тематике, а еще полезно почитать разные каналы с отчетностями компаний, чтобы понять, на чем они зарабатывают и на какие метрики смотрят, например, @businessincognita и @expertosphere
👉 Читайте книги, которые развивают бизнес-видение, например, The Data Detective и How To Measure Anything. Отдельно рекомендуем "Спроси маму" Роба Фитцпатрика, она научит вас правильно задавать вопросы клиенту и понимать, что реально он хочет, а в чем вообще не заинтересован. Саммари есть на хабре, но админы читали целиком и вам советуют
А теперь подборка, если вам нужно все и сразу за короткий срок перед собесом:
🔎 Школа менеджеров Яндекса: возможность заглянуть в закулисье яндекса, построения продукта и принятия решений в нем
🔎 Платформа growth.design, на которой в формате комиксов разбираются различные продуктовые кейсы мировых топ-компаний. Узнали про нее от Макса из Заскуль Питона, оч советуем подробнее про эту крутую платформу прочитать у него.
🔎 Блог GoPractice – много классных бесплатных статей про продуктовый менеджмент, маркетинг и аналитику. А если понравится, то у них есть и платные симуляторы
🔎 Блоги компаний. Например, Авито, Яндекса, Альфа-банка. Выбирайте статьи, относящиеся к бизнес-части и прокачивайте насмотренность по принятию решений, которые влияют на то, что вы видите в своем смартфоне. Отдельно рекомендуем читать блоки компаний, куда вы планируете собеседоваться в ближайшее время. Проверенно повышает успешность прохождения собеседований, тк вы становитесь не просто аналитиком, а аналитиком, знакомым с целями, вызовами и последними решениями компаний
Ставьте лайки 👍, если было полезно, и давайте добьем каналу следующий уровень, осталось совсем немного!
Бесспорно, для аналитиков любого грейда крайне важно помимо хард скиллов, также и бизнес видение. Не зря бигтехи проверяют и то, и другое на разных этапах собеса. Поэтому прокачивать его так же нужно, как и нарешивать литкод или задачки по терверу.
Небольшой список общих советов:
👉 Ходите на конференции, где разбираются реальные кейсы: матемаркетинг, aha!, датафест
👉 Читайте каналы по интересующей вас тематике, а еще полезно почитать разные каналы с отчетностями компаний, чтобы понять, на чем они зарабатывают и на какие метрики смотрят, например, @businessincognita и @expertosphere
👉 Читайте книги, которые развивают бизнес-видение, например, The Data Detective и How To Measure Anything. Отдельно рекомендуем "Спроси маму" Роба Фитцпатрика, она научит вас правильно задавать вопросы клиенту и понимать, что реально он хочет, а в чем вообще не заинтересован. Саммари есть на хабре, но админы читали целиком и вам советуют
А теперь подборка, если вам нужно все и сразу за короткий срок перед собесом:
🔎 Школа менеджеров Яндекса: возможность заглянуть в закулисье яндекса, построения продукта и принятия решений в нем
🔎 Платформа growth.design, на которой в формате комиксов разбираются различные продуктовые кейсы мировых топ-компаний. Узнали про нее от Макса из Заскуль Питона, оч советуем подробнее про эту крутую платформу прочитать у него.
🔎 Блог GoPractice – много классных бесплатных статей про продуктовый менеджмент, маркетинг и аналитику. А если понравится, то у них есть и платные симуляторы
🔎 Блоги компаний. Например, Авито, Яндекса, Альфа-банка. Выбирайте статьи, относящиеся к бизнес-части и прокачивайте насмотренность по принятию решений, которые влияют на то, что вы видите в своем смартфоне. Отдельно рекомендуем читать блоки компаний, куда вы планируете собеседоваться в ближайшее время. Проверенно повышает успешность прохождения собеседований, тк вы становитесь не просто аналитиком, а аналитиком, знакомым с целями, вызовами и последними решениями компаний
Ставьте лайки 👍, если было полезно, и давайте добьем каналу следующий уровень, осталось совсем немного!
Forwarded from max.sh
Искал статьи / работы рисерчеров, участвовавших в разработке Deep Research и наткнулся на блог одного из ключевых авторов технологии — Джейсона Вэя (Jason Wei). Ссылка на блог. Джейсон является первым автором статьи про Chain of Thought ещё со времён работы в Google Brain (теперь часть Дип Майнда).
В блоге Джейсон интересно пишет свои мысли про рисерч, как его вести, как строить карьерный путь и немного рефлексии на тему своих же научных статей.
Из интересного про RL — Асимметрия верификации. Ссылка
Множество задач требуют значительных усилий для генерации решения, но при этом легко поддаются проверке. Взять судоку или кроссворд. А вот написание эссе на заданную тему — напротив: сгенерировать его для модели несложно, а вот провести факт-чекинг и оценить содержание гораздо труднее. В этом и заключается асимметрия верификации: есть задачи, которые можно быстро и дёшево проверить на корректность (при наличии эталонного ответа), но при этом неясно, как к этому ответу прийти; а есть такие, к которым можно сгенерировать тысячи вариантов, но трудно определить, какие из них действительно правильные.
Тут и начинается самое интересное — поиск способов уменьшения асимметрии. Для большого класса сложных задач это действительно возможно. Например, асимметрию можно значительно снизить для задач по математике и программированию (Картинка к посту). Как? Если для задачи есть эталонное решение или тесты на корректность, то в процессе эволюции, какой бы сложной она ни была, генерация правильного ответа становится задачей RL-оптимизации.
Путём таких рассуждений автор приходит к формулировке условного "закона":
И дальше выделяет пять свойств, которыми должна обладать задача, чтобы быть "легко" решённой LLM:
⚫️ Быстрота верификации — можно за секунды определить, правильно ли решена задача
⚫️ Скейлинг верификации — можно проверять одновременно множество решений
⚫️ Согласованность корректности — все (люди) легко могут придти к консенсусу о том, какое решение хорошее, а какое нет
⚫️ Ранжирование качества решений — можно упорядочить варианты по степени качества
⚫️ Устойчивость к шуму — верификация коррелирует с качеством решения и ложно-положительные срабатывания минимальны
Автор вполне логично считает, что большинство задач, которые можно свести к быстрой верификации, будут решены в ближайшие годы.
Отдельно можно заметить, что большинство популярных бенчмарков как раз обладают всеми свойствами задачи для верификаци (MMLU, SWE bench, GSM8K, тот же Humanity's Last Exam). Потому эти бенчмарки и популярны, и потому в тех аспектах, что они проверяют (код, общие знания, математику) LLM-ы развиваются активнее всего.
В блоге Джейсон интересно пишет свои мысли про рисерч, как его вести, как строить карьерный путь и немного рефлексии на тему своих же научных статей.
Из интересного про RL — Асимметрия верификации. Ссылка
Множество задач требуют значительных усилий для генерации решения, но при этом легко поддаются проверке. Взять судоку или кроссворд. А вот написание эссе на заданную тему — напротив: сгенерировать его для модели несложно, а вот провести факт-чекинг и оценить содержание гораздо труднее. В этом и заключается асимметрия верификации: есть задачи, которые можно быстро и дёшево проверить на корректность (при наличии эталонного ответа), но при этом неясно, как к этому ответу прийти; а есть такие, к которым можно сгенерировать тысячи вариантов, но трудно определить, какие из них действительно правильные.
Тут и начинается самое интересное — поиск способов уменьшения асимметрии. Для большого класса сложных задач это действительно возможно. Например, асимметрию можно значительно снизить для задач по математике и программированию (Картинка к посту). Как? Если для задачи есть эталонное решение или тесты на корректность, то в процессе эволюции, какой бы сложной она ни была, генерация правильного ответа становится задачей RL-оптимизации.
Путём таких рассуждений автор приходит к формулировке условного "закона":
Verifier’s law: The ease of training AI to solve a task is proportional to how verifiable the task is. All tasks that are possible to solve and easy to verify will be solved by AI.
И дальше выделяет пять свойств, которыми должна обладать задача, чтобы быть "легко" решённой LLM:
Автор вполне логично считает, что большинство задач, которые можно свести к быстрой верификации, будут решены в ближайшие годы.
Отдельно можно заметить, что большинство популярных бенчмарков как раз обладают всеми свойствами задачи для верификаци (MMLU, SWE bench, GSM8K, тот же Humanity's Last Exam). Потому эти бенчмарки и популярны, и потому в тех аспектах, что они проверяют (код, общие знания, математику) LLM-ы развиваются активнее всего.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from эйай ньюз
GLM 4.5 — китайский опенсорс продолжает доминировать
Очередная очень сильная открытая MoE модель от китайцев, с очень хорошими результатами на бенчах. Гибридний ризонер, с упором на тулюз. Доступна по MIT лицензии, 128к контекста, нативный function calling, из коробки работают стриминг и batching, есть FP8‑инференс и совместимость с vLLM/SGLang.
Как и Kimi K2 модельку тренировали с Muon, но в отличие от Kimi авторы использовали QK норму вместо клиппинга — Kimi такой трюк не позволило провернуть использование MLA, из-за чего им пришлось придумывать свою версию оптимайзера. Для спекулятивного декодинга получше модельку тренировали с MTP. Она заметно глубже чем другие открытые китайские MoE — это повышает перформанс, за счёт роста размера KV-кэша. Вместе с этим они используют заметно больше attention heads. Это хоть и не помогает лоссу, но заметно улучшает ризонинг бенчмарки.
Модель идёт в двух размерах — 355B (32B active) и 106B (12B active). Претрейн был на 22 триллионах токенов — 15 триллионов токенов обычных данных, а после них 7 триллионов кода с ризонингом. На мидтрейне в модель запихнули по 500 миллиардов токенов кода и ризонинг данных с контекстом расширенным до 32к, а после этого 100 миллиардов long context и агентных данных при контексте уже в 128к.
Посттрейн двухэтапный — сначала из базовой модели через cold‑start+RL тренируют три эксперта (reasoning модель, agentic модель, и для общих тасков) и сводят их знания в одну модель через self‑distillation. Затем идёт объединённое обучение: общий SFT → Reasoning RL → Agentic RL → General RL.
Для ризонинга применяют одноступенчатый RL на полном 64K‑контексте с curriculum по сложности, динамическими температурами и адаптивным клиппингом. Агентные навыки тренируют на верифицируемых треках — поиск информации и программирование с обратной связью по исполнению. Полученные улучшения помогают и deep search и общему tool‑use. Кстати, их посттрейн фреймворк открытый и лежит на гитхабе.
Веса
Демо
Блогпост
Посттрейн фреймворк
@ai_newz
Очередная очень сильная открытая MoE модель от китайцев, с очень хорошими результатами на бенчах. Гибридний ризонер, с упором на тулюз. Доступна по MIT лицензии, 128к контекста, нативный function calling, из коробки работают стриминг и batching, есть FP8‑инференс и совместимость с vLLM/SGLang.
Как и Kimi K2 модельку тренировали с Muon, но в отличие от Kimi авторы использовали QK норму вместо клиппинга — Kimi такой трюк не позволило провернуть использование MLA, из-за чего им пришлось придумывать свою версию оптимайзера. Для спекулятивного декодинга получше модельку тренировали с MTP. Она заметно глубже чем другие открытые китайские MoE — это повышает перформанс, за счёт роста размера KV-кэша. Вместе с этим они используют заметно больше attention heads. Это хоть и не помогает лоссу, но заметно улучшает ризонинг бенчмарки.
Модель идёт в двух размерах — 355B (32B active) и 106B (12B active). Претрейн был на 22 триллионах токенов — 15 триллионов токенов обычных данных, а после них 7 триллионов кода с ризонингом. На мидтрейне в модель запихнули по 500 миллиардов токенов кода и ризонинг данных с контекстом расширенным до 32к, а после этого 100 миллиардов long context и агентных данных при контексте уже в 128к.
Посттрейн двухэтапный — сначала из базовой модели через cold‑start+RL тренируют три эксперта (reasoning модель, agentic модель, и для общих тасков) и сводят их знания в одну модель через self‑distillation. Затем идёт объединённое обучение: общий SFT → Reasoning RL → Agentic RL → General RL.
Для ризонинга применяют одноступенчатый RL на полном 64K‑контексте с curriculum по сложности, динамическими температурами и адаптивным клиппингом. Агентные навыки тренируют на верифицируемых треках — поиск информации и программирование с обратной связью по исполнению. Полученные улучшения помогают и deep search и общему tool‑use. Кстати, их посттрейн фреймворк открытый и лежит на гитхабе.
Веса
Демо
Блогпост
Посттрейн фреймворк
@ai_newz
Forwarded from Заскуль питона (Аналитика данных)
Раньше в
Сейчас для моих задач Spark - это необходимость, чтобы не падал JupyterHub по оперативной памяти: все вычисления выполняются распределённо на кластере с большим объёмом ресурсов. Но это не волшебная таблетка, т.к. важно следить за тем, как используются ресурсы, грамотно настраивать Spark-приложения и оптимизировать запросы. На самом деле подход к работе с ресурсами здесь другой, и есть ряд ограничений, о которых расскажу в следующих постах
1. Собираю данные из разных источников
В реальных задачах часто нужно объединять сразу несколько источников: выгрузки из разных баз, parquet и тд. Пока всё влезает в pandas - норм, но когда данных слишком много, pandas начинает падать. Spark позволяет легко подтянуть все необходимые источники и собрать их в одну большую таблицу, не заботясь об ограничениях памяти.
2. Выполняю тяжёлые вычисления и агрегации
После того как все данные собраны, начинаются подсчеты метрик по большим объёмам данных. Здесь Spark выигрывает за счёт распределённых вычислений: вся тяжёлая работа идёт на кластере, а не на ноутбуке. Как только нужные агрегаты посчитаны, можно забрать результат и уже дальше анализировать, строить графики и т.д.
from pyspark.sql import SparkSession
from pyspark.sql.functions import avg, count
# запускаем Spark-сессию, тут еще можно закопаться в настройки приложения (если будет много 🐳, выложу)
spark = SparkSession.builder.appName("zasql_python").getOrCreate() # название приложения может быть произвольным
# читаем csv и кучу источников
df_csv = spark.read.csv("file.csv", header=True, inferSchema=True)
df_parquet = spark.read.parquet("file.parquet")
df_json = spark.read.json("file.json")
# джойним таблицы между собой
df_joined = df_csv.join(df_parquet, on="user_id", how="inner")
# фильтруем данные
df_filtered = df_joined.filter(df_joined["is_active"] == 1)
# применяем агрегирующие функции, считаем сумму строчек, среднее значение по заказам
df_grouped = (
df_filtered
.groupBy("country")
.agg(
count("*").alias("users_count"),
avg("order_sum").alias("avg_order_sum")
)
)
df_pandas = df_grouped.toPandas()
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("zasql_python_sql").getOrCreate() # произвольное название приложения, должно быть другим, если запускаем параллельно
df_orders = spark.read.parquet("orders.parquet") # читаем в Spark DataFrame первый источник источник
df_users = spark.read.csv("users.csv", header=True, inferSchema=True) # читаем в Spark DataFrame второй источник
df_orders.createOrReplaceTempView("orders") # создаем темповые таблицы заказов
df_users.createOrReplaceTempView("users") # создаем темповые таблицы юзеров
# теперь читаем тут в sql-формате
query = """
SELECT
u.country,
COUNT(DISTINCT o.user_id) AS active_users,
AVG(o.order_sum) AS avg_order_sum
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.is_active = 1
GROUP BY u.country
ORDER BY avg_order_sum DESC
"""
result = spark.sql(query) # читаем в spark.sql, результат тот же получаем, но в SQL-формате
result.show() # показать значения, но можно перевести и в pandas, но ресурсов много сожрет
Spark спасает, когда надо соединить и обработать десятки миллионов строк из разных источников, и обычный pandas падает по памяти, ядро умирает.
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Б/У ml (Толик Мастрюков)
Ускорение раннего связывания для моделей ранжирования
База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.
На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.
На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.
Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.
В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.
Авторы берут за основу две модели с ранним связыванием (early interaction):
BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.
TransAct — кандидат конкатенируется к каждому айтему в истории.
Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.
Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:
n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.
При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.
Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.
Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)
Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).
Результаты
+0.18% к качеству (A/B-тесты).
+5% к latency (vs. +56% у BST и +52% у TransAct).
Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).
Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.
На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.
На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.
Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.
В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.
Авторы берут за основу две модели с ранним связыванием (early interaction):
BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.
TransAct — кандидат конкатенируется к каждому айтему в истории.
Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.
Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:
n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.
При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.
Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.
Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)
Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).
Результаты
+0.18% к качеству (A/B-тесты).
+5% к latency (vs. +56% у BST и +52% у TransAct).
Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).
Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
Forwarded from Б/У ml (Толик Мастрюков)
Слева BST , справа идея из статьи. Наглядное сравнение почему 1 метод быстрее другого