Forwarded from gonzo-обзоры ML статей
Если не видели, тут очередной курс по трансформерам выкладывают.
CME 295 - Transformers & Large Language Models
This course explores the world of Transformers and Large Language Models (LLMs). You'll learn the evolution of NLP methods, the core components of the Transformer architecture, along with how they relate to LLMs as well as techniques to enhance model performance for real-world applications. Through a mix of theory and practical insights, this course will equip you with the knowledge to leverage LLMs effectively. Ideal for those with a background in calculus, linear algebra, and basic machine learning concepts.
https://cme295.stanford.edu/syllabus/
CME 295 - Transformers & Large Language Models
This course explores the world of Transformers and Large Language Models (LLMs). You'll learn the evolution of NLP methods, the core components of the Transformer architecture, along with how they relate to LLMs as well as techniques to enhance model performance for real-world applications. Through a mix of theory and practical insights, this course will equip you with the knowledge to leverage LLMs effectively. Ideal for those with a background in calculus, linear algebra, and basic machine learning concepts.
https://cme295.stanford.edu/syllabus/
cme295.stanford.edu
Syllabus | CME 295 - Transformers & Large Language Models
Here, you will find slides and recordings of class lectures, along with suggested readings.
Forwarded from Дата канальи — про «специалистов» в данных / ML / AI
#полезного_пост
Выше у меня полыхало на нравоучения с претензией на великость от молодых да успешных и приводил кейс куда это может привести.
Честно будет сказать на кого я ориентируюсь, благо их книги за давностью лет в открытом доступе (хотя мудачки-издатели и здесь пытаются навариться, но я дам ссылки на легальные бесплатные версии).
Если вам статья про обезьянку 1974 года показалась старой, то сейчас будет сеанс археологии.
Хотя обезьянку я использую ровно каждый день - и очень вам советую перечитать в 101й раз, лишним не будет.
Итак
Чарльз Шваб — от клерка-чертежника до главы нескольких стальных компаний
И его книга «Как преуспеть с тем что есть» (1917)
Эндрю Карнеги — от ребенка-рабочего до стального магната (пусть прекрасные зумеры расскажут про риски человеку который ребенком прыгал в ткацкие станки 19 века менять шпуни)
И сборник его эссе "The Gospel of Wealth" 1889
Книжки столетней давности не применить? Ок, подержите мое пиво.
Помните затасканный сюжет (он кстати из книги Шваба выше):
А стоит помнить.
Итак, 20е числа апреля 2015го года. У меня горит проект, а впереди майские праздники — у сотрудников дачи, шашлыки, пьянки. Да и ребята все молодые, активные — шансов кого-то толкового уболтать проработать все праздники даже за деньги нет никаких. Да и качество той работы будет ну сами понимаете.
Иду к шефу с калькуляцией сколько выйдет команда из 3-4 человек на все майские (а праздничные дни по двойной таксе). Оклады у ребят были в районе 100ки чистыми — вот и представьте что четверо на 2 недели вышли бы примерно 4 (чел) * 2 (двойная оплата) * 50_000 (пол-мес) = 400 тыс. рублей — поэтому не встречаю в нем сочуствия от слова «совсем». Быть уволенным за сорванный проект совсем не хочется.
Прошу хотя бы сотню, но налом, и говорю что все будет. Пишу рыбу и прошу шефа закинуть на всех в cлак. Догадались что в рыбе?
Естественно, соревнование с призовым фондом в 100к.
К концу майских у меня было штуки 2 крутых оформленных рабочих решения и несколько попроще за бюджет вчетверо меньше чем решение в лоб (так и еще и уговаривать никого не пришлось). Почему так вышло? Ведь победитель получил ровно столько же сколько получил бы согласившись поработать на праздниках -- только работы сильно больше вышло бы. А ответ есть в цитате из Шваба выше.
А еще один мой кейс по запуску соревнования думаю вам хорошо известен — MTS ML Cup 2023. На понятном языке задачу и бейзлайн описал на хабре.
За фонд в 650 тыс боролись 2311 участников с 6336 решениями — сравните с крупными банками у которых призовой фонд в 10 раз больше а участников в 10 раз меньше.
stay tuned ⚡️
Выше у меня полыхало на нравоучения с претензией на великость от молодых да успешных и приводил кейс куда это может привести.
Честно будет сказать на кого я ориентируюсь, благо их книги за давностью лет в открытом доступе (хотя мудачки-издатели и здесь пытаются навариться, но я дам ссылки на легальные бесплатные версии).
Если вам статья про обезьянку 1974 года показалась старой, то сейчас будет сеанс археологии.
Хотя обезьянку я использую ровно каждый день - и очень вам советую перечитать в 101й раз, лишним не будет.
Итак
Чарльз Шваб — от клерка-чертежника до главы нескольких стальных компаний
И его книга «Как преуспеть с тем что есть» (1917)
Эндрю Карнеги — от ребенка-рабочего до стального магната (пусть прекрасные зумеры расскажут про риски человеку который ребенком прыгал в ткацкие станки 19 века менять шпуни)
И сборник его эссе "The Gospel of Wealth" 1889
Книжки столетней давности не применить? Ок, подержите мое пиво.
Помните затасканный сюжет (он кстати из книги Шваба выше):
I had a mill manager who was finely educated, thoroughly capable and master of every detail of the business. But he seemed unable to inspire his men to do their best.
“How is it that a man as able as you,” I asked him one day, “cannot make this mill turn out what it should?”
“I don’t know,” he replied. “I have coaxed the men; I have pushed them, I have sworn at them. I have done everything in my power. Yet they will not produce.”
It was near the end of the day; in a few minutes the night force would come on duty. I turned to a workman who was standing beside one of the red-mouthed furnaces and asked him for a piece of chalk.
“How many heats has your shift made today?” I queried.
“Six,” he replied.
I chalked a big “6” on the floor, and then passed along without another word. When the night shift came in they saw the “6” and asked about it.
“The big boss was in here today,” said the day men. “He asked us how many heats we had made, and we told him six. He chalked it down.”
The next morning I passed through the same mill. I saw that the “6” had been rubbed out and a big “7” written instead. The night shift had announced itself. That night I went back. The “7” had been erased, and a “10” swaggered in its place. The day force recognized no superiors. Thus a fine competition was started, and it went on until this mill, formerly the poorest producer, was turning out more than any other mill in the plant.
А стоит помнить.
Итак, 20е числа апреля 2015го года. У меня горит проект, а впереди майские праздники — у сотрудников дачи, шашлыки, пьянки. Да и ребята все молодые, активные — шансов кого-то толкового уболтать проработать все праздники даже за деньги нет никаких. Да и качество той работы будет ну сами понимаете.
Иду к шефу с калькуляцией сколько выйдет команда из 3-4 человек на все майские (а праздничные дни по двойной таксе). Оклады у ребят были в районе 100ки чистыми — вот и представьте что четверо на 2 недели вышли бы примерно 4 (чел) * 2 (двойная оплата) * 50_000 (пол-мес) = 400 тыс. рублей — поэтому не встречаю в нем сочуствия от слова «совсем». Быть уволенным за сорванный проект совсем не хочется.
Прошу хотя бы сотню, но налом, и говорю что все будет. Пишу рыбу и прошу шефа закинуть на всех в cлак. Догадались что в рыбе?
К концу майских у меня было штуки 2 крутых оформленных рабочих решения и несколько попроще за бюджет вчетверо меньше чем решение в лоб (так и еще и уговаривать никого не пришлось). Почему так вышло? Ведь победитель получил ровно столько же сколько получил бы согласившись поработать на праздниках -- только работы сильно больше вышло бы. А ответ есть в цитате из Шваба выше.
А еще один мой кейс по запуску соревнования думаю вам хорошо известен — MTS ML Cup 2023. На понятном языке задачу и бейзлайн описал на хабре.
За фонд в 650 тыс боролись 2311 участников с 6336 решениями — сравните с крупными банками у которых призовой фонд в 10 раз больше а участников в 10 раз меньше.
stay tuned ⚡️
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Bar is sooooooooo high
Сегодня приношу вам социально-айтишный хоррор про то, как человек отработал в Amazon Web Services 3 года и уволился, устав бежать изо всех сил в этом колесе https://nekrolm.github.io/blog.html.
Для себя я отметил несколько моментов:
- Традиционная любовь корпораций евангелизировать свои «принципы», «свойства», «ценности» и прочие желаемые в работниках качества. Да, я понимаю, что на масштабе многих тысяч людей нужна какая-то общая линейка и общее направление, куда идти синхронно в ногу. Но чем старше и опытнее я становлюсь (совсем скоро счетчик снова тикнет), тем лучше умею отличать в этом всём пользу от манипуляции 🙂
- Стрессовый кашель. Страшно, если вдуматься, как стресс перекручивает человеческий организм, и каков должен быть его уровень, и сколько он должен был копиться. У меня есть пара знакомых, которые с подобным тоже столкнулись.
- Любовь к прожарке, баррейзингу и влияние этого на моральное состояние человека. Опять же, да, я понимаю, что в бигтехе очень дорога цена ошибки, плюс взгляд со стороны и критика помогают отточить решение. Просто надо понять, что это, как и всегда, некоторый трейдофф, где есть толика пользы и толика страдания.
- Релизы по году-полтора. Менеджеры уже давно привыкли к долгому циклу обратной связи от своей работы, но вот для инженеров это бедовая цифра, на мой взгляд.
- Ну и конечно же ежедневный опрос о том, как ты энергичен, жизнерадостен и насколько быстро работаешь – это прям лучший инструмент, чтобы понять, что происходит с людьми. Особенно на фоне регулярных рассказов о том, как планируется делать сокращения.
Там, наверное, по опросам шкалит уровень энергии и трудолюбия.
Всё как в анекдоте:
- Специалисты говорят, что люди стали жить лучше.
- А люди утверждают, что ничего не ощущают.
- Но ведь они же не специалисты.
Фан-факт: я заготовил этот пост ещё в воскресенье, а в понедельник AWS конкретно так прилёг. Вчера было много мемов про сокращение SRE и разработчиков в Амазоне, мол, у нас тут ИИ много чего теперь делает.
А я вот видите, как всегда, со стороны людей захожу🙂
Сегодня приношу вам социально-айтишный хоррор про то, как человек отработал в Amazon Web Services 3 года и уволился, устав бежать изо всех сил в этом колесе https://nekrolm.github.io/blog.html.
Для себя я отметил несколько моментов:
- Традиционная любовь корпораций евангелизировать свои «принципы», «свойства», «ценности» и прочие желаемые в работниках качества. Да, я понимаю, что на масштабе многих тысяч людей нужна какая-то общая линейка и общее направление, куда идти синхронно в ногу. Но чем старше и опытнее я становлюсь (совсем скоро счетчик снова тикнет), тем лучше умею отличать в этом всём пользу от манипуляции 🙂
- Стрессовый кашель. Страшно, если вдуматься, как стресс перекручивает человеческий организм, и каков должен быть его уровень, и сколько он должен был копиться. У меня есть пара знакомых, которые с подобным тоже столкнулись.
- Любовь к прожарке, баррейзингу и влияние этого на моральное состояние человека. Опять же, да, я понимаю, что в бигтехе очень дорога цена ошибки, плюс взгляд со стороны и критика помогают отточить решение. Просто надо понять, что это, как и всегда, некоторый трейдофф, где есть толика пользы и толика страдания.
- Релизы по году-полтора. Менеджеры уже давно привыкли к долгому циклу обратной связи от своей работы, но вот для инженеров это бедовая цифра, на мой взгляд.
- Ну и конечно же ежедневный опрос о том, как ты энергичен, жизнерадостен и насколько быстро работаешь – это прям лучший инструмент, чтобы понять, что происходит с людьми. Особенно на фоне регулярных рассказов о том, как планируется делать сокращения.
Там, наверное, по опросам шкалит уровень энергии и трудолюбия.
Всё как в анекдоте:
- Специалисты говорят, что люди стали жить лучше.
- А люди утверждают, что ничего не ощущают.
- Но ведь они же не специалисты.
Фан-факт: я заготовил этот пост ещё в воскресенье, а в понедельник AWS конкретно так прилёг. Вчера было много мемов про сокращение SRE и разработчиков в Амазоне, мол, у нас тут ИИ много чего теперь делает.
А я вот видите, как всегда, со стороны людей захожу🙂
Forwarded from Dealer.AI
Мама любит Mamba и Сережа тоже (с) Тихий "релиз" Mamba3 на ICLR2026.
Если хотите понять, про что Mamba и все эти RWKV, какие модели уже были и оценить перспективу – читайте тут, тут и тут.
Утечка тут, чирикают тут. Хвалебные отзывы по каналам смотреть не тут.💳
Мое мнение такое, уже несколько лет мы видим развитие SSM, RWKV моделей. Основной пойнт - это линейность от размера входного сиквенса, в отличии от механизмов внимания в трансформерах. При этом, мы наследуем и проблемы, аля затухание или взрыв градиента, что влияет на механизм "памяти" внутри архитектуры. Отсюда мы и получаем пляски с разными микстами rnn+transformer в виде указанных выше моделей семейств ssm, rwkv.
Причем можно проследить несколько направлений:
1. Работа с механизмом внутренней "памяти" в лице специальных блоков внутри архитектуры.
2. Работа с сложностью от длины контекста. Микстят блоки ssm с блоками трансформера, где-то последовательно, где-то параллельно.
3. Оптимизация работы всей этой доброты на GPU. Т.к. в отличии от RNN-like, трансформеры параллеляться хорошо.
Кстати знаю, что в бигтехах стажерам дают RWKV делать для тюна автокомплит и пр. Штуки для умной клавы, вместо lstm, разумеется. И это работает on-device хорошо, как и сказано в Mamba3 в качестве перспективы.
4. Работа над стабильностью самой архитектуры, чтобы исключить проблемы RNN. Все эти плавности/насыщения весов и сходимость оттуда же.
В итоге, задается вопрос: А за что мы платим линейной сложностью от длины контекста и памятью в рамках него же, и стабильностью архитектуры?
Также мы уже видели публично аналоги от Qwen3 next, от ребят из Nvidia и пр., стало ли это смертью трансформера? Поживем, увидим, пока все еще не становилось. Но динамика развития архитектур данного семейства хорошая, может даже кому-то лучше заложиться на знание и представление о таких архитектурах. А каким-то rnd командам и на собственные исследования и разработки, чтобы потом внезапно не оказаться в догоняющих .
Всем добра, увидимся.👍
Если хотите понять, про что Mamba и все эти RWKV, какие модели уже были и оценить перспективу – читайте тут, тут и тут.
Утечка тут, чирикают тут. Хвалебные отзывы по каналам смотреть не тут.
Мое мнение такое, уже несколько лет мы видим развитие SSM, RWKV моделей. Основной пойнт - это линейность от размера входного сиквенса, в отличии от механизмов внимания в трансформерах. При этом, мы наследуем и проблемы, аля затухание или взрыв градиента, что влияет на механизм "памяти" внутри архитектуры. Отсюда мы и получаем пляски с разными микстами rnn+transformer в виде указанных выше моделей семейств ssm, rwkv.
Причем можно проследить несколько направлений:
1. Работа с механизмом внутренней "памяти" в лице специальных блоков внутри архитектуры.
2. Работа с сложностью от длины контекста. Микстят блоки ssm с блоками трансформера, где-то последовательно, где-то параллельно.
3. Оптимизация работы всей этой доброты на GPU. Т.к. в отличии от RNN-like, трансформеры параллеляться хорошо.
Кстати знаю, что в бигтехах стажерам дают RWKV делать для тюна автокомплит и пр. Штуки для умной клавы, вместо lstm, разумеется. И это работает on-device хорошо, как и сказано в Mamba3 в качестве перспективы.
4. Работа над стабильностью самой архитектуры, чтобы исключить проблемы RNN. Все эти плавности/насыщения весов и сходимость оттуда же.
В итоге, задается вопрос: А за что мы платим линейной сложностью от длины контекста и памятью в рамках него же, и стабильностью архитектуры?
Также мы уже видели публично аналоги от Qwen3 next, от ребят из Nvidia и пр., стало ли это смертью трансформера? Поживем, увидим, пока все еще не становилось. Но динамика развития архитектур данного семейства хорошая, может даже кому-то лучше заложиться на знание и представление о таких архитектурах.
Всем добра, увидимся.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Dealer.AI
Ты следующий ⡨⠪⠸⠋⠉ 🇨🇩
Новая модель Qwen3-Next...
Забавно, что в блоге утек обзор, но ссылку почистили и поэтому довольствуемся hf релизом. Однако, спасибо коллегам, они засейвили страничку и приложу ее ниже.
Итак, погнали. Задача, которую решают авторы…
Новая модель Qwen3-Next...
Забавно, что в блоге утек обзор, но ссылку почистили и поэтому довольствуемся hf релизом. Однако, спасибо коллегам, они засейвили страничку и приложу ее ниже.
Итак, погнали. Задача, которую решают авторы…
Forwarded from Dealer.AI
REGEN – новый подход к рекомендациям на основе диалогового взаимодействия.
Традиционные рекомендательные системы сосредоточены на предсказании следующего товара, который может понравиться пользователю, но не способны вести естественный диалог, понимать отзывы на естественном языке или объяснять причины рекомендаций. Существующие архитектуры и наборы данных не позволяли изучать эти новые возможности, теперь же есть REGEN от Google(Reviews Enhanced with GEnerative Narratives) .
Работа поделена на два важных аспекта:
1. Датасет для измерения качества подобных взаимодействий юзера, рекомендательной системы и диалогового интерфейса.
2. Предложены и протестированны две архитектуры рекомендаций: FLARE - на базе коллаборативной фильтрации; и LUMEN - на базе LM (Gemma LLM), учитывающей, как интеракции user-item, так и текстовые взаимодействия. Люмен заявили впервые именно в статье REGEN.
Начнём с данных. Созданный набор данных REGEN был собран не совсем с нуля – исследователи дополнили общедоступный Amazon Product Reviews dataset, синтезировав с помощью LLM Gemini 1.5 Flash два ключевых элемента:
1. Критика: Примеры того, как пользователь может выразить предпочтение или критику в диалоге (например, "Я бы предпочел черную ручку, а вы предлагаете мне красную").
2. Нарративы: Разнообразные текстовые пояснения, такие как причины для покупки, отзывы о продуктух или предпочтения пользователя.
Архитектуры моделей. Как уже упоминалось, были предложены и протестированы два подхода:
1. Гибридная система FLARE. Классическая модель аля SASRec предсказывает следующий товар, а легковесная языковая модель Gemma 2B генерирует нарратив на основе этого предсказания.
2. Единая модель LUMEN. Одна большая языковая модель обучается для совместного выполнения задач: обработки критики, генерации рекомендации и создания нарратива в рамках единого процесса. Модель учится e2e "решать", когда выдать ID товара, а когда продолжить генерировать текст.
Дизайн эксперимента и метрики.
Эксперименты были построены вокруг предложенной авторами статьи задачи – совместной генеративной рекомендации товаров. Модели получали историю покупок и, опционально, текстовую критику, после чего должны были порекомендовать следующий товар и сгенерировать о нем контекстуальный нарратив.
Для оценки использовались два типа метрик:
- Метрики точности рекомендаций. Основной метрикой был Recall@10 – насколько часто желаемый товар оказывается в топ-10 предсказаний.
- Метрики качества текста. Для оценки сгенерированных нарративов использовались BLEU, ROUGE и семантическое сходство cosine similarly (используют Gecko эмбы).
В итоге, включение пользовательской обратной связи в модели улучшало Recall@10 для обеих архитектур. Разумеется, для модели на базе e2e подхода LUMEN качество согласованности было лучше, ввиду исполнения LM как базы архитектуры. Однако и последовательное использование FLARE, как next item prediction+LM также улучшало метрики. Для подробного изучения показателей бенчей советую заглянуть в статью.
В целом, основная идея авторов создать новый подход на основе не только исторических интеракций юзера с товарами, но и посредством воздействия естественного языка в виде обратной связи (отзывов, критики и пр.). Это же позволяет перевести рекомендации и поиск в "живой формат" диалогового взаимодействия, возможностью уточнения и обратной связи. Представьте, вам не понравились рекомендации, вы просто пишите: "неплохо, но я бы хотел видеть тут <целевой объект>". А система тут же реагирует на это в виде обновления пула.
В целом, мы уже видим на примере Perplexity и OpenAI переход в диалоговое взаимодействие с их решениями, как наиболее нативное и удобное. Теперь очередь рекомендательных систем.
Традиционные рекомендательные системы сосредоточены на предсказании следующего товара, который может понравиться пользователю, но не способны вести естественный диалог, понимать отзывы на естественном языке или объяснять причины рекомендаций. Существующие архитектуры и наборы данных не позволяли изучать эти новые возможности, теперь же есть REGEN от Google
Работа поделена на два важных аспекта:
1. Датасет для измерения качества подобных взаимодействий юзера, рекомендательной системы и диалогового интерфейса.
2. Предложены и протестированны две архитектуры рекомендаций: FLARE - на базе коллаборативной фильтрации; и LUMEN - на базе LM (Gemma LLM), учитывающей, как интеракции user-item, так и текстовые взаимодействия. Люмен заявили впервые именно в статье REGEN.
Начнём с данных. Созданный набор данных REGEN был собран не совсем с нуля – исследователи дополнили общедоступный Amazon Product Reviews dataset, синтезировав с помощью LLM Gemini 1.5 Flash два ключевых элемента:
1. Критика: Примеры того, как пользователь может выразить предпочтение или критику в диалоге (например, "Я бы предпочел черную ручку, а вы предлагаете мне красную").
2. Нарративы: Разнообразные текстовые пояснения, такие как причины для покупки, отзывы о продуктух или предпочтения пользователя.
Архитектуры моделей. Как уже упоминалось, были предложены и протестированы два подхода:
1. Гибридная система FLARE. Классическая модель аля SASRec предсказывает следующий товар, а легковесная языковая модель Gemma 2B генерирует нарратив на основе этого предсказания.
2. Единая модель LUMEN. Одна большая языковая модель обучается для совместного выполнения задач: обработки критики, генерации рекомендации и создания нарратива в рамках единого процесса. Модель учится e2e "решать", когда выдать ID товара, а когда продолжить генерировать текст.
Дизайн эксперимента и метрики.
Эксперименты были построены вокруг предложенной авторами статьи задачи – совместной генеративной рекомендации товаров. Модели получали историю покупок и, опционально, текстовую критику, после чего должны были порекомендовать следующий товар и сгенерировать о нем контекстуальный нарратив.
Для оценки использовались два типа метрик:
- Метрики точности рекомендаций. Основной метрикой был Recall@10 – насколько часто желаемый товар оказывается в топ-10 предсказаний.
- Метрики качества текста. Для оценки сгенерированных нарративов использовались BLEU, ROUGE и семантическое сходство cosine similarly (используют Gecko эмбы).
В итоге, включение пользовательской обратной связи в модели улучшало Recall@10 для обеих архитектур. Разумеется, для модели на базе e2e подхода LUMEN качество согласованности было лучше, ввиду исполнения LM как базы архитектуры. Однако и последовательное использование FLARE, как next item prediction+LM также улучшало метрики. Для подробного изучения показателей бенчей советую заглянуть в статью.
В целом, основная идея авторов создать новый подход на основе не только исторических интеракций юзера с товарами, но и посредством воздействия естественного языка в виде обратной связи (отзывов, критики и пр.). Это же позволяет перевести рекомендации и поиск в "живой формат" диалогового взаимодействия, возможностью уточнения и обратной связи. Представьте, вам не понравились рекомендации, вы просто пишите: "неплохо, но я бы хотел видеть тут <целевой объект>". А система тут же реагирует на это в виде обновления пула.
В целом, мы уже видим на примере Perplexity и OpenAI переход в диалоговое взаимодействие с их решениями, как наиболее нативное и удобное. Теперь очередь рекомендательных систем.
arXiv.org
REGEN: A Dataset and Benchmarks with Natural Language Critiques...
This paper introduces a novel dataset REGEN (Reviews Enhanced with GEnerative Narratives), designed to benchmark the conversational capabilities of recommender Large Language Models (LLMs),...
Forwarded from дата инженеретта
Full + Incremental Load
Начала читать книгу "Data Engineering Design Patterns" (2025), 375 страниц. Несколько раз видела хорошие отзывы, по содержанию очень прикольная. Это про паттерны загрузки данных, как лучше работать с ошибками в данных, как организовать правильный перезапуск пайплайна и еще много всего
В книге дали ссылочку на гитхаб с готовым кодом❤
Эта серия постов будет неким конспектом с добавлением моих мыслей
Итак, начнем
Data Ingestion/Загрузка данных
🌷 Full Load
Опасности и решения:
1. Следить за ростом датасета. В идеале не слишком много строк, растет медленно
2. drop-insert - опасная штука, пользователи могут читать в момент записи. Использовать вьюшку:
🤩 пользователи ходят в вьюшку
🤩 вьюшка смотрит на table1
🤩 данные пишутся в table2
🤩 table2 подменяется на table1
У нас реально были такие проблемы:
Что мы сделали:
1. Добавили зависимости по событию от источников
2. shadow calc: создается копия витрины, все манипуляции происходят с копией в стейджинге, в конце делается rename
🪴 Incremental Load
1⃣ Pattern: Incremental Loader
1й способ. Иметь дату загрузки, чтобы определить инкремент. Опасно использовать дату события, потому что они могут долетать позже. Например, временно отключился интернет, события долетели с лагом, а мы уже обработали этот период. Последняя дата загрузки должна где-то сохраняться
2й способ. Делать партиции по времени. Например, даг работает каждый час и всегда берет данные за предыдущий час
Опасности и решения:
1. Для удаленных строк применять soft delete (просто маркируем удаленной) вместо hard delete, иначе они просто останутся у нас в системе
2. Использовать Insert-only/append-only - в табличку только добавляем данные
Реализации:
1. Для даты загрузки - обязательно добавлять фильтр
2. Для партиций по времени - добавить сенсор, который смотрит на появление следующей партиции. Если партиция появилась, значит, текущий период закончился и его можно обработать. Плюс обязательно передать дату в Airflow через {{ ds }}
Я была удивлена, прочитав этот механизм. Все делаем по книжке, получается😎
2⃣ Pattern: Change Data Capture
Используется, когда события нужно получать быстро (~30s). CDC - это стриминг логов журналов (WAL) баз данных
Был приведен пример с Delta Lake, но для Iceberg я тоже нашла примеры
На этом пока все, это была даже не половина всей главы🥺
#depatterns
Начала читать книгу "Data Engineering Design Patterns" (2025), 375 страниц. Несколько раз видела хорошие отзывы, по содержанию очень прикольная. Это про паттерны загрузки данных, как лучше работать с ошибками в данных, как организовать правильный перезапуск пайплайна и еще много всего
В книге дали ссылочку на гитхаб с готовым кодом
Эта серия постов будет неким конспектом с добавлением моих мыслей
Итак, начнем
Data Ingestion/Загрузка данных
Опасности и решения:
1. Следить за ростом датасета. В идеале не слишком много строк, растет медленно
2. drop-insert - опасная штука, пользователи могут читать в момент записи. Использовать вьюшку:
У нас реально были такие проблемы:
File does not exist:
hdfs://warehouse/hive/my_db.db/my_table/2
6-01_29_data.0.parq
It is possible the underlying files have been
updated. You can explicitly invalidate the
cache in Spark by running 'REFRESH TABLE
tableName' command in SQL or by recreating
the Dataset/DataFrame involved.
Что мы сделали:
1. Добавили зависимости по событию от источников
2. shadow calc: создается копия витрины, все манипуляции происходят с копией в стейджинге, в конце делается rename
1й способ. Иметь дату загрузки, чтобы определить инкремент. Опасно использовать дату события, потому что они могут долетать позже. Например, временно отключился интернет, события долетели с лагом, а мы уже обработали этот период. Последняя дата загрузки должна где-то сохраняться
2й способ. Делать партиции по времени. Например, даг работает каждый час и всегда берет данные за предыдущий час
Опасности и решения:
1. Для удаленных строк применять soft delete (просто маркируем удаленной) вместо hard delete, иначе они просто останутся у нас в системе
2. Использовать Insert-only/append-only - в табличку только добавляем данные
Реализации:
1. Для даты загрузки - обязательно добавлять фильтр
f'ingestion_time BETWEEN "{date_from}" AND "{date_to}"'2. Для партиций по времени - добавить сенсор, который смотрит на появление следующей партиции. Если партиция появилась, значит, текущий период закончился и его можно обработать. Плюс обязательно передать дату в Airflow через {{ ds }}
Я была удивлена, прочитав этот механизм. Все делаем по книжке, получается
Используется, когда события нужно получать быстро (~30s). CDC - это стриминг логов журналов (WAL) баз данных
Был приведен пример с Delta Lake, но для Iceberg я тоже нашла примеры
На этом пока все, это была даже не половина всей главы
#depatterns
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
leetcode.pdf
552 KB
Очень большой сборник задач с leetcode для подготовки к собесу, самые ключевые задачи с кодом и решением. Формат pdf позволяет готовиться к интервью в любой обстановке. Ставим огонек 🔥 и делимся с другом такой годнотой, если хотите больше подобных задачников!
@postypashki_old
@postypashki_old
Forwarded from LLM is all you need
Speculative Decoding — хитрая техника, которая позволяет ускорить инференс LLM.
Фокус заключается в следующем... имеется две модели:
- Маленькая и тупенькая, но быстрая (draft model)
- Большая и умная, но медленная (target model)
Маленькая модель используется для предсказания, а большая — для проверки и исправления ошибок маленькой модели. Как это работает...
Маленькая модель генерирует текст. Делает она это итерационно: на каждой итерации появляется новый токен (если упрощенно - слово):
1. Каждый охотник
2. Каждый охотник желает
3. Каждый охотник желает знать
4. Каждый охотник желает знать где
5. Каждый охотник желает знать где спит
Делает она это очень быстро, потому что - маленькая.
Допустим, на 5 итерации мы останавливаемся и вся сгенерированная последовательность подается на вход в большую модель, чтобы она предсказала вероятности по каждому токену в последовательности.
И сверяем — что выдала маленькая модель и что предсказала большая. Если на какой-то итерации возникли различия, то начиная с нее большая модель (также в итерационном режиме) генерирует новый текст:
4. Каждый охотник желает знать где
5. Каждый охотник желает знать где сидит
Потом маленькая модель снова выдает пачку черновых токенов, а большая проверяет. И так продолжается дот тех пор, пока не будет закончен весь текст.
Такой подход гарантирует, что конечный результат будет точно таким же, как если бы весь текст писала большая модель.
При этом мы получаем прирост производительности (инференса) примерно в 2-3 раза.
Фокус заключается в следующем... имеется две модели:
- Маленькая и тупенькая, но быстрая (draft model)
- Большая и умная, но медленная (target model)
Маленькая модель используется для предсказания, а большая — для проверки и исправления ошибок маленькой модели. Как это работает...
Маленькая модель генерирует текст. Делает она это итерационно: на каждой итерации появляется новый токен (если упрощенно - слово):
1. Каждый охотник
желает2. Каждый охотник желает
знать3. Каждый охотник желает знать
где4. Каждый охотник желает знать где
спит5. Каждый охотник желает знать где спит
белкаДелает она это очень быстро, потому что - маленькая.
Допустим, на 5 итерации мы останавливаемся и вся сгенерированная последовательность подается на вход в большую модель, чтобы она предсказала вероятности по каждому токену в последовательности.
И сверяем — что выдала маленькая модель и что предсказала большая. Если на какой-то итерации возникли различия, то начиная с нее большая модель (также в итерационном режиме) генерирует новый текст:
4. Каждый охотник желает знать где
сидит5. Каждый охотник желает знать где сидит
фазанПотом маленькая модель снова выдает пачку черновых токенов, а большая проверяет. И так продолжается дот тех пор, пока не будет закончен весь текст.
Такой подход гарантирует, что конечный результат будет точно таким же, как если бы весь текст писала большая модель.
При этом мы получаем прирост производительности (инференса) примерно в 2-3 раза.
Forwarded from Korenev AI - GPT в тапочках🩴
Чотинькие пацанчики из Клода выкатили пушка-фичу - Скиллы.
Скилл (он же Навык) - это свой персональный сценарий по обработке/ созданию инфы, в т.ч. с использованием питона. Все выполняется на стороне Клода. Т.е. это такой глобальный шаг от персональных текстовых инструкций и кастомному инструментарию, который каждый пользователь может заточить под себя и выбирать в зависимости от ситуации. Скилл может состоять из нескольких файлов, разных инструкций и пояснений, а так же кода.
Ребята не поленились и вынести в настройки предустановленные скиллы: создание сложных многокомпонентных сайтов а-ля Ловабл, создание MCP, брендирование в стиле Клод и прочие создатели визуалов. А еще для ленивых они сделали скилл по созданию скиллов.
Тут подробная инструкция по скилам и их использованию
Я сразу сделал себе два скилла:
Промпт был элементарный: "создай скилл, который будет делать изображение квадратным (обрезаем снизу или справа) и переворачивать его на 180 градусов."
Все заработало с первого раза - результат прикладывсаю! Правда, немного не так, как я ожидал: при каждом вызове скилла Клод создает питон-скрипт заново. Я же ожидал, что скрипт будет в составе скилла. Но вопрос решаем, можно актуализировать скилла, версионность поддерживается
В инструкции Клода перечислены еще варианты Скиллов:
Навык автоматизации CRM: создаёт контакты, обновляет возможности продаж, поддерживает стандарты данных для устранения повторяющегося ввода
Навык проверки юридических договоров: оценивает соглашения на соответствие стандартным условиям, выявляет рискованные пункты, предлагает защитную формулировку
Навык планирования спринтов: рассчитывает скорость команды, оценивает работу с учётом паттернов, распределяет мощности, генерирует документы планирования
Навык SEO-контента: анализирует возможности, структурирует под поисковые намерения, оптимизирует с сохранением тона бренда
Навык музыкальной композиции: создаёт оригинальные треки с реалистичными инструментами, применяет жанровые конвенции, экспортирует для продакшена
Навык автоматизации отчётов: собирает месячные данные, применяет расчёты, генерирует визуализации, форматирует по шаблону, рассылает заинтересованным лицам
Навык рецензирования навыков: оценивает эффективность другого навыка, предлагает улучшения инструкций, выявляет упущенные крайние случаи, рекомендует изменения структуры
Я так понимаю, в работу скилла еще и MCP можно подрубить. Очень знатный комбайн получается.
Осталось только убедиться, что он будет действительно полезным и удобным
И еще бы выяснить, как правильно писать: "скилл" или "скил". Ау, филологи, помогайте!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Женя Янченко
«Твой API вообще не RESTful»
Такую претензию один разработчик озвучил аналитику. Причиной возмущения были следующие решения:
🟣 использование POST вместо GET для получения данных
🟣 использование глагола в URL, типа
Ирония ситуации была в том, что в проекте оба эти «нарушения» RESTful подхода уже не раз встречались, а разработчик и аналитик оба только недавно пришли в команду.
Давайте разберемся, насколько претензии были правомерны.
🤓 Вообще REST создавался не для сложных бизнес-систем с кучей операций, а как архитектурный стиль (то есть набор правил) для гипермедийных систем типа Википедии.
Когда мы пытаемся уложить логику бизнес-операций и взаимодействия микросервисов в чистый REST, то неизбежно сталкиваемся со сложностями.
Даже простой
Классический RESTful возможен там, где мы имеем дело с набором статичных ресурсов, которым достаточно CRUD-операций. Например, хранилище файлов S3 или MVP сервиса стриминга музыки.
🤔 Может, если у нас бизнес-процессы, то нам отказаться от REST и делать эндпойнты с действиями?
Такой подход называется RPC over REST. Он выглядит как REST, но отталкивается не от ресурсов, а от действий (процедур). При этом методы http (GET/PUT/DELETE) могут не использоваться, всё может реализовываться через POST.
Среди публичных API не встречала этот подход в чистом виде, но эндпойнтов с действиями много например в Ozon Seller API:
Так, а если мне список документов нужно получить, то это POST
А если мне нужно сделать поиск (фильтрацию) документов по куче полей? Все их в url GET класть кажется плохой идеей.
Ответы GET запросов могут кэшироваться на промежуточных узлах, а зачем такой специфический запрос кэшировать? Да и ограничение на длину запроса может сработать.
Поэтому делают POST
Это удобно и часто используется.
Так что с первой претензией разобрались, снимается 😊
Вернемся к глаголам.
🤔 Теоретически часть действий можно завернуть в статусы документа и вместо POST
PATCH
Но не для всех операций сработает. Да и читаемость может сильно пострадать.
Есть гибридный подход, который работает с ресурсами и методами HTTP, но может иметь действия в URL и использовать POST для сложных запросов чтения.
Такой подход называют Pragmatic REST. Его главная цель — понятность и удобство. Pragmatic REST берет всё лучшее из REST, но позволяет отступить от строгих правил, если это необходимо для ясности и удобства ☺️
Скорее всего на вашем проекте используется именно он, даже если сам термин не применяется.
Разработчик с аналитиком в итоге пришли к консенсусу по этой задаче, заменив один из POST-ов на GET, а остальное оставив в первоначальном виде. Но это был не последний их спор.
Кстати, есть еще холиварный вопрос: по классике REST-подхода метод PUT используется для полного обновления ресурса, а PATCH для частичного. Но на многих проектах я встречала PUT для частичного обновления нескольких полей, и всем было ок. Голосуйте в опросе ниже, на чьей вы стороне 😃
Были ли у вас ситуации с дискуссиями вокруг разрабатываемого API?
Такую претензию один разработчик озвучил аналитику. Причиной возмущения были следующие решения:
/approveИрония ситуации была в том, что в проекте оба эти «нарушения» RESTful подхода уже не раз встречались, а разработчик и аналитик оба только недавно пришли в команду.
Давайте разберемся, насколько претензии были правомерны.
🤓 Вообще REST создавался не для сложных бизнес-систем с кучей операций, а как архитектурный стиль (то есть набор правил) для гипермедийных систем типа Википедии.
Когда мы пытаемся уложить логику бизнес-операций и взаимодействия микросервисов в чистый REST, то неизбежно сталкиваемся со сложностями.
Даже простой
/login уже не RESTful 🤷♀️Классический RESTful возможен там, где мы имеем дело с набором статичных ресурсов, которым достаточно CRUD-операций. Например, хранилище файлов S3 или MVP сервиса стриминга музыки.
🤔 Может, если у нас бизнес-процессы, то нам отказаться от REST и делать эндпойнты с действиями?
/update
/approve
Такой подход называется RPC over REST. Он выглядит как REST, но отталкивается не от ресурсов, а от действий (процедур). При этом методы http (GET/PUT/DELETE) могут не использоваться, всё может реализовываться через POST.
Среди публичных API не встречала этот подход в чистом виде, но эндпойнтов с действиями много например в Ozon Seller API:
POST /v2/products/delete
POST /v1/product/archive
POST /v1/product/unarchive
Так, а если мне список документов нужно получить, то это POST
/getDocuments ? Как-то непривычно. Удобно же со старым добрым :GET /documents
GET /document/{id}
А если мне нужно сделать поиск (фильтрацию) документов по куче полей? Все их в url GET класть кажется плохой идеей.
Ответы GET запросов могут кэшироваться на промежуточных узлах, а зачем такой специфический запрос кэшировать? Да и ограничение на длину запроса может сработать.
Поэтому делают POST
/documents/searchЭто удобно и часто используется.
Так что с первой претензией разобрались, снимается 😊
Вернемся к глаголам.
🤔 Теоретически часть действий можно завернуть в статусы документа и вместо POST
/document/{id}/approve делать:PATCH
/document/{id}{
"status": "APPROVED"
}Но не для всех операций сработает. Да и читаемость может сильно пострадать.
Есть гибридный подход, который работает с ресурсами и методами HTTP, но может иметь действия в URL и использовать POST для сложных запросов чтения.
Такой подход называют Pragmatic REST. Его главная цель — понятность и удобство. Pragmatic REST берет всё лучшее из REST, но позволяет отступить от строгих правил, если это необходимо для ясности и удобства ☺️
Скорее всего на вашем проекте используется именно он, даже если сам термин не применяется.
Разработчик с аналитиком в итоге пришли к консенсусу по этой задаче, заменив один из POST-ов на GET, а остальное оставив в первоначальном виде. Но это был не последний их спор.
Кстати, есть еще холиварный вопрос: по классике REST-подхода метод PUT используется для полного обновления ресурса, а PATCH для частичного. Но на многих проектах я встречала PUT для частичного обновления нескольких полей, и всем было ок. Голосуйте в опросе ниже, на чьей вы стороне 😃
Были ли у вас ситуации с дискуссиями вокруг разрабатываемого API?
Please open Telegram to view this post
VIEW IN TELEGRAM