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

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

Как именно работают подобные механизмы? Потребитель, получая сообщение, берёт его ключ идемпотентности и сравнивает с ключами сообщений, которые уже были обработаны. Если такой ключ уже встречался — входящее сообщение является дубликатом и его можно проигнорировать. В противном случае потребитель начинает обработку сообщения. Например — сохраняя в базе данных само это сообщение или какое-либо представление данных, полученное после его анализа.

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

Metaflow — это фреймворк, работу над которым мы начали в 2019. В том же году мы открыли его исходный код. Теперь он обеспечивает функционирование широкого спектра ML/AI-систем в Netflix, а так же — во многих других компаниях. Он пользуется любовью тех, кто его применяет, так как он помогает им доводить их ML/AI-идеи от стадии прототипа до продакшна. Он позволяет им уделять внимание не решению рутинных задач, а созданию современнейших систем, которые дарят радость людям по всему миру и развлекают их.

Metaflow даёт разработчикам следующие возможности:

С самого начала одной из главных идей, лежащих в основе GRID, была идея о том, что работу с электронными таблицами (spreadsheet) и, в частности, с моделями электронных таблиц, можно сделать легче, если перенести их в веб-среду, снабдив приятно выглядящими комментариями и привлекательными интерактивными возможностями. Это касается как таблиц, с которыми взаимодействует единственный пользователь, так и таблиц, которыми одни пользователи делятся с другими.

Если говорить об интерактивности — то мы заранее знали о том, что нам понадобится наибыстрейший движок электронных таблиц, совместимый с Excel и с Google Sheets (GSheets), способный полноценно работать, пользуясь лишь ресурсами браузера. Так как подобного движка (достаточно функционального) нам найти не удалось, мы, кроме прочего, знали и о том, что нам придётся писать его самостоятельно.

К настоящему моменту мы создали то, что, скорее всего, входит в число 4–5 самых совершенных движков электронных таблиц на планете. И это (вероятно — после Google Sheets) самый продвинутый движок, который полностью работает в браузере.

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

Представьте себе такую картину: пятничным вечером вы нажимаете кнопку воспроизведения видео на Netflix. Не проходит и нескольких секунд, как в ответ на это в недрах системы оживают сотни контейнеров. Обеспечение эффективной работы большого количества контейнеров в Netflix — это один из краеугольных камней обеспечения качественного потокового видео для миллионов пользователей со всего мира. Для того чтобы обеспечить высокую скорость реакции системы таких масштабов, мы модернизировали нашу среду выполнения контейнеров (контейнерный рантайм, container runtime), но, сделав это, мы столкнулись с неприятной неожиданностью, сдерживающей рост нашей системы. Это — архитектура процессоров.

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

Я в последнее время экспериментировал с one-shot-декомпиляцией, используя режим Claude без пользовательского интерфейса в непрерывном цикле. Меня на это вдохновила статья о запуске Claude Code в цикле. Эксперимент оказался на удивление продуктивным.

Я занимаюсь декомпиляцией кода игры Snowboard Kids 2. За три недели, прошедших с того момента, как я начал применять описываемый здесь подход, я сделал больше, чем за предыдущие три месяца. Сейчас за ходом работ можно следить на decomp.dev, а до этого сведения о том, что сделано, я вносил прямо в README.md.

Главная задача этой статьи — показать связь между теорией информации Шеннона и инструментами, которые можно встретить в современных системах машинного обучения. Здесь мы поговорим об энтропии (entropy) и о приросте информации (information gain), потом перейдём к кросс-энтропии (перекрёстная энтропия, cross-entropy), к KL-дивергенции (дивергенция или расхождение Кульбака–Лейблера, относительная энтропия, KL-divergence), рассмотрим методы, используемые в современных системах генеративного ИИ.

Из этой статьи вы узнаете о том, как с помощью Docker упаковать, запустить и развернуть в продакшне полноценный ML-сервис для выдачи прогнозов. Мы рассмотрим все основные действия, необходимые для решения этих задач — от обучения модели до предоставления доступа к ней посредством API и до её распространения в виде образа контейнера.

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

Предположим, вы пишете многопоточное приложение для Linux, которое рассчитано на длительную работу. Может — это СУБД или какой-нибудь сервер. Представим ещё, что ваша программа не рассчитана на какую-нибудь среду выполнения кода (скажем — на JVM, Go или BEAM), которая берёт на себя управление низкоуровневыми вещами. Вы сами управляете порождением потоков (thread), прибегая к системному вызову clone. Когда пишут на C — потоки создают с помощью pthread_create, а в C++ применяется std::thread. (1)

Привет! Меня зовут Brent «Brentmeister» Randall (Брент Рэндалл). Я — инженер из команды Gameplay Integrity, которая занимается игрой VALORANT. В сферу нашей ответственности входит система сборки игры, фреймворки, используемые для автоматизации различных задач, производительность игрового клиента и серверов. Именно последнему пункту этого списка и посвящена данная статья. Я поделюсь с вами историей поиска подходов, позволивших вывести производительность наших серверов на оптимальный уровень.

На самых ранних этапах разработки проекта мы уже знали о том, что VALORANT отличается весьма жёсткими требования к производительности игровых серверов. Надеюсь, мне удастся дать вам некоторое представление о том, почему это так, и о том, как были достигнуты наши амбициозные цели. В самом начале серверный кадр (server frame, цикл обработки данных на сервере) длился 50 мс. А после завершения оптимизации нам удалось сократить это время до менее чем 2 мс. Всё это сделано благодаря анализу и оптимизации кода проекта, а так же — благодаря подстройке «железа» и тюнингу ОС.

Эпоха больших языковых моделей (LLM, Large Language Model) снова и снова ставит перед нами вопрос о том, что отличает великую прозу от просто хорошей.

Отвечая на этот вопрос, обычно довольно расплывчато рассуждают о «стиле»: о неуловимом, мистическом качестве, которое свойственно таким людям, как Хемингуэй, Вулф или Вудхаус. Это — как один судья сказал о порнографии: мы узнаём её, когда видим. Мы способны узнать стиль текста, мы даже можем его сымитировать. Но можем ли мы его измерить? Можем ли мы создать для него производственную функцию?

Большинство современных LLM выдаёт хорошие тексты. Даже — грамотные. Но — тексты это стандартные. Стилистически безвкусные. И что — так будет всегда? Этот вопрос меня тревожит с тех самых пор, как я начал пользоваться LLM. Они созданы из слов, и при этом не могут как следует словами пользоваться. Почему мы не способны создать ИИ, который пишет хорошие тексты?

Тут совершенно естественным образом возникает такой вопрос: можем ли мы задать какие-то (или хоть какие-нибудь) количественно измеримые, эмпирические «сигнатуры» хороших текстов? Если это возможно — значит такие вот «характеристики» можно использовать для обучения моделей, которые смогут лучше писать. Так случилось, что этот вопрос завёл меня, так сказать, в кроличью нору, породив проект, который я называю Horace.

Я выдвинул гипотезу, в соответствии с которой, приближённо говоря, волшебство текстов, написанных людьми, уместно сравнивать не с понятием «статистическое среднее», а с понятием «дисперсия». Полагаю, эту мысль нельзя назвать строгим правилом, но она, как мне кажется, ближе к истине, чем альтернативные идеи. Магия человеческих текстов заключается в осознанном, целенаправленном отступлении от ожидаемого. Речь идёт о ритме (rhythm), о темпе (pace), о музыкальности (cadence) текста.

Привет, Хабр! Недавно мы запустили Wunder RNN Challenge — соревнование по машинному обучению, где нужно предсказывать следующее состояние рынка по последовательности предыдущих состояний.

В этом посте мы расскажем, что это за состояние рынка, и в чём вообще прикол.

📅 Решения принимаются до 1 декабря
💰 Призовой фонд $13,600

Большие языковые модели (LLM, Large Language Model), как подсказывает их название, часто отличаются значительными размерами и слишком велики для того, чтобы нормально работать на обычных компьютерах. Масштабы этих моделей могут измеряться миллиардами параметров. Обычно для обеспечений достойной скорости их работы необходимы GPU с серьёзными объёмами видеопамяти (VRAM).

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

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

Оценка сроков выполнения задач — это важное дело. Но, в то же время, подобные оценки доставляют массу неприятных эмоций множеству инженеров и программистов. Оценки сроков являются источником напряжения, которое возникает между командами разработчиков и всеми теми, кто так или иначе с ними взаимодействует. Это — менеджеры, другие отделы компаний, клиенты.

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

Одно из самых важных наблюдений, которые я сделал за годы работы, заключается в том, что во всех программах есть ошибки. С ростом сложности программы растёт и сложность ошибок, которые можно в ней встретить. Часто изъяны программы — сущности вполне простые и понятные. Их легко заметить, проверить и воспроизвести. Иногда процесс исправления заурядной ошибки выставляет идеи программиста о том, как работают те или иные механизмы, в столь новом и неожиданном свете, что в итоге кажется, будто кто-то просто над ним издевается.

Сегодня хочу рассказать об ошибке, которая была исправлена путём редактирования одной строчки кода. Это исправление избавило людей, работающих на огромном количестве устройств, от странных ошибок, которые очень трудно воспроизвести. Речь идёт о ситуациях, в которых Anubis не давал пользователям смотреть сайты, при том что никаких веских причин для этого у него не было. Не переключайтесь. Будет интересно.

В теории вероятностей имеется несколько известных задач, решение которых противоречит здравому смыслу. Одна из таких задач — «Парадокс сестёр». Сейчас я изложу условие задачи, дам вам возможность подумать над ответом, а потом расскажу о том, как её решать.

Я начал пользоваться платформой Linear пару месяцев назад. То, с чем я столкнулся, затянуло меня в кроличью нору деталей local-first-разработки (локально-ориентированной разработки), которые изменили мой взгляд на веб-приложения.

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

После того, как я опубликовал предыдущую статью, в которой рассказал о том, какие приёмы применяю, создавая Shell-скрипты, отличающиеся отличным UX, сообщество Hacker News поделилось со мной ценными откликами и предложениями. Я оформил то, что мне удалось узнать, в виде новой статьи, разобрав здесь ещё шесть приёмов, которые позволят всем желающим улучшить свои скрипты.