⁣Feature Aliasing в real-time пайплайнах: как отлавливать синонимы признаков с помощью графов, когда нет времени на батч-джойн

Когда один и тот же признак приходит под десятком имен в real-time потоке, модель либо видит разреженные фичи, либо учит шум. В продакшене это вылезает в момент масштабирования, когда rule-based маппинг на if-else превращается в ад поддержки, а словарь синонимов растет быстрее, чем инфраструктура.

Проблема: синонимы множатся, latency не прощает

user_id, userId, user.id — в батче это смержили бы за один join. В real-time пайплайне с миллионами событий в секунду такая роскошь недоступна. Rule-based подход с конфигами работает до первого расширения, а потом каждое новое имя фичи требует правки кода и редеплоя. Ошибка, которую я вижу чаще всего — попытка поддерживать словарь синонимов вручную или через regex, что ломается на первом же нестандартном паттерне.

Решение: graph-based дедупликация с Union-Find

Подход, который работает в реальном продакшене: строится граф синонимии, где вершины — это имена признаков или их значения, а ребра — семантическая или статистическая связь. Затем через Union-Find (или Connected Components) выделяются канонические группы. В прототипе подойдет NetworkX, но в production нужно инкрементальное обновление.

Пример кода для ядра логики:

class UnionFind:
    def __init__(self):
        self.parent = {}
    def find(self, x):
        if self.parent.setdefault(x, x) != x:
            self.parent[x] = self.find(self.parent[x])
        return self.parent[x]
    def union(self, x, y):
        px, py = self.find(x), self.find(y)
        self.parent[px] = py

Этот код — основа. В real-time пайплайне граф должен динамически обновляться: новые алиасы выявляются через HLL sketch или LSH, а сам граф живет в Redis или RocksDB. Если latency меньше 10ms — предвычисляй и загружай в память при старте стрима.

Production сценарий: Kafka Streams и перестройка графа

На практике это выглядит так: на этапе Kafka Streams каждый новый признак прогоняется через lookup-таблицу связности, где Union-Find возвращает каноническое имя. Раз в час граф перестраивается по свежим логам — это позволяет учитывать новые синонимы без остановки потока. Типичный выигрыш — cardinality фичей падает на 30-50%, что напрямую снижает размерность модели и latency инференса.

Trade-offs и предупреждение

Подход особенно окупается в мультитенантных системах, где датасеты от разных команд с разным неймингом, в A/B тестах, где колонки переименовывают на лету, или когда feature engineering делают руками без CI/CD. Но здесь есть ключевой trade-off: скорость против точности. Если гнаться за каждым синонимом — граф разрастается, latency растет. Если реже — часть алиасов остается, и модель снова видит шум. Ошибка: пытаться найти все синонимы сразу. Лучше начинать с Union-Find, потом делать incremental clustering, постепенно расширяя на HLL-sketches для редких паттернов.

Вывод:
Graph-based дедупликация с Union-Find и инкрементальным обновлением в Redis — это инженерный баланс между гибкостью и latency, который решает проблему feature aliasing без тонн мусорного кода в real-time пайплайнах.