Shopify — это один из крупнейших конкурентов Amazon в сфере онлайн‑ритейла. В компании работает около 10 000 человек. Shopify, в отличие от Amazon — централизованной торговой площадки, предлагает коммерческим структурам платформу для создания их собственных онлайн‑магазинов и веб‑сайтов. Shopify — это одна из крупнейших технологических организаций, в которой применяется полностью удалённый режим работы. Она перешла к такой модели в начале 2020 года. Это — одна из последних компаний такого размера, которая не переводит сотрудников обратно в офисы. По крайней мере — пока не переводит.

Shopify находится в самом разгаре внесения серьёзных изменений в свои процессы разработки ПО и в свою систему распределения сотрудников по уровням. Новая система основана на концепции «мастерства». В её рамках существующие уровни делятся на более мелкие части. Компания планировала ввести в строй эти новые «уровни мастерства» в мае, но она немного отстаёт от графика. Правда, даже учитывая это, изменения в уровнях сотрудников уже начались.

Я поговорил с несколькими инженерами‑программистами и менеджерами, которые сейчас работают в Shopify. Мне было интересно узнать от них о том, как в компании работает система уровней сотрудников, что вкладывается в понятие «мастерство», почему компания решила сделать то, что сделала. В этом материале мы исследуем следующие вопросы:

Значения Шепли применяются в экономике, а точнее — в теории кооперативных игр. Такие значения назначаются игрокам сообразно их вкладу в игру. В сфере машинного обучения идея использования значений Шепли нашла отражение во фреймворке SHAP (SHapley Additive exPlanations). Он представляет собой эффективный инструмент для интерпретации механизмов функционирования моделей.

Если вам интересны подробности о значениях Шепли — очень рекомендую обратиться к моей предыдущей статье, посвящённой математическим и интуитивным представлениям, раскрывающим смысл этих значений. И хотя в машинном обучении эти значения применяются по‑особенному, понимание базовых принципов, на которых они основаны, может оказаться полезным.

Использование значений Шепли во фреймворке SHAP напоминает их классическое применение тем, что они отражают индивидуальное влияние признаков на «игру» (другими словами — на модель машинного обучения). Но модели машинного обучения — это «игры», где нет «кооперирования» игроков, то есть — признаки не обязательно взаимодействуют друг с другом, как это происходило бы, будь они игроками в кооперативной игре. Вместо этого каждый из признаков вносит независимый вклад в результаты работы модели. Хотя тут может быть использована формула для нахождения значений Шепли, соответствующие вычисления могут оказаться слишком «тяжёлыми» и неточными. Это так из‑за большого количества «игроков» и из‑за того, что они могут объединяться в «союзы». Для того чтобы решить эту проблему, исследователи разработали альтернативные подходы. Среди них — метод Монте‑Карло и ядерные методы. В этом материале мы будем заниматься методом Монте‑Карло.

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

Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.

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

ChatGPT, GPT-4 и Claude — это мощные языковые модели, которые дообучают, используя метод, который называется «обучение с подкреплением на основе отзывов людей» (Reinforcement Learning from Human Feedback, RLHF). Благодаря этому такие модели лучше отражают наши ожидания в плане их поведения, они лучше соответствуют тому, как мы собираемся их использовать.

В этом материале мы рассмотрим процесс обучения модели LLaMa c использованием RLHF. Модель будет учиться отвечать на вопросы с сайта Stack Exchange.

Большие языковые модели (Large Language Model, LLM) сейчас у всех на слуху. Они привлекают внимание общественности своей, казалось бы, впечатляющей возможностью — составлять осмысленные тексты в ответ на запрос пользователя (иногда такие запросы называют «приглашениями», а так же — «промптами» или «промтами» — от английского «prompt»). Эти системы представляют собой тщательно сконструированные комбинации из исключительно простых алгоритмов, огромных объёмов данных и грандиозных вычислительных мощностей. LLM учатся, бесчисленное множество раз играя сами с собой в игру «угадай следующее слово». В каждом раунде такой игры модель смотрит на часть предложения и пытается угадать, или предсказать, следующее слово. Если слово угадано — модель обновляет параметры для того чтобы подкрепить свою уверенность; в противном случае модель учится на своей ошибке для того чтобы в следующий раз её догадка была бы точнее.

Хотя базовый алгоритм обучения LLM, по большому счёту, уже давно не меняется, недавнее увеличение размеров моделей и данных наделило эти модели качественно новыми возможностями. Среди них — написание простого программного кода и решение логических задач.

Как эти модели достигли таких результатов? Они всего лишь запоминают обучающие данные и потом их воспроизводят, или они схватывают правила английской грамматики и усваивают синтаксис языка C? Создают ли они нечто вроде внутренней модели мира — доступной для понимания модели процесса, выдающего некие последовательности данных?

Недавно мы рассказывали о последнем поколении процессоров Intel Xeon (кодовое название Sapphire Rapids). Мы говорили об их новых аппаратных возможностях, ориентированных на ускорение задач глубокого обучения,  разбирались с тем, как использовать их для ускорения распределённого дообучения трансформеров, занимающихся обработкой естественного языка, как применять их для ускорения работы таких моделей.

В этом материале мы собираемся остановиться на различных подходах к ускорению моделей Stable Diffusion на процессорах Sapphire Rapids. В следующем похожем посте речь пойдёт о распределённом дообучении.

В этом материале приведён краткий обзор использования модульного подхода в задачах глубокого обучения. Более детальный разбор этой темы вы можете найти здесь. Если вас интересует модульный подход к тонкой настройке (дообучению) моделей обработки естественного языка — взгляните на наше учебное руководство 2022 года по EMNLP. Дополнительные материалы по модульному глубокому обучению вы можете найти на этом ресурсе.

Представьте, что вы, совершенно один, отдыхаете в своём маленьком бревенчатом домике в лесу. Когда вы, декабрьским вечером, начинаете читать уже вторую книгу из списка «Книги недели», вы слышите поблизости чьи-то тяжёлые шаги. Вы бросаетесь к окну, чтобы посмотреть — кто это там прошёл. Через окно вы видите крупный силуэт кого-то, кто, кажется, покрыт мехом. Существо исчезает в тёмном лесу сразу за вашим крыльцом. Информация, которую вы получили из окружающей среды, прямо-таки кричит вам: «Я встретил снежного человека!». Но ваш здравый рассудок говорит, что это был, с гораздо большей вероятностью, просто слишком увлечённый путешествием турист, который прошёл мимо вашего дома.

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

1 декабря я в очередной раз поучаствовал в Advent of Code, написав программу на Rust. Если интересно — код можно найти на GitHub. Тут мне хотелось бы рассказать о моём решении задачи, предлагавшейся во 2 день мероприятия, так как это решение, с одной стороны, сверх всякой меры оптимизировано, а с другой — демонстрирует кое-какие полезные приёмы. Чтобы не усложнять себе жизнь — мы рассмотрим лишь первую часть задачи, но те же приёмы можно применить и к её второй части.

Этот материал посвящён формированию культуры технических собеседований, проводимых с учётом потребностей людей и с уважением к ним.

Публикуем девятую, заключительную часть (1, 2, 3, 4, 5, 6, 7, 8) перевода руководства по модулю asyncio в Python. Здесь вы найдёте разделы исходного материала с 23 по 26.

Любому образованному человеку непременно нужно иметь общее представление о бухгалтерском учёте. Так же, как и математика, естественные науки, программирование, музыка, литература, история, да и много чего ещё, бухучёт — это одна из тех сфер знаний, которые помогают нам понимать этот мир. Хотя работа с деньгами — не особо увлекательное занятие, это — неотъемлемая часть жизни, поэтому вполне можно уделить некоторое время на то, чтобы в этом разобраться.

Я полагаю, что, к сожалению, большинство бухгалтеров совсем не умеют понятно рассказывать о том, чем они занимаются, объяснять это другим людям. Бухучёт — это область, полная жаргона, акронимов, странных терминов, пришедших из глубины веков. Да у меня даже от книги «Бухучёт для чайников» кружится голова. А на самом деле, наверняка, всё это не может быть таким уж сложным.

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

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

Перед вами восьмая часть (1, 2, 3, 4, 5, 6, 7) перевода руководства по модулю asyncio в Python. Здесь вы найдёте разделы исходного материала с 20 по 22.

Вот какое дело: как показывают мои изыскания, большинство веб-разработчиков поразительно мало знают об HTTP-заголовках или, в целом, о стандарте HTTP. Я имею в виду, что я понимаю то, что во многих университетах и школах, вероятно, этому не учат (там, где я учился, определённо, так и было). А кто будет, сидя дома праздным воскресным утром, думать о том, чтобы развлечь себя чтением стандарта HTTP? Да никто. Знаю, но… есть одно важное обстоятельство: отсутствие хоть какого-то понимания стандарта HTTP — это зияющая дыра в знаниях веб-разработчиков, в знаниях многих из тех, кто это читает. Предлагаю это исправить.

Публикуем седьмую часть (1, 2, 3, 4, 5, 6) перевода руководства по модулю asyncio в Python. Здесь представлены разделы исходного материала с 17 по 19.

Привет, Хабр! Перед вами шестая часть (1, 2, 3, 4, 5) перевода руководства по модулю asyncio в Python. Здесь представлены 14-16 разделы исходного материала.

Привет, Хабр! Публикуем пятую часть (первая, вторая, третья, четвёртая) перевода руководства по модулю asyncio в Python. Здесь представлены разделы оригинала с №10 по №13.

Сегодня, в четвёртой части (первая, вторая, третья) перевода учебного руководства по модулю asyncio в Python, представляем вашему вниманию разделы оригинала №8 и 9.

Примечание Wunder Fund: мы very early adopters Ноушена и большие его фанаты. Поэтому решили перевести нетипичную для нас статью о том, как он создавался, как рос, как развивалась его стратегия. В статье есть ряд интересных мыслей про развитие продуктов.

Сегодня публикуем вторую часть перевода материала о стратегиях роста платформы Notion.

→ Головокружительная первая часть