Перед вами вторая часть из серии материалов, состоящей из двух публикаций. Здесь я предлагаю практическое руководство по архитектуре ML-проекта, освоение которого позволит вам оценить качество автоматического реферирования (суммаризации) текстов в той области, в которой вы работаете.

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

Сегодняшняя публикация состоит из трёх частей, представленных, с применением сквозной нумерации, 2, 3 и 4 разделами. Здесь мы, соответственно, поговорим о реферировании без подготовки (с использованием предварительно обученной модели), об обучении предварительно обученной модели на нашем наборе данных, об оценке эффективности обученной модели.

В июле 2020 года компания OpenAI выпустила свою модель машинного обучения третьего поколения, GPT-3, ориентированную на генерирование текстов. Тогда я понял, что мир уже не будет прежним. Эта модель задела меня за живое. Те системы такого рода, что выходили раньше, у меня подобных ощущений не вызывали. И вот ещё неожиданность — о новой системе начали говорить мои друзья и коллеги, в принципе интересующиеся технологиями, но не особенно обращающие внимание на последние достижения машинного обучения (Machine Learning, ML) и искусственного интеллекта (Artificial Intelligence, AI). Об этом написала даже газета Guardian. А если точнее — статью написала сама модель, а в Guardian её лишь отредактировали и опубликовали. Совершенно очевидно то, что выход модели GPT-3 стал поворотным моментом в развитии искусственного интеллекта.

Сразу же после выхода модели начали появляться идеи по поводу вариантов её применения. В течение нескольких недель было создано множество впечатляющих демонстрационных проектов, которые можно найти на сайте GPT-3. Моё внимание привлёк один из способов применения GPT-3 — автоматическое реферирование текстов (text summarization): компьютер читает переданный ему текст и выдаёт краткое изложение этого текста. Это — одна из самых сложных задач, с которыми приходится сталкиваться компьютерам. Дело в том, что она совмещает в себе два навыка из сферы обработки естественных языков (Natural Language Processing, NLP). Это — понимание читаемых текстов и возможность писать тексты самостоятельно. Именно поэтому меня так впечатлили примеры использования GPT-3, демонстрирующие возможности системы по генерированию текстов.

Прим. Wunder Fund: В статье описан относительно новый подход к ускорению обучения больших моделей. Сами мы его не применяем, но над скоростью обучения моделей работаем постоянно, и если вам интересна эта тема, будем рады с вами пообщаться)

Обучение крупномасштабных ИИ-моделей — это не так уж и просто. Помимо того, что для этого нужны серьёзные вычислительные мощности и ресурсы, задачи обучения очень больших моделей сопряжены с немалыми технологическими сложностями. Мы, в команде Facebook AI Research (FAIR), работаем над созданием инструментов и инфраструктурных решений, нацеленных на упрощение обучения больших моделей. Среди наших недавних проектов в этой области можно отметить модели с внутрислойным параллелизмом, модели с конвейерным параллелизмом, модели с шардингом состояния оптимизатора и данных, относящихся к вычислению градиента, архитектуру «смесь экспертов». Всё это — лишь часть нашей работы, направленной на то, чтобы сделать более эффективным обучение продвинутых ИИ-моделей для любого количества задач.

В Uber все рабочие нагрузки, хранящие состояние, запускают на единой контейнеризованной платформе. Аппаратной основой этой платформы является обширный парк серверов. Среди таких рабочих нагрузок можно отметить MySQL, Apache Cassandra, ElasticSearch, Apache Kafka, Apache HDFS, Redis, Docstore, Schemaless. Во многих случаях они совместно работают на одних и тех же физических хостах.

Речь идёт о 65000 таких хостов, о 2,4 миллионах процессорных ядер и о 200000 контейнеров. Мы постоянно боремся за повышение эффективности использования серверов, делая это ради снижения затрат на их поддержку. Это — важная задача, но до недавнего времени её достойному решению мешал троттлинг процессоров. Это явление указывало на то, что нашим программам выделялось недостаточно ресурсов.

Оказалось, что проблема заключалась в том, как именно ядро Linux распределяет процессорное время между процессами. В этом материале мы расскажем о переходе с квот CPU (квот на ресурсы процессора, CPU quotas) на механизм распределения процессов по процессорам и памяти (cpusets; эта технология ещё известна как CPU pinning — закрепление процессора). Такой переход позволил нам значительно снизить задержки в 99 перцентиле (P99) в обмен на небольшой рост задержек в 50 перцентиле (P50). Это, в свою очередь, позволило нам снизить уровень выделения процессорных ядер во всём нашем серверном парке на 11% благодаря уменьшению различий в требованиях к ресурсам.

Прим. Wunder Fund: В этой статье разбираемся, что такое декораторы в Python, зачем они нужны, и в чем их прикол. Статья будет полезна начинающим разработчикам.

Материал рассчитан на начинающих программистов, которые хотят разобраться с тем, что такое декораторы, и с тем, как применять их в своих проектах.

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

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

Все мы тратим немало времени на отладку, копаясь в логах или читая трейсбеки (traceback, отчёты о трассировке стека). Любое из этих дел может оказаться сложным и длительным. Этот материал посвящён тому, как сделать трассировку стека и работу с исключениями как можно более простыми и эффективными.

На пути к этой цели мы узнаем о том, как реализовывать и использовать собственные перехватчики исключений (exception hook), которые позволяют убрать из трейсбеков весь «информационный шум». Мы поговорим о том, как улучшить читабельность отчётов о трассировке стека, как выводить в них лишь то, что нужно для решения проблем с Python-кодом и с возникающими в процессе его работы исключениями. Кроме того, мы посмотрим на несколько потрясающих Python-библиотек, в которых имеются готовые к использованию, хорошо сделанные перехватчики исключений. Их можно использовать без необходимости написания собственного кода перехватчиков.

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

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

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

Прим. Wunder Fund: В сегодняшней статье рассказываем, как Уберу удается точно предсказывать время прибытия такси или курьера. Мы нашли её очень увлекательной, как и несколько других статьей из технического блога Убера.

Волшебный клиентский опыт пользователей Uber зависит от точного прогнозирования ожидаемого времени прибытия (Estimated Time of Arrival, ETA) автомобиля. Мы используем ETA для расчёта тарифов, для оценки времени подачи автомобилей, для стыковки пассажиров и водителей, для планирования доставок и для многого другого. Традиционные системы маршрутизации вычисляют ETA путём разделения дорожной сети на маленькие сегменты, представленные взвешенными рёбрами графа. Эти системы используют алгоритмы поиска кратчайшего пути для нахождения наилучшего пути на графе и складывают веса для получения ETA. Но, как всем известно, карта — это не то же самое, что поверхность Земли: граф дорог — это всего лишь модель, она не способна идеально соответствовать реальности. Более того — мы можем не знать о том, какой именно маршрут к пункту назначения выберет конкретный пассажир или водитель. Обучая ML-модели (Machine Learning, машинное обучение) на базе прогнозов, построенных с применением графов дорог, применяя исторические данные в комбинации с данными, получаемыми в режиме реального времени, мы можем уточнить расчёт ETA, приблизить расчётные показатели к реальным.

Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.

В первой части этой серии статей я рассказал о том, как организовать фаззинг Apache HTTP Server с привлечением кастомных мутаторов. Во втором материале я раскрыл вопрос создания перехватчиков ASAN, которые позволяют выявлять ошибки при использовании собственных реализаций пулов памяти.

Эта статья, третья и последняя, посвящена результатам моих исследований. Я расскажу тут об обнаруженных мной уязвимостях Apache.

Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.

В первой статье из этой серии я рассказал о том, с чего стоит начать тому, кто хочет заняться фаззингом Apache HTTP Server. Там мы обсудили разработку кастомных мутаторов в AFL++, поговорили о том, как создать собственный вариант грамматики HTTP.

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

Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.

Этот материал открывает серию из трёх статей (она продолжает материалы о фаззинге FTP-серверов и FreeRDP), посвящённых фаззинг-тестированию реализации протокола HTTP, представленной в Apache HTTP Server. Это — один из самых популярных веб-серверов и в представлении он не нуждается. Так, Apache HTTP — это один из первых HTTP-серверов, разработка которого началась в 1995 году. По состоянию на январь 2021 года под его управлением работали более чем 300000000 серверов, а значит — он использовался на 26% таких систем и занимал второе место по распространённости, немного уступая лишь Nginx (31%).

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

GTD (Getting Things Done, Доведение дел до завершения) — это методика организации и отслеживания задач и проектов. Но эта методика, правда, ориентирована на нечто большее, чем только на «доведение дел до завершения». (Ей стоило бы называться «Доведение дел до завершения гораздо лучшим способом, чем просто позволяя чему-то идти своим чередом, что часто получается не так, чтобы очень уж хорошо»). Цель GTD — сделать так, чтобы человек полностью доверял бы системе сбора задач, идей и проектов. Это относится и к туманным задачам, вроде «сделать самое великое изобретение», и к конкретным делам, вроде «позвонить Аде 25 августа чтобы обсудить программу конференции». Речь идёт абсолютно обо всём!

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

Но числа в Python — это гораздо больше, чем, собственно, их числовые значения. Поговорим о трёх особенностях чисел в Python, с которыми вы, возможно, не знакомы.

Современный человек много чем занимается в интернете: ходит по магазинам, слушает музыку, читает новости. Все эти задачи подразумевают поиск и выбор того, что ему нужно. При этом важную роль тут играют рекомендательные системы. Они помогают людям не утонуть в многообразии вариантов и увидеть именно то, что им подойдёт, то, что иначе им сложно было бы найти. Предоставление пользователям качественных рекомендаций — это важнейшая часть обеспечения первоклассного уровня удовлетворения клиента. Это — один из самых эффективных способов взращивания лояльности клиентов и повышения ценности продукта или услуги в их глазах. Всё это так важно, что целые бизнес-модели некоторых компаний построены вокруг предоставления их клиентам наилучших рекомендаций, что делает рекомендательные системы важнейшими факторами, влияющими на прибыль подобных компаний! В результате неудивительно то, что клиенты проекта Microsoft CSE часто обращаются к нам с просьбами, касающимися реализации эталонных рекомендательных техник. Один из таких проектов был моим первым опытом в данной сфере.

Прим. Wunder Fund: не спешите минусовать эту публикацию — её перевода на Хабре ещё не было :)

Это — продолжение моей предыдущей публикации (вот — первая, вторая и третья части перевода), посвящённой тому, как я создал алгоритм сортировки, который быстрее std::sort. Эта статья — мой шанс углубиться в те детали, о которых меня спрашивали в комментариях. Я собираюсь разъяснить здесь некоторые вещи, которые оказались непонятными аудитории, и поговорить о будущем моего алгоритма, о доработках, в которых он нуждается.

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

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

Прим. Wunder Fund: ну, вы наверное, и сами догадываетесь, как мы любим быстрые алгоритмы и оптимизации. Если вы тоже такое любите — вы знаете, что делать)

Прим. Wunder Fund: ну, вы наверное, и сами догадываетесь, как мы любим быстрые алгоритмы и оптимизации. Если вы тоже такое любите — вы знаете, что делать)

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

Прим. Wunder Fund: ну, вы наверное, и сами догадываетесь, как мы любим быстрые алгоритмы и оптимизации. Если вы тоже такое любите — вы знаете, что делать)

В наши дни сказать, что изобрёл алгоритм сортировки, который на 30% быстрее того, что считают эталонным, это значит — сделать довольно смелое заявление. Я, к сожалению, вынужден сделать ещё более смелое заявление. Дело в том, что я создал алгоритм сортировки, который, для многих вариантов входных данных, вдвое быстрее std::sort. И, за исключением сортировки специально созданных входных последовательностей, на которых алгоритм упирается в свой худший случай, он всегда быстрее std::sort. (А когда появляются данные, приводящие к худшему случаю алгоритма, я эту ситуацию детектирую и автоматически перехожу на std::sort).

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

Учитывая то, о чём я писал в моём прошлом материале, это, конечно, вариант поразрядной сортировки (radix sort). То есть — его временная сложность ниже, чем O(n log n). Вот два основных направления, по которым я усовершенствовал базовый алгоритм:

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