Рудник нолей и единиц

Большой адронный коллайдер (БАК) — самый сложный, большой и дорогой прибор в истории экспериментальной физики. Но с концептуальной точки зрения его функция довольно проста: взять протоны, разогнать их в вакуумной трубе до максимальной скорости и столкнуть друг с другом. Самое интересное начинается потом — когда столкновение порождает возникновение и распад частиц, мимолетную жизнь которых надо увидеть и зарегистрировать в детекторах. Объем генерируемой при этом информации настолько велик, что БАК вполне уместно сравнить с огромным «рудником данных», из которого физики, — словно горнодобытчики алмазы, — пытаются вылавливать интересные события.

Если иметь ввиду эту метафору, то участие в работе ЦЕРН такой компании, как Яндекс, будет выглядеть не таким уж и неожиданным. В конце концов, и инженеры поисковика и физики ЦЕРНа занимаются, в общем, одним и тем же — обработкой и осмыслением огромных потоков данных. Возможно, именно поэтому новую технологию машинного обучения CatBoost Яндекс впервые обкатывал именно на данных БАКа. Мы решили разобраться, чем именно Яндекс занимается в ЦЕРНе, как это помогает физикам и смогут ли новые технологии машинного обучения помочь совершать фундаментальные открытия.

Для начала нужно в двух словах напомнить, как устроена добыча информации в «рудниках» ЦЕРНа. Протоны в БАКе летят в вакууме, в окруженной магнитами кольцевой трубе длиной в 27 километров и внутренним диаметром около 5 сантиметров. Если говорить точнее, речь идет о двух очень близко расположенных трубах, по которым протоны летят в противоположных направлениях.

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

В составе БАКа есть также группа предварительных ускорителей, система сброса пучка, 1232 поворотных магнита, каждый длиной в 15 метров, и многое другое, о чем мы сейчас вспоминать не будем (для подробного ознакомления с устройством БАК нельзя не порекомендовать спецпроект Игоря Иванова на сайте «Элементы»).

Генерация данных в БАКе происходит в детекторах. Есть универсальные установки, предназначенные для изучения любых возможных событий, — это массивные ATLAS и CMS. Есть более специализированные: ALICE, «заточенный» на изучение столкновения тяжелых ядер (а не протонов) и LHCb, предназначенный для исследования «прелестных» адронов и видящий лишь те частицы, которые вылетают под небольшим углом к оси столкновения. Есть небольшие эксперименты LHCf, TOTEM, CASTOR, LUCID… но это уже детали.

Каждый из этих детекторов, безусловно, имеет огромное количество особенностей, но важно понимать, что по общей структуре они схожи. Устроены они как матрешки: внутренняя, ближайшая к столкновению часть отвечает на вопрос, откуда пришла частица и какова ее траектория. Работают эти детекторы примерно так же, как цифровой фотоаппарат: они состоят из большого числа элементарных пикселей, которые «загораются», когда в результате прохождения частицы в них возникает ионизация (под пикселями можно иметь ввиду «настоящие» кремниевые пиксели, а можно диффузионные камеры — и те и другие делают одно дело). Получив информацию с этих трековых детекторов, можно установить, откуда и как полетели «осколки столкновения».

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

Детекторы внутри установки работают одновременно. Вся получаемая ими информация так или иначе используется для того, чтобы установить природу конкретного события — причем дело это не простое, оно требует анализа. На первой картинке ниже, например, показано одно из событий столкновения двух протонов, зарегистрированное детектором LHCb. На второй (для просмотра кликните на стрелку под окном с картинками) — одно из событий на детекторе ATLAS. Каждая линия — это трек, восстановленный по данным миллионов пикселей, каждое пятно — данные с калориметров и других детекторов.

Для того чтобы оценить объем добываемой в ЦЕРНе «информационной руды», приведем несколько фактов. Один лишь пиксельный (внутренний) детектор установки ATLAS состоит из 80 миллионов отдельных пикселей. Столкновения сгустков протонов внутри детектора происходят 40 миллионов раз в секунду. При этом для наблюдения хотя бы одного события, в котором рождается бозон Хиггса (с распадом на два Z-бозона, каждый из которых распадается на электрон-позитронную пару), нужно в среднем около трех часов работы при максимальной светимости коллайдера. Перемножив эти цифры, можно примерно представить объем информации, которую требуется перебрать для получения интересных данных. Поскольку обнаружение нужного события — это задача не тривиальная (требуется сопоставление информации с разных частей установки, это не датчик да/нет), становится понятно, насколько сложная задача стоит перед системой обработки информации.

О том, как устроена эта система, что улучшают в ней специалисты Яндекса, и о роли новой технологии машинного обучения CatBoost мы поговорили с руководителем группы совместных проектов Яндекса и ЦЕРН, заведующим лабораторией LAMBDA ВШЭ Андреем Устюжаниным, физиками Денисом Деркачем и Федором Ратниковым.

N + 1: Яндекс присоединился к работе ЦЕРНа в 2012 году. Чем вы исходно собирались заниматься? Насколько я понимаю, идея была в том, чтобы создать что-то вроде интернет-поисковика, только на данных БАКа?

Андрей Устюжанин: Грубо говоря, да. Мы хотели создать индекс всех событий, которые регистрирует детектор, чтобы впоследствии можно было найти любое из них. Однако довольно быстро стало ясно, что эта задача несколько бессмысленная, так как отдельные события физиков почти не интересуют. Кроме того, реальные критерии поиска оказались гораздо более сложными, чем предполагает индексирование. Возможно, был бы полезен поиск, аналогичный поиску по картинке: вот событие, где рождаются два мюона, найди мне все похожие случаи. Но это пока задача на будущее.

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

Что касается последнего, это задача более или менее стандартная для любого проекта в области больших данных. Интереснее поговорить о том, что касается непосредственно физики. Объясните, как вообще на БАКе происходит сбор данных и что с ними дальше происходит?

Федор Ратников: Протоны в БАК, как вы знаете, летят не сплошным потоком, а сгустками. Пары таких сгустков контактируют друг с другом примерно 40 миллионов раз в секунду, причем в среднем это приводит к столкновению одной пары протонов. Значит каждые 25 наносекунд в детекторе происходит одно событие. Цифровой «снимок» этого события, полученный от всех компонентов детектора, занимает примерно около мегабайта — я в данном случае говорю про LHCb, с которым мы работаем плотнее всего. Дальше эта информация проходит систему фильтрации, которая основана на нескольких уровнях триггеров.

Что вообще это такое и зачем нужно? Исходно вся полученная за событие информация запоминается в некоем временном электронном хранилище, буфере, а затем посылается на триггер, задача которого — определить, нужно ли эту информацию хранить дальше или она заведомо неинтересна. Это решение нужно принять очень быстро, пока информация еще лежит в буфере, — а в него уже поступают данные от все новых и новых событий (40 миллионов раз в секунду). Определяющим фактором тут является объем буфера, и сейчас он составляет от силы сто-тысяча событий. Это означает, что на принятие решения триггеру отводится от силы несколько микросекунд. За такое время можно принять только очень простое решение. Например, оставить только каждое десятое подходящее событие. Эти отобранные данные складываются в новый буфер, который тоже имеет ограниченную длину. Однако даже если второй буфер по размеру точно равен первому, время на принятие решения на этом этапе в десять раз увеличивается. А значит, и анализ, который проводит триггер, может быть более сложным. С каждым уровнем логарифмически спадают потоки данных, экспоненциально растет время принятия решения.

Всего в детекторе три уровня триггеров, это L0, HLT1, и HLT2. Нулевой, самый быстрый уровень, реализован хардверно. Там стоят простые микросхемы (FPGA-карты), которые проверяют самое простое — количество выделившейся в событии энергии. Условно говоря, это «яркость» полученного снимка. Если продукты столкновения улетели в каком-то неизвестном направлении и их увидели только отдельные детекторы, то скорее всего из этих данных все равно ничего выудить не получится и их лучше просто выкинуть.

Триггеры следующих уровней (HLT1 и HLT2) реализованы уже софтверно, то есть это программы, которые работают на универсальных процессорах. На этом этапе вычисления проводятся на специальной вычислительной ферме из пары тысяч компьютеров, которые стоят на территории ЦЕРН, рядом с детектором. Всего триггеры уменьшают поток данных примерно на три порядка. Прошедшие эти фильтры данные поступают в систему хранения, которая называется LHCb-grid. Она состоит из нескольких уровней: есть датацентры, которые хранят и обрабатывают данные, есть такие, которые только обрабатывают.

Расположены датацентры в разных уголках планеты. Центральный узел расположен непосредственно в ЦЕРНе, есть еще семь узлов по Европе. Узлы первого уровня принципиально отличаются тем, что в них есть ленточные носители, которые хранят все данные. А вот узлы второго уровня обходятся только дисками. Всего на данный момент эксперимент LHCb собрал порядка 10 петабайт данных, на всем БАКе это где-то 200 петабайт.

Общая картина понятна. Но что же с этими триггерами делала команда Яндекса?

Андрей Устюжанин: Как уже говорил Федор, триггеры самого первого уровня определяют просто число «загоревшихся пикселей». Следующий уровень, HLT1, восстанавливает траекторию частиц (если сильно упростить). Третий уровень, HLT2, уже восстанавливает топологию распада: соединяет треки обнаруженных частиц в какое-то дерево и пытается разобраться — это дерево распада принадлежит интересному семейству событий или про такие распады уже все известно и это неинтересно. И в зависимости от того, как хорошо вы можете отделять интересные события от неинтересных, зависит эффективность всего эксперимента. Так вот, используя возможности машинного обучения, нам удалось повысить эффективность системы триггеров на 40-50 процентов.

Помимо триггеров, вы среди совместных проектов упоминали некий стриппинг. Что это такое?

Андрей Устюжанин: Стриппинг, или реконструкция, — это то, что происходит с данными после того, как они собраны и прошли систему триггеров. Представьте, что вы физик и изучаете двухмюонные события. Или, скажем, электроны высокой энергии. И те и другие события происходят редко, чтобы найти их в собранных данных, понадобится прокручивать огромное количество информации. Однако можно заранее проанализировать входящие данные и найти там группы событий, которые включают мюонные или электронные события. Понятно, что некоторые из них могут попасть и в одну, и в другую кучку. В определенном смысле такая обработка данных аналогична индексации интернета по словам, — того, с чего мы начинали взаимодействие с ЦЕРН.

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

Но чтобы классифицировать данные, нужно для начала определить тип возникающих в событиях частиц. Насколько я понимаю, именно на этой задаче вы обкатывали технологию машинного обучения CatBoost, которая вообще-то создавалась вовсе даже не для ЦЕРН?

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

Андрей Устюжанин: Когда в прошлом году за эту задачу взялись мы, нужно было не только повысить качество работы этой нейросети, но и улучшить ее равномерность. Равномерность это такое свойство системы обработки информации, которое позволяет видеть частицы, — допустим, электроны с низкой и с высокой энергией – с одинаковой эффективностью. Это очень важно для последующего анализа. Как правило, стандартные алгоритмы классификации такие параметры вообще не учитывают и не умеют с ними работать. А мы создали такой классификатор, который не просто правильно узнает тип частицы, но и делает это одинаково хорошо для частиц с энергией в широком диапазоне.

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

А о каких цифрах вообще идет речь? Насколько хорошим оказался ваш лучший алгоритм?

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

Честно говоря, не очень понятно, как вообще можно обучить компьютер разбираться в частицах. Это ведь не фото котов и собак, на которых обычно объясняют принципы машинного обучения. Как это делается? Знает ли ваш классификатор о тонкостях Стандартной модели? Как он интерпретирует сигнал от детекторов? Откуда берется обучающая выборка? Как вообще это все устроено?

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

Да, но помимо теории есть еще особенности реального детектора: что-то всегда работает не так, как надо. Что-то где-то недокрутили, что-то перекрутили...

Денис Деркач: Все эти особенности тоже учитываются при создании симуляции. Причем обучающая выборка создается не нами, это работа отдельной группы внутри коллаборации LHCb. И эту выборку могут использовать все, кто хочет создавать классификаторы. Такое разделение гарантирует то, что мы не «мухлюем» с исходными данными, делаем все честно и максимально приближенно к условиям эксперимента.

И как выглядит эта выборка?

Денис Деркач: Это шесть миллионов событий, которые используются для обучения, и еще есть такого же размера тестовая выборка. На ней можно проверить наш алгоритм и доказать, насколько он хорош или плох. По каждому из событий у нас имеется 56 разных параметров, которые мы используем при классификации, плюс мы их еще некоторым образом комбинируем вручную, прежде чем отправить в классификатор CatBoost.

Андрей Устюжанин: Как я уже говорил, нам очень важно добиться равномерности в классификации частиц. Но точность и равномерность плохо сочетаются друг с другом: увеличивая одно, можно сильно уменьшить другое. Поэтому, чтобы получить гладкий и при этом точный классификатор, требуется некоторое «шаманство», это не так просто.

Увеличить эффективность классификатора в полтора раза — вообще вещь нетривиальная. Обычно бой идет за проценты и даже доли процентов (я вспоминаю, например, результаты CatBoost с вашей презентации). Что теперь будет с вашим алгоритмом, когда он будет внедрен в работу БАК и на каком этапе?

Денис Деркач: После того как мы показали его эффективность на симуляции, мы начали работать с реальными данными с детектора. Полученные результаты потом должны изучить аналитики, и после того, как БАК уйдет на каникулы (а это будет в конце этого года), классификатор будет включен в систему. Получать информацию он будет от триггеров второго уровня, HLT1 (тех, что определяют треки частиц), и будет поставлять данные для последнего уровня, HLT2. То есть работа этого классификатора будет использоваться для того, чтобы решать, какие данные оставлять, какие выкидывать.

Я правильно понимаю, таким образом вы фактически программно увеличили светимость коллайдера?

Денис Деркач: Не совсем. Светимость — это нечто другое, это величина, пропорциональная количеству столкновений. Иногда увеличение светимости даже нежелательно. В отличие от ATLAS и CMS, на LHCb невыгодно иметь как можно большую светимость: на каждое событие нужно одно-полтора столкновения протонов, не больше — иначе интерпретация полученных данных будет слишком сложной. Причем ресурсы, необходимые для анализа, растут экспоненциально росту светимости. А вот чем больше частота событий, чем больше происходит столкновений сгустков протонов в единицу времени, тем действительно лучше.

Федор Ратников: На частоту столкновений мы повлиять не можем (понадобилось бы вносить изменения во все узлы БАКа), но мы можем сделать так, чтобы большее число произошедших интересных событий не было выкинуто, а попало в руки исследователей. Именно для этого и нужен наш алгоритм. Увеличение эффективности триггеров означает увеличение в полтора раза количества реальных данных. Тот же объем информации можно собрать за существенно меньшее время, сэкономить при этом большое количество энергии и денег.

Беседовал Александр Ершов