Value Stream Mapping

В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM).

Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения.

Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping:
1. Собираем ключевых участников.
2. Формулируем, какую стратегическую задачу мы хотим решить.
3. Записываем проблемы, вопросы, идеи.
4. Группируем их, выбираем главную область для улучшения.
5. Формулируем конкретный и измеримый результат.

В статье ещё приводится несколько конкретных примеров Outcome mapping.

Теперь можно перейти к построению VSM.
Что нужно отразить на карте:
— Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем.
— Задержки — проанализировать и отразить места, где работа простаивает.
— Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой.
— Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет

В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места?

На тему ускорения процесса доставки у нас был пост, где мы анализировали источники багов.
А сократить путь бага нам помогает табличка с зонами ответственности.

#systemdesign

Конкретный автоэнкодер [2019] и его улучшение [2024]

Итак, обычно в автоэнкодерах мы решаем задачу сжатия изначального вектора фичей в пространство маленькой размерности. Мы обучаем энкодер q(z|x) и декодер p(x|z) таким образом, чтобы у нас получалось восстановить изначальный вектор x из вектора скрытых переменных z.

Конкретный автоэнкодер ставит задачу более интересным образом - вместо перевода вектора фичей в скрытое пространство мы хотим выбрать список фичей в x, который и будет этим самым вектором скрытых переменных.

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

Слово "конкретный" в названии - "concrete" - на самом деле сокращение от Continuous Discrete - это параллельное изобретение того самого Gumbel Softmax трюка, который я описывал в позапрошлом посте.

Единственным параметром энкодера является матрица KxN - размерность скрытого вектора на кол-во фичей. В каждой строке у нас находится обучаемый вектор "логитов" для каждой фичи, к которому мы применяем Gumbel Softmax и получаем soft one-hot вектор-маску для всех фичей, которую затем скалярно умножаем на исходный вектор фичей - получая таким образом дифференцируемую аппроксимацию выбора одной фичи из всего списка.

Делая это независимо K раз, мы выбираем K фичей, которые и становятся выходом энкодера. В базовой статье про конкретный автоэнкодер иллюстрация на MNIST демонстрируют способность такой схемы обучиться игнорировать пиксели по краям и при этом задействовать по 1 пикселю из всех остальных частей картинки, никогда не беря соседние. Эксперименты на других датасетах там тоже есть.

Indirectly Parameterized CAE - улучшение данного подхода. Я с CAE не развлекался, но утверждается, что у базовой модели есть проблемы со стабильностью обучения, а также она почему-то всё же дублирует фичи по несколько раз, что, вроде как, тоже связано с этой нестабильностью.

Один простой трюк очень сильно улучшает ситуацию. Вместо обучаемой матрицы KxN используется Indirect Parameterization - эта матрица вычисляется как функция от 3 обучаемых штук: умножения матрицы KxN на матрицу NxN и прибавления вектора размера N к каждой строке результата.

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

Главный вопрос - а нахрена вообще всё это нужно?

Внезапно эта идея имеет отличное практическое применение в нейросетях, а именно для проведения Feature Selection! В ситуации, когда обучать сеть супердорого и вы можете позволить это делать единичное число раз, а фичей у вас тысячи, использование Конкретного Энкодера в самом начале модели позволяет обучить Selection K фичей из N напрямую. При этом, если качество модели совпадает с качеством изначальной модели, можно смело выкидывать из прода целых N-K фичей.

Коллеги рапортуют о том, что у нас это заработало, так что, с чистой совестью делюсь хаком.

@knowledge_accumulator

Привет, друзья! Сегодня кратко-пост
про небольшое удивительное чтение с множеством ссылок.

Рассмотрим обученную модель машинного или глубокого обучения. Как её отучить от чего-либо?

Что делать, если модель

1. гендерно или социально предвзята? [1, 2, 3]
2. отдаёт вредоносные ответы;
3. содержит данные, защищенные авторским правом или личные данные;
4. галлюцинирует

Можно ли заставить её забыть изученное? Можно и сложно.

Model (от истоков machine) unlearning (MU) — актуальная задача для больших моделей, восставшая от проблем машинного обучения. Восставшая — потому что, если рассматривать агрегаторы статей, проблема отучения редко упоминалась, чаще всего рядом с SVM, в 2000-2015 и сделала скачок с 2018 года рядом с глубокими моделями.

Что интересно, термин «механистическая интерпретируемость» тоже сперва был рядом с ML моделью SVM. Нестареющая классика!

Подходы в MU глобально разделены на 3 группы:

1. Model-Agnostic Methods (независимые от модели)
2. Model-Intrinsic Methods (встроенные в процесс обучения модели)
3. Data-Driven Methods (основанные на изменении данных)

Key Idea из методов: заставить модель забыть что-то — это больше чем про полное переобучение (потому что это чаще будет дорого). Если посмотреть на подходы «очень сверху», то мы можем:

1. Применять обучение с подкреплением (проводить хитрый файн-тюнинг);
2. Выполнять градиентный подъем по примерам под забывание (проводить хитрый файн-тюнинг);
3. Модифицировать пространство обучения (менять данные, чтобы проводить хитрый файн-тюнинг или обучение)
4. Использовать различные методы файн-тюнинга (LoRA, KL-divergence based etc) (снова проводить хитрый файн-тюнинг)
5. Накладывать условие на изменение параметров модели для конкретных примеров (проводить хитрое обучение/дообучение (снова файн-тюнинг));
6. Находить параметры, отвечающие за конкретное поведение и занулять их (не однозначный, но валидный к жизни метод, так как также важно показать, что зануление не вызвало других нежелательных поведенческих изменений)

Быть может, я не докопала до идей глубже (и если вы знаете что-то — welcome в комментарии!), но отучение преимущественно построено на генерации гипотез о том, как дообучить модель или же как устранить нежелательное поведение точечно (если говорить о "выключении" активаций).

Ещё интересно, что хотя статьи 1-3 также сосредоточены на устранении точечных признаков/паттернов поведения, термин "unlearning" в них явно не упоминается. Это может усложнять, как мне кажется, будущие обзоры и поиск литературы — необходимо генерировать и анализировать смежные ключи. Будьте всегда внимательны)

Пара полезных ссылок про Unlearning:

1. Глубокая детализация подходов для MU здесь.
2. Репозиторий, собирающий статьи по MU

Такой мини-обзор, друзья! Само наличие класса исследований про unlearning просто вдохновляет — чем больше модели, тем будто бы больше задач нам нужно решать.

Бесконечная область, выходит :)

Отличного вам вечера,
Ваш Дата автор!

#softskills #career

Несогласие и кризис

В сегодняшнем посте объединены два тимлидских материала, к которому я приложил руку и голову.

1. Три тимлида заходят в бар и не соглашаются. В этом выпуске мы рассмотрели что делать, когда в команде кто-то с чем-то не согласен (например, постоянно не согласен с тобой). Когда это нормально, когда не очень, а когда это откровенный саботаж. Не обошлось без выходов раз на раз, рептилоидов и серийных хейтеров на работе!
https://t.me/teamleadsBar/75

2. Кризис — это проблема или возможность? Дебаты, на, казалось бы, однозначную, но на самом деле нет, тему. Там мы с Настей Абрашитовой постарались раскрыть все плюсы и минусы кризисных и спокойных времен для руководителя. А в конце еще и поучительное напутствие подвели, обязательно досматривайте до конца, рефлексируйте, прикидывайте на себя.
https://www.youtube.com/watch?v=tY2C5zRe-EM

Как улучшили ML-продукт, взглянув на данные по-новому

Почитал интересный пост про то как команда разрабатывала ML-систему для снижения числа негативных отзывов в сервисе заказов поездок.

Первая версия снизила жалобы всего на 1% вместо необходимых 4,5%. После доработки — 3%, но этого всё ещё было недостаточно.

В итоге помог новый взгляд на данные. Выяснилось что 20% водителей создают 80% поездок и жалоб.

Фокус на этих водителях позволил снизить затраты и достичь цели.

Вывод: Иногда дело не в модели, а в том, на какие данные мы смотрим.

Заметка

#interview #sql

#gpu #courses