✔ Что такое Gated Recurrent Unit (GRU)? Где используется ?
Закрытый рекуррентный блок (GRU) является частью конкретной модели рекуррентной нейронной сети, которая намеревается использовать соединения через последовательность узлов для выполнения задач машинного обучения, связанных с памятью и кластеризацией, например, в распознавании речи.
Рекуррентные блоки помогают регулировать входные веса нейронной сети для решения проблемы исчезающего градиента, которая является общей проблемой с рекуррентными нейронными сетями.
Еще закрытые рекуррентные блоки используются в машинном переводе. Они отличаются от LSTM, хотя тоже являются расширением для нейросетевого машинного обучения. В GRU на один гейт меньше, и работа строится по-другому: вместо входного, выходного и забывания, есть гейт обновления (
Функции сброса гейта (reset gate) похожи на затвор забывания у LSTM, но расположение отличается. GRU всегда передают свое полное состояние, не имеют выходной затвор. Часто эти затвор функционирует как и LSTM, однако, большим отличием заключается в следующем: в GRU затвор работают быстрее и легче в управлении (но также менее интерпретируемые). На практике они стремятся нейтрализовать друг друга, так как нужна большая нейросеть для восстановления выразительности (expressiveness), которая сводит на нет приросты в результате. Но в случаях, где не требуется экстра выразительности, GRU показывают лучше результат, чем LSTM.
В дополнение к машинному преводу, модели нейронной сети, использующие рекуррентные единицы, могут использоваться для исследования генома человека, анализа почерка и многого другого. Некоторые из этих инновационных сетей используются для анализа фондового рынка и работы правительства. Многие из них используют моделируемую способность машин запоминать информацию.
@machinelearning_interview
Закрытый рекуррентный блок (GRU) является частью конкретной модели рекуррентной нейронной сети, которая намеревается использовать соединения через последовательность узлов для выполнения задач машинного обучения, связанных с памятью и кластеризацией, например, в распознавании речи.
Рекуррентные блоки помогают регулировать входные веса нейронной сети для решения проблемы исчезающего градиента, которая является общей проблемой с рекуррентными нейронными сетями.
Еще закрытые рекуррентные блоки используются в машинном переводе. Они отличаются от LSTM, хотя тоже являются расширением для нейросетевого машинного обучения. В GRU на один гейт меньше, и работа строится по-другому: вместо входного, выходного и забывания, есть гейт обновления (
update gate). Он определяет, сколько информации необходимо сохранить c последнего состояния и сколько информации пропускать с предыдущих слоев.Функции сброса гейта (reset gate) похожи на затвор забывания у LSTM, но расположение отличается. GRU всегда передают свое полное состояние, не имеют выходной затвор. Часто эти затвор функционирует как и LSTM, однако, большим отличием заключается в следующем: в GRU затвор работают быстрее и легче в управлении (но также менее интерпретируемые). На практике они стремятся нейтрализовать друг друга, так как нужна большая нейросеть для восстановления выразительности (expressiveness), которая сводит на нет приросты в результате. Но в случаях, где не требуется экстра выразительности, GRU показывают лучше результат, чем LSTM.
В дополнение к машинному преводу, модели нейронной сети, использующие рекуррентные единицы, могут использоваться для исследования генома человека, анализа почерка и многого другого. Некоторые из этих инновационных сетей используются для анализа фондового рынка и работы правительства. Многие из них используют моделируемую способность машин запоминать информацию.
@machinelearning_interview
✔ Расскажите про методы увеличения производительности СУБД?
СУБД очень часто становится «узким местом» в производительности веб‑приложений, влияющим на общее быстродействие и устойчивость к высоким нагрузкам.
Масштабирование «железа» и адекватная настройка
• Первое, что стоит сделать, если скорость работы базы данных не удовлетворяет требованиям, это проверить адекватность настройки СУБД относительно имеющихся ресурсов, а также убедиться, что при проектировании БД были учтены используемые запросы. Если, например, для СУБД работает с настройками «из коробки», а при обработке запросов не используются индексы, то надо не масштабировать СУБД, достаточно просто откорректировать конфигурацию работы сервера баз данных и обновить схему используемой базы данных под профиль нагрузки.
• Иногда также проще увеличить выделение ресурсов под сервер баз данных — количество оперативной памяти и скорость работы дисковой подсистемы оказывают существенное воздействие на скорость работы СУБД. Нередко даже небольшое увеличение RAM и переход на SSD увеличивает производительность в разы.
Масштабирование через партиционирование, репликацию и шардинг
В момент, когда даже корректно настроенный сервер баз данных на достаточно мощном железе уже недостаточно хорошо справляется с нагрузками, производится масштабирование при помощи партиционирования, репликации и шардинга. Далее рассмотрим эти способы увеличения производительности СУБД.
Партиционирование (partitioning)
Партиционирование — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям. Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. Для правильного конфигурирования параметров партиционирования необходимо, чтобы в каждом потоке было примерно одинаковое количество записей.
Например, на новостных сайтах имеет смысл партиционировать записи по дате публикации, так как свежие новости на несколько порядков более востребованы и чаще требуется работа именно с ними, а не со всех архивом за годы существования новостного ресурса.
Репликация (replication)
Репликация — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие серверы часто называют мастерами (master), а ведомые серверы — слэйвами (slave). Более политкорректные современные названия — Лидер и Фолловер (leader & follower).
Ведущие сервера используются для чтения и изменения данных, а ведомые — только для чтения. В классической схеме репликации обычно один мастер и несколько слэйвов, так как в большей части веб‑проектов операций чтения на несколько порядков больше, чем операций записи. Однако в более сложной схеме репликации может быть и несколько мастеров.
Например, создание нескольких дополнительных slave‑серверов позволяет снять с основного сервера нагрузку и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет.
Шардинг (sharding)
Шардинг — это прием, который позволяет распределять данные между разными физическими серверами. Процесс шардинга предполагает разнесения данных между отдельными шардами на основе некого ключа шардинга. Связанные одинаковым значением ключа шардинга сущности группируются в набор данных по заданному ключу, а этот набор хранится в пределах одного физического шарда. Это существенно облегчает обработку данных.
Например, в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких.
@machinelearning_interview
СУБД очень часто становится «узким местом» в производительности веб‑приложений, влияющим на общее быстродействие и устойчивость к высоким нагрузкам.
Масштабирование «железа» и адекватная настройка
• Первое, что стоит сделать, если скорость работы базы данных не удовлетворяет требованиям, это проверить адекватность настройки СУБД относительно имеющихся ресурсов, а также убедиться, что при проектировании БД были учтены используемые запросы. Если, например, для СУБД работает с настройками «из коробки», а при обработке запросов не используются индексы, то надо не масштабировать СУБД, достаточно просто откорректировать конфигурацию работы сервера баз данных и обновить схему используемой базы данных под профиль нагрузки.
• Иногда также проще увеличить выделение ресурсов под сервер баз данных — количество оперативной памяти и скорость работы дисковой подсистемы оказывают существенное воздействие на скорость работы СУБД. Нередко даже небольшое увеличение RAM и переход на SSD увеличивает производительность в разы.
Масштабирование через партиционирование, репликацию и шардинг
В момент, когда даже корректно настроенный сервер баз данных на достаточно мощном железе уже недостаточно хорошо справляется с нагрузками, производится масштабирование при помощи партиционирования, репликации и шардинга. Далее рассмотрим эти способы увеличения производительности СУБД.
Партиционирование (partitioning)
Партиционирование — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям. Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. Для правильного конфигурирования параметров партиционирования необходимо, чтобы в каждом потоке было примерно одинаковое количество записей.
Например, на новостных сайтах имеет смысл партиционировать записи по дате публикации, так как свежие новости на несколько порядков более востребованы и чаще требуется работа именно с ними, а не со всех архивом за годы существования новостного ресурса.
Репликация (replication)
Репликация — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие серверы часто называют мастерами (master), а ведомые серверы — слэйвами (slave). Более политкорректные современные названия — Лидер и Фолловер (leader & follower).
Ведущие сервера используются для чтения и изменения данных, а ведомые — только для чтения. В классической схеме репликации обычно один мастер и несколько слэйвов, так как в большей части веб‑проектов операций чтения на несколько порядков больше, чем операций записи. Однако в более сложной схеме репликации может быть и несколько мастеров.
Например, создание нескольких дополнительных slave‑серверов позволяет снять с основного сервера нагрузку и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет.
Шардинг (sharding)
Шардинг — это прием, который позволяет распределять данные между разными физическими серверами. Процесс шардинга предполагает разнесения данных между отдельными шардами на основе некого ключа шардинга. Связанные одинаковым значением ключа шардинга сущности группируются в набор данных по заданному ключу, а этот набор хранится в пределах одного физического шарда. Это существенно облегчает обработку данных.
Например, в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких.
@machinelearning_interview
🏋️♀️ Упражнения для продвинутого использования NumPy
https://uproger.com/prodvinutyj-numpy-ottachivajte-tryuki-s-shagami/
@machinelearning_interview
https://uproger.com/prodvinutyj-numpy-ottachivajte-tryuki-s-shagami/
@machinelearning_interview
📌C какими проблемами может столкнуться нейронный алгоритм в работе с временными рядами? Какую архитектуру можно выбрать, чтобы решить такие проблемы?
Первое, что приходит на ум - это, конечно, рекуррентные нейросети(картинка 1).
Одна из идей, сделавшая RNN неоправданно эффективными - "авторегрессия" (auto-regression), это значит, что созданная переменная добавляется в последовательность в качестве входных данных. В машинном обучении часто применяется эта техника, особенно в работе с временными рядами.
Хотя рекуррентная сеть и должна работать со всей последовательностью, к сожалению, присутствует проблема "затухающего градиента"(vanishing gradient problem). Что значит, что более старые входы не влияют на текущий выход. Такие модели, как LSTM пытаются решить эту проблему, добавляя дополнительные параметры (картинка 2).
Такие модели считывают ввод данных последовательно.
Архитектура, в которой обработка последовательности производится сразу, что практически не оставляет места для потери информации, реализована в кодировщике модели Transformer. Эта характеристика позволяет модели изучать контекст переменной на основе всего его окружения. Кроме того, по сравнению с рекуррентными нейросетями, чаще всего они быстрее.
@machinelearning_interview
Первое, что приходит на ум - это, конечно, рекуррентные нейросети(картинка 1).
Одна из идей, сделавшая RNN неоправданно эффективными - "авторегрессия" (auto-regression), это значит, что созданная переменная добавляется в последовательность в качестве входных данных. В машинном обучении часто применяется эта техника, особенно в работе с временными рядами.
Хотя рекуррентная сеть и должна работать со всей последовательностью, к сожалению, присутствует проблема "затухающего градиента"(vanishing gradient problem). Что значит, что более старые входы не влияют на текущий выход. Такие модели, как LSTM пытаются решить эту проблему, добавляя дополнительные параметры (картинка 2).
Такие модели считывают ввод данных последовательно.
Архитектура, в которой обработка последовательности производится сразу, что практически не оставляет места для потери информации, реализована в кодировщике модели Transformer. Эта характеристика позволяет модели изучать контекст переменной на основе всего его окружения. Кроме того, по сравнению с рекуррентными нейросетями, чаще всего они быстрее.
@machinelearning_interview
Как создавать качественные ML-системы
Команда VK Cloud перевела серию из двух статей, посвященных ML-системам. В первой статье разобрались, почему каждый проект надо начинать с плана, обсудили жизненный цикл ML-проекта, выяснили, как определять его ценность для бизнеса и собирать требования, а заодно поговорили о важности проектной документации на этом этапе.
Во второй статье остановились на Data-centric ИИ, данных для обучения, разметке и очистке, синтетических данных и еще немного о Data Engineering и ETL.
@machinelearning_interview
Команда VK Cloud перевела серию из двух статей, посвященных ML-системам. В первой статье разобрались, почему каждый проект надо начинать с плана, обсудили жизненный цикл ML-проекта, выяснили, как определять его ценность для бизнеса и собирать требования, а заодно поговорили о важности проектной документации на этом этапе.
Во второй статье остановились на Data-centric ИИ, данных для обучения, разметке и очистке, синтетических данных и еще немного о Data Engineering и ETL.
@machinelearning_interview
📌 Почему длина контекста так важна при работе с большими языковыми моделями? Как обходить ограничения длины контекста?
Длина контекста – один из важнейших лимитирующих факторов при работе с большими языковыми моделями. Увеличить контекст до 100K – это уже невероятное достижение, ставшее реальностью (занятно, как этот тезис будет восприниматься через год).
Вот как выглядит один из важных практических случаев, в которых желательно применять большие языковые модели: «забросить в LLM целую кучу пользовательских данных (документов, касающихся работы компании либо конкретной задачи; также это могут быть различные разнородные тексты, т.д.) и задавать вопросы по этим конкретным данным, а не по какой-нибудь взятой из Интернета отвлечённой информации, которую LLM видела на этапе обучения.
В настоящее время обходить это ограничение пробуют по-разному, а именно:
▪При помощи приёмов резюмирования и изощрённых сцепленных затравок
▪Ведя векторные базы данных, в которых хранятся векторы для пользовательских документов с последующим «поиском» по этому корпусу в соответствии с некоторой метрикой схожести
▪Когда это возможно – тонко настраивать LLM на данных, предоставляемых пользователем (такая возможность предоставляется не во всех коммерческих LLM, а для опенсорсных LLM это не самая тривиальная задача)
▪Разработка специализированных сравнительно небольших LLM для конкретных данных, которые нас интересуют (опять же, не самая тривиальная задача)
При наличии длинного контекстного окна уже имеющаяся в вашем распоряжении большая языковая модель (видевшая целый Интернет) может изучить имеющийся у вас контекст и данные, а затем взаимодействовать с вами на совершенно ином уровне, предполагающем более высокую персонализацию. Всё это – без изменения весов модели, когда всё «обучение» производится на лету, «в памяти». В целом, чем больше контекстное окно, тем более высокая точность, беглость и изобретательность приобретается моделью.
В качестве аналогии здесь можно рассмотреть ОЗУ компьютера, где операционная система хранит в режиме реального времени актуальный контекст для всех ваших приложений. LLM, располагая достаточно длинным контекстом, сравнима с «рассуждающим компьютером», учитывающим широкий контекст, предоставляемый пользователем.
Оригинальный трансформер и длина контекста
Важно отметить, что в архитектуре транмформеров формы всех весов матриц, доступных для обучения, не зависят от количества подаваемых на вход токенов n. Все параметры, поддающиеся обучению (поиск по векторам, слои проекций, слой softmax и слои внимания) не зависят от длины входного фрагмента и должны быть в состоянии обрабатывать такие фрагменты варьирующейся длины. Просто отлично, когда такое свойство в архитектуре предоставляется прямо «из коробки».
Это значит, что, если вы обучали трансформерную модель с контекстным окном длиной 2K, то можете экстраполировать её на последовательности токенов любой длины. Единственная проблема здесь в том, что в таком случае модель не сможет методом вывода дать осмысленных результатов на материале в 100K токенов, если её не обучали на окне контекста длиной 100K. В таком случае распределение учебных данных будет очень далеким от тех данных, которые приходится логически обрабатывать, поэтому модель потерпит фиаско, как и любая модель машинного обучения в таком сценарии.
Если требуется обучить трансформер на таком большом контексте, то можно, например, обучать его в два этапа: сначала базовую модель на окне контекста длиной 2K токенов, а потом продолжить обучение (в качестве тонкой настройки) на более длинных контекстах (например, 65K или 100K). Именно это и было сделано с моделью MosaicML. Но вот загвоздка: такой подход не сработает с оригинальной архитектурой Трансформеров, поэтому придётся прибегать к определённым ухищрениям.
@machinelearning_interview
Длина контекста – один из важнейших лимитирующих факторов при работе с большими языковыми моделями. Увеличить контекст до 100K – это уже невероятное достижение, ставшее реальностью (занятно, как этот тезис будет восприниматься через год).
Вот как выглядит один из важных практических случаев, в которых желательно применять большие языковые модели: «забросить в LLM целую кучу пользовательских данных (документов, касающихся работы компании либо конкретной задачи; также это могут быть различные разнородные тексты, т.д.) и задавать вопросы по этим конкретным данным, а не по какой-нибудь взятой из Интернета отвлечённой информации, которую LLM видела на этапе обучения.
В настоящее время обходить это ограничение пробуют по-разному, а именно:
▪При помощи приёмов резюмирования и изощрённых сцепленных затравок
▪Ведя векторные базы данных, в которых хранятся векторы для пользовательских документов с последующим «поиском» по этому корпусу в соответствии с некоторой метрикой схожести
▪Когда это возможно – тонко настраивать LLM на данных, предоставляемых пользователем (такая возможность предоставляется не во всех коммерческих LLM, а для опенсорсных LLM это не самая тривиальная задача)
▪Разработка специализированных сравнительно небольших LLM для конкретных данных, которые нас интересуют (опять же, не самая тривиальная задача)
При наличии длинного контекстного окна уже имеющаяся в вашем распоряжении большая языковая модель (видевшая целый Интернет) может изучить имеющийся у вас контекст и данные, а затем взаимодействовать с вами на совершенно ином уровне, предполагающем более высокую персонализацию. Всё это – без изменения весов модели, когда всё «обучение» производится на лету, «в памяти». В целом, чем больше контекстное окно, тем более высокая точность, беглость и изобретательность приобретается моделью.
В качестве аналогии здесь можно рассмотреть ОЗУ компьютера, где операционная система хранит в режиме реального времени актуальный контекст для всех ваших приложений. LLM, располагая достаточно длинным контекстом, сравнима с «рассуждающим компьютером», учитывающим широкий контекст, предоставляемый пользователем.
Оригинальный трансформер и длина контекста
Важно отметить, что в архитектуре транмформеров формы всех весов матриц, доступных для обучения, не зависят от количества подаваемых на вход токенов n. Все параметры, поддающиеся обучению (поиск по векторам, слои проекций, слой softmax и слои внимания) не зависят от длины входного фрагмента и должны быть в состоянии обрабатывать такие фрагменты варьирующейся длины. Просто отлично, когда такое свойство в архитектуре предоставляется прямо «из коробки».
Это значит, что, если вы обучали трансформерную модель с контекстным окном длиной 2K, то можете экстраполировать её на последовательности токенов любой длины. Единственная проблема здесь в том, что в таком случае модель не сможет методом вывода дать осмысленных результатов на материале в 100K токенов, если её не обучали на окне контекста длиной 100K. В таком случае распределение учебных данных будет очень далеким от тех данных, которые приходится логически обрабатывать, поэтому модель потерпит фиаско, как и любая модель машинного обучения в таком сценарии.
Если требуется обучить трансформер на таком большом контексте, то можно, например, обучать его в два этапа: сначала базовую модель на окне контекста длиной 2K токенов, а потом продолжить обучение (в качестве тонкой настройки) на более длинных контекстах (например, 65K или 100K). Именно это и было сделано с моделью MosaicML. Но вот загвоздка: такой подход не сработает с оригинальной архитектурой Трансформеров, поэтому придётся прибегать к определённым ухищрениям.
@machinelearning_interview
🚀 Расскажите что такое утечка данных в машинном обучении? В чём суть проблемы ?
Из-за утечки данных может возникнуть неприятная ситуация: во время обучения модель выдаст нереалистично высокие показатели эффективности, а в реальных условиях будет работать совсем не так. Проще говоря, во время обучения модель запомнила информацию, к которой у неё не должно было быть доступа, и из-за этого метрики эффективности получились искусственно завышенными.
Представьте, что вы готовитесь к экзамену по математике. Вы решаете много задач, чтобы получше натренироваться. И тут выясняете, что вопросы к экзамену случайно выложили в интернет. У вас есть доступ к этой критически важной информации и возможность всё решить. То есть вы начинаете учиться на датасете, который, по идее, должен был попасть к вам только на экзамене, и таким образом вы «запоминаете» паттерны. Результат? Вы вызубрили задачи «тестового датасета» и получили нереалистично высокую оценку за эту часть экзамена, но когда речь заходит о выполнении реальных задач… лучше даже не говорить, что будет.
Утечка информации о целевой переменной
Распознать утечку информации о целевой переменной — дело непростое. Представьте себе: вы создаёте модель, которая предсказывает, отменят ли клиенты ежемесячную подписку на ваш сервис, то есть их отток. На первый взгляд не кажется проблемой включение в модель «количества звонков клиента в службу поддержки». Ведь можно считать, что много звонков свидетельствует о высокой вероятности оттока клиентов.
Но при пристальном рассмотрении выясняется, что «количество звонков в службу поддержки» — это следствие, а не причина ухода. Клиенты, которые уже решили отказаться от сервиса, просто звонят уладить оставшиеся вопросы, прежде чем окончательно отписаться. Так что эта информация будет недоступна на тот момент, когда нужно спрогнозировать, уйдёт клиент или нет. Иными словами, она известна нам только по клиентам, которые уже решили уйти.
Если в состав признаков попадёт целевая переменная или любые прокси-метрики, которые можно прямо или косвенно извлечь из неё, это может привести к утечке данных.
Контаминация обучающих и тестовых данных и утечка данных во время предварительной обработки
Такое происходит, когда одни и те же этапы предварительной обработки данных применяются и к обучающему, и к тестовому датасетам. Например, возьмём этапы предварительной обработки: нормализацию признаков, оценку недостающих данных и удаление исключений. Здесь нужно убедиться, что мы не используем тестовый датасет для «обучения», как показано ниже.
Мы заранее разделяем датасет на учебный и тестовый, чтобы можно было тренироваться только на обучающем датасете. Обратите внимание, что не нужно тренировать модель на целом датасете, включающем и обучающую, и тестовую выборку. Это приведёт к утечке данных, ведь модель будет тренироваться на данных, которую ей не нужно было показывать. Иными словами, тестовый датасете неизвестен ей на момент прогнозирования.
Тренируйте модель на обучающих данных, выполняйте преобразования и с обучающими, и с тестовыми данными.
Последствия утечки данных
Модель показывает чрезвычайно высокую эффективность при обучении, а тестовый датасет даёт крайне низкие результаты — знакомая ситуация? Возможно, всё дело в утечке данных. Здесь ключевые слова это «чрезмерное обучение» и «неспособность генерализации». Модель натренировалась на шуме и нерелевантной информации, что привело к низкой эффективности при работе с реальным тестовым датасетом.
В конечном счёте из-за неточной оценки модели вы получаете ненадёжные прогнозы. Это бессмысленная трата ресурсов!
@machinelearning_interview
Из-за утечки данных может возникнуть неприятная ситуация: во время обучения модель выдаст нереалистично высокие показатели эффективности, а в реальных условиях будет работать совсем не так. Проще говоря, во время обучения модель запомнила информацию, к которой у неё не должно было быть доступа, и из-за этого метрики эффективности получились искусственно завышенными.
Представьте, что вы готовитесь к экзамену по математике. Вы решаете много задач, чтобы получше натренироваться. И тут выясняете, что вопросы к экзамену случайно выложили в интернет. У вас есть доступ к этой критически важной информации и возможность всё решить. То есть вы начинаете учиться на датасете, который, по идее, должен был попасть к вам только на экзамене, и таким образом вы «запоминаете» паттерны. Результат? Вы вызубрили задачи «тестового датасета» и получили нереалистично высокую оценку за эту часть экзамена, но когда речь заходит о выполнении реальных задач… лучше даже не говорить, что будет.
Утечка информации о целевой переменной
Распознать утечку информации о целевой переменной — дело непростое. Представьте себе: вы создаёте модель, которая предсказывает, отменят ли клиенты ежемесячную подписку на ваш сервис, то есть их отток. На первый взгляд не кажется проблемой включение в модель «количества звонков клиента в службу поддержки». Ведь можно считать, что много звонков свидетельствует о высокой вероятности оттока клиентов.
Но при пристальном рассмотрении выясняется, что «количество звонков в службу поддержки» — это следствие, а не причина ухода. Клиенты, которые уже решили отказаться от сервиса, просто звонят уладить оставшиеся вопросы, прежде чем окончательно отписаться. Так что эта информация будет недоступна на тот момент, когда нужно спрогнозировать, уйдёт клиент или нет. Иными словами, она известна нам только по клиентам, которые уже решили уйти.
Если в состав признаков попадёт целевая переменная или любые прокси-метрики, которые можно прямо или косвенно извлечь из неё, это может привести к утечке данных.
Контаминация обучающих и тестовых данных и утечка данных во время предварительной обработки
Такое происходит, когда одни и те же этапы предварительной обработки данных применяются и к обучающему, и к тестовому датасетам. Например, возьмём этапы предварительной обработки: нормализацию признаков, оценку недостающих данных и удаление исключений. Здесь нужно убедиться, что мы не используем тестовый датасет для «обучения», как показано ниже.
scaler = StandardScaler()
scaler.fit(X_train)
scaler.transform(X_train)
scaler.transform(X_test)Мы заранее разделяем датасет на учебный и тестовый, чтобы можно было тренироваться только на обучающем датасете. Обратите внимание, что не нужно тренировать модель на целом датасете, включающем и обучающую, и тестовую выборку. Это приведёт к утечке данных, ведь модель будет тренироваться на данных, которую ей не нужно было показывать. Иными словами, тестовый датасете неизвестен ей на момент прогнозирования.
Тренируйте модель на обучающих данных, выполняйте преобразования и с обучающими, и с тестовыми данными.
Последствия утечки данных
Модель показывает чрезвычайно высокую эффективность при обучении, а тестовый датасет даёт крайне низкие результаты — знакомая ситуация? Возможно, всё дело в утечке данных. Здесь ключевые слова это «чрезмерное обучение» и «неспособность генерализации». Модель натренировалась на шуме и нерелевантной информации, что привело к низкой эффективности при работе с реальным тестовым датасетом.
В конечном счёте из-за неточной оценки модели вы получаете ненадёжные прогнозы. Это бессмысленная трата ресурсов!
@machinelearning_interview
Лучший способ получать свежие обновлении и следить за трендами в разработке.
Машинное обучение: t.iss.one/ai_machinelearning_big_data
Python: t.iss.one/pythonl
C#: t.iss.one/csharp_ci
C/C++/ t.iss.one/cpluspluc
Data Science: t.iss.one/data_analysis_ml
Devops: t.iss.one/devOPSitsec
Go: t.iss.one/Golang_google
Базы данных: t.iss.one/sqlhub
Rust: t.iss.one/rust_code
Javascript: t.iss.one/javascriptv
React: t.iss.one/react_tg
PHP: t.iss.one/phpshka
Android: t.iss.one/android_its
Мобильная разработка: t.iss.one/mobdevelop
Linux: t.iss.one/+A8jY79rcyKJlYWY6
Big Data: t.iss.one/bigdatai
Хакинг: t.iss.one/linuxkalii
Тестирование: https://t.iss.one/+F9jPLmMFqq1kNTMy
Java: t.iss.one/javatg
Папка Go разработчика: t.iss.one/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: t.iss.one/addlist/eEPya-HF6mkxMGIy
Папка машинное обучение: https://t.iss.one/addlist/_FjtIq8qMhU0NTYy
🇬🇧Английский: t.iss.one/english_forprogrammers
Please open Telegram to view this post
VIEW IN TELEGRAM
Docker - это программный продукт, который программисты могут использовать для упаковки своего кода.
1. Что такое Docker?
Работодатель может задать вам этот вопрос, чтобы оценить ваше базовое понимание и опыт использования программы. Глубокое знание этого инструмента может показать вашу способность применять его в различных программных приложениях. Вы можете ответить, дав определение Docker и рассказав о его важности.
Пример: Docker - это платформа контейнеризации, которую программисты могут использовать для развертывания приложений в облачных вычислениях. Системные администраторы могут использовать платформу для масштабирования больших объемов данных в контейнерах и повышения эффективности работы приложений.
• Docker можно использовать как файловую систему, в которой хранится все, что требуется для работы программы, например, код, зависимости и системные инструменты. Этот контейнер может позволить программистам запускать программное обеспечение на нескольких платформах без конфликтов зависимостей.
2. Чем контейнерные технологии отличаются от виртуализации гипервизоров?
Работодатели могут задать этот вопрос, чтобы определить, понимаете ли вы преимущества использования Docker по сравнению с виртуализированными средами. Ваш ответ также может рассказать о вашем опыте использования гипервизоров для управления выполнением программ. В своем ответе вы можете сосредоточиться на определении двух технологий и объяснить особенности Docker, которые дают ему преимущества перед гипервизорами.
Пример: Гипервизор - это программное обеспечение, которое позволяет пользователям создавать и запускать виртуальные машины. Docker - это платформа, которую можно использовать для упаковки программного обеспечения и запуска его в любой среде. Запуск приложения в Docker занимает меньше шагов, чем запуск в виртуальной среде.
• Для виртуализации машин требуется целая гостевая операционная система, в то время как Docker содержит только приложение и его библиотеки. Поскольку для запуска Docker система может использовать меньшее количество шагов, контейнер развертывается быстрее, чем виртуализация гипервизора.
3. Как Docker повлиял на виртуализацию и облачные среды?
📌 Продолжение
@machinelearning_interview
Please open Telegram to view this post
VIEW IN TELEGRAM
📌 Форматы файлов Big Data для озера данных. Расскажите о Apache Parquet и его реализации.
Apache Parquet — это столбчатый формат хранения для обработки больших данных. Он активно используется в экосистеме Hadoop. Несмотря на снижение ее популярности, этот формат остается весьма распространенным — отчасти потому, что он все еще поддерживается ключевыми системами обработки данных, в том числе Apache Spark, Apache Flink и Apache Drill.
Реализованный в Parquet способ организации данных оптимизирует их для столбчатых операций, таких как фильтрация и агрегирование. Чтобы хранить данные с высокой эффективностью, в Parquet используется сочетание приемов сжатия и кодирования.
Формат позволяет создавать схемы, поддерживающие применение ограничений по типам данных и обработку с высокой скоростью. Parquet — популярное решение для хранения больших наборов и запросов к ним, поскольку в этом формате запросы выполняются быстро, а хранение и обработка — эффективно.
Обзор реализации
Эта схема (картинка) позволяет эффективно фиксировать метаданные, поддерживает эволюцию файлового формата и упрощает хранение. Алгоритмы сжатия Parquet снижают требования к объемам хранилища, позволяют быстрее извлекать данные и поддерживаются множеством фреймворков.
Есть три типа метаданных:
👇Напишите в комментариях, что вы знаете о формате ORC, (Optimized Row Columnar).
@machinelearning_interview
Apache Parquet — это столбчатый формат хранения для обработки больших данных. Он активно используется в экосистеме Hadoop. Несмотря на снижение ее популярности, этот формат остается весьма распространенным — отчасти потому, что он все еще поддерживается ключевыми системами обработки данных, в том числе Apache Spark, Apache Flink и Apache Drill.
Реализованный в Parquet способ организации данных оптимизирует их для столбчатых операций, таких как фильтрация и агрегирование. Чтобы хранить данные с высокой эффективностью, в Parquet используется сочетание приемов сжатия и кодирования.
Формат позволяет создавать схемы, поддерживающие применение ограничений по типам данных и обработку с высокой скоростью. Parquet — популярное решение для хранения больших наборов и запросов к ним, поскольку в этом формате запросы выполняются быстро, а хранение и обработка — эффективно.
Обзор реализации
Эта схема (картинка) позволяет эффективно фиксировать метаданные, поддерживает эволюцию файлового формата и упрощает хранение. Алгоритмы сжатия Parquet снижают требования к объемам хранилища, позволяют быстрее извлекать данные и поддерживаются множеством фреймворков.
Есть три типа метаданных:
файла, столбца (фрагмента) и заголовка страницы. Для сериализации и десериализации структур метаданных в Parquet используется Thrift TCompactProtocol.👇Напишите в комментариях, что вы знаете о формате ORC, (Optimized Row Columnar).
@machinelearning_interview
📌 Форматы данных и файлов. Расскажите о формате стерилизации MessagePack.
MessagePack — это формат сериализации, который обеспечивает компактное бинарное представление структурированных данных. Он эффективнее и быстрее других форматов сериализации, таких как JSON, благодаря представлению в двоичном, а не в текстовом формате. MessagePack применяют в распределенных системах, микросервисах и хранилищах данных. Он поддерживается множеством языков программирования, в том числе
Его часто используют, чтобы передавать данные по сети или хранить их в компактном формате. Кроме того, MessagePack — это расширяемый формат, так что пользователи могут определять собственные типы и структуры.
Обзор реализации
Благодаря возможности добавлять и удалять ключи обеспечивается расширяемость с JSON. Его изначальная реализация — это заголовок, за которым следует объект MessagePack со структурой:
Преобразования метаданных унаследованы от предыдущих версий, а новые версии включают V2Obj или DelObj в зависимости от активной операции при получении запросов на обновление. В сущности, когда нам нужно просто прочитать метаданные, можно остановить чтение файла, дочитав до их конца. Для получения обновлений нужно максимум два непрерывных чтения. Для этого меняется и представление на диске. Раньше все метаданные хранились как большой объект, содержащий все версии. Теперь мы пишем это следующим образом:
▪сигнатура с версией;
▪версия данных заголовка (целое число);
▪версия метаданных (целое число);
▪счетчик версий (целое число).
@machinelearning_interview
MessagePack — это формат сериализации, который обеспечивает компактное бинарное представление структурированных данных. Он эффективнее и быстрее других форматов сериализации, таких как JSON, благодаря представлению в двоичном, а не в текстовом формате. MessagePack применяют в распределенных системах, микросервисах и хранилищах данных. Он поддерживается множеством языков программирования, в том числе
C++, Python и Java. Его часто используют, чтобы передавать данные по сети или хранить их в компактном формате. Кроме того, MessagePack — это расширяемый формат, так что пользователи могут определять собственные типы и структуры.
Обзор реализации
Благодаря возможности добавлять и удалять ключи обеспечивается расширяемость с JSON. Его изначальная реализация — это заголовок, за которым следует объект MessagePack со структурой:
{
"Versions": [
{
"Type": 0, // Type of version, object with data or delete marker.
"V1Obj": { /* object data converted from previous versions */ },
"V2Obj": {
"VersionID": "", // Version ID for delete marker
"ModTime": "", // Object delete marker modified time
"PartNumbers": 0, // Part Numbers
"PartETags": [], // Part ETags
"MetaSys": {} // Custom metadata fields.
// More metadata
},
"DelObj": {
"VersionID": "", // Version ID for delete marker
"ModTime": "", // Object delete marker modified time
"MetaSys": {} // Delete marker metadata
}
}
]
}Преобразования метаданных унаследованы от предыдущих версий, а новые версии включают V2Obj или DelObj в зависимости от активной операции при получении запросов на обновление. В сущности, когда нам нужно просто прочитать метаданные, можно остановить чтение файла, дочитав до их конца. Для получения обновлений нужно максимум два непрерывных чтения. Для этого меняется и представление на диске. Раньше все метаданные хранились как большой объект, содержащий все версии. Теперь мы пишем это следующим образом:
▪сигнатура с версией;
▪версия данных заголовка (целое число);
▪версия метаданных (целое число);
▪счетчик версий (целое число).
@machinelearning_interview
📌Назовите способы и инструменты сбора данных
В течение многих веков люди собирали данные вручную. Даже сегодня, в эпоху ChatGPT, мы всё ещё заполняем бумажные документы и вводим числа и слова в файл Excel для фиксации событий и наблюдений. Однако процессы, в которых задействованы бумажные документы и ручной ввод данных, длительны, трудоёмки и, что хуже сего, подвержены человеческим ошибкам.
Ручной сбор данных всё ещё применим в мелких компаниях, но более крупные склонны отдавать на аутсорс эти монотонные и повторяющиеся задачи или максимально их автоматизировать. Ниже мы рассмотрим наиболее популярные методики упрощения сбора данных.
Извлечение данных при помощи интерфейсов программирования приложений
Application programming interface (API) — это слой ПО, позволяющий программам взаимодействовать друг с другом. Для прямого доступа к своим данным большинство современных платформ раскрывают публичные или приватные API. Благодаря API система может автоматически собирать интересующий вас контент.
В отличие от веб-скрейпинга, подключения к API не представляют юридических трудностей, потому что их нельзя установить без разрешения источника данных, который может накладывать ограничения на количество запросов и типы доступного контента. Также он определяет формат данных, но чаще всего вам придётся иметь дело с файлами JSON, которые обычно используются в современных REST API.
Оптическое распознавание символов
Optical character recognition (OCR) — это технология, распознающая печатный или рукописный текст в отсканированных документах, изображениях PDF и других файлах, а затем преобразующая его в машиночитаемый электронный вид. Она позволяет не только быстро оцифровывать бумажные документы, но и извлекать ценный контент из различных документов, делая его доступным для дальнейшей обработки.
Полнофункциональные системы наподобие ABBYY FineReader PDF и OCR-решения Google используют машинное обучение для анализа структуры документа и распознавания текста вне зависимости от его языка.
Автоматизация процессов
Robotic process automation (RPA) — это тип ПО, предназначенный для выполнения повторяющихся и монотонных повседневных операций, обычно выполняемых людьми. Среди прочего, RPA-боты способны выполнять некоторые действия, связанные со сбором данных, например, открывать электронные письма и вложения, собирать статистику в социальных сетях, извлекать данные из предварительно указанных полей в документах, считывать требуемые данные из баз данных и электронных таблиц, и так далее.
Традиционные RPA-инструменты способны работать только со структурированными и слабоструктурированными данными. Когда необходимо обрабатывать неструктурированные данные (которые, как мы помним, составляют 80-90% потенциально полезного контента), требуются более сложные решения на основе ИИ.
Интеллектуальная обработка документов
Intelligent document processing (IDP) включает в себя:
OCR для извлечения текста из сканов,
RPA для выполнения монотонных манипуляций со структурированными и слабоструктурированными данными, и
методики машинного обучения, в частности, компьютерное зрение и NLP, для классификации документов на основании текстов, изображений или визуальной структуры, извлечения значимой информации, очистки, упорядочивания и разметки неструктурированных данных с целью их подготовки для обучения моделей машинного обучения.
IDP может использоваться для сбора и очистки данных из заявлений о страховых случаях, медицинских форм, счетов, договоров и других документов, минимизируя вмешательство человека.
Веб-скрейпинг
Веб-скрейпинг — это автоматизированный способ сбора, фильтрации и структурирования данных с веб-сайтов. Обычно веб-скрейперы или боты обходят множество веб-страниц, собирая цены, подробности о товарах, комментарии пользователей и многое другое.
Стоит заметить, что не каждый вид веб-скрейпинга легален. Вы можете свободно скрейпить собственный веб-сайт и, в большинстве случаев, собирать публично доступные данные в Интернете (если они не скрыты за логином).
@machinelearning_interview
В течение многих веков люди собирали данные вручную. Даже сегодня, в эпоху ChatGPT, мы всё ещё заполняем бумажные документы и вводим числа и слова в файл Excel для фиксации событий и наблюдений. Однако процессы, в которых задействованы бумажные документы и ручной ввод данных, длительны, трудоёмки и, что хуже сего, подвержены человеческим ошибкам.
Ручной сбор данных всё ещё применим в мелких компаниях, но более крупные склонны отдавать на аутсорс эти монотонные и повторяющиеся задачи или максимально их автоматизировать. Ниже мы рассмотрим наиболее популярные методики упрощения сбора данных.
Извлечение данных при помощи интерфейсов программирования приложений
Application programming interface (API) — это слой ПО, позволяющий программам взаимодействовать друг с другом. Для прямого доступа к своим данным большинство современных платформ раскрывают публичные или приватные API. Благодаря API система может автоматически собирать интересующий вас контент.
В отличие от веб-скрейпинга, подключения к API не представляют юридических трудностей, потому что их нельзя установить без разрешения источника данных, который может накладывать ограничения на количество запросов и типы доступного контента. Также он определяет формат данных, но чаще всего вам придётся иметь дело с файлами JSON, которые обычно используются в современных REST API.
Оптическое распознавание символов
Optical character recognition (OCR) — это технология, распознающая печатный или рукописный текст в отсканированных документах, изображениях PDF и других файлах, а затем преобразующая его в машиночитаемый электронный вид. Она позволяет не только быстро оцифровывать бумажные документы, но и извлекать ценный контент из различных документов, делая его доступным для дальнейшей обработки.
Полнофункциональные системы наподобие ABBYY FineReader PDF и OCR-решения Google используют машинное обучение для анализа структуры документа и распознавания текста вне зависимости от его языка.
Автоматизация процессов
Robotic process automation (RPA) — это тип ПО, предназначенный для выполнения повторяющихся и монотонных повседневных операций, обычно выполняемых людьми. Среди прочего, RPA-боты способны выполнять некоторые действия, связанные со сбором данных, например, открывать электронные письма и вложения, собирать статистику в социальных сетях, извлекать данные из предварительно указанных полей в документах, считывать требуемые данные из баз данных и электронных таблиц, и так далее.
Традиционные RPA-инструменты способны работать только со структурированными и слабоструктурированными данными. Когда необходимо обрабатывать неструктурированные данные (которые, как мы помним, составляют 80-90% потенциально полезного контента), требуются более сложные решения на основе ИИ.
Интеллектуальная обработка документов
Intelligent document processing (IDP) включает в себя:
OCR для извлечения текста из сканов,
RPA для выполнения монотонных манипуляций со структурированными и слабоструктурированными данными, и
методики машинного обучения, в частности, компьютерное зрение и NLP, для классификации документов на основании текстов, изображений или визуальной структуры, извлечения значимой информации, очистки, упорядочивания и разметки неструктурированных данных с целью их подготовки для обучения моделей машинного обучения.
IDP может использоваться для сбора и очистки данных из заявлений о страховых случаях, медицинских форм, счетов, договоров и других документов, минимизируя вмешательство человека.
Веб-скрейпинг
Веб-скрейпинг — это автоматизированный способ сбора, фильтрации и структурирования данных с веб-сайтов. Обычно веб-скрейперы или боты обходят множество веб-страниц, собирая цены, подробности о товарах, комментарии пользователей и многое другое.
Стоит заметить, что не каждый вид веб-скрейпинга легален. Вы можете свободно скрейпить собственный веб-сайт и, в большинстве случаев, собирать публично доступные данные в Интернете (если они не скрыты за логином).
@machinelearning_interview
Такое обучение, которое ещё называется pre-training, решает задачу моделирования языка или, говоря проще, позволяет нашей модели выучить (насколько это возможно) язык, с которым она работает.
Для этого обучение проходит в парадигме Masked Language Modeling, MLM (проходим по тексту, маскируем по очереди каждый токен и пытаемся по окружающим его токенам – контексту предсказать этот токен) и Next Sentence Prediction, NSP (предсказание по паре текстовых фрагментов, следуют они друг за другом или нет). Есть ещё также Casual Language Modeling, но MLM обычно используется чаще.
На практике прибегнуть к процедуре pre-training может быть полезно, когда тексты, с которыми нужно работать, отличны от тех, на которых обучались общедоступные известные модели. Это может происходить в следующих случаях:
•специфичный стиль текста, его структура (яркий пример – юридические тексты, договора, сметы),
•наличие специфичных терминов (пример – медицинские тексты).
На что стоит обратить внимание перед процедурой pre-training:
•данные, с которыми вы работаете, может быть недостаточно для эффективного обучения модели, поэтому даже обладая хорошим потенциалом, они могут не обучиться и показывать такое же либо даже худшее качество по сравнению с бейзлайном;
• хорошие эмбеддинги – это лишь один из этапов во всём пайплайне и вовсе не единственная точка роста. Поэтому если вы стоите перед выбором, стоит ли тратить ресурсы на pre-training, аренду видеокарт и т.д., возможно, стоит сначала сделать упор на другие вещи, например, на более качественный сбор/обработку/обогащение данных.
Если решили идти по этому пути, то рабочим вариантом может быть следующий: взять веса общедоступной модели, обученной на таких текстах, как Википедия, затем обучить её на собственных текстах в парадигме MLM, дав возможность изучить тонкости именно ваших текстов. А затем снова дообучить в парадигме fine-tuning для решения целевой задачи.
Можно взять классический Bert. Но c другой стороны, с его создания уже утекло много воды и появились более продвинутые архитектуры. Особенно заслуживают внимания следующие архитектуры.
RoBERTa (A Robustly Optimized BERT Pre-training Approach) – это архитектура, основанная на BERT, но в которой оптимизировали параметры обучения, отказались от обучения в парадигме NSP и показали, что так качество будет выше.
DeBERTa (Decoding-enhanced BERT with disentangled attention) – дословно BERT улучшенного декодирования с рассеянным вниманием. Это основанная на RoBERTa архитектура, в которой авторы дополнительно применили механизм кодирования слова двумя векторами (кодирующими его содержание и положение в тексте) и заменили выходной softmax-слоя усовершенствованным декодером. Вот пример успешного применения этой архитектуры.
ELECTRA – архитектура (оригинальная статья), в которой отказались от обучения в парадигмах MLM и NSP и тренируют генератор и дискриминатор. Первая модель учится выборочно заменять токены в тексте, а вторая (которую и будем использовать после обучения) учится определять токены, которые были заменены, и таким образом осваивает структуру языка. Архитектура модели и её преимущества довольно подробно расписаны в статье Более эффективное предварительное обучение NLP моделей с ELECTRA.
@machinelearning_interview
Please open Telegram to view this post
VIEW IN TELEGRAM