Методы градиента политики PG довольно популярны в обучении с подкреплением (RL). Базовый принцип состоит в использовании градиентного спуска и подъема в направлениях, где ожидается наибольшая награда. Но при первом приближении оптимизация получается неаккуратной. При чрезмерной самоуверенности мы можем сделать действия, которые разрушат прогресс, достигнутый предыдущей тренировкой. Работы, посвященные TRPO, являются наиболее цитируемыми по этой проблеме. При этом его объясняют без должного введения в три базовые концепции: MM алгоритм, регион доверия и выборка по значимости (перенормировка).

Это давно назревшая статья об обучении с подкреплением Reinforcement Learning (RL). RL – крутая тема!

Вы, возможно, знаете, что компьютеры теперь могут автоматически учиться играть в игры ATARI (получая на вход сырые игровые пиксели!). Они бьют чемпионов мира в игру Го, виртуальные четвероногие учатся бегать и прыгать, а роботы учатся выполнять сложные задачи манипуляции, которые бросают вызов явному программированию. Оказывается, что все эти достижения не обходятся без RL. Я также заинтересовался RL в течение прошлого года: я работал с книгой Ричарда Саттона (прим.пер.: ссылка заменена), читал курс Дэвида Сильвера, смотрел лекции Джона Шульмана, написал библиотеку RL на Javascript, летом проходил практику в DeepMind, работая в группе DeepRL, и совсем недавно — в разработке OpenAI Gym, – нового инструментария RL. Так что я, конечно, был на этой волне, по крайней мере, год, но до сих пор не удосужился написать заметку о том, почему RL имеет большое значение, о чем он, как все это развивается.


Примеры использования Deep Q-Learning. Слева направо: нейросеть играет в ATARI, нейросеть играет в AlphaGo, робот складывает Лего, виртуальный четвероногий бегает по виртуальным препятствиям.

В целом ответ – да. Особенно, когда есть мозги и знание теоремы Байеса.

Напомню, что среднее и дисперсию можно считать только, если у вас имеется определенное количества событий. В старых методичках СССР РТМ (руководящий технический материал) говорилось, что чтобы считать среднее и дисперсию необходимо 29 измерений. Сейчас в ВУЗах немного округлили и используют число 30 измерений. С чем это связано – вопрос философский. Почему я не могу просто взять и посчитать среднее, если у меня есть 5 измерений? По идее ничто не мешает, только среднее получается нестабильным. После еще одного измерения и пересчета оно может сильно измениться и полагаться на него можно начиная где-то с 30 измерений. Но и после 31го измерения оно тоже пошатнется, только уже не так заметно. Плюс добавляется проблема, что и среднее можно считать по разному и получать разные значения. То есть из большой выборки можно выбрать первые 30 и посчитать среднее, потом выбрать другие 30 и тд … и получить много средних, которые тоже можно усреднять. Истинное среднее бывает недостижимо на практике, так как всегда имеем конечное количество измерений. В таком случае среднее является статистической величиной со своим средним и дисперсией. То есть измеряя среднее на практике мы имеем в виду «предположительное среднее», которое может быть близко к идеальному теоретическом значению.

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

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

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


В организации, где я работаю, автоматизируют бизнес процессы, и обычно это связано с ведением базы данных. У нас принято работать по канонам, — сначала проводить бизнес анализ, составлять умное ТЗ, писать код, проводить тестирование и много всякой деятельности при дефиците времени. Первичная мотивация, вроде разумная, — “давайте будем разделять обязанности”, “давайте будем делать так, чтобы было безопасно” и тд и тп. Все эти приемы менеджмента с восторгом преподают на различных курсах, обещая много хайпа и охмурянта. Надеюсь, что читатель уже знаком с некоторыми модными словами, которые зачастую ни потрогать, ни налить нельзя. Но вопрос не об них, а о том, как программисту жить с ними.

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

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

Если имеется 2 предприятия, тогда вероятность того, что они оба обанкротятся, и мы потеряем все вложения $$. Так учит стандартная теория вероятности. Но что будет, если предприятия связаны, и банкротство одного ведет к банкротству другого?

Крайним случаем является ситуация, когда предприятия полностью зависимы. Вероятность двойного банкротства $$( банкрот1 & банкрот2 ) = $$( банкрот1 ), тогда вероятность потери всех вложений равна $$. Методика оценки риска имеет большой разброс $$ от 0.05 до 0.0025 и реальное значение зависит от того, насколько правильно мы оценили связанность двух событий.


При оценке инвестиций в $$ предприятий имеем $$ от $$ до $$. То есть максимальная возможная вероятность остается большой $$, и старая поговорка «не клади яйца в одну корзину» не сработает, если упадет прилавок со всеми корзинами сразу.

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

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

Если кораблю некуда плыть, то ни одна карта не покажет правильный маршрут

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

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