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

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

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

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

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

Часть 1: Условные обозначения сомнений

Часто многие условности в финансах скрыты за масками и зеркалами или спрятаны у всех на виду. Они могут быть основаны на модели, например. Оптимизация средней дисперсии, ценообразование опционов Блэка-Шоулза, гребневая/ограниченная/панельная регрессия для прогнозирования. Они могут быть стандартами практики кодирования, например. использование модульного тестирования, уровней абстракции внутри методов/классов и уровней распределенных/нераспределенных вычислений.

Знайте, что причины некоторых из этих условностей часто менее загадочны, чем может показаться на первый взгляд; они никоим образом не рациональны, но в некоторых есть рациональность. Избегайте натуралистической ошибки «то, что есть, не равно тому, что должно быть» или, более красиво выраженное Юмом , «что различие между пороком и добродетелью не основано только на отношениях объектов».

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

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

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

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

Часто ни у кого не было времени или терпения, чтобы прийти и создать более общую всеобъемлющую модель, поскольку погоня за «альфой» и новыми идеями часто имеет приоритет — Брахма (создатель) часто более сексуален, чем Вишну (поддерживающий ) и Шива (разрушитель). Если не выполнять обслуживание и сокращение кода, то долгосрочным недостатком здесь может быть создание избыточности в коде и классах сигналов, которые на практике в конечном итоге коррелируют друг с другом.

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

Чтобы нормализовать и обобщить эти условности, требуется время, и часто об этом часто забывают. Полезной эвристикой здесь будет тратить 10–20 % рабочей недели (или 1–2 дня в течение 10 дней) на очистку, абстрагируя все, что можно, в отдельные методы, классы и расширение существующих.

Иногда более конкретное или сложное решение упускается из виду или, скорее, ему не уделяется внимание из-за производительности. Особенно по мере того, как вы переходите от более быстрых шкал времени от часов к минутам, вы можете заметить, что экономия занимает первое место по сложности. Мой бывший коллега придумал фразу «Масштаб — враг сложности». Если обучение ансамблевой модели с линейными и нелинейными комбинациями признаков занимает больше времени, возможно, потребуется отойти на задний план и перейти к линейной модели с тем же набором признаков.

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

Повышение производительности — альтернативная стоимость оптимизации

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