A Conceptual Explanation of Bayesian Hyperparameter Optimization for Machine Learning [2018]

Неделю назад я писал пост про Evolution Strategies. Напомню его область применения:

1) Есть не очень большое пространство параметров
2) Есть функция качества этих параметров, но нет доступа к каким-либо градиентам

Эта область применения не так уж и редко встречается в реальной жизни, и чаще всего это происходит в контексте оптимизации гиперпараметров. В этом случае появляется ещё одно обстоятельство:

3) Функцию качества очень долго и дорого считать

В данной ситуации мы хотим максимально эффективно использовать этот ресурс, извлекать и переиспользовать максимальное количество информации из её замеров. Стандартный Evolution Strategies в этом плане достаточно туп - каждая итерация алгоритма происходит "с чистого листа", а точки для замера выбираются с помощью добавления шума.

Именно здесь на сцену выходит Bayesian model-based optimization. Это целое семейство методов, но все они работают по примерно одному и тому же принципу:

1) Мы пытаемся аппроксимировать распределение P(objective | params)
2) Мы используем каждое наше измерение для обучения этой аппроксимации
3) Выбор следующих кандидатов происходит по-умному, балансируя между неисследованными областями в пространстве параметров и проверкой тех областей, в которых мы ожидаем получить хорошее значение функции

Исследуя всё больше и больше точек, мы получаем всё более точную аппроксимацию функции, как показано на картинке. Остаётся выбрать, каким образом моделировать распределение и выбирать кандидатов.

Один из вариантов, используемых на практике, выглядит так:

- При выборе следующих кандидатов мы максимизируем нечто похожее на "мат. ожидание" P(objective | params), но интеграл берётся только по "хорошим" значениям objective - это называется Expected Improvement
- Для оценки P(objective | params) мы формулу Байеса и переходим к моделированию P(params | objective), которое в свою очередь является композицией из двух распределений P(params) - для "хороших" значений objective и для "плохих" - эти распределения называется`L(params) и `G(params).
- В пунктах выше я упоминал "хорошие" и "плохие" значения. Порог, который их разделяет, выбирается как квантиль уже собранного нами множества значений objective.

При применении капельки математики получается, что Expected Improvement максимизируется в тех точках, в которых максимизируется` L(params) / G(params). Эти точки мы пытаемся найти, сэмплируя много раз из `L(params) и пересчитывая это соотношение. Вся эта схема называется Tree-structured Parzen Estimator.

Описанная процедура гораздо хитрее и тяжелее, чем Evolution Strategies, но всё это несопоставимо дешевле и быстрее, чем каждый подсчёт значения Objective(params). Таким образом, метод хорошо подходит для таких ситуаций, как оптимизация гиперпараметров обучения, и используется в качестве одного из основных в библиотеке Hyperopt.

Метод, конечно, не идеален - он не учитывает зависимости параметров между собой. Это может ограничивать область применения и мешать методу работать для оптимизации более запутанных схем. Бесплатные обеды, как обычно, не завезли.

@knowledge_accumulator

Ужасы поиска работы от Mimansa Jaiswal

Сегодня в твиттере я увидел весьма интересный тред об опыте поиска работы прошлой осенью от Mimansa Jaiswal. У неё есть PhD в Computer Science, опыт работы стажёром в Facebook AI, Allen и год опыта работы в ещё одной компании. Плюс 10+ опубликованных статей (часть во времена BERT, часто в настоящее время).

И вот она рассказывает, как осенью 2024 искала работу - подавалась в 200 компаний, было ~100 собеседований. Текст очень интересный - про подходы к поиску работы, про различия между стартапами и BigTech и многое другое.

Вот некоторые интересные моменты:

Общее:
• Искала работу связанную с ресерчем - общие применения LLM или работа над SOTA. Чисто инженерные позиции или разработка продуктов типа чат-ботов её не интересовали. Хотелось work-life balance и работа в Seattle или сравнимой локации.
• Основные способы поиска работы: подаваться через сайты компаний напрямую, писать рекрутёрам и hiring manager в LinkedIn, добывать рефералы
• Полно мини хоррор-историй о том, какие бывают общения с компаниями

Стартапы:
• Процессы собеседований сильно разнятся между компаниями. Из необычного: некоторые хотели проводить собеседования при личной стрече (не по созвону), некоторые хотели, чтобы кандидат несколько дней проработал у них (за оплату, конечно) как мини-триал вместо собеседований.
• Даже в таких молодых стартапах обычно было 5-6 раундов собеседований.
• Как можно ожидать, многие стартапы сразу озвучивали ожидания работать 6/7 дней в неделю или 12 часов в день.
• Нередко название позиции намекает на ресерч, а по факту оказывается, что нужна инженерная работа.
• Часто компании прекращают общение между этапами собеседований и перестают отвечать
• Стартапы обычно предлагают 150-250k$ gross в год и 0.2%–0.5% equity.

Unicorns (Anthropic, OpenAI, Scale):
• Дикое количество раундов у Anthropic - 10
• Не было раундов leetcode, часто можно было использовать дополнительные материалы (но без чат-ботов)

BigTech:
• Обычно процесс собеседований идёт 1.5-2.5 месяцев
• В Apple было... 12 раундов, у остальных компаний обычно около 6 +/- 2
• Процессы собесов были прозрачные, интервьюверы были профессиональными
• Некоторые компании всё-таки пропадали посередине общения
• В среднем компании предлагают 350-430k$ gross в год с учётом всех бонусов

Материалы для подготовки

#datascience

Claude Code

Вчера Antropic представили обновлённую модельку Sonnet 3.7 и вместе с ней локального агента Claude Code. Вместе с обновлением, которое значительно подняло метрики по выполнению кода, получилась пушка для как минимум хобби-разработчиков.

Агент работает по API, час работы выходит примерно 10-20$. Агент работает на локальной машине через свой терминал, запуская команды на локальной машине. За полтора часа работы у меня получилось "написать" ~5k строк C++ кода для системы быстрого построения графов при помощи locality-sensitive hashing проекций. Ничего сложного, но время разработки существенно скоратилось, а скаффолдинг можно и поправить.

За весь час я вообще не редактировал код, а давал только общие указания (напиши бенчмарк, напиши тесты). В результате получилась система, которая вроде бы даже работет – агент сам старается всё тестировать и себя проверять. В результате получилось написать то, на что у меня бы ушло недели две работы, да ещё и C++ вышел довольно читаемым.

Будущее, получается, уже совсем рядом – нужно только отстёгивать $20/час за такое удовольствие.

YandexGPT 5 уже в опенсорсе и Алисе

Сегодня Яндекс показал миру новое поколение больших языковых моделей — YandexGPT 5. Старшая модель YandexGPT 5 Pro доступна в чате с Алисой и Yandex Cloud через API. Ну а претрейн-версия младшей модели YandexGPT 5 Lite Pretrain — уже лежит на Hugging Face.

Все подробности о процессе обучения можно прочитать в статье на Хабре. А в этом посте — главные факты о свежей опенсорсной модели Яндекса.

YandexGPT 5 Lite Pretrain — модель на 8 миллиардов параметров с длиной контекста 32 тысячи токенов. Претрейн проходил в два этапа: сначала модель обучили на 15 триллионах токенов текста на русском и английском языках, а потом использовали 320 миллиардов токенов высококачественных данных, включая образовательный контент.

На первом этапе датасет больше чем на половину состоял из веб-документов, остальное — код, математика и специфичные данные. Под последними подразумеваются синтетика (сгенерированные YandexGPT 4 вопросы на основе проверенных источников) и внутренние наработки компании (например, внутренняя база Яндекса Fact Snippet и новый корпус данных Переводчика).

На втором этапе датасет на четверть состоял из веб-страниц и почти в равных пропорциях содержал математику, код и образовательные данные. Также была небольшая часть аугментаций фактовых документов, другой синтетики и датасетов сервисов.

По сравнению с моделью предыдущего поколения, YandexGPT 4 Lite Pretrain, новая модель показывает ощутимый рост качества в решении математических задач и написании кода. А в сравнении с зарубежными аналогами, такими как LLaMa3.1-8B и Qwen-2.5-7B-base, она лидирует почти во всех типах задач.

Ещё раз приглашаем пощупать модель, почитать статью на Хабре с деталями обучения и не забыть поделиться впечатлениями в комментариях!


ML Underhood

Как подойти к дизайну визуализации?🪜

Вчера в рассылке писала про модель Тамары Мунзнер, которая предлагает учитывать разные уровни вложенности в процессе визуализации. Идея в том, что ошибка на предыдущем уровне ломает все на следующем, поэтому важно идти по ступенькам:

👩‍💻1. Понимание домена – кто целевая аудитория и что они делают?
Самое опасное тут – неправильно понять конечные цели пользователей. Решать можно через качественный сбор требований:
- Dashbaord Canvas Ромы Бунина
- Про пользовательские интервью от Nielsen Group
- Jobs to be Done

🔎2. Задача и данные – какие данные мы показываем и зачем люди на них смотрят?
Из опасностей – выбор не тех данных и трансформация к ним, непревильно подобранные аналитические вопросы к данным
- Lean Anlaytics
- Как измерять?
- Дата команды и пониманием метрик бизнеса
- Одинаковые данные, разные вопросы

📊3. Визуальное представление – как это визуализировано?
Важен правильный выбор визуализаций.
- Как выбрать график?
- Эффективность базовых графиков
- Когнитивные искажения

🛠4. Валидация алгоритма – можем ли мы это сделать?
Проверка, что с визуализаций реально взаимодействовать и она технически реализуема.
- Про перфоманс дэшбордов в Tableau и перфоманс тестирование

#devops #mlops