Русский
Русский
English
Статистика
Реклама

Блог компании skillfactory

Перевод Биография основателя DEF CON и Black Hat Джеффа Мосса (Dark Tangent)

10.06.2021 14:04:32 | Автор: admin

К старту курса об этичном хакерстве мы перевели размещённую на сайте Black Hat биографию основателя этой серии мероприятий по кибербезопасности. Джефф Мосс родился в Калифорнии, США, в январе 1975 года, он эксперт по компьютерной и интернет-безопасности, хакер. Первый опыт работы с компьютером он получил в возрасте 10 лет и был восхищён возможностью общаться и вести взрослые разговоры с людьми по всему миру. У него ещё не было водительских прав, Джефф не мог голосовать, но мог общаться с людьми намного старше его, которых нисколько не волновали ни его возраст, ни внешность.


Джефф МоссДжефф Мосс

Начало хакерского пути

Его первый хакерский опыт был вызван исключительно желанием задействовать все возможности оборудования, за которое он заплатил; те же мотивы побудили хакера Джорджа Хотца (geohot) взломать Sony PlayStation, а затем сделать джейлбрейк iPhone. В начале 1990-х Джефф пытался понять, как фирмы защищают от копирования компьютерные игры. Ему это удалось, и он стал играть в скопированные игры со своими друзьями.

В те времена учебников по программированию почти не было, и он приступил к самостоятельному изучению ассемблера. Он узнал (пришлось узнать!), как с небольшими затратами разогнать процессор, чтобы тот работал намного быстрее, чем при стандартной конфигурации.

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

Когда у него появился первый модем и он понял, какие бесконечные возможности общения предоставляют доски объявлений (bulletin boards) никому не надо раскрывать свою личность, возраст или пол, его восхищению не было предела. Желание общаться с людьми в сети Интернет заставило его прибегнуть к телефонному жульничеству. Джефф взломал телефонную систему и мог практически бесплатно общаться с людьми на больших расстояниях.

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

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

В 1990 году Джефф окончил Университет Гонзага со степенью бакалавра в области уголовного права. (Признайтесь, вы не ожидали, что парень, стоявший у истоков конференций DEF CON и Black Hat, имеет степень бакалавра в области уголовного права!) После университета его взяли на работу в одну из крупнейших мировых компаний по предоставлению профессиональных услуг, Ernst & Young, на должность директора подразделения Secure Computing Corporation.

DEF CON: от прощальной вечеринки до одной из крупнейших в мире хакерских конференций

В 1990-е годы весь мир пользовался досками объявлений. Такие доски часто использовались хакерами для обмена информацией. Джефф держал собственную доску объявлений и мог позволить себе оплачивать телефонную связь из своей зарплаты, но его приятели, как правило, находили способы не платить за телефонную связь. В тот же период он стал своего рода главным администратором множества международных сетей, таких как HackNet, PhreakNet, PlatinumNet и HitNet.

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

Большинство пользователей этих сетей были американцами, поэтому он попросил Джеффа помочь с организацией вечеринки и провести её в США. Джефф начал готовить вечеринку и уже нашёл место в Лас-Вегасе для её проведения, но получилось так, что отец друга уехал раньше задуманного и забрал сына с собой, и Джефф остался один.

Мосс решил не отменять вечеринку, всё организовал сам, пригласил членов администрируемых им сетей, разослал приглашения в хакерские чаты IRC, разместил объявления на некоторых других досках, разослал всем факсы и даже отправил факсы в секретные службы США, сообщив, что "они идут". Встреча хакеров состоялась в Лас-Вегасе.

Название DEF CON имеет интересную историю. Defcon звали главного героя в фильме WarGames, который решил взорвать Лас-Вегас. Кроме того, термин DEF был в ходу у телефонных мошенников, в том числе у самого Джеффа, так как DEF это символы на кнопке "3" телефонной клавиатуры. И вот тот день настал, на конференции DEF CON должны были выступить 12 докладчиков. Приехали более 100 человек, и первая в истории конференция началась с выступления Дэна Фармера, эксперта по безопасности UNIX, который рассказал о разработанных им новых инструментах, в том числе SATAN одном из первых сканеров сетевой безопасности с веб-интерфейсом.

DEF CON 1 Defcar, 1993DEF CON 1 Defcar, 1993

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

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

Пик посещаемости пришёлся за год до возникновения феномена "пузырь доткомов" в 2000-х годах около семи тысяч человек, но, как сказал Мосс в интервью 2007 года, возможно, половине участников там вообще нечего было делать, но они всё равно приехали. После того как пузырь доткомов лопнул, количество участников конференции сократилось: в 2007 году её посетили около пяти тысяч человек, интересующихся проблемами хакерства.

DEF CON, следуя поговорке "под лежачий камень вода не течёт", продолжала развиваться. В её программу были включены соревнования CTF (захват флага), в которых команды участников соревнуются друг с другом, пытаясь быстрее других найти секретные "флаги" в намеренно уязвимых программах или веб-сайтах и получить за это награды. Black Badge высшая награда, вручаемая участникам DEF CON, победители получают ценные подарки и пожизненный бесплатный пригласительный билет на DEF CON.

Добавление семинаров (специальных собраний, на которых с упором на практику затрагивались различные темы, связанные с информационной безопасностью), таких как цифровая криминалистика, взлом IoT-устройств, и Деревни (Villages) (особые места в рамках конференции, имеющие статус мини-конференций), способствовало росту популярности мероприятия. DEF CON на протяжении многих лет занималась сбором денежных средств на различные программы.

За годы проведения мероприятия хакеры смогли показать миру, с какой лёгкостью можно взломать обычный компьютер, а также продемонстрировали множество инновационных инструментов/программ, совершивших революцию в сфере информационной безопасности. В 2018 году Джефф провёл первую в истории конференцию DEF CON за пределами США в Пекине, и этот формат был продолжен в 2019 году как DEF CON China 1.0.

В 2019 году конференцию DEF CON 27 посетило 30 тысяч человек, причём некоторые откровения докладчиков были ошеломляющими. Хакерам удалось взломать комплексы обработки избирательных бюллетеней в США, за считанные минуты после сканирования обнаружив в них критические уязвимости. Один из хакеров смог продемонстрировать вредоносные возможности кабеля Apple USB Lighting и многие другие критические уязвимости, обнаруженные в VPN и принтерах.

DEF CON 27DEF CON 27

Как начиналась конференция Black Hat

До DEF CON 5, которая была проведена в июле 1997 года также в Лас-Вегасе, Джефф организовал первую в истории конференцию Black Hat, ориентированную на индустрию компьютерной безопасности. Темами других конференций были информационная и сетевая безопасность, на конференции же Black Hat разработчики программного обеспечения встретились лицом к лицу с экспертами в области компьютерной безопасности и хакерами. Вначале конференция Black Hat проводилась как ежегодное мероприятие в Лас-Вегасе, но сегодня она проводится сразу в нескольких местах во всём мире.

В 2005 году Джефф продал права на проведение конференций Black Hat британской компании CMP Media, принадлежащей United Business Media, за 13,9 миллиона долларов США.

Конференция состоит из трех секций: Black Hat Briefings, Black Hat Trainings и Black Hat Arsenal. На секции Briefings обсуждаются различные темы, в том числе вскрытие технологий, компьютерный взлом, конфиденциальность и т. д., а также выступают ведущие специалисты в области информационной безопасности из различных ведомств США Министерства обороны, Министерства внутренней безопасности и АНБ.

На секции Trainings выступают поставщики решений в сфере безопасности и специалисты в области безопасности: семинары продолжительностью около недели организуют такие поставщики ПО, как Cisco, Offensive Security и многие другие. Секция Arsenal был создана в 2010 году. Её цель "живая" демонстрация новейших инструментов информационной безопасности с открытым исходным кодом, созданных исследователями и сообществами, в ходе которой участники могут задавать вопросы и пробовать инструменты в действии.

Конференция Black Hat обычно проводится до DEF CON, и многие участники посещают оба мероприятия. В индустрии безопасности Black Hat считается более официальной конференцией по безопасности, а DEF CON носит скорее неформальный характер.

Black Hat USA 2016Black Hat USA 2016

Другие события в карьере Джеффа

На протяжении всей своей карьеры Джефф использовал свои навыки и понимание принципов и методов хакерского сообщества и передавал эти знания организациям, чтобы те могли защитить свои глобальные сети. С 2005 по 2014 год он также выступал на множестве мероприятий, проводимых во всём мире, в качестве основного докладчика, был участником десятков форумов. Некоторые такие мероприятия организовывались CodeGate, Министерством внутренней безопасности США, АНБ, НАТО и многими другими международными организациями и учреждениями.

В 2009 году Джефф вошёл в группу из 16 человек, выбранных в состав Консультативного совета по национальной безопасности. Члены Консультативного совета могли давать рекомендации и советы непосредственно министру внутренней безопасности.

Через два года, в 2011 году, Джефф был назначен вице-президентом и директором по безопасности Корпорации по управлению доменными именами и IP-адресами (ICANN), многонациональной некоммерческой организации, работающей над созданием безопасной, стабильной и единой глобальной сети Интернет. Многие официальные лица, в том числе президент ICAAN, отмечают профессионализм и мастерство Джеффа и ценят его за прекрасное понимание угроз безопасности и способов защиты от них.

В конце 2013 года он ушёл со своего поста в ICAAN. Следующий его важный карьерный шаг состоялся в 2017 году, когда он был назначен Комиссаром Глобальной комиссии по стабильности киберпространства (GCSC), состоящей из 24 авторитетных независимых комиссаров со всего мира. Цель работы Комиссии способствовать повышению уровня осведомлённости и взаимопонимания между различными сообществами киберпространства и изучать вопросы, связанные с глобальной кибербезопасностью.

В 2017 году на конференции DEF CON 25 он представил участникам Деревню машин для голосования DEF CON (Voting Machine Village). На этом семинаре хакеры могли протестировать безопасность электронных машин для голосования, в том числе нескольких моделей, по-прежнему активно используемых в США. Участникам DEF CON удалось взломать все машины (в общей сложности 25 моделей), некоторые всего через несколько часов после открытия Деревни. Это событие получило освещение в СМИ и вызвало общенациональную дискуссию о безопасности голосования.

В 2018 году проект Voting Machine Village был отмечен премией Cybersecurity Excellence как проект года в области кибербезопасности.

Чем Джефф занимается сейчас

Сейчас Джефф живёт в Сиэтле, штат Вашингтон, и занимает должность консультанта по безопасности в одной из компаний. Он тестирует системы безопасности и консультирует другие компании, одновременно проводя конференции DEF CON в качестве президента DEF CON Communications, Inc. Он также был техническим консультантом телесериала "Мистер Робот" и до сих пор вкладывает средства в многие стартапы в сфере информационной безопасности.

Заключительные мысли

В мире информационной безопасности такие трудолюбивые и хорошо образованные люди, как Джефф Мосс, большая редкость. Он оказал большое влияние на хакерское сообщество, что привело к большей открытости этого сообщества и возможности его диалога с поставщиками и производителями программного обеспечения. Благодаря конференциям DEF CON и Black Hat развиваются контакты между хакерами и поставщиками ПО. На этих мероприятиях организации получают знания о том, как обезопасить свои инфраструктуры, совместно с независимыми специалистами в области обеспечения безопасности работают над выявлением и устранением угроз безопасности.

Начиная с 2009 года, когда он отправил открытое письмо в Google с предложением перейти на формат HTTPS по умолчанию, и до настоящего времени Джефф является неотъемлемой частью сообщества информационной безопасности.

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

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

Как сказано выше, зародившаяся в США DEF CON проводится уже в Китае, иными словами проблемы информационной безопасности сегодня актуальны для всех людей без исключения, каким бы ни был подход к ИБ в отдельно взятой стране. Это означает, что в ближайшие годы востребованность этичного хакерства будет только расти, причём с ощутимой вероятностью не просто большими, но взрывными темпами. Если вам интересна сфера этичного взлома, то вы можете обратить внимание на наш курс "Этичный хакеp", где студенты на практике получают полное представление о законном взломе, чтобы начать карьеру хакера в белой шляпе.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Как мы потерпели неудачу, а затем преуспели в переходе на TypeScript

02.06.2021 18:06:54 | Автор: admin

К старту курса о Fullstack-разработке на Python, где также рассматривается TypeScript, мы перевели статью о миграции в Heap.io компании, которая предоставляет платформу аналитики продуктов, c языка CoffeeScript на TypeScript; TS в Heap.io начали использовать более 4 лет назад. Несмотря на широкое предпочтение TypeScript среди инженеров, миграция была медленной, а чёткого пути к 100 % кода TS не было.


На самом деле, если цель состояла в том, чтобы полностью переключиться на TS, мы двигались в неправильном направлении. Да, код на TS добавлялся, но количество кода на CoffeeScript росло быстрее. TypeScript и CoffeeScript нацелены на один и тот же рантайм Node.js, который, как ожидалось, должен был облегчить переход, но, несмотря на желание большого числа разработчиков перейти на TypeScript, мы не набрали большого импульса и не направлялись к будущему без CoffeeScript.

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

Количество строк кода в разработкеКоличество строк кода в разработке

Миграция стека в равной степени касается и технологий, и людей

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

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

Новый опыт разработки должен предлагать очевидное улучшение

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

Мы начали с определения областей кодовой базы, которые в случае преобразования приведут к существенному повышению производительности, зная, что стратегическое преобразование файлов будет привлекательнее произвольного преобразования. Например, наш слой доступа к данным (ORM) покрывает всё, и большинство файлов каким-то образом работают с ORM. Введение типов на уровне доступа к данным было множителем всей работы; почти каждый преобразованный в будущем файл выиграет от хорошо типизированных моделей баз данных и утилит.

Кроме того, мы сделали приоритетом оснастку и конфигурацию. Большинство разработчиков использовали один из нескольких редакторов, поэтому мы создали конфигурации редактора, которые будут работать сразу. Мы также добавили конфигурации отладки, облегчающие установку точек останова и пошаговое выполнение кода.

Наконец, мы сошлись на наборе согласованных правил линтинга, которые позволили нам писать код в едином стиле по всей организации и сделать переход более удобным.

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

Технические барьеры нужно ломать

Когда мы начали анализировать шаблоны внедрения TypeScript, стало ясно, что использование TypeScript для наших инженеров не было простым, им часто приходилось импортировать специальные утилиты (ts-node/register) или создавать промежуточные файлы CoffeeScript, которые не делали ничего, кроме импорта их эквивалентов TypeScript. Короче говоря, история взаимодействия языков существовала, но требовала много бойлерплейта и слишком много проб и ошибок.

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

Чтобы добиться этого, мы отдавали приоритет усилиям, которые позволили бы разработчикам писать на TS в любом компоненте или сервисе. Будь то бэкенд, фронтенд, скрипты или задачи devops, мы хотели, чтобы наши инженеры могли писать код в TypeScript и чтобы он просто работал. В итоге мы прописали переменную среды NODE_OPTIONSс -r ts-node/register, чтобы существующие (использующие команду coffee для запуска файлов CoffeeScript) рабочие процессы также продолжали работать.

Преобразование должно быть простым, безопасным и автоматизированным

Миграция на другой язык может быть рискованной: то, что может показаться эквивалентным синтаксисом между CoffeeScript и ES6/TypeScript, на самом деле может вообще не быть эквивалентным. И разработчики могут рассматривать преобразование как хорошую возможность для рефакторинга, а это ещё хуже; переписывание делает рискованную миграцию ещё более рискованной.

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

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

Для первоначального преобразования мы использовали скрипт, преобразующий файл .coffee в файл .ts. В целях перехода от CoffeeScript к JavaScript ES6 Под капотом работал decaffeinate. Поскольку весь JavaScript ES6 является синтаксически правильным TypeScript, на выходе получался рабочий файл. (Мы обнаружили, что decaffeinate очень зрелый и надёжный инструмент.) В истории Git шаг преобразования представлен одним отдельным коммитом.

Однако работа ещё не была закончена. Мы используем TypeScript в строгом режиме, поэтому была отключена такая функция, как "implicit any". Мы использовали это окно преобразования как возможность создавать аннотации типов для элементов, где вывод типов был невозможен. Также мы избегали использования any в этой фазе, вместо этого выбрав более строгий неизвестный. Цель на этом этапе состояла в том, чтобы внести изменения, которые не приведут к изменению поведения во время выполнения. Мы не занимались никаким рефакторингом, а просто выполняли минимальный объём работы, чтобы привести код в состояние, в котором он компилировался, линтовался и проходил тесты.

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

Этот второй шаг также прошёл отдельным коммитом; такой подход сильно упростил ревью: ревьюер мог легко увидеть, какие изменения были внесены после шага c decafeinate.

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

#typescript: канал дискуссий и вопросов

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

Для этого мы создали канал #typescript в Slack и гарантировали, что застрявшие разработчики могут выйти из положения. Разработчики, управляющие миграцией, стали отвечать на вопросы и остановились на поиске общих проблем и камней преткновения. Если возникала одна и та же проблема, они знали, что нужно сделать лучше.

Разработчики должны знать, что на любые вопросы о языке и инструментах, которые у них есть, будут даны быстрые ответы. Мы решили, что чемпионы TypeScript должны отдать приоритет ответам, а не собственной работе. Хотя такой подход замедлил их работу, он также устранил ряд потенциально серьёзных препятствий в миграции.

Отслеживание прогресса

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

Отслеживание усилий во времени оказалось полезным. Таким образом возможно было понять, продолжается ли прогресс в миграции. Для визуализации количества строк мы воспользовались Grafana. Вот ещё одна визуализация, показывающая количество файлов во времени:

Уважающее инженеров руководство

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

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

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

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

Ситуации могут быть разными, и если вам не хочется ограничивать себя только одним подходом, владеть языками с разными системами типов, то вы можете обратить внимание на наш курс Fullstack-разработчик на Python, где, кроме Python и TS, студенты также изучают чистый JavaScript.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Sparkplug неоптимизирующий компилятор JavaScript в подробностях

09.06.2021 20:16:20 | Автор: admin

Создать компилятор JS с высокой производительностью означает сделать больше, чем разработать сильно оптимизированный компилятор, например TurboFan, особенно это касается коротких сессий, к примеру, загрузки сайта или инструментов командной строки, когда большая часть работы выполняется до того, как оптимизирующий компилятор получит хотя бы шанс на оптимизацию, не говоря уже о том, чтобы располагать временем на оптимизацию. Как решить эту проблему? К старту курса о Frontend-разработке делимся переводом статьи о Sparkplug свече зажигания под капотом Chrome 91.


Вот почему с 2016 года мы ушли от синтетических бенчмарков, таких как Octane, к измерению реальной производительности и почему старательно работали над производительностью JS вне оптимизирующих компиляторов. Для нас это означало работу над парсером, стримингом [этой поясняющей ссылки в оригинале нет], объектной моделью, конкурентностью, кешированием скомпилированного кода...

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

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

Выход из положения Sparkplug: новый неоптимизирующий компилятор JavaScript, который мы выпустили вместе с V8 9.1, он работает между интерпретатором Ignition и компилятором TurboFan.

Новый процесс компиляцииНовый процесс компиляции

Быстрый компилятор

Sparkplug создан компилировать быстро. Очень быстро. Настолько, что мы всегда можем компилировать, когда захотим, повышая уровень кода SparkPlug намного агрессивнее кода TurboFan, [подробнее здесь, этой ссылки в оригинале нет].

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

Второй трюк в отличие от большинства компиляторов Sparkplug не генерирует промежуточное представление (IR). Вместо этого Sparkplug компилирует прямо в машинный код за один линейный проход по байт-коду и выдаёт соответствующий выполнению байт-кода машинный код. На самом деле компилятор это switch внутри цикла for, который занят диспетчеризацией, чтобы за каждой инструкцией закрепить генерирующие машинный код функции.

// The Sparkplug compiler (abridged).for (; !iterator.done(); iterator.Advance()) {  VisitSingleBytecode();}

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

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

Совместимые с интерпретатором фреймы

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

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

Стековый фрейм с указателями стека и фреймаСтековый фрейм с указателями стека и фрейма

Сейчас около половины читателей закричит: "Диаграмма не имеет смысла, стек направлен в другую сторону!" Ничего страшного, я сделал кнопку: думаю, стек направлен вниз.

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

Стековые фреймы для нескольких вызововСтековые фреймы для нескольких вызовов

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

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

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

В случае Ignition соглашение становится более явным. Ignition интерпретатор на основе регистров, это означает, что есть виртуальные регистры (не путайте их с машинными!), которые хранят текущее состояние интерпретатора. включая локальные переменные (объявления var, let, const) и временные значения. Эти регистры содержатся в стековом фрейме интерпретатора, вместе с указателем на выполняемый массив байт-кода и смещением текущего байт-кода в массиве.

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

  1. Это упрощает компиляцию Sparkplug; новый компилятор может просто отражать поведение интерпретатора без необходимости сохранять какое-либо отображение из регистров интерпретатора в состояние Sparkplug.

  2. Поскольку компилятор байт-кода выполнил тяжёлую работу по распределению регистров, такой подход ускоряет компиляцию.

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

  4. Тривиальной становится и замена на стеке (OSR). Замена на стеке это когда выполняемая функция заменяется в процессе выполнения; сейчас это происходит, когда интерпретированная функция находится в горячем цикле (в это время она поднимается до оптимизированного кода этого цикла) и где оптимизированный код деоптимизируется (когда он опускается и продолжает выполнение функции в интерпретаторе), любая работающая в интерпретаторе логика замены на стеке будет работать и для Sparkplug. Даже лучше: мы можем взаимозаменять код интерпретатора и SparkPlug почти без накладных расходов на переход фреймов.

Мы немного изменили стековый фрейм интерпретатора: во время выполнения кода Sparkplug не поддерживается актуальная позиция смещения. Вместо этого мы храним двустороннее отображение из диапазона адресов кода Sparkplug к соответствующему смещению. Для декодирования такое сопоставление относительно просто, поскольку код Sparklpug получается линейным проходом через байт-код. Всякий раз, когда стековый фрейм хочет узнать "смещение байт-кода" для фрейма Sparkplug, мы смотрим на текущую выполняемую инструкцию в отображении и возвращаем связанное смещение байт-кода. Аналогично, когда Sparkplug нужно узнать OSR из интерпретатора, мы смотрим на байт-код в смещении и перемещаемся к соответствующей инструкции Sparkplug.

Вы можете заметить, что теперь у нас есть неиспользуемый слот фрейма, где должно быть смещение байт-кода; избавиться от него мы не можем, поскольку хотим сохранить оставшуюся часть стека неизменной. Мы перепрофилируем этот слот стека, чтобы вместо него кешировать "вектор обратной связи" для текущей выполняющейся функции; это вектор, хранящий данные о форме объекта, и он должен быть загружен для большинства операций. Всё, что нам нужно делать, соблюдать осторожность с OSR, чтобы гарантировать, что мы подставляем либо правильное смещение байт-кода, либо правильный вектор обратной связи для этого слота. В итоге стековый фрейм Sparkplug выглядит так:

Полагаемся на встроенный код

На самом деле Sparkplug генерирует очень мало собственного кода. У JS сложная семантика, так что для выполнения даже самых простых операций требуется много кода. Принудительная повторная генерация такого кода при каждой компиляции оказалась бы плохим решениям по нескольким причинам:

  1. Из-за огромного количества кода, который необходимо сгенерировать, она значительно увеличила бы время компиляции.

  2. Этот подход увеличил бы потребление памяти кодом Sparkplug.

  3. Пришлось бы переписывать кодогенерацию для большого количества функциональности JS, что, вероятно, означало бы и больше ошибок, и большую поверхность атаки.

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

Вы можете подумать: "Ну и какой тогда смысл во всём этом? Разве Sparkplug не выполняет ту же работу, что и интерпретатор?" и во многом будете правы. Во многих отношениях Sparkplug является "просто" сериализацией выполнения интерпретатора, вызывая те же встроенные двоичные сниппеты и поддерживая тот же стековый фрейм. Тем не менее оно того стоит, потому что Sparkplug удаляет (или, точнее, предварительно компилирует) те самые неустранимые накладные расходы интерпретатора, такие как декодирование операндов и диспетчеризация следующего байт-кода.

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

Производительность

Так как же Sparkplug работает на практике? Мы выполнили несколько бенчмарков Chrome на наших ботах для замера производительности со Sparkplug и без него. Спойлер: мы очень довольны.

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

Speedometer

Speedometer это тест, который пытается эмулировать реально работающий фреймворк, создавая веб-приложение для отслеживания списка задач с использованием нескольких популярных фреймворков и проводя стресс-тестирование производительности этого приложения добавлением и удалением задач. Мы обнаружили, что это отличное отражение поведения загрузки и взаимодействия в реальном мире, и мы неоднократно обнаруживали, что улучшения в спидометре отражаются на наших реальных показателях. Со Sparkplug оценка Speedometer улучшается на 510 %, в зависимости от бота.

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

Обзор бенчмарка

Speedometer отличный ориентир, но он не показывает всей картины. Также у нас есть набор бенчмарков просмотра веб-страниц записи набора реальных веб-сайтов, их мы можем воспроизводить, а также скрипт небольших взаимодействий, с их помощью мы можем получить более реалистичное представление о том, как различные метрики ведут себя в реальном мире.

На этих тестах мы решили посмотреть метрику V8 Main-Thread Thread, измеряющую общее проведённое в V8 время (включая компиляцию и выполнение), в основном потоке (то есть исключая стриминговый парсинг или фоновую оптимизацию). Это лучший способ увидеть, насколько оправдан Sparkplug, без учёта других источников шума бенчмарка.

Результаты различны и сильно зависят от машины и веб-сайта, но в целом выглядят прекрасно: видно улучшение около 515 %.

Медианное улучшение времени работы V8 в основном потоке на наших бенчмарках для просмотра с 10 повторениями. Полосы на диаграмме указывают на диапазон между квартилямиМедианное улучшение времени работы V8 в основном потоке на наших бенчмарках для просмотра с 10 повторениями. Полосы на диаграмме указывают на диапазон между квартилями

Таким образом, V8 имеет новый сверхбыстрый неоптимизирующий компилятор, повышающий производительность V8 в реальных бенчмарках на 515 %. Он уже доступен в V8 v9.1 (укажите опцию --sparkplug), и мы выпустим его вместе с Chrome 91.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Быстрое обнаружение Covid-19 на рентгеновских снимках с помощью Raspberry Pi

14.06.2021 18:13:31 | Автор: admin

Системы обнаружения Covid-19 на рентгеновских снимках выдают быстрые результаты, в частности информацию о том, насколько серьёзно лёгкие поражены вирусом Covid-19. Традиционные системы обнаружения Covid-19 обладают тем недостатком, что для формирования отчётов им требуется довольно длительное время, в то время как инфицированный человек нуждается в немедленной помощи. Кроме того, после каждого использования всех подобных систем обнаружения вируса часть деталей приходится утилизировать, что в некоторых случаях может приводить к их дефициту.К старту курса о машинном и глубоком обучении мы перевели статью о том, как эта проблема решается при помощи Raspberry Pi, кроме того, материал знакомит читателей с онлайн-платформой EDGE Impulse.


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

Что для этого нужно

Решение задачи начнём с подбора компонентов.

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

Предварительные требования

На Raspberry Pi должна быть установлена последняя версия ОС Raspbian. Также необходимо подготовить наборы данных для рентгеновских снимков лёгких, инфицированных и не инфицированных Covid-19. Такие снимки можно получить на сайте kaggle онлайн-ресурсе, где размещены рентгеновские снимки инфицированных пациентов, предоставленные сообществом экспертов и врачей. Аналогичные данные приведены на портале GitHub. Загрузим наборы данных рентгеновских снимков здоровых лёгких и лёгких, инфицированных Covid-19.

Теперь выберем платформу для создания ML-модели и обучим её обнаруживать на рентгеновских снимках инфицированные вирусом лёгкие. Здесь у нас есть разные варианты, например TensorFlow, PyTorch или онлайн-платформы: SensiML, Apache Spark, EDGE Impulse и так далее. Я выбрал EDGE Impulse.

В интерфейсе Edge Impulse переходим в меню создания проекта. Система спросит, как мы намереваемся использовать проект. Поскольку мы будем работать с проектом для создания ML-модели обработки изображений, выберем вариант, связанный с работой с изображениями.

Затем система спросит, как нужно классифицировать изображение (классификация одного или многих объектов). Здесь можно выбрать любой вариант. Я выбрал классификацию одного объекта (рис. 2). Щелчком мыши выберем только что созданный проект. Здесь система предложит указать, как его необходимо использовать. Выберем пункт Connect a development board (Подключение макетной платы). Через эту плату данные будут загружаться в проект (рис. 3).

1. Создание проекта1. Создание проекта2. Выбор типа для классификации2. Выбор типа для классификации3. Подключение макетной платы3. Подключение макетной платы

Установка на Raspberry Pi

Откроем окно терминала и с помощью приведённых ниже команд установим на Raspberry Pi зависимость для EDGE_Impulse:

curl -sL https://deb.nodesource.com/setup_12.x | sudo bash -sudo apt install -y gcc g++ make build-essential nodejs sox gstreamer1.0-tools gstreamer1.0-plugins-good gstreamer1.0-plugins-base gstreamer1.0-plugins-base-appsnpm config set user root && sudo npm install edge-impulse-linux -g --unsafe-perm

После установки запускаем Edge_Impulse командой edge-impulse-linux. Нам будет предложено ввести адрес электронной почты и пароль для EDGE Impulse. Вводим требуемые данные и входим в систему (рис. 4).

4. Вход в систему с помощью адреса электронной почты и пароля4. Вход в систему с помощью адреса электронной почты и пароля

Система попросит выбрать проект, к которому должно быть подключено устройство. Указываем название проекта (в моём случае это COVID-19 Detector) (рис. 5).

5. Выбор проекта5. Выбор проекта

Подготовка набора данных

Система выдаст URL-адрес для загрузки набора данных. Есть два варианта загрузки наборов данных рентгеновских снимков: либо через камеру Raspberry Pi (поместив рентгеновские снимки в кадр камеры), либо загрузив файлы фотографий средствами ПК/Raspberry Pi (рис. 6). Я рекомендую второй вариант.

Чтобы вручную загрузить с ПК наборы данных, то есть изображения рентгеновских снимков, выберем эти наборы в качестве тестовых и тренировочных изображений. Выбрав наборы, загрузим их для обучения и установим метки [в оригинале level, крайне вероятна сложная опечатка label, о пороге принятия решений речь идёт далее] для классификации изображений. Здесь я устанавливаю метку Covid-19 infected (Covid-инфицированные лёгкие) и Normal Lungs (Здоровые лёгкие) (рис. 8). Далее загружаем рентгеновские снимки здоровых лёгких и лёгких, инфицированных Covid-19.

6. Получение URL-адреса для создания модели6. Получение URL-адреса для создания модели7. Загрузка набора данных с использованием камеры Raspberry Pi для модели7. Загрузка набора данных с использованием камеры Raspberry Pi для модели8. Загрузка данных из файла изображения8. Загрузка данных из файла изображения

Если вы не успели загрузить изображения в соответствующие категории, с помощью функции Edit (Редактирование) можно позже добавить и/или обозначить их как "Инфицированное лёгкое" или "Здоровое лёгкое". Размечая набор данных, пожалуйста, будьте осторожны. Если пометить рентгеновские снимки здоровых лёгких как Covid-инфицированные, модель будет обучена неправильно, и её точность будет снижена. Перед первоначальной загрузкой наборов данных (с веб-сайта) необходимо создать две отдельные папки: одну для тренировочных, другую для тестовых наборов данных. В обеих папках создадим ещё две папки с названиями Infected lung X-ray (Рентген инфицированных лёгких) и Normal lung X-ray (Рентген здоровых лёгких) соответственно. Загрузим отдельно изображения из обеих папок и после загрузки распределим их по соответствующим категориям (рис. 9).

9. Установка уровня для рентгеновского снимка наборов данных для тренировки модели9. Установка уровня для рентгеновского снимка наборов данных для тренировки модели

Повторим те же шаги, загружая рентгеновские изображения инфицированных и здоровых лёгких для тестовых наборов данных. Опция загрузки изображений для тестовых наборов данных находится рядом с опцией тренировки (рис. 10).

10. Вкладка тренировочных данных10. Вкладка тренировочных данных

Тренируем модель

После загрузки рентгеновских снимков инфицированных и неинфицированных наборов данных модель готова к тренировке. Переходим на вкладку Impulse design, выбираем пункт Create Impulse и жмём кнопку Create Impulse (см. рис. 11). Затем добавляем блок обработки и блок обучения (рис. 12, 13).

11. Создание Impulse11. Создание Impulse12. Выбор блока обработки12. Выбор блока обработки13. Блок обучения.13. Блок обучения.

После добавления блоков обработки и обучения необходимо определить параметры [в оригинале the parameter в единственном числе опечатка]. Для этого нужно получить характеристики рентгеновского снимка и сохранить их (рис. 14, 15). Затем переходим к новой опции тренировки ML-модели. Для этого в экспертном или обычном режиме Keras выбираем тренировку создаваемой ML-модели. В нашем случае выбираем обычный режим. В этом режиме можно задать количество циклов обучения. При увеличении количества циклов обучения точность работы модели увеличится, так как она пройдёт через различные циклы обучения, но при этом также увеличится время, необходимое для обучения ML-модели. Здесь можно задать такие параметры, как порог принятия решений и скорость обучения, значения которых влияют на точность и время работы модели.

15. 3D-визуализация признаков модели15. 3D-визуализация признаков модели16. Генерация параметра16. Генерация параметра17. Настройка и создание Ml-модели17. Настройка и создание Ml-модели

В оригинале надпись к рисунку 15 Feathers graph for ML model., вероятнее всего Features graph for ML model, то есть визуализация пространства признаков модели в трёхмерном пространстве.

Тестирование

Теперь натренированная модель готова к тестированию. Протестировать модель мы можем с уже загруженным рентгеновским снимком, на котором модель попытается обнаружить инфекцию Covid-19 в лёгких.

18. Обнаружение инфекции по рентгеновскому снимку во время тестирования18. Обнаружение инфекции по рентгеновскому снимку во время тестирования19. Классификация снимка для проверки точности модели19. Классификация снимка для проверки точности модели

Развёртывание модели

Теперь наша ML-модель готова к развёртыванию. Развернуть созданную ML-модель для обнаружения инфекции вируса Covid-19 на рентгеновском снимке лёгкого можно многими способами и на разном оборудовании. Поскольку мы используем Linux, выбираем Linux. Затем открываем окно терминала и запускаем программу.

edge-impulse-runner-linux

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

Развёртывание ML-модели обнаружения Covid может быть осуществлено и другими способами. Используя SDK, можно обнаруживать Covid, развёртывая ML-модели на Python. Кроме того, можно загрузить рентгеновский снимок непосредственно в набор тестовых данных, а затем запустить ML-модель в режиме живой классификации она сработает за считанные секунды.

20. Выбор платы для развёртывания20. Выбор платы для развёртывания21. Развёртывание ML-модели в Raspberry Pi21. Развёртывание ML-модели в Raspberry Pi22. Обнаружение инфицированного лёгкого по рентгеновскому изображению22. Обнаружение инфицированного лёгкого по рентгеновскому изображению24. Вывод результатов24. Вывод результатов23. Обнаружение инфекции по рентгеновскому снимку23. Обнаружение инфекции по рентгеновскому снимку24. Здоровые лёгкие идентифицируются как здоровые24. Здоровые лёгкие идентифицируются как здоровые25. Обнаружение вирусной инфекции внутри лёгкого на рентгеновском снимке25. Обнаружение вирусной инфекции внутри лёгкого на рентгеновском снимке

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

Такое сочетание Raspberry Pi в решении проблемы коронавируса одним людям покажется очевидным, но другим неожиданным. Область ML сегодня бурно развивается, расширяет сферу влияния, так что впереди нас ждёт ещё много больших и маленьких парадоксов и неожиданностей самого разного рода. Если вы не хотите оставаться в стороне от прогресса ML, то вы можете присмотреться к нашему курсу о машинном и глубоком обучении, который может стать для вас источником новых идей и решений.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы

ПРОФЕССИИ

КУРС

Подробнее..

DIY регистратор молний

15.06.2021 20:16:32 | Автор: admin

Автор: Alex Wulff (из-за глюков хабраредактора не получилось оформить как перевод)

К старту курса о разработке на С++ мы перевели статью о персональном регистраторе молний небольшом устройстве, сообщающем об ударах молнии поблизости. Оно даже сообщает, на каком расстоянии ударила молния; при этом, по словам автора, собрать его самому обойдётся дешевле, чем купить в магазине. Ещё один очевидный плюс вы сможете отточить свои умения в схемотехнике.

В основу устройства положен детектор молний AS3935 с ВЧ-каналом производства DFRobot. Детектор обнаруживает электромагнитное излучение молнии и с помощью специального алгоритма преобразовывает эту информацию в информацию о расстоянии до удара.


Датчик может обнаруживать удары молнии на расстоянии до 40 км (25 миль) и определять расстояние до места удара молнии с точностью до 4 км (2,5 мили). Сам датчик довольно надёжен, но может срабатывать неверно, если устройство находится на открытом воздухе. Самодельное устройство может работать не так надёжно, как коммерческий регистратор молний.

Материалы
  • микроконтроллер-жучок (beetle) DFRobot #DFR0282. Это плата Arduino Leonardo очень малых размеров;

  • Gravity: датчик расстояния до молнии DFRobot #SEN0290;

  • зарядное устройство для литиевых аккумуляторов DFRobot #SEN0290;

  • аккумулятор LiPo, 500 мАч Amazon #B00P2XICJG;

  • пьезодинамик 5В, например Amazon #B07GJSP68S;

  • маленький скользящий переключатель;

  • монтажный провод (одно- или многожильный).

Инструменты
  • компьютер с бесплатным ПО Arduino IDE.

  • паяльник и припой;

  • пистолет для горячего клея;

  • машинка для зачистки концов провода от изоляции;

  • 3D-принтер (не обязательно).

1. Разработка схемы соединений

Схема устройства проста. Информация с датчика молнии передаётся по линиям SCL и SDA, плюс к этому одно соединение предусмотрено для звукового сигнала. Устройство питается от литий-ионного полимерного аккумулятора (LiPo), поэтому я решил встроить в схему зарядное устройство для такой батареи.

Рисунок AРисунок A

Схема устройства показана на рисунке A. Обратите внимание, что аккумуляторная батарея LiPo соединяется с зарядным устройством через штекерно-гнездовые разъёмы JST и не требует пайки.

2. Сборка схемы

Для сборки устройства лучше всего применить так называемую технику свободной сборки. Детали не крепятся к подложке (например к перфорированной плате) а просто соединяются проводами (рис. Б). Так устройство собирается гораздо быстрее и получается меньше по размеру. Правда, страдает эстетика... Но сомнительную эстетику никто не увидит, если сборку закрыть напечатанным на 3D-принтере корпусом. На видео выше показано, как я собрал схему методом свободной сборки.

Подсоедините жучок к зарядному устройству

Отпаяйте зелёные клеммы от зарядного устройства LiPo. Они бесполезны, но занимают пространство. Соедините положительную (+) и отрицательную (-) клеммы зарядного устройства аккумуляторной батареи LiPo с положительной (+) и отрицательной () клеммами на лицевой части жучка. По этим проводам первичное напряжение батареи LiPo будет подаваться непосредственно на микроконтроллер. Технически жучку требуется 5В, но от напряжения 4В батареи LiPo он всё равно будет работать.

Подключение датчика молнии

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

  • положительную (+) клемму на датчике молнии соедините с положительной (+) клеммой на жучке;

  • отрицательную () клемму на датчике молнии соедините с отрицательной (-) клеммой на жучке;

  • контакт синхронизации (C) на датчике молнии соедините с колодкой SCL на жучке;

  • контакт данных (D) на датчике молнии соедините с колодкой SDA на жучке.

Контакт IRQ на датчике молнии также должен быть соединён с колодкой RX на жучке. Соединение должно подходить к аппаратному прерывателю на жучке; колодка RX (контакт 0) единственный оставшийся контакт, поддерживающий прерывание.

Подключение зуммера

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

Подсоединение переключателя

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

Рисунок БРисунок Б

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

Окончательная компоновка

Рисунок ВРисунок В

Последний шаг избавляемся от беспорядочного скопления проводов и компонентов и приводим устройство в более презентабельный вид (рис. В). Это нужно делать аккуратно, чтобы не переломить провода. Приклейте горячим клеем зарядное устройство LiPo к верхней части батареи LiPo, затем сверху приклейте жучок. И последнее действие: приклейте к самому верху датчик молнии. Зуммер я вывел на сторону, как показано на рисунке В. В результате получилось несколько скреплённых между собой плат с торчащими из них проводами. Выводы переключателя я также оставил свободными, чтобы позже вставить их в корпус, распечатанный на 3D-принтере.

3. Программирование микроконтроллера

Запустите на компьютере Arduino IDE и убедитесь, что в меню ToolsBoard (ИнструментыПлата) выбрано значение Leonardo. Загрузите и установите библиотеку для датчика молнии. Затем скачайте код проекта и загрузите его на жучок. Программа предельно проста и очень легко настраивается.

Обнаружив молнию, устройство сначала подаст несколько звуковых сигналов, чтобы предупредить об ударе молнии поблизости, а затем подаст определённое количество звуковых сигналов, соответствующее расстоянию до молнии в километрах. Если молния находится на расстоянии менее 10 км (6,2 мили), детектор подаст один длинный звуковой сигнал. Если расстояние превышает 10 км (6,2 мили), расстояние будет поделено на 10, округлено, и устройство подаст соответствующее полученному числу количество сигналов. Например, если молния ударит на расстоянии 26 км (16 миль), то сигнала будет три.

Программное обеспечение запускается прерываниями от датчика молнии. Когда он обнаружит электромагнитное излучение от удара, на контакт IRQ подаётся высокое напряжение, оно вызывает прерывание в микроконтроллере. Датчик также может посылать прерывания для событий, не связанных с ударом молнии, например при превышении порогового уровня помех/шума.

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

4. Распечатка корпуса на 3D-принтере (не обязательно)

Рисунок ГРисунок ГРисунок ДРисунок ДРисунок ЕРисунок Е

Корпус для устройства разработал я сам. Файлы для 3D-печати можно загрузить здесь. (рис. Г, Д). Верхняя часть корпуса прищёлкивается к нижней, никакого специального оборудования не требуется. Корпус достаточно просторный, чтобы в нём могло поместиться и ваше устройство, если вы будете собирать его по-другому (рис. Д). В любом случае вам ничего не мешает спроектировать аналогичный корпус самому:

  • определите габариты устройства;

  • спроектируйте устройство в программе CAD (мне нравится Fusion 360 студенты могут получить её бесплатно);

  • создайте корпус, перетащив профиль из модели устройства. Допуска в 2 мм будет вполне достаточно.

Обнаружение ударов молнии

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

Заряжать устройство очень просто достаточно подключить microUSB-кабель к зарядному устройству LiPo и дождаться, когда индикатор зарядки загорится зелёным цветом. Во время зарядки устройство должно быть включено, иначе энергия не будет поступать в аккумулятор!

Внесение изменений

Регистратор молнии можно сделать более полезным и удобным в использовании, если внести в программное обеспечение определённые изменения:

  • другие звуковые сигналы: чтобы устройство звучало приятнее, используйте библиотеку звуков Tone.h;

  • спящий режим: микроконтроллер ATmega32u4 (чип, на основе которого работает жучок) поддерживает аппаратные прерывания в спящем режиме. Устройство можно перевести в спящий режим, и любое поступившее от датчика молнии, событие заставит датчик реагировать. Спящий режим может значительно продлить срок службы батареи.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Оптимизация платежей в Dropbox при помощи машинного обучения

19.06.2021 16:06:42 | Автор: admin

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


Платежи в Dropbox

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

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

Продление подписки и сбои

Обычно подписчики Dropbox платят за подписку ежемесячно или ежегодно. Если клиент дал нам полномочия снимать оплату, повторный платёж списывается с банковской карты клиента автоматически. Когда оплата проходит успешно, подписка продлевается без каких-либо действий со стороны пользователя.

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

Рисунок 1. Недобровольный отток происходит, когда истекает срок действия кредитной карты, или же она аннулирована, или на ней нет средств и т. д.Рисунок 1. Недобровольный отток происходит, когда истекает срок действия кредитной карты, или же она аннулирована, или на ней нет средств и т. д.

Чтобы определить время платежа от клиента, чья подписка не продлевается, наша платёжная платформа использовала статический набор из примерно 10 различных методов. Так сложилось исторически. Например, мы можем взимать плату с клиента каждые четыре дня, пока платёж не завершится успешно, в течение максимум 28 дней. Если платеж клиента к концу этого срока по-прежнему не выполнен, уровень его учётной записи в Dropbox понижается до бесплатной базовой учётной записи. Конечно, для активных пользователей и команд понижение уровня учётной записи создаёт неприятные впечатления, а для Dropbox недобровольный отток может обернуться упущенной выгодой.

Рисунок 2. Попытки обновленияРисунок 2. Попытки обновления

Сбои в оплате могут произойти по ряду причин. Среди них:

  • нехватка средств;

  • карта с истекшим сроком действия;

  • заблокированная карта возможно, сообщается о потере или краже;

  • непредсказуемые сбои обработки.

Некоторые причины могут быть устранены сами по себе, другие для восстановления подписки требуют действий клиента.

Зачем машинное обучение в работе с платежами?

Последние два года, чтобы выяснить, повлияет ли изменение времени оплаты на её успешность, Dropbox проводил A/B-тестирование. Чтобы разработать набор правил о том, когда взимать плату, эти тесты в значительной мере опирались на интуицию и знания людей в предметной области.

Команда платежей должна была вручную разделить пользователей на группы в зависимости от их признаков типа подписки, географического местоположения и т. д., а затем выполнить A/B-тест наших десяти или около того различных жёстко закодированных наборов правил, чтобы определить, какие из них лучше всего подходят для этих признаков. Затем команда платежей сохраняла оптимальный вариант политики для этой группы выставления счетов по умолчанию. Периодически команда проводила повторное тестирование, чтобы узнать, изменились ли для разных пользователей лучшие решения.

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

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

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

Применяя машинное обучение, мы со временем выявили множество улучшений, которые не смогла бы просчитать даже команда ведущих экспертов по платежам:

  • устранение ручного вмешательства и сложной логики на основе правил;

  • например, Повторяйте каждые X дней или Избегайте попыток оплаты в выходные;

  • глобальная оптимизация множества параметров для конкретных сегментов клиентов;

  • устойчивость к изменениям клиентов и рынка;

  • увеличение общего числа успешных платежей и сокращение времени сбора платежей.

Говоря коротко, применение ML к платежам сделало счастливее и клиентов, и нас.

Как мы сделали это

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

Эксперименты проводились с различными сегментами клиентов, а конкретно начиная с отдельных клиентов и команд в Северной Америке. Мы построили модель ранжирования с градиентным бустингом, обученную на таких признаках, как типы сбоев платежей, шаблоны использования учётной записи Dropbox и характеристики типа оплаты. Модель ранжирует попытки оплаты по прогнозируемой вероятности успеха для каждого окна оплаты.

Например, мы взяли окно в 8 дней, разделив его на часовые промежутки, так, в общей сложности получилось 192 отрезка времени. Чтобы найти самый протяжённый отрезок времени для попытки обновления, мы использовали наши модели. А также экспериментировали с дневными окнами по 6 и 4 часа.

Сначала эксперименты проводились с оптимизацией каждой попытки независимо. У нас была модель, оптимизирующая решение о том, когда взимать плату с клиента после неудачной первой оплаты. Если рекомендуемая попытка модели также проваливалась, в оставшейся части окна обновления мы по умолчанию возвращались к логике правил. A/B-тесты этой комбинации проводились на отдельных сегментах пользователей в США. Для таргетинга применялся внутренний сервис развёртывания функциональности Stormcrow. Модель стала работать лучше, и мы развернули её.

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

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

Именно эта модель сегодня проходит A/B-тестирование в производстве при помощи Stormcrow со случайным набором команд участников тестирования Dropbox. Результаты пока положительные.

Predict Service

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

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

Чтобы упростить процесс, мы воспользовались созданным и управляемым командой платформы ML сервисом Predict Service, этот сервис управляет инфраструктурой для быстрого создания, развёртывания и масштабирования процессов машинного обучения в Dropbox. Применение Predict Service помогло сократить время ожидания при генерации прогнозов модели с нескольких минут до менее 300 мс для 99 % моделей. Переход на Predict Service также обеспечил возможность легкого масштабирования и чистое разделение двух систем.

С помощью этой системы машинного обучения платёжная платформа собирает все относящиеся к клиенту сигналы, запрашивает обслуживаемую через сервис Predict модель, чтобы получить лучшее время выставления счета, таким образом устраняя все наши разработанные и закодированные за 14 лет A/B-тестирования неоптимальные политики биллинга. Рабочий процесс этой системы построен следующим образом:

Белый цвет представляет компоненты платёжной платформы. Фиолетовым цветом обозначены компоненты системы машинного обученияБелый цвет представляет компоненты платёжной платформы. Фиолетовым цветом обозначены компоненты системы машинного обучения
  1. Получение прогноза о следующем лучшем времени списания средств. Когда попытка не удалась, платформа платежей, чтобы получить следующее лучшее время, запрашивает модуль Predict. Запрос выполняется с использованием идентификатора клиента и его типа.

  2. Получение сигналов клиентов. Модуль Predict собирает последние сигналы об использовании и о платежах клиентов, а также информацию о предыдущем сбое. Эти данные сохраняются в Edgestore (основной системе хранения метаданных в Dropbox) ежедневным заданием Airflow Job.

  3. Запрос прогноза. Собранные сигналы отправляются в Predict Service через вызов GRPC, который кодирует сигналы во фрейм данных о признаках, а затем отправляет их в модель.

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

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

  6. Расписание следующего платежа. Как только сервис платежей получает наилучшее время списания средств, он учитывает это время при планировании следующей попытки оплаты и сохраняет в Edgestore.

ML-операции

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

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

Бизнес-метрики

  • Коэффициент одобрения счетов. Основная метрика, которую нужно улучшить. При каждом продлении подписки в Dropbox все платежи за продление отслеживаются как часть единого счёта. Эта метрика сообщает нам, было ли обновление подписки успешным.

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

Внутренний мониторинг модели

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

  • Охват: процент клиентов, получивших рекомендации от модели, в сравнении с подходом фиксированного интервала в 4 дня.

  • Количество сделанных моделью прогнозов: количество рекомендаций, которые модель успешно выполнила без каких-либо ошибок.

  • Задержка прогнозирования: сколько времени потребовалось модели для составления каждой рекомендации.

Мониторинг инфраструктуры

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

  • свежесть и задержки в конвейерах данных признаков;

  • доступность и задержка сервиса Predict;

  • доступность EdgeStore.

Для мониторинга нашей модели и метрик инфраструктуры мы используем дашборды Grafana и Vortex. Для бизнес-метрик мы используем Superset. Все эти живые метрики и дашборды помогают нам проактивно отслеживать ожидаемое поведение модели, позволяя принимать соответствующие меры, когда оно отклоняется.

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

Дальнейшие шаги

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

Наша модель, ориентированная на индивидуальных клиентов, в настоящее время внедрена в производство. Модель оптимизации всего цикла обновления сейчас проходит A/B-тестирование. Компания стремится распространить оптимизацию через ML на всех наших клиентов.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Что не так с современным преподаванием информатики

28.05.2021 18:18:56 | Автор: admin

Привет, Хабр! Меня зовут Анна Агабекян, я ментор и автор курсов по направлениям "Тестировщик-автоматизатор на Python" (QAP-тестирование) и Fullstack-разработчик на JavaScript в SkillFactory, а также преподаю физику и информатику в лицее. Параллельно с преподаванием я веду научную работу, посвящённую проблемам образования, и на её основе решила сделать статью для Хабра, так как, на мой взгляд, проблема качественного образования в области информатики и IT сейчас стоит очень остро, но остаётся неосвёщенной. Как преподаватель я вижу, что сейчас процесс развития образовательных организаций отстает от требований IT-сферы. Хотела бы с вами поделиться своим видением данной проблемы и возможных путей решения.


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

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

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

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

Языки программирования, используемые в учебных заведениях

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

Эволюция языков программированияЭволюция языков программирования

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

  • Паскаль;

  • Бейсик;

  • Кумир;

  • Fortran;

  • Алгоритмический язык.

  • Вы имеете в виду английский?

Как мы видим, детям даются знания по языкам, которые не используются сейчас в профессиональной разработке. С точки зрения кадров, это, наверное, правильно, потому что не нужно переучивать преподавателей и переписывать учебники. Но ни Паскаль, ни Бейсик, ни блок-схемы сейчас не нужны в профессиональном программировании разработческая мысль давно шагнула вперёд.

Паскаль лишь только помогает преподавать алгоритмику, но писать современные программы на нём крайне сложно, и вот почему:

  • нет инструмента для быстрого создания интерфейса программы;

  • слабая графическая часть, которая может рисовать только простейшие объекты;

  • ограничения по размеру используемой памяти в переменных и циклах;

  • нет встроенной поддержки web-сервисов и страниц;

  • Паскаль не знает, как работать с современными базами данных, протоколами обмена, облачными хранилищами и сервисами.

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

  1. Чистота и ясность кода, читаемость кода.

  2. Чистота и целостность парадигмы, заложенной в основу языка.

  3. Многогранность и гибкость, возможность писать сложные программы кратко и красиво.

  4. Простота синтаксиса, прозрачность интерпретации языковых конструкций.

  5. Наличие стандартных библиотек и средств интеграции проектов друг с другом и с другими системами и технологиями.Озвученным критериям вполне соответствует Python. Так почему бы не использовать его в качестве образовательного базиса?

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

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

Таким образом, преподаватель имеет право выбрать язык программирования Python в качестве средства обучения основам алгоритмизации и программирования. Для большей наглядности давайте сравним Python с одним из широко используемых сейчас в школах и вузах языком.

Сравнение ЯП, используемых в обучении программированию

Разберём главные отличительные особенности языка программирования Python и проведём сравнение с Паскалем.

1. Простой синтаксис и низкий порог входа.

Python вместо знаков препинания или ключевых слов (в Паскале такими словами являются begin и end) использует отступы для обозначения выполнения блока. Программы, написанные в одну строку или с другими нарушениями в структуре, не смогут быть выполненными в Python. Такая особенность позволит сократить размер кода и увеличить читаемость программы. Синтаксис Python приучит школьников писать красивый код, что улучшит написание и понимание кода. Так, например, различаются записи цикла на Паскале и Python (таблица ниже).

Сравнение синтаксиса цикла с предусловием в Паскаль и Python

Паскаль

Python

while s + n < 150 do

begin

s := s + 15;

n := n - 5

end;

writeln(n)

while s + n < 150:

s = s + 15

n = n - 5

print(n)

2. Динамическая типизация.

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

Сравнение синтаксиса объявления переменных в Паскаль и Python

Паскаль

Python

var s, n: integer;

begin

s := 0;

n := 75;

end.

s = 0

n = 75

3. Лаконичный и изящный код.

Одно из очевидных достоинств языка. Python компактность программного кода. Например, решение задачи поменять местами значения двух переменных на языке Паскаль решается в три оператора, в Python в одну строку (таблица ниже):

Сравнение синтаксиса переприсвоения переменных в Паскаль и Python

Паскаль

Python

c := a;

a := b;

b := c;

a, b = b, a

4. Высокоуровневые типы данных.

Python, будучи языком очень высокого уровня, имеет встроенные типы данных высокого уровня, такие как динамические массивы (списки) и словари.

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

Сравнение синтаксиса заполнения массива в Паскаль и Python

Паскаль

Python

const n = 100;

var a: array[0..n - 1] of integer;

for i := 0 to n - 1 do

a[i] := 0;

n = 100

a = [0] * n

5. Широкое применение.

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

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

Так как же можно всё поправить?

В случае школы одним из решений могло бы стать видоизменение самого предмета "Информатика" в новую дисциплину под названием Информатика и IT-технологии, где это не уроки по использованию офисного пакета, а изучение принципов алгоритмики, computational thinking тех основ, которые не меняются годами.

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

Например, если учебная программа подразумевает преподавание только языка Паскаль, преподавателю должен понимать и другие современные, промышленные языки, особенно если в классе есть ученик, заинтересованный в программировании. Иначе создаётся ситуация, как сейчас, когда уже немолодой преподаватель монотонно подаёт информацию о том, что нужно для того, чтобы в Turbo Pascal возвести x в степень 14.

И, конечно, не обойтись без изменений в местных органах Министерства образования и самой школе. У них должны быть механизмы и ресурсы для отправки преподавателя на дополнительное обучение, в том числе и на частных платных курсах, даже за рубежом. Также не стоит забывать о книгах и иных источниках новой, полезной информации. Необходимо предоставить больше свободы преподавателям-энтузиастам, которые хотят, например, дать своим ученикам Python или C++, а не навязывать Паскаль, как в новых учебниках для 1011 классов, где по ФГОСам есть только упомянутый язык. К сожалению, в нынешних реалиях России всё это выглядит утопией. Хотя по-прежнему будут существовать разработчики, использующие устаревшие языки, нужно учитывать, что в ближайшем будущем они будут заменены более распространёнными.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Простое ускорение Java с помощью Quarkus и JHipster

01.06.2021 20:15:10 | Автор: admin

К старту курса о разработке на Java делимся переводом вводной статьи о Quarkus "родной" для Kubernetes Java-платформе для создания высокопроизводительных веб-, бессерверных (serverless) и нативных приложений (оптимизированных для используемых микропроцессоров). В ней используются предварительная компиляция AOT и агрессивная оптимизация, например сканирование путей к классам, перезагрузка конфигурации и предварительная конфигурация самозагрузки приложения в процессе сборки. Результатом становится впечатляющая скорость загрузки. Другими словами, приложения, созданные с Quarkus, запускаются не просто быстро, а очень быстро!


Так же как для платформ Spring и Micronaut, в Quarkus можно использовать преимущество GraalVM для преобразования JVM-приложений в нативные исполняемые файлы, что ещё больше повышает их быстродействие.

Такой прирост производительности позволяет этой Java-платформе конкурировать с бессерверными, облачными и созданными на основе Kubernetes средами, создавая приложения Supersonic Subatomic Java. В Quarkus используются стандарты Java (такие, как MicroProfile, JAX-RS), а также лучшие из существующих Java-библиотек (например, Hibernate и Vert.x). Есть даже поддержка аннотаций Spring.

Quarkus + JHipster = простое ускорение Java

История технологий разработки наглядно демонстрирует, что совместить различные компоненты бывает очень непросто. Разработчики любят, когда им предлагается что-то авторитетно-одобренное, и как раз здесь на сцену выходит JHipster.

JHipster это сопровождаемая сообществом разработчиков полнофункциональная платформа разработки, позволяющая создавать, развивать и развёртывать веб-приложения и ориентированные на микросервисы архитектуры. Стандартной серверной платформой в JHipster является Spring Boot, но постоянно появляются всё новые и новые возможности. Одним из таких вариантов стала blueprint-схема JHipster Quarkus.

Помимо прочего, одной из ключевых возможностей, определяющих успех JHipster, стала его расширяемость с помощью blueprint-схем. Blueprint-схема действует как плагин JHipster и позволяет вам переопределять стандартное поведение, настраивая его на свой вкус.

Например, blueprint-схема Kotlin с JHipster является популярным дополнением, которое любят использовать разработчики. Использование blueprint-схемам многократно расширяет границы возможностей. Вот почему в JHipster есть даже реализации без Java (такие, как Node + NestJS и .NET Core). Эта публикация познакомит вас с основными шагами по использованию JHipster, blueprint-схемой Quarkus, а также протоколом OAuth для создания оптимизированного для работы на конкретных микропроцессорах и безопасного полнофункционального приложения.

Создание Java-приложения с Quarkus

Прежде чем приступить к работе, необходимо установить несколько инструментов.

Предварительные требования:

Установите JHipster и его blueprint-схему Quarkus, используя npm:

# Install JHipster globallynpm install -g generator-jhipster@6.10.5# Install the JHipster Quarkus blueprintnpm install -g generator-jhipster-quarkus@1.1.1

Команда jhipster-quarkus сокращение для jhipster --blueprints quarkus. Посмотреть все варианты её синтаксиса можно с помощью команды --help.

$ jhipster-quarkus --help

Создание приложения в среде JHipster Quarkus

mkdir okta-jhipster-quarkus-example && cd okta-jhipster-quarkus-example# oh-my-zsh users: take okta-jhipster-quarkus-example

Чтобы запустить мастер создания приложений, можно выполнить команду jhipster-quarkus:

jhipster-quarkus

В этой вводной статье основным вопросом будет выполнение аутентификации.

Среда JHipster Quarkus позволяет использовать JWT (с возможностью управления пользователями в базе данных приложений) или аутентификацию OAuth 2.0/OIDC с применением поставщиков идентификационной информации, таких как Keycloak и Okta. OIDC расшифровывается как OpenID Connect, этот протокол представляет собой тонкий слой поверх протокола аутентификации OAuth 2.0. Его основная задача обеспечить аутентификацию и идентификацию пользователя.

Ниже представлен пример ответов на вопросы мастера создания приложений.

После того как вы ответите на все эти вопросы, JHipster создаст код вашего приложения и выполнит команду npm install.

{  "generator-jhipster": {    "promptValues": {      "packageName": "com.mycompany.myapp",      "nativeLanguage": "en"    },    "jhipsterVersion": "6.10.5",    "applicationType": "monolith",    "baseName": "jhipster",    "packageName": "com.mycompany.myapp",    "packageFolder": "com/mycompany/myapp",    "serverPort": "8080",    "authenticationType": "oauth2",    "cacheProvider": "no",    "enableHibernateCache": true,    "websocket": false,    "databaseType": "sql",    "devDatabaseType": "h2Disk",    "prodDatabaseType": "mysql",    "messageBroker": false,    "buildTool": "maven",    "embeddableLaunchScript": false,    "useSass": true,    "clientPackageManager": "npm",    "clientFramework": "angularX",    "clientTheme": "none",    "clientThemeVariant": "",    "creationTimestamp": 1614834465776,    "jhiPrefix": "jhi",    "entitySuffix": "",    "dtoSuffix": "DTO",    "otherModules": [      {        "name": "generator-jhipster-quarkus",        "version": "1.1.1"      }    ],    "enableTranslation": true,    "nativeLanguage": "en",    "languages": ["en"],    "blueprints": [      {        "name": "generator-jhipster-quarkus",        "version": "1.1.1"      }    ]  }}

В этом файле содержатся все ответы на исходные вопросы мастера JHipster, что позволит создать приложение без дополнительных запросов.

Убедитесь, что выполняемая с помощью Keycloak аутентификация OAuth 2.0/OIDC действительно работает

Помимо прочих файлов JHipster Quarkus создаёт файлы для инструментального средства Docker Compose, помогающие загрузить среду разработки, настроенную для вашего только что созданного приложения. При этом даже выполняется импорт данных Keycloak, заданных по умолчанию для пользователей и приложений, и вам не придётся делать это самим.

https://gitlab.webant.ru/russia_quiz/frontend/-/merge_requests

Если Keycloak запущен и работает, вы сможете выполнить вход в систему. Запустите ваше приложение с помощью Maven:

./mvnw

Вы можете видеть, что приложение запускается за 3,351 с, также выводится обширный список расширений Quarkus (включая oidc). Перейдите по адресу http://localhost:8080 в предпочитаемом вами браузере и нажмите ссылку sign in (вход).

Вы будете перенаправлены в Keycloak для входа в систему. При запросе идентификационных данных введите admin/admin.

После успешного прохождения аутентификации вы будете перенаправлены обратно в ваше приложение Quarkus.

Как работает поддержка протокола аутентификации OAuth 2.0 в JHipster Quarkus

Одной из проблем при разработке blueprint-схем JHipster, таких как Quarkus, является необходимость найти правильный баланс между повторным использованием существующих механизмов и добавлением индивидуальных реализаций.

С самого первого дня своего появления JHipster осуществлял интеграцию всех современных платформ для создания веб-приложений (Angular, React или даже Vue.js), совмещая их с фактически стандартными Java-технологиями, такими как Spring Boot и Spring Cloud.

В реализации JHipster Quarkus OAuth 2.0 за основу взято URI-перенаправление login/oauth2/code/oidc, предполагающее использование платформы аутентификации Spring Security. Настоятельно рекомендуем выполнять аутентификации на стороне сервера, поскольку это намного безопаснее (так как у браузера нет необходимости управлять какими-либо идентификационными данными и хранить какие-либо маркеры доступа).

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

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

Объединение JHipster Quarkus с сервисом Okta

Из этого раздела вы узнаете, как использовать сервис Okta в качестве провайдера протокола аутентификации OAuth 2.0/OIDC. В Okta предусмотрены два варианта для конфигурирования OIDC-приложения. Это можно выполнить либо в консоли разработчика, либо с помощью инфраструктуры Okta CLI.

Использование инфраструктуры Okta CLI для конфигурирования JHipster

Инфраструктура Okta CLI автоматизирует для вас все конфигурации JHipster и Okta. Для установки Okta CLI можно воспользоваться популярными менеджерами пакетов.

macOS (с помощью Homebrew):

brew install --cask oktadeveloper/tap/okta

Linux (с помощью Flatpak):

# Add Flathub repoflatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo# install the packageflatpak install com.okta.developer.CLI# add this to your appropriate dot filealias okta="flatpak run com.okta.developer.CLI"

Windows (с помощью Chocolatey):

choco install okta -version 0.8.0

Вы также можете просто передать его в оболочку bash:

curl https://raw.githubusercontent.com/okta/okta-cli/master/cli/src/main/scripts/install.sh | bash

Если у вас ещё нет аккаунта разработчика в Okta, откройте терминал, перейдите в каталог приложения Quarkus и выполните okta register. Если у вас есть аккаунт, выполните okta login.

$ okta registerFirst name: DanielLast name: PetismeEmail address: daniel.petisme@gmail.comCompany: OktaCreating new Okta Organization, this may take a minute:OrgUrl: https://dev-9323263.okta.comAn email has been sent to you with a verification code.Check your emailVerification code: 232819New Okta Account created!Your Okta Domain: https://dev-9323263.okta.comTo set your password open this link:https://dev-9323263.okta.com/welcome/drpt2SjbRAPR-gvVHhnm

Если у вас уже есть аккаунт разработчика Okta, выполните команду okta login. Затем из каталога приложения Quarkus выполните okta apps create jhipster. Примите предлагаемые по умолчанию предложения для перенаправления URI.

$ okta apps create jhipsterApplication name [okta-jhipster-quarkus-example]:Redirect URICommon defaults:  Spring Security - http://localhost:8080/login/oauth2/code/okta  Quarkus OIDC - http://localhost:8080/callback  JHipster - http://localhost:8080/login/oauth2/code/oidcEnter your Redirect URI(s) [http://localhost:8080/login/oauth2/code/oidc, http://localhost:8761/login/oauth2/code/oidc]:Enter your Post Logout Redirect URI(s) [http://localhost:8080/, http://localhost:8761/]:Configuring a new OIDC Application, almost done:Created OIDC application, client-id: 0oa5ozjxyNQPPbKc65d6Creating Authorization Server claim 'groups':Adding user daniel.petisme@gmail.com to groups: [ROLE_USER, ROLE_ADMIN]Creating group: ROLE_USERCreating group: ROLE_ADMIN

Конфигурация приложения Okta записывается здесь: /Users/daniel/workspace/okta-jhipster-quarkus-example/.okta.env

ПРИМЕЧАНИЕ: идентификаторы URI, перенаправленные http://localhost:8761*, предназначены для реестра JHipster, который часто используется при создании микросервисов с помощью JHipster. В инфраструктуре Okta CLI они добавляются по умолчанию. Они не требуются для приложения, создаваемого в этой вводной статье, но если их оставить, то никакого вреда точно не будет.

Инфраструктура Okta CLI создаст файл .okta.env в текущем каталоге. Если посмотреть на него, то вы увидите, что в нём содержатся несколько ключей и значений, предназначенных для протокола OIDC.

$ cat .okta.envexport QUARKUS_OIDC_AUTH_SERVER_URL="http://personeltest.ru/aways/dev-9323263.okta.com/oauth2/default"export QUARKUS_OIDC_CLIENT_ID="0oa5ozjxyNQPPbKc65d6"export QUARKUS_OIDC_CREDENTIALS_SECRET="KEJ0oNOTFEUEFHP7i1TELLING1xLm1XPRn"export QUARKUS_OIDC_AUTHENTICATION_REDIRECT_PATH="/login/oauth2/code/oidc"export JHIPSTER_OIDC_LOGOUT_URL="http://personeltest.ru/aways/dev-9323263.okta.com/oauth2/default/v1/logout"

Установите файл, чтобы задать переменные среды, и запустите ваше приложение с помощью Maven.

source .okta.env./mvnw

Обязательно добавьте \*.env в ваш файл .gitignore, чтобы в коммиты не попадал ваш секрет клиента.

Как только приложение будет запущено, в окне в режиме инкогнито откройте http://localhost:8080 и выполните вход. Вам будет предложено ввести свои идентификационные данные Okta.

После успешного прохождения аутентификации вы будете перенаправлены обратно в ваше приложение. На начальной странице должен отображаться ваш адрес электронной почты.

Инфраструктура Okta CLI упрощает конфигурирование JHipster и выполняет следующие полезные операции.

  1. Создаётся приложение OIDC с правильным перенаправлением URI.

  2. Заводятся группы ROLE_ADMIN и ROLE_USER, требуемые для JHipster.

  3. Ваш текущий пользователь добавляется в группы ROLE_ADMIN и ROLE_USER.

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

Но вдруг вы не любите работать из командной строки? Не паникуйте, тут есть кому прикрыть вашу спину! Инфраструктура Okta CLI проста в использовании, но для тех, кому это необходимо, есть возможность выполнить настройки с помощью интерфейса пользователя. Именно поэтому я так подробно рассматриваю каждый шаг по настройке приложения OIDC, работающего с JHipster Quarkus.

Использование консоли разработчика Okta для настройки JHipster

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

Разверните вложенное меню Applications (Приложения) на панели навигации слева, затем выберите в меню Applications > Create App Integration (Приложения > Создать интеграцию приложений), чтобы запустить мастер создания приложений.

Выберите OIDC и Web Application. Затем нажмите кнопку Next (Далее).

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

  • Name (Имя): можете указать любое имя на свой вкус, но разве JHipster Quarkus чем-то не подходит?

  • Login redirect URIs (Перенаправление URI при входе): определяет, будет ли Okta выполнять перенаправление в браузере клиента после аутентификации. Установите для него http://localhost:8080/login/oauth2/code/oidc, именно это значение настроено по умолчанию.

  • Logout redirect URIs (Перенаправление URI при выходе): http://localhost:8080 указывается, куда будет перенаправляться пользователь после выполнения выхода.

  • Group assignments (Назначения групп): определяет, какие группы могут использовать это приложение.

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

Наиболее важными являются следующие значения:

  • идентификационные данные клиента (ID и секрет клиента). Они позволяют приложению Java выполнять аутентификацию в сервисах Okta для последующей обработки потоков аутентификации и авторизации пользователей;

  • домен Okta, из которого Quarkus будет выводить конечные точки адресов URL для протоколов OAuth/OIDC.

Создание групп пользователей

Теперь настало время для создания групп пользователей. По умолчанию для JHipster требуются две следующие группы:

  • ROLE_USER: для аутентифицированных пользователей;

  • ROLE_ADMIN: для аутентифицированных пользователей с административными правами для этого приложения.

В консоли разработчика выберите в меню Directory > Groups (Каталог > Группы). Нажмите Add Group (Добавить группу) и создайте группу ROLE_ADMIN

Теперь добавьте группу ROLE_USER.

Всё, вы завершили создание групп, теперь займёмся добавлением пользователей.

Создание пользователей

Чтобы увидеть различие между обычными и административным пользователями, создайте пользователей в каждой из групп. Используя консоль разработчика Okta, выберите в меню Directory > People (Каталог > Люди). Нажмите Add Person (Добавить человека). Начните с создания пользователя Administrator.

Основным моментом тут является привязка пользователя Administrator к группе ROLE_ADMIN. Чтобы определить исходный пароль, который пользователь должен будет изменить, исключительно в демонстрационных целях для данной вводной статьи использована стратегию выбора пароля Set by Admin (Задаётся администратором). В реальном проекте я рекомендую использовать стратегию Set by User (Задаётся пользователем) с активацией по электронной почте. Теперь добавим обычного пользователя.

Убедитесь, что пользователь User входит в группу ROLE_USER. Очень важно использовать действующий адрес электронной почты, так как он может понадобиться при восстановлении пароля. Выберите в меню Applications > JHipster Quarkus (Приложения > JHipster Quarkus) и нажмите Assignments (Назначения). Назначьте группам пользователей, которых только что создали.

Добавление заявки на группы к маркеру ID

Последнее, о чём необходимо вам позаботиться, это настроить заявку на группы, включающую группы пользователей в маркер ID. Выберите в меню Security > API (Безопасность > API), а затем нажмите default (по умолчанию). Щёлкните Claims > Add Claim (Заявки > Добавить заявку). Введите следующие значения:

  • Name (Имя): groups (группы);

  • Include in token type (Включить тип маркера): ID Token (Маркер ID);

  • Value type (Тип значения): groups (группы);

  • Filter (Фильтр): Matches regex with a value of .* (Соответствует регулярному выражению со значением .*).

Нажмите Create (Создать). Конфигурация Okta для JHipster готова!

Настройка Quarkus OIDC для Okta

В этот момент необходимо, чтобы приложение JHipster Quarkus уже было запущено и для использования Keycloak в качестве провайдера идентификационных данных для него. Давайте изменим настройки для работы с Okta. Во-первых, необходимо выйти из веб-приложения JHipster, чтобы предотвратить конфликт файлов cookie. Выберите Account > Sign Out (Аккаунт > Выход).

ПРИМЕЧАНИЕ: можно оставить приложение запущенным. Quarkus поддерживает работу в так называемом режиме для разработки (Dev Mode), обеспечивающем горячую перезагрузку любых исходных или ресурсных файлов при каждом их обновлении. Это исключительно удобно!

Откройте для редактирования файл src/main/resources/application.properties и найдите в нём раздел со следующей конфигурацией OIDC.

# OAuth 2.0 and OIDCquarkus.oidc.enabled=truequarkus.oidc.auth-server-url=http://localhost:9080/auth/realms/jhipster/%dev.quarkus.oidc.client-id=web_app%dev.quarkus.oidc.credentials.secret=web_appquarkus.oidc.application-type=hybridquarkus.oidc.authentication.scopes=profile,address,email,address,phone,offline_accessquarkus.oidc.authentication.cookie-path=/quarkus.oidc.authentication.redirect-path=/login/oauth2/code/oidcquarkus.oidc.authentication.restore-path-after-redirect=falsejhipster.oidc.logout-url=http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/logout%test.quarkus.oidc.client-id=dummy%test.quarkus.oidc.application-type=service%test.jhipster.oidc.logout-url=some-dummy-logoutUrl

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

  • quarkus.oidc.auth-server-url: корневой URL для API Okta, полученный из домена приложения OIDC;

  • quarkus.oidc.client-id: ID клиента для приложения OIDC;

  • quarkus.oidc.credentials.secret: секрет клиента для приложения OIDC;

  • jhipster.oidc.logout-url: в JHipster браузер будет запускать выход из системы. Серверная сторона должна предоставлять эту информацию (пока её невозможно получить с помощью OIDC-поиска).

После того как вы обновите этот файл, ваши настройки должны выглядеть примерно так:

# OAuth 2.0 and OIDCquarkus.oidc.enabled=truequarkus.oidc.auth-server-url=https://dev-9323263.okta.com/oauth2/defaultquarkus.oidc.client-id=0oaajhdr9q9jxbBM95d6quarkus.oidc.credentials.secret=NEVERSHOWSECRETSquarkus.oidc.application-type=hybridquarkus.oidc.authentication.scopes=profile,address,email,address,phonequarkus.oidc.authentication.cookie-path=/quarkus.oidc.authentication.redirect-path=/login/oauth2/code/oidcquarkus.oidc.authentication.restore-path-after-redirect=falsejhipster.oidc.logout-url=https://dev-9323263.okta.com/oauth2/default/v1/logout

Перезапустите приложение, перейдите по адресу http://localhost:8080. Нажмите sign in (вход) и вы будете перенаправлены на страницу входа Okta.

Введите admin в качестве имени пользователя и пароль, который вы задали. Okta определит, что это ваш первый вход в систему, и предложит сменить пароль. После выполнения вы будете перенаправлены в ваше приложение Quarkus.

Переход в нативный формат с помощью Quarkus и GraalVM

Заключительным шагом в данной вводной статье будет упаковка приложения Java в виде нативного выполняемого файла (оптимизированного для используемого микропроцессора). И снова JHipster надёжно прикрывает ваши тылы, делая для вас всё необходимое. Просто выполните в Maven команду package с профилем native:

./mvnw package -Pnative -DskipTests

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

[error]: Build step io.quarkus.deployment.pkg.steps.NativeImageBuildStep#build threw an exception: java.lang.RuntimeException: Cannot find the `native-image` in the  GRAALVM_HOME, JAVA_HOME and System PATH. Install it using `gu install native-image`

Самым простым способом решения этой проблемы будет применение SDKMAN для установки Java 11 с GraalVM:

sdk install java 21.0.0.2.r11-grl

Затем выполните gu install native-image:

$ gu install native-imageDownloading: Component catalog from www.graalvm.orgProcessing Component: Native ImageDownloading: Component native-image: Native Image  from github.comInstalling new component: Native Image (org.graalvm.native-image, version 21.0.0.2)

Как только процесс завершится, перезапустите команду package в Maven:

./mvnw package -Pnative -DskipTests

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

  • ознакомиться с проектом JHipster Quarkus Blueprint;

  • исследовать сайт для разработчиков Okta;

  • изучить эти великолепные руководства по Quarkus.

Спустя примерно три минуты нативный выполняемый файл должен быть готов:

Запустите его как нативный выполняемый файл, используя команду target/*runner:

Ваше старое доброе Java-приложение запустится через 1 секунду! Помните, я рассказывал о приросте памяти? Ниже привожу команду, как посмотреть потребление памяти в мегабайтах:

$ ps -o pid,rss,command | grep --color jhipster | awk '{$2=int($2/1024)"M";}{ print;}'30951 46M ./target/jhipster-1.0.0-SNAPSHOT-runner31433 0M grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --color jhipster

Ваше приложение потребляет менее 50 МБ памяти. Перейдите по адресу http://localhost:8080 и убедитесь, что всё исправно работает. Теперь наслаждайтесь своим успехом!

Дальнейшая разработка с помощью JHipster Quarkus

Надеюсь, вы получили удовольствие от данной вводной статьи, пройдя все этапы создания нативного приложения и применяя для этого Java, Quarkus и JHipster. Не правда ли, впечатляет, как JHipster и Okta CLI делают для вас основную тяжёлую работу?! Вы можете найти пример, созданный в этой вводной статье, на GitHub. Если вы заинтересованы в дополнительном изучении blueprint-схем Quarkus, посмотрите проект generator-jhipster-quarkus, также размещённый на GitHub.

Совсем недавно Java считали медленным языком программирования, а вернее было бы сказать, что медленной была виртуальная машина Java, но это не помешало языку стать одним из самых востребованных по версии TIOBE. Сегодня Java становится всё быстрее, а это значит, что она ещё надолго сохранит способность конкурировать с новыми языками; кроме того, в последнее время наметилась тенденция к упрощению синтаксиса Java. Если вам интересен этот язык и работа с ним в перспективе, то вы можете посмотреть на программу обучения нашего курса по Java, где студенты за 14 месяцев получают всестороннюю подготовку к трудоустройству в качестве Java-разработчика.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Как использовать Python для проверки протокола Signal

08.06.2021 18:13:14 | Автор: admin

Galois работает над повышением удобства SAW, инструмента для верификации программ наCиJava, исходный код кторого открыт. Основным способом взаимодействия пользователей сSAW является его спецификация иязык программирования сценариев. Чтобы сделать SAW как можно более доступным, вкачестве языка программирования SAW теперь можно использовать Python! Для демонстрации этой новой возможности в Galoisсоздали пример, выполнив проверку части реализации протокола Signal наязыкеС.В частности, как спецификация SAW определяются условия, при которых сообщение протокола Signal будет успешно аутентифицировано. К старту курса о Fullstack-разработке на Python мы перевели материал об этом примере.


SAW-клиент Python

Управление SAW может осуществляться средствами Python через библиотеку saw-client вPyPI. Реализация спомощью Python непредставляет сложности управление SAW осуществляется через JSON-RPC API, как показано впредыдущей статье. Библиотека saw-client постоянно развивалась, итеперь вней реализован высокоуровневый интерфейс, отвечающий зареализацию функций RPC.

Помимо Python, вSAW также используется альтернативный язык программирования сценариев, называемый SAWScript. Хотя наSAWScript возможно писать теже проверки, что иPython, этотязыкнелишён недостатков. SAWScript специализированный язык, поэтому ондовольно сложен для понимания теми, кто впервые берётся заизучениеSAW. Кроме того, вSAWScript практически отсутствует возможность подключения внешних библиотек. Если вызахотите написать наSAWScript то, чего нет встандартной библиотеке, вам придётся реализовать нужную функцию самостоятельно.

Сдругой стороны, Python широко используемый язык, изначально хорошо знакомый гораздо большему числу людей. УPython также имеется богатый набор библиотек ивспомогательных программ, доступных вкаталоге PyPI. Даже если Python невходит вчисло ваших любимых языков программирования, мывсё равно советуем попробовать saw-client. Если под рукой неокажется ничего другого, код, написанный вsaw-client, может послужить источником вдохновения для реализации аналогичного клиента надругом языке.

Базовая спецификация вsaw-client

Давайте рассмотрим, как saw-client можно использовать для создания спецификаций реального кода наязыкеC. Для примера возьмём libsignal-protocol-c. Эта библиотека представляет собой реализованный наязыке Cпротокол Signal, криптографический протокол, используемый для шифрования мгновенных сообщений, голосовых ивидеозвонков. Этот протокол применяется вприложении Signal Messenger, получившем название попротоколу, нотакже поддерживается вдругих приложениях, таких как WhatsApp, Facebook Messenger иSkype.

Общее описание возможностей SAW сиспользованием библиотеки libsignal-protocol-c приведено вразделе "Планы".

Для начала рассмотрим базовую структуру данных, используемую библиотекой libsignal-protocol-c, аименно signal_buffer:

struct signal_buffer {    size_t len;    uint8_t data[];};

signal_buffer представляет собой байтовый массив (массив данных) сдлинойlen. При отправке сообщения спомощью libsignal-protocol-c основным компонентом сообщения является signal_buffer.

Чтобы быть уверенным, что libsignal-protocol-c работает так, как заявлено, нужно убедиться, что содержимое signal_buffer сообщения соответствует ожидаемому. Библиотека проверяет соответствие двух буферов signal_buffer спомощью функции signal_constant_memcmp:

int signal_constant_memcmp(const void *s1, const void *s2, size_t n){    size_t i;    const unsigned char *c1 = (const unsigned char *) s1;    const unsigned char *c2 = (const unsigned char *) s2;    unsigned char result = 0;    for (i = 0; i < n; i++) {        result |= c1[i] ^ c2[i];    }    return result;}

Интуитивно понятно, что утилита signal_constant_memcmp должна проверить, одинаковоли содержимое двух байтовых массивов signal_buffer. Если они одинаковы, функция вернёт значение0. Если содержимое несовпадает, возвращается значение, указывающее набайты, вкоторых массивы отличаются.

При этом напервый взгляд может быть неочевидно, что при одинаковых массивах функция вернёт значение0. Учитывая, что манипуляций сбитами происходит довольно много, вполне возможно, что кто-то мог допустить ошибку при написании кода, манипулирующего битами. Правильность такого кода можно проверить, сверив его соспецификацией, созданной спомощью saw-client. Такая спецификация может выглядеть примерно так:

from saw_client.llvm import *class ConstantMemcmpEqualSpec(Contract):    def specification(self) -> None:        _1        self.execute_func(_2)        _3

Класс Contract определяет спецификации SAW сиспользованием метода specification. Чтобы создать собственную спецификацию, достаточно создать подкласс Contract ипереопределить метод specification. Каждая спецификация состоит изтрёх частей:

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

  • Аргументы для передачи впроверяемую функцию (_2).

  • Постусловия (_3), определяющие характер проверки после вызова верифицируемой функции.

Учитывая требования кспецификации, проверим, как утилита signal_constant_memcmp работает в пределах спецификации SAW:

class ConstantMemcmpEqualSpec(Contract):    n: int    def __init__(self, n: int):        super().__init__()        self.n = n    def specification(self) -> None:        s1  = self.fresh_var(array_ty(self.n, i8), "s1")        s1p = self.alloc(array_ty(self.n, i8), points_to = s1)        s2  = self.fresh_var(array_ty(self.n, i8), "s2")        s2p = self.alloc(array_ty(self.n, i8), points_to = s2)        self.precondition(cryptol(f"{s1.name()} == {s2.name()}"))        self.execute_func(s1p, s2p, cryptol(f"{self.n} : [64]"))        self.returns(cryptol("0 : [32]"))

Предварительными условиями являются наличие двух байтовых массивов (s1p иs2p), содержимое которых s1 иs2одинаково. Вчастности, одинаковость содержимого гарантирует вызов self.precondition(...). Аргумент self.precondition(...) записывается наCryptol, предметно-ориентированном языке программирования (DSL), используемом вкриптографии. Приведённое выражение наCryptol довольно простое, так как выполняет только проверку равенства, нониже мыувидим более сложные примеры наCryptol.

Аргументами функции являются два байтовых массива суказанием ихдлин (self.n), преобразуемых вначале ввыражение Cryptol, чтобы SAW мог получить оних представление. Порстусловие, снова ввиде выражения наCryptol, заключается втом, что функция возвращает значение 0.

После проведения всей подготовительной работы проверяем, что signal_constant_memcmp соответствует созданной нами спецификации:

mod = llvm_load_module("libsignal-protocol-c.bc") # An LLVM bitcode filearray_len = 42 # Pick whichever length you want to checkllvm_verify(mod, "signal_constant_memcmp", ConstantMemcmpEqualSpec(array_len))

Если проверка пройдёт нормально, можно запустить этот код наPython иувидеть следующий результат:

Verified: lemma_ConstantMemcmpEqualSpec (defined at signal_protocol.py:122)

Ура! Инструмент SAW проверил правильность работы утилиты signal_constant_memcmp. Важно отметить, что нам ненужно было даже упоминать обитовых манипуляциях внутри функции SAW выполнил ихавтоматически. Отметим, однако, что команда ConstantMemcmpEqualSpec определяет происходящее только втом случае, если байтовые массивы равны друг другу. Еслибы мыхотели охарактеризовать происходящее вслучае неравенства байтовых массивов, потребоваласьбы несколько более сложная спецификация.

Также следует отметить, что вприведённом выше коде встречаются повторения, так как мыдважды вызываем функцию self.fresh_var(), азатем self.alloc(). Ксчастью, Python избавляет оттаких проблем:

def ptr_to_fresh(spec: Contract, ty: LLVMType,                 name: str) -> Tuple[FreshVar, SetupVal]:    var = spec.fresh_var(ty, name)    ptr = spec.alloc(ty, points_to = var)    return (var, ptr)class ConstantMemcmpEqualSpec(Contract):    ...    def specification(self) -> None:        (s1, s1p) = ptr_to_fresh(self, array_ty(self.n, i8), "s1")        (s2, s2p) = ptr_to_fresh(self, array_ty(self.n, i8), "s2")        ...

Верификация кода сиспользованием HMAC

Отбиблиотеки libsignal-protocol-c требуется гораздо больше, чем просто хранить сообщения она также должна отправлять иполучатьих. Кроме того, шифровать сообщения необходимо так, чтобы ихмог прочитать только предполагаемый получатель, чтобы частную переписку немогли перехватить третьи лица.

Одним изосновных этапов шифрования сообщения является присоединение кода аутентификации сообщения (MAC), который можно использовать для проверки того, что после отправки сообщения его содержимое неменялось. Вчастности, libsignal-protocol-c использует HMAC, тип MAC, вычисляемый спомощью криптографической хеш-функции.

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

hmac_init : {n} [n][8] -> HMACContexthmac_init = undefinedhmac_update : {n} [n][8] -> HMACContext -> HMACContexthmac_update = undefinedhmac_final : HMACContext -> [SIGNAL_MESSAGE_MAC_LENGTH][8]hmac_final = undefined

Это будут неинтерпретируемые функции, используемые для создания кода, связанного сHMAC, вбиблиотеке libsignal-protocol-c. Основная идея заключается втом, что, получив навходе криптографический ключ, hmac_init создаст HMACContext. HMACContext будет многократно обновляться через hmac_update, используя данные первого аргумента. Затем hmac_final преобразует HMACContext вsignal_buffer достаточной длины для хранения MAC.

Определение HMACContext зависит оттого, какая криптографическая хэш-функция используется всочетании сHMAC. Параметры библиотеки libsignal-protocol-c настроены для используемых еюхеш-функций, поэтому можно свободно подключать библиотеки OpenSSL, Common Crypto или другую подходящую библиотеку.

Поскольку эти функции считаются неинтерпретируемыми, SAW небудет ихоценивать вовремя верификации. Другими словами, то, как реализованы эти функции, неимеет значения; undefined выбрано для удобства, ноподойдёт илюбая другая реализация.

После определения этих функций можно связать ихссоответствующими функциями Cвсамой библиотеке. Например, вот сокращённая спецификация для функции signal_hmac_sha256_initC:

class SignalHmacSha256InitSpec(Contract):    key_len: int    def specification(self) -> None:        hmac_context_ptr = self.alloc(...)        (key_data, key)  = ptr_to_fresh(self, array_ty(self.key_len, i8),                                        "key_data")            self.execute_func(..., hmac_context_ptr, key,                          cryptol(f"{self.key_len} : [64]"))        init = f"hmac_init`{{ {self.key_len} }} {key_data.name()}"        dummy_hmac_context = self.alloc(..., points_to = cryptol(init))        self.points_to(hmac_context_ptr, dummy_hmac_context)        self.returns(cryptol("0 : [32]"))key_len = 32init_spec = llvm_assume(mod, "signal_hmac_sha256_init",                        SignalHmacSha256InitSpec(key_len))

Нестарайтесь понять каждую строчку кода. Просто знайте, что самой важной его частью является последняя строка, вкоторой вместо llvm_verify используется llvm_assume. Функция llvm_assume позволяет SAW использовать спецификацию, фактически немоделируя её посути SAW трактует еёкак аксиому. Это позволяет привязать поведение signal_hmac_sha256_init кнеинтерпретируемой функции hmac_init впостусловиях спецификации.

Аналогичным образом llvm_assume также можно использовать для создания спецификаций, включающих hmac_update иhmac_final. После этого можно проверить очень важную функцию, связанную сMAC: signal_message_verify_mac. Фактически данная функция принимает сообщение вкачестве аргумента, вычисляет MAC для данных внутри сообщения ипроверяет, совпадаетли онсMAC вконце сообщения. Если значения совпадают, можно суверенностью утверждать, что при отправке получателю сообщение неменялось.

Объяснение всех тонкостей работы signal_message_verify_mac занялобы довольно много времени, поэтому вэтой заметке мыкоснёмся лишь главного вопроса: как должно выглядеть содержимое сообщения? Данные внутри сообщения могут быть произвольными, однако MAC вконце должен иметь вполне определённую форму. Эту форму можно определить спомощью функции Python:

def mk_hmac(serialized_len: int, serialized_data: FreshVar,        receiver_identity_key_data : FreshVar,        sender_identity_key_data: FreshVar,        mac_key_len: int, mac_key_data: FreshVar) -> SetupVal:    sender_identity_buf = f"""        [{DJB_TYPE}] # {sender_identity_key_data.name()}            : [{DJB_KEY_LEN} + 1][8]        """    receiver_identity_buf = f"""        [{DJB_TYPE}] # {receiver_identity_key_data.name()}            : [{DJB_KEY_LEN} + 1][8]        """    hmac = f"""        hmac_final         (hmac_update`{{ {serialized_len} }} {serialized_data.name()}          (hmac_update`{{ {DJB_KEY_LEN}+1 }} ({receiver_identity_buf})           (hmac_update`{{ {DJB_KEY_LEN}+1 }} ({sender_identity_buf})            (hmac_init`{{ {mac_key_len} }} {mac_key_data.name()}))))        """    return cryptol(hmac)

Довольно сложно, неправдали? Ноещё раз нестарайтесь понять каждую строчку кода. Тут важно понять, что сначала вызывается hmac_init, затем выполняются несколько вызовов hmac_update, после чего осуществляется вызов hmac_finalcall. Это весьма близко интуитивным допущениям, сделанным ранее для HMAC, поэтому, если SAW убедится втом, что MAC выглядит как данное выражение Cryptol, можно быть уверенным, что онработает так, как ожидалось.

Далее нам нужно использовать это вспецификации. Вот выдержка изспецификации для signal_message_verify_mac, вкоторой впредусловиях описывается, как должно выглядеть валидное сообщение:

lass SignalMessageVerifyMacSpec(Contract):    serialized_len: int    def specification(self) -> None:        ...        mac_index = 8 + self.serialized_len - SIGNAL_MESSAGE_MAC_LENGTH        ser_len   = f"{self.serialized_len} : [64]"        self.points_to(serialized[0], cryptol(ser_len))        self.points_to(serialized[8], serialized_message_data)        self.points_to(serialized[mac_index], mk_hmac(...))        self.execute_func(...)        self.returns(cryptol("1 : [32]"))

Здесь serialized указывает наsignal_buffer для всего сообщения. Для описания памяти, содержащейся вразличных частях буфера, можно использовать нотацию слайса Python (например, serialized[0]). Первая часть содержит self.serialized_len, общую длину сообщения. Через восемь байтразмещается serialized_message_data данные сообщения. Всамом конце буфера содержится MAC, вычисленный спомощью mk_hmac(...).

Проверяем всё напрактике вызываем llvm_verify согласно этой спецификации. Вэтот раз нужно передать несколько дополнительных аргументов. Нужно явно указать, какие допущения мысделали ранее спомощью llvm_assume посредством аргумента lemmas. Также нужно указать инструменту решения SMT, какие функции должны рассматриваться как неинтерпретируемые. Это делается спомощью аргумента script:

uninterps = ["hmac_init", "hmac_update", "hmac_final"]llvm_verify(mod, "signal_message_verify_mac",  SignalMessageVerifyMacSpec(...),            lemmas=[init_spec, update_spec1, update_spec2, final_spec],            script=ProofScript([z3(uninterps)]))

В результате мы видим долгожданную зелёную галочку:

Планы

Спомощью saw-client мысмогли получить ряд интересных данных окоде вlibsignal-protocol-c. Мысмогли продемонстрировать, что signal_message_verify_mac, функция, проверяющая целостность сообщения, отправленного попротоколу Signal, работает правильно, если последняя часть сообщения содержит верный код аутентификации сообщения (MAC). Кроме того, мыопределили, каким должно быть содержимое MAC относительно абстрактной спецификации криптографических хэш-функций.

Однако спомощью инструмента saw-client можно сделать гораздо больше, чем рассказано вданной заметке. Мыпроверяли ключевое свойство кода, проверяющего целостность сообщений. Нотакая проверка целостности некасалась сообщений, передаваемых попроводам. Мытакже нестали полностью определять поведение HMAC, хотя это можно былобы сделать; смотрите здесь.

Несмотря нато что saw-client может использоваться как самостоятельный инструмент верификации, внекоторых аспектах saw-client недостигает функциональности SAWScript. saw-client внастоящее время неподдерживает ряд функций SAW, например функцию инициализации глобальных переменных вспецификациях. Кроме того, некоторые идиомы SAWScript реализованы вsaw-client нетак "красиво", пример квазикавычки ввыражениях Cryptol. Мысчитаем, что современем нам удастся решить эти проблемы.

Вперспективе мыпопытаемся сделать Python полноправным языком написания кода для SAW, иданная работа первый шаг вэтом направлении. Весь код, представленный вэтой заметке, можно найти здесь. Рекомендуем испытать вработе инструмент saw-client. Любые ваши пожелания икомментарии отправляйте в трекер проблем ивопросов SAW.

А если вам инетересен не только анализ программ с помощью Python, но и активная разработка на этом языке в направлениях как бекенда, так и фронтенда, то вы можете обратить внимание на наш курс "Fullstack-разработчик на Python", где также рассматривается тестирование ПО и многие другие аспекты профессии программиста.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод 5 разных библиотек Python, которые сэкономят ваше время

12.06.2021 18:20:44 | Автор: admin

В этой подборке, переводом которой мы решили поделиться к старту курса о машинном и глубоком обучении, по мнению автора, каждая библиотека заслуживает отдельной статьи. Всё начинается с самого начала: предлагается библиотека, которая сокращает шаблонный код импортирования; заканчивается статья пакетом удобной визуализации данных для исследовательского анализа. Автор также касается работы с картами Google, ускорения и упрощения работы с моделями ML и библиотеки, которая может повысить качество вашего проекта в области обработки естественного языка. Посвящённый подборке блокнот Jupyter вы найдёте в конце.


PyForest

Когда вы начинаете писать код для проекта, каков ваш первый шаг? Наверное, вы импортируете нужные библиотеки. Проблема в том, что заранее неизвестно, сколько библиотек нужно импортировать, пока они вам не понадобятся, то есть пока вы не получите ошибку.

Вот почему PyForest это одна из самых удобных библиотек, которые я знаю. С её помощью в ваш блокнот Jupyter можно импортировать более 40 популярнейших библиотек (Pandas, Matplotlib, Seaborn, Tensorflow, Sklearn, NLTK, XGBoost, Plotly, Keras, Numpy и другие) при помощи всего одной строки кода.

Выполните pip install pyforest. Для импорта библиотек в ваш блокнот введите команду from pyforest import *, и можно начинать. Чтобы узнать, какие библиотеки импортированы, выполните lazy_imports().

При этом с библиотеками удобно работать. Технически они импортируются только тогда, когда вы упоминаете их в коде. Если библиотека не упоминается, она не импортируется.

Emot

Эта библиотека может повысить качество вашего проекта по обработке естественного языка. Она преобразует эмотиконы в их описание. Представьте, например, что кто-то оставил в Твиттере сообщение I [здесь в оригинале эмодзи "красное сердце", новый редактор Хабра вырезает его] Python. Человек не написал слово люблю, вместо него вставив эмодзи. Если твит задействован в проекте, придётся удалить эмодзи, а значит, потерять часть информации.

Вот здесь и пригодится пакет emot, преобразующий эмодзи в слова. Для тех, кто не совсем понял, о чём речь, эмотиконы это способ выражения через символы. Например, :) означает улыбку, а :( выражает грусть. Как же работать с библиотекой?

Чтобы установить Emot, выполните команду pip install emot, а затем командой import emot импортируйте её в свой блокнот. Нужно решить, с чем вы хотите работать, то есть с эмотиконами или с эмодзи. В случае эмодзи код будет таким: emot.emoji(your_text). Посмотрим на emot в деле.

Выше видно предложение I [эмодзи "красное сердце"] Python, обёрнутое в метод Emot, чтобы разобраться со значениями. Код выводит словарь со значением, описанием и расположением символов. Как всегда, из словаря можно получить слайс и сосредоточиться на необходимой информации, например, если я напишу ans['mean'], вернётся только описание эмодзи.

Geemap

Говоря коротко, с её помощью можно интерактивно отображать данные Google Earth Engine. Наверное, вы знакомы с Google Earth Engine и всей его мощью, так почему не задействовать его в вашем проекте? За следующие несколько недель я хочу создать проект, раскрывающий всю функциональность пакета geemap, а ниже расскажу, как можно начать с ним работать.

Установите geemap командой pip install geemap из терминала, затем импортируйте в блокнот командой import geemap. Для демонстрации я создам интерактивную карту на основе folium:

import geemap.eefolium as geemapMap = geemap.Map(center=[40,-100], zoom=4)Map

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

Dabl

Позвольте мне рассказать об основах. Dabl создан, чтобы упростить работу с моделями ML для новичков. Чтобы установить её, выполните pip install dabl, импортируйте пакет командой import dabl и можно начинать. Выполните также строчку dabl.clean(data), чтобы получить информацию о признаках, например о том, есть ли какие-то бесполезные признаки. Она также показывает непрерывные, категориальные признаки и признаки с высокой кардинальностью.

Чтобы визуализировать конкретный признак, можно выполнить dabl.plot(data).

Наконец, одной строчкой кода вы можете создать несколько моделей вот так: dabl.AnyClassifier, или так: dabl.Simplefier(), как это делается в scikit-learn. Но на этом шаге придётся предпринять некоторые обычные шаги, такие как создание тренировочного и тестового набора данных, вызов, обучение модели и вывод её прогноза.

# Setting X and y variablesX, y = load_digits(return_X_y=True)# Splitting the dataset into train and test setsX_train, X_test, y_train, y_test = train_test_split(X, y, random_state=1)# Calling the modelsc = dabl.SimpleClassifier().fit(X_train, y_train)# Evaluating accuracy scoreprint(Accuracy score, sc.score(X_test, y_test))

Как видите, Dabl итеративно проходит через множество моделей, включая Dummy Classifier (фиктивный классификатор), GaussianNB (гауссовский наивный Байес), деревья решений различной глубины и логистическую регрессию. В конце библиотека показывает лучшую модель. Все модели отрабатывают примерно за 10 секунд. Круто, правда? Я решил протестировать последнюю модель при помощи scikit-learn, чтобы больше доверять результату:

Я получил точность 0,968 с обычным подходом к прогнозированию и 0,971 с помощью Dabl. Для меня это достаточно близко! Обратите внимание, что я не импортировал модель логистической регрессии из scikit-learn, поскольку это уже сделано через PyForest. Должен признаться, что предпочитаю LazyPredict, но Dabl стоит попробовать.

SweetViz

Это low-code библиотека, которая генерирует прекрасные визуализации, чтобы вывести ваш исследовательский анализ данных на новый уровень при помощи всего двух строк кода. Вывод библиотеки интерактивный файл HTML. Давайте посмотрим на неё в общем и целом. Установить её можно так: pip install sweetviz, а импортировать в блокнот строкой import sweetviz as sv. И вот пример кода:

my_report = sv.analyze(dataframe)my_report.show_html()

Вы видите это? Библиотека создаёт HTML-файл с исследовательским анализом данных на весь набор данных и разбивает его таким образом, что каждый признак вы можете проанализировать отдельно. Возможно также получить численные или категориальные ассоциации с другими признаками; малые, большие и часто встречающиеся значения. Также визуализация изменяется в зависимости от типа данных. При помощи SweetViz можно сделать так много, что я даже напишу о ней отдельный пост, а пока настоятельно рекомендую попробовать её.

Заключение

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

Этот материал не только даёт представление о полезных пакетах экосистемы Python, но и напоминает о широте и разнообразии проектов, в которых можно работать на этом языке. Python предельно лаконичен, он позволяет экономить время и в процессе написания кода, выражать идеи максимально быстро и эффективно, то есть беречь силы, чтобы придумывать новые подходы и решения задач, в том числе в области искусственного интеллекта, получить широкое и глубокое представление о котором вы можете на нашем курсе "Machine Learning и Deep Learning".

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Оптимизация при помощи линейного поиска на Python

13.06.2021 18:05:09 | Автор: admin

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


Прочитав это руководство, вы узнаете:

  • что линейный поиск это алгоритм оптимизации для одномерных и многомерных задач оптимизации;

  • что библиотека SciPy предоставляет API выполнения линейного поиска, который требует знания о том, как вычисляется первая производная вашей целевой функции;

  • как выполнить линейный поиск для целевой функции и работать с результатом.

Давайте начнём.

Обзор

Этот учебный материал разделён на три части:

  1. Что такое линейный поиск?

  2. Линейный поиск на Python.

  3. Как выполняется линейный поиск? Он состоит из:

a) определения целевой функции;

б) выполнения линейного поиска;

в) работы со сбоями алгоритма.

Что такое линейный поиск?

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

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

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

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

Алгоритмы оптимизации, 2019. С. 54.

Альфа коэффициент масштаба для направления, поэтому при поиске учитываются только значения в диапазоне от 0,0 до 1,0. Один шаг линейного поиска решает задачу минимизации, которая минимизирует целевую функцию для текущей позиции в сумме с масштабируемым направлением, то есть:

  • Минимизирует objective(position + alpha * direction).

Таким образом, линейный поиск работает в одном измерении за один раз и возвращает расстояние перемещения в выбранном направлении.

Каждая итерация метода линейного поиска вычисляет направление поиска pk, а затем решает, как далеко двигаться в этом направлении.

Численная оптимизация, 2006. С. 30.

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

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

Линейный поиск на Python

Выполнить линейный поиск на Python можно вручную, с помощью функции line_search(). Она поддерживает одномерную оптимизацию, а также многомерные задачи оптимизации. Эта функция принимает имя целевой функции и имя градиента для целевой функции, а также текущее положение в пространстве поиска и направление движения.

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

...result = line_search(objective, gradient, point, direction)

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

...# retrieve the alpha value found as part of the line searchalpha = result[0]

Альфа, начальная точка и направление могут использоваться при построении конечной точки линейного поиска.

...# construct the end point of a line searchend = point + alpha * direction

Для задач оптимизации с более чем одной входной переменной, например многомерной оптимизации, функция line_search() вернёт одно альфа-значение для всех измерений. Это значит, функция предполагает, что оптимум равноудалён от начальной точки во всех измерениях, такое ограничение существенно. Теперь, после ознакомления с тем, как в Python выполнять линейный поиск, давайте рассмотрим работающий пример.

Как выполняется линейный поиск?

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

Определение целевой функции

Во-первых, мы можем определить целевую функцию. Здесь поработаем с одномерной целевой функцией, а именно со сдвинутой на небольшую величину от нуля функцией x^2. Это выпуклая функция, она была выбрана потому, что её легко понять, а также легко вычислить первую производную.

  • objective(x) = (-5 + x)^2.

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

# objective functiondef objective(x):return (-5.0 + x)**2.0

Первая производная этой функции может быть вычислена аналитически следующим образом:

  • gradient(x) = 2 * (-5 + x).

Градиент для каждого входного значения просто указывает наклон к оптимумам в каждой точке. Реализация функции градиента приведена ниже:

# gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x)

Можно определить диапазон входных данных для x от -10 до 20 и вычислить целевое значение для каждого входного значения:

...# define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]

Затем, чтобы получить представление о форме функции, мы можем построить график входных значений в сравнении с целевыми значениями:

...# plot inputs vs objectivepyplot.plot(inputs, targets, '-', label='objective')pyplot.legend()pyplot.show()

Связав всё это воедино, получим такой код:

# plot a convex objective functionfrom numpy import arangefrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]# plot inputs vs objectivepyplot.plot(inputs, targets, '-', label='objective')pyplot.legend()pyplot.show()

Программа вычисляет входные значения (x) в диапазоне от -10 до 20 и создаёт график, показывающий знакомую U-образную форму параболы. Оптимум функции, по-видимому, находится в точке x=5,0, целевое значение 0,0.

Линейный график выпуклой целевой функцииЛинейный график выпуклой целевой функции

Выполнение линейного поиска

Затем можно выполнить линейный поиск по этой функции. Во-первых, мы должны определить отправную точку поиска и его направление. Здесь воспользуемся начальной точкой x=-5, расстояние от которой до оптимума около 10 единиц. Сделаем большой шаг вправо, в данном случае в 100 единиц (что значительно превышает оптимум), например, в положительном направлении. Напомним, что направление похоже на размер шага и поиск масштабирует размер шага, чтобы найти оптимум:

...# define the starting pointpoint = -5.0# define the direction to movedirection = 100.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)

Затем поиск ищет оптимумы и возвращает альфа или расстояние, чтобы изменить направление. Из результата мы можем получить значение альфа, а также количество выполненных вычислений функций:

...# summarize the resultalpha = result[0]print('Alpha: %.3f' % alpha)print('Function evaluations: %d' % result[1])

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

...# define objective function minima end = point + alpha * direction# evaluate objective function minimaprint('f(end) = %.3f' % objective(end))

Затем, для развлечения, мы можем снова построить график функции и показать начальную точку в виде зелёного квадрата, а конечную точку в виде красного квадрата.

...# define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]# plot inputs vs objectivepyplot.plot(inputs, targets, '--', label='objective')# plot start and end of the searchpyplot.plot([point], [objective(point)], 's', color='g')pyplot.plot([end], [objective(end)], 's', color='r')pyplot.legend()pyplot.show()

Ниже приведён полный пример выполнения линейного поиска для выпуклой целевой функции:

# perform a line search on a convex objective functionfrom numpy import arangefrom scipy.optimize import line_searchfrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define the starting pointpoint = -5.0# define the direction to movedirection = 100.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)# summarize the resultalpha = result[0]print('Alpha: %.3f' % alpha)print('Function evaluations: %d' % result[1])# define objective function minimaend = point + alpha * direction# evaluate objective function minimaprint('f(end) = f(%.3f) = %.3f' % (end, objective(end)))# define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]# plot inputs vs objectivepyplot.plot(inputs, targets, '--', label='objective')# plot start and end of the searchpyplot.plot([point], [objective(point)], 's', color='g')pyplot.plot([end], [objective(end)], 's', color='r')pyplot.legend()pyplot.show()

Программа-пример сначала сообщает начальную точку и направление. Поиск выполняется, и обнаруживается изменяющая направление для нахождения оптимума значение альфа, в данном случае найденное после трёх вычислений функции 0.1. Точка оптимума находится на отметке 5,0, значение y, как и ожидалось, равно 0,0:

start=-5.0, direction=100.0Alpha: 0.100Function evaluations: 3f(end) = f(5.000) = 0.000

Наконец, создаётся график функции, показывающий зелёную начальную точку и красную цель.

Линейный график целевой функции с оптимумами и начальной точкой поискаЛинейный график целевой функции с оптимумами и начальной точкой поиска

Работа со сбоями алгоритма

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

# perform a line search on a convex objective function with a direction that is too smallfrom numpy import arangefrom scipy.optimize import line_searchfrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define the starting pointpoint = -5.0# define the direction to movedirection = 3.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)# summarize the resultalpha = result[0]print('Alpha: %.3f' % alpha)# define objective function minimaend = point + alpha * direction# evaluate objective function minimaprint('f(end) = f(%.3f) = %.3f' % (end, objective(end)))

При выполнении примера поиск достигает предела альфа 1,0, что даёт конечную точку от -2 до 49. При f(5) = 0,0 от оптимумов очень далеко:

start=-5.0, direction=3.0Alpha: 1.000f(end) = f(-2.000) = 49.000

Кроме того, мы можем выбрать неправильное направление, ведущее только к вычислениям хуже стартовой точки. Здесь оно будет отрицательным в сторону от оптимума, например, вверх по склону от начальной точки:

...# define the starting pointpoint = -5.0# define the direction to movedirection = -3.0

Ожидается, что поиск не сойдётся, поскольку он не может найти какие-либо точки лучше начальной. Полный пример поиска, который не сходится, приведён ниже:

# perform a line search on a convex objective function that does not convergefrom numpy import arangefrom scipy.optimize import line_searchfrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define the starting pointpoint = -5.0# define the direction to movedirection = -3.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)# summarize the resultprint('Alpha: %s' % result[0])

Выполнение программы приводит к предупреждению LineSearchWarning, указывающему на то, что поиск, как и ожидалось, не может сойтись. Альфа возвращённое в результате поиска значение равно None:

start=-5.0, direction=-3.0LineSearchWarning: The line search algorithm did not convergewarn('The line search algorithm did not converge', LineSearchWarning)Alpha: None

Дальнейшее чтение

Если вы хотите глубже погрузиться в тему, смотрите этот раздел.

Книги

API

Статьи

Резюме

Из этого руководства вы узнали, как выполнить оптимизацию линейного поиска на Python. В частности, вы узнали:

  • что линейный поиск это алгоритм оптимизации для одномерных и многомерных задач оптимизации;

  • что библиотека SciPy предоставляет API выполнения линейного поиска, требующий знания о том, как вычисляется первая производная вашей целевой функции;

  • как выполнить линейный поиск для целевой функции и работать с его результатом.

Применяемые в машинном обучении методы оптимизации, конечно же, не ограничиваются одним лишь линейным поиском, они многочисленны, разнообразны и у каждого есть свои недостатки и преимущества. Если вы хотите погрузиться в машинное обучение, изучить оптимизацию глубже, но не хотите ограничивать себя областью ML, вы можете обратить внимание на наш курс "Machine Learning и Deep Learning", партнёр которого, компания NVIDIA, не нуждается в представлении.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Как Airbnb скрывает кошмары при помощи тайной команды чистильщиков

16.06.2021 18:22:08 | Автор: admin

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

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

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


Инцидент на 37-й улице

Квартира на первом этаже на 37-й Западной улице, в нескольких кварталах к югу от Таймс-сквер, была популярна среди туристов настолько, что ключи для арендаторов Airbnb оставляли на стойке соседнего винного магазина. Именно там 29-летняя австралийка и её друзья забрали их, не предъявляя никаких документов, когда приехали на Манхэттен провожать 2015 год. Квартира была размещена на Airbnb, несмотря на то, что краткосрочная аренда в Нью-Йорке в большинстве случаев вне закона. Город, подталкиваемый влиятельными профсоюзами отельеров, вёл войну с компанией, которая размещала тысячи объявлений о сдаче квартир в пяти районах, несмотря на одни из самых строгих законодательных предписаний об аренде в стране.

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

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

О происшествии немедленно известили кризис-менеджера Airbnb Ника Шапиро. Шла вторая неделя его работы в этой должности, куда он перешёл с поста заместителя начальника штаба ЦРУ и советника в Совете национальной безопасности в Белом доме Обамы. Я помню, как думал, что снова оказался в гуще событий. вспоминает он. Происшествие вернуло меня к ощущениям, которые я испытывал, сталкиваясь с действительно ужасными вещами в Лэнгли и в ситуационной комнате Белого дома.

Даже видавший некоторое де**мо Ник Шапиро был в шоке.Даже видавший некоторое де**мо Ник Шапиро был в шоке.

Шапиро, в свою очередь, уведомил других руководителей Airbnb, включая главного исполнительного директора Брайана Чески. Тем временем агенты из элитной команды компании по обеспечению доверия и безопасности начали действовать. Они переселили пострадавшую женщину в отель, оплатили перелёт ее матери из Австралии, доставили их обеих домой и предложили покрыть все расходы на лечение и консультации психолога.

Дубликаты ключей представляли собой особую проблему для компании и загадку для следователей. Откуда они у мужчины? У Airbnb нет правил, как хозяева (здесь и далее владельцы сдаваемых помещений) должны обмениваться ключами с гостями, и от ответа на этот вопрос зависела репутация компании в плане безопасности и, возможно, её юридическая ответственность. Шапиро (который на сегодня уже покинул компанию) помогал координировать расследование этого вопроса.

Тот самый дом на 37-й Западной улице.Тот самый дом на 37-й Западной улице.

Через неделю один из сотрудников был отправлен в суд, чтобы проверить, не упоминался ли Airbnb в ходе судебного разбирательства. Местные СМИ также не сообщали о преступлении, несмотря на ужасающие подробности, и компания хотела, чтобы СМИ и дальше молчали. Эта история осталась не освещённой до сих пор, в немалой степени потому, что через два года после нападения Airbnb выписал женщине чек на 7 млн. долларов это одна из самых больших выплат, которые когда-либо делала компания. В обмен на деньги она подписала соглашение не говорить об урегулировании или подразумевать уголовную ответственность или обязательства со стороны Airbnb или хозяина дома.

Подробности преступления, реакция компании и факт урегулирования были реконструированы из полицейских и судебных протоколов и конфиденциальных документов, а также из интервью с людьми, которые знакомы с этим делом. Женщина, имя которой было изменено в судебных документах и которая через своего адвоката попросила не называть её имени, отказалась от комментариев. Так же поступил и её адвокат. Бен Брейт, представитель Airbnb, говорил, что у компании нет полномочий скрывать информацию от СМИ и что, несмотря на формулировку мирового соглашения, женщина может обсуждать, считает ли она кого-либо ответственным. Он добавил, что целью Airbnb после инцидента была поддержка выжившей после ужасного нападения и что местные политические вопросы не имеют никакого отношения к её реакции.

Этот случай в Нью-Йорке произошёл во время ожесточённой борьбы с регуляторами, и реакция Airbnb на него показывает, насколько важна была команда безопасности для роста компании. Бизнес-модель Airbnb основана на идее, что незнакомые люди могут доверять друг другу. Если идея будет развенчана, это может означать уменьшение числа пользователей и увеличение количества судебных исков, не говоря уже об ужесточении регулирования.

При всей своей важности команда безопасности остаётся секретной. Инсайдеры называют её чёрным ящиком. Но восемь бывших членов команды и 45 других сотрудников Airbnb (нынешних и бывших), знакомых с ролью команды, дали редкую возможность взглянуть на её операции и внутренние проблемы. Большинство из этих людей говорили на условиях анонимности, опасаясь нарушить соглашения о конфиденциальности. По словам бывших членов команды, это очень нервная работа балансировать между часто противоречивыми интересами гостей, хозяев и компании. У меня были ситуации, когда я говорил с клиентом после инцидента, вешал трубку и плакал, вспоминает один из бывших агентов. Это всё, что я мог сделать.

Рождение секретной службы Airbnb

Airbnb была основана в 2008 году студентами-дизайнерами Брайаном Чески и Джо Геббиа вместе с инженером-программистом Натаном Блечарчиком. Из забавной альтернативы каучсёрфингу Airbnb выросла до одной из крупнейших гостиничных компаний в мире с 5,6 миллионами объявлений, а это больше, чем количество номеров в семи крупнейших гостиничных сетях, вместе взятых.

Светлые и прекрасные лица основателей Airbnb, слева направо: Джо Геббиа, Брайан Чески, Натан Блечарчик.Светлые и прекрасные лица основателей Airbnb, слева направо: Джо Геббиа, Брайан Чески, Натан Блечарчик.

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

Одним из первых привлечённых ими венчурных капиталистов Кремниевой долины был Крис Сакка, один из первых инвесторов Instagram, Twitter и Uber. Позже Сакка вспоминал, что после их презентации он отвёл их в сторону и сказал: Ребята, это очень опасно. Кого-то изнасилуют или убьют, и кровь будет на ваших руках. Деньги вкладывать он не стал.

С самого начала Airbnb поощряла незнакомых людей общаться в Интернете, а затем встречаться в реальной жизни, часто ночуя под одной крышей. Компания находится где-то между технологической платформой и гостиничным оператором она не может снять с себя ответственность за безопасность своих пользователей, как некоторые технологические компании (вспоминаем известное у нас Мы не такси, мы просто агрегатор прим. перев.), или предоставить охрану и другой персонал на месте, как гостиница. Доверие и безопасность в Airbnb сложнее, чем в Apple или Facebook, потому что вы имеете дело с реальными людьми в домах реальных людей, рассказывает Тара Банч, руководитель глобальных операций Airbnb.

На первых порах соучредители отвечали на все жалобы клиентов по своим мобильным телефонам. Когда это стало неуправляемым, они наняли вспомогательный персонал для полевых вызовов. Только через три года, когда было сделано более 2 млн. бронирований, компания столкнулась с первым серьёзным кризисом безопасности. В 2011 году одна из хозяек в Сан-Франциско написала в блоге о том, как, вернувшись из рабочей поездки, обнаружила, что её дом разграблен. Её гости испортили её одежду, сожгли её вещи и пробили дыру в запертой двери шкафа, чтобы украсть её паспорт, кредитные карты, ноутбук и жёсткие диски, а также драгоценности её бабушки.

В следующем посте хозяйка написала, что с ней связался соучредитель Airbnb и, вместо того чтобы предложить поддержку, попросил её удалить историю из блога, сказав, что это может повредить предстоящему раунду финансирования. Вскоре #RansackGate стал трендом в Твиттере, и этот инцидент превратился в краткий курс по управлению кризисом. Результат публичные извинения Чески, гарантия хозяевам на возмещение ущерба в размере 50 000 долларов (с тех пор она увеличена до 1 млн. долларов), круглосуточная горячая линия поддержки клиентов и новый отдел доверия и безопасности.

Брайан Чески смотрит на вас как на помеху в привлечении инвестиций.Брайан Чески смотрит на вас как на помеху в привлечении инвестиций.

По мере роста Airbnb росло и количество опасных инцидентов от выбрасывания хозяевами чемоданов из окон до установки скрытых камер, утечек газа и сексуальных посягательств.

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

К 2016 году команда безопасности была перегружена звонками, многие из которых были незначительными по своему характеру, и Airbnb начала обучать подрядчиков в колл-центрах по всему миру, чтобы они справлялись с потоком жалоб. Airbnb утверждает, что менее 0,1% случаев проживания приводят к возникновению проблем с безопасностью, но при более чем 200 млн. бронирований в год это всё равно очень много поездок с плохим концом. В службу внутренней безопасности передаются только самые серьёзные проблемы.

Эта команда состоит примерно из 100 агентов в Дублине, Монреале, Сингапуре и других городах. Некоторые из них имеют опыт работы в аварийно-спасательных службах или в армии. Члены команды имеют право на любые расходы, чтобы жертва почувствовала поддержку, включая оплату авиабилетов, проживания, питания, консультаций, медицинских расходов и анализов на заболевания, передающиеся половым путем, для тех, кто пережил изнасилование. Бывший агент, проработавший в Airbnb пять лет, описывает этот подход как стрельбу из денежной пушки. Команда переселяла гостей в гостиничные номера по цене, в 10 раз превышающей стоимость их бронирования, оплачивала кругосветные отпуска и даже подписывала чеки на сеансы психологической помощи собакам. Мы делаем всё возможное, чтобы обо всех, кто пострадал на нашей платформе, позаботились, рассказывает Тара Банч. Мы не беспокоимся о бренде и имидже. Эта штука позаботится о себе сама, пока вы поступаете правильно.

Тара Банч, руководитель глобальных операций Airbnb и секретной команды безопасности делает вид, что имидж ничто.Тара Банч, руководитель глобальных операций Airbnb и секретной команды безопасности делает вид, что имидж ничто.

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

Работа может быть настолько напряжённой, что агенты имеют доступ к комнатам с приглушённым освещением, чтобы создать успокаивающую атмосферу для ответов на тревожные звонки. И это может привести к тяжёлым потерям. Некоторые бывшие агенты говорят, что страдают от викарной (или заместительной) травмы. На работе они старались помнить, что всё происходящее в жизни может произойти и в Airbnb. Эту точку зрения вдалбливали новобранцам во время 12-недельных тренингов: точно так же, как ночные клубы не могут исключить сексуальные посягательства, а отели не могут остановить торговлю людьми, Airbnb не может помешать злоумышленникам использовать свою платформу.

В компании отказались комментировать условия расчётов или бюджет службы безопасности. Но из конфиденциального документа, с которым ознакомился Bloomberg Businessweek, следует, что в последние годы Airbnb тратила в среднем около 50 млн. долларов в год на выплаты хозяевам и гостям, в том числе на судебные разбирательства и возмещение ущерба, нанесённого жилью. (Компания утверждает, что большинство её выплат связано с ущербом имуществу по программе страхования хозяев и что шестизначные суммы выплат исключительная редкость.)

Бывшие агенты по безопасности также рассказывают о напряжённых отношениях с отделом доверия, чья работа заключается в разработке политики по предотвращению плохих вещей, будь то клопы, заряжённое оружие или похищения. Агенты по безопасности, которые наводят порядок только после происшествий, говорят, что чувствовали себя изгоями. Между отделами безопасности и продаж также существовала напряжённость из-за профессиональных хозяев, управляющих несколькими объектами недвижимости, удаление которых с платформы за нарушение правил безопасности могло стоить Airbnb сотен объявлений.

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

Представляем работу секретной команды Airbnb в российских реалиях.Представляем работу секретной команды Airbnb в российских реалиях.

Как и многие другие компании Кремниевой долины, Airbnb поднялась благодаря политике роста любой ценой: она проникала в города, обходя правила, побеждала в народном голосовании и набирала популярность так быстро, что к тому времени, когда чиновники замечали происходящее, у них уже не оставалось шансов контролировать ситуацию. По всему миру разгорелись нормативные битвы, самая токсичная из которых разыгралась в Нью-Йорке в 2015 году. Городские власти проводили операции по выявлению незаконной аренды жилья на срок менее 30 дней и обязали компанию предоставить адреса своих объявлений, что вызвало многолетнюю судебную тяжбу. Airbnb нанимала исследователей оппозиции, чтобы изучить биографии своих критиков, и оплачивала атаки на них в прессе.

Инцидент на 37-й улице. Расследование

В начале 2016 года, после нападения в районе Таймс-сквер, агенты по безопасности сделали то, чему их учили: обеспечили комфорт и помощь жертве. Но возможность судебного разбирательства повысила ставки. Крис Лихэйн, бывший политический консультант президента Билла Клинтона, был принят на работу в Airbnb в качестве главы отдела глобальной политики и коммуникаций за несколько месяцев до инцидента. Инсайдеры компании говорят, что Лихэйн, автор книги 2014 года Masters of Disaster о чёрном искусстве контроля репутационного ущерба, боялся, что этот случай может быть использован оппонентами для изгнания Airbnb из города.

Крис Лихэйн как бы намекает, что даже с супружеской изменой президента можно работать.Крис Лихэйн как бы намекает, что даже с супружеской изменой президента можно работать.

Проблема с ключами решалась нелегко. Такие схемы, как та, что использовал хозяин квартиры на 37-й Западной улице, распространены в экосистеме краткосрочной аренды магазин багажа по соседству со зданием рекламировал себя в Интернете как удобное место для получения ключей от сейфа Airbnb. Но такая практика может быть опасной, так как ключи проходят через неизвестное количество рук.

Уильям Делайно, много лет живущий в доме на 37-й Западной улице, вспоминает, что друзья этой женщины позвонили в его квартиру в тот вечер, не получив от неё ответа. В здании было довольно много квартир Airbnb, и я привык к подобным поступкам иностранных путешественников, говорит он. По его оценкам, в то время на Airbnb сдавались 4 из 12 квартир здания. Владеющая зданием компания Kano Real Estate Investors LLC отказалась от комментариев. Но после нападения, по словам жильцов, она внесла изменения в свои договоры аренды, запретив им размещать свои квартиры на Airbnb.

Детективам повезло, что предполагаемый насильник, Джуниор Ли, вернулся с ключами. Ему было предъявлено обвинение в хищническом сексуальном нападении, которое в штате Нью-Йорк предусматривает максимальное наказание в виде пожизненного заключения. Прокурор заявил судье, что 24-летний Ли закоренелый преступник, имеющий 40 судимостей за мелкие правонарушения. Ли не признал себя виновным, и залог был установлен в размере 250 000 долларов.

Компания Airbnb избежала упоминания в СМИ, в обвинительном заключении и даже в полицейском отчёте и жалобе, поданной прокурорами. В открытых источниках также нет информации о том, как Ли получил ключи. Его адвокат отказался комментировать это дело. Ли, признанный психически неполноценным, находится под стражей в ожидании дальнейшей экспертизы, но, даже если он предстанет перед судом, неясно, встанет ли вопрос о роли компании в этом деле и будет ли когда-нибудь раскрыта тайна ключей.

Потенциальная ответственность Airbnb за несоблюдение более строгой политики обмена ключей не будет проблемой благодаря урегулированию в размере 7 млн. долларов, которое было достигнуто после того, как адвокат пострадавшей женщины отправил письмо с угрозой судебного разбирательства. Хотя это соглашение не запрещает женщине сотрудничать с прокуратурой, оно не позволяет ей обвинять компанию или подавать на неё в суд. Это было особенно важно для Airbnb, потому что женщина не снимала квартиру и не подписывала соглашение об условиях предоставления услуг компании, состоящее из 10 000 слов еще один важный способ Airbnb не доводить инциденты от суда и не привлекать внимание общественности.

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

От сексуального насилия до убийства

То самое единственное дело, которое удалось довести до конца, было возбуждено в 2017 году, когда Лесли Лапайоукер, 51-летняя женщина, подала в суд на Airbnb после того, как якобы подверглась нападению со стороны хозяина в Лос-Анджелесе. Согласно судебным документам, Лапайоукер переезжала в город из Нью-Мексико и заказала 30-дневное проживание, пока искала постоянную квартиру. В иске говорится, что после того как она решила уехать из-за странного поведения хозяина, он последовал за ней в однокомнатную квартиру, которую она сняла, запер дверь, удерживал её на стуле против её воли, мастурбировал перед ней и кончил в мусорное ведро. Когда Лапайоукер убегала, согласно жалобе, хозяин сказал: Не забудьте оставить мне положительный отзыв на Airbnb. Мужчине, который заявил, что встреча произошла по обоюдному согласию, не было предъявлено никаких обвинений.

Фильм Американский психопат.Фильм Американский психопат.

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

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

Этот же адвокат урегулировала ещё одно дело о нападении, возбуждённое гражданкой США, изнасилованной в Индии родственником хозяина, который был выпущен под залог после обвинения в убийстве.

Аналогичный процесс произошёл, когда семья Карлы Стефаниак, женщины из Флориды, убитой во время празднования своего 36-летия в Коста-Рике в 2018 году, подала иск против компании в том же году. Разлагающиеся останки Стефаниак были обнаружены полузарытыми и завёрнутыми в пластик примерно в 300 метрах от её квартиры на Airbnb. Охранник комплекса, где она остановилась, был признан виновным в её убийстве. В иске утверждалось, что Airbnb не проверила биографию охранника, который работал в стране нелегально. Компания урегулировала дело за нераскрытую сумму.

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

Меньше знаешь крепче спишь?

Стремление Airbnb к секретности также затрудняет понимание того, какое влияние оказывает краткосрочная аренда на общую безопасность районов. Компания не публикует адреса объявлений, чтобы защитить безопасность и конфиденциальность своих пользователей. И, хотя некоторые города США требуют от хозяев вносить свои квартиры в реестры краткосрочной аренды, большинство из них не публикуют эти данные, ссылаясь на те же соображения конфиденциальности. Те, кто это делает, часто не раскрывают номера квартир, что делает практически невозможной проверку многих адресов по звонкам полиции или записям об арестах. Реестры также не включают квартиры, арендуемые незаконно.

Журналисты Bloomberg получил реестры для Остина, Майами-Бич и Лос-Анджелеса через запросы на публичные документы, попытались сопоставить их с публичными базами данных полицейских вызовов или преступлений. За последние два года полиция отреагировала на тысячи инцидентов, связанных с краткосрочной арендой жилья в этих трёх городах. В Майами-Бич реестр показал 1071 вызов полиции по адресам, указанным в 2019 году, включая 40 случаев насильственных преступлений. Однако в полицейских отчётах не указывается, на какой платформе находилась квартира и сдавалась ли она в аренду в тот момент, что затрудняет получение полезных выводов о взаимосвязи между индустрией краткосрочной аренды и преступностью. Научные исследователи говорят, что аналогичные ограничения помешали их усилиям изучить эту связь. Было проведено всего около полудюжины научных исследований по этому вопросу, и их результаты противоречивы.

Поскольку города и полиция не в состоянии собрать данные, а дела редко доходят до суда, громкие инциденты, как правило, определяют политические дискуссии вокруг краткосрочной аренды. Помня об этом, с 2018 года Airbnb передаёт подобные инциденты в свою глобальную группу кризисного управления, которая была сформирована Лихэйном и другими руководителями и первоначально возглавлялась Шапиро, бывшим сотрудником ЦРУ.

В 2018 и 2019 годах произошло несколько смертельных инцидентов, помимо убийства Стефаниак, когда компания готовилась к первичному размещению акций. Один из них произошёл в ноябре 2018 года, когда пара пенсионеров из Нового Орлеана умерла в Мексике, надышавшись токсичными испарениями, когда они спали в арендованной квартире Airbnb. После этого их сын выступил по телевидению, умоляя Airbnb сделать больше для защиты своих пользователей.

Брайан Чески как бы намекает, что устал от таких инцидентов.Брайан Чески как бы намекает, что устал от таких инцидентов.

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

Но трагедии продолжали происходить. В мае того же года шесть бразильских туристов, двое из которых были детьми, погибли от отравления угарным газом в арендованной квартире Airbnb в Сантьяго, Чили. Родственник погибших перед их смертью позвонил в компанию, но ответ задержался, потому что никто в колл-центре не говорил по-португальски. По словам бывших сотрудников, Чески был в ярости.

Кровавая хэллоуинская вечеринка

В Хэллоуин Airbnb столкнулась с одним из самых смертоносных инцидентов: перестрелка в доме с четырьмя спальнями стоимостью 1,2 млн. долларов в Оринде, штат Калифорния, примерно в 32 км к востоку от Сан-Франциско. Дом, на который было подано множество жалоб в полицию и городские власти, был забронирован на одну ночь. Гость, о котором Airbnb уже сообщили, что за несколько дней до этого он оставил пулю в другом арендованном доме, что было зафиксировано внутри компании, затем дал объявление о вечеринке в особняке в социальных сетях. На вечеринке было более 100 человек, когда гость-стрелок открыл огонь, убив пятерых.

Полиция расследует стрельбу в Оринде.Полиция расследует стрельбу в Оринде.

Чески выразил свои соболезнования в Твиттере и объявил о новых мерах безопасности, включая запрет на дома для вечеринок и обещание проверять фотографии, удобства, чистоту и безопасность всех объявлений на Airbnb. Но компания не связывалась с матерью одной из жертв, 23-летнего Реймона Хилла, в течение недели, пока её адвокат, Джесси Данофф, не написал письмо и не выступил с заявлением, в котором раскритиковал Airbnb за то, что компания предоставляет лишь молитвы. Даже некоторые из собственных агентов компании по безопасности были расстроены. Они говорят, что дома для вечеринок были проблемой на протяжении многих лет.

Дом в Оринде, где были застрелены пять человек.Дом в Оринде, где были застрелены пять человек.

Впоследствии Airbnb предложила оплатить похороны, но Данофф рассказывает, что, когда некоторые из семей прислали счета на сумму более 30 тыс. долларов, компания начала торговаться. Им уже всё равно, потому что новостной цикл пошёл дальше, рассказывает Данофф. Единственное, что их действительно мотивирует, это угроза или потенциальная угроза плохого пиара или кошмара в прессе. (Airbnb утверждает, что оплатила счета. Данофф говорит, что он всё ещё ведёт переговоры об урегулировании.)Они должны ответить за то, что произошло, говорит об Airbnb мать Хилла, Синтия Тейлор. У моего сына отняли жизнь в доме, который они разрешили продолжать сдавать в аренду на своём сервисе после многочисленных жалоб.

Синтия Тейлор со своим сыномСинтия Тейлор со своим сыном

В декабре того же года Airbnb объявила о выделении 150 млн. долларов на дополнительные расходы, связанные с доверием и безопасностью. Компания ввела круглосуточную горячую линию, которая предоставляет арендаторам немедленный доступ к агенту по безопасности; создала систему, чтобы отмечать бронирования с высоким риском; запретила пользователям моложе 25 лет и не имеющим истории положительных отзывов бронировать Airbnb в районе, где они живут; и перестала разрешать останавливаться на одну ночь на Хэллоуин, 4 июля и Новый год. Многие из этих мер были введены в США их внедрение по всему миру оказалось непростой задачей, учитывая различия в культуре, обычаях и правилах в 191 стране, где работает Airbnb. Компания также обсуждала вопрос о том, нужно ли заставлять пользователей предоставлять удостоверения личности государственного образца, но решила не делать этого, чтобы не исключить хозяев и гостей в странах, где удостоверение личности трудно получить.

Последствия

В начале 2020 года разразилась пандемия, которая свела на нет все путешествия, так как страны закрыли границы, и мир оказался под замком. Airbnb потерял 80 % своего бизнеса за восемь недель. Команда по безопасности была завалена звонками по поводу инфекции. Что ещё хуже, профессиональные организаторы вечеринок начали превращать арендуемые Airbnb квартиры и дома в ночные клубы. Сотни пьяных гуляк без масок разгуливали по пригородам США, напрягая ресурсы полиции, приводя в ярость чиновников здравоохранения и перегружая команду безопасности.

В мае прошлого года Чески плакал в веб-камеру во время общекорпоративного собрания, на котором он объявил о сокращении 25% персонала. Увольнения были ожидаемы, но для многих было шоком то, что вся команда безопасности в Портленде, штат Орегон, была уволена, включая 25 самых опытных агентов компании. Некоторым сказали, что они смогут сохранить работу, если пойдут на сокращение зарплаты и переедут в Монреаль, куда Airbnb переводит свои североамериканские подразделения безопасности, привлеченные выгодными налоговыми льготами и более низкими затратами на недвижимость и рабочую силу.

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

Из эпизода Южный парк Енот 2: Непредусмотрительность, в котором CEO BP в издевательской манере просит прощения за аварию в Мексиканском заливеИз эпизода Южный парк Енот 2: Непредусмотрительность, в котором CEO BP в издевательской манере просит прощения за аварию в Мексиканском заливе

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

Крис Сакка, инвестор, который 13 лет назад отверг стартап, поздравил его в Твиттере. Я позволил худшему варианту помешать мне увидеть вероятный вариант, написал он. На каждой платформе есть плохие игроки, но большинство людей хорошие люди. Они это знали. Я не слушал.

Airbnb всё ещё приходится сталкиваться с кризисами безопасности, реагировать на нападения и бороться с регуляторами. 31 мая в рамках соглашения об урегулировании судебного процесса с Нью-Йорком компания начала передавать информацию о своих хозяевах, включая имена, адреса и информацию о том, сдают ли они всю квартиру. Эти данные облегчат отслеживание незаконных объявлений.

Спустя более пяти лет после нападения на 37-й Западной улице Airbnb всё ещё не установила чётких правил относительно ключей. Этот случай положил начало многолетним внутренним дебатам о бесключевом доступе. Если бы хозяев можно было заставить пользоваться цифровыми клавиатурами и менять код после каждого пребывания, то в будущем можно было бы избежать подобных ситуаций. Даже требование раскрывать информацию о том, есть ли у них вход с клавиатуры, может изменить ситуацию. Шапиро, бывший глава антикризисного управления, вспоминает, как настаивал на том, чтобы исключить обмен ключами. Я помню, как пытался поговорить о процессе обмена ключами и способах предотвращения того, чтобы хозяева оставляли их в магазинах, говорит он.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Clustergram визуализация кластерного анализа на Python

28.05.2021 14:21:34 | Автор: admin

В этой статье, переводом которой мы решили поделиться специально к старту курса о Data Science, автор представляет новый пакет Python для генерации кластерограмм из решений кластеризации. Библиотека была разработана в рамках исследовательского проекта Urban Grammar и совместима со scikit-learn и библиотеками с поддержкой GPU, такими как cuML или cuDF в рамках RAPIDS.AI.


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

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

Маттиас Шонлау предложил другой подход кластерограмму. Кластерограмма это двухмерный график, отражающий потоки наблюдений между классами по мере добавления кластеров. Это говорит вам о том, как перетасовываются ваши данные и насколько хороши ваши сплиты. Тал Галили позже реализовал кластерограмму для k-средних в R. Я использовал реализацию Таля, перенёс ее на Python и создал clustergram пакет Python для создания кластерограмм.

clustergram в настоящее время поддерживает метод k-средних, использование scikit-learn (включая реализацию Mini-Batch) и RAPIDS.AI cuML (если у вас есть GPU с поддержкой CUDA), Gaussian Mixture Model (только scikit-learn) и иерархическую кластеризацию на основе scipy.hierarchy. В качестве альтернативы мы можем создать кластерограмму на основе меток и данных, полученных с помощью альтернативных пользовательских алгоритмов кластеризации. Пакет предоставляет API, подобный sklearn, и строит кластерные диаграммы с помощью matplotlib, что даёт ему широкий выбор вариантов оформления в соответствии со стилем вашей публикации.

Установка

Установить clustergram можно при помощи conda или pip:

conda install clustergram -c conda-forge

или

pip install clustergram

В любом случае вам нужно установить выбранный бэкенд (scikit-learn и scipy или cuML).

from clustergram import Clustergramimport urbangrammar_graphics as uggimport seaborn as snsimport matplotlib.pyplot as pltfrom sklearn.preprocessing import scalesns.set(style='whitegrid')

Давайте рассмотрим несколько примеров, чтобы понять, как выглядит кластерограмма и что с ней делать.

Набор данных о цветке ириса

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

iris = sns.load_dataset("iris")g = sns.pairplot(iris, hue="species", palette=ugg.COLORS[1:4])g.fig.suptitle("Iris flowers", y=1.01)

Похоже, что setosa относительно чётко определённая группа, тогда как разница между versicolor и virginica меньше, поскольку они частично перекрываются (или, в случае ширины чашелистика, полностью).

Итак, мы знаем, как выглядят данные. Теперь мы можем увидеть кластерограмму. Помните, мы знаем, что существует три кластера, и в идеале мы должны быть в состоянии распознать это по кластерограмме. Я говорю в идеале, потому что, даже если есть известные метки, это не значит, что наши данные или метод кластеризации способны различать эти классы.

Давайте начнём с кластеризации методом k-средних. Чтобы получить стабильный результат, мы можем запустить кластерную программу с 1000 инициализаций.

data = scale(iris.drop(columns=['species']))cgram = Clustergram(range(1, 10), n_init=1000)cgram.fit(data)ax = cgram.plot(    figsize=(10, 8),    line_style=dict(color=ugg.COLORS[1]),    cluster_style={"color": ugg.COLORS[2]},)ax.yaxis.grid(False)sns.despine(offset=10)ax.set_title('K-Means (scikit-learn)')

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

Мы ищем разделение, т. е. отвечаем на вопрос, принёс ли дополнительный кластер какое-либо значимое разделение? Шаг от одного кластера к двум большой хорошее и чёткое разделение. От двух до трёх свидетельство довольно хорошего раскола в верхней ветви. Но с 3 по 4 видимой разницы нет, потому что новый четвёртый кластер почти не отличается от существующей нижней ветви. Хотя сейчас она разделена на две части, это разделение не даёт нам много информации. Таким образом, можно сделать вывод, что идеальное количество кластеров для данных Iris три.

Мы также можем проверить некоторую дополнительную информацию, например оценку силуэта или оценку Калинского Харабазса.

fig, axs = plt.subplots(2, figsize=(10, 10), sharex=True)cgram.silhouette_score().plot(    xlabel="Number of clusters (k)",    ylabel="Silhouette score",    color=ugg.COLORS[1],    ax=axs[0],)cgram.calinski_harabasz_score().plot(    xlabel="Number of clusters (k)",    ylabel="Calinski-Harabasz score",    color=ugg.COLORS[1],    ax=axs[1],)sns.despine(offset=10)

По этим графикам можно предположить наличие 34 кластеров по аналогии с кластерограммой, но они не очень убедительны.

Набор данных о пингвинах со станции Палмера

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

penguins = sns.load_dataset("penguins")g = sns.pairplot(penguins, hue="species", palette=ugg.COLORS[3:])g.fig.suptitle("Palmer penguins", y=1.01)

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

data = scale(penguins.drop(columns=['species', 'island', 'sex']).dropna())cgram = Clustergram(range(1, 10), n_init=1000)cgram.fit(data)ax = cgram.plot(    figsize=(10, 8),    line_style=dict(color=ugg.COLORS[1]),    cluster_style={"color": ugg.COLORS[2]},)ax.yaxis.grid(False)sns.despine(offset=10)ax.set_title("K-Means (scikit-learn)")

Мы ищем разделения, и эта кластерограмма показывает достаточное их количество. На самом деле определить оптимальное количество кластеров довольно сложно. Однако, поскольку мы знаем, что происходит между различными вариантами, мы можем поиграть с этим. Если у нас есть причина быть консервативными, мы можем обойтись 4 кластерами (я знаю, это уже больше, чем первоначальный вид). Но и дальнейшее разделение также разумно, а это указывает на то, что даже более высокая детализация может дать полезную информацию, что могут существовать значимые группы.

Можно ли сказать, что их три? Поскольку мы знаем, что их должно быть три... Ну, не совсем. Разница между разделениями 23 и 34 незначительна. Однако здесь виновником является метод K ближайших соседей, а не кластерограмма. Он просто не может правильно кластеризовать эти данные из-за наложений и общей структуры. Давайте посмотрим, как работает смешанная Гауссова модель (Gaussian Mixture).

cgram = Clustergram(range(1, 10), n_init=100, method="gmm")cgram.fit(data)ax = cgram.plot(    figsize=(10, 8),    line_style=dict(color=ugg.COLORS[1]),    cluster_style={"color": ugg.COLORS[2]},)ax.yaxis.grid(False)sns.despine(offset=10)ax.set_title("Gaussian Mixture Model (scikit-learn)")

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

Подобная ситуация случается очень часто. Идеального случая не существует. В конечном счёте нам необходимо принять решение об оптимальном количестве кластеров. Clustergam даёт нам дополнительные сведения о том, что происходит между различными вариантами, как они расходятся. Можно сказать, что вариант с четырьмя кластерами в данных Iris не помогает. Также можно сказать, что пингвины Палмера могут быть сложными для кластеризации с помощью k-средних, что нет решающего правильного решения. Кластерограмма не даёт простого ответа, но она даёт нам лучшее понимание, и только от нас зависит, как мы её [кластерограмму] интерпретируем.

Установить clustergram можно с помощью conda install clustergram -c conda-forge или pip install clustergram. В любом случае вам всё равно придётся установить бэкенд кластеризации: либо scikit-learn, либо cuML. Документация доступна здесь, а исходный код здесь, он выпущен под лицензией MIT.

Если вы хотите поиграть с примерами из этой статьи, блокнот Jupyter находится на GitHub. Вы также можете запустить его в среде interactive binder в браузере. Более подробную информацию можно найти в блоге Тала Галили и оригинальных статьях Матиаса Шонлау.

Вполне понятно, что идеальной кластеризации не существует. И даже сегодня, с учётом всего прогресса искусственного интеллекта, для принятия сложных решений о данных по-прежнему нужен человек. Если вам интересна наука о данных область, в которой такие решения принимаются постоянно вы можете обратить внимание на наш курс о Data Science, где через подкреплённую теорией практику студенты учатся ориентироваться в данных, делать обоснованные выводы и действовать с открытыми глазами.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Как StarCraft II может помочь экологам в изучении жизни на Земле

30.05.2021 18:13:46 | Автор: admin

Вряд ли Лу Барбе осмелится назвать себя заядлым геймером. Он занимается проблемами экологии в Университете Ренна во Франции, проводя большую часть времени среди растений. Но одна игра с самого детства захватила его воображение: StarCraft популярная онлайн-стратегия, в которой игроки накапливают ресурсы и создают армии инопланетных бойцов для ведения войн на внеземных территориях. "Игрок из меня никакой, говорит Барбе, но я понимаю, что происходит в игре".


Несколько лет назад, играя в StarCraft II (последнюю версию игры), Барбе понял, что помимо всех взрывов и лазерных ударов в игре происходит что-то ещё. Он обратил внимание, что события в StarCraft развиваются точно так же, как развивается любая экосистема."В игре имеется среда, говорит Барбе. В игре имеются ресурсы и организмы, конкурирующие друг с другом в этой среде. Всё это очень хорошо подходит под определение экосистемы".

На этом идея Барбе пока и ограничилась. Но в 2019 году DeepMind, дочерняя компания Google Alphabet по исследованию ИИ, выставила интеллектуального агента под названием AlphaStar против лучших в мире игроков в StarCraft II. AlphaStar превзошёл в мастерстве 99,8% геймеров-людей, получив заветное звание гроссмейстера высший ранг в игре и дополнив тем самым список побед ИИ над людьми.

После этого Барбе пришло в голову, что способности AlphaStar могут не ограничиваться управлением действиями инопланетян на выдуманной планете. Если StarCraft функционирует подобно экосистеме, возможно, игровые алгоритмы могли бы помочь исследователям в изучении экологических проблем Земли?

В статье, опубликованной в журнале Trends in Ecology and Evolution в 2020 году, Барбе вместе с другими экологами из Реннского университета и Университета Бригама Янга объясняет, как способность AlphaStar управлять сложной многомерной динамикой StarCraft может применяться для проверки идей о динамике развития экосистем в реальном мире с решением этой задачи традиционные модели пока справиться не могут.

Например, исследователи могут запускать агентов AlphaStar на картах StarCraft, созданных для имитации реалистичного распределения ресурсов, и создавать модели, на базе которых можно получить представление, как различные организмы реагируют на такие отклонения, как возникновение инвазивных чужеродных видов или уничтожение среды обитания.

Алгоритм AlphaStar, говорит Барбе, возможно, непреднамеренно стал самой сложной экологической моделью из всех существующих.

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

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

"Сложность [большинства] экологических моделей ничтожно мала по сравнению со сложностью некоторых систем искусственного интеллекта, утверждает Бен Эббот, эколог из Университета Бригама Янга и соавтор статьи об AlphaStar. То, что умеем мы, экологи, не идёт ни в какое сравнение с тем, что умеют эти алгоритмы.

Как создавался чемпион

Для исследователей ИИ игра StarCraft II, вышедшая в 2010 году, стала сложным интеллектуальным вызовом. Так же как в шахматах или го, игроки StarCraft управляют различными отрядами, чтобы нападать на противников, но здесь игроки тоже выбирают, где и когда собирать ресурсы, когда создавать новые отряды, какие именно отряды создавать и тому подобное, и всё это в окружении множества посторонних факторов. В шахматах в одной позиции у игрока есть выбор из примерно 35 возможных ходов, в игре Go из 200250. Но в StarCraft II возможных ходов в одной позиции 1026. Кроме того, в отличие от игр, называемых теоретиками игр играми с "полной информацией", где все игроки могут видеть полное игровое пространство, события в StarCraft происходят на огромной карте, которую геймеры могут видеть лишь частично.

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

Чтобы натренировать алгоритм AlphaStar и создать ИИ, который способен брать верх над лучшими игроками в StarCraft II, исследователи DeepMind использовали методы машинного обучения. Они начали с того, что создали лигу интеллектуальных агентов, обученных на основе данных сотен тысяч матчей StarCraft, проведённых между людьми. Затем они заставили членов лиги виртуальных агентов играть друг против друга, отобрали самых сильных из них, внесли в них определённые коррективы и отправили обратно в лигу. Они повторяли этот процесс до тех пор, пока не придали AlphaStar силу джаггернаута, крушащего всё на своём пути. Ориол Виньялс, возглавлявший команду DeepMind создателя AlphaStar, сравнил саму лигу с некой экосистемой, в которой работает процесс естественного отбора. "Создавая лигу AlphaStar, мы черпали вдохновение из литературы об эволюции", рассказывает он.

Поведение медленно растущих терранов, одной из трёх инопланетных рас в StarCraft II, в экосистеме игры один в один напоминает поведение кактусов.Поведение медленно растущих терранов, одной из трёх инопланетных рас в StarCraft II, в экосистеме игры один в один напоминает поведение кактусов.

"Традиционные" исследователи ИИ черпали вдохновение в природе, Барбе же и его коллеги-экологи стали черпать вдохновение в игре. В своей работе, опубликованной в 2020 году, они подробно описывают глубокие параллели между расами терранов, протоссов и зергов в StarCraft, и конкурентными стратегиями, характерными для определённых видов организмов.

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

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

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

"Возникает весьма интересная игрушечная модель вы наблюдаете за очень упрощённой системой и можете задавать очень конкретные вопросы, говорит Энн Тессен, специалист по работе с данными из Университета штата Орегон, не имеющий отношения к работе по экологическому смыслу StarCraft. Просто нужно помнить, что вы имеете дело с моделью".

Модные технологии

Надо признать, что StarCraft II при всей своей сложности намного проще реальной экосистемы. Барбе отмечает, что в игре никак не отражены базовые природные процессы, например азотный цикл, а также никак не затрагиваются ключевые отношения между организмами, например паразитизм. К тому же в мире StarCraft II всего три вида существ.

"Проблема, на мой взгляд, заключается в том, что игровая механика, призванная быть как можно более развлекательной, лишь частично отражает реальный физический мир", считает Вернер Раммер, эколог из Технического университета Мюнхена. Раммер утверждает, что делать выводы о способностях AlphaStar вне рамок StarCraft, лишь наблюдая за его игрой, какой бы сложной и замысловатой она ни была, преждевременно.

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

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

Однако ИИ в экологии используется всё ещё недостаточно активно, полагает Николя Лекомт, сотрудник Канадской кафедры полярной и бореальной экологии и эколог Университета Монктона в Канаде, который использует инструменты ИИ для классификации звуков арктических птиц и прогнозирования их миграции.

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

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

Такие компании, как Blizzard, создавшая StarCraft, ежегодно тратят сотни миллионов долларов на разработку алгоритмов для своих игр, говорит он. У них просто гораздо больше ресурсов, чем у нас. Но мы, конечно же, считаем, что наши проблемы гораздо важнее их проблем". Хоть это и была шутка, но в ней кроется чистая правда, в конце концов, жизнь на Земле это далеко не игра.

Машинное обучение и искусственный интеллект продолжают всё глубже проникать в самые разные сферы знаний, находя для этого всё более неочевидные и нестандартные пути. Если вам интересны новые подходы к машинному и глубокому обучению, разнообразные эксперименты с моделями, а также лежащие в основе моделей алгоритмы, вы можете обратить внимание на курс "Machine Learning и Deep Learning", партнёром которого является компания NVIDIA.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Реальная история легендарной денежной ямы Острова Оук

05.06.2021 18:10:05 | Автор: admin

Золото тамплиеров, пиратское хранилище, природная карстовая воронка или один гигантский обман? Проклятие острова Оук рассказывает нам, что семь человек должны умирать до того, как остров раскроет своё легендарное сокровище. Шесть человек погибли в поисках миллиардов в золоте, но опасность только подогревает исследования и спекуляции.

Разочаровывающий, увлекательный, манящий вы можете поставить любое прилагательное перед словами остров Оук, и будете правы, рассказывает Чарльз Баркхаус, историк шоу канала History Channel The Curse of Oak Island, в котором на протяжении восьми сезонов (с некоторыми результатами) рассказывается о продолжающихся поисках сокровищ.


Если вы не готовы к эмоциональной нагрузке, то можете собирать свои игрушки и уходить.

Охота за сокровищами денежной ямой острова Оук, то есть яма в 100 футов (около 30 с половиной метров) на острове в Новой Шотландии, где якобы хранится что угодно от пиратских сокровищ до Ковчега Завета, началась ещё в 1795 году. Хотя сокровища так и не были найдены, сопутствующие открытия очевидные подсказки, возможные ловушки и геологические диковинки заставляют искателей продолжать поиски, даже когда историки оспаривают более сенсационные заявления, связанные с кладом. Был ли остров Оук сокровищницей рыцарей-тамплиеров, секретным промышленным центром Британии или злополучной природной воронкой? Чтобы ответить на этот вопрос, конечно же, нужно копать.

Поиски начинаются

Остров Оук впервые привлёк к себе внимание вскоре после золотого века пиратства (примерно в 16501730 годах), когда Эдвард Лоу и Бартоло Мью Робертс патрулировали моря к северо-востоку от Америки. В 1795 году подросток из Новой Шотландии со своего дома на материке увидел парящие над островом странные огни.

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

Мальчики начали выкапывать то, что впоследствии стали называть денежной ямой. На глубине двух футов (60 сантиметров) они обнаружили круг из камней, окаймляющих окружность ямы, а на глубине 10 футов (3 метров) платформу из подогнанных в стенки ямы обрезков брёвен. Вторая платформа лежала на 20 футов (около 6 метров) ниже, но на этом рассказ о первом поиске заканчивается.

История возобновляется в начале 1800-х годов, когда компания Онслоу отправилась в первую официальную экспедицию для раскопок. Они продолжили раскопки с того места, где остановились в первый раз, обнаружив новые платформы через каждые 10 футов (около 3 метров) (приблизительно три метра), иногда со слоями замазки, древесного угля или кокосовых волокон. Кокосы не растут в радиусе 900 миль (приблизительно полтора километра) от Новой Шотландии, но в истории утверждается, что экипаж сделал ещё более грандиозное открытие на высоте 90 футов (более 27 метров): прямоугольный камень, исписанный странными знаками.

Остров Оук. Пиковая высота острова Оук составляет всего 36 футов (почти 11 метров) над уровнем моря. Архивы Новой ШотландииОстров Оук. Пиковая высота острова Оук составляет всего 36 футов (почти 11 метров) над уровнем моря. Архивы Новой Шотландии

Исследователи и охотники за сокровищами сочли, что эти отметки были сделаны по ошибке инструментами экскаватора, но другие были уверены, что это секретный код, ведущий к зарытым сокровищам. В 1860-х годах профессор лингвистики из университета Далхаузи в Новой Шотландии изучил камень и определил, что код представляет собой подстановочный шифр: Сорок футов [кооло 12 метров] ниже погребены два миллиона фунтов. Но другая попытка перевода в 1970-х годах интерпретировала код как христианское предупреждение коптов не забывать о своём долге перед Господом.

Компания Онслоу продолжала копать, и на глубине 98 футов (кооло 30 метров) они обнаружили нечто, по звуку удара напоминавшее полый контейнер предположительно, хранилище сокровищ. Бригада прекратила работу на вечер, но когда они вернулись на следующее утро, то обнаружили, что котлован заполнен водой на 60 футов (около 18 метров). Предполагалось, что раскопки привели к срабатыванию мины-ловушки. И похоже, что наводнение, похоже, положило конец усилиям Онслоу; в 1805 году компания была распущена.

Удар проклятия

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

Ничуть не смутившись, люди подумали, что нашли затопленный тоннель, соединявший яму и рукотворную бухту Смита примерно на 500 футов (около 150 метров) к востоку от площадки, где они копали.

Остров Оук. К моменту съёмки в 1947 году охота унесла две жизни. Архивы Новой Шотландии.Остров Оук. К моменту съёмки в 1947 году охота унесла две жизни. Архивы Новой Шотландии.

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

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

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

Не дали прорыва и современные технологии. Съёмочная группа 1971 года привезла камеры и монитор, чтобы исследовать примерно 235-футовую (чуть менее 72 метров) шахту (называемую скважиной 10X и находящуюся примерно в 180 футах (около 55 метров) от денежной ямы), и хотя они утверждали, что во время исследования на дне ямы был обнаружен деревянный сундук и отрубленная человеческая рука, этот инцидент так и не был зарегистрирован.

Рик и Марти Лагина, входящие в группу владельцев острова Оук, ведут сериал на канале History Channel.Рик и Марти Лагина, входящие в группу владельцев острова Оук, ведут сериал на канале History Channel.

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

Несмотря на это, рассказывает Баркхаус, количество доказательств, которые мы находим [на острове Оук], заставляет вас поверить, что какая-то группа или какой-то человек сделали там нечто особенное.

Дыры в поиске

Остров Оук иногда называют островом мистификации из-за отсутствия свидетельств очевидцев. До начала 1860-х годов нет прямых свидетельств, подтверждающих какие-либо раскопки на острове Оук, когда были зарегистрированы первые две экспедиции мальчиков из Новой Шотландии и компании Онслоу. Большинство других рассказов XIX века об острове Оук это воспоминания людей, утверждавших, что они участвовали в раскопках.

Есть другие пробелы: многие считают, что звенья золотой цепи от группы 1849 года были подброшены самой группой для поощрения будущих экспедиций, а камень с надписью, найденный в начале 1800-х годов, был зарегистрирован как найденный только в 1862 году. Этот камень вообще не упоминался в инвестиционном проспекте компании Oak Island Treasure Company за 1893 год: ни сам камень, ни его маркировка не были зарисованы или сфотографированы, а существующее сегодня изображение камня датируется 1949 годом. Именно с этого времени начинаются современные переводы.

Остров Оук. Ведущая на материк дамба позволяет искателям сокровищ доставлять на остров Оук тяжёлую технику. Архивы Новой ШотландииОстров Оук. Ведущая на материк дамба позволяет искателям сокровищ доставлять на остров Оук тяжёлую технику. Архивы Новой Шотландии

Можно привести аргумент существует общая структура [историй] о зарытых сокровищах, рассказывает Даунс. Сокровища каким-то образом теряются, истории о них рассказываются так, будто они правда, а тот факт, что сокровища так и не найдены подпадает под категорию подтверждающих формул, добавляемых в легенду, чтобы она стала достовернее.

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

Небылицы о денежной яме

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

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

Даунс считает,эти теории движимы теми же механизмами, что и и вера в теории заговора. Людям нравится верить, что в окружающем нас мире существует некий порядок, считает она.

Реальность такова, что они не всегда [достаточно знают об ордене]. Чтобы придать смысл миру, который нам трудно понять, мы часто придумываем повествования.

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

Сцена из сериала Проклятие острова Оук. Часто люди, предполагающие существование сокровищ на острове Оук, имеют долю его землиСцена из сериала Проклятие острова Оук. Часто люди, предполагающие существование сокровищ на острове Оук, имеют долю его земли

Тем не менее правда об острове Оук сохраняет элементы интриги. Исследование, проведённое историком Джой А. Стил и отставной морской геолог Гордон Фейдер доказывают, что на острове Оук располагался секретный британский промышленный центр.

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

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

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

Канцлер казначейства Англии (по сути, министр финансов) и другие высокопоставленные банковские чиновники того времени часто ссылались на Секрет в своей переписке, рассказывает Стил, который [несомненно] проект Оук-Айленд.

Я удивлена, что историки никогда не обращали на это внимания и не осмеливались выяснить, в чём заключался секрет, говорит она. [Остров Оук] воплотил то, что могло бы стать очень прибыльной товарной схемой.

Контрсвидетельства природы

Последний аргумент против рукотворной Денежной ямы основан на геологических условиях местности. По словам Фейдера, горные породы острова подвержены растворению под воздействием моря и грунтовых вод. Это создаёт систему подземных трещин и пещер склонных к обрушению и образованию карстовых воронок.

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

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

На острове Оук обнаружено по меньшей мере две карстовые воронки, а на прилегающем материке их гораздо больше. Стивен Эйткен, доктор наук, геофизик с более чем 25-летним опытом изучения района острова Оук, считает: природные данные указывают на то, что Денежная яма сама по себе является карстовой воронкой. В соответствии с утверждениями Фейдера Эйткен рассказывает, что горная порода под этой стороной острова локально растворилась, образовав карстовую систему, и некоторые пещеры этой системы обрушились и образовали карстовые воронки, включая Денежную яму.

Карстовые ямы это мусорные баки геологического мира, рассказывает Эйткен. Они часто заполнены обрушившейся брекчией [разновидностью осадочной породы], перекрытой смесью органических обломков и отложений.

Эйткен пишет, что отложения над брекчией в Денежной яме утолщены до 37 футов (чуть более 11 метров), а это указывает на позднее заполнение впадины. По словам Эйткена, первоначальная впадина, обнаруженная в 1795 году, также соответствует типичному проявлению карстовой воронки на поверхности.

Затопление Денежной ямы, которая по легенде, является доказательством существования мины-ловушки, в этой части острова Оук происходит естественным образом из-за притока пресной воды из песков недр острова. Если стволы или скважины не засыпаны непроницаемой глиной или не обсажены при бурении песками над коренными породами, пресная вода естественным образом затопит эти выработки, объясняет Эйткен.

Идея о том, что пираты вырыли сокровищницу кирками в скальных породах, просто смешна, также добавляет он.

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

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

Куда бы вы ни шли по этому острову, вы идёте сквозь историю, утверждает Баркхаус. Нельзя взять и свалить всё найденное на одну теорию; вот что так странно на острове. Я никогда не перестану верить, что на острове Оук зарыт клад, иэтот клад всё ещё там. Я чувствую это.

Притягательность настоящих сокровищ, будь то Святой Грааль, Ковчег Завета или огромный пиратский банк, затмевает собой все остальные находки на острове Оук. Охота может никогда не прекратиться. Навязчивая идея богатства, как указал один из зарегистрированных искателей сокровищ ещё в 1862 году, может стоить борьбы.

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

Как формируются карстовые воронки?

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

В зависимости от геологических условий и вышележащих материалов карстовые воронки могут образовываться в течение десятилетий и разрушаться в считаные секунды. Обрушение может быть ускорено внезапным притоком воды в недра или замерзанием и оттаиванием. Фейдер рассказывает, что при благоприятных обстоятельствах карстовая воронка может быть от 130 до 165 футов (чуть более 50 метров) в поперечнике. Он уверен, что именно этот феномен истинная причина происхождения денежной ямы острова Оук.

Если вам интересны не только исследования и поиски сокровищ и вы хотите исследовать данные и извлекать пользу из них, то вы можете присмотреться к нашему курсу Data Science, итог которого эквивалентен двум-трём годам активных самостоятельных поисков в науке о данных.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Стаи рыб следуют алгоритмам композиционного обучения

11.06.2021 16:11:37 | Автор: admin

Группа животных это больше, чем сумма всех членов группы. Поведение одинокого муравья трудно назвать осмысленным, но их колония способна построить прочную и хорошо вентилируемую муравьиную кучу. Одинокий журавль может легко заблудиться в небе, но стая журавлей безошибочно выбирает правильный путь миграции. Во многих сложных когнитивных процессах мы регулярно наблюдаем отличия в поведении группы от поведения её отдельных членов. Как это возможно? Даже автор статьи, кандидат наук, не может понять, как примитивные рыбы золотые нотемигонусы, абсолютно безнадёжные, безмозглые существа, собираясь в стаи, способны эффективно уклоняться от хищников. Автор прочитал десятки статей и учебников, проводил эксперименты, анализировал данные и консультировался с теоретиками, пытаясь понять, почему, когда речь идёт о рыбах, 1 плюс 1 получается не 2, а 3.

К старту курса о машинном и глубоком обучении мы перевели материал о том, как групповое поведение связано с композиционным (ансамблевым) обучением, где вы найдёте как кратко изложенную теорию со ссылками, так и вопросы, которые сегодня стоят перед наукой о коллективном поведении.


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

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

Машина

Сначала рассмотрим, как обстоят дела в области машинного обучения, ведь вам, вероятно, ближе алгоритмы, чем животные! Для формирования прогноза в методах композиционного обучения используется набор моделей, а не одна модель. Идея заключается в том, что ошибки в прогнозах отдельных моделей нивелируются, что приводит к более точным прогнозам в целом.

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

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

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

Теория

Повышенную точность модели случайного леса можно назвать коллективным интеллектом. Этот термин вошёл в обиход в 1906 году после того, как на ярмарке скота в Плимуте, штат Массачусетс, провели конкурс на угадывание веса быка. Угадать вес пытались почти 800 фермеров. Позже статистик сэр Фрэнсис Гальтон проанализировал все оценки и пришёл к выводу, что, несмотря на то что отдельные оценки сильно отличались друг от друга, среднее значение оценок было более точным, чем любая отдельно взятая оценка. Гальтон изложил свою теорию в знаменитом труде Vox Populi.

Для того чтобы коллективный интеллект работал, необходимо соблюдение двух основных требований. Первое требование люди должны получать разную информацию. Если у всех будет одинаковая входная информация, решение группы не будет более точным, чем решение отдельного человека. Решение группы может быть даже менее точным, чем решения отдельных людей, так как некоторые члены группы под воздействием эффекта эхо-камеры могут выдавать неверные прогнозы[1].

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

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

Рыбы

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

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

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

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

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

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

Второй класс алгоритмов базируется на предположении о том, что стаи рыб действуют как крупная нейронная сеть. (От биологических нейронов до искусственных нейронных сетей и стай рыб... мы прошли полный круг!) Уходя от хищников, многие виды рыб проявляют стартл-рефлекс сверхбыстрый рефлекторный рывок в сторону от тревожного раздражителя[2].

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

Каскад стартл-рефлексов. Из научной работы Розенталя и других учёных 2015 года: https://www.pnas.org/content/pnas/early/2015/03/24/1420068112.full.pdf?with-ds=yesКаскад стартл-рефлексов. Из научной работы Розенталя и других учёных 2015 года: https://www.pnas.org/content/pnas/early/2015/03/24/1420068112.full.pdf?with-ds=yes

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

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

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

Решения принимает нейронная сеть из нейронных сетейРешения принимает нейронная сеть из нейронных сетей

Заключение

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

Хотите узнать больше? Советуем почитать, как бабуины принимают демократические решения о передвижении, как у диких птиц из поколения в поколение сохраняется инновационное поведение [значение понятия можно прочитать здесь, этой ссылки в оригинальной статье нет], как слизистые грибы помогли заново создать карту токийского метро, оптимизировав распределение ресурсов. Чтобы узнать о последних исследованиях в области коллективного поведения, также рекомендуем ознакомиться с интернет-ресурсом Отдела коллективного поведения Института поведения животных им. Макса Планка.

Сноски

1. Теория
Если вы никогда не встречаете иные точки зрения в Интернете или такие иные точки зрения представлены как точки зрения идиота, то, скорее всего, вы находитесь в эхо-камере. Такое происходит довольно часто, поскольку социальные сети, как ни странно, имеют самоизолирующий эффект. Для более объективного взгляда на мир необходимо знакомиться с различными точками зрения.

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

Эта статья прекрасное напоминание о том, что многие решения в науке и технике позаимствованы у природы, либо просто существуют в ней уже очень давно. Если вы хотите экспериментировать с моделями машинного и глубокого обучения, повторяя и совершенствуя находки природы, находить новое в комбинациях разнообразных подходов к искусственному интеллекту, то вы можете обратить внимание на наш курс "Machine Learning и Deep Learning", партнёром которого является компания NVIDIA лидер в области вычислений для ИИ.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Сеть в bitly Linux tc для минимизации издержек и забавы ради

02.06.2021 20:09:34 | Автор: admin

Представьте, что вы, например, bitly то есть очень большой сервис сокращения ссылок. И вот, вы хотите скопировать свои 150 ТБ сжатых данных с одного физического кластера на другой, новый. Чтобы сделать это, вы запускаете distcp из набора инструментов hadoop и рады тому, насколько быстро он работает. Но, несколько позже, вы уже совсем не радуетесь жалобам обычных пользователей веб-сайта и API-клиентов случаются ошибки, задерживаются ответы, а данные их дата-центра только запутывают. К старту курса о DevOps мы перевели материал о том, что делать, если вы, как и bitly, оказались в подобной ситуации.


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

Важной частью инфраструктуры bitly и основным инструментом команды Data Science и рабочей группы обслуживания операций и инфраструктуры (Ops/Infra) в течение довольно долгого времени был физический кластер hadoop набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч узлов. Мы уже давно вынашивали идею подключения нового кластера, копирования и объединения данных старого кластера с данными нового.

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

  • bitly работает с огромными объёмами данных: на момент миграции кластер hadoop занимал более 150 ТБ дискового пространства сжатых потоковых данных, то есть данных, полученных в результате работы наших различных приложений. Объёмы таких данных продолжали увеличиваться в результате дополнительной обработки другими приложениями;

  • физически инфраструктура bitly располагается в центре обработки данных нашего партнёра. Она состоит из трёх физических видов шасси (приложения, хранилище и база данных), расположенных в ряд в смежных стойках. На момент написания этой статьи каждое шасси имело три физических гигабитных Ethernet-канала (каждый логически изолирован посредством организации сети VLAN) прямой канал, обратный канал и схему удалённого управления (для внеполосного управления серверными шасси). Каждое соединение после прохождения через ряд патч-панелей и коммутаторов подключается к нашим главным коммутаторам через стеклянное оптоволокно 10 Gb по звездообразной схеме сети;

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

Вернёмся к нашей истории.

Для быстрого копирования данных с одного кластера на другой мы воспользовались инструментом distcp, поставляемом в комплекте с кластером hadoop. Говоря просто, инструмент distcp выдаёт задание программному фреймворку mapreduce (используемому для параллельных вычислений над очень большими наборами данных в компьютерных кластерах) на перемещение данных из одного кластера hdfs в другой при копировании узлов в режиме "многие ко многим". Инструмент distcp сработал быстро, и это нас порадовало.

Но тут сломался сервис bitly, и это не привело в восторг команду Ops/Infra.

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

Теперь нам нужно было решать сразу две противоречивые задачи: с одной стороны, надо было продолжать миграцию hadoop, а с другой устранить неполадки и понять, в чём же кроется наша сетевая проблема.

Мы ограничили количество диспетчеров mapreduce, которые инструмент distcp использовал для копирования данных между кластерами, что позволило искусственно снизить пропускную способность при копировании и кое-как возобновить миграцию. После завершения копирования нам, наконец, удалось установить новый кластер взамен старого.

В новом кластере было больше узлов, значит, по идее, hadoop должен был работать быстрее.

Мы, кажется, осчастливили команду Data Science.

Но, к сожалению, поскольку кластер hadoop стал крупнее и быстрее, во время работы mapreduce на большее количество узлов стало передаваться большее количество данных, и это привело к непредвиденному эффекту:

Сервис bitly опять сломался, на этот раз очень серьёзно. Команда Ops/Infra была от этого не в восторге.

Первым импульсивным действием было вообще отрубить hadoop.

Но такое решение очень не понравилось команде Data Science.

Отключение кластера hadoop самое плохое из возможных решений (по последствиям может сравниться разве что с поломкой bitly), поэтому мы вернули кластер в состояние 1995 года, заставив все сетевые карты перейти на 100 Мбит/с (с 1 Гбит/с) с помощью команды ethtool -s eth1 speed 100 duplex full autoneg on. Теперь можно было спокойно подключить hadoop, но какой же медленной стала его работа!

Команда Data Science по-прежнему не выказывала признаков восторга.

И действительно, работа кластера была настолько "тормозной", что при вводе данных, выполнении запланированных заданий ETL (извлечения, преобразования и загрузки) и выдаче отчётов стали часто возникать сбои, постоянно срабатывали аварийные сигналы, будившие среди ночи членов команды Ops/Infra.

Надо ли говорить, как это не нравилось команде Ops/Infra!

Поскольку мы были лишены возможности удовлетворительно контролировать состояние сети, работа по поиску и устранению неисправностей вместе с партнёром из центра обработки данных предстояла сложная и длительная. Нужно было что-то сделать, чтобы привести hadoop в пригодное для использования состояние, и одновременно сделать так, чтобы сервис bitly перестал выходить из строя.

Сделаем ещё одно небольшое отступление:

Что нам было доступно в bitly?

  • roles.json : список серверов (app01, app02, userdb01, hadoop01 и т. д.), ролей (userdb, app, web, monitoring, hadoop_node и т.д.), а также сведения об отображении серверов на роли (app01,02 -> app, hadoop01,02 -> hadoop_node и т. д.);

  • $datacenter/jsons/* : каталог, содержащий json-файл для каждого логического сервера с атрибутами, описывающими сервер, IP-адресами, именами, информацией конфигурирования и, что наиболее важно в нашей истории, расположением стоек.;

  • Linux : Linux.

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

Но команда Ops/Infra не проявляла признаков радости.

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

$ tc class show dev eth1class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b    cburst 1561bclass htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b     cburst 1433bclass htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b     cburst 1561b$ tc filter show dev eth1filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16filter parent 1: protocol ip pref 49129 u32 filter parent 1: protocol ip pref 49129 u32 fh 817: ht divisor 1 filter parent 1: protocol ip pref 49129 u32 fh 817::800 order 2048 key     ht 817 bkt 0 flowid 1:10     match 7f000002/ffffffff at 16filter parent 1: protocol ip pref 49130 u32 filter parent 1: protocol ip pref 49130 u32 fh 816: ht divisor 1 filter parent 1: protocol ip pref 49130 u32 fh 816::800 order 2048 key     ht 816 bkt 0 flowid 1:20     match 7f000003/ffffffff at 16<snipped>$ tc qdisc showqdisc mq 0: dev eth2 root qdisc mq 0: dev eth0 root qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100     direct_packets_stat 24

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

class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b cburst 1561b

Каждый класс это потолок пропускной способности исходящего трафика, агрегированного по всем подписанным на этот класс фильтрам.

Каждый фильтр это конкретное правило для конкретного IP (к сожалению, каждый IP выводится в шестнадцатеричном формате), поэтому фильтр:

filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16

можно интерпретировать как "subscribe hadoop14 to the class 1:20", где "7f000001" можно интерпретировать как IP для hadoop14, а "flowid 1:20" класс для подписки. Затем запускаем команду qdisc, формирующую более или менее активную очередь для устройства eth1. Данная очередь по умолчанию помещает любой хост, не определённый в фильтре класса, в класс 1:100:

qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100 direct_packets_stat 24

В такой конфигурации любой хост (hadoop или другой), находящийся в одной стойке с конфигурируемым хостом, получает фильтр, назначенный классу "1:10", разрешающий скорость передачи до ~800 Мбит/с для класса в целом. Аналогичным образом для предопределённого списка ролей, считающихся "ролями приоритетных узлов", создаётся фильтр по тому же правилу "1:100". Такие узлы выполняют довольно важные задачи, например запускают сервисы hadoop namenode или jobtracker, а также наши узлы мониторинга. Любой другой хост hadoop, не находящийся в той же стойке, подключается к классу "1:20", ограниченному более консервативным классом ~200 Мбит/с.

Как было сказано выше, любой хост, не определённый в фильтре, попадает в класс по умолчанию для eth1 qdisc, то есть в класс "1:100". Как это выглядит на практике? Вот хост, подпадающий под действие правила "1:100":

[root@hadoop27 ~]# iperf -t 30 -c NONHADOOPHOST------------------------------------------------------------Client connecting to NONHADOOPHOST, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 35897 connected with NONHADOOPHOST port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.1 sec   735 MBytes   205 Mbits/sec

Теперь при подключении к другому хосту, расположенному в той же стойке или подпадающему под правило "1:10":

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER------------------------------------------------------------Client connecting to CABINETPEER, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39016 connected with CABINETPEER port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  2.86 GBytes   820 Mbits/sec

Что произойдёт при подключении к двум серверам, подпадающим под правило "1:10"?

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER1------------------------------------------------------------Client connecting to CABINETPEER1, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39648 connected with CABINETPEER1 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.47 GBytes   421 Mbits/sec[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER2------------------------------------------------------------Client connecting to 10.241.28.160, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 38218 connected with CABINETPEER2 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.43 GBytes   408 Mbits/sec

Трафик уменьшится вдвое? Похоже на правду. Даже лучше стало относительно проще отслеживать тренды данных, анализируя статистические данные, выводимые на наши сервисы трендов:

$ /sbin/tc -s class show dev eth1 classid 1:100class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit     burst 1561b cburst 1561b Sent 5876292240 bytes 41184081 pkt (dropped 0, overlimits 0 requeues 0) rate 3456bit 2pps backlog 0b 0p requeues 0 lended: 40130273 borrowed: 0 giants: 0tokens: 906 ctokens: 906

После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.

Мы осчастливили команду Data Science.

Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.

Мы осчастливили и команду Ops/Infra.

Выводы:

  • Попав в трудное положение, помните: ваш набор инструментов для управления средой так же важен, как и сама среда. Поскольку у нас уже имелся набор инструментов для комплексного контроля среды, мы сумели выбраться из ямы почти так же быстро, как попали в неё.

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

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

  • Linux: Linux

И последнее

Эта история хорошая иллюстрация "закона Мерфи для девопсов":

Закон Мёрфи для девопсов: "Если что-то может пойти не так, значит, что-то уже идёт не так, просто Nagios ещё не предупредил".

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Теория игр как механизм для анализа крупномасштабных данных

31.05.2021 16:13:25 | Автор: admin

Современные системы искусственного интеллекта подходят к решению таких задач, как распознавание объектов на изображениях и прогнозирование трёхмерной структуры белков, как прилежный студент готовится к экзамену. Тренируясь на многих примерах решения аналогичных задач, они со временем сводят к минимуму собственные ошибки и в конце концов добиваются успеха. Но приведённый пример лишь частный случай и лишь одна из известных форм обучения. К старту курса "Machine Learning и Deep Learning" делимся переводом статьи о том, как в DeepMind создали многоагентную систему при помощи нового подхода EigenGame, то есть компромисса между чистой оптимизацией и динамической системой.


Обучение также происходит при взаимодействии и играх с другими людьми. Перед человеком могут вставать чрезвычайно сложные проблемы, и решить их в одиночку ему вряд ли удастся. DeepMind попыталась решать проблемы с использованием определённых игровых приёмов, и у неё это прекрасно получилось она обучила агентов ИИ играть в Capture the Flag, а один из её агентов даже набрал гроссмейстерскую норму в Starcraft [мы писали об этом вчера, в статье о том, как StarCraft II может помочь экологам]. Это заставило нас задуматься, сможет ли теория игр помочь в решении других фундаментальных проблем машинного обучения.

Сегодня на ICLR 2021 (Международной конференции по обучающим представительствам) мы представили исследование "EigenGame: метод PCA как равновесие по Нэшу", получившее награду за лучшую публикацию (Outstanding Paper Award). В нём мы описали новый подход к решению старой проблемы: представили метод главных компонент (PCA), тип задачи о собственных значениях как конкурентную многоагентную игру. Такую игру мы назвали EigenGame. Метод PCA обычно трактуется как задача оптимизации (или проблема одного агента); однако мы выяснили, что, если применить многоагентный подход, можно разрабатывать новые идеи и алгоритмы, использующие современные вычислительные ресурсы. Применяя многоагентный подход, мы научились масштабировать огромные наборы данных, обработка которых ранее занимала бы слишком много времени и ресурсов, и теперь предлагаем альтернативный подход к проведению будущих исследований.

Метод PCA как равновесие Нэша

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

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

Во-вторых, метод PCA имеет много общего с множеством важных инженерных методов и алгоритмов машинного обучения, в частности с методом разложения по сингулярным значениям (SVD). Благодаря правильно выбранному подходу к применению метода PCA наши идеи и алгоритмы стали широко применяться во всех областях машинного обучения.

Рис. 1. Дерево знаний на базе SVD охватывает многие фундаментальные идеи машинного обучения, включая методы PCA, наименьших квадратов, спектральной кластеризации, функции условных значений, латентно-семантическое индексирование и сортировкуРис. 1. Дерево знаний на базе SVD охватывает многие фундаментальные идеи машинного обучения, включая методы PCA, наименьших квадратов, спектральной кластеризации, функции условных значений, латентно-семантическое индексирование и сортировку

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

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

В игре EigenGame каждый игрок управляет собственным вектором. Игроки увеличивают свой счёт, объясняя дисперсию в данных, но получают штраф, если слишком близко "подходят" к другим игрокам. Мы также устанавливаем иерархию: игрока 1 волнует только максимизация дисперсии, в то время как другие игроки также должны беспокоиться о том, чтобы не "подходить" близко к игрокам, стоящим выше их в иерархии. Такое сочетание поощрений и наказаний определяет полезность каждого игрока.

Рис. 3. Определение полезности каждого игрока выше в иерархииРис. 3. Определение полезности каждого игрока выше в иерархии

С помощью надлежащим образом определённых Var и Align можно показать, что:

  • Если все игроки играют оптимально, вместе они достигают равновесия по Нэшу, что и является решением PCA.

  • Такого результата можно достичь, если каждый игрок независимо и одновременно максимизирует собственную полезность, используя градиентное восхождение.

Рис. 4. EigenGame параллельно направляет каждого игрока вдоль единичной сферы от пустых окружностей к стрелкам. Синий игрок 1. Красный игрок 2. Зелёный игрок 3Рис. 4. EigenGame параллельно направляет каждого игрока вдоль единичной сферы от пустых окружностей к стрелкам. Синий игрок 1. Красный игрок 2. Зелёный игрок 3

Данное свойство независимости одновременного восхождения имеет особенную важность, так как позволяет распределить вычисления по десяткам TPU в Google Cloud, обеспечивая параллелизм данных и моделей. Соответственно, наш алгоритм может адаптироваться к данным действительно крупного масштаба. Для наборов данных из сотен терабайт, содержащих миллионы признаков или миллиарды строк, EigenGame находит главные компоненты за несколько часов.

Рис. 5. Каждый цветной квадрат представляет собой отдельное устройство. (L) Каждый игрок живёт и вычисляет обновления на одном устройстве. (R) Каждый игрок копируется на несколько устройств и вычисляет обновления, используя независимые наборы данных; различные обновления затем усредняются, и определяется более надёжное направление обновленияРис. 5. Каждый цветной квадрат представляет собой отдельное устройство. (L) Каждый игрок живёт и вычисляет обновления на одном устройстве. (R) Каждый игрок копируется на несколько устройств и вычисляет обновления, используя независимые наборы данных; различные обновления затем усредняются, и определяется более надёжное направление обновления

Полезность, обновления и всё, что с ними связано

Применяя метод PCA как многоагентную функцию, мы смогли разработать масштабируемые алгоритмы и предложить новые метода анализа. Мы также обнаружили удивительную связь метода с обучением по Хеббу, то есть тем, как происходит адаптация нейронов в процессе обучения. В EigenGame каждый игрок, максимизирующий собственную полезность, запускает уравнения обновления, аналогичные правилам обновления, полученным на основе Хеббовских моделей мозговой синаптической пластичности. Известно, что обновления по Хеббу сводятся к решению проблемы PCA, однако они не выводятся как градиент какой-либо функции полезности. Теория игр предоставляет возможность по-новому взглянуть на обучение по Хеббу, а также предлагает большое разнообразие подходов к решению проблем машинного обучения.

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

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

Рис. 6. Возможность использования нескольких функций полезности устраняет разрыв между оптимизационными подходами и динамическими системамиРис. 6. Возможность использования нескольких функций полезности устраняет разрыв между оптимизационными подходами и динамическими системами

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

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

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


Более подробная информация приведена в нашей работе EigenGame: метод PCA как равновесие по Нэшу и последующей работе EigenGame Unloaded: когда играть лучше, чем оптимизировать. Данная запись в блоге основана на совместной работе с Туром Грейпелом, руководителем исследовательской группы в DeepMind и заведующим кафедрой машинного обучения в Университетском колледже Лондона.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Наглядно о том, почему трансформеры работают настолько хорошо

20.06.2021 18:15:44 | Автор: admin

Трансформеры за последние несколько лет штурмом захватили мир NLP, а сегодня они с успехом применяются в выходящих за рамки NLP приложениях. Они обладают такими возможностями благодаря модулю внимания, который схватывает отношения между всеми словами последовательностей. Но самый важный вопрос как именно трансформеры делают это? Попытаемся ответить и понять, почему трансформеры способны выполнять такие вычисления. Итак, цель статьи, чуть сокращённым переводом которой мы делимся к старту курса о машинном и глубоком обучении, разобраться не только с тем, как что-то работает, но и почему работает так. Чтобы понять, что движет трансформерами, мы должны сосредоточиться на модуле внимания. Начнём с входных данных и посмотрим, как они обрабатываются.


Как входная последовательность попадает в модуль внимания

Модуль внимания присутствует в каждом энкодере внутри стека каждого энкодера, а также внутри стека каждого декодера. Сначала внимательно посмотрим на энкодер.

Модуль внимания в энкодереМодуль внимания в энкодере

Для примера предположим, что мы работаем над задачей перевода с английского на испанский, где исходная последовательность слов The ball is blue, а целевая последовательность La bola es azul.

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

Внутри модуля внимания последовательность векторного представления проходит через три линейных слоя, создающих три отдельные матрицы запроса (Query), ключа (Key) и значения (Value). Именно эти три матрицы используются для вычисления оценки внимания [прим. перев. оценка определяет, сколько внимания нужно уделить другим частям входного предложения, когда мы кодируем слово в определённой позиции]. Важно помнить, что каждая "строка" этих матриц соответствует одному слову исходной последовательности.

Поток исходной последовательностиПоток исходной последовательности

Каждая входная строка это слово из последовательности

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

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

Расположение каждого слова в исходной последовательностиРасположение каждого слова в исходной последовательности

Каждое слово проходит серию обучаемых преобразований (трансформаций)

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

Линейные веса и веса векторного представления обученыЛинейные веса и веса векторного представления обучены

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

Оценка внимания это скалярное произведение матрицы ключа и матрицы запроса слов

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

Многоголовое вниманиеМногоголовое вниманиеРасчёт оценки вниманияРасчёт оценки внимания

Как видно из формулы, первый шаг в рамках модуля внимания умножение матрицы, то есть скалярное произведение между матрицей Query (Q) и транспонированием матрицы ключа Key (K). Посмотрите, что происходит с каждым словом. Итог промежуточная матрица (назовём её факторной матрицей [матрицей множителей]), где каждая ячейка это результат матричного умножения двух слов.

Скалярное произведение матрицы запроса и матрицы ключаСкалярное произведение матрицы запроса и матрицы ключа

Например, каждый столбец в четвёртой строке соответствует скалярному произведению между четвёртым словом запроса и каждым ключевым словом.

Скалярное произведение между матрицами запроса и ключаСкалярное произведение между матрицами запроса и ключа

Оценка внимания скалярное произведение между запросом-ключом и значением слов

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

Скалярное произведение между матрицами ключа запроса и значенияСкалярное произведение между матрицами ключа запроса и значения

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

Оценка внимания это взвешенная сумма значения словОценка внимания это взвешенная сумма значения слов

Какова роль слов запроса, ключа и значения?

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

Оценка внимания для слова blue обращает внимание на каждое словоОценка внимания для слова blue обращает внимание на каждое слово

Например, для предложения The ball is blue строка для слова blue будет содержать оценку внимания для слова blue с каждым вторым словом. Здесь blue это слово запроса, а другие слова ключ/значение. Выполняются и другие операции, такие как деление и softmax, но мы можем проигнорировать их в этой статье. Они просто изменяют числовые значения в матрицах, но не влияют на положение каждой строки слов в ней. Они также не предполагают никаких взаимодействий между словами.

Скалярное произведение сообщает нам о сходстве слов

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

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

Каждая ячейка представляет собой скалярное произведение двух векторов словКаждая ячейка представляет собой скалярное произведение двух векторов слов

Для получения скалярного произведения двух векторов мы умножаем пары чисел, а затем суммируем их.

  • Если два парных числа (например, a и d выше) оба положительны или оба отрицательны, произведение положительно. Произведение увеличит итоговую сумму.

  • Если одно число положительное, а другое отрицательное, произведение будет отрицательным. Произведение уменьшит итоговую сумму.

  • Если произведение положительное, то, чем больше два числа, тем больше их вклад в окончательную сумму.

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

Как трансформер изучает релевантность между словами?

Скалярное произведение также применимо к оценке внимания. Если векторы для двух слов более выровнены, оценка внимания будет выше. Итак, какого поведения мы хотим от трансформера? Мы хотим, чтобы оценка внимания была высокой для двух релевантных друг другу слов в предложении. И мы хотим, чтобы оценка двух слов, не связанных друг с другом, была низкой.

Например, в предложении The black cat drank the milk слово milk очень релевантно к drank, возможно, немного менее релевантно для cat, и нерелевантно к black. Мы хотим, чтобы milk и drink давали высокую оценку внимания, чтобы milk и cat давали немного более низкую оценку, а для milk и black незначительную. Мы хотим, чтобы модель научилась воспроизводить этот результат. Чтобы достичь воспроизводимости, векторы слов milk и drank должны быть выровнены. Векторы milk и cat несколько разойдутся. А для milk и black они будут совершенно разными.

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

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

Следовательно, векторные представления слов milk и drank будут очень согласованными и обеспечат высокую оценку внимания. Они будут несколько отличаться для milk и cat, производить немного более низкую оценку и будут совершенно разными в случае milk и black: оценка внимания будет низкой вот лежащий в основе модуля внимания принцип.

Итак, как же работает трансформер?

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

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

Самовнимание энкодера в трансформере

Внимание используется в трансформере в трёх местах:

  • Самовнимание в энкодере исходная последовательность обращает внимание на себя.

  • Самовнимание в декодере целевая последовательность обращает внимание на себя.

  • Энкодер-декодер-внимание в декодере целевая последовательность обращает внимание на исходную последовательность.

Внимание в ТрансформереВнимание в Трансформере

В самовнимании энкодера мы вычисляем релевантность каждого слова в исходном предложении каждому другому слову в исходном предложении. Это происходит во всех энкодерах стека.

Декодер самовнимания в трансформере

Большая часть того, что мы только что видели в энкодере самовнимания, применима и к вниманию в декодере, но с некоторыми существенными отличиями.

Внимание в декодереВнимание в декодере

В декодере самовнимания мы вычисляем релевантность каждого слова в целевом предложении каждому другому слову в целевом предложении.

Самовнимание декодераСамовнимание декодера

Энкодер-декодер модуля внимания в трансформере

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

Энкодер-декодер ВниманияЭнкодер-декодер Внимания

Заключение

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

Здесь мы видим, что за сложными идеями скрываются простые решения. Более того, есть ощутимая вероятность того, что вскоре понимание внутренних механизмов глубокого обучения станет второй грамотностью, как сегодня второй грамотностью стало знание ПК в целом и если вы хотите углубиться в область глубокого и машинного обучения, получить полное представление о современном ИИ, вы можете присмотреться к нашему курсу Machine Learning иDeep Learning, партнёром которого является компания NVIDIA.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Тематическое исследование распознавания именованных сущностей в биомедицине

04.06.2021 18:05:38 | Автор: admin

Не так давно у автора этой статьи возник вопрос: может ли простой метод сопоставления строк в сочетании с некоторыми простыми оптимизациями конкурировать с моделью, обученной с учителем, в биомедицинской задаче распознавания именованных сущностей (NER)? Автор сравнил эти два метода между собой и предположил, что при правильном подходе даже простые модели могут конкурировать со сложными системами, а мы к старту курса "Machine Learning и Deep Learning" перевели его статью.


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

Что касается системы сопоставления строк, я использовал классификатор QuickUMLS. QuickUMLS [1] как система сопоставления строк принимает на вход строку (например, документ или реферат статьи, содержащий медицинские понятия) и выводит все промежутки документа, которые соответствуют понятиям унифицированного языка медицинских систем (UMLS). Затем эти понятия могут быть повторно использованы в других условиях или в качестве исходных данных для других систем машинного обучения. По этой причине QuickUMLS можно рассматривать как удобный инструмент предварительной обработки для получения релевантных понятий из клинических и биомедицинских текстов. Однако в этой статье мы сосредоточимся на использовании QuickUMLS в качестве классификатора на сложном наборе данных MedMentions [2].

Рисунок 1. Схематическое описание того, как работает QuickUMLS. Получив строку, базу данных UMLS, превращённую в БД simstring, модель возвращает оптимальные соответствия, идентификаторы понятий и семантические типыРисунок 1. Схематическое описание того, как работает QuickUMLS. Получив строку, базу данных UMLS, превращённую в БД simstring, модель возвращает оптимальные соответствия, идентификаторы понятий и семантические типы

Некоторые ключевые моменты, которые необходимо знать о биомедицинском NER

Прежде чем мы погрузимся в проблему, которую пытаемся решить, полезно описать некоторые особенности биомедицинского NER. В целом проблема NER заключается в поиске именованных сущностей (например, известных мест, лиц, организаций и т. д.) в тексте. Как вы, вероятно, догадываетесь, многие из этих сущностей можно найти через контекст. Например, в таком предложении, как "Сэм и Дрю пошли в Колизей", мы можем сделать вывод, что Колизей это место, потому что вы обычно ходите в какие-то места. Аналогично, мы можем предположить, что "Сэм" это имя собственное, потому что слова в позиции подлежащего "идти", которые не являются обычными словами, это обычно имена.

В отличие от этого биомедицинская NER заключается в поиске и однозначном определении интересующих биомедицинских терминов из текста, таких как заболевания, названия лекарств, а также общих терминов, таких как "больница.роддом" (hospital), "палата интенсивной терапии/подопечный отделения интенсивной терапии" или "алкоголь/спирт" (alcohol). Это важное различие, поскольку существует очень мало контекстуальной информации, определяющей, имеет ли данное слово медицинское значение. Чтобы привести немного нагруженный пример, рассмотрим слово "alcohol" в предложении "пациент выпил много alcohol" [для ясности того, что речь идёт о неоднозначности, оставлено оригинальное alcohol]. Тяжесть этого заключения зависит от того, относится ли оно к алкоголю, такому как пиво или вино, или к чистому спирту, такому как спирт для растирания. Для более полного обзора состояния дел в области биомедицинского NER см. эту запись в блоге моего коллеги из Slimmer AI, Сибрена Янсена.

Знать, какие понятия имеют медицинское значение, сложно без большого количества обучающих данных, которые, как правило, не всегда доступны. Поэтому многие системы используют унифицированный язык медицинских систем (UMLS), которая представляет собой большую онтологию, содержащую множество различных понятий вместе с их строковыми представлениями и другой информацией. Обратите внимание, что "понятие" здесь отличается от "строки", поскольку многие строки могут ссылаться на более чем одно понятие. Например, строка "alcohol" может относиться к спирту для растирания или к алкогольным напиткам.

В UMLS каждое понятие описывается уникальным идентификатором понятия (CUI), который является символическим идентификатором для любого данного уникального понятия, и семантическим типом (STY), который, в свою очередь, является идентификатором семейства, группирующим понятия с похожими характеристиками. Одной из причин, по которой UMLS является полезным, но в то же время сложным для работы, его огромный размер. Версия UMLS 2020AB, которую мы будем использовать в дальнейшем, насчитывает более 3 миллионов уникальных английских понятий. Маловероятно, что значительная часть этих понятий появится даже в больших аннотированных наборах данных.

Работа с набором данных MedMentions

Одним из таких наборов данных является MedMentions. Он состоит из 4 392 статей (заголовки и рефераты), опубликованных в Pubmed за 2016 год; аннотировано 352 K понятий (идентификаторов CUI) и семантических типов из UMLS. В документах имеется около 34 тысяч аннотированных уникальных понятий это около 1 % от общего числа понятий в UMLS. Факт показывает, что аннотирование упоминаний в UMLS является сложной задачей, которую не всегда можно решить с помощью машинного обучения с учителем.

Особый интерес в этом отношении представляет то, что корпус MedMentions включает в тестовое множество CUI, которые не встречаются в обучающем наборе. В целом, однако, эта задача всё ещё рассматривается как задача машинного обучения с учителем и с использованием семантических типов понятий UMLS в качестве меток. Поскольку UMLS имеет 127 семантических типов, это всё равно приводит к большому пространству меток. У набора данных MedMentions тоже есть уменьшенная версия st21pv, который состоит из тех же документов, что и обычный набор, но в нём аннотирован только 21 наиболее часто встречающийся семантический тип.

Полумарковская базовая модель получает около 45,3 по F-мере на уровне сущностей [2]. Другие подходы, включая BlueBERT [3] и BioBERT [4], были протестированы и улучшили оценку до 56,3 балла, используя точное соответствие на уровне сущностей [5]. Обратите внимание, что все эти подходы являются контролируемыми и, следовательно, полагаются на определённое совпадение между обучающим и тестовым множеством в плане понятий. Если понятие или метка никогда не встречалась в процессе обучения, в подходе машинного обучения с учителем будет сложно её правильно классифицировать. Далее в качестве меток мы будем использовать семантические типы из набора данных MedMentions.

QuickUMLS: без учителя и на основе знаний

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

  1. Качество модели ограничено качеством базы знаний. Модель не может предсказать то, чего нет в базе знаний.

  2. Модель может обобщать не только аннотированные данные. Модель, которая обучалась с учителем и во время обучения не видела конкретной метки, в целом не может точно предсказать эти вещи. Исключение из правила методы обучения zero-shot.

Zero-shot learning (ZSL) это постановка задачи в машинном обучении, когда во время тестирования алгориттм наблюдает выборки из классов, которые не наблюдались во время обучения, и должен спрогнозировать, к какому классу они принадлежат.

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

Архитектура модели QuickUMLS

QuickUMLS как модель проста. Сначала она анализирует текст с помощью парсера spacy. Затем выбирает словесные n-граммы, то есть последовательности слов, на основе цитат и описаний цитат, а также списков стоп-слов. Это означает, что модель отбрасывает определённые словесные n-граммы, если они содержат нежелательные токены и знаки препинания. Подробные сведения об этих правилах можно найти в оригинальной статье [1]. После выбора кандидатов вся база данных UMLS запрашивается, чтобы найти понятия, частично соответствующие словам n-грамм. Поскольку точное сопоставление в такой огромной базе данных неэффективно и сложно, авторы выполняют приблизительное сопоставление строк с помощью simstring [6]. При задании текста QuickUMLS, таким образом, возвращает список понятий в UMLS вместе с их сходством со строкой запроса и другой связанной информацией. Например, текст У пациента было кровоизлияние, используя (по умолчанию) порог сходства строк 0,7, возвращает следующих кандидатов:

Для слова patient:

{term: Inpatient, cui: C1548438, similarity: 0.71, semtypes: {T078}, preferred: 1},{term: Inpatient, cui: C1549404, similarity: 0.71, semtypes: {T078}, preferred: 1},{term: Inpatient, cui: C1555324, similarity: 0.71, semtypes: {T058}, preferred: 1},{term: *^patient, cui: C0030705, similarity: 0.71, semtypes: {T101}, preferred: 1},{term: patient, cui: C0030705, similarity: 1.0, semtypes: {T101}, preferred: 0},{term: inpatient, cui: C0021562, similarity: 0.71, semtypes: {T101}, preferred: 0}

Для слова hemmorhage:

{term: No hemorrhage, cui: C1861265, similarity: 0.72, semtypes: {T033}, preferred: 1},{term: hemorrhagin, cui: C0121419, similarity: 0.7, semtypes: {T116, T126}, preferred: 1},{term: hemorrhagic, cui: C0333275, similarity: 0.7, semtypes: {T080}, preferred: 1},{term: hemorrhage, cui: C0019080, similarity: 1.0, semtypes: {T046}, preferred: 0},{term: GI hemorrhage, cui: C0017181, similarity: 0.72, semtypes: {T046}, preferred: 0},{term: Hemorrhages, cui: C0019080, similarity: 0.7, semtypes: {T046}, preferred: 0}

Как вы можете видеть, слово patient имеет три соответствия с корректным семантическим типом (T101) и два соответствия с корректным понятием (C0030705). Слово кровоизлияние также имеет лишние совпадения, включая понятие "No hemmorhage". Тем не менее кандидат с самым высоким рейтингом, если исходить из сходства, является правильным в обоих случаях.

В приложении QuickUMLS по умолчанию мы сохраняем только предпочтительные термины, то есть термины, для которых предпочтительным является 1, а затем сортируем по сходству. После мы берём семантический тип (семтип) кандидата с самым высоким рейтингом в качестве прогноза мы называем это базовой моделью (baseline model). Мы использовали seqeval со строгой парадигмой соответствия, которая сопоставима с предыдущей работой [5].

    BERT  QUMLS  P   .53    .27  R   .58    .36  F   .56    .31 Таблица 1  производительность базовой модели

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

Улучшение QuickUMLS с помощью некоторых простых оптимизаций

Есть несколько способов улучшить QuickUMLS помимо его первоначальной производительности. Во-первых, отметим, что стандартный синтаксический анализатор, используемый QuickUMLS, по умолчанию является моделью spacy, т. е. en_core_web_sm. Учитывая, что мы имеем дело с биомедицинским текстом, нам лучше применить модель биомедицинского языка. В нашем случае мы заменили spacy на scispacy [7], en_core_sci_sm. Это уже немного повышает производительность без каких-либо затрат.

    BERT  QUMLS  + Spacy  P   .53    .27      .29  R   .58    .36      .37  F   .56    .31      .32 Таблица 2  Замена на scispacy

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

Оптимизация порога QuickUMLS

Настройки по умолчанию для QuickUMLS включают пороговое значение 0,7 и набор метрик. Метрика определяет, как подсчитывается сходство строк, и может быть установлена в Jaccard, cosine, overlap и dice. Мы выполняем поиск по сетке, по метрике и различным пороговым значениям. Наилучшими результатами оказались пороговые значения 0,99, а это означает, что мы выполняем точные совпадения только с помощью SimString и метрики Jaccard, которая превосходит все другие варианты с точки зрения скорости и оценки. Как видите, мы всё ближе и ближе подходим к производительности BERT.

    BERT  QUMLS  + Spacy  + Grid  P   .53    .27      .29     .37  R   .58    .36      .37     .37  F   .56    .31      .32     .37 Таблица 3  Поиск по сетке параметров

Преимущество добавления априорной вероятности

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

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

    BERT  QUMLS  + Spacy  + Grid  + Priors  P   .53    .27      .29     .37       .39  R   .58    .36      .37     .37       .39  F   .56    .31      .32     .37       .39 Таблица 4  Добавление приоров

К сожалению, это всё, что мы могли бы получить, используя простую систему в QuickUMLS. Учитывая, что мы в конечном счёте использовали порог 0,99, это означает, что мы вообще не используем функциональность приблизительного сопоставления QuickUMLS. Удаление приблизительного сопоставления также значительно ускорит работу всей системы, так как большая часть времени алгоритма теперь тратится на сопоставление в QuickUMLS.

Глубокое погружение в анализ ошибок: соответствовало ли наше решение поставленной задаче?

Когда мы выполняем задачу распознавания именованных сущностей, мы можем допустить ошибки нескольких типов. Во-первых, мы можем извлечь правильный промежуток, но неправильный класс. Это происходит, когда мы находим правильный термин, но даём ему неправильную метку: например, мы думаем, что alcohol относится к напитку, в то время как он относится к дезинфицирующему средству. Во-вторых, мы также можем извлечь промежуток частично, но при этом всё равно сопоставить его правильной метке. В этом случае возможно рассматривать совпадение как частичное совпадение. В нашем скоринге мы считали правильными только точные совпадения. Пример извлечение мягкого анестетика, когда золотым стандартом является анестетик. Мы также можем полностью пропустить какие-то промежутки, например потому, что UMLS не содержит термина, или извлечь не соответствующие упоминаниям золотого стандарта промежутки. На рисунке ниже показано, какие виды ошибок допускает наша система:

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

Заключение

Как вы можете видеть из результатов, готовая система извлечения терминологии может быть использована в качестве эффективной системы NER без обучения. Получение обучающих данных для конкретных случаев применения часто может быть трудоёмким, снижающим скорость R&D процессом. Построенный нами классификатор QuickUMLS показывает, что мы можем многого добиться с очень небольшим количеством обучающих примеров. И, будучи разумными в том, как использовать ресурсы, мы в процессе исследований и разработок для биомедицинских исследований сэкономили много времени. Модифицированный классификатор QuickUMLS можно опробовать здесь, на github. Преимущество подхода может означать, что мы нашли решение, достаточно надёжное для достижения конечного результата, простое в разработке и тестировании, а также достаточно небольшое, чтобы легко внедрить его в разработку продукта.

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

Вместе с тем одни из самых успешных моделей так или иначе комбинируют подходы из разных областей ИИ, например мы писали о визуализации пения птиц, чтобы ИИ работал со звуком так же, как работает с изображениями и если вам интересна не только обработка естественного языка, но и эксперименты с ИИ в целом, вы можете обратить внимание на наш курс "Machine Learning и Deep Learning", партнёром которого является компания NVIDIA.

Ссылки

[1]L. Soldaini, and N. Goharian. Quickumls: a fast, unsupervised approach for medical concept extraction, (2016), MedIR workshop, SIGIR

[2]S. Mohan, and D. Li, Medmentions: a large biomedical corpus annotated with UMLS concepts, (2019), arXiv preprint arXiv:1902.09476

[3]Y. Peng, Q. Chen, and Z. Lu, An empirical study of multi-task learning on BERT for biomedical text mining, (2020), arXiv preprint arXiv:2005.02799

[4]J. Lee, W. Yoon, S. Kim, D. Kim, S. Kim, C.H. So, and J. Kang, BioBERT: a pre-trained biomedical language representation model for biomedical text mining, (2020), Bioinformatics, 36(4)

[5]K.C. Fraser, I. Nejadgholi, B. De Bruijn, M. Li, A. LaPlante and K.Z.E. Abidine, Extracting UMLS concepts from medical text using general and domain-specific deep learning models, (2019), arXiv preprint arXiv:1910.01274.

[6]N. Okazaki, and J.I. Tsujii, Simple and efficient algorithm for approximate dictionary matching, (2010, August), In Proceedings of the 23rd International Conference on Computational Linguistics (Coling 2010)

[7]M. Neumann, D. King, I. Beltagy, and W. Ammar, Scispacy: Fast and robust models for biomedical natural language processing, (2019),arXiv preprint arXiv:1902.07669.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Категории

Последние комментарии

  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru