Опубликовано: 21.09.2026 | Источник: The Verge – Tech Section

**Семантический анализ** 1. **Primary keyword:** предиктивная аналитика и прогнозные рынки для ВКР 2. **LSI-запросы:** WebSocket-поток данных, event-driven архитектура, Apache Kafka, TimescaleDB, OpenTelemetry, Prometheus, Grafana, alerting вместо дашборда, CEP-правила, rate limiting, идемпотентность, RTO/RPO, ISO/IEC 25010, ГОСТ 34.602-89 3. **Вопросы студентов:** как измерить эффективность системы мониторинга в дипломе; обязательно ли писать код; где брать данные, если API закрыт; как обосновать выбор брокера сообщений; нужен ли интерфейс, если тема — «мониторинг без мониторов» 4. **Ключевые сущности:** ISO/IEC 25010, ГОСТ 34.602-89, ГОСТ 19.701-90, Kubernetes, OpenTelemetry, CI/CD-пайплайн ---

Прогнозные рынки в дипломе: мониторинг событий без классических дашбордов

20 марта 2026 года Polymarket открыл в Вашингтоне поп-ап бар Situation Room — и это не метафора. Внутри не было ни одного экрана с котировками: посетители смотрели не на графики, а друг на друга, на официантов и на собственные телефоны, которые вибрировали, когда вероятность события прыгала выше порога. The Verge описал это как эксперимент: можно ли «мониторить ситуацию» без мониторов. Ответ оказался интереснее самой идеи — данные никуда не делись, изменился только способ их доставки человеку.

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

Три темы ВКР, которые вырастают прямо из кейса

Тема 1. Сервис агрегации вероятностных оценок из нескольких прогнозных площадок

Актуальность. Кейс Polymarket показал: рынок предсказаний стал публичным источником данных с API, а не экзотикой. Одновременно растёт запрос на сравнение нескольких площадок (Kalshi, Manifold, Metaculus) — расхождения между ними сами по себе являются сигналом.

• Цель: разработать сервис сбора, нормализации и хранения временных рядов рыночных вероятностей.
• Задачи: обзор API и лимитов; проектирование модели «событие → рынок → исход → цена»; реализация потокового конвейера; оценка задержек и完整性 данных.
• Структура: Гл. 1 — теория прогнозных рынков и метрик калибровки; Гл. 2 — архитектура (стриминг + колоночное хранилище); Гл. 3 — нагрузочные тесты и расчёт стоимости владения.

Тема 2. Подсистема оповещений «мониторинг без мониторов»

Актуальность. Идея бара без экранов — это alerting-first подход: пользователь получает не поток графиков, а короткое уведомление с контекстом. В DevOps такая логика применяется годами, но в прикладных системах её почти не защищают.

• Цель: спроектировать движок правил и доставки уведомлений с порогами по вероятностям, детекцией скачков и защитой от «шторма».
• Задачи: формализация правил (пороговые, оконные, change-point); выбор брокера; дедупликация и rate limiting; замер ложноположительных срабатываний.
• Структура: Гл. 1 — observability и alerting; Гл. 2 — архитектура правил и очередей; Гл. 3 — эксперимент с задержкой доставки и точностью.

Тема 3. Модель калибровки рыночных вероятностей для оценки рисков

Актуальность. Регуляторный тренд на аудит ИИ-решений означает, что «чёрный ящик» больше не проходит. Рыночная вероятность — объяснимое число, но её нужно калибровать: рынки переоценивают редкие события.

• Цель: построить пайплайн калибровки и сравнить модель с базовыми предикторами.
• Задачи: сбор исторических рядов; метрики Brier score и log loss; подбор калибрующего преобразования; интерпретация результатов.
• Структура: Гл. 1 — теория вероятностного прогноза; Гл. 2 — пайплайн данных и модель; Гл. 3 — валидация и сценарии внедрения.

Аналитическая глава: сравнение решений и обоснование стека

Первая глава — это место, где студенты чаще всего пишут «мы выбрали Kafka, потому что она популярная». Так делать нельзя: комиссия спрашивает про альтернативы. Привяжите сравнение к кейсу — Polymarket оперирует потоками обновлений цен по сотням рынков, и именно частота обновлений диктует выбор.

Отдельно обоснуйте хранилище. Для временных рядов вероятностей логично смотреть в сторону TimescaleDB (знакомая SQL-экосистема, гипертаблицы) или ClickHouse (агрегации по миллионам строк). InfluxDB уместна, если вы умеете объяснить разницу между tag и field — иначе лучше не рисковать на защите.

Проектная часть: схемы, интеграция, код

Здесь статья даёт вам естественный пример для раздела «описание реализации». Конвейер выглядит так: приём потока → буфер → нормализация → хранилище → движок правил → доставка. Каждый переход — это отдельный пункт в главе 2 и отдельная диаграмма.

import asyncio, json, websockets
from aiokafka import AIOKafkaProducer

async def pump(ws_url: str, topic: str) -> None:
    producer = AIOKafkaProducer(bootstrap_servers="kafka:9092",
                                enable_idempotence=True)
    await producer.start()
    try:
        # ping_interval не даёт соединению отвалиться на «тихих» рынках
        async with websockets.connect(ws_url, ping_interval=20) as ws:
            async for raw in ws:
                msg = json.loads(raw)
                key = msg["market_id"].encode()
                await producer.send_and_wait(topic, raw.encode(), key=key)
    finally:
        await producer.stop()

asyncio.run(pump("wss://example/stream", "market.ticks"))

Обратите внимание на три вещи, которые комиссия любит спрашивать: идемпотентность продюсера (защита от дублей при реконнекте), ключ партиционирования (сохранение порядка по конкретному рынку) и отсутствие бизнес-логики в приёмнике. Последнее — это принцип «тонкого приёмника»: нормализацию делайте отдельным консьюмером, иначе при смене формата источника придётся переписывать весь сервис.

Диаграммы оформляйте по ГОСТ 19.701-90, если вуз требует ЕСПД, либо в нотации C4, если кафедра ближе к современным практикам. Главное — единый стиль и подписи на русском. Требования к системе фиксируйте в соответствии с ГОСТ 34.602-89: это тот документ, наличие которого сразу отличает аккуратную работу.

Тестирование и метрики: чем доказывать работоспособность

Самая слабая часть типичной ВКР — раздел «тестирование». Обычно там скриншот запущенного приложения и фраза «система работает корректно». Для потоковой аналитики этого мало: нужно показать поведение под нагрузкой и качество прогноза.

Нагрузочный профиль опишите честно: сколько рынков, сколько подписчиков, какая частота тиков. Синтетический генератор из аналитической таблицы как раз для этого и нужен — он даёт воспроизводимость, которой не бывает с живым API. Скрипт нагрузочного теста можно написать на k6 или Locust и приложить в раздел приложений.

Чему вы научитесь на такой работе

• Проектировать событийные конвейеры и аргументировать выбор брокера, а не выбирать «по хайпу».
• Работать с потоковыми API: реконнект, backoff, идемпотентность, лимиты запросов.
• Строить наблюдаемость через OpenTelemetry, а не через логи в файле.
• Оценивать качество прогноза количественно, а не словами «модель показала хорошие результаты».
• Оформлять техническую документацию по ГОСТ 34.602-89 и ГОСТ 19.701-90.
• Считать экономику внедрения: стоимость инфраструктуры против сэкономленных часов аналитика.

Частые вопросы

Нужен ли реальный доступ к API прогнозной площадки, или хватит моков?

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

Обязательно ли писать код, если тема звучит как «анализ»?

Если в задачах есть слово «разработать» — да, нужен программный продукт или хотя бы прототип. Если работа чисто аналитическая, замените реализацию на вычислительный эксперимент: скрипты обработки данных и воспроизводимые расчёты тоже считаются практическим результатом.

Как оформить UML-диаграммы, если кафедра требует ГОСТ?

Компромисс простой: диаграммы делаете в UML-нотации (это стандарт де-факто), а рамки, основные надписи и перечень элементов оформляете по ЕСПД. Уточните у научного руководителя, какие именно листы он хочет видеть в приложениях, — это экономит неделю переделок.

Хватит ли одного виртуального сервера для стенда?

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

Источник: Can you monitor a situation without monitors? The Polymarket sports bar tried (опубликовано 2026-03-25)