Как я склеиваю 23 тысячи событий из пяти афиш — и почему дедуп нельзя делать необратимым
«Окрест» собирает афиши по 16 городам из Яндекс Афиши, Afisha.ru, Timepad, KudaGo и телеграм-каналов площадок. В базе 23 097 активных событий: 8260 приходят из двух источников, 533 — из трёх, ещё десять — из четырёх. Кандидаты на объединение сначала ограничиваются одной площадкой и одним календарным днём в фиксированном часовом поясе; SQL берёт окно плюс-минус сутки, а окончательная проверка дня выполняется в Python.
Названия транслитерируются в два вида: компактный ключ без пробелов и пунктуации нужен для точного совпадения, а строка с сохранёнными словами — для token_sort_ratio. Автоматическое объединение проходит при score от 92, спорные пары начинаются от 85; разные годы, части и номера блокируют склейку, а список из 51 служебного слова позволяет считать «Света» и «Света. Большой сольный концерт» одним событием. При точном совпадении площадки и секунды начала правила можно ослабить, хотя мультизальные площадки оставляют риск ложных объединений.
Сложные пары доходят до LLM только после предварительных фильтров: при совпадении точного времени используется порог уверенности 0,7, при совпадении только дня — 0,95. Решения кэшируются в Redis на 30 дней, а ошибки вызова трактуются как несовпадение. Слабое место системы в том, что ручной очереди нет, исходный дубль после слияния удаляется, а фоновая проверка замечает лишь события, оказавшиеся на нескольких физических площадках.
Коротко
- Площадки сначала нормализуются по названию, адресу, городу и расстоянию; пары «Большой зал» и «Малый зал» блокируются словарём антонимов.
- Изменение уникального ключа площадки с (name, address) на (name, address, city) потребовало синхронно обновить все выражения ON CONFLICT.
- Фоновый скрипт каждые 15 минут ищет event_id, связанные с несколькими физическими местами, и разделяет их обратно на отдельные события.
- В ключ Redis входят только два отсортированных названия, поэтому после смены модели или промпта старые решения могут жить в кэше ещё 30 дней.
FAQ
Зачем при дедупликации событий сохранять исходные записи и возможность отката, если большинство дублей алгоритм объединяет автоматически?
Ложное объединение незаметно удаляет одно из реальных событий, а текущая фоновая проверка ловит только случаи, когда запись связалась с разными физическими местами. Без исходных строк восстановить потерянное событие нельзя.
Почему точное совпадение площадки и секунды начала позволяет мягче сравнивать названия, но не гарантирует корректную склейку?
Точный слот служит сильным якорем: на одной сцене обычно не начинается два показа в одну секунду. Но один venue_id может объединять несколько залов или экранов, поэтому совпадение времени не исключает ошибку.
Когда спорную пару передают в LLM и какие данные модель получает для решения о том, относится ли она к одному событию?
LLM вызывается после предварительных фильтров для редких сложных пар: при точном времени действует порог 0,7, при совпадении только дня — 0,95. В промпт передаются только два названия, без площадки, времени и категории.
Читайте также
Публичность или небытие: как ИИ меняет цену знания- Бот в MAX молчит: четыре проблемы Bot API, о которых не пишут в документации
- Как показывать клиентам документацию из приватного репозитория, не открывая им доступ к репозиторию
- Перевёз ИИ-агентов на российский сервер. Оказалось, полмира с ним разговаривать не хочет
- Что такое качественный антидетект-браузер и почему мы написали свой, когда рынок уже перегрет
- Обратимая дедупликация вместо удаления исходных записей: При объединении дублей исходные записи нельзя безвозвратно удалять: ошибочная склейка может незаметно уничтожить отдельное событие, объявление или рекламный объект. Безопасная схема должна хранить исходные сущности, историю решений и механизм отката к состоянию до объединения.
[Дедупликация данных]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Сервис «Окрест» сводит в одну запись дубли событий из пяти источников, но делает это не по одному названию, а по связке площадки, даты, времени и нескольких уровней текстового сравнения. Главный риск схемы — ошибочная склейка удаляет реальное событие без возможности отката.