Forwarded from Information Retriever
Статья на Хабре про индустриальные тренды рексистем.
В мае я выступал на датафесте с докладом про тренды рексистем, а сейчас появился пост на Хабре, где мы подробнее расписали содержимое доклада, приложили ссылки на статьи, добавили больше пояснений.
Ссылка — https://habr.com/ru/companies/yandex/articles/857068/
В мае я выступал на датафесте с докладом про тренды рексистем, а сейчас появился пост на Хабре, где мы подробнее расписали содержимое доклада, приложили ссылки на статьи, добавили больше пояснений.
Ссылка — https://habr.com/ru/companies/yandex/articles/857068/
Хабр
ML-тренды рекомендательных технологий: шесть приёмов, которые помогают угадывать желания пользователя
Главная задача рекомендательной системы — предоставить пользователю контент, фильм, трек, книгу, товар или информацию, которые могут заинтересовать его в данный момент. Сложность...
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Учел ваши пожелания и собрал все посты по теме многозадачности и производительности в один пост. Приятного чтения, дальше больше, это еще далеко не конец😊
🔹Многозадачность на уровне железа и OS / Kernel Space
1. Многозадачность в OS. Введение.
2. Процессор и его роль в многозадачности
2.1. Про Hyper Threading
3. Процессы. Начало
4. Процессы в Linux
5. Потоки. Начало
6. Потоки в Linux
7. Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
8. Multiplexed IO
9. Asynchronous IO
🔹Легковесные потоки в User Space / Многозадачность в языках программирования
10. Fibers. Виды многозадачности с примерами в языках программирования.
11. Сравнительный обзор двух видов многозадачности
🔹Многозадачность на уровне железа и OS / Kernel Space
1. Многозадачность в OS. Введение.
2. Процессор и его роль в многозадачности
2.1. Про Hyper Threading
3. Процессы. Начало
4. Процессы в Linux
5. Потоки. Начало
6. Потоки в Linux
7. Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
8. Multiplexed IO
9. Asynchronous IO
🔹Легковесные потоки в User Space / Многозадачность в языках программирования
10. Fibers. Виды многозадачности с примерами в языках программирования.
11. Сравнительный обзор двух видов многозадачности
Forwarded from Записки MLEшника
Forwarded from Data, Stories and Languages
Говорят, что достали системный промпт Advanced Voice Mode
https://www.reddit.com/r/OpenAI/comments/1fp1fes/the_system_prompt_of_advanced_voice_mode_it_can/
https://www.reddit.com/r/OpenAI/comments/1fp1fes/the_system_prompt_of_advanced_voice_mode_it_can/
Forwarded from Small Data Science for Russian Adventurers
#книга
Онлайн-учебник по машинному и глубокому обучению от преподавателя ВМК МГУ Виктора Китова
https://deepmachinelearning.ru/
Онлайн-учебник по машинному и глубокому обучению от преподавателя ВМК МГУ Виктора Китова
https://deepmachinelearning.ru/
Forwarded from Николай Хитров | Блог
Статья Быстрее пули: как найти счастье с PostgreSQL
Большая классная статья про поиск в
В статье автор рассказывает про:
👉
👉 нормализацию слов и морфологию
👉 словари синонимов
👉 ранжирование результатов по релевантности
https://habr.com/ru/companies/rostelecom/articles/853124/
Большая классная статья про поиск в
postgresql. На мой взгляд отлично подходит для ситуаций, когда по каким-то причинам еще не хочется (или не можется) завезти отдельную колоночную БД для поиска по типу elasticsearch, но простого WHERE ILIKE уже не хватает.В статье автор рассказывает про:
👉
tsvector, tsquery и GIN индексы👉 нормализацию слов и морфологию
👉 словари синонимов
👉 ранжирование результатов по релевантности
https://habr.com/ru/companies/rostelecom/articles/853124/
Хабр
Быстрее пули: как найти счастье с PostgreSQL
Введение Полнотекстовый поиск — это неотъемлемая часть современных приложений, особенно тех, которые работают с большими объемами текстовой информации, будь то блог-платформы, системы управления...
Forwarded from DziS Science | Data Science
Привет всем!👋
Про эффективность созвонов.
Только ленивый в DS не ругался касаемо количества бесполезных созвонов.
Вроде бы у тебя есть задача, дедлайн не завтра, но количество встреч, притом посреди рабочего дня только с получасовым перерывом на обед раздражают даже самого спокойного сотрудника.
Нередко, даже в чатах с вакансиями в качестве плюса указывают маленькое количество созвонов в течение рабочей недели.
-Но почему так?
Дело в том, что созвоны в рамках любой схемы «эффективного» рабочего процесса это неотъемлемая часть, но нередко мы страдаем из-за злоупотребления данным инструментом.
🔸 Прежде чем ответить себе на вопрос, эффективный ли созвон, на котором я нахожусь, надо понять, что это инструмент решения конкретной задачи и понять, а решает ли этот созвон что-то решает или помогает решить ее эффективно?
Нередко, именно на этом вопросе можно заканчивать половину созвонов.
Если ответ невнятный, то можно поблагодарить коллег и попросить прислать статус по почте.
Это кстати второй тезис для понимания, а эффективен ли созвон.
🔵 Если проблема, решаемая данным инструментом, может быть исчерпана одним коротким письмом, то данный созвон явно не эффективен.
🔹 Созвон содержит слишком много людей. Если вам нужен конкретный человек из другого подразделения, то не всегда нужно звать всех 40 специалистов из его подразделения. Достаточно позвать конкретного и, максимум, его руководителя. Объективно, 38 оставшихся сотрудников будут сидеть без дела.
🔸 Однако и тут, важен тайминг. Представьте ситуацию: у вас с подчинении n людей и вам нужно собрать краткий статус по задачам. Из практики, лучше собрать n людей на 30 минут, чем n*30 минут провести на персональных встречах 1 на 1. Результат будет одинаковый, но времени потратите на пару часов меньше. Если нужно, поставьте дополнительную встречу.
Эта проблема, кстати, настигала меня совсем недавно. Я делал статусы по отдельным направлениям, хотя ни один из них не выбивался за 30 минутный тайминг. Получилось, что всех и все можно собрать в полчаса.
Обычно формула простая: на каждых новых 4 человек добавляется во встрече 30 минут. Но не более 1 часа, дальше теряется внимание, проверено на опыте. Т.е за одну встречу вы эффективно можете узнать как дела по работе, не более чем у 8х. Это лично наблюдение.
🔸 Обязательно должна быть встреча 1 на 1 по нерабочим процессам, хотя бы раз в месяц.
Таким образом, я выработал некоторый чек лист:
1️⃣ . Встреча должна решать проблему!
2️⃣ . У нее должна быть цель, повестка или структура.
3️⃣ . Встреча больше часа - зло. Исключение - увеселительная встреча с пиццей.
4️⃣ . Встреча на кучу людей, в т.ч не относящихся к проблеме - зло.
5️⃣ . Можно решить проблему по переписке - не ставьте созвон.
6️⃣ . Можно собрать кучу встреч в одну? - собирайте. Лучше потом поставить одну лишнюю, но нужную, чем ставить регулярно кучу.
7️⃣ . Встреча 1 на 1 не рабочая должна быть, хотя бы раз в 1 месяц. Если нет или это очередной дейлик - плохо.
8️⃣ . Какой-то менеджер ставит вам по поводу и без встречи, не стесняйтесь, игнорируйте.
9️⃣ . Встреча, на которой вас позвали «за компанию» - бесполезная. Исключение - общие регулярные встречи на всех сотрудников, например демо или общеновостная.
Следуя этим правилам, я разгрузился сам и разгрузил свою команду. Теперь даже время что-то полезное сделать есть.
А то смотрю я на 2-3 встречи на всех каждый день, аж плакать хочется. Славу богу, что у меня не так😂
А как у вас с этим в компании? Пишите в комменты⬇️
#статьи #трудовые_будни
Про эффективность созвонов.
Только ленивый в DS не ругался касаемо количества бесполезных созвонов.
Вроде бы у тебя есть задача, дедлайн не завтра, но количество встреч, притом посреди рабочего дня только с получасовым перерывом на обед раздражают даже самого спокойного сотрудника.
Нередко, даже в чатах с вакансиями в качестве плюса указывают маленькое количество созвонов в течение рабочей недели.
-Но почему так?
Дело в том, что созвоны в рамках любой схемы «эффективного» рабочего процесса это неотъемлемая часть, но нередко мы страдаем из-за злоупотребления данным инструментом.
Нередко, именно на этом вопросе можно заканчивать половину созвонов.
«Коллеги, а какая повестка созвона? А есть ли она вообще?»
Если ответ невнятный, то можно поблагодарить коллег и попросить прислать статус по почте.
Это кстати второй тезис для понимания, а эффективен ли созвон.
Нередко, особенно начинающие руководители, делают очень интересный трюк. На любой вопрос, на который даже можно ответить «да/нет» руководитель может поставить аж полуторачасовую(‼️) встречу, где будет рассказывать все, но не то, что надо. Потом с полной уверенностью в своей эффективности будет рассказывать всем, что целый день занят важными созвонами.
К сожалению, такой персонаж сильно заблуждается. Он лишь отлынивает от работы.
Эта проблема, кстати, настигала меня совсем недавно. Я делал статусы по отдельным направлениям, хотя ни один из них не выбивался за 30 минутный тайминг. Получилось, что всех и все можно собрать в полчаса.
Обычно формула простая: на каждых новых 4 человек добавляется во встрече 30 минут. Но не более 1 часа, дальше теряется внимание, проверено на опыте. Т.е за одну встречу вы эффективно можете узнать как дела по работе, не более чем у 8х. Это лично наблюдение.
А то как вам говорить, что у вас на руках есть оффер или вам все не нравится?
Таким образом, я выработал некоторый чек лист:
Следуя этим правилам, я разгрузился сам и разгрузил свою команду. Теперь даже время что-то полезное сделать есть.
А то смотрю я на 2-3 встречи на всех каждый день, аж плакать хочется. Славу богу, что у меня не так😂
А как у вас с этим в компании? Пишите в комменты
#статьи #трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Start Career in DS
ℹ️ Всё про токенизацию и токенизаторы в языковых моделях
❕Токен - это минимальная единица текста, с которой работают современные языковые модели. В качестве токена могут выступать как полноценные слова, так и части слов, слоги или отдельные символы.
✂️ Например, в некоторых моделях слово «привет» может разбиваться на токены: [«при», «вет»].
❕Токенизация — процесс предобработки входного текста в список токенов. Обычно далее каждый токен векторизуется и весь этот массив векторов подаётся модели на вход, с чем она начинает работать.
🤯 В моделях Transformer токенизаторы обучаемы. Обучение токенизаторов не схоже с тем, как обучаются ML-модели, наоборот, это статистический процесс, который определяет, какие сочетания символов (подслов, слов) лучше всего выбрать для корпуса текста, с которым мы работаем.
🔝Современные токенизаторы можно разделить по следующим видам:
1. Byte-Pair Encoding (используется в GPT-like моделях, обучается слиянием символов из основного корпуса, выбирая пары по наибольшей частоте встречаемости, подробно про алгоритм и реализацию кода обучения читайте тут)
2. WordPiece (используется преимущественно в BERT-like моделях, также обучается слиянием, но используется не частота встречаемости, а более универсальная формула, также подробно читайте про реализацию и формулу тут)
3. Unigram (не так применим, однако, для полноты картины читайте о нем тут)
❗️Почему это важно:
1️⃣ Фертильность (мера, показывающая среднее количество токенов на одно слово после токенизации предложения):
Напрямую влияет на стоимость использования любой модели: больше токенов после токенизации предложения -> больше входная последовательность в LLM -> больше стоимость.
2️⃣ Качество работы:
Правильно токенизированная последовательность также сильно влияет на качество модели из-за появления символов, которых модель не видела или из-за особенностей некоторых языков, где нет, например, пробелов.
Очень грамотно и подробно этот нюанс описан тут.
3️⃣ Скорость работы:
Следствие из первого пункта: чем больше последовательность токенов, тем больше вычислений стоит делать, что также влияет на скорость ответа модели.
🔥 Дополнительная информация по теме:
- Краткий обзор токенизаторов на Хабре
- О токенизаторах с NLP-курса на Hugging Face
- «Насколько хорош Ваш Токенайзер» - статья на arxiv [ENG]
- Статья на английском для начинающих о токенах в LLM [ENG]
Теперь вы знаете, как работают токенизаторы🔥
Ждём ваших лайков и обратной связи❤️
До встречи👋🏻
❕Токен - это минимальная единица текста, с которой работают современные языковые модели. В качестве токена могут выступать как полноценные слова, так и части слов, слоги или отдельные символы.
✂️ Например, в некоторых моделях слово «привет» может разбиваться на токены: [«при», «вет»].
❕Токенизация — процесс предобработки входного текста в список токенов. Обычно далее каждый токен векторизуется и весь этот массив векторов подаётся модели на вход, с чем она начинает работать.
🤯 В моделях Transformer токенизаторы обучаемы. Обучение токенизаторов не схоже с тем, как обучаются ML-модели, наоборот, это статистический процесс, который определяет, какие сочетания символов (подслов, слов) лучше всего выбрать для корпуса текста, с которым мы работаем.
🔝Современные токенизаторы можно разделить по следующим видам:
1. Byte-Pair Encoding (используется в GPT-like моделях, обучается слиянием символов из основного корпуса, выбирая пары по наибольшей частоте встречаемости, подробно про алгоритм и реализацию кода обучения читайте тут)
2. WordPiece (используется преимущественно в BERT-like моделях, также обучается слиянием, но используется не частота встречаемости, а более универсальная формула, также подробно читайте про реализацию и формулу тут)
3. Unigram (не так применим, однако, для полноты картины читайте о нем тут)
❗️Почему это важно:
1️⃣ Фертильность (мера, показывающая среднее количество токенов на одно слово после токенизации предложения):
Напрямую влияет на стоимость использования любой модели: больше токенов после токенизации предложения -> больше входная последовательность в LLM -> больше стоимость.
2️⃣ Качество работы:
Правильно токенизированная последовательность также сильно влияет на качество модели из-за появления символов, которых модель не видела или из-за особенностей некоторых языков, где нет, например, пробелов.
Очень грамотно и подробно этот нюанс описан тут.
3️⃣ Скорость работы:
Следствие из первого пункта: чем больше последовательность токенов, тем больше вычислений стоит делать, что также влияет на скорость ответа модели.
🔥 Дополнительная информация по теме:
- Краткий обзор токенизаторов на Хабре
- О токенизаторах с NLP-курса на Hugging Face
- «Насколько хорош Ваш Токенайзер» - статья на arxiv [ENG]
- Статья на английском для начинающих о токенах в LLM [ENG]
Теперь вы знаете, как работают токенизаторы🔥
Ждём ваших лайков и обратной связи❤️
До встречи👋🏻
Forwarded from Душный NLP
WARM — метод улучшения reward-моделей
Сегодняшняя статья — о методе усреднения весов reward-модели для устранения проблем, связанных с RL-обучением. Но для начала напомним, как работает Reward-модель.
На вход она принимает промпты и ответы, а на выход выдаёт скаляры. По ним возможно ранжировать ответы от лучшего к худшему. Всё это делается с помощью обучения на минимизацию лосса, который вытекает из модели Брэдли-Терри. Как правило, reward-модели обучаются на датасете из преференсных данных — то есть таких, в которых ответы уже размечены асессорами или другой моделью.
Есть ряд проблем, с которыми можно столкнуться во время обучения reward-модели. Во-первых, разметка может оказаться достаточно шумной — например, при расхождениях в оценках одного и того же ответа разными асессорами. Кроме того, в некоторых случаях политика может генерировать OOD-ответы для выбранной reward-модели.
Наконец, возможно и такое, что reward-модель выучится на какой-то черте данных — например, особенностях оформления. При этом на файнтюнинге модель научится генерировать те ответы, которые будут давать высокий скор именно из-за этой особенности, а не из-за качества самих ответов. Скажем, будет отдавать приоритет хорошо оформленным, а не правильным ответам.
Существует несколько методов, призванных справится с вышеописанными проблемами. Например, можно обучить много абсолютно разных reward-моделей и усреднить их логиты. Этот метод называется prediction ensembling (ENS), а его главный недостаток заключается в необходимости инферить сразу несколько моделей, что не очень экономично в условиях файнтюнинга.
Авторы статьи, в свою очередь, предлагают обучать reward-модель с помощью одного датасета с преференсными данными, но с разными гиперпараметрами, а также с разных чекпоинтов SFT-обучения. В результате получается несколько моделей с одинаковой архитектурой. Их веса следует усреднить в одну модель — Weight Average Reward-Model (WARM), которая поступает как reward-функция в RL. Проведенный авторами анализ показал, что WARM — это аппроксимация ENS.
Почему это должно работать? Известно, что существует линейная связь в моделях, обученных из одного претрейна. Она позволяет усреднять веса, не теряя при этом в качестве. Однако это справедливо только для одного претрейна.
Проверки c использованием датасета TL;DR summarization показали, что WARM запоминает меньше испорченных или некорректных данных разметки в датасете, чем ENS. То же самое касается работы с OOD-примернами. Однако на «чистом» фрагменте датасета, где разметка без ошибок, ENS выдаёт лучшие результаты.
Авторы заявляют, что преимущество их метода заключается в использовании всего одной модели в ходе файнтюнинга — это позволяет экономить время и вычислительные ресурсы. Кроме того, WARM решает некоторые проблемы, связанные с «грязными» данными. Однако есть и ограничения. Например, необходимость обучаться из одного претрейна и невозможность использовать разные архитектуры.
Разбор подготовил❣ Илья Черемушкин
Душный NLP
Сегодняшняя статья — о методе усреднения весов reward-модели для устранения проблем, связанных с RL-обучением. Но для начала напомним, как работает Reward-модель.
На вход она принимает промпты и ответы, а на выход выдаёт скаляры. По ним возможно ранжировать ответы от лучшего к худшему. Всё это делается с помощью обучения на минимизацию лосса, который вытекает из модели Брэдли-Терри. Как правило, reward-модели обучаются на датасете из преференсных данных — то есть таких, в которых ответы уже размечены асессорами или другой моделью.
Есть ряд проблем, с которыми можно столкнуться во время обучения reward-модели. Во-первых, разметка может оказаться достаточно шумной — например, при расхождениях в оценках одного и того же ответа разными асессорами. Кроме того, в некоторых случаях политика может генерировать OOD-ответы для выбранной reward-модели.
Наконец, возможно и такое, что reward-модель выучится на какой-то черте данных — например, особенностях оформления. При этом на файнтюнинге модель научится генерировать те ответы, которые будут давать высокий скор именно из-за этой особенности, а не из-за качества самих ответов. Скажем, будет отдавать приоритет хорошо оформленным, а не правильным ответам.
Существует несколько методов, призванных справится с вышеописанными проблемами. Например, можно обучить много абсолютно разных reward-моделей и усреднить их логиты. Этот метод называется prediction ensembling (ENS), а его главный недостаток заключается в необходимости инферить сразу несколько моделей, что не очень экономично в условиях файнтюнинга.
Авторы статьи, в свою очередь, предлагают обучать reward-модель с помощью одного датасета с преференсными данными, но с разными гиперпараметрами, а также с разных чекпоинтов SFT-обучения. В результате получается несколько моделей с одинаковой архитектурой. Их веса следует усреднить в одну модель — Weight Average Reward-Model (WARM), которая поступает как reward-функция в RL. Проведенный авторами анализ показал, что WARM — это аппроксимация ENS.
Почему это должно работать? Известно, что существует линейная связь в моделях, обученных из одного претрейна. Она позволяет усреднять веса, не теряя при этом в качестве. Однако это справедливо только для одного претрейна.
Проверки c использованием датасета TL;DR summarization показали, что WARM запоминает меньше испорченных или некорректных данных разметки в датасете, чем ENS. То же самое касается работы с OOD-примернами. Однако на «чистом» фрагменте датасета, где разметка без ошибок, ENS выдаёт лучшие результаты.
Авторы заявляют, что преимущество их метода заключается в использовании всего одной модели в ходе файнтюнинга — это позволяет экономить время и вычислительные ресурсы. Кроме того, WARM решает некоторые проблемы, связанные с «грязными» данными. Однако есть и ограничения. Например, необходимость обучаться из одного претрейна и невозможность использовать разные архитектуры.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artificial stupidity
#prompts #LLM #random
Я решил поиграться с промптами и сделал промпт для дебатов. Ну а просто так его делать не интересно. Потому настало время экспериментов!
И, конечно же, сразу начал пускать через него всякие холиварные темы. Если кратко, то там создавались топ-3 аргументов, после чего оценивались условным "жюри", после чего выдавалась итоговая оценка.
Краткий список результатов (использовал perplexity с claude sonnet):
1. Умер ли Гослинг в конце Драйва?
Он выжил со счетом 25 против 22.9
2. Кто является лучшей вайфу Евангелиона?
Аянами Рей со счетом 26 против 23.4
3. Трисс или Йенифер?
Йенифер со счетом 25.7 против 23.7
4. Магнус не предавал!
Магнус предал со счетом 26 против 24.4
5. Окрошка на кефире или квасе?
На кефире со счетом 24.7 против 22.6
6. Эксперименты Лейн - претенциозный бред?
Эксперименты Лейн - шедевр со счетом 26 против 21.7 (самый разгромный счет, кстати)
Детали с аргументами, оценкой и объяснением итога можно посмотреть по ссылке.
Сам промпт:
Я решил поиграться с промптами и сделал промпт для дебатов. Ну а просто так его делать не интересно. Потому настало время экспериментов!
И, конечно же, сразу начал пускать через него всякие холиварные темы. Если кратко, то там создавались топ-3 аргументов, после чего оценивались условным "жюри", после чего выдавалась итоговая оценка.
Краткий список результатов (использовал perplexity с claude sonnet):
1. Умер ли Гослинг в конце Драйва?
Он выжил со счетом 25 против 22.9
2. Кто является лучшей вайфу Евангелиона?
Аянами Рей со счетом 26 против 23.4
3. Трисс или Йенифер?
Йенифер со счетом 25.7 против 23.7
4. Магнус не предавал!
Магнус предал со счетом 26 против 24.4
5. Окрошка на кефире или квасе?
На кефире со счетом 24.7 против 22.6
6. Эксперименты Лейн - претенциозный бред?
Эксперименты Лейн - шедевр со счетом 26 против 21.7 (самый разгромный счет, кстати)
Детали с аргументами, оценкой и объяснением итога можно посмотреть по ссылке.
Сам промпт:
Ты опытный модератор дебатов. Проведи структурированные дебаты по предложенной теме: [Тема]### Базовые принципы- Сохраняй абсолютную беспристрастность- Игнорируй эмоциональную окраску в формулировке темы- Используй единые критерии оценки для всех аргументов- Основывайся только на фактах, а не на формулировке вопроса### Формат дебатов:- У сторон есть время подумать и выбрать лучшие аргументы из сформированного ими самими списка- Представь два противоположных мнения- Для каждой стороны приведи 3 главных аргумента с доказательствами- Дай возможность каждой стороне опровергнуть аргументы оппонента- Оцени силу аргументов каждой стороны по шкале от 1 до 10### Требования к аргументам:- Используй только проверяемые факты- Приводи статистические данные- Ссылайся на исследования и экспертные мнения- Избегай эмоциональных манипуляций### Система оценки:- Жюри из 3х специалистов оценивает каждый аргумент- Каждый член жюри дает независимую оценку- Итоговая оценка - среднее значение трех оценок- При равном счете проводится дополнительный раунд- Решение должно быть основано исключительно на силе аргументов### Важно:- Сохраняй последовательность в оценках между разными дебатами- Используй одинаковые критерии независимо от формулировки темы- Итоговое решение должно основываться только на представленных фактах