Forwarded from Персонализация неизбежна
Про "рекомендательные системы" скидок, бонусов, тритментов и пр.
Все посты до этого были про персонализацию на больших каталогах (когда айтемов много). Но есть задачи по персонализации некоторых "стратегий" (или тритментов), в которых может быть очень много бизнес-профита (советую посмотреть статьи D. Goldenberg из Booking на RecSys 20/22 и др.).
Например, вам могут принести задачу: "построить рекомендательную систему скидок в такси, чтобы она рекомендовала, какую скидку дать конкретному клиенту". Тут можно спорить о терминах — рек. система это или нет, — но персонализация явно может помочь.
Датасет будет примерно такой:
Я сталкивался с 4 разными прикладными задачами из разных доменов, которые подходят под это условие. И можно было бы сэкономить много времени, если бы знал следующее: делать что-то хорошее можно только на рандомизированной раздаче тритментов (то есть вы сначала делаете рандомную раздачу, и поверх нее только обучаете модель). И вот почему:
1. Это важно для обучения модели. Если большую скидку давать тем, кто вряд ли закажет, а маленькую — тем, кто пользуется постоянно, то модель выучит контринтуитивную связь:
Когда же тритменты назначаются случайно, появляется шанс выучить что-то адекватное.
2. Это важно для валидации модели. Задачи часто связаны с финансами, и очень важно корректно оценить стратегию по эффективности. Когда-то я долго гуглил тему "evaluation of multiple treatments" и нашел вот такую статью. Я показал её коллеге Вите Харламову (@xapulc) и очень удивился, когда через пару дней Витя прислал ~5 страниц математического текста с доказательством корректности метода при определённых условиях. Потом узнал, что Витя учится в аспирантуре ММ МГУ :) Вот ссылка на его пост, где он рассказывает про метод и в целом обещал продолжить писать на тему персонализации.
Но иметь рандомизированную выборку дорого — её надо постоянно поддерживать для обновления модели; больший размер = меньше эффект от персонализации и т. д. Поэтому хочется использовать смещённые данные (а) для обучения и (б) для валидации.
Сейчас думаю так: для обучения можно пробовать разные методы "устойчивые к смещению" (они легко гуглятся) — например, аккуратно добавлять смещённую часть данных к рандомной. Но вот валидацию моделей, насколько я знаю, можно делать только на чистом рандомном эксперименте. Если вы знаете другие способы — пишите в комментариях 👇
Все посты до этого были про персонализацию на больших каталогах (когда айтемов много). Но есть задачи по персонализации некоторых "стратегий" (или тритментов), в которых может быть очень много бизнес-профита (советую посмотреть статьи D. Goldenberg из Booking на RecSys 20/22 и др.).
Например, вам могут принести задачу: "построить рекомендательную систему скидок в такси, чтобы она рекомендовала, какую скидку дать конкретному клиенту". Тут можно спорить о терминах — рек. система это или нет, — но персонализация явно может помочь.
Датасет будет примерно такой:
user_id, treatment_group (0%, 5%, 10% скидки), date, targetЯ сталкивался с 4 разными прикладными задачами из разных доменов, которые подходят под это условие. И можно было бы сэкономить много времени, если бы знал следующее: делать что-то хорошее можно только на рандомизированной раздаче тритментов (то есть вы сначала делаете рандомную раздачу, и поверх нее только обучаете модель). И вот почему:
1. Это важно для обучения модели. Если большую скидку давать тем, кто вряд ли закажет, а маленькую — тем, кто пользуется постоянно, то модель выучит контринтуитивную связь:
Чем больше скидка, тем меньше вероятность, что человек купит → значит, всем надо дать маленькую скидку.
Когда же тритменты назначаются случайно, появляется шанс выучить что-то адекватное.
2. Это важно для валидации модели. Задачи часто связаны с финансами, и очень важно корректно оценить стратегию по эффективности. Когда-то я долго гуглил тему "evaluation of multiple treatments" и нашел вот такую статью. Я показал её коллеге Вите Харламову (@xapulc) и очень удивился, когда через пару дней Витя прислал ~5 страниц математического текста с доказательством корректности метода при определённых условиях. Потом узнал, что Витя учится в аспирантуре ММ МГУ :) Вот ссылка на его пост, где он рассказывает про метод и в целом обещал продолжить писать на тему персонализации.
Но иметь рандомизированную выборку дорого — её надо постоянно поддерживать для обновления модели; больший размер = меньше эффект от персонализации и т. д. Поэтому хочется использовать смещённые данные (а) для обучения и (б) для валидации.
Сейчас думаю так: для обучения можно пробовать разные методы "устойчивые к смещению" (они легко гуглятся) — например, аккуратно добавлять смещённую часть данных к рандомной. Но вот валидацию моделей, насколько я знаю, можно делать только на чистом рандомном эксперименте. Если вы знаете другие способы — пишите в комментариях 👇
Telegram
Math for Impact
Оценка качества персонализации
TL;DR
Позволяет оценить эффективность персонализации без проведения нового эксперимента. Особенно полезен, если вариантов воздействий немного.
Почему обсуждается?
При разработке персонализации важно заранее понимать, принесёт…
TL;DR
Позволяет оценить эффективность персонализации без проведения нового эксперимента. Особенно полезен, если вариантов воздействий немного.
Почему обсуждается?
При разработке персонализации важно заранее понимать, принесёт…
Forwarded from DevFM
Прокачать навыки System Design
Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.
И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.
– если готовитесь к интервью, вы получите базу о том, как такие интервью проводятся, что важно для интервьюера, и достаточно оперативно получите фундаментальные знания, чтобы проходить такие интервью
– если хотите подтянуть навыки проектирования – этот курс даёт структурированную базу, и вы будете понимать, куда копать дальше, чтобы расширить знания
Начать рекомендую с видео от автора курса на YouTube.
Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.
#systemdesign
Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.
И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.
– если готовитесь к интервью, вы получите базу о том, как такие интервью проводятся, что важно для интервьюера, и достаточно оперативно получите фундаментальные знания, чтобы проходить такие интервью
– если хотите подтянуть навыки проектирования – этот курс даёт структурированную базу, и вы будете понимать, куда копать дальше, чтобы расширить знания
Начать рекомендую с видео от автора курса на YouTube.
Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.
#systemdesign
Leetcode
Explore - LeetCode
LeetCode Explore is the best place for everyone to start practicing and learning on LeetCode. No matter if you are a beginner or a master, there are always new topics waiting for you to explore.
Forwarded from что-то на инженерном
Способы загрузки данных
В нашей инженерской работе часто приходится сталкиваться с задачами создания витрин данных, миграции с одного источника на другой и регулярного обновления данных. Каждый проект уникален, для каждой витрины нужно подобрать свой подход к загрузке данных, учитывая особенности бизнеса, формат и объем данных, а также частоту и скорость обновления.
На выбор стратегии влияют множество факторов: требования по времени загрузки, качество данных, возможность обработки изменений и многое другое.
Кстати, на собеседованиях с уклоном в system design часто просят спроектировать витрины данных и продумать разные способы загрузки, чтобы обеспечить эффективную и надежную работу всей архитектуры.
➡️ В карточках я собрала основные типы загрузок данных в ETL-процессах. Они помогут лучше ориентироваться в существующих методах и подобрать оптимальный подход для своей задачи.
В нашей инженерской работе часто приходится сталкиваться с задачами создания витрин данных, миграции с одного источника на другой и регулярного обновления данных. Каждый проект уникален, для каждой витрины нужно подобрать свой подход к загрузке данных, учитывая особенности бизнеса, формат и объем данных, а также частоту и скорость обновления.
На выбор стратегии влияют множество факторов: требования по времени загрузки, качество данных, возможность обработки изменений и многое другое.
Кстати, на собеседованиях с уклоном в system design часто просят спроектировать витрины данных и продумать разные способы загрузки, чтобы обеспечить эффективную и надежную работу всей архитектуры.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
This media is not supported in your browser
VIEW IN TELEGRAM
Курсы по Recsys😠
Пока все обычные люди идут на агентов и верят, что волна AI не закончится, настоящие gigachats идут на рекомендательные системы. Иронично, что вакансий на тимлида рекомендашек сейчас больше, чем на ИИ, поэтому составил список курсов от zero to hero, чтобы не быть, как все.
1️⃣ Для начала пытаемся в целом понять, надо ли нам такое, поэтому идем читать главу в хендбуке яндекса, где уже получаем представление о сфере
2️⃣ Если вам вдруг понравилось, то даем джаззу вместе с базовыми курсами от 🥚 : Your first recsys и Your Second RecSys
3️⃣ Курс от Sber AI Labs на библиотеке RePlay с нуля до выхода в продакшн
4️⃣ Kaggle competition для Otus по рекомендашкам
5️⃣ Огромный болт курс от Microsoft
А всем остальным желаю хорошей температуры(жду пока она будет соответствовать температуре на улице) и легкого прода💗
Пока все обычные люди идут на агентов и верят, что волна AI не закончится, настоящие gigachats идут на рекомендательные системы. Иронично, что вакансий на тимлида рекомендашек сейчас больше, чем на ИИ, поэтому составил список курсов от zero to hero, чтобы не быть, как все.
А всем остальным желаю хорошей температуры(жду пока она будет соответствовать температуре на улице) и легкого прода
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Галлюцинации, как недостаток энтропии для генерации токенов.
Ща будет сложное миясо 😈 осторожно длинопост.
Свежая и очень интересная статья, которая может связать концептуальное понимание глюков через недостаток знаний (в обывательском смысле) и недостаток информации для генерации уверенных/надежных токенов в Байессовском.
Авторы статьи задаются вопросом: если LLM приближенно выполняют байесовский вывод, то почему они демонстрируют нарушение инвариантности к перестановкам данных? Проще говоря, если изменить порядок слов во входном контексте, модель может выдать разные ответы, что противоречит принципам строгого байесовского вывода.Кстати, мы используем этот артефакт для атак языковых моделей в нашей библиотеке augmentex , и это работает не только для decoder, но и для encoder моделей.
Такое явление напрямую связано с проблемой галлюцинаций. Исследователи ставят задачу объяснить этот парадокс и предложить теоретическую основу, которая не просто констатирует, а предсказывает возникновение галлюцинаций.
Ключевая идея исследования заключается в том, что языковые модели оптимизируют не истинную условную энтропию ℓ(Y|X), а ожидаемую кросс-энтропию по всем перестановкам входных данных.
Это означает, что модель является "байесовской в среднем", но не для каждого конкретного порядка слов. На основе этого авторы выводят несколько важных теоретических результатов:
1. Quantified Martingale Violation Bound: Показывает, что отклонения, вызванные порядком слов, масштабируются как O(log n).
2. Expectation-level Decompression Law: Связывает информационный бюджет модели с надежностью ее ответов.
Прим. Что такое информационный бюджет EDFL? EDFL — это математический закон, который устанавливает точную связь между количеством информации, доступной модели для ответа и максимально достижимой надежностью этого ответа.
Его главная роль заключается в том, что он превращает галлюцинации из непредсказуемых сбоев в предсказуемые последствия нехватки информации.
Исследователи сравнивают это с поврежденным ZIP-архивом: если при сжатии были потеряны данные, то при распаковке алгоритм выдаст "мусор", чтобы заполнить пробелы. EDFL позволяет заранее рассчитать, достаточно ли данных для корректного "восстановления" факта.
Согласно EDFL, для того чтобы поднять вероятность корректного ответа с априорного уровня q (когда у модели мало контекста) до целевого уровня надежности p, требуется информационный бюджет Δ, измеряемый в натах (единица информации).
Формула EDFL задает нижнюю границу для этого бюджета:
Δ ≥ (1 - ε) * log(1 / q) + O(q), где
1 - ε — целевая надежность ответа (например, 95%).
q — средняя априорная вероятность правильного ответа, рассчитанная по "ослабленным" версиям промпта (например, с удаленными или замаскированными ключевыми фактами).
Δ — информационный бюджет, который измеряется как разница между логарифмом вероятности ответа на полный промпт и средним значением логарифмов вероятностей на ослабленных промптах.
Проще говоря, эта формула показывает: чем реже или неочевиднее факт (ниже q), тем больше информации Δ требуется модели, чтобы дать на него надежный ответ.
3. Мониторы B2T/RoH/ISR: Практические инструменты для принятия решений "ответить" или "воздержаться" от ответа, основанные на расчетах информационного бюджета.
- Bits-to-Trust (B2T): Рассчитывает, сколько именно информации (в битах или натах) необходимо для достижения заданного пользователем уровня надежности h* (например, не более 5% галлюцинаций). B2T = KL(Ber(1 - h*) || Ber(q_lo)), где q_lo — наихудшая априорная оценка.
- Risk-of-Hallucination (RoH): Оценивает максимально достижимую надежность (или, наоборот, риск ошибки) при текущем информационном бюджете Δ.
- Information Sufficiency Ratio (ISR): Ключевое отношение для принятия решения. ISR = Δ / B2T.
• Если ISR ≥ 1, информации достаточно, и модель можно уверенно отвечать.
• Если ISR < 1, информационный бюджет недостаточен, и безопаснее отказаться от ответа.
Свежая и очень интересная статья, которая может связать концептуальное понимание глюков через недостаток знаний (в обывательском смысле) и недостаток информации для генерации уверенных/надежных токенов в Байессовском.
Авторы статьи задаются вопросом: если LLM приближенно выполняют байесовский вывод, то почему они демонстрируют нарушение инвариантности к перестановкам данных? Проще говоря, если изменить порядок слов во входном контексте, модель может выдать разные ответы, что противоречит принципам строгого байесовского вывода.
Такое явление напрямую связано с проблемой галлюцинаций. Исследователи ставят задачу объяснить этот парадокс и предложить теоретическую основу, которая не просто констатирует, а предсказывает возникновение галлюцинаций.
Ключевая идея исследования заключается в том, что языковые модели оптимизируют не истинную условную энтропию ℓ(Y|X), а ожидаемую кросс-энтропию по всем перестановкам входных данных.
Это означает, что модель является "байесовской в среднем", но не для каждого конкретного порядка слов. На основе этого авторы выводят несколько важных теоретических результатов:
1. Quantified Martingale Violation Bound: Показывает, что отклонения, вызванные порядком слов, масштабируются как O(log n).
2. Expectation-level Decompression Law: Связывает информационный бюджет модели с надежностью ее ответов.
Прим. Что такое информационный бюджет EDFL? EDFL — это математический закон, который устанавливает точную связь между количеством информации, доступной модели для ответа и максимально достижимой надежностью этого ответа.
Его главная роль заключается в том, что он превращает галлюцинации из непредсказуемых сбоев в предсказуемые последствия нехватки информации.
Исследователи сравнивают это с поврежденным ZIP-архивом: если при сжатии были потеряны данные, то при распаковке алгоритм выдаст "мусор", чтобы заполнить пробелы. EDFL позволяет заранее рассчитать, достаточно ли данных для корректного "восстановления" факта.
Согласно EDFL, для того чтобы поднять вероятность корректного ответа с априорного уровня q (когда у модели мало контекста) до целевого уровня надежности p, требуется информационный бюджет Δ, измеряемый в натах (единица информации).
Формула EDFL задает нижнюю границу для этого бюджета:
Δ ≥ (1 - ε) * log(1 / q) + O(q), где
1 - ε — целевая надежность ответа (например, 95%).
q — средняя априорная вероятность правильного ответа, рассчитанная по "ослабленным" версиям промпта (например, с удаленными или замаскированными ключевыми фактами).
Δ — информационный бюджет, который измеряется как разница между логарифмом вероятности ответа на полный промпт и средним значением логарифмов вероятностей на ослабленных промптах.
Проще говоря, эта формула показывает: чем реже или неочевиднее факт (ниже q), тем больше информации Δ требуется модели, чтобы дать на него надежный ответ.
3. Мониторы B2T/RoH/ISR: Практические инструменты для принятия решений "ответить" или "воздержаться" от ответа, основанные на расчетах информационного бюджета.
- Bits-to-Trust (B2T): Рассчитывает, сколько именно информации (в битах или натах) необходимо для достижения заданного пользователем уровня надежности h* (например, не более 5% галлюцинаций). B2T = KL(Ber(1 - h*) || Ber(q_lo)), где q_lo — наихудшая априорная оценка.
- Risk-of-Hallucination (RoH): Оценивает максимально достижимую надежность (или, наоборот, риск ошибки) при текущем информационном бюджете Δ.
- Information Sufficiency Ratio (ISR): Ключевое отношение для принятия решения. ISR = Δ / B2T.
• Если ISR ≥ 1, информации достаточно, и модель можно уверенно отвечать.
• Если ISR < 1, информационный бюджет недостаточен, и безопаснее отказаться от ответа.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
GRPO на самом деле DPO и это многое упрощает 😱
Не буду приводить доказательства, вся зубодробительная математика тут. Скажу лишь, что GRPO было развитием PPO от команды DeepSeek при создании R семейства. Данный метод также исследует политику на разных траекториях, только сводит все в группы. Т.к. это ppo-like подход мы наследуем все те же проблемы стабилизации и настройки алгоритма, мало у кого кроме таких топ игроков он завелся для LLM предсказуемо. Поэтому модификация в виде dpo like (оч подробно писал тут про это) нам дает более простой, стабильный и надёжный вариант RLHF чисто на уровне sft.
Поэтому данная статья считаю оч важна и упростит жизнь AI-engineer при обучении моделек. Модификацию к dpo-like лосса GRPO приложу на скринах ниже.
Не буду приводить доказательства, вся зубодробительная математика тут. Скажу лишь, что GRPO было развитием PPO от команды DeepSeek при создании R семейства. Данный метод также исследует политику на разных траекториях, только сводит все в группы. Т.к. это ppo-like подход мы наследуем все те же проблемы стабилизации и настройки алгоритма, мало у кого кроме таких топ игроков он завелся для LLM предсказуемо. Поэтому модификация в виде dpo like (оч подробно писал тут про это) нам дает более простой, стабильный и надёжный вариант RLHF чисто на уровне sft.
Поэтому данная статья считаю оч важна и упростит жизнь AI-engineer при обучении моделек. Модификацию к dpo-like лосса GRPO приложу на скринах ниже.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Pavel Zloi
Давно мечтал разобраться с тем как конвертировать в GGUF без потерь в качестве, чтобы оного добиться необходимо использовать калибровочный датасет, но как подружить датасет, GGUF и инструменты квантизации для меня было неведомо.
Поэтому решил изучить тему сам и рассказать вам в моей новенькой публикации "GGUF: квантизация с калибровкой (imatrix)" на Хабр.
UPD. На примере модельки ai-sage/GigaChat-20B-A3B-instruct
#habr #gguf
Поэтому решил изучить тему сам и рассказать вам в моей новенькой публикации "GGUF: квантизация с калибровкой (imatrix)" на Хабр.
UPD. На примере модельки ai-sage/GigaChat-20B-A3B-instruct
#habr #gguf
Forwarded from Базы данных & SQL
Хранение временных данных в PostgreSQL
Временные (промежуточные) данные - те, которые нужны для обработки в течение транзакции, сессии или ограниченное время. После истечения срока такие данные не нужны. Причина использования временных данных в том, что в одном запросе не всегда можно обработать все данные. Логика приложения может предусматривать обработку данных по частям - разными запросами. В статье рассматриваются и сравниваются способы хранения временных данных в:
1) обычных таблицах;
2) нежурналируемых таблицах;
3) материализованных представлениях;
4) временных таблицах;
5) в памяти серверного процесса, используя расширение pg_variables
Читать статью
Временные (промежуточные) данные - те, которые нужны для обработки в течение транзакции, сессии или ограниченное время. После истечения срока такие данные не нужны. Причина использования временных данных в том, что в одном запросе не всегда можно обработать все данные. Логика приложения может предусматривать обработку данных по частям - разными запросами. В статье рассматриваются и сравниваются способы хранения временных данных в:
1) обычных таблицах;
2) нежурналируемых таблицах;
3) материализованных представлениях;
4) временных таблицах;
5) в памяти серверного процесса, используя расширение pg_variables
Читать статью