Навигация
Хэштеги внутри блога, по которым можно найти посты на интересующие вас темы:
#py_basic - инсайты и лайфхаки для начинающих в Питоне, а также разборы несложных задач. Основано на большом опыте преподавания Питона с нуля.
#py_advanced - более продвинутые и специфические трюки и инструменты, разборы сложных задач.
#ml - про машинное обучение, интеллектуальный анализ данных, особенно в сфере обработки текстов. Истории из опыта (правда, не обо всём можно рассказывать из-за NDA).
#career - советы по продвижению карьеры в IT, прохождение собеседований, как найти первую работу и т.д.
#soft_skills - как эффективно общаться с коллегами, управлять временем, эмоциями, своим развитием.
Голосование:
https://t.me/plush_python/5
Об авторе:
https://t.me/plush_python/4
Хэштеги внутри блога, по которым можно найти посты на интересующие вас темы:
#py_basic - инсайты и лайфхаки для начинающих в Питоне, а также разборы несложных задач. Основано на большом опыте преподавания Питона с нуля.
#py_advanced - более продвинутые и специфические трюки и инструменты, разборы сложных задач.
#ml - про машинное обучение, интеллектуальный анализ данных, особенно в сфере обработки текстов. Истории из опыта (правда, не обо всём можно рассказывать из-за NDA).
#career - советы по продвижению карьеры в IT, прохождение собеседований, как найти первую работу и т.д.
#soft_skills - как эффективно общаться с коллегами, управлять временем, эмоциями, своим развитием.
Голосование:
https://t.me/plush_python/5
Об авторе:
https://t.me/plush_python/4
Telegram
Плюшевый Питон
Какие темы наиболее интересны? Также можете писать свои варианты в комментариях.
Базовый Питон / Продвинутый Питон / Машинное обучение и искусственный интеллект / Поиск работы, собеседования, карьера / Работа с людьми, гибкие навыки (soft skills)
Базовый Питон / Продвинутый Питон / Машинное обучение и искусственный интеллект / Поиск работы, собеседования, карьера / Работа с людьми, гибкие навыки (soft skills)
Dive into Deep Learning
#ml
И напоследок на сегодня хочу поделиться, недавно наткнулся на полезнейшую книжку по машинному / глубокому обучению:
https://d2l.ai/
Почему рекомендую:
* Написал крутой коллектив учёных из Amazon
* Книга бесплатная (но на английском)
* Отлично подходит для начинающих, будет интересна и продвинутым
* Актуальные примеры кода на современных фреймворках
* Книгу постоянно обновляют, она не должна быстро устареть
* Пишут, что её уже используют в 400 университетах в 60 странах мира
Прочитал несколько глав для ознакомления, мне понравилось.
#ml
И напоследок на сегодня хочу поделиться, недавно наткнулся на полезнейшую книжку по машинному / глубокому обучению:
https://d2l.ai/
Почему рекомендую:
* Написал крутой коллектив учёных из Amazon
* Книга бесплатная (но на английском)
* Отлично подходит для начинающих, будет интересна и продвинутым
* Актуальные примеры кода на современных фреймворках
* Книгу постоянно обновляют, она не должна быстро устареть
* Пишут, что её уже используют в 400 университетах в 60 странах мира
Прочитал несколько глав для ознакомления, мне понравилось.
Что нужно показать на собеседовании по машинному обучению?
#ml #career
Из опыта прохождения и проведения многочисленных собеседований в сфере ML могу сказать, что чаще всего интервьюеры хотят видеть в вас следующее:
• Чёткое понимание того, как происходит машинное обучение - градиентный спуск, типичные постановки задач в ML, функции потерь, недообучение / переобучение (bias / variance), валидация моделей, правильная методология проведения экспериментов.
• Опыт или хотя бы теоретическое знание методов решения различных проблем с данными: шум, выбросы, несбалансированность, низкая репрезентативность, повторы, слишком мало данных, слишком много данных и т.д.
• Знание и опыт применения основных современных и классических моделей в вашей области, будь то обработка структурированных данных или же естественного языка, изображений, звука.
• Не всегда, но довольно часто желателен опыт создания микросервисов, оптимизации моделей, мониторинга ML-приложений в продакшне.
Всё это, конечно, желательно демонстрировать на конкретных примерах из своей предыдущей работы / личных проектов. Так вы лучше продемонстрируете уверенное владение "матчастью". Не "проблема X решается методами Y1 и Y2", а "когда в таком-то проекте наша команда столкнулась с проблемой X, мы сначала применили метод Y1, но он оказался неэффективен по такой-то причине, поэтому мы перешли на метод Y2, и это привело вот к таким результатам". Так можно раскрыть больше деталей. Детали - ваши друзья, они не только свидетельствуют о вашем реальном опыте решения сложных проблем, но и делают ваш рассказ более живым и запоминающимся в глазах интервьюера. А это важно, потому что нас с вами (пока что) оценивают на собеседованиях живые люди, а не беспристрастные машины)
Пока остановлюсь на этом. Тема технических собеседований очень объёмная, буду постепенно раскрывать её в следующих постах.
#ml #career
Из опыта прохождения и проведения многочисленных собеседований в сфере ML могу сказать, что чаще всего интервьюеры хотят видеть в вас следующее:
• Чёткое понимание того, как происходит машинное обучение - градиентный спуск, типичные постановки задач в ML, функции потерь, недообучение / переобучение (bias / variance), валидация моделей, правильная методология проведения экспериментов.
• Опыт или хотя бы теоретическое знание методов решения различных проблем с данными: шум, выбросы, несбалансированность, низкая репрезентативность, повторы, слишком мало данных, слишком много данных и т.д.
• Знание и опыт применения основных современных и классических моделей в вашей области, будь то обработка структурированных данных или же естественного языка, изображений, звука.
• Не всегда, но довольно часто желателен опыт создания микросервисов, оптимизации моделей, мониторинга ML-приложений в продакшне.
Всё это, конечно, желательно демонстрировать на конкретных примерах из своей предыдущей работы / личных проектов. Так вы лучше продемонстрируете уверенное владение "матчастью". Не "проблема X решается методами Y1 и Y2", а "когда в таком-то проекте наша команда столкнулась с проблемой X, мы сначала применили метод Y1, но он оказался неэффективен по такой-то причине, поэтому мы перешли на метод Y2, и это привело вот к таким результатам". Так можно раскрыть больше деталей. Детали - ваши друзья, они не только свидетельствуют о вашем реальном опыте решения сложных проблем, но и делают ваш рассказ более живым и запоминающимся в глазах интервьюера. А это важно, потому что нас с вами (пока что) оценивают на собеседованиях живые люди, а не беспристрастные машины)
Пока остановлюсь на этом. Тема технических собеседований очень объёмная, буду постепенно раскрывать её в следующих постах.
Что важнее, модель или данные?
#ml
Как известно, суть машинного обучения в том, что мы не сами программируем логику принятия решений, а показываем машине довольно большое количество примеров, на которых она должна научиться решать ту или иную задачу. Многие инженеры по машинному обучению, с которыми я работал, считали, что главное в достижении хороших результатов - это применять самые свежие алгоритмы и трюки из научных статей. Другими словами, добиваться прироста качества за счёт изменений (часто - усложнений) в ML-модели. "Давайте возьмём нейросеть побольше!" Но нередко случается так, что недели и месяцы уходят на реализацию новых моделей и эксперименты с ними, при этом качество выполнения задачи не повышается или повышается несущественно - на 0.1-0.2%. Небольшой выигрыш в качестве может стоить значительных вычислительных ресурсов, что может быть неприемлемо в продакшне.
В последние годы набирает популярность другой подход, фокусирующийся на данных, а не на модели. По-английски его называют "data-centric machine learning". В нём задачу ставим чуть иначе: что, если наша модель уже достаточно хороша и мы просто должны показать ей более правильные и качественные примеры, чтобы она лучше научилась решать задачу?
В одной из компаний, где я работал, мы решали довольно трудную задачу классификации коротких текстов на японском языке. Классов было довольно много, некоторые из них были очень похожи, обучающих примеров было мало, и в результате всего этого наши нейросетевые модели плохо работали. Эксперименты с разными архитектурами мало помогали, поэтому я предложил применить подход, ориентированный на повышение качества датасета. Что мы сделали:
1. Анализ ошибок нашей модели. Валидационные примеры, которые не удаётся правильно классифицировать, часто могут выявить систематические проблемы обучения, сказать о том, чего не хватает в обучающих данных. Нам это помогло понять, какого рода тексты обычно относятся моделью к неверным классам, что между ними общего.
2. Построение матрицы ошибок (confusion matrix). Это ответило на вопрос, какие классы наиболее часто путает модель. По результатам мы добавили в обучающий датасет примеры, лучше разводящие между собой именно эти классы.
3. Сравнение качества модели с тем, насколько хорошо человек справляется с такой же задачей. Дали экспертам примеры из валидационного сета для ручной разметки, увидели, что люди тоже допускают немало ошибок и путают некоторые классы. Это помогло снизить нереалистичные ожидания от модели, а также пересмотреть принятую систему классов.
4. Очистка датасета от "плохих" примеров. Эксперты просмотрели датасет на предмет того, какие примеры (с человеческой точки зрения) слишком неоднозначны. С другой стороны, применили и автоматические методики поиска неадекватных примеров, основанные на методе ближайших соседей (сейчас я бы применил ещё и метод TracIn от Google).
Всё это в совокупности помогло значительно повысить точность классификации - с 0.47 до 0.85 - и практически "вернуло жизнь" проекту. Временные затраты были относительно невелики, к тому же значительная часть работ выполнялась экспертами-лингвистами, что позволило высвободить ценное время ML-инженеров.
Пишите в комментариях, о чём было бы интересно прочитать в следующих постах!
#ml
Как известно, суть машинного обучения в том, что мы не сами программируем логику принятия решений, а показываем машине довольно большое количество примеров, на которых она должна научиться решать ту или иную задачу. Многие инженеры по машинному обучению, с которыми я работал, считали, что главное в достижении хороших результатов - это применять самые свежие алгоритмы и трюки из научных статей. Другими словами, добиваться прироста качества за счёт изменений (часто - усложнений) в ML-модели. "Давайте возьмём нейросеть побольше!" Но нередко случается так, что недели и месяцы уходят на реализацию новых моделей и эксперименты с ними, при этом качество выполнения задачи не повышается или повышается несущественно - на 0.1-0.2%. Небольшой выигрыш в качестве может стоить значительных вычислительных ресурсов, что может быть неприемлемо в продакшне.
В последние годы набирает популярность другой подход, фокусирующийся на данных, а не на модели. По-английски его называют "data-centric machine learning". В нём задачу ставим чуть иначе: что, если наша модель уже достаточно хороша и мы просто должны показать ей более правильные и качественные примеры, чтобы она лучше научилась решать задачу?
В одной из компаний, где я работал, мы решали довольно трудную задачу классификации коротких текстов на японском языке. Классов было довольно много, некоторые из них были очень похожи, обучающих примеров было мало, и в результате всего этого наши нейросетевые модели плохо работали. Эксперименты с разными архитектурами мало помогали, поэтому я предложил применить подход, ориентированный на повышение качества датасета. Что мы сделали:
1. Анализ ошибок нашей модели. Валидационные примеры, которые не удаётся правильно классифицировать, часто могут выявить систематические проблемы обучения, сказать о том, чего не хватает в обучающих данных. Нам это помогло понять, какого рода тексты обычно относятся моделью к неверным классам, что между ними общего.
2. Построение матрицы ошибок (confusion matrix). Это ответило на вопрос, какие классы наиболее часто путает модель. По результатам мы добавили в обучающий датасет примеры, лучше разводящие между собой именно эти классы.
3. Сравнение качества модели с тем, насколько хорошо человек справляется с такой же задачей. Дали экспертам примеры из валидационного сета для ручной разметки, увидели, что люди тоже допускают немало ошибок и путают некоторые классы. Это помогло снизить нереалистичные ожидания от модели, а также пересмотреть принятую систему классов.
4. Очистка датасета от "плохих" примеров. Эксперты просмотрели датасет на предмет того, какие примеры (с человеческой точки зрения) слишком неоднозначны. С другой стороны, применили и автоматические методики поиска неадекватных примеров, основанные на методе ближайших соседей (сейчас я бы применил ещё и метод TracIn от Google).
Всё это в совокупности помогло значительно повысить точность классификации - с 0.47 до 0.85 - и практически "вернуло жизнь" проекту. Временные затраты были относительно невелики, к тому же значительная часть работ выполнялась экспертами-лингвистами, что позволило высвободить ценное время ML-инженеров.
Пишите в комментариях, о чём было бы интересно прочитать в следующих постах!
Проклятие правил (часть 1/2)
#ml
Когда имеет смысл для решения бизнес-задачи применять машинное обучение, а когда это того не стоит? С одной стороны, если задача не очень сложная, то быстрый результат можно получить и без ML, построив систему на правилах (эвристиках). Для этого нужно иметь некоторую экспертизу в решаемой задаче и уметь описывать логику принятия решения на формальном языке, будь то Python, регулярные выражения или что-то ещё.
Пример из личного опыта. Когда-то давно я работал преподавателем английского. Однажды мне захотелось заменить скучные языковые упражнения из учебника на более интересные. Я подумал, что дело не в самом формате упражнений - вставить пропущенные слова, выбрать правильную форму глагола, подходящуе по смыслу и т.д. - а в их содержании. Например, вместо текстов про банальных Джона и Мэри можно было бы взять более интересные студентам темы: музыку, спорт, Гарри Поттера и т.д. Но составлять упражнения вручную не хотелось. Зная Питон, я за несколько вечеров написал прототип автоматического генератора упражнений на основе любых текстов на английском. Программа ранжировала тексты по сложности на основе количественных показателей (средняя длина предложений и слов, средняя частота слов), затем выбирала в текстах интересные слова и контексты для создания пропусков, после чего форматировала тексты в виде упражнений. В первой версии программа поддерживала всего три вида упражнений, но её уже можно было использовать в учебном процессе. Получив первые результаты, я стал постепенно улучшать генератор: добавлял новые виды упражнений и совершенствовал алгоритм оценки сложности текстов. Всё это безобразие работало довольно хорошо без какого-либо машинного обучения, только на правилах. (Кстати, это был мой первый серьёзный проект в natural language processing, хоть и некоммерческий, т.к. программа распространялась бесплатно. Зато я сделал по нему несколько научных публикаций в 2014-2015 гг.)
Однако, как известно, есть много сложных задач, решение которых практически невозможно автоматизировать на достойном уровне качества без использования машинного обучения: машинный перевод, генерация изображений по текстовому запросу, распознавание речи и т.д. Странно было бы пытаться решать подобные задачи с помощью правил, написанных экспертами вручную (хотя такое порой пытались провернуть на ранних этапах развития искусственного интеллекта). А что нужно для машинного обучения? Хороший набор обучающих данных: чем он чище и полнее, тем лучше на нём обучится алгоритм. Для действительно сложных задач, которые решаются большими нейросетевыми моделями, конечно, нужно ещё обеспечить достаточные вычислительные ресурсы, но об этом мы поговорим как-нибудь в другой раз.
#ml
Когда имеет смысл для решения бизнес-задачи применять машинное обучение, а когда это того не стоит? С одной стороны, если задача не очень сложная, то быстрый результат можно получить и без ML, построив систему на правилах (эвристиках). Для этого нужно иметь некоторую экспертизу в решаемой задаче и уметь описывать логику принятия решения на формальном языке, будь то Python, регулярные выражения или что-то ещё.
Пример из личного опыта. Когда-то давно я работал преподавателем английского. Однажды мне захотелось заменить скучные языковые упражнения из учебника на более интересные. Я подумал, что дело не в самом формате упражнений - вставить пропущенные слова, выбрать правильную форму глагола, подходящуе по смыслу и т.д. - а в их содержании. Например, вместо текстов про банальных Джона и Мэри можно было бы взять более интересные студентам темы: музыку, спорт, Гарри Поттера и т.д. Но составлять упражнения вручную не хотелось. Зная Питон, я за несколько вечеров написал прототип автоматического генератора упражнений на основе любых текстов на английском. Программа ранжировала тексты по сложности на основе количественных показателей (средняя длина предложений и слов, средняя частота слов), затем выбирала в текстах интересные слова и контексты для создания пропусков, после чего форматировала тексты в виде упражнений. В первой версии программа поддерживала всего три вида упражнений, но её уже можно было использовать в учебном процессе. Получив первые результаты, я стал постепенно улучшать генератор: добавлял новые виды упражнений и совершенствовал алгоритм оценки сложности текстов. Всё это безобразие работало довольно хорошо без какого-либо машинного обучения, только на правилах. (Кстати, это был мой первый серьёзный проект в natural language processing, хоть и некоммерческий, т.к. программа распространялась бесплатно. Зато я сделал по нему несколько научных публикаций в 2014-2015 гг.)
Однако, как известно, есть много сложных задач, решение которых практически невозможно автоматизировать на достойном уровне качества без использования машинного обучения: машинный перевод, генерация изображений по текстовому запросу, распознавание речи и т.д. Странно было бы пытаться решать подобные задачи с помощью правил, написанных экспертами вручную (хотя такое порой пытались провернуть на ранних этапах развития искусственного интеллекта). А что нужно для машинного обучения? Хороший набор обучающих данных: чем он чище и полнее, тем лучше на нём обучится алгоритм. Для действительно сложных задач, которые решаются большими нейросетевыми моделями, конечно, нужно ещё обеспечить достаточные вычислительные ресурсы, но об этом мы поговорим как-нибудь в другой раз.
Проклятие правил (часть 2/2)
#ml
Так значит, всё просто? Для сложных задач размечаем датасет и используем машобуч, а для относительно простых - придумываем хорошие эвристики? Проблема в том, что во многих компаниях неверно оценивают сложность задачи и начинают решать её системой правил, думая, что это "дёшево и сердито" и что так будет всегда. Поначалу всё выглядит неплохо: правила позволяют быстро получить какой-то приемлемый результат, а для дальнейшего улучшения системы, как кажется, нужно всего лишь учесть в правилах все возникающие исключения. Но это очень большое "всего лишь". Проклятие правил в том, что чем сложнее становится система, тем труднее и дороже её становится поддерживать. Штат экспертов, пишущих правила, постоянно растёт, как растёт и время, необходимое для обучения новых сотрудников (чем больше система правил, тем дольше в ней приходится разбираться даже опытному человеку). А допускать ошибки в таких системах становится всё легче. При этом у руководства компании может возникнуть ощущение, что раз в эту систему уже вбухали столько ресурсов, то нужно её развивать и дальше, а не отказываться от неё в пользу чего-то другого (например, машинного обучения). А тут на рынке появляется новый стартап, который с самого начала решал эту задачу как задачу машинного обучения. И вот он уже обходит компанию, которая за несколько лет на рынке вложила в свой продукт огромные ресурсы.
В качестве наглядной иллюстрации приведу ещё один пример из опыта. В одной из компаний, где я раньше работал, был матёрый программист, который в течение года разрабатывал систему правил для извлечения именованных сущностей (имён людей, географических локаций, названий компаний и т.п.) из текстов. Он работал над этой системой год. В ней была сложная логика, написанная на Джаве, использовались разные хитрые словари и списки исключений, а запуск полного цикла тестов занимал целую ночь. В конце концов автору системы и его начальству стало очевидно, что уровень качества распознавания всё ещё недостаточно высок, все исключения учесть невозможно, а любое изменение в раздувшейся до невозможности системе вызывает больше новых ошибок, чем исправляет старых. В результате компании всё равно пришлось переходить на ML, но уже было впустую потрачено слишком много времени и ресурсов.
Такие вот дела. Вывод: используйте правила для несложных задач, но используйте их с умом и помните, что иногда они становятся проклятием.
#ml
Так значит, всё просто? Для сложных задач размечаем датасет и используем машобуч, а для относительно простых - придумываем хорошие эвристики? Проблема в том, что во многих компаниях неверно оценивают сложность задачи и начинают решать её системой правил, думая, что это "дёшево и сердито" и что так будет всегда. Поначалу всё выглядит неплохо: правила позволяют быстро получить какой-то приемлемый результат, а для дальнейшего улучшения системы, как кажется, нужно всего лишь учесть в правилах все возникающие исключения. Но это очень большое "всего лишь". Проклятие правил в том, что чем сложнее становится система, тем труднее и дороже её становится поддерживать. Штат экспертов, пишущих правила, постоянно растёт, как растёт и время, необходимое для обучения новых сотрудников (чем больше система правил, тем дольше в ней приходится разбираться даже опытному человеку). А допускать ошибки в таких системах становится всё легче. При этом у руководства компании может возникнуть ощущение, что раз в эту систему уже вбухали столько ресурсов, то нужно её развивать и дальше, а не отказываться от неё в пользу чего-то другого (например, машинного обучения). А тут на рынке появляется новый стартап, который с самого начала решал эту задачу как задачу машинного обучения. И вот он уже обходит компанию, которая за несколько лет на рынке вложила в свой продукт огромные ресурсы.
В качестве наглядной иллюстрации приведу ещё один пример из опыта. В одной из компаний, где я раньше работал, был матёрый программист, который в течение года разрабатывал систему правил для извлечения именованных сущностей (имён людей, географических локаций, названий компаний и т.п.) из текстов. Он работал над этой системой год. В ней была сложная логика, написанная на Джаве, использовались разные хитрые словари и списки исключений, а запуск полного цикла тестов занимал целую ночь. В конце концов автору системы и его начальству стало очевидно, что уровень качества распознавания всё ещё недостаточно высок, все исключения учесть невозможно, а любое изменение в раздувшейся до невозможности системе вызывает больше новых ошибок, чем исправляет старых. В результате компании всё равно пришлось переходить на ML, но уже было впустую потрачено слишком много времени и ресурсов.
Такие вот дела. Вывод: используйте правила для несложных задач, но используйте их с умом и помните, что иногда они становятся проклятием.
Пару недель тут не постил, время было немного суматошное по работе и не только. Но вот исправляюсь)
Решил поделиться слайдами со своего выступления про трансформеры и ChatGPT (подробнее о содержании в предыдущем посте). Доклад вызвал большой интерес, а после была ещё классная дискуссия с коллегами на целых полтора часа. Если пропустили само мероприятие, можете посмотреть слайды. Думаю, будет полезно и познавательно, особенно тем, кто пока не очень в теме. (А ещё там есть шутки и мотивационные цитаты от ChatGPT)
#ml
Решил поделиться слайдами со своего выступления про трансформеры и ChatGPT (подробнее о содержании в предыдущем посте). Доклад вызвал большой интерес, а после была ещё классная дискуссия с коллегами на целых полтора часа. Если пропустили само мероприятие, можете посмотреть слайды. Думаю, будет полезно и познавательно, особенно тем, кто пока не очень в теме. (А ещё там есть шутки и мотивационные цитаты от ChatGPT)
#ml
Как правильно оценивать чатбота-"болталку"?
#ml
На работе мы делаем, в числе прочего, чатбота, который должен уметь поддержать разговор с пользователем на любую (приличную) тему, да так, чтобы непотребного чего-нибудь не ляпнул. С подобными чатботами есть известная проблема - автоматически оценить их качество не очень получается, нужна экспертная - то есть человеческая - оценка. А как её делать эффективно и результативно?
Первое соображение - "болталку" нужно оценивать по достаточно большому количеству примеров. Ещё хорошо, если ответы нашего бота будут случайно перемешаны с ответами других ботов и даже людей. Мы при обучении новой модели отдаём на оценку качества около полутора тысяч её ответов в разных контекстах (причём контексты разной длины). Ну, а чтобы не слишком уж полагаться на отдельно взятого эксперта - мало ли, не с той ноги сегодня встал(а), - делаем оценку с перекрытием. Каждый ответ модели оценивают три эксперта, независимо друг от друга.
Оценка тоже не самая простая. Чем чётче обозначены критерии, тем легче будет работа разметчиков, а значит, тем надёжнее результаты. Есть разные методики оценки, в их числе sensibleness and specificity average (SSA), которую разработали исследователи из Google. Она довольно проста и эффективна: оценивают разумность и специфичность ответов бота. Вот тут можно подробнее прочитать, но если вкратце, разумность - это про адекватность ответов, отсутствие в них бреда и оскорблений, например. Специфичность интереснее: ответы бота не должны быть слишком односложными, короткими, "на все случаи жизни". Простой пример:
Пользователь: У моего сына сегодня день рождения.
Бот А: Отличная песня!
Данный ответ не имеет смысла в этом контексте, поэтому он получает оценку 0 за разумность. Если за разумность 0, то и за специфичность автоматически тоже 0.
Бот Б: Понятно.
Данный ответ, в целом, разумен, но не специфичен, много на что можно сказать "понятно", но развитию темы это не способствует. Поэтому оценки 1 и 0, соответственно.
Бот В: Поздравляю от всей цифровой души. А сколько лет вашему сыну исполняется?
А вот это уже и разумный, и специфичный ответ. Да ещё и с юмором. Кстати, реальный ответ нашего бота. Вот бы он всегда так хорошо отвечал)
Мы добавили к SSA ещё пару дополнительных критериев, важных для бизнес-задачи. Итак, у нас есть оценки от трёх разметчиков по четырём параметрам. Что дальше? Имеет смысл также измерить согласие между аннотаторами. Каппа Коэна - отличная метрика, которую очень легко посчитать с помощью библиотеки scikit-learn. Она лучше, чем просто усреднение ответов разметчиков, потому что учитывает вероятность случайного совпадения. Другими словами, если у вас всего два возможных класса (0 и 1) и их распределение неравномерно, то вероятность случайного совпадения оценок гораздо выше, чем если бы классов было 15 и они встречались бы примерно с одинаковой частотой.
Каппа Коэна считается для каждой пары аннотаторов, благодаря чему мы можем увидеть, например, что ответы одного из разметчиков сильно отличаются от ответов двух других. Это может говорить о том, что данный эксперт не так понял задачу и его следует проинструктировать ещё раз. Или возможна ситуация, когда у всех троих разметчиков очень разные оценки по одному из критериев - тогда, возможно, данный критерий стоит сформулировать более понятно.
#ml
На работе мы делаем, в числе прочего, чатбота, который должен уметь поддержать разговор с пользователем на любую (приличную) тему, да так, чтобы непотребного чего-нибудь не ляпнул. С подобными чатботами есть известная проблема - автоматически оценить их качество не очень получается, нужна экспертная - то есть человеческая - оценка. А как её делать эффективно и результативно?
Первое соображение - "болталку" нужно оценивать по достаточно большому количеству примеров. Ещё хорошо, если ответы нашего бота будут случайно перемешаны с ответами других ботов и даже людей. Мы при обучении новой модели отдаём на оценку качества около полутора тысяч её ответов в разных контекстах (причём контексты разной длины). Ну, а чтобы не слишком уж полагаться на отдельно взятого эксперта - мало ли, не с той ноги сегодня встал(а), - делаем оценку с перекрытием. Каждый ответ модели оценивают три эксперта, независимо друг от друга.
Оценка тоже не самая простая. Чем чётче обозначены критерии, тем легче будет работа разметчиков, а значит, тем надёжнее результаты. Есть разные методики оценки, в их числе sensibleness and specificity average (SSA), которую разработали исследователи из Google. Она довольно проста и эффективна: оценивают разумность и специфичность ответов бота. Вот тут можно подробнее прочитать, но если вкратце, разумность - это про адекватность ответов, отсутствие в них бреда и оскорблений, например. Специфичность интереснее: ответы бота не должны быть слишком односложными, короткими, "на все случаи жизни". Простой пример:
Пользователь: У моего сына сегодня день рождения.
Бот А: Отличная песня!
Данный ответ не имеет смысла в этом контексте, поэтому он получает оценку 0 за разумность. Если за разумность 0, то и за специфичность автоматически тоже 0.
Бот Б: Понятно.
Данный ответ, в целом, разумен, но не специфичен, много на что можно сказать "понятно", но развитию темы это не способствует. Поэтому оценки 1 и 0, соответственно.
Бот В: Поздравляю от всей цифровой души. А сколько лет вашему сыну исполняется?
А вот это уже и разумный, и специфичный ответ. Да ещё и с юмором. Кстати, реальный ответ нашего бота. Вот бы он всегда так хорошо отвечал)
Мы добавили к SSA ещё пару дополнительных критериев, важных для бизнес-задачи. Итак, у нас есть оценки от трёх разметчиков по четырём параметрам. Что дальше? Имеет смысл также измерить согласие между аннотаторами. Каппа Коэна - отличная метрика, которую очень легко посчитать с помощью библиотеки scikit-learn. Она лучше, чем просто усреднение ответов разметчиков, потому что учитывает вероятность случайного совпадения. Другими словами, если у вас всего два возможных класса (0 и 1) и их распределение неравномерно, то вероятность случайного совпадения оценок гораздо выше, чем если бы классов было 15 и они встречались бы примерно с одинаковой частотой.
Каппа Коэна считается для каждой пары аннотаторов, благодаря чему мы можем увидеть, например, что ответы одного из разметчиков сильно отличаются от ответов двух других. Это может говорить о том, что данный эксперт не так понял задачу и его следует проинструктировать ещё раз. Или возможна ситуация, когда у всех троих разметчиков очень разные оценки по одному из критериев - тогда, возможно, данный критерий стоит сформулировать более понятно.
Выложили запись моего доклада про трансформеры и ChatGPT, в конце живая дискуссия. Если пропустили, можно посмотреть в записи. Особенно будет полезно тем, кто пока ещё не очень хорошо знаком с NLP:
https://www.youtube.com/watch?v=lVOPft5U500
#ml
https://www.youtube.com/watch?v=lVOPft5U500
#ml
YouTube
ODS Breakfast @NN: 2023.02.19 | От классического трансформера к ChatGPT
Тема: От классического трансформера к ChatGPT
Спикер: Алексей Малафеев, руководитель группы NLP-платформы Центра искусственного интеллекта МТС
Нижегородское сообщество ODS завтраков: https://t.me/nnodsbreakfast
Трансформеры – это наиболее актуальная на сегодняшний…
Спикер: Алексей Малафеев, руководитель группы NLP-платформы Центра искусственного интеллекта МТС
Нижегородское сообщество ODS завтраков: https://t.me/nnodsbreakfast
Трансформеры – это наиболее актуальная на сегодняшний…
После вчерашнего мок-интервью мне в чате ODS NN задавали интересные вопросы, опубликую здесь ответы на некоторые из них. Надеюсь, что кому-то из вас будет полезно)
1. Если на собеседовании будут спрашивать про Python, какие вопросы могут быть?
На уровне мидла / сеньора по Питону можно ожидать вопросы про декораторы + functools.wraps, метаклассы и чем их лучше заменить, контекстные менеджеры, переписывание операторов (+ - * == > и т.д.), дескрипторы, наследование vs композиция vs микс-ины, pytest, разрешение circular imports, аннотирование типов и т.п.
На уровне джуниора часто спрашивают про то, когда лучше использовать какие типы данных (список vs словарь vs множество vs кортеж), list/dict comprehensions, generator expressions, принципы ООП.
Всем полезно знать про инженерные практики: SOLID, DRY, AHA, YAGNI и т.п.
2. Как оставаться в курсе трендов NLP (особенно когда уже владеешь теоретической базой)?
Я обычно, чтобы быть в курсе трендов, читаю телеграм-каналы наподобие:
https://t.me/dlinnlp
https://t.me/gonzo_ML
https://t.me/doomgrad
Потом, если нужно более глубоко разобраться в том или ином методе / подходе, читаю научные статьи (а куда от них деваться) и блог-посты крупных компаний.
Иногда полезно выборочно читать новые книги, издаваемые авторитетными издательствами (O'Reilly, Manning), там бывает более систематичное и подробное изложение относительно "больших" тем (например, какой-то конкретный фреймворк или тип задач).
3. Какие есть бесплатные онлайн-курсы не про алгоритмы ML, а про выведение моделей в продакшн, применение ML в реальных приложениях и т.п.?
Вот эти рекомендую посмотреть:
https://www.coursera.org/specializations/machine-learning-engineering-for-production-mlops
https://ods.ai/tracks/ml-system-design-22
https://c.d2l.ai/stanford-cs329p/
#ml #career
1. Если на собеседовании будут спрашивать про Python, какие вопросы могут быть?
На уровне мидла / сеньора по Питону можно ожидать вопросы про декораторы + functools.wraps, метаклассы и чем их лучше заменить, контекстные менеджеры, переписывание операторов (+ - * == > и т.д.), дескрипторы, наследование vs композиция vs микс-ины, pytest, разрешение circular imports, аннотирование типов и т.п.
На уровне джуниора часто спрашивают про то, когда лучше использовать какие типы данных (список vs словарь vs множество vs кортеж), list/dict comprehensions, generator expressions, принципы ООП.
Всем полезно знать про инженерные практики: SOLID, DRY, AHA, YAGNI и т.п.
2. Как оставаться в курсе трендов NLP (особенно когда уже владеешь теоретической базой)?
Я обычно, чтобы быть в курсе трендов, читаю телеграм-каналы наподобие:
https://t.me/dlinnlp
https://t.me/gonzo_ML
https://t.me/doomgrad
Потом, если нужно более глубоко разобраться в том или ином методе / подходе, читаю научные статьи (а куда от них деваться) и блог-посты крупных компаний.
Иногда полезно выборочно читать новые книги, издаваемые авторитетными издательствами (O'Reilly, Manning), там бывает более систематичное и подробное изложение относительно "больших" тем (например, какой-то конкретный фреймворк или тип задач).
3. Какие есть бесплатные онлайн-курсы не про алгоритмы ML, а про выведение моделей в продакшн, применение ML в реальных приложениях и т.п.?
Вот эти рекомендую посмотреть:
https://www.coursera.org/specializations/machine-learning-engineering-for-production-mlops
https://ods.ai/tracks/ml-system-design-22
https://c.d2l.ai/stanford-cs329p/
#ml #career
Выложили на ютуб запись моего мок-интервью для Junior NLP Developer, посмотрите, если для вас актуально:
https://youtu.be/mCeZZvOq0qA
#ml #career
https://youtu.be/mCeZZvOq0qA
#ml #career
На работе попросили записать короткое видео о том, что такое машинное обучение. Формат специфический: короткий клип, всего одна минута. Много за 60 секунд не расскажешь, но надеюсь, что будет небесполезно для совсем начинающих, кто ещё ничего не знает о машинном обучении. Для меня это был интересный первый опыт. Ролик здесь, если кому любопытно:
https://vk.com/clip-212087550_456239074?c=0
#ml
https://vk.com/clip-212087550_456239074?c=0
#ml
VK
MTS AI on VK Clips
Как машинное обучение влияет на
Первый раз опубликовался в Форбс!
Это opinion piece на одну актуальную тему, связанную с генеративным AI. Вместе с Сергеем Загоруйко, руководителем направления фундаментальных исследований в моей компании, порассуждали о том, к каким проблемам может привести наводнение Интернета контентом, произведённым нейросетями, и как с этими проблемами бороться.
#ml
Это opinion piece на одну актуальную тему, связанную с генеративным AI. Вместе с Сергеем Загоруйко, руководителем направления фундаментальных исследований в моей компании, порассуждали о том, к каким проблемам может привести наводнение Интернета контентом, произведённым нейросетями, и как с этими проблемами бороться.
#ml
Forbes.ru
Нейросетевой коллапс: почему вскоре может остановиться развитие алгоритмов ИИ
По оценке ряда ученых, уже скоро качество нейросетей может стремительно деградировать. Причиной этого станет обилие в сети контента, ранее сгенерированного ИИ-моделями. О том, станут ли нейросети в будущем бесполезными, рассуждают руководитель направ
Одна из читательниц блога задала классный вопрос в комментариях (кстати, напоминаю, что вы всегда можете задавать мне интересующие вас вопросы под постами или просто писать мне в личку, контакты есть в описании канала). Я подумал, что на этот вопрос будет полезно ответить развёрнуто, в формате отдельного поста, потому что ответ затронет важную для меня тему, на которую я всё равно хотел в ближайшее время написать.
Итак, меня спросили: "расскажите, пожалуйста, про языки, которые используются в NLP-разработке и ML. Что встречалось на Ваших местах работы или у Ваших знакомых? Большинство проектов, которые я находила на эту тематику, — на python, однако кажется, что знание и умение использовать один язык для этих целей — не самое эффективное и правильное решение. Есть же языки побыстрее всё-таки"
---
Коротенькая ремарка. Некоторые пишут "на Python", другие "на Пайтоне", третьи "на Питоне". Мне привычнее и больше нравится "на Питоне", простите, если кого-то это раздражает)
---
Часть 1. Медленно, но быстро
#python #ml
Собственно для ML-разработки, действительно, почти всегда используется Питон. Это во многом связано с тем, что для машинного обучения в экосистеме Питона уже есть мощнейший набор фреймворков, библиотек и прочих инструментов. Да и не только для машинного обучения - про Питон говорят, что он "идёт с батарейками в комплекте". Представьте, что вам по работе нужно обучить ML-модель - например, классификатор токсичности для фильтрации оскорбительных высказываний. Если вы будете делать это на Питоне, у вас уже есть готовые библиотеки для всех этапов работы: загрузка и разведочный анализ данных, очистка и подготовка данных, обучение моделей (как "классических", так и более современных, основанных на трансформерах), оценка их качества, визуализация результатов, анализ ошибок модели, выявление примеров, неправильно размеченных людьми в обучающей выборке и т.д. На других языках такого изобилия инструментов нет, вам бы пришлось реализовывать всё или почти всё это с нуля.
Таким образом, важно учитывать не только быстродействие самого языка, но и скорость разработки на нём. Питон довольно лаконичен, его синтаксис не слишком перегружен скобками и прочими знаками препинания, а эксперты в языке всячески поощряют читаемость кода (например, об этом пишут автор книги "Effective Python" Brett Slatkin и автор книги "Robust Python" Patrick Viafore). Плюс отличный набор готовых библиотек и инструментов - вот и секрет его успеха. Раньше Питон называли "вторым лучшим языком для чего угодно", но сейчас по популярности этот язык занимает первое место в мире. Да и с "медленностью" Питона не всё так однозначно. Версия 3.10 значительно быстрее, чем 3.9, а 3.11 сильно обгоняет 3.10. Посмотрим, что будет с 3.12 и дальше. К тому же, активно развиваются всякие специальные инструменты для ускорения кода на Питоне.
Итак, меня спросили: "расскажите, пожалуйста, про языки, которые используются в NLP-разработке и ML. Что встречалось на Ваших местах работы или у Ваших знакомых? Большинство проектов, которые я находила на эту тематику, — на python, однако кажется, что знание и умение использовать один язык для этих целей — не самое эффективное и правильное решение. Есть же языки побыстрее всё-таки"
---
Коротенькая ремарка. Некоторые пишут "на Python", другие "на Пайтоне", третьи "на Питоне". Мне привычнее и больше нравится "на Питоне", простите, если кого-то это раздражает)
---
Часть 1. Медленно, но быстро
#python #ml
Собственно для ML-разработки, действительно, почти всегда используется Питон. Это во многом связано с тем, что для машинного обучения в экосистеме Питона уже есть мощнейший набор фреймворков, библиотек и прочих инструментов. Да и не только для машинного обучения - про Питон говорят, что он "идёт с батарейками в комплекте". Представьте, что вам по работе нужно обучить ML-модель - например, классификатор токсичности для фильтрации оскорбительных высказываний. Если вы будете делать это на Питоне, у вас уже есть готовые библиотеки для всех этапов работы: загрузка и разведочный анализ данных, очистка и подготовка данных, обучение моделей (как "классических", так и более современных, основанных на трансформерах), оценка их качества, визуализация результатов, анализ ошибок модели, выявление примеров, неправильно размеченных людьми в обучающей выборке и т.д. На других языках такого изобилия инструментов нет, вам бы пришлось реализовывать всё или почти всё это с нуля.
Таким образом, важно учитывать не только быстродействие самого языка, но и скорость разработки на нём. Питон довольно лаконичен, его синтаксис не слишком перегружен скобками и прочими знаками препинания, а эксперты в языке всячески поощряют читаемость кода (например, об этом пишут автор книги "Effective Python" Brett Slatkin и автор книги "Robust Python" Patrick Viafore). Плюс отличный набор готовых библиотек и инструментов - вот и секрет его успеха. Раньше Питон называли "вторым лучшим языком для чего угодно", но сейчас по популярности этот язык занимает первое место в мире. Да и с "медленностью" Питона не всё так однозначно. Версия 3.10 значительно быстрее, чем 3.9, а 3.11 сильно обгоняет 3.10. Посмотрим, что будет с 3.12 и дальше. К тому же, активно развиваются всякие специальные инструменты для ускорения кода на Питоне.
А вы знали про confident learning?
#ml
"Уверенное обучение" в контексте machine learning - что бы это могло значить? 🤔 Почти все алгоритмы машинного обучения основаны на предположении, что обучающие данные чисты и заслуживают доверия. Однако на самом деле в них часто закрадываются ошибки разметки, которые плохо влияют на обучение моделей. Confident learning - это относительно новый подход к обучению моделей в русле data-centric ML. Он объединяет в себе различные практики и трюки для обнаружения ошибок разметки и эффективного обучения моделей несмотря на присутствие в данных таких ошибок.
Зачем знать про этот подход? Его можно применять в почти любых задачах машинного обучения с учителем (мультикласс- и мультилейбл-классификация, регрессия) в NLP, CV, работе со структурированными данными. Подход автоматически определяет ошибки в разметке, не требуя подбора гиперпараметров (использует кросс-валидацию для предсказания вероятностей в режиме out-of-sample). После этого можно обучить модель только на данных, не содержащих ошибок разметки - как правило, такая модель будет более точной. 🤓
Confident learning хорошо обоснован теоретически, также есть реализация его методов в библиотеке cleanlab со свободной лицензией. Статья, описывающая подход, имеет 400+ цитирований с 2021 года, а репозиторий cleanlab - 6,2К звёзд. При этом подход не то чтобы очень широко известен. Вы можете применить confident learning в своих рабочих задачах (будем честны, как часто мы видим идеально размеченные датасеты?), а также блеснуть эрудицией на собеседованиях.
Например, с cleanlab можно одной строчкой кода запустить диагностику датасета и получить отчёт о возможных проблемах:
Для тех, кто дочитал до конца 🙏, небольшой бонус - курс 2023 года от MIT по датацентричному ИИ с большим количеством лабораторных работ. Очень рекомендую!
#ml
"Уверенное обучение" в контексте machine learning - что бы это могло значить? 🤔 Почти все алгоритмы машинного обучения основаны на предположении, что обучающие данные чисты и заслуживают доверия. Однако на самом деле в них часто закрадываются ошибки разметки, которые плохо влияют на обучение моделей. Confident learning - это относительно новый подход к обучению моделей в русле data-centric ML. Он объединяет в себе различные практики и трюки для обнаружения ошибок разметки и эффективного обучения моделей несмотря на присутствие в данных таких ошибок.
Зачем знать про этот подход? Его можно применять в почти любых задачах машинного обучения с учителем (мультикласс- и мультилейбл-классификация, регрессия) в NLP, CV, работе со структурированными данными. Подход автоматически определяет ошибки в разметке, не требуя подбора гиперпараметров (использует кросс-валидацию для предсказания вероятностей в режиме out-of-sample). После этого можно обучить модель только на данных, не содержащих ошибок разметки - как правило, такая модель будет более точной. 🤓
Confident learning хорошо обоснован теоретически, также есть реализация его методов в библиотеке cleanlab со свободной лицензией. Статья, описывающая подход, имеет 400+ цитирований с 2021 года, а репозиторий cleanlab - 6,2К звёзд. При этом подход не то чтобы очень широко известен. Вы можете применить confident learning в своих рабочих задачах (будем честны, как часто мы видим идеально размеченные датасеты?), а также блеснуть эрудицией на собеседованиях.
Например, с cleanlab можно одной строчкой кода запустить диагностику датасета и получить отчёт о возможных проблемах:
from cleanlab.dataset import health_summary
health_summary(labels, pred_probs)
Ещё один короткий пример для классификации текстов:cl = CleanLearning(model, cv_n_folds=cv_n_folds)
label_issues = cl.find_label_issues(
X=train_texts,
labels=train_labels,
)
cl.fit(
X=train_texts,
labels=train_labels,
label_issues=cl.get_label_issues(),
)
При обучении новой модели на очищенных от ошибок данных будьте внимательны к тому, как вы оцениваете итоговый результат. Если оценивать на тестовом сете, содержащем ошибки разметки, то эффект от confident learning не будет заметен. Авторы библиотеки дают рекомендации, как правильно применять этот подход, в понятных тьюториалах и FAQ.Для тех, кто дочитал до конца 🙏, небольшой бонус - курс 2023 года от MIT по датацентричному ИИ с большим количеством лабораторных работ. Очень рекомендую!
Не так давно составлял индивидуальный учебный план для одного из подписчиков, который хотел перейти в сферу data science / machine learning. План был сильно "заточен" под этого конкретного человека и его бэкграунд. Потом я подумал, что будет полезно также опубликовать здесь обобщённый учебный план для тех, кто хотел бы заниматься машинным обучением, но не знает, с чего начать. Надеюсь, кому-то из вас будет полезно! Смотрите следующий пост.
#ml #career
#ml #career