Почему точное сравнение полей не ловит дубли

Классический дедуп в CRM сравнивает строки: совпал телефон — дубль, совпал e-mail — дубль. В реальности лид с сайта приходит как «ООО Ромашка», из Авито — «Ромашка ООО», из входящего звонка менеджер вбивает «Ромашка, Иван Петров», а из мессенджера — «ромашка_мск». Телефон записан в трёх форматах, почта — то личная, то корпоративная. Формально это четыре разные записи, фактически — одна компания с одним бюджетом и одним менеджером.

Правила «строгое равенство» дают либо пропуски, либо ложные срабатывания. Семантический дедуп решает задачу иначе: он сравнивает не строки, а смысл записей, приведённых к сопоставимому виду.

Как ИИ видит дубли

Каждое поле превращается в вектор — числовое представление смысла. Название компании, ФИО, адрес и текст заявки кодируются эмбеддингами (для русского хорошо работают ruBERT-семейство, bge-m3, multilingual-e5), после чего близость считается по косинусной метрике. «Ромашка», «Ромашка Мск» и «Ромашка-Москва» оказываются рядом в векторном пространстве, а «Ромашка» и «Ромашково» — нет.

Дальше включается гибридная логика. Жёсткие идентификаторы (ИНН, ОГРН, нормализованный телефон в формате E.164, e-mail) дают детерминированное решение. Нечёткие поля — название, ФИО, адрес, домен почты — работают как признаки для модели сопоставления записей (entity resolution), которая выдаёт итоговую вероятность «это один и тот же клиент».

Поиск кандидатов идёт не по всей базе, а через блокинг: вектора складываются в pgvector или FAISS, и для новой записи поднимаются 20–50 ближайших соседей. Это позволяет проверять дедуп на потоке, а не ночным скриптом.

Где проходит граница автоматизации

Ключевая настройка — пороги. Обычно их три: выше 0,92 — автослияние, 0,75–0,92 — серая зона на подтверждение оператору, ниже 0,75 — разные записи. Пороги калибруются на размеченной выборке, а не «на глаз»: для каждого уровня считается precision и recall, и бизнес сам выбирает, что дороже — потерянный дубль или склеенные карточки двух разных клиентов.

Обязательны журнал слияний, сохранение исходных значений и возможность разъединить записи. Без этого первая же ошибка модели превращается в невосстановимую потерю истории сделок и переписки.

Практические шаги внедрения

1. Аудит. Выгрузите 10–20 тыс. записей из CRM, вручную разметьте 300–500 пар «дубль / не дубль» — это эталон для проверки модели.
2. Нормализация. Телефоны — к E.164, e-mail — к нижнему регистру, юр. форму и ИНН — в отдельные поля, адреса — через ФИАС/ГАР.
3. Векторизация. Выберите модель под русский язык, прогоните поля и сохраните эмбеддинги в векторном хранилище рядом с CRM.
4. Гибридные правила. ИНН и телефон — автослияние, остальное — через модель с порогами и ручным подтверждением.
5. Пилот на одном канале. Например, только лиды с сайта и Авито, две недели, замер доли дублей до и после.
6. Мониторинг. Раз в месяц — контрольная выборка и пересчёт метрик: качество данных деградирует вместе с ростом базы.

Российская специфика

В российских CRM (Bitrix24, amoCRM, 1С:УТ) дедуп осложняют транслитерация названий, разные юрлица одной группы компаний и лиды, приходящие с классифайдов и мессенджеров без единого идентификатора. Данные клиентов — персональные, поэтому модель и векторная база обычно разворачиваются в локальном контуре, без передачи записей во внешние API. Отдельная тонкость — не сливать в одну карточку разные ИНН: это разные плательщики, даже если названия совпадают.

Как мы можем помочь

Мы внедряем семантический дедуп как часть ИИ-контура вокруг CRM: нормализация данных, локальные эмбеддинги, гибридные правила слияния, интеграция с Bitrix24, amoCRM и 1С, панель ручного разбора серой зоны и метрики качества. Начинаем с аудита вашей базы и пилота на одном канале, чтобы вы увидели реальную долю дублей до масштабирования. Обсудить проект