Forwarded from Борис опять
В общем, коротко: SigLIP 2 это лучший на текущий момент CLIP.
К нему приделали все идеи из разных self-supervised методов современного CV и получилось хорошо:
1. Self-distillation при обучении как в DINO/DINOv2. Модель-ученик видит только локальный кроп изображения, модель-учитель (ema от обучаемой модели) глобальный кроп. Так что модель учится по деталям получать те же репрезентации, что и по всей картинке. Это, например, заставляет модель видя нос собаки мысленно "достраивать" всю собаку.
2. Маскировка патчей, что ставит некоторую задачу реконструкции, как в MAE (который Masked Autoencoders от FAIR).
3. Декодер. Прямо при обучении заставляют модель генерировать подписи, ббоксы и подписи к ббоксам. Это, по идее, самое важное: напрямую учат модель связи деталей изображения и текста.
Все это должно полечить вечную проблему клипов, что они хорошо понимают на уровне изображения и плохо понимают детали. Таким образом прошло долгожданное объединение contrastive learning и self supervised подходов.
Ещё подвезли версию устойчивую к разным разрешениям и размерам изображений.
Это конечно Франкенштейн с несколькими лоссами и стадиями тренировки, так что bitter lesson еще придет, но очень круто.
В общем, теперь если нужны какие-то эмбеддинги изображений и текстов берем с полки SigLIP2.
К нему приделали все идеи из разных self-supervised методов современного CV и получилось хорошо:
1. Self-distillation при обучении как в DINO/DINOv2. Модель-ученик видит только локальный кроп изображения, модель-учитель (ema от обучаемой модели) глобальный кроп. Так что модель учится по деталям получать те же репрезентации, что и по всей картинке. Это, например, заставляет модель видя нос собаки мысленно "достраивать" всю собаку.
2. Маскировка патчей, что ставит некоторую задачу реконструкции, как в MAE (который Masked Autoencoders от FAIR).
3. Декодер. Прямо при обучении заставляют модель генерировать подписи, ббоксы и подписи к ббоксам. Это, по идее, самое важное: напрямую учат модель связи деталей изображения и текста.
Все это должно полечить вечную проблему клипов, что они хорошо понимают на уровне изображения и плохо понимают детали. Таким образом прошло долгожданное объединение contrastive learning и self supervised подходов.
Ещё подвезли версию устойчивую к разным разрешениям и размерам изображений.
Это конечно Франкенштейн с несколькими лоссами и стадиями тренировки, так что bitter lesson еще придет, но очень круто.
В общем, теперь если нужны какие-то эмбеддинги изображений и текстов берем с полки SigLIP2.
Forwarded from Reliable ML
Почему во времена AI-революции стоит быть осторожным?
Заметки на полях
Решила тут Ирина почитать последние актуальные книги по GenAI - и по внедрению в прод, и про разное менеджерско-стратегическое. Нашлось как всякое интересное (могу потом сделать обзор, если интересно), так и очень интересное.
Например, книга Chief AI Officer Handbook от Packt Publishing. Которую уже после 1й главы начинаешь подозревать в чем-то нехорошем: уж слишком подозрительно структурирован текст, идеальным языком написаны итоги каждого раздела, а главное - уж больно бессмысленно все это в совокупности. До последнего не хотелось верить, что в такое издательство может проникнуть книга, так неприкрыто написанная LLM/ChatGPT, но более детальный разбор показал, что так оно и есть.
Грусть, возмущение и мысли о том, что бедным издательствам теперь будет трудно, и надо что-то менять, чтобы продолжать оставаться ценными для читаталей. А нам, читателям, тоже надо быть начеку и - если мы хотим получать действительно ценную информацию - уметь отличать сгенерированную LLM инфу от человеческой. Уже даже исследования появляются на тему того, что у человека это неплохо получается - лучше алгоритмов.
В голове - с учетом статей - собираются вот такие критерии для идентификации LLM-подставы:
- Очень характерный стиль изложения: выхолощенная, предсказуемая структура, с четкими абзацами и пошаговым изложением, где жирным выделены главные резюмирующие мысли (в начале каждого абзаца).
- Заключения всегда аккуратные, оптимистичные и резюмирующие
- Часто используются определенные слова. Судя по статье, например, vibrant, crucial, significantly, etc. А по личным наблюдениям, можно даже найти следы промптов в тексте - например step-by-step в заголовках книги про Chief AI Officer.
- Отсутствие понятного посыла или новых/интересных для читателя мыслей. Хотя как единственный критерий это, конечно, не работает. Всякие книги встречаются.
- Фактура спорная, неверная или очень общая. Пример критерия с высоким весом - ссылки на литературу ведут на несуществующие страницы.
- Ни одной (или мало) схем в тексте. У авторов-людей почти всегда есть потребность как-то визуально структурировать и показать наглядно мысли, которые они передают в тексте. Для LLM-текста - человек должен заморочиться отдельным промптом, чтобы собрать подобное. А возможно, даже осмыслить тот текст, который ему написала модель. Это уже существенно отдалит его от полностью сгенеренного.
Есть ли у вас что добавить к списку критериев? Не дадим LLM захватить литературу!
Вот такой вот дивный новый мир. На фоне размышлений о будущем после книги про AI Officers мне вспоминается история из великого башорга. Для тех, кто еще помнит😄
На картинке - скрин из книги с заголовком с кусочком промпта.
Ваш @Reliable ML
#business #мысли #reliable_ml #llm
Заметки на полях
Решила тут Ирина почитать последние актуальные книги по GenAI - и по внедрению в прод, и про разное менеджерско-стратегическое. Нашлось как всякое интересное (могу потом сделать обзор, если интересно), так и очень интересное.
Например, книга Chief AI Officer Handbook от Packt Publishing. Которую уже после 1й главы начинаешь подозревать в чем-то нехорошем: уж слишком подозрительно структурирован текст, идеальным языком написаны итоги каждого раздела, а главное - уж больно бессмысленно все это в совокупности. До последнего не хотелось верить, что в такое издательство может проникнуть книга, так неприкрыто написанная LLM/ChatGPT, но более детальный разбор показал, что так оно и есть.
Грусть, возмущение и мысли о том, что бедным издательствам теперь будет трудно, и надо что-то менять, чтобы продолжать оставаться ценными для читаталей. А нам, читателям, тоже надо быть начеку и - если мы хотим получать действительно ценную информацию - уметь отличать сгенерированную LLM инфу от человеческой. Уже даже исследования появляются на тему того, что у человека это неплохо получается - лучше алгоритмов.
В голове - с учетом статей - собираются вот такие критерии для идентификации LLM-подставы:
- Очень характерный стиль изложения: выхолощенная, предсказуемая структура, с четкими абзацами и пошаговым изложением, где жирным выделены главные резюмирующие мысли (в начале каждого абзаца).
- Заключения всегда аккуратные, оптимистичные и резюмирующие
- Часто используются определенные слова. Судя по статье, например, vibrant, crucial, significantly, etc. А по личным наблюдениям, можно даже найти следы промптов в тексте - например step-by-step в заголовках книги про Chief AI Officer.
- Отсутствие понятного посыла или новых/интересных для читателя мыслей. Хотя как единственный критерий это, конечно, не работает. Всякие книги встречаются.
- Фактура спорная, неверная или очень общая. Пример критерия с высоким весом - ссылки на литературу ведут на несуществующие страницы.
- Ни одной (или мало) схем в тексте. У авторов-людей почти всегда есть потребность как-то визуально структурировать и показать наглядно мысли, которые они передают в тексте. Для LLM-текста - человек должен заморочиться отдельным промптом, чтобы собрать подобное. А возможно, даже осмыслить тот текст, который ему написала модель. Это уже существенно отдалит его от полностью сгенеренного.
Есть ли у вас что добавить к списку критериев? Не дадим LLM захватить литературу!
Вот такой вот дивный новый мир. На фоне размышлений о будущем после книги про AI Officers мне вспоминается история из великого башорга. Для тех, кто еще помнит
На картинке - скрин из книги с заголовком с кусочком промпта.
Ваш @Reliable ML
#business #мысли #reliable_ml #llm
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Blog
🔎 Probing GPT model: привет, друзья!
Почему бы и не опубликовать туториал под ночь перед понедельником? Я тоже не вижу препятствий.
Подготовила новый туториал. Карты активации в прошлый раз зашли хорошо, так что по мере сил стараюсь что-то такое интересное добавлять в открытые материалы.
Туториал посвящён зондированию (probing) — простому, но мощному (и красивому иногда) методу для изучения внутренней работы LLM (больших языковых моделей). С его помощью можно получить приближенные знания о паттернах, которые выучивает модель и о том, как эти знания распространяются по слоям.
В туториале рассмотрено:
1. Процесс зондирования на примере GPT2;
2. Анализ информативности скрытых состояний с помощью PCA;
3. Постановку эксперимента (и сам эксперимент) для ответа на вопрос: какой слой по уровню позволяет приближенно решить задачу регресси и хранит информацию по годам?;
Ссылочки:
✔️Код туториала на гитхаб: часть 1, часть 2 (по ссылкам англ версии, но можно провалиться в папку — есть русский).
✔️Статья на Хабр
Добрых вам снов и продуктивной недели!
Ваш Дата-автор!
Почему бы и не опубликовать туториал под ночь перед понедельником? Я тоже не вижу препятствий.
Подготовила новый туториал. Карты активации в прошлый раз зашли хорошо, так что по мере сил стараюсь что-то такое интересное добавлять в открытые материалы.
Туториал посвящён зондированию (probing) — простому, но мощному (и красивому иногда) методу для изучения внутренней работы LLM (больших языковых моделей). С его помощью можно получить приближенные знания о паттернах, которые выучивает модель и о том, как эти знания распространяются по слоям.
В туториале рассмотрено:
1. Процесс зондирования на примере GPT2;
2. Анализ информативности скрытых состояний с помощью PCA;
3. Постановку эксперимента (и сам эксперимент) для ответа на вопрос: какой слой по уровню позволяет приближенно решить задачу регресси и хранит информацию по годам?;
Ссылочки:
✔️Код туториала на гитхаб: часть 1, часть 2 (по ссылкам англ версии, но можно провалиться в папку — есть русский).
✔️Статья на Хабр
Добрых вам снов и продуктивной недели!
Ваш Дата-автор!
Forwarded from Valuable AI / Валентин Малых
китайские товарищи предложили еще одну новую идею: не считать всю огромную матрицу внимания, а выбрать из нее только важные блоки; это и до них пытались делать, вспомнить хотя бы BigBird, но тут коллеги предложили делать выбор по принципу смеси экспертов, то есть ввести специальный роутер, который будет отправлять запрос в нужный блок (фактически - на сравнение с нужной фразой); на картинке слева показана принципиальная схема работы самого модифицированного внимания, а справа - в контексте всего трансформера; в заключение хочу отметить вкус коллег в плане названия - MoBA (ждем YoBA)
P.S. стоит отметить, что Moonshot сразу выложили код, за что им отдельный лайк от меня
P.S. стоит отметить, что Moonshot сразу выложили код, за что им отдельный лайк от меня
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
Я раcскажу вам о классном
Если у вас в компании есть проблемы с соблюдением стандартов форматирования SQL-кода, и вас бесит
Данный форматер устанавливается очень просто, с помощью команды:
pip install shandy-sqlfmt[jinjafmt]
А чтобы отформатировать код необходимо выполнить ну просто "нереальную
sqlfmt <путь к sql файлу>
Прелести данной фичи:
Мои коллеги накатили данную приблуду на репозиторий во время миграции, ибо когда мы дошли до задачи переписывания кода формирования витрин на DBT, ужаснулись в том плане, что читать этот код, невозможно, пока его не отформатируешь. И чтобы в дальнейшем такого не было, накатили данную приблуду на репу, где данный код хранился.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 5 minutes of data
🚀 PGAI-Vectorizer + SQLAlchemy + LiteLLM: Векторный поиск в PostgreSQL стал простым как никогда
Если вы хотите внедрить векторный поиск в свои проекты, но не готовы разворачивать отдельные сервисы вроде Elasticsearch или Qdrant, то вот хорошая новость. Команда Timescale объединила три мощных инструмента, чтобы вы могли работать с векторными эмбеддингами прямо внутри PostgreSQL. Давайте разберемся, как это работает!
Что в связке?
1. PGAI-Vectorizer
— Расширение для PostgreSQL, которое превращает текст в векторные эмбеддинги напрямую в БД.
— Поддерживает модели из Hugging Face, OpenAI, Anthropic и другие.
— Автоматическое обновление эмбеддингов при изменении данных.
2. SQLAlchemy
— Знакомый ORM для работы с PostgreSQL.
— Позволяет описывать таблицы и векторы как Python-объекты.
3. LiteLLM
— Универсальный интерфейс для 100+ языковых моделей (LLM).
— Единый API для OpenAI, Claude, Cohere и даже локальных моделей (например, Llama 3).
🔧 Как это работает?
1. Генерация эмбеддингов
— Через SQL-запросы или Python-код PGAI-Vectorizer преобразует текст в векторы.
Пример SQL:
2. Интеграция с SQLAlchemy
— Векторы хранятся как специальные типы данных в таблицах.
— Поиск похожих записей через оператор <=> (косинусное сходство).
3. Гибкость моделей через LiteLLM
— Можно легко переключаться между LLM без изменения кода.
— Пример на Python:
🛠 Пример использования: поиск статей по смыслу
1. Создаете таблицу с колонкой для векторов:
2. Генерируете эмбеддинги при добавлении данных:
3. Ищете похожие статьи одним запросом:
💡 Плюсы подхода
✅ Не нужно обслуживать отдельные сервисы (всё в PostgreSQL).
✅ Меньше boilerplate-кода — эмбеддинги генерируются автоматически.
✅ Масштабируемость — TimescaleDB отлично работает с большими объемами данных.
✅ Снижение затрат — можно использовать бесплатные модели из Hugging Face.
🚨 Когда это не подойдет?
— Для high-load проектов с миллиардами векторов (смотрите в сторону специализированных векторных БД).
— Если нужны сложные метрики поиска (например, HNSW-индексы).
@data_whisperer
Если вы хотите внедрить векторный поиск в свои проекты, но не готовы разворачивать отдельные сервисы вроде Elasticsearch или Qdrant, то вот хорошая новость. Команда Timescale объединила три мощных инструмента, чтобы вы могли работать с векторными эмбеддингами прямо внутри PostgreSQL. Давайте разберемся, как это работает!
Что в связке?
1. PGAI-Vectorizer
— Расширение для PostgreSQL, которое превращает текст в векторные эмбеддинги напрямую в БД.
— Поддерживает модели из Hugging Face, OpenAI, Anthropic и другие.
— Автоматическое обновление эмбеддингов при изменении данных.
2. SQLAlchemy
— Знакомый ORM для работы с PostgreSQL.
— Позволяет описывать таблицы и векторы как Python-объекты.
3. LiteLLM
— Универсальный интерфейс для 100+ языковых моделей (LLM).
— Единый API для OpenAI, Claude, Cohere и даже локальных моделей (например, Llama 3).
🔧 Как это работает?
1. Генерация эмбеддингов
— Через SQL-запросы или Python-код PGAI-Vectorizer преобразует текст в векторы.
Пример SQL:
SELECT pgai.embed(
transformer => 'huggingface',
model => 'sentence-transformers/all-MiniLM-L6-v2',
text => 'Ваш текст здесь'
);
2. Интеграция с SQLAlchemy
— Векторы хранятся как специальные типы данных в таблицах.
— Поиск похожих записей через оператор <=> (косинусное сходство).
3. Гибкость моделей через LiteLLM
— Можно легко переключаться между LLM без изменения кода.
— Пример на Python:
from litellm import completion
response = completion(
model="claude-3",
messages=[{"content": "Ваш запрос", "role": "user"}]
)
🛠 Пример использования: поиск статей по смыслу
1. Создаете таблицу с колонкой для векторов:
class Article(Base):
__tablename__ = "articles"
id = Column(Integer, primary_key=True)
content = Column(Vector(384)) # Размерность вектора
2. Генерируете эмбеддинги при добавлении данных:
article = Article(content=pgai.embed("...ваш текст..."))
session.add(article)
3. Ищете похожие статьи одним запросом:
SELECT * FROM articles
ORDER BY content <=> pgai.embed('Искать это')
LIMIT 5;
💡 Плюсы подхода
✅ Не нужно обслуживать отдельные сервисы (всё в PostgreSQL).
✅ Меньше boilerplate-кода — эмбеддинги генерируются автоматически.
✅ Масштабируемость — TimescaleDB отлично работает с большими объемами данных.
✅ Снижение затрат — можно использовать бесплатные модели из Hugging Face.
🚨 Когда это не подойдет?
— Для high-load проектов с миллиардами векторов (смотрите в сторону специализированных векторных БД).
— Если нужны сложные метрики поиска (например, HNSW-индексы).
@data_whisperer
GitHub
GitHub - timescale/pgai: A suite of tools to develop RAG, semantic search, and other AI applications more easily with PostgreSQL
A suite of tools to develop RAG, semantic search, and other AI applications more easily with PostgreSQL - timescale/pgai
Forwarded from Техножрица 👩💻👩🏫👩🔧
Доброе утро, дорогие девочки 💋 и фембойчики 💅. Спешу поделиться радостной новостью: вчера я выложила на архив новый препринт (short paper), в написании которого принимала участие - Quantifying Logical Consistency in Transformers via Query-Key Alignment: https://arxiv.org/abs/2502.17017 .
Статья посвящена анализу того, как разные головы внимания LLMок реагируют на логические задачки. Главный прием, который в ней используется, изображен на рис. 1 и аналогичен приему из нашей с коллегами статьи про использование Query-Key Alignment для MCQA (часть 1, часть 2). Мы подаем на вход модели текст логической задачки вместе с вариантом ответа "true" и считаем скалярное произведение токена "true" из Query на выбранной голове внимания, на последний токен перед словом "Answer:" из Key на той же голове внимания. Получается одно число. Далее то же самое повторяется для варианта ответа "false". Получается второе число. Если первое число больше второго, то мы считаем, что голова выбрала вариант "true", а если наоборот, то "false" (в некоторых задачах более уместно вместо "true" и "false" использовать "yes" и "no", но принцип остается таким же). Таким образом можно проэкзаменовать каждую голову внимания и посмотреть, насколько хорошо из её query и key извлекаются правильные ответы (условно говоря, насколько хорошо голова "решает" логические задачки).
Задачки различались по степени сложности: во-первых, по количеству логических шагов, которые нужно предпринять для нахождения ответа ("steps" на рис. 2), а во-вторых, по количеству нерелевантных, шумных элементов в условии ("distractors" на рис. 2).
В статье было проанализировано много разных моделей (от 1.5B до 70B), и везде нашлись головы, которые "решают" сложные (5 шагов/5 дистракторов) задачки лучше, чем сама модель (если ответ модели оценивать по логитам, аналогично тому, как это делается в MCQA задачах). Более того, часть таких "хороших" голов, отобранных на валидационной выборке одного датасета, сохраняет высокое качество и на других датасетах, являясь более-менее универсальными. Мы выдвигаем гипотезу, что именно эти головы могут отвечать за логические рассуждения в модели.
Этот феномен аналогичен тому, что происходит в MCQA задачах (см. ссылки на разбор статьи выше): модель находит правильный ответ на задачу/вопрос где-то на промежуточных слоях, но этот ответ, по каким-то причинам, не всегда доходит до финального слоя. При чем, что интересно, чем сложнее задача, тем чаще правильный ответ не доходит до выхода. А это значит, что все рассмотренные модели не полностью раскрывают свой потенциал и имеют пространство для улучшения.
#объяснения_статей
Статья посвящена анализу того, как разные головы внимания LLMок реагируют на логические задачки. Главный прием, который в ней используется, изображен на рис. 1 и аналогичен приему из нашей с коллегами статьи про использование Query-Key Alignment для MCQA (часть 1, часть 2). Мы подаем на вход модели текст логической задачки вместе с вариантом ответа "true" и считаем скалярное произведение токена "true" из Query на выбранной голове внимания, на последний токен перед словом "Answer:" из Key на той же голове внимания. Получается одно число. Далее то же самое повторяется для варианта ответа "false". Получается второе число. Если первое число больше второго, то мы считаем, что голова выбрала вариант "true", а если наоборот, то "false" (в некоторых задачах более уместно вместо "true" и "false" использовать "yes" и "no", но принцип остается таким же). Таким образом можно проэкзаменовать каждую голову внимания и посмотреть, насколько хорошо из её query и key извлекаются правильные ответы (условно говоря, насколько хорошо голова "решает" логические задачки).
Задачки различались по степени сложности: во-первых, по количеству логических шагов, которые нужно предпринять для нахождения ответа ("steps" на рис. 2), а во-вторых, по количеству нерелевантных, шумных элементов в условии ("distractors" на рис. 2).
В статье было проанализировано много разных моделей (от 1.5B до 70B), и везде нашлись головы, которые "решают" сложные (5 шагов/5 дистракторов) задачки лучше, чем сама модель (если ответ модели оценивать по логитам, аналогично тому, как это делается в MCQA задачах). Более того, часть таких "хороших" голов, отобранных на валидационной выборке одного датасета, сохраняет высокое качество и на других датасетах, являясь более-менее универсальными. Мы выдвигаем гипотезу, что именно эти головы могут отвечать за логические рассуждения в модели.
Этот феномен аналогичен тому, что происходит в MCQA задачах (см. ссылки на разбор статьи выше): модель находит правильный ответ на задачу/вопрос где-то на промежуточных слоях, но этот ответ, по каким-то причинам, не всегда доходит до финального слоя. При чем, что интересно, чем сложнее задача, тем чаще правильный ответ не доходит до выхода. А это значит, что все рассмотренные модели не полностью раскрывают свой потенциал и имеют пространство для улучшения.
#объяснения_статей
Forwarded from Fley's flow
Давно я ничего не писал – всё не видел достойных поводов для постов, однако сейчас такой появился.
Я сделаю небольшую серию публикаций на тему глобальной оптимизации:
Пример
Представьте, что у вас есть какая-то бизнес- или математическая задача. Например — купить мясо и напитки к столу на фиксированный бюджет. Цель — потратить минимум времени. Зададим переменные и ограничим их диапазон, чтобы совсем с ума не сходить:
x1: Сколько людей мы отправим: от 1 до 4
x2: Каких именно людей мы отправим: пускай будет выборка из 6 человек.
x3: День недели: пятница или суббота
x4: В какое время суток отправлять: с 8 до 16 часов
x5: На какой рынок отправиться: пускай будет 3 варианта наиболее удачных рынков в городе.
Давайте попробуем решить эту задачу, опираясь на жизненный опыт. Я опишу свои мысли, а вы можете прикинуть сами и потом читать дальше.
х2 — кого отправим: здесь нужны люди пунктуальные и желательно с большим опытом в организации таких мероприятий.
х3 — день недели: лучше в пятницу, чем в субботу, очевидно.
х4 — время суток: я бы выбрал 10 утра, потому что в это время уже все, кому надо, на работе, и отправленные на рынок люди уже проснулись и бодрствуют, тормозить не будут.
х5 — рынок: здесь не буду предполагать, но можно учесть местоположение людей, которых отправляем, и взять тот рынок, который по среднему расстоянию будет ближе всего.
Разумеется, это достаточно простая жизненная задача, однако к 20-25 годам у нас уже есть набор знаний и опыта, который позволяет оценить поведение этой функции в зависимости от переменных, и выбрать некоторую субоптимальную комбинацию параметров. Но как, очутившись в мире, где есть только люди, рынки и мясо для шашлыка, такой опыт можно получить и каким образом достичь цели быстрее всего? Перепробовать все комбинации — точно сработает, но долго. Попробовать случайные 5-6 — а достаточно ли это хороший подход?
Задача
Теперь с опорой на пример сформулируем общую задачу: есть функция многих переменных, f(x1, x2, ..., x_n), для которой мы предполагаем существование глобального минимума или максимума — нужно его найти.
Оптимизация гиперпараметров
С помощью примера выше мы показали, что в жизни таких задач очень много — практически каждый процесс можно сформулировать как задачу оптимизации, в том числе и эволюционный (это важное замечание). И раз уж я не владелец кафе а-ля Шашлычный Мир, а CV/ML-инженер, расскажу про реальную задачу, где нам нужна глобальная оптимизация.
Обучаем мы нейросеть, задаем различные гиперпараметры, начиная с оптимизатора, learning rate и batch size, заканчивая аугментациями и регуляризациями и смотрим на точность после обучения. Важно отметить, что в силу невозможности продифференцировать такую функцию, мы имеем более общую задачу и медленную сходимость. Как будем подбирать самую хорошую комбинацию? Жизненный опыт — это хорошо, но его долго получать, нет гарантий, что он верный и сработает как нам надо, а также его не так легко обосновать.
Люди, которые касались этой задачи, сразу же вспомнят про GridSearch – поиск по сетке, где мы задаем для каждого параметра набор значений, которые нужно перебрать каждый с каждым. Однако есть высокая вероятность не попасть даже в хороший локальный максимум. Ну и вспомним RandomSearch – поиск по случайным наборам параметров. Любопытно, что у него даже теоретически доказанная сходимость заметно лучше, чем у поиска по сетке, но он тоже не вызывает чувство спокойствия по поводу обоснованности сделанного выбора.
Как раз о таких методах, которые помогут спать спокойно, в следующих постах и пойдет речь.
#learn #hard #cases
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Knowledge Accumulator
A Conceptual Explanation of Bayesian Hyperparameter Optimization for Machine Learning [2018]
Неделю назад я писал пост про Evolution Strategies. Напомню его область применения:
1) Есть не очень большое пространство параметров
2) Есть функция качества этих параметров, но нет доступа к каким-либо градиентам
Эта область применения не так уж и редко встречается в реальной жизни, и чаще всего это происходит в контексте оптимизации гиперпараметров. В этом случае появляется ещё одно обстоятельство:
3) Функцию качества очень долго и дорого считать
В данной ситуации мы хотим максимально эффективно использовать этот ресурс, извлекать и переиспользовать максимальное количество информации из её замеров. Стандартный Evolution Strategies в этом плане достаточно туп - каждая итерация алгоритма происходит "с чистого листа", а точки для замера выбираются с помощью добавления шума.
Именно здесь на сцену выходит Bayesian model-based optimization. Это целое семейство методов, но все они работают по примерно одному и тому же принципу:
1) Мы пытаемся аппроксимировать распределение
2) Мы используем каждое наше измерение для обучения этой аппроксимации
3) Выбор следующих кандидатов происходит по-умному, балансируя между неисследованными областями в пространстве параметров и проверкой тех областей, в которых мы ожидаем получить хорошее значение функции
Исследуя всё больше и больше точек, мы получаем всё более точную аппроксимацию функции, как показано на картинке. Остаётся выбрать, каким образом моделировать распределение и выбирать кандидатов.
Один из вариантов, используемых на практике, выглядит так:
- При выборе следующих кандидатов мы максимизируем нечто похожее на "мат. ожидание"
- Для оценки
- В пунктах выше я упоминал "хорошие" и "плохие" значения. Порог, который их разделяет, выбирается как квантиль уже собранного нами множества значений objective.
При применении капельки математики получается, что Expected Improvement максимизируется в тех точках, в которых максимизируется` L(params) / G(params)
Описанная процедура гораздо хитрее и тяжелее, чем Evolution Strategies, но всё это несопоставимо дешевле и быстрее, чем каждый подсчёт значения Objective(params). Таким образом, метод хорошо подходит для таких ситуаций, как оптимизация гиперпараметров обучения, и используется в качестве одного из основных в библиотеке Hyperopt.
Метод, конечно, не идеален - он не учитывает зависимости параметров между собой. Это может ограничивать область применения и мешать методу работать для оптимизации более запутанных схем. Бесплатные обеды, как обычно, не завезли.
@knowledge_accumulator
Неделю назад я писал пост про 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