Всем привет!
На связи ML-команда Точка Банк, и мы приняли решение создать этот канал, чтобы рассказать миру о том, чем мы занимаемся 💜
Здесь мы будем публиковать:
📌 Рассказы о нашей инфраструктуре и наших процессах
📌 Обзоры интересных инструментов, технологий, статей и библиотек
📌 Рассказы о наших командах и проектах
📌 Анонсы наших митапов, выступлений на конференциях и статей
📌 Наши открытые вакансии и стажировки в ML-команду
📌 Интервью с нашими тимлидами, ML-инженерами, аналитиками и разработчиками
📌 И многое другое
Присоединяйтесь к нам, чтобы быть в курсе самых интересных новостей про ML 💜
На связи ML-команда Точка Банк, и мы приняли решение создать этот канал, чтобы рассказать миру о том, чем мы занимаемся 💜
Здесь мы будем публиковать:
📌 Рассказы о нашей инфраструктуре и наших процессах
📌 Обзоры интересных инструментов, технологий, статей и библиотек
📌 Рассказы о наших командах и проектах
📌 Анонсы наших митапов, выступлений на конференциях и статей
📌 Наши открытые вакансии и стажировки в ML-команду
📌 Интервью с нашими тимлидами, ML-инженерами, аналитиками и разработчиками
📌 И многое другое
Присоединяйтесь к нам, чтобы быть в курсе самых интересных новостей про ML 💜
❤🔥37👀9🔥4
Причина успеха ChatGPT — RLHF
Многие уже слышали про этот подход — он учит модели вести себя так, как мы бы хотели. Этим он отличается от претрена, который дает только базовые способности к естественному языку.
При использовании метода LLM сильно деградирует, потому что для максимизации вероятности успеха жертвует другими способностями. Для сохранения начальных качеств модели мы ставим ограничение (Kullback-Leibler divergence) на вид распределения вероятностей получить различные токены.
Плюсы метода:
➕ Достаточно эффективен, в том числе для очень больших моделей. На нем работают модели из топа арены.
➕ В зависимости от требований мы можем обучить модель под любые качества и быть уверенными, что она не будет сильно деградировать по другим способностям.
Минусы:
➖ RL достаточно сложно настраивать и контролировать, а еще она довольно быстро оверфитится.
➖ Так как фидбэк от людей очень дорогой, нужно обучить дополнительную модель наград для ранжирования ответов.
➖ Нужно держать в памяти сразу несколько больших моделей: саму модель, ее начальную версию и ревард-модель.
А вы используете этот метод в своих проектах?
Многие уже слышали про этот подход — он учит модели вести себя так, как мы бы хотели. Этим он отличается от претрена, который дает только базовые способности к естественному языку.
В основе RLHF лежит reinforcement learning алгоритм Proximal Policy Optimization. Сначала мы создаем датасет из пар ответов, отранжированных человеком, и обучаем отдельную модель наград предсказывать, насколько ответ будет «хорошим». Это позволяет использовать модель для понимания, насколько людям понравятся неразмеченные ответы.
Дальше мы используем обученную модель, чтобы оценивать ответы нашей LLM и обучать ее максимизировать вероятность сгенерировать текст, который получит большую награду — то есть быть ближе к «хорошему» ответу.
При использовании метода LLM сильно деградирует, потому что для максимизации вероятности успеха жертвует другими способностями. Для сохранения начальных качеств модели мы ставим ограничение (Kullback-Leibler divergence) на вид распределения вероятностей получить различные токены.
Плюсы метода:
Минусы:
А вы используете этот метод в своих проектах?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍32🤓13🔥12⚡5❤1
Мы тут обнаружили, что потеряли пост про RoPE🙃🙃
Поэтому отправляем вам его ещё раз
Поэтому отправляем вам его ещё раз
🔥8👍2
Шо пацаны, вращаем и масштабируем!
Сейчас самый популярный метод позиционного кодирования в LLM’ках и не только — это RoPE. Но глубокому исследованию влияния параметров RoPE на поведение и свойства итоговой модели уделяется довольно мало внимания.
В статье “Scaling Laws of RoPE-based Extrapolation” ребята исследовали влияние выбора параметра rope base на поведение модели при разном размере контекста.
А еще:
📌 Ввели концепцию critical dimension, которая чуть-чуть приводит в порядок теорию про адаптацию RoPE для Train Short Test Long сценариев.
📌 Пофлексили тем, что “we achieve extrapolation up to 1 million context length within only 16K training length on LLaMA2 7B and 13B” — но есть нюанс 🙃
Основные интересные моменты:
Велкам в полную версию статьи — давайте в комментариях обсудим, кто что полезное в ней нашел.
Сейчас самый популярный метод позиционного кодирования в LLM’ках и не только — это RoPE. Но глубокому исследованию влияния параметров RoPE на поведение и свойства итоговой модели уделяется довольно мало внимания.
В статье “Scaling Laws of RoPE-based Extrapolation” ребята исследовали влияние выбора параметра rope base на поведение модели при разном размере контекста.
А еще:
📌 Ввели концепцию critical dimension, которая чуть-чуть приводит в порядок теорию про адаптацию RoPE для Train Short Test Long сценариев.
📌 Пофлексили тем, что “we achieve extrapolation up to 1 million context length within only 16K training length on LLaMA2 7B and 13B” — но есть нюанс 🙃
Основные интересные моменты:
- Маленькие rope base из коробки ведут к лучшей устойчивости к длинам контекста, которых не было в трейне, но при этом работают хуже на длинах, которые были в трейне.
- Есть понятный способ вычислить оптимальные rope base, если хочется сделать его маленьким.
- Большие rope base неустойчивы к длинам контекста, которых не было в трейне, но при этом работают лучше на длинах, которые были в трейне.
- Есть понятный способ вычислить оптимальный rope base, если хочется сделать его большим. Для этого нужно знать, на какой максимальной длине сиквенсов будет учиться модель, и на какой максимальной длине сиквенсов она будет работать на тесте.
- Пусть есть вектор размерности d для репрезентации какого-то query или key внутри башки атеншена. Тогда будет существовать d_extra, и во время претрейна позиционная информация в измерениях d_i ≤ d_extra будет полностью выучена, а в измерениях d_i > d_extra будет выучена не полностью и потребует дальнейших упражнений с адаптацией.
Велкам в полную версию статьи — давайте в комментариях обсудим, кто что полезное в ней нашел.
🔥24👍11🥰6❤1
Метод прямой оптимизации предпочтений
Proximal Policy Optimization работает хорошо, но необходимость собирать фидбэк, обучать на нем модель наград и тюнить дальнейший RL — сложно и долго.
Вместо этого можно напрямую оптимизировать нашу политику (LLM) по парам предпочтений пользователей. С промптом и парой ответов chosen/rejected, мы можем вместо их абсолютных значений награды требовать, чтобы вероятность генерации одного была выше, чем у второго.
Плюсы метода:
➕ Не требует обучения и хранения в памяти ревард модели, в том числе не подвержен ее собственным искажениям. Проще контролировать, чем PPO.
➕ Можно попробовать использовать вместо исходной модели предполагать равномерное распределение предсказаний, чтобы ограничить затраты по памяти.
➕ Есть модификации, которые используют отранжированные списки ответов для улучшения качества обучения.
Минусы метода:
➖ Некоторые исследования показывают, что модель после DPO перформит еще хуже, чем до него.
➖ Все еще неэффективный по памяти, так как нужно хранить не только саму модель, но и ее начальное состояние, что даже с шарингом некоторых слоев оказывается затратным.
➖ Все еще оверфиттится под датасет. Кроме того, мы не можем использовать многие методы расширения датасета, так как ожидаем, что все ответы сгенерированы одной и той же политикой. То есть, можем наказать модель за то, чего она не делала.
➖ В отличие от более свежих методов, требует больше времени на обучение.
Что думаете про этот метод?
Proximal Policy Optimization работает хорошо, но необходимость собирать фидбэк, обучать на нем модель наград и тюнить дальнейший RL — сложно и долго.
Вместо этого можно напрямую оптимизировать нашу политику (LLM) по парам предпочтений пользователей. С промптом и парой ответов chosen/rejected, мы можем вместо их абсолютных значений награды требовать, чтобы вероятность генерации одного была выше, чем у второго.
Как и в PPO, метод имеет свойство сильно ухудшать другие качества модели. Из-за этого нужно добавлять в лосс ограничивающий член, который будет сохранять общее распределение предсказаний похожим на начальную модель.
Плюсы метода:
Минусы метода:
Что думаете про этот метод?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17🔥15👍9
Авторы этого метода подсмотрели идею Loss Aversion в экономической теории Канемана и Тверски
Люди склонны переоценивать низкие вероятности возникновения альтернатив и недооценивать высокие. Кроме того, приобретенная ценность в результате действий оказывается менее значительной, чем потеря такой же ценности, и даже при малом риске потерь люди склонны отказываться от него.
Авторы вводят Human-Aware Loss, который моделирует такое восприятие. Здесь уже не нужны пары ответов модели: достаточно иметь бинарную оценку, которая показывает «хороший» он или «плохой».
Плюсы метода:
➕ Очень простой сбор датасета: достаточно просить пользователя после ответа поставить лайк или дизлайк. А уже существующие парные датасеты автоматически увеличиваются в 2 раза.
➕ Более устойчивый, чем DPO и PPO.
➕ Не использует прямую генерацию референсной модели, сильно повышает эффективность по памяти и скорости работы.
➕ На моделях 13B+ не требует SFT.
Минусы метода:
➖ Не показано качество работы на больших моделях 30B+.
➖ Нужно уделять больше внимания датасету при его переработке из других форматов. Проблема может крыться в транзитивности A>B>C. В датасете DPO будет A>B, B>C. В датасете KTO окажется, что A — хороший пример, C — плохой, а B один раз хороший, а другой плохой. Из-за этого мы будем пытаться по-разному отметить один и тот же пример.
Люди склонны переоценивать низкие вероятности возникновения альтернатив и недооценивать высокие. Кроме того, приобретенная ценность в результате действий оказывается менее значительной, чем потеря такой же ценности, и даже при малом риске потерь люди склонны отказываться от него.
Авторы вводят Human-Aware Loss, который моделирует такое восприятие. Здесь уже не нужны пары ответов модели: достаточно иметь бинарную оценку, которая показывает «хороший» он или «плохой».
Лосс сначала оценивает относительную награду, используя референсную политику — вероятность получить тот же ответ, используя модель до начала дообучения. После этого относительная награда максимизируется с учетом KL-дивергенции и заданного желаемого промежутка между «хорошими» и «плохими» ответами.
Плюсы метода:
Минусы метода:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍8🤓3
Как LLM могут помочь в классическом ML?
По статистике, специалисты по Data Science тратят до 70% рабочего времени на этап Feature Engineering, то есть отбирают наиболее важные признаки в данных и формируют новые, более информативные, датасеты. Кажется, с этой рутинной задачей отлично справится LLM. Но нет — в итоге 64% времени уйдёт на подготовку промптов.
Исследователи предлагают новые решения проблемы, одно из них — FELIX (Feature Engineering with LLMs for Interpretability and Explainability). Всё, что нужно для получения готовых фич — сам датасет и его короткий контекст. Дальше FELIX делает следующее:
✏️ Из случайных групп сэмплов датасета LLM генерирует численных и категориальных кандидатов в новые признаки.
✏️ С помощью кластеризации эмбеддингов похожие признаки отбрасываются.
✏️ Из полученных признаков отбрасываются те, что дают наименьшую объяснимость.
Метод эффективен для текстовых данных и сильно превосходит TF-IDF и трансформерные эмбеддинги от RoBERT. Если вам интересно, расскажем и о преобразовании других типов данных в новых постах!
По статистике, специалисты по Data Science тратят до 70% рабочего времени на этап Feature Engineering, то есть отбирают наиболее важные признаки в данных и формируют новые, более информативные, датасеты. Кажется, с этой рутинной задачей отлично справится LLM. Но нет — в итоге 64% времени уйдёт на подготовку промптов.
Исследователи предлагают новые решения проблемы, одно из них — FELIX (Feature Engineering with LLMs for Interpretability and Explainability). Всё, что нужно для получения готовых фич — сам датасет и его короткий контекст. Дальше FELIX делает следующее:
✏️ Из случайных групп сэмплов датасета LLM генерирует численных и категориальных кандидатов в новые признаки.
✏️ С помощью кластеризации эмбеддингов похожие признаки отбрасываются.
✏️ Из полученных признаков отбрасываются те, что дают наименьшую объяснимость.
Метод эффективен для текстовых данных и сильно превосходит TF-IDF и трансформерные эмбеддинги от RoBERT. Если вам интересно, расскажем и о преобразовании других типов данных в новых постах!
❤28👍15🔥10🥴2🤡1
Чем вы займётесь 8 ноября в 14:45?
Мы будем смотреть выступление наших коллег Лизы и Максима «Как перестать пересылать Jupyter-ноутбуки по почте» на конференции I’ML.
Доклад вдохновлён книгой «Effective Python» — там собраны советы, которые помогут писать чистый эффективный код. Так что если вы пишете ML-код для продакшен-решений — присоединяйтесь!
Мы будем смотреть выступление наших коллег Лизы и Максима «Как перестать пересылать Jupyter-ноутбуки по почте» на конференции I’ML.
Ребята расскажут, как писать код в ML-проектах, и объяснят, почему нам важно знать основы безопасности в Python. А ещё Лиза и Максим посоветуют to-go решения, чтобы код был читаемый, эксперименты — воспроизводимыми, а время на написание и рефакторинг своего и чужого кода — минимальным.
Доклад вдохновлён книгой «Effective Python» — там собраны советы, которые помогут писать чистый эффективный код. Так что если вы пишете ML-код для продакшен-решений — присоединяйтесь!
IML 2024 Autumn. MLOps-конференция: от обучения до эксплуатации моделей
Как перестать пересылать Jupyter-ноутбуки по почте | Доклад на IML 2024 Autumn
Расскажем, какие политики написания кода в ML-проектах мы выработали в команде и в компании в целом. Покажем на примерах широко используемых ML-библиотек Hugging Face Transformers и scikit-learn, как писать не надо и почему, а на примерах сообщений младших…
❤22🔥13❤🔥6😍2🥴1
После нескольких месяцев экспериментов в проекте Точка Нетворк мы вывели правила, которые помогают получать стабильно хорошие результаты в ответах GPT:
📌 Подбирайте подходящую модель GPT и параметры под каждую задачу: экспериментируйте с параметром «температура», который отвечает за креативность, и выбирайте актуальные модели.
📌 Конкретизируйте основную задачу: без воды, отрицания и лишнего шума.
📌 Подберите подходящую роль, которую точно знает GPT: она может быть не одна: GPT умеет переключаться между разными ними в нужный момент во время выполнения задачи.
📌 Распишите задачу по шагам: это поможет GPT выдать более корректный ответ.
📌 Опишите структуру и правила сообщения: объём, план текста, цитаты, формат вывода.
📌 Добавьте примеры для входных данных и для вывода.
📌 Используйте markdown-разметку, выделяйте """тексты""" и размечайте структурированные данные в формате JSON.
📌 Опишите Tone of Voice, редполитику и язык ответа. Не бойтесь объёма: контекстное окно у GPT-4 Omni — 128k токенов и может вмещать примерно 512 000 символов на английском языке. В веб-версии в поле общения с GPT-4 можно ввести до 8192 символов за одно сообщение. А вот у GPT-4 входные объёмы в два раза меньше.
📌 Самый важный этап: тестирование. Для проверки работы промпта и соответствия всех критериев нужно 300-500 прогонов на разных кейсах, а одинаковые важно проверить несколько раз подряд.
Подробнее о том, как мы перешли от объёмных линейных запросов к запросам с многоэтапной структурой, а потом от дорогой Chat GPT-4 к новой и интересной по цене GPT-4o, читайте в нашей статье на Хабре. Там примеры промптов, оценка затрат и все подробности перехода.
📌 Подбирайте подходящую модель GPT и параметры под каждую задачу: экспериментируйте с параметром «температура», который отвечает за креативность, и выбирайте актуальные модели.
📌 Конкретизируйте основную задачу: без воды, отрицания и лишнего шума.
📌 Подберите подходящую роль, которую точно знает GPT: она может быть не одна: GPT умеет переключаться между разными ними в нужный момент во время выполнения задачи.
📌 Распишите задачу по шагам: это поможет GPT выдать более корректный ответ.
📌 Опишите структуру и правила сообщения: объём, план текста, цитаты, формат вывода.
📌 Добавьте примеры для входных данных и для вывода.
📌 Используйте markdown-разметку, выделяйте """тексты""" и размечайте структурированные данные в формате JSON.
📌 Опишите Tone of Voice, редполитику и язык ответа. Не бойтесь объёма: контекстное окно у GPT-4 Omni — 128k токенов и может вмещать примерно 512 000 символов на английском языке. В веб-версии в поле общения с GPT-4 можно ввести до 8192 символов за одно сообщение. А вот у GPT-4 входные объёмы в два раза меньше.
📌 Самый важный этап: тестирование. Для проверки работы промпта и соответствия всех критериев нужно 300-500 прогонов на разных кейсах, а одинаковые важно проверить несколько раз подряд.
Подробнее о том, как мы перешли от объёмных линейных запросов к запросам с многоэтапной структурой, а потом от дорогой Chat GPT-4 к новой и интересной по цене GPT-4o, читайте в нашей статье на Хабре. Там примеры промптов, оценка затрат и все подробности перехода.
🔥26👍7✍4❤4🥴2🥰1💩1
Недавно мы публиковали небольшой обзор статьи “Scaling Laws of RoPE-based Extrapolation”. Самое время вспомнить о базе по этой теме — сделали выжимку статьи “RoFormer: Enhanced Transformer with Rotary Position Embedding”. Это её первая часть.
Как❓
C помощью векторов query и key: мы пытаемся повернуть их так, чтобы эмбеддинги соседних токенов оказались рядом в векторном пространстве, а далёких — наоборот. Это увеличит внимание на близкие токены и понизит на дальние.
Почему❓
Потому что SDPA (Scaled Dot Product Attention), куда мы подаём вектора q и k после поворота, тем больше, чем ближе вектора, которые мы перемножаем. Это же знакомое со школьной скамьи скалярное перемножение!
Как будем поворачивать❓
Для каждого токена входной последовательности рассчитываем угол, на которых хотим повернуть эмбеддинг. Чем больше позиция слова, тем больше угол поворота — напомним, что он линейно зависит от номера позиции токена. Так токены, которые стоят в предложении рядом, оказываются близко в векторном пространстве, а далёкие, например, первое и последнее слово в предложении — далеко.
Но у эмбеддингов большая размерность, как поворачивать-то❓
А вот так: раз мы умеем решать задачу для двумерных эмбеддингов, то постараемся свести задачу с многомерными к ней же. Разобьём наш эмбеддинг размера 512 на пары координат: (x1, x2), (x3, x4), ... Затем повернём каждую пару отдельно и снова сконкатенируем в эмбеддинг нужной нам длины.
То есть, для слова с позицией m1 мы:
- (x1, x2) повернём на угол m1 * k1
- (x3, x4) повернём на угол m1 * k2
- ....
Для слова с позицией m2 мы:
- (x1, x2) повернём на угол m2 * k1
- (x3, x4) повернём на угол m2 * k2
- ....
Короче, мы поворачиваем пару координат эмбеддинги на угол, пропорциональный позиции слова в последовательности и напрямую зависящие от номера этой пары координат.
RoPE — Rotary Position Embeddings, идея добавить в механизм внимания трансформера информации о позиции слова в тексте.
Как
C помощью векторов query и key: мы пытаемся повернуть их так, чтобы эмбеддинги соседних токенов оказались рядом в векторном пространстве, а далёких — наоборот. Это увеличит внимание на близкие токены и понизит на дальние.
Почему
Потому что SDPA (Scaled Dot Product Attention), куда мы подаём вектора q и k после поворота, тем больше, чем ближе вектора, которые мы перемножаем. Это же знакомое со школьной скамьи скалярное перемножение!
Как будем поворачивать
Для каждого токена входной последовательности рассчитываем угол, на которых хотим повернуть эмбеддинг. Чем больше позиция слова, тем больше угол поворота — напомним, что он линейно зависит от номера позиции токена. Так токены, которые стоят в предложении рядом, оказываются близко в векторном пространстве, а далёкие, например, первое и последнее слово в предложении — далеко.
Но у эмбеддингов большая размерность, как поворачивать-то
А вот так: раз мы умеем решать задачу для двумерных эмбеддингов, то постараемся свести задачу с многомерными к ней же. Разобьём наш эмбеддинг размера 512 на пары координат: (x1, x2), (x3, x4), ... Затем повернём каждую пару отдельно и снова сконкатенируем в эмбеддинг нужной нам длины.
Но! Разные пары координат мы будем поворачивать на разные углы, а вернее, будем крутить с разной частотой.
То есть, для слова с позицией m1 мы:
- (x1, x2) повернём на угол m1 * k1
- (x3, x4) повернём на угол m1 * k2
- ....
Для слова с позицией m2 мы:
- (x1, x2) повернём на угол m2 * k1
- (x3, x4) повернём на угол m2 * k2
- ....
Короче, мы поворачиваем пару координат эмбеддинги на угол, пропорциональный позиции слова в последовательности и напрямую зависящие от номера этой пары координат.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥20🥰7⚡5👍4🤓1
Вторая часть обзора статьи “RoFormer: Enhanced Transformer with Rotary Position Embedding”. Первую часть читайте выше.
Почему мы хотим поворачивать разные пары координат на разные углы с разной частотой❓
Потому что таким образом мы позволяем какой-то части координат хранить более точную позиционную информацию: например, координатам с высокой частотой поворота, которые в конце предложения. А какой-то части координат — наоборот, и этим стимулируем накапливать в этой части эмбеддинга смысловую, а не позиционную информацию.
Зачем это вообще придумали❓
Так как добавить RoPE в свой трансформер❓
Полная версия статьи — по ссылке. Делитесь в комментариях, что полезного вам удалось в ней найти.
Почему мы хотим поворачивать разные пары координат на разные углы с разной частотой
Потому что таким образом мы позволяем какой-то части координат хранить более точную позиционную информацию: например, координатам с высокой частотой поворота, которые в конце предложения. А какой-то части координат — наоборот, и этим стимулируем накапливать в этой части эмбеддинга смысловую, а не позиционную информацию.
Зачем это вообще придумали
- RoPE позволяет обрабатывать последовательности любой длины, так как реализует относительное позиционное кодирование. То есть, нам не надо учить вектора позиций.
- Трансформеры с RoPE attention показывают лучшие результаты на бенчмарках с длинными текстами по сравнению с аналогичными ванильными SDPA.
Так как добавить RoPE в свой трансформер
- Во время инициализации блока внимания рассчитывать матрицы поворотов.
- В forward внимания поворачивать проекции query и key прежде, чем считать SDPA.
- Переобучить модельку.
- Профит!
Полная версия статьи — по ссылке. Делитесь в комментариях, что полезного вам удалось в ней найти.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17❤8👌3👍1🤓1
Вы уже теряли лучшую версию модели, потому что все эксперименты проводили в одном ноутбуке, не сохраняя предыдущие результаты? Или пытались вспомнить, какие гипотезы не сработали полгода назад? Тогда этот пост для вас.
❓Зачем логировать эксперименты?
- Чтобы не искать «тот самый ноутбук» с лучшей итерацией обучения.
- Чтобы удобно сравнивать разные версии моделей: алгоритмы, параметры, метрики, наборы признаков.
- Чтобы не держать в голове, что, как и с каким результатом было сделано.
- Чтобы где-то безопасно хранить все свои модели.
- Чтобы не пересылать коллегам ноутбуки и pickle-файлы по почте.
❓Куда логировать?
Существует много инструментов для хранения артефактов экспериментов. Мы в Точке выбрали MLflow — он покрывает наши основные потребности.
❓Что логировать?
Зависит от стандартов и практик, которые приняты в вашей команде. Мы рекомендуем хранить всё (или почти всё):
📌 Denoscription: текстовое описание эксперимента и краткие выводы по нему.
📌 Parameters: параметры модели — но только те, которые отличаются от дефолтных.
📌 Metrics: метрики и лоссы.
📌 Tags: любая информация, которая поможет раскрыть детали эксперимента, например:
- временной период данных, на которых обучалась и тестировалась модель;
- пропорция классов;
- дата проведения эксперимента;
- контактные данные создателя;
- путь к обучающим и тестовым данным.
📌 Artifacts: информация в виде файлов S3, которая поможет воспроизвести эксперимент и использовать модель, например:
- сама модель и зависимости;
- кривые обучения (loss, metric);
- графики (shap, feature importance, roc-curve, pr-curve);
- архитектура модели — если это нейронная сеть, которую вы написали сами;
- confusion matrix, перечень и описание признаков, ваши комментарии и всякое полезное;
- примеры данных, на которых обучалась и тестировалась модель.
Подробно рассказывать о том, как пользоваться MLflow, мы не будем: в интернете есть много гайдов на всех языках. А ещё у MLflow неплохая документация с примерами и туториалами — изучайте и делитесь мнениями!
❓Зачем логировать эксперименты?
- Чтобы не искать «тот самый ноутбук» с лучшей итерацией обучения.
- Чтобы удобно сравнивать разные версии моделей: алгоритмы, параметры, метрики, наборы признаков.
- Чтобы не держать в голове, что, как и с каким результатом было сделано.
- Чтобы где-то безопасно хранить все свои модели.
- Чтобы не пересылать коллегам ноутбуки и pickle-файлы по почте.
❓Куда логировать?
Существует много инструментов для хранения артефактов экспериментов. Мы в Точке выбрали MLflow — он покрывает наши основные потребности.
Плюсы MLflow:
- open-source и большое коммьюнити;
- низкий порог входа;
- удобные API и стандартизированные методы;
- позволяет сравнить результаты нескольких экспериментов в одном окне;
- легко использовать в продуктивных решениях.
Минусы MLflow:
- нетривиальное обновление до более свежих версий;
- не оптимизирован для хранения кода;
- отсутствует ролевая модель доступа.
❓Что логировать?
Зависит от стандартов и практик, которые приняты в вашей команде. Мы рекомендуем хранить всё (или почти всё):
📌 Denoscription: текстовое описание эксперимента и краткие выводы по нему.
📌 Parameters: параметры модели — но только те, которые отличаются от дефолтных.
📌 Metrics: метрики и лоссы.
📌 Tags: любая информация, которая поможет раскрыть детали эксперимента, например:
- временной период данных, на которых обучалась и тестировалась модель;
- пропорция классов;
- дата проведения эксперимента;
- контактные данные создателя;
- путь к обучающим и тестовым данным.
📌 Artifacts: информация в виде файлов S3, которая поможет воспроизвести эксперимент и использовать модель, например:
- сама модель и зависимости;
- кривые обучения (loss, metric);
- графики (shap, feature importance, roc-curve, pr-curve);
- архитектура модели — если это нейронная сеть, которую вы написали сами;
- confusion matrix, перечень и описание признаков, ваши комментарии и всякое полезное;
- примеры данных, на которых обучалась и тестировалась модель.
Подробно рассказывать о том, как пользоваться MLflow, мы не будем: в интернете есть много гайдов на всех языках. А ещё у MLflow неплохая документация с примерами и туториалами — изучайте и делитесь мнениями!
mlflow.org
MLflow Overview | MLflow
Stepping into the world of Machine Learning (ML) is an exciting journey, but it often comes with
🔥22👍9🤓3
В этом году коллеги активно нанимали промпт-инженеров для разных проектов Точки.
У нас они:
📌 Пишут промпты и их системы, чтобы языковая модель генерировала релевантные ответы.
📌 Помогают DS специалистам обучать и тренировать новые модели.
📌 Разрабатывают и поддерживают библиотеки промптов, чтобы использовать их повторно.
📌 Много тестируют.
В статье на Хабре рассказали про процесс поиска промпт-инженеров: какие вопросы задавали на собеседованиях, что было самым сложным для кандидатов и кого в итоге наняли.
У нас они:
📌 Пишут промпты и их системы, чтобы языковая модель генерировала релевантные ответы.
📌 Помогают DS специалистам обучать и тренировать новые модели.
📌 Разрабатывают и поддерживают библиотеки промптов, чтобы использовать их повторно.
📌 Много тестируют.
Самое сложное — это найти действительно подходящего кандидата. Промпт-инженеру нужно хорошо знать русский и английский языки, понимать принципы работы разных LLM, RAG, понимать бизнес-специфику финтеха, а в идеале — знать языки программирования.
В статье на Хабре рассказали про процесс поиска промпт-инженеров: какие вопросы задавали на собеседованиях, что было самым сложным для кандидатов и кого в итоге наняли.
Хабр
Бесполезные курсы и помешательство на GPTs: как мы искали prompt-инженеров
Сейчас Точка активно развивает свою LLM, поэтому нам очень нужны prompt-инженеры. В этом году было целых три волны найма, но из 400 человек мы взяли только 9. Почему в этой сфере так сложно...
🔥20🥰9👏6❤3😎3
Векторные базы данных (ВБД) — это NoSQL решения для хранения, индексирования и поиска похожих векторов.
С их помощью можно:
- Строить рекомендательные и поисковые системы.
- Делать анализ изображений и видео.
От базы данных требуется две операции: сохранять данные и читать информацию, записанную ранее. Как работают эти процессы в векторных базах:
📝 Запись
📖 Чтение
Поиск наиболее подходящих соседей может работать долго, ведь нужно просмотреть все записи на диске. Решение этой проблемы — индексация. Мы чуть замедлим запись, но чтение будет работать сильно быстрее. Про разные алгоритмы индексации подробнее расскажем в следующем посте.
С их помощью можно:
- Строить рекомендательные и поисковые системы.
- Делать анализ изображений и видео.
От базы данных требуется две операции: сохранять данные и читать информацию, записанную ранее. Как работают эти процессы в векторных базах:
📝 Запись
1. На вход поступает какой-то объект — например, текст.
2. Этот объект нужно превратить в вектор с помощью обученного векторизатора.
3. Полученный вектор и метаданные можно сохранить на диск.
📖 Чтение
1. К нам приходит приложение с новым объектом и запросом сделать для него рекомендацию.
2. Нужно проделать весь процесс обработки: векторизовать объект запроса той же моделью, получить вектор той же размерности.
3. По сгенерированному вектору можно найти наиболее близкий вектор. На этом этапе можно сделать предварительную фильтрацию по метаданным — например, искать соседей только с длинной текста больше n.
Поиск наиболее подходящих соседей может работать долго, ведь нужно просмотреть все записи на диске. Решение этой проблемы — индексация. Мы чуть замедлим запись, но чтение будет работать сильно быстрее. Про разные алгоритмы индексации подробнее расскажем в следующем посте.
👍15🔥12❤7
Несколько алгоритмов индексирования, которые ускоряют поиск наиболее близких векторов:
Уменьшение размерности с помощью случайной проекции
Нужно уменьшить размерность векторов, но сохранить свойство схожести. Это можно сделать согласно лемме Джонсона-Линденштрауса:
Для этого нужно сгенерировать матрицу случайной проекции, на которую будем скалярно умножать входные вектора. На выходе получаем вектора меньшей размерности, которые сохраняют свойство подобия. Из-за небольшой потери информации снижается точность, но увеличивается скорость из-за уменьшения размер векторов.
Хэширование с учетом местоположения
Хэш-функция определяет, в какой из бакетов попадёт вектор. Она позволяет группировать похожие вектора в одни и те же бакеты. Чтобы найти ближайших соседей для вектора запроса, нужно определить его бакет при помощи хэширования. Выполнить поиск можно среди данного бакета, не рассматривая предварительно неблизкие вектора. Этот метод намного быстрее, чем поиск по всему набору данных, потому что в бакете меньше векторов, чем во всем пространстве.
Качество этого метода зависит от свойств выбранной функции хэширования точно так же, как и в устройстве обычной хэш мапы.
Подробнее про алгоритмы индексирования и их применение на практике — в нашей статье на Хабре .
Уменьшение размерности с помощью случайной проекции
Нужно уменьшить размерность векторов, но сохранить свойство схожести. Это можно сделать согласно лемме Джонсона-Линденштрауса:
«Небольшой набор точек в пространстве большой размерности может быть вложен в пространство гораздо меньшей размерности таким образом, что расстояния между точками почти сохраняются».
Для этого нужно сгенерировать матрицу случайной проекции, на которую будем скалярно умножать входные вектора. На выходе получаем вектора меньшей размерности, которые сохраняют свойство подобия. Из-за небольшой потери информации снижается точность, но увеличивается скорость из-за уменьшения размер векторов.
Хэширование с учетом местоположения
Locality-sensitive hashing (LSH) — метод индексации, который похож на устройство обычной хэш-мапы. Суть в том, чтобы отобразить вектора в бакеты похожести, используя набор функций хеширования.
Хэш-функция определяет, в какой из бакетов попадёт вектор. Она позволяет группировать похожие вектора в одни и те же бакеты. Чтобы найти ближайших соседей для вектора запроса, нужно определить его бакет при помощи хэширования. Выполнить поиск можно среди данного бакета, не рассматривая предварительно неблизкие вектора. Этот метод намного быстрее, чем поиск по всему набору данных, потому что в бакете меньше векторов, чем во всем пространстве.
Качество этого метода зависит от свойств выбранной функции хэширования точно так же, как и в устройстве обычной хэш мапы.
🔥16👍7🤓4❤2👨💻2
Топ-3 просчёта в А/B-тестировании: культурологические
1. Проводить эксперименты без дизайна и action plan
Запущенный A/B-тест без предварительно выполненного дизайна — редкость, а хорошо продуманный action plan попадается нечасто.
Наш совет: до запуска эксперимента продумайте, какое решение вы будете принимать в разных сценариях. Например:
Составление Action plan до старта эксперимента помогает не только принимать решения, но и оставаться честным перед собой, коллегами и продуктом.
2. Расстраиваться, если нет прокраса
Если бы каждый эксперимент завершался прокрасом и ростом продукта, было бы слишком скучно жить, а A/B-тесты потеряли бы смысл: зачем делать их, если каждая гипотеза ведёт к успеху? Но мы знаем, что в реальности большая часть идей не срабатывает:
Поэтому, если эксперимент не взлетел, как можно скорее доходим до стадии «принятия», и идём дизайнить следующий A/B-тест.
3. A/B-тесты замедляют T2M, или Жизнь слишком коротка, чтобы проводить A/B-тесты
Понятно, что ничего не делать быстрее, чем что-то делать. Но катить фичи без экспериментов ≠ развивать продукт быстрее:
Чтобы ускорить процесс выкатки фичи, нужно верно настроить циклы discovery и delivery в команде — например, с помощью фреймворка Double Diamond. Тогда запуск A/B-тестов встанет на поток, гипотезы будут проверяться, фичи — выкатываться, а метрики продукта — расти.
Profit!
1. Проводить эксперименты без дизайна и action plan
Запущенный A/B-тест без предварительно выполненного дизайна — редкость, а хорошо продуманный action plan попадается нечасто.
Наш совет: до запуска эксперимента продумайте, какое решение вы будете принимать в разных сценариях. Например:
- Если не прокрасилась основная метрика, а вспомогательные показывают разноплановую динамику.
- Если все метрики серые, но это изменение открывает путь для новых фичей и гипотез.
- Если основная метрика зеленая, а защитная упала заметно, но не статистически значимо.
Составление Action plan до старта эксперимента помогает не только принимать решения, но и оставаться честным перед собой, коллегами и продуктом.
2. Расстраиваться, если нет прокраса
Если бы каждый эксперимент завершался прокрасом и ростом продукта, было бы слишком скучно жить, а A/B-тесты потеряли бы смысл: зачем делать их, если каждая гипотеза ведёт к успеху? Но мы знаем, что в реальности большая часть идей не срабатывает:
“80% of the time you/we are wrong about what a customer wants.”
“Netflix considers 90% of what they try to be wrong.”
“Microsoft is no different … only about one-third (experiments) were successful at improving the key metric!”
Поэтому, если эксперимент не взлетел, как можно скорее доходим до стадии «принятия», и идём дизайнить следующий A/B-тест.
3. A/B-тесты замедляют T2M, или Жизнь слишком коротка, чтобы проводить A/B-тесты
Понятно, что ничего не делать быстрее, чем что-то делать. Но катить фичи без экспериментов ≠ развивать продукт быстрее:
- Долго ли просуществует такой продукт?
- Какими будут его метрики роста?
- Сколько упущенных возможностей и шагов назад мы сделаем, если не будем проверять гипотезы экспериментами?
Чтобы ускорить процесс выкатки фичи, нужно верно настроить циклы discovery и delivery в команде — например, с помощью фреймворка Double Diamond. Тогда запуск A/B-тестов встанет на поток, гипотезы будут проверяться, фичи — выкатываться, а метрики продукта — расти.
Profit!
❤20🔥8🤓3👍1