Стажировка в штатах — Data Science в Seagate

 Публичный пост
11 ноября 2021  569

Вступление

Хочу поделиться опытом прохождения стажировки в роли Data Scientist в компании Seagate, которая формально была в долине, а по факту удаленно в Нью-Йорке. Стажировка длилась 3 месяца.

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

В штатах стажировки - что-то вроде испытательного срока, «трёхмесячное интервью», как сказал мне рекрутер. Собеседования похожи на те, что использую на фулл-тайм позиции, а иногда такие же. Зарплаты, как я знаю, около 80% от зарплат на фулл-тайме, интернам часто дают проекты или куски работы, на которых можно получить понятный и полезный для компании результат в течение стажировки.

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

Как это было

На деле выяснилось, что конкретно эту инициативу по оптимизации производства ПП в компании толкает один человек, а получить результат пытается команда из 5 интернов. Поначалу я загрустил, потому что не было ни одного фулл-тайм инженера, с которым можно было бы пообщаться, но в итоге все оказалось совсем неплохо. Интерны - PhD студенты Computer Science 3-4 года - оказались опытными и знающими ребятами.

Основной задачей группы была разработка решения для оптимизация контроля качества полупроводников - разумеется, с помощью алгоритмов машинного обучения. Источником данных были сенсоры, которыми облеплено оборудование на производстве, плюс несколько дискретных параметров, характеризующих процесс. Установка сенсоров, как я понял, тоже была частью эксперимента, никто не был уверен, будет ли от них толк. В итоге данные были в формате мультивариативных временных рядов (multivariate time series, короче).

(Следующие 3 абзаца - техчасть, может быть скучно)

Когда я заступил на службу, работа над задачей классификации с обучением велась уже давно, и были какие-то адекватные результаты. Классифицировали полупроводники в две категории - норм или брак. Основными проблемами были дико несбалансированные данные (брака было около 1.5%) и субъективность лейблов, которые и использовались для обучения. Тем удивительнее было то, что модельки что-то смогли в этом разобрать. Особенно забавно было то, что попытки выяснить у инженеров то, как же они выявляют брак вручную, затыкались на ответах типа «я просто знаю».

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

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

(Конец техчасти)

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

Фидбэк получал в основном от «старшего» интерна, который работал на проекте не первый год. Чувак очень много знал и задавал четкие вопросы, работать с ним понравилось.

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

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

Итого

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

Насколько я понял, в других департаментах стажировки более структурированы и похожи на стажировки. Я попал в команду, которая заточена под реальную работу (ресерч), чему очень рад.

6 комментариев 👇
Ivan Petrov, Machine Learning Engineer 22 ноября в 19:59

Интересный опыт, но я ожидал куда более развернутую техчасть и прохладные истории про приколюхи с данными и модельками, если NDA позволяет таковые рассказать.
Было бы клево увидеть вторую часть - тут или в отдельном треде.

  Развернуть 1 комментарий

@obi-ivan_kenobi,

Техчасть - для менее широкой аудитории, с удовольствием поделюсь тут.

Фундамент описан здесь: https://arxiv.org/pdf/2111.05973.pdf, это трансформер для классификации.

Данных всего было около 250 к точек, но оказалось, что для каждого типа измерения отдельно работает намного лучше, поэтому стал тестировать на одном самом жирном. В нем было около 60 к точек, из них для обучения использовал, кажется, 50.

Данные multivariate time series, с тремя измерениями: (кол-во точек х кол-во временных сэмплов х кол-во фич). Серии короткие, большиство с 2 сэмплами, но все паддились до 7, потому что самая длинная 7. Пробовали цифры меньше, лучше не стало. Фич было больше 300.

Размерность на выходе - 1 х 1, предсказывал одно число.

Обработка данных состояла в основном из фильтрации дубликатов и нерепрезентативных категорий, данные были уже неплохо обработаны, не сырые. Для заполнения пропусков пробовал среднее, деревья и MICE (итеративный алго с деревьями). Все деревья работали очень долго - несколько дней на одном куске, поэтому репрезентативного результата не получил. Думаю, что это могло бы улучшить результат, но в итоге использовал среднее.

Опробовал модели:

  • Базовая Convolutional 1D: Conv1d > BatchNorm > AvgPool > Dropout > Dense; AvgPool потому, что другой стажер ранее тестировал сетки на основе Conv1D и обнаружил, что AvgPool работает хорошо.

  • "Трехголовая" Convolutional 1D: три отдельных ветки Conv1d > BatchNorm > AvgPool, выход из них объединяется Concat, далее Dropout > Dense

  • Базовая LSTM: LSTM > LSTM > Dense > Dense > Dense

  • "Трехголовая" LSTM: три отдельных ветки LSTM > BatchNorm > AvgPool, выход из них объединяется Concat, далее Dropout > Dense

-Трансформер из статьи с небольшими модификациями (где-то добавил Dense, перестроил под регрессию)

-"Двойной" трансформер: стандартный трансформер, считающий attention матрицу вдоль измерения временных сэмплов и трансформер, считающий матрицу вдоль фич. Выход из обоих соединяется Concat'ом, затем Dropout > Dense. Размер матрицы первого трансформера - (кол-во сэмплов х кол-во сэмплов), второго - (кол-во фич х кол-во фич).

Идея считать attention вдоль фич в том, что в фичах есть дискретные переменные (one-hot encoded), которые характеризуют процесс, и трансформер выучит, на какие сенсорные фичи активироваться в зависимости от того, какие дискретные переменные присутствуют.

Все модели основаны на слоях, которые созданы для работы с time series (Conv1D, LSTM). Идея "трехголовых" моделей заимствована из mutli-headed transformer.

Оптимайзер - стандартный Adam, активации - ReLU. В моделях тестировал количесто разных слоев, количество весов в Conv1D, LSTM, Dense слоях, фундаментальный тест параметров не делал Целью было найти оптимальную модель, на которой можно сфокусироваться в дальнейшем.

Сравнивал learning rate scheduling vs постоянное значение learning rate, постоянный работал лучше.

Тестировал лосс-функции: RMS, Mean Relative Squared Error (MRSE), Focal, SuperLoss. RMS была стабильно хороша, но SuperLoss заметно улучшил результат (открытие для меня).

Использовал метрики: Mean Squared Error, Mean Absolute Error, Mean Relative Absolute Error, Mean value of Absolute Error over Standard Devi-ation.

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

Высокоуровневый, но с некоторыми деталями обзор - если есть желание углубиться еще дальше, можно в телегу/зум.

  Развернуть 1 комментарий

@spetrov, мощно. Я пока что далек от нейронок, но суть понял. Про SuperLoss вообще слышу впервые.

  Развернуть 1 комментарий

@obi-ivan_kenobi, я тоже про суперлосс не слышал до этого, в процессе познакомился :)

  Развернуть 1 комментарий
Egor Suvorov, Программист/преподаватель C++ 1 день, 2 часа назад

А как на стажировку попал? Уже находился в США и это какие-то местные программы для всех подряд/только для студентов или из-за рубежа тоже можно?

  Развернуть 1 комментарий

@yeputons, я был студентом американского вуза, было разрешение на работу. Других кейсов не встречал, если не академия.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб