Интересное что-то
517 subscribers
2.72K photos
253 videos
139 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Привет всем!👋

Количество постов явно коррелирует с загруженностью на работе. Прошлая неделя была посвящена модельному риску.

Кто не знает что такое модельный риск, дам небольшую вводную.
Модельный риск - событие риска, наступающее при ошибочных решениях на основе неточности/несовершенства использования моделей в бизнес процессах.

Любая модель в том или ином виде подвержена модельному риску!


Основные проблемы, с которыми сталкивается моделист в рамках модельного риска - падение инфраструктуры (модель не считается n-дней), отсутствие данных (отдельные данные не приходят n-дней), выведена не та версия модели (модель работает не так, как предполагается или не совсем полный функционал).

Так уж случилось, что на той неделе произошло аж 2 инцидента по модельному риску.

- Что в таких случаях делает команда DS и в чем заключается сложность данного процесса?
Любая модель, так или иначе, стоит на мониторинге, в разных системах, которые в случае проблем дают симптомы. Чаще всего перераспределение признаков, либо целевой метки.

- Итак, мы видим на мониторингах странные вещи, в чем проблема их пофиксить?
Главная проблема в том, что симптомы общие для семейства проблем и DS оперативно выявить и локализовать проблему. Например, видим падение источника (фича перестала приходить, везде NaN) на источнике данные могут быть, но например, не подгружаться корректно инфрой. Тут уже надо бежать смотреть логи модели, проверяя как и первоисточник данных, так и систему, их выгружающую. В случае моей работы, это постоянное смотрение ручками + коммуникация и координация действий со смежными подразделениями по данным (DE) и инфраструктуре (MLOps).

- Выявили проблему, что дальше?
Это уже большая победа, ведь каждый день ошибки на модели - миллионы потерь для банка. Составляется план исправления в кратчайшие сроки. Когда понятны причины, заводится риск событие. Риск событие - формализация проблемы с указанием его первоисточника, процессов, затронутой проблемой и планом решения.

Данное событие обрабатывают риск-чемпионы - коллеги, которые принимают решение о критичности, формализуется оценка потери. Буквально коллеги оценивают полноту картины, в каких процессах что упало и где это влияет в денежном эквиваленте. Результатом их работы является поручение на анализ финансового эффекта потерь, подтверждение, что предложенный план исчерпывает проблему и дается правовая оценка события (если дело пахнет жареным и тянет на пару статей УК РФ).

Для нас как для DS данный процесс представляет собой формирование Ad-hoc упражнений, которые потом используются для подсчета потерь (чаще всего это некоторый what-if анализ, который мы проводим в сжатые сроки). Плюс на плечах DS лежит вывод патча + проверка и подтверждение, что после исправления работает все именно так, как и должно.

- Какой результат?
Исправление бага, действия со стороны бизнеса, которые минимизируют эффект (например, оперативный пересчет предложений, блокировка выдачи в конкретный момент), оценка прогнозируемых и фактических потерь (хорошая новость этого события, что потенциальные потери != фактические, нередко клиент может даже не заметить на себе что что-то случилось).

#трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Про "рекомендательные системы" скидок, бонусов, тритментов и пр.

Все посты до этого были про персонализацию на больших каталогах (когда айтемов много). Но есть задачи по персонализации некоторых "стратегий" (или тритментов), в которых может быть очень много бизнес-профита (советую посмотреть статьи D. Goldenberg из Booking на RecSys 20/22 и др.).

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

Датасет будет примерно такой:
user_id, treatment_group (0%, 5%, 10% скидки), date, target

Я сталкивался с 4 разными прикладными задачами из разных доменов, которые подходят под это условие. И можно было бы сэкономить много времени, если бы знал следующее: делать что-то хорошее можно только на рандомизированной раздаче тритментов (то есть вы сначала делаете рандомную раздачу, и поверх нее только обучаете модель). И вот почему:

1. Это важно для обучения модели. Если большую скидку давать тем, кто вряд ли закажет, а маленькую — тем, кто пользуется постоянно, то модель выучит контринтуитивную связь:
Чем больше скидка, тем меньше вероятность, что человек купит → значит, всем надо дать маленькую скидку.

Когда же тритменты назначаются случайно, появляется шанс выучить что-то адекватное.

2. Это важно для валидации модели. Задачи часто связаны с финансами, и очень важно корректно оценить стратегию по эффективности. Когда-то я долго гуглил тему "evaluation of multiple treatments" и нашел вот такую статью. Я показал её коллеге Вите Харламову (@xapulc) и очень удивился, когда через пару дней Витя прислал ~5 страниц математического текста с доказательством корректности метода при определённых условиях. Потом узнал, что Витя учится в аспирантуре ММ МГУ :) Вот ссылка на его пост, где он рассказывает про метод и в целом обещал продолжить писать на тему персонализации.

Но иметь рандомизированную выборку дорого — её надо постоянно поддерживать для обновления модели; больший размер = меньше эффект от персонализации и т. д. Поэтому хочется использовать смещённые данные (а) для обучения и (б) для валидации.

Сейчас думаю так: для обучения можно пробовать разные методы "устойчивые к смещению" (они легко гуглятся) — например, аккуратно добавлять смещённую часть данных к рандомной. Но вот валидацию моделей, насколько я знаю, можно делать только на чистом рандомном эксперименте. Если вы знаете другие способы — пишите в комментариях 👇
Forwarded from DevFM
Прокачать навыки System Design

Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.

И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.

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

Начать рекомендую с видео от автора курса на YouTube.

Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.

#systemdesign
Способы загрузки данных

В нашей инженерской работе часто приходится сталкиваться с задачами создания витрин данных, миграции с одного источника на другой и регулярного обновления данных. Каждый проект уникален, для каждой витрины нужно подобрать свой подход к загрузке данных, учитывая особенности бизнеса, формат и объем данных, а также частоту и скорость обновления.

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

Кстати, на собеседованиях с уклоном в system design часто просят спроектировать витрины данных и продумать разные способы загрузки, чтобы обеспечить эффективную и надежную работу всей архитектуры.

➡️ В карточках я собрала основные типы загрузок данных в ETL-процессах. Они помогут лучше ориентироваться в существующих методах и подобрать оптимальный подход для своей задачи.
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

А всем остальным желаю хорошей температуры(жду пока она будет соответствовать температуре на улице) и легкого прода💗
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, информационный бюджет недостаточен, и безопаснее отказаться от ответа.
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 приложу на скринах ниже.
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