Досвід квантового розробника: системи, моделі та інфраструктура

Шлях до ролі квантового розробника

Освіта та досвід до найму

Диплом інженерного факультету Університету Ватерлоо
Шість стажувань у великих технологічних компаніях та стартапах як розробник програмного забезпечення та інженер машинного навчання
Жодного досвіду у фінансах або квантових фінансах перед влаштуванням на роботу
Після випуску подав сотні заявок на різноманітні квантові позиції

Процес співбесіди (6 раундів)

Раунд 1 — Технічне кодування: система управління портфелем

Завдання: побудувати систему, що відстежує та виконує ордери і підтримує позиції по різних акціях
Включало такі функції, як стоп-лосси та лімітні ордери
Головний висновок: половина того, що оцінює інтерв'юер — це вміння чітко й лаконічно пояснювати хід думок, а не лише технічний результат

Раунд 2 — Алгоритм на основі статистики

Завдання пов'язане з комбінаціями карт у колоді з 52 карт та модифікованими мастями й рангами
Найскладніший раунд — тестував здатність застосовувати статистику до програмування
Кандидат виконав завдання приблизно на 70%, але чітке пояснення ходу думок дозволило пройти далі

Раунд 3 — Системне проєктування з партнерами фірми

Детальний розбір резюме та проєктів
Демонстрація архітектури систем у реальному часі через спільний екран
Питання щодо організації баз даних, інженерії даних та алгоритмів машинного навчання (зокрема, градієнтний бустинг)
Порада: потрібно бути готовим впевнено захищати свої проєкти протягом цілої години

Раунди 4–6 — Фінальні співбесіди з партнерами

Кожен раунд — з іншим партнером окремого підрозділу квантового відділу
Суміш системного проєктування, поведінкових питань та запитань щодо баз даних
Питання про глобальні акції на досить загальному рівні — глибокі знання фінансів не були обов'язковими

Ключова порада щодо технічних співбесід

Завжди промовляйте хід думок уголос під час розв'язання задач
Записуйте розв'язок у псевдокоді перед реалізацією
Відмінна комунікація цінується вище за посередні технічні навички — особливо в нинішньому середовищі технологічної індустрії

Багатофакторна торгова модель: загальна архітектура

Базова концепція: альфа та перевищення над бенчмарком

Мета квантової фірми — перевершити бенчмарк, наприклад індекс
Альфа — це додаткова дохідність понад ринок; якщо бенчмарк зріс на 10%, а портфель на 12%, то 2% — це альфа
Ринкова ціна вже відображає консенсусну думку тисяч учасників, тому завдання — знайти місця, де ви обґрунтовано не погоджуєтеся з консенсусом
Активне управління — це, по суті, прогнозування помилок ринку

Декомпозиція дохідності акцій

Рух акції за будь-який день складається з кількох шарів:
- Загальний рух ринку
- Країновий вплив
- Галузевий вплив (наприклад, нафтові акції рухаються разом з нафтою)
- Ідіосинкратична дохідність — залишок, специфічний для компанії
На практиці ці складові розділяють за допомогою регресії: дохідність акції регресується відносно факторів-драйверів; пояснена частина — це факторна дохідність, а залишок — специфічна дохідність
Навіть для акцій, що тісно корелюють з галуззю, компанієспецифічний залишок зазвичай є значною частиною загального руху

Блоки архітектури багатофакторної моделі

1. Дані та сигнали

Вхідна точка всього конвеєра — як традиційні фінансові дані, так і альтернативні
Із даних будуються сигнали — вимірювані погляди на акцію (вартість, моментум, розмір, якість тощо)
Спочатку потрібно визначити торговий всесвіт — перелік акцій, якими взагалі допустимо торгувати; неліквідні активи виключаються, оскільки великі позиції рухають ціну проти вас

2. Альфи (очищені прогнози дохідності)

Сирий сигнал не можна торгувати безпосередньо — його потрібно перетворити на альфу
Альфа — це добуток трьох складових:
- Волатильність акції
- Інформаційний коефіцієнт — реальна прогностична сила сигналу
- Поточне значення сигналу для конкретної акції
Кожен очищений сигнал стає одним фактором; модель одночасно використовує багато незалежних факторів

3. Модель ризику (паралельно з альфами)

Відповідає на питання: скільки коштуватиме прийнятий ризик у вигляді волатильності
Використовує ту саму декомпозицію: дохідність акції = експозиція до спільних факторів (галузі, індекси ризику) + специфічна частина

Чому факторна модель ризику, а не коваріація між акціями напряму?

Для 1 400 акцій кількість попарних коваріацій складає ~980 000 — неможливо надійно оцінити
Факторна модель: кожна акція — це набір експозицій до ~65 спільних факторів → потрібно оцінити лише ~2 000 коваріацій між факторами
Це перетворює нерозв'язну задачу на обчислювально можливу

Ключові інсайти про ризик

Диверсифікація: ризик портфеля менший за зважену суму ризиків окремих акцій, оскільки вони не рухаються синхронно
Специфічний ризик можна розбавити диверсифікацією; систематичний ризик не зникає, скільки б акцій ви не тримали — це основна ідея CAPM
Ризик у часі: дисперсія накопичується лінійно з часом (за умови відсутності автокореляції), тому ризик зростає пропорційно кореню квадратному з часу — місячну волатильність перетворюють на річну, множачи на √12, а не на 12

4. Побудова портфеля (оптимізатор)

Отримує на вхід альфи та модель ризику
Балансуюча задача: максимізувати очікувану дохідність мінус штраф за ризик мінус транзакційні витрати — при дотриманні обмежень (ліміти позицій, секторна нейтральність, капи на оборотність, ліміти плечового навантаження)
Результат — цільовий портфель: точна кількість кожного активу, яку потрібно тримати

5. Реалізація та торгівля

Філософія: відняти якомога менше вартості від альфи
Складові транзакційних витрат:
- Комісія — плата брокеру за акцію
- Спред між попитом і пропозицією — вартість двосторонньої угоди
- Вплив на ринок — купівля великих обсягів рухає ціну проти вас (аналог принципу невизначеності Гейзенберга у фінансах)
- Альтернативна вартість — упущена вигода через очікування кращої ціни, поки ринок іде вгору
Дефіцит реалізації (implementation shortfall): різниця між гіпотетичним «паперовим» портфелем без витрат і реальним портфелем — загальна міра витрат на виконання

6. Аналіз ефективності

Декомпозиція результатів після факту: скільки надійшло від навмисних факторних ставок, скільки від обмежень, скільки — просто шум
Мета — відокремити майстерність від удачі та знайти джерела справжньої переваги
Фактори завжди деградують у часі — як тільки їх відкривають усі, перевага зникає, тому пошук нових факторів — безперервний процес

Фундаментальний закон активного управління

Два ключові показники

Інформаційне відношення (IR): активна дохідність / активний ризик — «табель успішності» менеджера
Фундаментальний закон: IR ≈ Майстерність × √Широта, де широта — кількість незалежних ставок

Чому незалежність ставок є визначальною

Якщо ви маєте 5 довгих позицій у роздрібному секторі та 5 коротких в енергетиці — це 2 ставки, а не 10
Справжня широта означає по-справжньому різні рішення по назвах та в часі
Багатофакторна модель — це машина для генерації широти: тисячі малих, незалежних, дещо кращих за рівні ставок щодня по всьому ринку
Квадратний корінь показує, що накопичення широти перетворює скромну перевагу на кожну ставку на серйозну сукупну перевагу

Дані та сигнали: практична реалізація

Альтернативні дані

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

Підбір цінних паперів (Security Matching)

Процес зіставлення сутностей у наборі даних (наприклад, URL-адреса apple.com) з внутрішніми ідентифікаторами фірми
Стандартні ідентифікатори: ISIN, CUSIP, Bloomberg ID
Ключова вимога — прив'язка до точки в часі (point-in-time): ідентифікатор дійсний лише для тих часових проміжків, коли він реально використовувався — інакше виникає упередження на майбутнє (look-ahead bias)
Набори даних часто мають обсяг кілька терабайт і потребують розподілених обчислень та ефективних інструментів (Polars, Spark, NumPy)

Очищення та аудит даних

Дані від постачальників ніколи не надходять чистими; стандартна робота включає перевірку викидів, заповнення пропусків, виправлення форматів, узгодження між постачальниками
Завантажувачі даних (data loaders): унікальні для кожного постачальника механізми оновлення — тягнуть нові дані, виконують трансформації та зберігають у внутрішню базу; збій завантажувача зупиняє відповідний торговий фактор
Аудит даних: статистичні метрики по колонках, перевірка покриття цінних паперів; при перевищенні порогових значень спрацьовує сповіщення для відповідальної особи

Виробнича реалізація торгових факторів

Процес переведення в продакшн

Дослідницький код (зазвичай на R) конвертується в Python, Spark або KDB
Розробнику надається документ Word із повною методологією фактора — центральний орієнтир для всієї команди
Документація критично важлива: фактори потребують повторних досліджень через деградацію, і чітка документація прискорює майбутні проєкти

Розподілені обчислення та часові вікна

Повний історичний прогін (5–15 років даних) займає від півдня до цілого дня з розподіленими обчисленнями
Торгові фактори мають жорсткі часові вікна оновлення: при торгівлі глобальними акціями після закриття Нью-Йоркської біржі є лічені години до відкриття японського ринку

Командна структура

Кожен проєкт ведеться малою групою: дослідник, розробник, тестувальник та кілька старших партнерів для нагляду
Ефективні, злагоджені групи зберігаються разом для майбутніх проєктів

Інфраструктура: міграція до хмари

Від власних серверів до хмарних рішень

Спочатку всі обчислення відбувалися на власних серверах у офісі
Зростання команди, збільшення обсягів даних та складності факторів зумовили міграцію до AWS та Databricks

Ключові сервіси AWS

EC2 — обчислювальні інстанції
ECR — реєстр контейнерів
S3 — об'єктне сховище

Apache Spark: рушій масштабованих обчислень

Архітектура та принцип роботи

Розподілений рушій обробки даних в оперативній пам'яті
Компоненти:
- Драйвер — «мозок», що зберігає програму та будує план виконання
- Виконавці (executors) — робочі вузли по всьому кластеру, що паралельно обробляють дані
- Менеджер кластера — розподіляє машини
- Набір даних розбивається на партиції, кожен виконавець обробляє свою партицію одночасно

Ліниве виконання та оптимізатор Catalyst

Spark не виконує трансформації одразу — він будує граф кроків (план виконання) і чекає на дію (запис результату, підрахунок рядків тощо)
Оптимізатор запитів Catalyst переглядає весь план цілком і переписує його для максимальної ефективності:
- Проштовхування фільтрів до джерела даних — зчитується лише необхідне
- Оптимальне перевпорядкування з'єднань
- Усе це відбувається до обробки жодного байту реальних даних

Обробка в оперативній пам'яті

Стара модель MapReduce записувала проміжні результати на диск між кожним кроком
Spark зберігає дані в пам'яті між кроками, що робить його на порядок швидшим для багатоетапних конвеєрів

Відмовостійкість через лінійність

Spark пам'ятає лінійність — рецепт трансформацій, що породив кожен шматок даних
Якщо машина виходить з ладу, він просто перераховує втрачений фрагмент замість провалу всього завдання

Перемішування (Shuffle) як головний виклик

Деякі операції (з'єднання, групування) потребують переміщення даних між машинами по мережі, щоб пов'язані рядки опинилися разом
Саме це переміщення є найдорожчою частиною
Більшість оптимізації Spark зводиться до мінімізації та контролю перемішувань

Практичний приклад: обробка терабайтного набору альтернативних даних

Spark читає партиції з S3, розподіляючи їх між виконавцями
Завдяки ліниві виконанні проштовхує фільтри за датами та колонками — зчитує лише потрібне
Паралельно виконує трансформації на кожній партиції: очищення, агрегація, обчислення ознак
Для підбору цінних паперів — широкомовне з'єднання (broadcast join): невелика таблиця відповідностей розсилається на кожен виконавець, тому з'єднання відбувається локально без перемішування
Результат партиціонується за датою та записується у таблицю Delta Lake для подальшого споживання торговим фактором

Історичний прогін, який на одній машині тривав би дні, скорочується до годин

Сховища даних у квантовій сфері

Чому вибір бази даних є принциповим

Місце зберігання даних — не другорядне рішення, воно безпосередньо визначає продуктивність усієї системи
Близько 80% співбесід на позиції квантового розробника містили конкретні запитання про бази даних
Найпоширеніші теми: Parquet / Delta Lake та KDB

Parquet і Delta Lake: масштабований архів для досліджень

Формат Parquet: стовпцева організація даних

Звичайна база даних зберігає всі поля запису разом у рядку
Parquet перевертає цю логіку: кожен стовпець зберігається разом
Переваги для квантових задач (де зазвичай потрібно кілька стовпців по мільйонах рядків):
- Зчитуються лише запитані стовпці — решта не чіпається
- Чудове стиснення — схожі значення розміщені поруч
- Пропуск чанків, що гарантовано не відповідають фільтру

Delta Lake: транзакційний шар поверх Parquet

Самі по собі папки з файлами Parquet не мають поняття про атомарні зміни
Delta Lake додає журнал транзакцій, що забезпечує гарантії ACID:
- Атомарність — запис або відбувається повністю, або не відбувається взагалі
- Узгодженість — читач ніколи не бачить наполовину записану таблицю
- Ізольованість — паралельні завдання не псують одне одного
- Довговічність — зафіксовані дані не губляться
Примусове дотримання схеми — погані дані не проникають непомітно

Чому Delta Lake ідеально підходить для квантових часових рядів

Дані партиціонуються за датою: запит за 10 роками по кількох полях сканує лише потрібні партиції та стовпці
Щоденні оновлення — просте додавання нової партиції, швидко та дешево
Версіонування та подорож у часі: завдяки журналу транзакцій можна запросити таблицю в будь-якому минулому стані — критично важливо для прив'язки до точки в часі при бектестингу факторів
Відтворюваність: якщо постачальник переглядає історичні дані, можна чисто перезаписати лише відповідні партиції
Зберігання на дешевому об'єктному сховищі (S3) з паралельним зчитуванням — пропускна здатність масштабується з розміром кластера

KDB та мова Q: рушій живої торгівлі

Що таке KDB

Стовпцева база даних часових рядів в оперативній пам'яті, побудована з нуля для фінансових даних
Розрахована на величезні потоки тікових даних і котирувань із мітками часу

Мова Q: векторизована лаконічність

Надзвичайно стисла та векторизована — невеликі вирази оперують цілими стовпцями одразу (подібно до NumPy)
Виконується дуже близько до «заліза» — мінімальні накладні витрати

Ключова перевага: з'єднання за станом на момент часу (as-of join)

Для кожної угоди потрібно знайти котирування, яке діяло саме в той момент
Ця операція повсюдна у фінансах і болісно повільна у звичайних базах даних
У KDB — це первинна операція, блискавично швидка за замовчуванням

Поєднання KDB та HTCondor на практиці

KDB зберігав і обслуговував дані часових рядів на великій швидкості
HTCondor — планувальник завдань, що розподіляв обчислення торгової моделі по сітці машин поверх KDB

Порівняння двох підходів до зберігання

Характеристика	Parquet / Delta Lake	KDB
Призначення	Дослідження та пакетна обробка	Жива торгівля та часові ряди
Масштаб	Терабайти, роки історії	Швидкість у реальному часі
Головна перевага	Версіонування, дешевизна, масштабування	Сирова швидкість на тікових даних
Типове використання	Бектестинг факторів, архів	Живий торговий рушій

Більшість фірм використовують обидва підходи, оскільки вони вирішують принципово різні задачі

Загальний підсумок: єдина зв'язана система

Весь описаний матеріал складається у єдину картину багатофакторної машини, де кожен блок існує з конкретною причиною та органічно пов'язаний з рештою — саме так це відчувається зсередини реальної квантової фірми:

Блок даних → підбір цінних паперів, очищення, альтернативні дані
Блок альф → конвеєр від дослідження до продакшну
Блок ризику та оптимізації → факторна модель ризику, побудова портфеля
Блок реалізації → торгівля, транзакційні витрати
Інфраструктура → Spark, Parquet, Delta Lake, KDB, HTCondor — усе, що змушує систему працювати вчасно