Forwarded from ML for Value / Ваня Максимов
NeoBERT: апгрейд классики в 2025г
Пока мы все следим за новыми GenAI LLM-ками, вышла действительно годная LLM - NeoBERT
Авторы статьи утверждают, что это новая SOTA на длинных последовательностях
- 2.8 TB данных для обучения - почти в 20 раз больше, чем в RoBERTa
- Длина последовательности до 4096 через RoPE
- Куча современных трюков в архитектуре: SwiGLU, Pre-RMSNorm, AdamW, ...)
Если внимательно почитать, то все конечно не так однозначно:
В классе small в топе все еще RoBERTa
В medium классе (~250M параметров) NeoBERT и правда бьет все другие модели. При этом он все еще достаточно быстр в инференсе на коротких последовательностях, и существенно быстрее аналогов на длинных. Выглядит как заявочка на новую default model в классическом NLP весто RoBERTa
При этом если у вас есть мощности и время на инференс, то DeBERTa V3 Large (350+ M параметров) все еще в топе на большинстве бенчмарков. Хотя на MTEB новый NeoBERT ее уже обходит
В общем, авторы аккуратно применили последние достижения в нейроночках - получили приличный результат. С чем их и поздравляем!) Ну и не забывайте теперь пробовать кое-что еще вместо стандартных RoBERTa в классических NLP задачах 🧐
Пока мы все следим за новыми GenAI LLM-ками, вышла действительно годная LLM - NeoBERT
Авторы статьи утверждают, что это новая SOTA на длинных последовательностях
- 2.8 TB данных для обучения - почти в 20 раз больше, чем в RoBERTa
- Длина последовательности до 4096 через RoPE
- Куча современных трюков в архитектуре: SwiGLU, Pre-RMSNorm, AdamW, ...)
Если внимательно почитать, то все конечно не так однозначно:
В классе small в топе все еще RoBERTa
В medium классе (~250M параметров) NeoBERT и правда бьет все другие модели. При этом он все еще достаточно быстр в инференсе на коротких последовательностях, и существенно быстрее аналогов на длинных. Выглядит как заявочка на новую default model в классическом NLP весто RoBERTa
При этом если у вас есть мощности и время на инференс, то DeBERTa V3 Large (350+ M параметров) все еще в топе на большинстве бенчмарков. Хотя на MTEB новый NeoBERT ее уже обходит
В общем, авторы аккуратно применили последние достижения в нейроночках - получили приличный результат. С чем их и поздравляем!) Ну и не забывайте теперь пробовать кое-что еще вместо стандартных RoBERTa в классических NLP задачах 🧐
Forwarded from Quant Valerian
👌 НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ (НОРМИНГ)
• На стадии нормализации происходит каскад изменений.
• Конфликты помогают людям успокоиться и рационализировать мышление.
• Группа перестраивается, изгоняет проблемных участников и пересматривает цели.
Риски и задачи этапа нормализации
• Группа может разойтись, если не договорится по новым целям и ролям.
• Важно найти решение производственных проблем.
• Управление этапом нормализации включает сохранение группы, реорганизацию и оптимизацию.
⭐️ РЕКОМЕНДАЦИИ НОРМИНГ
• Выяснить индивидуальные потребности участников.
• Призывать к сотрудничеству и объяснять, что успех возможен только совместными усилиями.
• Работать сначала со всей группой, затем уточнять договоренности индивидуально.
Мотивация и возвращение участников
• Мотивация определяется наличием потребности, возможности её удовлетворить и отсутствием препятствий.
• Вернуть ушедших участников, выяснив причины ухода и показав, что их потребности будут удовлетворены.
• Вовлекать участников в процесс преобразований и обучения навыкам конструктивных взаимодействий.
Роль руководителя
• Руководитель должен быть модератором, направляющим и структурирующим обсуждения.
• Обучать людей навыкам конструктивных взаимодействий и открытой коммуникации.
• Успех зависит от умения руководителя организовывать и модерировать групповые обсуждения.
• На стадии нормализации происходит каскад изменений.
• Конфликты помогают людям успокоиться и рационализировать мышление.
• Группа перестраивается, изгоняет проблемных участников и пересматривает цели.
Риски и задачи этапа нормализации
• Группа может разойтись, если не договорится по новым целям и ролям.
• Важно найти решение производственных проблем.
• Управление этапом нормализации включает сохранение группы, реорганизацию и оптимизацию.
⭐️ РЕКОМЕНДАЦИИ НОРМИНГ
• Выяснить индивидуальные потребности участников.
• Призывать к сотрудничеству и объяснять, что успех возможен только совместными усилиями.
• Работать сначала со всей группой, затем уточнять договоренности индивидуально.
Мотивация и возвращение участников
• Мотивация определяется наличием потребности, возможности её удовлетворить и отсутствием препятствий.
• Вернуть ушедших участников, выяснив причины ухода и показав, что их потребности будут удовлетворены.
• Вовлекать участников в процесс преобразований и обучения навыкам конструктивных взаимодействий.
Роль руководителя
• Руководитель должен быть модератором, направляющим и структурирующим обсуждения.
• Обучать людей навыкам конструктивных взаимодействий и открытой коммуникации.
• Успех зависит от умения руководителя организовывать и модерировать групповые обсуждения.
Forwarded from Quant Valerian
💪 СТАДИЯ КОМАНДНОЙ РАБОТЫ (ПЕРФОРМИНГ)
• Восстановление производительности и улучшение настроения участников.
• Участники осознают ценность друг друга и становятся настоящей командой.
⭐️ РЕКОМЕНДАЦИИ ПЕРФОРМИНГ
Получать удовольствие от работы, обращать внимание на успехи и благодарить друг друга.
🔚 ФИНАЛЬНАЯ СТАДИЯ (РАСПАД)
• Завершение работы, фиксация результатов и получение заслуженного вознаграждения.
• В современном командообразовании стадия расставания менее актуальна.
• Используется концепция рефлексии и перехода для поддержания командной работы.
Изменения в команде
• Со временем в команде могут накапливаться изменения в мировоззрении, мотивах и привычках.
• Это может привести к новому кризису, но с меньшим риском развала группы.
• Важно контролировать процесс, чтобы избежать полного развала.
• Восстановление производительности и улучшение настроения участников.
• Участники осознают ценность друг друга и становятся настоящей командой.
⭐️ РЕКОМЕНДАЦИИ ПЕРФОРМИНГ
Получать удовольствие от работы, обращать внимание на успехи и благодарить друг друга.
🔚 ФИНАЛЬНАЯ СТАДИЯ (РАСПАД)
• Завершение работы, фиксация результатов и получение заслуженного вознаграждения.
• В современном командообразовании стадия расставания менее актуальна.
• Используется концепция рефлексии и перехода для поддержания командной работы.
Изменения в команде
• Со временем в команде могут накапливаться изменения в мировоззрении, мотивах и привычках.
• Это может привести к новому кризису, но с меньшим риском развала группы.
• Важно контролировать процесс, чтобы избежать полного развала.
Forwarded from Quant Valerian
Как пройти систем дизайн?
Все материалы для подготовки к систем дизайнам я запостил в пятничном пыльном чулане. Но что происходит на реальных собесах?
Я провел несколько десятков систем дизайнов, а сейчас прохожу обучение на "илитную архитектуру" (надеюсь, меня возьмут в круг избранных), поэтому у меня есть сформировавшееся мнение.
Мы даём задачку, сформулированную очень размыто. Но там обязательно будет какой-то челлендж от размера: большая нагрузка, много данных, много интерферирующих сценариев и т.п.
Здесь ожидается, что кандидат выяснит, что вообще надо сделать. Поспрашивает, сколько пользователей, продемонстрирует back of the envelope computation skills. Sori za moj ingliš. Это показывает наличие какой-то насмотренности на хай лоад, кроме того, некоторые кандидаты здесь начинают плыть между битами, байтами, мегбитами и мегабайтами, сколько там байтов в инте и флоте... Плохой знак.
Потом моя персональная рекомендация: разработайте API. Его можно потом доделать, но продумывание каких-то основ функционирования системы происходит именно в этот момент. Обычно всем пофиг на rest vs grpc vs graphql, я бы не тратил на это время. Но желательно что-то выбрать, озвучить и оформить API в _едином_ озвученном стиле.
И не забывать про response!
Дальше нужно выдать минимально рабочую схему. Вообще рассказать, как это сделать в гараже на коленке, но чтобы работало на 1 rps.
Это супер важный шаг, потому что если есть рабочее решение, это уже много баллов в копилку результата интервью. Только с такой схемой на руках может начаться _настоящая_проверка_ на сильного инженера.
Когда кандидат понимает профиль нагрузки, схему API и функциональное устройство системы, он может находить проблемы, с которыми столкнется текущая конфигурация при эксплуатации. Где-то слишком большой рейт на запись, где-то тяжелые запросы на чтение. Нужно указать на эти проблемы и полечить их. Тут же, имхо, стоит подумать об отказоустойчивости. Рассказать, что будет при отказе той или иной части.
Дальше мы ждём, что кандидат подумает о каких-то крайних случаях. На самом деле есть какие-то стандартные кейсы типа супер популярный ивент, человек и т.п. или супер массовый подписчик. Т.е. объект, который все хотят прочитать и объект, который хочет прочитать всех. Чем больше таких штук кандидат найдет и починит, тем лучше впечатление останется.
От расчёта железа решили, все-таки отказаться. Хотя были кандидаты, которые это успевали.
В сухом остатке, систем дизайн нацелен на выявление синьор и стафф+ инженеров. Поэтому в основном смотрим на насмотренность и набитость руки при решении задач: выбор схем, технологий, поиск и починка типичных проблемных мест, отказоустойчивость, перфоманс. Оценивается это всё достаточно формально, но секреты фокусники не раскрывают! А как и почему устроены такие секции я вам рассказал.
P.S.:
есть отдельный трек таких интервью для технических менеджеров и продактов, про него могу отдельно прокомментировать, если вам интересно будет
Все материалы для подготовки к систем дизайнам я запостил в пятничном пыльном чулане. Но что происходит на реальных собесах?
Я провел несколько десятков систем дизайнов, а сейчас прохожу обучение на "илитную архитектуру" (надеюсь, меня возьмут в круг избранных), поэтому у меня есть сформировавшееся мнение.
Мы даём задачку, сформулированную очень размыто. Но там обязательно будет какой-то челлендж от размера: большая нагрузка, много данных, много интерферирующих сценариев и т.п.
Здесь ожидается, что кандидат выяснит, что вообще надо сделать. Поспрашивает, сколько пользователей, продемонстрирует back of the envelope computation skills. Sori za moj ingliš. Это показывает наличие какой-то насмотренности на хай лоад, кроме того, некоторые кандидаты здесь начинают плыть между битами, байтами, мегбитами и мегабайтами, сколько там байтов в инте и флоте... Плохой знак.
Потом моя персональная рекомендация: разработайте API. Его можно потом доделать, но продумывание каких-то основ функционирования системы происходит именно в этот момент. Обычно всем пофиг на rest vs grpc vs graphql, я бы не тратил на это время. Но желательно что-то выбрать, озвучить и оформить API в _едином_ озвученном стиле.
И не забывать про response!
Дальше нужно выдать минимально рабочую схему. Вообще рассказать, как это сделать в гараже на коленке, но чтобы работало на 1 rps.
Это супер важный шаг, потому что если есть рабочее решение, это уже много баллов в копилку результата интервью. Только с такой схемой на руках может начаться _настоящая_проверка_ на сильного инженера.
Когда кандидат понимает профиль нагрузки, схему API и функциональное устройство системы, он может находить проблемы, с которыми столкнется текущая конфигурация при эксплуатации. Где-то слишком большой рейт на запись, где-то тяжелые запросы на чтение. Нужно указать на эти проблемы и полечить их. Тут же, имхо, стоит подумать об отказоустойчивости. Рассказать, что будет при отказе той или иной части.
Дальше мы ждём, что кандидат подумает о каких-то крайних случаях. На самом деле есть какие-то стандартные кейсы типа супер популярный ивент, человек и т.п. или супер массовый подписчик. Т.е. объект, который все хотят прочитать и объект, который хочет прочитать всех. Чем больше таких штук кандидат найдет и починит, тем лучше впечатление останется.
От расчёта железа решили, все-таки отказаться. Хотя были кандидаты, которые это успевали.
В сухом остатке, систем дизайн нацелен на выявление синьор и стафф+ инженеров. Поэтому в основном смотрим на насмотренность и набитость руки при решении задач: выбор схем, технологий, поиск и починка типичных проблемных мест, отказоустойчивость, перфоманс. Оценивается это всё достаточно формально, но секреты фокусники не раскрывают! А как и почему устроены такие секции я вам рассказал.
P.S.:
есть отдельный трек таких интервью для технических менеджеров и продактов, про него могу отдельно прокомментировать, если вам интересно будет
Telegram
Quant Valerian
Пятничная рубрика "Пыльный чулан"
Вообще должен был быть юбилей с достижением мной пятидесяти проведенных архитектурных секций, но кандидаты посливались в последний момент.
Но это не повод оставить вас без поста с полезняхами! Вспоминаем всё полезное для…
Вообще должен был быть юбилей с достижением мной пятидесяти проведенных архитектурных секций, но кандидаты посливались в последний момент.
Но это не повод оставить вас без поста с полезняхами! Вспоминаем всё полезное для…
Forwarded from adapt compete evolve or die
image_2025-03-24_19-45-28.png
116.2 KB
Прочитал решение первого места с Lux AI
1000 фичей на каждый тайл 24*24 карты! большая часть бинарных, около 100 числовых. фичи в основном про историю того, что видели на данной клетке в прошлом, как давно это было и так далее.
Архитектура очень нетривиальная, мне нравится. Две головы, где одна отвечает за предсказание действие всех агентов и своих и вражеских и одна для предсказания атакующих действий.
ConvLSTM для учета предыдущих действий и трансформер поверх - это забавно, позволяет держать трансформер маленьким, не запихивая в него энкоды предыдущих шагов.
Не использовали Behavior Cloning как многие в топе в финальном решении и его обучении.
Обучали IMPALA (асинхронные агенты RL) + V-trace (корректировка оценок для борьбы со смещениями из-за устаревших треков).
Мне понравились идеи:
* Играли против учителя (лучшей последней модели), текущей и еще пачки старых, чтобы избежать оверфита.
* KL с учителем, чтобы не терять приобретенные навыки
* динамические реворды: реворды могут прыгать, поэтому давайте заскейлим их на каждом шаге в определенный диапазон
* убывающие коэффициенты энтропии по мере обучения (тут я не до конца понял) что заставляет policy автоматически скейлиться по мере улучшения модели
* аугментации с флипами поля (вот они почему довольно симметрично играют сами с собой!)
* стратегия участия в сореве: не хотим чтобы нас копировали через imitation learning, поэтому выкладываем только слабые улучшения, а сильные играют только небольшое количество времени; поскольку противники обладают меньшей информацией - какая версия сильная, а какая слабая, то им сильно сложнее копировать
Что-то еще интересное упустил, наверное. Точно не смог бы по описанию повторить, дюже сложно.
RL работает👍
1000 фичей на каждый тайл 24*24 карты! большая часть бинарных, около 100 числовых. фичи в основном про историю того, что видели на данной клетке в прошлом, как давно это было и так далее.
Архитектура очень нетривиальная, мне нравится. Две головы, где одна отвечает за предсказание действие всех агентов и своих и вражеских и одна для предсказания атакующих действий.
ConvLSTM для учета предыдущих действий и трансформер поверх - это забавно, позволяет держать трансформер маленьким, не запихивая в него энкоды предыдущих шагов.
Не использовали Behavior Cloning как многие в топе в финальном решении и его обучении.
Обучали IMPALA (асинхронные агенты RL) + V-trace (корректировка оценок для борьбы со смещениями из-за устаревших треков).
Мне понравились идеи:
* Играли против учителя (лучшей последней модели), текущей и еще пачки старых, чтобы избежать оверфита.
* KL с учителем, чтобы не терять приобретенные навыки
* динамические реворды: реворды могут прыгать, поэтому давайте заскейлим их на каждом шаге в определенный диапазон
* убывающие коэффициенты энтропии по мере обучения (тут я не до конца понял) что заставляет policy автоматически скейлиться по мере улучшения модели
* аугментации с флипами поля (вот они почему довольно симметрично играют сами с собой!)
* стратегия участия в сореве: не хотим чтобы нас копировали через imitation learning, поэтому выкладываем только слабые улучшения, а сильные играют только небольшое количество времени; поскольку противники обладают меньшей информацией - какая версия сильная, а какая слабая, то им сильно сложнее копировать
Что-то еще интересное упустил, наверное. Точно не смог бы по описанию повторить, дюже сложно.
RL работает
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Диджитализируй!
Прочёл тут на досуге «PostgreSQL 17 QuickStart Pro» Tessa Vorin.
Сэкономлю вам время — не читайте это, какая-то странная петрушка, как набор повторяющихся статей. Должно быть, снова ChatGPT постарался.
Если вам интересно, что можно почитать по PostgreSQL:
— PostgreSQL. Основы языка SQL. Моргунов.
Отличная книга по SQL в реализации постгреса, и для новичков, и для тех, кто переходит с других БД. Если вы новичок и она покажется сложной, начните с другой книги — «SQL Быстрое погружение», Уолтер Шилдс.
— Изучаем PostgreSQL 10. Салахалдин Джуба, Андрей Волков.
Отличный материал по использованию PostgreSQL, балансирующий материал разных тем — здесь есть и SQL, причём некоторые показанные особенности были для меня неизвестны, есть и вопросы настройки производительности PostgreSQL, и вопросы масштабирования СУБД.
— PostgreSQL 11. Мастерство разработки. Ганс-Юрген Шёниг.
Материал не без огрехов, но мне был полезен. Описание индексов, транзакций и некоторых возможностей SQL, о которых до этой книги не знал.
— Оптимизация запросов в PostgreSQL. Домбровская Г., Новиков Б., Бейликова А.
Кайфовейшая книга, которую крайне рекомендую всем, кто использует PostgreSQL.
Если интересно, как внутри работает PostgreSQL, можно почитать «PostgreSQL 17 изнутри», Рогов Е. В. Для практической работы разработчика это не будет сильно полезно, но для админа или просто интересующегося — вполне.
И также могу рекомендовать полистать «Антипаттерны SQL», Билл Карвин.
А если хотите не только почитать, но и от души попрактиковаться, приходите на курс.
Сэкономлю вам время — не читайте это, какая-то странная петрушка, как набор повторяющихся статей. Должно быть, снова ChatGPT постарался.
Если вам интересно, что можно почитать по PostgreSQL:
— PostgreSQL. Основы языка SQL. Моргунов.
Отличная книга по SQL в реализации постгреса, и для новичков, и для тех, кто переходит с других БД. Если вы новичок и она покажется сложной, начните с другой книги — «SQL Быстрое погружение», Уолтер Шилдс.
— Изучаем PostgreSQL 10. Салахалдин Джуба, Андрей Волков.
Отличный материал по использованию PostgreSQL, балансирующий материал разных тем — здесь есть и SQL, причём некоторые показанные особенности были для меня неизвестны, есть и вопросы настройки производительности PostgreSQL, и вопросы масштабирования СУБД.
— PostgreSQL 11. Мастерство разработки. Ганс-Юрген Шёниг.
Материал не без огрехов, но мне был полезен. Описание индексов, транзакций и некоторых возможностей SQL, о которых до этой книги не знал.
— Оптимизация запросов в PostgreSQL. Домбровская Г., Новиков Б., Бейликова А.
Кайфовейшая книга, которую крайне рекомендую всем, кто использует PostgreSQL.
Если интересно, как внутри работает PostgreSQL, можно почитать «PostgreSQL 17 изнутри», Рогов Е. В. Для практической работы разработчика это не будет сильно полезно, но для админа или просто интересующегося — вполне.
И также могу рекомендовать полистать «Антипаттерны SQL», Билл Карвин.
А если хотите не только почитать, но и от души попрактиковаться, приходите на курс.
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Курсы технических лекций на ютубе
В последнее время нечасто приношу вам техническое, но в моих закромах и такое имеется. Вот решил с вами сегодня поделиться тремя плейлистами.
1. Курс от Т-Банка про SRE https://www.youtube.com/playlist?list=PLjCCarnDJNstX36A6Cw_YD28thNFev1op
Мониторинг, SLI, SLO, SLA, постмортемы, отказоустойчивость, тестирование, причины и устранение сбоев и всё подобное.
2. Курс лекций в МФТИ от Олега Бунина про хайлоад и систем дизайн https://www.youtube.com/playlist?list=PL4_hYwCyhAva6-f-YxobKju-6ltmn-jNC (утащил у товарища Quant Valerian)
Вся классика: сбор требований, кеши, очереди, репликация, шардирование и т.д.
3. Вечерняя школа Слёрм по Кубернетес https://www.youtube.com/playlist?list=PL8D2P0ruohOA4Y9LQoTttfSgsRwUGWpu6
Курс лекций старый, но когда-то он мне хорошо помог понять, что же в этих ваших кубернетесах происходит. Не готов отвечать за его 146% актуальность сегодняшнему дню. Если у вас есть про это мнение, то приходите, пожалуйста, в комменты и расскажите свои рекомендации.
В последнее время нечасто приношу вам техническое, но в моих закромах и такое имеется. Вот решил с вами сегодня поделиться тремя плейлистами.
1. Курс от Т-Банка про SRE https://www.youtube.com/playlist?list=PLjCCarnDJNstX36A6Cw_YD28thNFev1op
Мониторинг, SLI, SLO, SLA, постмортемы, отказоустойчивость, тестирование, причины и устранение сбоев и всё подобное.
2. Курс лекций в МФТИ от Олега Бунина про хайлоад и систем дизайн https://www.youtube.com/playlist?list=PL4_hYwCyhAva6-f-YxobKju-6ltmn-jNC (утащил у товарища Quant Valerian)
Вся классика: сбор требований, кеши, очереди, репликация, шардирование и т.д.
3. Вечерняя школа Слёрм по Кубернетес https://www.youtube.com/playlist?list=PL8D2P0ruohOA4Y9LQoTttfSgsRwUGWpu6
Курс лекций старый, но когда-то он мне хорошо помог понять, что же в этих ваших кубернетесах происходит. Не готов отвечать за его 146% актуальность сегодняшнему дню. Если у вас есть про это мнение, то приходите, пожалуйста, в комменты и расскажите свои рекомендации.
Forwarded from Находки в опенсорсе
wemake-python-styleguide@1.1.0
Вышла новая версия самого строго линтера для питона. Теперь еще строже!
Главная фича релиза:
А так же несколько новых правил:
-
-
Ну и много разных багов поправили, куда без них.
Полный список изменений: https://github.com/wemake-services/wemake-python-styleguide/releases/tag/1.1.0
Большое спасибо участникам нашего чата за PRы, они затащили релиз 🧡
Обсуждение: каких правил в wemake-python-styleguide вам не хватает? Какие душат вас сильнее всего? Что можно улучшить?
| Поддержать | YouTube | GitHub | Чат |
Вышла новая версия самого строго линтера для питона. Теперь еще строже!
Главная фича релиза:
wps explain CLI, которая позволяет видеть вывод информации: почему что-то запрещено, и как такое исправить.А так же несколько новых правил:
-
WPS476 не дает использовать await в for (потому что вы скорее всего хотите использовать asyncio.gather, чтобы добиться асинхронности)-
WPS477 запрещает сложную комбинацию TypeVarTuple рядом с TypeVar с дефолтным значением: class Class[T=int, *Ts=*tuple[int, ...]]:Ну и много разных багов поправили, куда без них.
Полный список изменений: https://github.com/wemake-services/wemake-python-styleguide/releases/tag/1.1.0
Большое спасибо участникам нашего чата за PRы, они затащили релиз 🧡
Обсуждение: каких правил в wemake-python-styleguide вам не хватает? Какие душат вас сильнее всего? Что можно улучшить?
| Поддержать | YouTube | GitHub | Чат |
Forwarded from Душный NLP
Метод борьбы с likelihood displacement в DPO
Датасет для Direct Preference Optimization (DPO) состоит из инструкции, а также двух ответов: негативного — его хотим разучить — и позитивного, который мы хотим чаще получать. Likelihood displacement — это явление, при котором модель разучивает оба варианта. О методе преодоления этой проблемы сегодняшняя статья.
В своей работе авторы использовали датасет Persona, промпты в котором сформулированны как вопросы вида «Мог бы ты сказать следующее:...» (“Is the following statement something you would say? [STATEMENT]”). То есть модели нужно было согласиться или не согласиться с утверждением, ответив «да», «нет», «никогда» или «возможно». Эксперименты показали, что при попытках научить модель отвечать отрицательно, но не категорично («никогда» считался негативным вариантом на DPO, а «нет» — позитивным), вероятность токена «да» становится больше вероятности «нет». Подобное происходит только тогда, когда оба типа ответов похожи (изображение 1).
Авторы считают, что likelihood displacement происходит из-за анэмбеддинг-геометрии токенов. Анэмбеддинг-матрица позитивного и негативного токенов — разница между Wy+ и Wy- — содержит в себе большую компоненту, ортогональную позитивному ответу, по которой можно выучить даже противоположный ответ.
Справиться с этой проблемой авторы предлагают с помощью метрики для оценки похожих ответов. Чтобы её вывести, нужно взять суммы эмбеддингов всех токенов в позитивном ответе и негативном ответе, посчитать их скалярное произведение, а затем вычесть норму позитивного ответа. Эта метрика зависит от длины ответов, поэтому авторы предлагают делить скалярное произведение на произведение длин позитивных и негативных ответов, а норму — на квадрат длины позитивных ответов (изображение 2).
С помощью метрики, которую назвали centered hidden embedding similarity (CHES), отфильтровали выборку ответов из датасета. Для эксперимента использовали SORRY-bench, призванный научить модель отказывать пользователю в исполнении неэтичных, токсичных или преступных запросов. Использование CHES показало хорошие результаты (голубой столбец на графике), однако после фильтрации в выборке осталось всего 5% сэмплов. Кроме того, модели в сравнении обучались не одинаковое количество шагов, что могло повлиять на результаты тестов.
Разбор подготовил❣ Карим Галлямов
Душный NLP
Датасет для Direct Preference Optimization (DPO) состоит из инструкции, а также двух ответов: негативного — его хотим разучить — и позитивного, который мы хотим чаще получать. Likelihood displacement — это явление, при котором модель разучивает оба варианта. О методе преодоления этой проблемы сегодняшняя статья.
В своей работе авторы использовали датасет Persona, промпты в котором сформулированны как вопросы вида «Мог бы ты сказать следующее:...» (“Is the following statement something you would say? [STATEMENT]”). То есть модели нужно было согласиться или не согласиться с утверждением, ответив «да», «нет», «никогда» или «возможно». Эксперименты показали, что при попытках научить модель отвечать отрицательно, но не категорично («никогда» считался негативным вариантом на DPO, а «нет» — позитивным), вероятность токена «да» становится больше вероятности «нет». Подобное происходит только тогда, когда оба типа ответов похожи (изображение 1).
Авторы считают, что likelihood displacement происходит из-за анэмбеддинг-геометрии токенов. Анэмбеддинг-матрица позитивного и негативного токенов — разница между Wy+ и Wy- — содержит в себе большую компоненту, ортогональную позитивному ответу, по которой можно выучить даже противоположный ответ.
Справиться с этой проблемой авторы предлагают с помощью метрики для оценки похожих ответов. Чтобы её вывести, нужно взять суммы эмбеддингов всех токенов в позитивном ответе и негативном ответе, посчитать их скалярное произведение, а затем вычесть норму позитивного ответа. Эта метрика зависит от длины ответов, поэтому авторы предлагают делить скалярное произведение на произведение длин позитивных и негативных ответов, а норму — на квадрат длины позитивных ответов (изображение 2).
С помощью метрики, которую назвали centered hidden embedding similarity (CHES), отфильтровали выборку ответов из датасета. Для эксперимента использовали SORRY-bench, призванный научить модель отказывать пользователю в исполнении неэтичных, токсичных или преступных запросов. Использование CHES показало хорошие результаты (голубой столбец на графике), однако после фильтрации в выборке осталось всего 5% сэмплов. Кроме того, модели в сравнении обучались не одинаковое количество шагов, что могло повлиять на результаты тестов.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM