Новая уязвимость в данных для ML: как Event Time и Watermarks обманывают модели

Недавний инцидент в одном из банковских проектов показал, как хитроумные механизмы обработки данных могут подвести даже самую продвинутую модель машинного обучения. Разработчики столкнулись с парадоксом: система Apache Flink, известная своей стабильностью и скоростью обработки потоков, работала без нареканий, данные из Kafka не терялись и не задерживались, а модель антифрода получала на вход заведомо искажённые признаки. Например, при пяти последовательных транзакциях за две минуты модель видела всего три операции в десятиминутном окне. В результате вероятность мошенничества вместо ожидаемых 91% снижалась до 42%, что могло привести к пропуску реального мошеннического сценария. Этот случай заставил специалистов всерьёз задуматься о том, как современные системы работы с данными — от стриминговых фреймворков до механизмов назначения временных меток — влияют на качество машинного обучения, которое принимает критически важные решения в финансах, здравоохранении и других сферах.

Проблема кроется в том, как системы назначают временные метки данным. Event Time — это концепция, при которой события получают временные метки не в момент их фактического поступления в систему (Processing Time), а на основе времени, когда они произошли в реальности. Казалось бы, это логично: если транзакция совершена в 14:00, то и временная метка должна быть 14:00, а не 14:02, когда данные попали в систему. Однако на практике Event Time требует дополнительной логики для обработки данных, которые приходят с задержкой — например, из-за сетевых задержек или проблем на стороне клиента. Для этого используются водяные знаки (Watermarks) — механизм, который позволяет системе понять, когда можно безопасно считать все данные за определённый интервал времени полученными и начать их обработку. Но именно здесь и кроется подвох: водяные знаки могут как помогать системе оставаться согласованной, так и создавать иллюзию отсутствия данных, если их задержка превышает установленный порог.

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

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

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