Forwarded from Душный NLP
TDPO — потокенный DPO или просто регуляризация?
Авторы сегодняшней статьи предлагают метод потокенного Direct Preference Optimization (DPO), который на бумаге должен исправить некоторые проблемы оффлайн-обучения с подкреплением. Но на деле все оказывается не так просто.
DPO — метод обучения, не полагающийся на reward-модель. Здесь применяют датасет с размеченными парами запросов и ответов, чтобы натренировать генератор на контрастный лосс.
Проблема в том, что в случае с DPO мы работаем с вероятностями последовательностей целиком. Метод ограниченно контролирует поведение модели на уровне отдельных токенов. Это приводит к тому, что модель может ошибочно сильно повышать или понижать вероятность отдельных токенов значительно после совершенных ошибок.
Эту проблему можно нивелировать, если сделать DPO потокенным. Авторы статьи пытаются добиться этого.
Для начала они предлагают ввести необычное ограничение — сделать так, чтобы сумма наград всех токенов-продолжений для произвольного префикса была равна 0. Это довольно сильное допущение: например, если мы решаем задачу копирования какого-то куска текста, то будем сильно штрафовать модель за любое отклонение. Как результат — награда за правильный токен окажется очень большой. В этом случае, если при выборе между длинной и короткой строкой, модель будет склоняться к длинной строке.
Такое ограничение позволило авторам в их расчётах лосса избавиться от нормировочной константы вероятностного распределения. Чтобы ее вычислить, нужно суммировать награду по всем возможным ответам, а это невозможно, поэтому от константы при расчётах избавляются. В DPO нормировочная константа одинакова для победившего и проигравшего ответов, поэтому она сокращается в лоссе, но авторы статьи сделали это несколько иначе.
Из их математической модели выводится функция, которая очень похожа на DPO. Но в отличие от DPO, авторы вычитают из неё разницу между SeqKL проигравшего и победившего ответа. Этот метод, названный Token-level Direct Preference Optimization (TDPO), обеспечил незначительное улучшение по сравнению с обычным DPO. На датасете Anthropic HH точность увеличилась всего на 0,65%.
Далее авторы предлагают умножить на дополнительный коэффициент разницу SeqKL и не пропускать градиенты для победившего варианта. Это можно трактовать так: при росте SeqKL проигравшего ответа всегда увеличивается лосс, в то время, как при росте SeqKL победившего — лосс уменьшается. Получается, что добавка к DPO, после остановки градиента для её части, по сути работает, как регуляризация.
С ней метод получил название TDPO2 и он действительно неплохо улучшает показатели. На том же Anthropic HH прирост по сравнению с DPO составил уже не 0,65%, а 7,9%.
Авторы действительно предложили лучшее решение. Но возникает вопрос: насколько здесь велик вклад выведенной математической модели. По факту, авторы сильно меняют основные моменты в этой модели, а то, что остается, очень похоже на простую потокенную регуляризацию. Но её идея не нова: часто к DPO добавляют negative log likelihood loss — например, при DPO-обучении Llama 3.1, — что тоже является вариантом потокенной регуляризации. Мы склоняемся к тому, что научный вклад этой статьи невелик, а ключевые выводы — ошибочны.
Разбор подготовил❣ Михаил Хрущев
Душный NLP
Авторы сегодняшней статьи предлагают метод потокенного Direct Preference Optimization (DPO), который на бумаге должен исправить некоторые проблемы оффлайн-обучения с подкреплением. Но на деле все оказывается не так просто.
DPO — метод обучения, не полагающийся на reward-модель. Здесь применяют датасет с размеченными парами запросов и ответов, чтобы натренировать генератор на контрастный лосс.
Проблема в том, что в случае с DPO мы работаем с вероятностями последовательностей целиком. Метод ограниченно контролирует поведение модели на уровне отдельных токенов. Это приводит к тому, что модель может ошибочно сильно повышать или понижать вероятность отдельных токенов значительно после совершенных ошибок.
Эту проблему можно нивелировать, если сделать DPO потокенным. Авторы статьи пытаются добиться этого.
Для начала они предлагают ввести необычное ограничение — сделать так, чтобы сумма наград всех токенов-продолжений для произвольного префикса была равна 0. Это довольно сильное допущение: например, если мы решаем задачу копирования какого-то куска текста, то будем сильно штрафовать модель за любое отклонение. Как результат — награда за правильный токен окажется очень большой. В этом случае, если при выборе между длинной и короткой строкой, модель будет склоняться к длинной строке.
Такое ограничение позволило авторам в их расчётах лосса избавиться от нормировочной константы вероятностного распределения. Чтобы ее вычислить, нужно суммировать награду по всем возможным ответам, а это невозможно, поэтому от константы при расчётах избавляются. В DPO нормировочная константа одинакова для победившего и проигравшего ответов, поэтому она сокращается в лоссе, но авторы статьи сделали это несколько иначе.
Из их математической модели выводится функция, которая очень похожа на DPO. Но в отличие от DPO, авторы вычитают из неё разницу между SeqKL проигравшего и победившего ответа. Этот метод, названный Token-level Direct Preference Optimization (TDPO), обеспечил незначительное улучшение по сравнению с обычным DPO. На датасете Anthropic HH точность увеличилась всего на 0,65%.
Далее авторы предлагают умножить на дополнительный коэффициент разницу SeqKL и не пропускать градиенты для победившего варианта. Это можно трактовать так: при росте SeqKL проигравшего ответа всегда увеличивается лосс, в то время, как при росте SeqKL победившего — лосс уменьшается. Получается, что добавка к DPO, после остановки градиента для её части, по сути работает, как регуляризация.
С ней метод получил название TDPO2 и он действительно неплохо улучшает показатели. На том же Anthropic HH прирост по сравнению с DPO составил уже не 0,65%, а 7,9%.
Авторы действительно предложили лучшее решение. Но возникает вопрос: насколько здесь велик вклад выведенной математической модели. По факту, авторы сильно меняют основные моменты в этой модели, а то, что остается, очень похоже на простую потокенную регуляризацию. Но её идея не нова: часто к DPO добавляют negative log likelihood loss — например, при DPO-обучении Llama 3.1, — что тоже является вариантом потокенной регуляризации. Мы склоняемся к тому, что научный вклад этой статьи невелик, а ключевые выводы — ошибочны.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Архитектура ИТ-решений
Карту причин неудачи при модернизации унаследованных приложений нашел я в бумаге /thoughtworks Legacy modernization. A transformation opportunity
Такое впечатление, что традиционные задачи архитектуры предприятия регулярно переосмысливаются самым разными консультантами. И не то, чтоб они что-то принципиально новое предлагают. Скорее преподносят более современное звучание достаточно известных идей и подходов. Внутри снова история про business capabilities, ценностное предложение, расстановку приоритетов и управление объемом и границами изменения
Впрочем, если интересно, посмотрите эти рекомендации сами. Может вы увидите их как-то иначе
Такое впечатление, что традиционные задачи архитектуры предприятия регулярно переосмысливаются самым разными консультантами. И не то, чтоб они что-то принципиально новое предлагают. Скорее преподносят более современное звучание достаточно известных идей и подходов. Внутри снова история про business capabilities, ценностное предложение, расстановку приоритетов и управление объемом и границами изменения
Впрочем, если интересно, посмотрите эти рекомендации сами. Может вы увидите их как-то иначе
Forwarded from Архитектура ИТ-решений
Еще один огромный SlideDoc(слайды с заметками) System Design and Software Architecture от Ruth Malan. Какие-то идеи и слайды встречались у неё раньше. Другие я увидел впервые. Анонс от автора:
Я не хотела ограничиваться тем, что архитектура программного обеспечения - это просто "части и отношения" или ADR и т.д., подробнее здесь: введение в архитектуру ПО как системный дизайн
Forwarded from Reliable ML
Советы для CDO - Part #1
Обзор книги Carruthers, Jackson - The Chief Data Officer's Playbook
Прочитала CDO Playbook и хочу поделиться моментами, которые показались интересными.
В целом в книге ну очень высокая доля воды относительно полезной информации, поэтому обзор может быть полезным :-)
Итак, что - по мнению авторов - важно понимать, если вы CDO.
Общее - про выстраивание работы в целом:
- Не бывает много коммуникации: прогресс, фидбек, объяснения. Ты не обязательно должен делать работу в совершенстве, но все должны быть в курсе о том, что ты делаешь.
- Первое дело в работе CDO - понять бизнес. При проведении интервью спрашивать не про дату, а про проблемы в бизнесе. И, отталкиваясь от них, предлагать решения на основе данных.
- Для успеха надо вовлекать людей в активности, и особенно искать евангелистов своих идей в бизнесе. Много маленьких поддерживающих армий лучше одной большой. Это становится очень важным при внедрении изменений: одна коммуникация на всех про новые правила не приведёт к результату. Много индивидуальных коммуникаций и продажи своих идей с учётом особенностей и интересов стейкхолдеров даёт сильно больше результата. И развивается и помогает в долгосрочном периоде.
- Важно не увлекаться the empire-building trap. Дело, в первую очередь, не только в том, сколько у вас людей, а в том, какое value вы можете принести.
- Лучше недокоммититься и принести больше, чем наоборот. Это должно быть в основе. Такая вот непреложная истина 😄
Про роль CDO и немного про дата офисы:
- Авторы выделяют два основных типа CDO с точки зрения их роли в компании: first CDO и second CDO. FCDO это risk-averse чувак (фундамент пирамиды), а вот SCDO - это value-add чувак (монетизация данных). Первый должен выстроить технологический и архитектурный фундамент + запустить процессы data governance, но и не забыть про квик вины, ибо ожиданий у бизнеса от роли будет много, так как инвестируют в неё тоже много. Второй CDO - больше рискует и очень плотно общается с бизнесом, а бизнес по идее уже понимает на опыте первого CDO, что от улучшения технологий можно подвинуть границы возможного.
- Нужно понимать, какого типа ты CDO, какие навыки в тебе сильнее. Как минимум, технические (и какие), навыки управленца, бизнес-ориентированности и понимания бизнес-процессов. Слабые стороны нужно подкреплять союзниками и наймом людей. И постоянно анализировать, всё ли ок. Нельзя предавать себя. Стоит понимать, кто нужен организации, и идти туда, где будут применяться твои сильные стороны.
- При централизованной структуре чаще всего бизнес теряет оунершип над развитием дата дривен проектов. Считает, что дата должна все делать сама, а так не бывает.
- Data literacy. Обязательно должна быть база по данным у всех - понимание данных, способность их правильно понимать, уметь интерпретировать и аргументировать свою точку зрения по ним. В компании чаще всего есть значительный слой data unaware людей. В них кроется золотая жила, CDO нужно работать с ними. Они могут дать много value и идей использования данных, когда получат базовый уровень грамотности данных. При этом нужно учитывать, какой уровень грамотности нужен на каких уровнях: операционная деятельность, тактическое принятие решений, стратегическое принятие решений. На операционном важно уметь быть информированным, уметь читать данные, т.е. иметь базовые навыки. На тактическом и стратегическом нужны более индивидуальные программы обучения, плюс обязательно совместная работа с CDO над вовлеченностью к работе с данными - зачем мы это делаем, что можем классного получить.
Важно мониторить и работать над тем, чтобы на всех уровнях развивать нужную степень грамотности данных, и их использования. Плохо, когда на стратуровень поступают классные выверенные данные, но не используются, и плохо, если используются невыверенные.
Вот такие заметки. Будем рады обсудить в комментариях ваши мысли.
Во второй части обзора напишу про рекомендации для бизнеса - как найти себе подходящего CDO.
Ваш @Reliable ML
#business #обзор_книги #cdo
Обзор книги Carruthers, Jackson - The Chief Data Officer's Playbook
Прочитала CDO Playbook и хочу поделиться моментами, которые показались интересными.
В целом в книге ну очень высокая доля воды относительно полезной информации, поэтому обзор может быть полезным :-)
Итак, что - по мнению авторов - важно понимать, если вы CDO.
Общее - про выстраивание работы в целом:
- Не бывает много коммуникации: прогресс, фидбек, объяснения. Ты не обязательно должен делать работу в совершенстве, но все должны быть в курсе о том, что ты делаешь.
- Первое дело в работе CDO - понять бизнес. При проведении интервью спрашивать не про дату, а про проблемы в бизнесе. И, отталкиваясь от них, предлагать решения на основе данных.
- Для успеха надо вовлекать людей в активности, и особенно искать евангелистов своих идей в бизнесе. Много маленьких поддерживающих армий лучше одной большой. Это становится очень важным при внедрении изменений: одна коммуникация на всех про новые правила не приведёт к результату. Много индивидуальных коммуникаций и продажи своих идей с учётом особенностей и интересов стейкхолдеров даёт сильно больше результата. И развивается и помогает в долгосрочном периоде.
- Важно не увлекаться the empire-building trap. Дело, в первую очередь, не только в том, сколько у вас людей, а в том, какое value вы можете принести.
- Лучше недокоммититься и принести больше, чем наоборот. Это должно быть в основе. Такая вот непреложная истина 😄
Про роль CDO и немного про дата офисы:
- Авторы выделяют два основных типа CDO с точки зрения их роли в компании: first CDO и second CDO. FCDO это risk-averse чувак (фундамент пирамиды), а вот SCDO - это value-add чувак (монетизация данных). Первый должен выстроить технологический и архитектурный фундамент + запустить процессы data governance, но и не забыть про квик вины, ибо ожиданий у бизнеса от роли будет много, так как инвестируют в неё тоже много. Второй CDO - больше рискует и очень плотно общается с бизнесом, а бизнес по идее уже понимает на опыте первого CDO, что от улучшения технологий можно подвинуть границы возможного.
- Нужно понимать, какого типа ты CDO, какие навыки в тебе сильнее. Как минимум, технические (и какие), навыки управленца, бизнес-ориентированности и понимания бизнес-процессов. Слабые стороны нужно подкреплять союзниками и наймом людей. И постоянно анализировать, всё ли ок. Нельзя предавать себя. Стоит понимать, кто нужен организации, и идти туда, где будут применяться твои сильные стороны.
- При централизованной структуре чаще всего бизнес теряет оунершип над развитием дата дривен проектов. Считает, что дата должна все делать сама, а так не бывает.
- Data literacy. Обязательно должна быть база по данным у всех - понимание данных, способность их правильно понимать, уметь интерпретировать и аргументировать свою точку зрения по ним. В компании чаще всего есть значительный слой data unaware людей. В них кроется золотая жила, CDO нужно работать с ними. Они могут дать много value и идей использования данных, когда получат базовый уровень грамотности данных. При этом нужно учитывать, какой уровень грамотности нужен на каких уровнях: операционная деятельность, тактическое принятие решений, стратегическое принятие решений. На операционном важно уметь быть информированным, уметь читать данные, т.е. иметь базовые навыки. На тактическом и стратегическом нужны более индивидуальные программы обучения, плюс обязательно совместная работа с CDO над вовлеченностью к работе с данными - зачем мы это делаем, что можем классного получить.
Важно мониторить и работать над тем, чтобы на всех уровнях развивать нужную степень грамотности данных, и их использования. Плохо, когда на стратуровень поступают классные выверенные данные, но не используются, и плохо, если используются невыверенные.
Вот такие заметки. Будем рады обсудить в комментариях ваши мысли.
Во второй части обзора напишу про рекомендации для бизнеса - как найти себе подходящего CDO.
Ваш @Reliable ML
#business #обзор_книги #cdo
Forwarded from ML Advertising
Как поймать прод, если он падает?
Я уже писал о том, как подготовиться к инцидентам на проде, чтобы, если это вдруг произошло, не терять время и разрешить быстро.
Сегодня разберем, что делать, когда инцидент уже просходит, и, например,
- у сервиса отпал регион
- трафик на платформу клиент перестал фильтроваться
- произошел резкий скачек QPS входных запросов, ваш кластер машин не вывозит
- latency резко увеличился и не хочет уменьшаться etc.
1️⃣ Для начала, сразу после того, как вам пришло уведомление, или вас пинганул менеджер, оцените ущерб (или по-модному blast radius). Для таких целей у вас должен быть доступ в аналитическую БД, куда аггрегируются ивенты (по аукционам, пользователям, минутам, регионам), и где вы можете, написав SQL запрос, оценить, на каком регионе, клиентской DSP, сегменте пользователей имеет место инцидент. А еще лучше для таких целей иметь уже готовый дашборд с основными аггрегатами и группами.
2️⃣ После того, как оценили ущерб, определяем состояние сервиса:
- operational: работает, возможно с небольшой долей ошибок
- degraded performance: значительная доля ошибок, ухудшен пользовательский опыт, ухудшено качество ML моделей, но основные сценарии работают или резервные (fallback) модели подхватили трафик
- partial outage: часть функционала отпала, отпал регион, полностью не отправляются запросы на конкретные DSP
- major outage: все полегло
После того, как оценили состояние, эскалируем инцидент своему менеджеру и команде инфры
3️⃣ Локализуйте проблему. Постарайтесь определить, из какого сервиса происходит причина инцидента. Если причина на сервисе, куда вы ранее не контрибьютили, пингуйте соответствующие команды, чтобы они подключились и проверили свои зоны ответственности.
4⃣️️️️️️ Пока ищется причина инцидента сфокусируйтесь на том, чтобы оживить прод (по-модному stop bleeding) - проверьте, какие были крайние коммиты, связанные с ошибками, и откатите их.
Если проблема в новых артефактах, которые кеширует сервис, то зачистите кеш (если у вас есть доступ) и перезалейте рабочие или fallback артефакты.
Если проблема в повышенном использованием CPU/ RAM от выброса трафика, upscal'ите машины на кластере
Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена.
5️⃣ Если все разрешилось - продолжайте мониторить и составьте postmortem. В нем укажите
- Оцененный ущерб
- Проанализируйте причину, почему так произошло
- Укажите ваши действия, и в какие сроки вы их предприняли
Что делают в это время менеджеры и аналитики?
- помогают связаться со стейкхолдерами (чтобы те были в курсе происходящего и могли со своей стороны что-то сделать - например, включить fallback) или нужными командами разработки
- смотрят на метрики и помогают оценить ущерб и в целом состояние приложения
- помогают эскалировать в нужную команду
Также рекомендую хорошую статью, как поднимают упавший прод на Ozon'е
Я уже писал о том, как подготовиться к инцидентам на проде, чтобы, если это вдруг произошло, не терять время и разрешить быстро.
Сегодня разберем, что делать, когда инцидент уже просходит, и, например,
- у сервиса отпал регион
- трафик на платформу клиент перестал фильтроваться
- произошел резкий скачек QPS входных запросов, ваш кластер машин не вывозит
- latency резко увеличился и не хочет уменьшаться etc.
1️⃣ Для начала, сразу после того, как вам пришло уведомление, или вас пинганул менеджер, оцените ущерб (или по-модному blast radius). Для таких целей у вас должен быть доступ в аналитическую БД, куда аггрегируются ивенты (по аукционам, пользователям, минутам, регионам), и где вы можете, написав SQL запрос, оценить, на каком регионе, клиентской DSP, сегменте пользователей имеет место инцидент. А еще лучше для таких целей иметь уже готовый дашборд с основными аггрегатами и группами.
2️⃣ После того, как оценили ущерб, определяем состояние сервиса:
- operational: работает, возможно с небольшой долей ошибок
- degraded performance: значительная доля ошибок, ухудшен пользовательский опыт, ухудшено качество ML моделей, но основные сценарии работают или резервные (fallback) модели подхватили трафик
- partial outage: часть функционала отпала, отпал регион, полностью не отправляются запросы на конкретные DSP
- major outage: все полегло
После того, как оценили состояние, эскалируем инцидент своему менеджеру и команде инфры
3️⃣ Локализуйте проблему. Постарайтесь определить, из какого сервиса происходит причина инцидента. Если причина на сервисе, куда вы ранее не контрибьютили, пингуйте соответствующие команды, чтобы они подключились и проверили свои зоны ответственности.
4⃣️️️️️️ Пока ищется причина инцидента сфокусируйтесь на том, чтобы оживить прод (по-модному stop bleeding) - проверьте, какие были крайние коммиты, связанные с ошибками, и откатите их.
Если проблема в новых артефактах, которые кеширует сервис, то зачистите кеш (если у вас есть доступ) и перезалейте рабочие или fallback артефакты.
Если проблема в повышенном использованием CPU/ RAM от выброса трафика, upscal'ите машины на кластере
Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена.
5️⃣ Если все разрешилось - продолжайте мониторить и составьте postmortem. В нем укажите
- Оцененный ущерб
- Проанализируйте причину, почему так произошло
- Укажите ваши действия, и в какие сроки вы их предприняли
Что делают в это время менеджеры и аналитики?
- помогают связаться со стейкхолдерами (чтобы те были в курсе происходящего и могли со своей стороны что-то сделать - например, включить fallback) или нужными командами разработки
- смотрят на метрики и помогают оценить ущерб и в целом состояние приложения
- помогают эскалировать в нужную команду
Также рекомендую хорошую статью, как поднимают упавший прод на Ozon'е
Telegram
ML Advertising
Как подготовиться к инциденту на проде, чтобы разрешить его как батя?
Если в вашей компании есть высоконагруженные сервисы, то наверняка вы уже сталкивались с инцидентами: когда происходят выбросы входного трафика, ошибок 500, зомби инстансами серверов,…
Если в вашей компании есть высоконагруженные сервисы, то наверняка вы уже сталкивались с инцидентами: когда происходят выбросы входного трафика, ошибок 500, зомби инстансами серверов,…
Forwarded from IT analysis • Системный и бизнес анализ
Webhook, Websocket и SSE
Продолжаем тему интеграций, сегодня рассмотрим 3 механизма для передачи данных: Websocket, Webhook и SSE.
Из карточек вы узнаете: принцип работы каждой технологии, плюсы и минусы, а также в каких задачах применяется эти технологии.
Изучайте новое и не забывайте отдыхать. Всем хороших выходных 🏖
Кстати, на 1000 подписчиков будет розыгрыш небольшого подарка (+1 повод пригласить друзей подписаться) 😊
Продолжаем тему интеграций, сегодня рассмотрим 3 механизма для передачи данных: Websocket, Webhook и SSE.
Из карточек вы узнаете: принцип работы каждой технологии, плюсы и минусы, а также в каких задачах применяется эти технологии.
Изучайте новое и не забывайте отдыхать. Всем хороших выходных 🏖
Forwarded from Клуб CDO
Полезная статья, вынесу пожалуй в отдельный пост
https://habr.com/ru/companies/piter/articles/853400/?utm_source=habrahabr&utm_medium=rss&utm_campaign=853400
https://habr.com/ru/companies/piter/articles/853400/?utm_source=habrahabr&utm_medium=rss&utm_campaign=853400
Хабр
Какую архитектуру конвейера данных следует использовать?
Здесь представлен обзор архитектур конвейеров данных, которые вы можете использовать сегодня. Данные важны для любого приложения и нужны для разработки эффективных конвейеров для доставки и управления...