Мировоззрение

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

Поиск первопричины

• Постарайтесь воспроизвести проблему
  
  • Можете ли вы воспроизвести это из командной строки?
    
    • Другим людям легче воспроизвести проблему
    • Легче проверить исправление
• Есть ли файлы журналов? Что за сообщение об ошибке?
  
  • Прочтите описание ошибки. Каждое его слово. Дважды.
  • Есть ли где-нибудь опечатка (командная строка / конфигурация / код)?
• Изолируйте проблему
  
  • Удалите некоторые части системы и попробуйте воспроизвести ошибку
  • Меняйте одно за раз, сохраняя все остальное постоянным

Проблема все еще не устранена? Чек-лист

• Постарайтесь решать сложные проблемы утром на свежую голову и без отвлечения (решите её перед тем, как вы просмотрите: почту, чат, тикет-систему, мониторинг)
• У вас несколько проблем? Сначала попробуйте решить основную проблему (например, ssh-соединение, которое разрывается каждую минуту)
• Это действительно проблема или просто недоразумение (работает как положено?)
  • Есть ли функция/политика безопасности, которая блокирует вашу работу?
• Найдите стабильную среду отладки
• Проблема возникает только на одном сервере? То же самое работает где-то еще?
  
  • Какая разница? Проверьте!
• Когда впервые возникла проблема? Что изменилось?
• Можете ли вы увеличить журнал логов?
• Сделайте некоторые проверки на вменяемость
  
  • Вы на той виртуальной машине?
  • Можете ли вы пропинговать хост?
  • DNS все еще работает?
  • Проверьте сетевой трафик с помощью ngrep/tcpdump. Вы видите то, что ожидаете?
  • Один из дисков полон?
  • Вы редактируете нужный файл?
    
    • Напишите мусор и попробуйте скомпилировать и проверить синтаксис
  • Проверить систему мониторинга
    
    • Есть ли проблемы с другими виртуальными машинами заказчика?
    • Есть ли проблемы у других виртуальных машин, работающих на том же гипервизоре?
    • Не работает весь центр обработки данных?
  • Клиент авторизован в системе? Что он делает (проверьте bash_history и ps -u)

Через некоторое время отладки

• Заставьте себя выразить проблему легко и понятно, чтобы ее понял случайный плюшевый мишка.
• Будьте терпеливы и примите тот факт, что все занимает больше времени, чем ожидалось.
• Попытайтесь понять, что происходит. Не с помощью бесконечных проб и ошибок
  
  • Есть ли документация, которая поможет вам разобраться в системе?
  • Поговорите с другими людьми, которые знают систему лучше, чем вы
• Сделайте перерыв (прогуляйтесь, сделайте зарядку, сделайте глубокий вдох, выпейте воды, съешьте фрукты)
• Вернемся к началу: в чем проблема? В чем причина проблемы? Какую цель вы пытаетесь достичь?
• У вас нет времени и вы зациклились на каких-то несвязанных деталях?
  
  • Используйте другой подход для решения вашей актуальной проблемы

Если вы копируете код из Stackoverflow

• Не копируйте код из Stackoverflow, не понимая реальной проблемы
• Не копируйте код из Stackoverflow, не понимая предлагаемого решения
  
  • Если у вас нет на это сейчас времени => запишите это решение (даже когда вы уже разберетесь с проблемой)
  • Если вы не знаете, что делает команда или инструмент, прочтите документацию (http://personeltest.ru/aways/explainshell.com)
  • Не копируйте команды/код. Пишите самостоятельно
  
  

После решения проблемы

1. Отличная работа! Я рад, что ты не сдался!
2. Что вы узнали для себя?
3. Какие предположения были неправильные?
4. Как вы можете решить подобную проблему в будущем еще быстрее?

---

• Первая в России серийная система управления двухтопливным двигателем с функциональным разделением контроллеров
• В современном автомобиле строк кода больше чем
• Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
• McKinsey: переосмысляем софт и архитектуру электроники в automotive

От автора перевода

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

1. Мы никогда не сможем взять в работу все проекты, которые хотелось бы.
2. Нужно научиться правильно их выбирать.

Уверен, что с аналогичными проблемами сталкивается абсолютное большинство продуктовых компаний. В качестве рабочего инструмента для решения этих проблем полезным представляется подход, описанный в статье Ленни Рачитски, product lead Airbnb.

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

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


_{Первые наработки запущенного продукта, дающие возможность путешественникам Airbnb находить мероприятия, в которых можно участвовать вместе с другими путешественниками}

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



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

• Шаг 1. Кристаллизация проблемы
• Шаг 2. Согласование проблемы с командой и стейкхолдерами
• Шаг 3. Постоянный возврат к проблеме

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

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

Шаг 1. Кристаллизация проблемы

Начните с ответа на эти вопросы о своем проекте.

• Описание: что это за проект?
• Проблема: какую проблему он решает?
• Почему: как мы поняли, что это реальная проблема и ее нужно решать?
• Успех: как мы узнаем, что проблема решена?
• Аудитория: для кого мы делаем это?
• Что это: как будет выглядеть реализация в продукте?

Описание: что это за проект?

Это краткое описание идеи. Люди, читающие его, смогут быстро понять суть. Будьте кратки.

Проблема: какую проблему он решает?

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

Назовем ключевые характеристики правильной постановки проблемы.

1. Проблема кратка. Цель описать проблему одним предложением. Чем больше вам требуется объяснений, тем менее ясной становится проблема в конечном итоге.
2. Сфокусирована. У нас есть единственная ясная проблема, которая может быть решена одной командой и в разумные сроки. Часто очень полезно привести несколько примеров других проблем, которые вы НЕ решаете.
3. Связана с неудовлетворенной потребностью. Сосредоточьтесь на потребностях пользователя или бизнеса. Тут крайне полезно использовать вот этот фреймворк.
4. Включает ответы на вопрос что и почему. Что идет не так и почему это проблема? Возможно, вам придется вернуться сюда в следующей секции.
5. Не зависит от решения. Подавляйте в себе желание слишком быстро перейти к решению проблемы.

Хорошие примеры постановки проблемы

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

Плохие примеры постановки проблемы

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

Почему: как мы поняли, что это реальная проблема и ее нужно решать?

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

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

Несколько советов для этого шага.

1. Изучите количественные и качественные доказательства. Соберите все данные, которые указывают на то, что это действительно реальная и важная проблема.
2. Качество важнее количества. От 3 до 5 прямых фактов лучше дюжины косвенных. Во втором случае ваши выводы будут слабее, так как они будут основаны на второстепенных и не имеющих отношения к делу фактах, выглядящих как куча доказательств. Лишний перфекционизм также ни к чему.
3. Сыграйте сами с собой в адвоката дьявола. Попытайтесь убедить себя, что это совершенно незначимая проблема. Какие пробелы имеются в ваших доказательствах? Действительно ли доказательства соответствуют тому, что вы думаете? Проверьте себя.

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

Успех: как мы узнаем, что проблема решена?

Вы достигли того, что планировали достичь? Как вы узнаете? Ответьте на этот вопрос и запишите ответ.



Этот критерий становится невероятно важен на протяжении всего проекта, так как он помогает принимать решения и расставлять приоритеты. Фича X увеличивает шансы достичь поставленной цели? Если нет, не делаем ее.

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

Несколько советов для определения критериев успеха.

• Постарайтесь получить конкретное число, например: 10% прирост показателя X; 50% уменьшение показателя Y.
• Цель должна быть достижима, но амбициозна. Достижение какой цели приведет вашу команду и руководителей в восторг?
• Если вы не смогли придумать метрику для своей цели (думать нужно долго и напряженно), опишите, как будет выглядеть мир в случае успеха проекта. Сделайте это критерием успеха.

Аудитория: для кого мы делаем это?

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

Что: как будет выглядеть реализация в продукте?

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

Шаг 2. Согласование проблемы с командой и стейкхолдерами

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



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

Я обычно подхожу к этому шагу так.

1. Возьмите документ, созданный на первом этапе (это может сделать и любой член вашей команды, вовлеченный в эту проблему).
2. Поделитесь им со всей командой. Соберите обратную связь. Доработайте документ с учетом полученной обратной связи и снова предоставьте его на общее обозрение.
3. Если обратная связь сходится и команда выглядит синхронизированной отлично. Если нет, соберите всех вместе и обсудите разногласия.
4. Когда согласие внутри команды будет достигнуто, синхронизируйтесь в понимании проблемы со стейкхолдерами. Важно, чтобы ваша команда и люди, которые будут оценивать результаты, одинаково понимали проблему, которую вы решаете, до того, как вы плотно приступите к работе по проекту.
5. Соберите команду и снова произведите ревью постановки проблемы. Отыщите ответы на нерешенные вопросы и убедитесь, что у команды есть все необходимое, чтобы начать работать.

Шаг 3. Постоянный возврат к проблеме

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



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

Я помню, как несколько лет назад работал над проектом по созданию админки для хозяев жилья в Airbnb. Изначально мы решали проблему уменьшения времени ответа от хозяина, а именно сокращения времени ответа хозяина на сообщение гостя. Наша гипотеза заключалась в следующем: хозяева отвечали бы быстрее, если бы непрочитанные сообщения им были более заметны. Вдобавок мы напоминали бы им о том, что скорость ответа на сообщения влияет на их поисковый рейтинг. В итоге мы оказались правы. Но на протяжении проекта с ростом его масштаба и сложности я постоянно находил себя напоминающим команде, какую проблему мы должны решить. (Профессиональный совет: админки классическая проблема буррито в фольге.) От размывания фокуса проекта ничто не помогает лучше, чем постоянное возвращение к первоначальной постановке задачи и критериям успеха. Вы можете решить множество проблем множеством способов, но можете также создать прекрасный продукт, который не решает никаких проблем.

Избежать этой ловушки помогут полезные привычки.

1. При каждом ревью проекта удостоверьтесь, что исполнитель начинает с постановки проблемы. Если это не очевидно, задайте вопрос: Какую проблему мы пытаемся решить?.
2. При каждом отчете о ходе проекта перед стейкхолдерами возвращайтесь к постановке проблемы. Убедитесь, что у всех остается одинаковое ее понимание.
3. Перед финализацией проекта спросите себя: Чувствую ли я уверенность в том, что мы готовы решить проблему, которую планировали решить изначально?.

И в заключение

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

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

Марк Менсон. Тонкое искусство пофигизма

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

Очень рекомендую прочитать следующие 5 книг.

1. Deep Work (Кэл Ньюпорт. В работу с головой. Паттерны успеха от IT-специалиста)
2. The Subtle Art of Not Giving a F*ck (Марк Менсон. Тонкое искусство пофигизма)
3. Good Strategy, Bad Strategy (Ричард Румельт. Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно)
4. Measure What Matters (Джон Дорр: Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR)
5. Lean Analytics (На момент написания статьи не переведена на русский)

От автора перевода

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



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

Выражаю благодарность нашему журналисту Анисимовой Татьяне и арт-директору Забегалову Алексею за помощь в редактировании и оформлении статьи.

Haystacks at Sunset Reimagined by AshnoAlice

Инженер по машинному обучению Джордж Хосу задает вопрос: Какие проблемы решает машинное обучение?. Или конкретнее, с учетом современного развития отрасли: Какие проблемы нейросеть способна решить на практике?. Команда Mail.ru Cloud Solutions перевела статью, так как рассуждения на эту тему, как нам кажется, встречаются редко.

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

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

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

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

Например, игра в шахматы уже решенная проблема. Компьютерные программы обыгрывают человека с помощью небольших деревьев решений и нескольких простых эвристик поиска (пример: Chess-AI-TDD).

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

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

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

Формально это предположение не всегда верно, потому что:

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

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

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

Я действительно не могу придумать здесь контрпримера может, какие-то конкретные типы числовых проекций?

Первое правило довольно скучное, но его следовало изложить в качестве отправной точки.

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

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

Допустим, эта модель решает вашу проблему, то есть предсказывает риск невозврата кредита лучше, чем 80% аналитиков.

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

У вас теперь меньше входных данных, а история посещения сайтов более не доступна или ее запрещено анализировать.

Можно ли с уверенностью предположить, что вы по-прежнему способны построить разумную модель для решения этой проблемы?

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

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

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

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

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

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

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

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

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

Или посмотрим на модели распознавания изображений и обнаружения объектов. Их узкое место объем хорошо маркированных данных, а не контент изображений. Конечно, есть пограничные случаи. Но если подать достаточно примеров из другой задачи (например, из сверточной остаточной сети для ImageNet), как правило, все объекты и изображения можно распознать и классифицировать.

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

Правило 3. Нейросеть способна решить те же задачи, что может решить человек с небольшими точками данных и почти без контекста

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

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

Вы можете посчитать количество пикселей как объем информации, которую нужно изучить. Так, здесь у нас 400 пикселей по 255 значений каждый, значит, разумно предположить, что с несколькими миллионами параметров в нашем уравнении можно учесть все возможные паттерны.

Что имеется в виду под небольшими точками данных? Если вкратце, это понятие вытекает из нескольких факторов:

1. Размер модели. Чем больше модель, тем более сложные паттерны она может выучить, тем больше возможный объем входных и выходных данных.
2. Детализация ответа (выдачи). Например, 1000 классов против 10 классов или диапазон целых чисел от 0 до 1000 против одного числа от 0 до 100 000. В нашем случае детализация равна 2.
3. Размер входного сигнала. В данном случае 400 пикселей, так как размер изображений 2020.

Возьмите классическую задачу классификации изображений, такую как MNIST. Несмотря на пару незначительных улучшений, эффективность лучших систем не сильно повысилась. За последние 8 лет качество улучшилось с 98,5% до 99,4%, что в обоих случаях хорошо вписывается в обычный человеческий диапазон ошибок.

Сравните это с какой-нибудь системой, которая работает с большим объемом входных и выходных данных, например ImageNet. Там за последние 8 лет произошел скачок от 50% до почти 90%.

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

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

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

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

Что же означает практически без контекста?

Это сложнее сформулировать, но можно посмотреть на примеры с большим и малым объемом контекста:

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

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

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

Итак, третий принцип можно сформулировать следующим образом.

Общая нейросеть, вероятно, может решить проблему, если:

1. Человек может ее решить
2. Задачи с входными данными и выдачей похожего размера уже решены сетью такого же размера
3. Бльшая часть релевантных контекстных данных, которыми располагает человек, включена во входные данные нашего алгоритма.

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

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

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

Вы можете свести проблему к следующему:

1. Около 2000 признаков на входе (третичная структура аминокислот) охватит 99, Х% белков, а не 100%.
2. Около 18 000 соответствующих выходных признаков (число позиций атомов в третичной структуре, то есть форма, которую необходимо предсказать, чтобы получить структуру).

Это лишь один из примеров. Как и в большинстве проблем NLP с субъективной оценкой размера входных данных, для этого типа входных данных требуется прямое кодирование, то есть кодирование с использованием индивидуальных переменных для каждого состояния. Тогда размер внезапно возрастает до 40 000 (генетическим кодом ДНК кодируются 20 протеиногенных аминокислот), 42 000 (с учетом селенопротеинов) или 44 000 (с учетом остальных белков, которые не появляются у эукариот) признаков.

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

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

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

По моему опыту, даже очень простая модель способна узнать нечто значимое о свертывании белка. Если задано достаточно параметров (135 миллионов), то после 12 часов обучения на RTX2080 она делает предположения лучше случайных и достаточно часто попадает в пределы 1% от фактического положения атомов.

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

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

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

1. Мы знаем, что пептиды сворачиваются в белки в той инертной среде, которую предполагает большинство наших моделей.
2. Мы знаем, что аминокислоты являются тем компонентом, который полностью описывает пептид.
3. Поскольку окружающая среда всегда одинакова, а сам процесс фолдинга не сильно изменяет ее, проблема не является функцией окружающей среды. Заметьте, что это только в случае фолдинга in vitro, то есть в пробирке, тогда как в живом организме, то есть in vivo, задача сильно усложняется.

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

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

Вот почему наше четвертое правило сложнее всего применить.

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

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

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

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

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

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

В заключение

Я попытался представить несколько простых правил для ответа на вопрос: Как понять, что нейросеть решит проблему?. Какие задачи разрешимы с достаточным поиском архитектуры и текущими возможностями GPU?

Итак, подведем итог. Нейросеть решит вашу проблему:

1. [Почти наверняка]. Когда другие модели ML уже решили эту проблему.
2. [С очень высокой вероятностью]. Если похожая проблема уже решена алгоритмом ML, а различия между этой проблемой и вашей невелики.
3. [С высокой вероятностью]. Если входы и выходы достаточно малы, сопоставимы по размеру с другими рабочими моделями ML, а человек решает задачу без особой необходимости знать контекст.
4. [С разумной вероятностью]. Если входы и выходы достаточно малы, сопоставимы по размеру с другими рабочими моделями ML, и мы достаточно уверены в детерминированной природе проблемы, то есть что результат полностью определен входными данными.

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

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

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

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

Что еще почитать по теме:

1. Искусственный интеллект, нейронные сети и машинное обучение в маркетинге: в чем разница.
2. Форматы файлов в больших данных.
3. Наш телеграм-канал о цифровой трансформации.