Конвейер данных и сигналов для AI-инвестирования
Как спроектировать серверный конвейер, который получает рыночные и альтернативные данные, строит ML-сигналы, проверяет риск и передаёт решение в торговый контур?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Потоки данных нормализуются по времени и инструментам, проходят контроль качества и сохраняются с версией. Отдельный контур строит признаки и сигналы, риск-слой применяет лимиты, а исполнение получает только идемпотентную заявку с полным журналом происхождения.
Подробный разбор
Источники — котировки, сделки, фундаментальные и альтернативные данные — сначала приводятся к единой схеме времени и идентификаторов инструментов. Конвейер проверяет опоздания, дубли, пропуски и корпоративные действия, затем сохраняет сырой и нормализованный слой, чтобы исследование и воспроизведение использовали одни данные. Признаки рассчитываются point-in-time без знания будущего, а версия модели и конфигурации записывается вместе с каждым сигналом.
Модель не должна напрямую отправлять приказ на рынок. Риск-слой проверяет позицию, ликвидность, концентрацию, дневной убыток и аварийные ограничения, после чего формирует идемпотентное поручение для системы исполнения. Нужны журнал решений, сверка заявок и сделок, мониторинг задержки и качества данных, теневой режим и возможность быстро отключить новую модель.
Как оценить ресурсы Kafka и Spark для миллионов событий в секунду
Если панель CTR получает миллионы событий в секунду, как оценить число разделов Kafka и обработчиков Spark и где искать узкое место?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Расчёт начинают с пиковой частоты событий, их размера и измеренной пропускной способности одного раздела и обработчика. Основной объём обычно создают показы, а не клики.
Подробный разбор
Оценка начинается с нагрузки: средний поток умножают на коэффициент пика, переводят в байты в секунду и делят на измеренную пропускную способность одного раздела Kafka и одного обработчика. К результату добавляют запас на отказ узла и перераспределение разделов. Для CTR почти вся нагрузка обычно приходится на показы, потому что кликов на порядок меньше.
Проверять нужно всю цепочку: сериализацию и сеть, перекос ключей, shuffle, состояние окон, контрольные точки и скорость записи в ClickHouse. Оценку подтверждают нагрузочным тестом. Наблюдают отставание потребителей, задержку обработки, длительность контрольных точек, ошибки записи и p95 задержки API.
Как интерпретировать backtest при возможном leakage
Как сравнивать модели прогноза, если LLM-extractor может знать будущие факты из pretraining?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Сравнение остается полезным, если явно ограничить evidence path, добавить leakage flags и сравнивать не LLM “как oracle”, а extractive pipeline с проверяемыми источниками.
Подробный разбор
Backtest нельзя трактовать как честную оценку будущего, если LLM могла видеть future facts. Но его можно использовать для сравнения controlled variants: один и тот же document set, одинаковый retrieval cutoff, одинаковые schema validators и одинаковая табличная модель.
Отдельно нужно считать leakage-sensitive slices: события после cutoff, документы с поздней публикацией, редкие крупные изменения. Если LLM-фичи дают слишком резкий прирост именно на таких срезах, результат требует ручной проверки. Production-критерий - не только RMSE/MAPE, но и auditability: можно ли показать, из какого доступного источника появилась фича.