Рефлексия о работе в OpenAI или как из хаоса и атомарных действий рождается великое.
Ex сотрудник Codex рассказывает о своем опыте работы в OpenAI.
Советую почитать самостоятельно, если уж английский не ваше - перевод тут.
Выделю то, что именно интересно мне, в основном, это процессы, за остальным вэлкам, опять же, в полную версию.
1. Наличие моно-репо разработки, отсутствие коммуникаций в почте. Да, ребята общаются через мессенджер - Slack. Имеется многоуровневая система доступов, особенно, к чатам с фин. информацией. В почте почти нет коммуникации, автор буквально получал около 10 писем за все время. На сладкое разработка в одном огромном монорепозитории.
2. Процессы под лозунгом "bias to action". Формирование групп и команд идет по интересам и сразу в бой. Зачастую, годные идеи и их реализации просто интегрируют в более масштабный флоу к основной ветке. Отсюда возможность создания параллельно нескольких групп, делающих одну фичу по-своему, далее побеждает "сильнейший". Также это дает возможность расти тем, кто делает интересное/полезное хорошо и быстро, даже без возможности нормальной презентации. Вокруг таких успешных групп быстро далее формируется core команда для доведения до ума решения. Обычно все крутые фичи рождаются в рамках "мелких" исследований, это в т.ч. порождает порой огромные распределенные кусочки, которые важно соединить воедино. Отсюда и важны руководители.
3. Руководители исследовательских групп – «мини CEO». В рамках работы, при создании трека важная максимальная самостоятельность и принятие рисков. Поэтому лиды групп становятся мини-CEO, которые видят весь ландшафт работ, в т.ч. в соседних командах. Отмечается важность иметь хороших research engineering manager и PMов. Причём люди, занимающие данные позиции обладают открытым и широким взглядом, создавая впечатление что уже видели все. Но эта черта не мешает поддерживать команды, мотивировать на успех и минимально вмешиваться в реализацию. Такие руководители поощряют креатив и т. п., а не микроменеджерят, помогая и нанять лучших людей под задачу или ротировать их, а также дать выч. ресурсы.
Как следствие из п. 1-3, компания довольно гибкая и быстро может менять направление исследований и разработок. Все что не интересно, решенное и устарело, скорее всего, делаться не будет. Также это не дает возможности быть инертными и четко двигаться по плану/стратегии в отличии от конкурентов в Google и др. Руководители вовлечены в работу и не ждут квартального планирования и планового перераспределения в штат, подтягивая опять же быстро нужных людей. Какой к чёрту план, когда вы на острие технологий и все меняется молниеносно.
4. Важность оптимизации GPU. Работа с оптимизацией латенси вплоть до времени отклика на генерацию первого токена. Отмечается, что ресурсы GPU для создания одной нишевой функции Codex были сопоставимы по затратам со всем пайпом сбора и чистки данных логов клиентов.
5. Не забываем о социальной ответственности. Большое внимание уделяется практическим угрозам (например, разжиганию вражды, злоупотреблению технологиями, манипуляциям общественным мнением, созданию биологического оружия, проблемам самолечения и атакам методом инъекций запросов), нежели абстрактным рискам вроде интеллектуального скачка или стремлениях машин к власти. Однако это вовсе не означает, что вопросами гипотетических рисков никто не занимается — такие специалисты действительно существуют.
Интересно? Читайте полную версию и черпайте интересные моменты для себя. Жду от вас комментарии, что отметили именно вы.
Upd. Мне напомнило это все, кстати, рассказ разработчиков ChatGPT, как они сделали это. Когда Сэм пришел и попросил перед очередным собранием инвесторов удивить его, команда достала из широких штанин, что они делали с GPT3.5 (или 3). И это было оно. Сама сказал, накинуть на это GUI и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.
Ex сотрудник Codex рассказывает о своем опыте работы в OpenAI.
Советую почитать самостоятельно, если уж английский не ваше - перевод тут.
Выделю то, что именно интересно мне, в основном, это процессы, за остальным вэлкам, опять же, в полную версию.
1. Наличие моно-репо разработки, отсутствие коммуникаций в почте. Да, ребята общаются через мессенджер - Slack. Имеется многоуровневая система доступов, особенно, к чатам с фин. информацией. В почте почти нет коммуникации, автор буквально получал около 10 писем за все время. На сладкое разработка в одном огромном монорепозитории.
2. Процессы под лозунгом "bias to action". Формирование групп и команд идет по интересам и сразу в бой. Зачастую, годные идеи и их реализации просто интегрируют в более масштабный флоу к основной ветке. Отсюда возможность создания параллельно нескольких групп, делающих одну фичу по-своему, далее побеждает "сильнейший". Также это дает возможность расти тем, кто делает интересное/полезное хорошо и быстро, даже без возможности нормальной презентации. Вокруг таких успешных групп быстро далее формируется core команда для доведения до ума решения. Обычно все крутые фичи рождаются в рамках "мелких" исследований, это в т.ч. порождает порой огромные распределенные кусочки, которые важно соединить воедино. Отсюда и важны руководители.
3. Руководители исследовательских групп – «мини CEO». В рамках работы, при создании трека важная максимальная самостоятельность и принятие рисков. Поэтому лиды групп становятся мини-CEO, которые видят весь ландшафт работ, в т.ч. в соседних командах. Отмечается важность иметь хороших research engineering manager и PMов. Причём люди, занимающие данные позиции обладают открытым и широким взглядом, создавая впечатление что уже видели все. Но эта черта не мешает поддерживать команды, мотивировать на успех и минимально вмешиваться в реализацию. Такие руководители поощряют креатив и т. п., а не микроменеджерят, помогая и нанять лучших людей под задачу или ротировать их, а также дать выч. ресурсы.
Как следствие из п. 1-3, компания довольно гибкая и быстро может менять направление исследований и разработок. Все что не интересно, решенное и устарело, скорее всего, делаться не будет. Также это не дает возможности быть инертными и четко двигаться по плану/стратегии в отличии от конкурентов в Google и др. Руководители вовлечены в работу и не ждут квартального планирования и планового перераспределения в штат, подтягивая опять же быстро нужных людей. Какой к чёрту план, когда вы на острие технологий и все меняется молниеносно.
4. Важность оптимизации GPU. Работа с оптимизацией латенси вплоть до времени отклика на генерацию первого токена. Отмечается, что ресурсы GPU для создания одной нишевой функции Codex были сопоставимы по затратам со всем пайпом сбора и чистки данных логов клиентов.
5. Не забываем о социальной ответственности. Большое внимание уделяется практическим угрозам (например, разжиганию вражды, злоупотреблению технологиями, манипуляциям общественным мнением, созданию биологического оружия, проблемам самолечения и атакам методом инъекций запросов), нежели абстрактным рискам вроде интеллектуального скачка или стремлениях машин к власти. Однако это вовсе не означает, что вопросами гипотетических рисков никто не занимается — такие специалисты действительно существуют.
Интересно? Читайте полную версию и черпайте интересные моменты для себя. Жду от вас комментарии, что отметили именно вы.
Upd. Мне напомнило это все, кстати, рассказ разработчиков ChatGPT, как они сделали это. Когда Сэм пришел и попросил перед очередным собранием инвесторов удивить его, команда достала из широких штанин, что они делали с GPT3.5 (или 3). И это было оно. Сама сказал, накинуть на это GUI и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.