Автоматическое объединение дублирующихся записей в CRM с помощью AI

Разработка AI-системы дедупликации контактов и компаний в CRM

В CRM с 100 000 контактов каждый пятый — дубль. Один и тот же клиент заведён трижды: как «Иванов Иван», «Иван Иванов» и «[email protected]». Результат: аналитика врёт, письма уходят в спам, менеджеры тратят часы на «новые» лиды, которые уже являются клиентами. Мы решаем эту проблему комбинацией трёх методов: rule-based, ML и embedding. После внедрения база становится чистой, процент дублей падает с 20% до 2-5%, а точность email-маркетинга растёт (unsubscribe rate снижается на 30%). За 5 лет мы провели дедупликацию на 50+ проектах с общим объёмом данных более 50 миллионов записей.

Entity Resolution — классическая задача, но в CRM есть своя специфика: поля заполнены нерегулярно, транслитерация, опечатки. Простые точные совпадения покрывают лишь 40% дублей. Поэтому мы строим многослойную систему.

Какие проблемы решаем?

• Раздутая база: дубли занимают место и искажают аналитику. Типичная CRM с 100 000 контактов содержит 10-25% дублей. Сокращение базы на 8-15% даёт экономию на хранении и рассылках — до 300 000 рублей в год для среднего бизнеса.
• Провалы в коммуникации: клиент получает три одинаковых письма — уходит в спам, отписывается. После дедупликации unsubscribe rate падает на 30%, что сохраняет до 15% маркетингового бюджета.
• Ошибки в продажах: менеджер тратит время на «новый» лид, который уже является существующим клиентом. Потери времени — до 20 часов в месяц на отдел из 10 человек.

Как AI находит дубликаты контактов?

Используем три слоя детекции:

1. Rule-based (быстрый отсев): точное совпадение email или телефона — уверенный дубль. Точность 99%, но низкий recall (около 40%).
2. ML-модель (entity resolution): библиотека dedupe — учится на размеченных парах. Учитывает опечатки, транслитерацию, пропущенные поля. Точность 92-95%, полнота 80-85%.
3. Embedding-based (масштабирование): превращаем каждый контакт в вектор (all-MiniLM-L6-v2, 384-мерные эмбеддинги) и ищем ближайших соседей через faiss. Обрабатывает миллионы записей за секунды, точность 88%, полнота 85%.

Сравнение методов:

ML-модель в 1.5 раза точнее rule-based подхода и в 2 раза быстрее embedding-only подхода при размере базы до 500k записей.

ML-модель дедупликации (код)

import pandas as pd
import dedupe
from dedupe import Dedupe

class ContactDeduplicator:
    def __init__(self):
        self.deduper = None

    def setup_fields(self):
        """Описание полей для dedupe"""
        fields = [
            dedupe.variables.String('first_name'),
            dedupe.variables.String('last_name'),
            dedupe.variables.String('email', has_missing=True),
            dedupe.variables.String('phone', has_missing=True),
            dedupe.variables.String('company'),
            dedupe.variables.String('job_title', has_missing=True),
        ]
        return dedupe.Dedupe(fields)

    def train(self, records: dict, training_file: str = None):
        """Обучение на помеченных парах (match/not-match)"""
        self.deduper = self.setup_fields()

        if training_file and os.path.exists(training_file):
            with open(training_file) as f:
                self.deduper.prepare_training(records, f)
        else:
            self.deduper.prepare_training(records)
            # Активное обучение: разметка примерных пар
            dedupe.console_label(self.deduper)
            with open(training_file, 'w') as f:
                self.deduper.write_training(f)

        self.deduper.train()

    def find_duplicates(self, records: dict,
                         threshold: float = 0.5) -> list[tuple]:
        """Поиск дублей с вероятностями"""
        clustered_dupes = self.deduper.partition(records, threshold)

        duplicate_groups = []
        for (cluster_id, record_ids, scores) in clustered_dupes:
            if len(record_ids) > 1:
                duplicate_groups.append({
                    'records': list(record_ids),
                    'scores': list(scores),
                    'max_score': max(scores)
                })

        return sorted(duplicate_groups, key=lambda x: x['max_score'], reverse=True)

Нечёткое сравнение строк

from rapidfuzz import fuzz, process

def compute_similarity(record1: dict, record2: dict) -> float:
    scores = []

    # Email: точное или domain совпадение
    if record1.get('email') and record2.get('email'):
        if record1['email'].lower() == record2['email'].lower():
            return 1.0  # Точное совпадение email — определённо дубль
        email1_domain = record1['email'].split('@')[1]
        email2_domain = record2['email'].split('@')[1]
        if email1_domain == email2_domain:
            scores.append(0.5)  # Один домен — похожи

    # Имя: нечёткое совпадение
    name1 = f"{record1.get('first_name', '')} {record1.get('last_name', '')}"
    name2 = f"{record2.get('first_name', '')} {record2.get('last_name', '')}"
    name_score = fuzz.token_sort_ratio(name1, name2) / 100
    scores.append(name_score * 0.4)

    # Телефон: нормализация и сравнение
    phone1 = re.sub(r'\D', '', record1.get('phone', ''))
    phone2 = re.sub(r'\D', '', record2.get('phone', ''))
    if phone1 and phone2:
        if phone1[-10:] == phone2[-10:]:  # Последние 10 цифр
            scores.append(0.9)

    # Компания
    if record1.get('company') and record2.get('company'):
        company_score = fuzz.token_set_ratio(
            record1['company'], record2['company']
        ) / 100
        scores.append(company_score * 0.2)

    return sum(scores) / len(scores) if scores else 0.0

Стратегия слияния записей

def merge_duplicates(records: list[dict]) -> dict:
    """Слияние группы дублей в одну запись"""
    merged = {}
    field_priority = ['email', 'phone', 'first_name', 'last_name', 'company']

    for field in field_priority:
        values = [r.get(field) for r in records if r.get(field)]
        if not values:
            continue
        # Берём наиболее часто встречающееся значение
        merged[field] = max(set(values), key=values.count)

    # Для created_at берём самую раннюю дату
    dates = [r.get('created_at') for r in records if r.get('created_at')]
    if dates:
        merged['created_at'] = min(dates)

    # Объединяем теги и метки
    all_tags = []
    for r in records:
        all_tags.extend(r.get('tags', []))
    merged['tags'] = list(set(all_tags))

    merged['merged_from'] = [r['id'] for r in records]
    return merged

Почему стоит внедрять дедупликацию на базе ML?

Rule-based пропускает опечатки и транслитерацию. Embedding-based без дообучения даёт ложные срабатывания. ML-модель на dedupe — золотая середина: обучается на ваших данных за пару часов активной разметки, точность 92-95%, полнота 80-85%. Гарантируем снижение процента дублей в базе минимум на 10% — опыт внедрения на 50+ проектах. Стоимость проекта рассчитывается индивидуально в зависимости от объёма данных и сложности интеграции.

Процесс работы

1. Аудит базы — выгружаем контакты, оцениваем текущий процент дублей.
2. Выбор стратегии — rule-based + ML или embedding для больших объёмов.
3. Разметка и обучение — подготавливаем тренировочный набор, обучаем модель.
4. Интеграция — API или прямой доступ к CRM (Bitrix24, AmoCRM, Salesforce).
5. Тестирование — A/B сравнение: автоматическое слияние vs ручной аудит.
6. Деплой и мониторинг — пайплайн периодической дедупликации, алерты по аномалиям.

Сравнение времени для разных объёмов данных:

Что входит в работу

• Документация: описание модели, настройки порогов, инструкция по дообучению.
• Доступы: к исходному коду (GitLab), к обученной модели (MLflow), к дашборду метрик.
• Обучение: сессия для аналитиков (как размечать новые данные).
• Поддержка: 1 месяц — исправление ошибок, донастройка порогов.

Закажите бесплатный аудит вашей CRM — мы оценим процент дублей и экономический эффект. Свяжитесь с нами через форму на сайте или по телефону.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

ETL для аналитики и ETL для ML — разные задачи. В аналитике важна агрегация, в ML — индивидуальные записи с историей. В аналитике train/val/test split не нужен, в ML — критичен. В аналитике skew данных мешает интерпретации, в ML — напрямую влияет на качество модели.

Инструменты. Apache Spark (Wikipedia) для больших объёмов (10GB+): PySpark с DataFrames, оптимизации через partitioning и caching. dbt для трансформаций поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версионируется, тестируется. Pandas + Polars для объёмов до нескольких GB — Polars в 5-10x быстрее Pandas на типичных трансформациях.

Temporal splits. Для ML важно, что split по времени, а не случайный. Если данные временные (транзакции, события пользователей), случайный split даёт data leakage: модель видит «будущие» данные при обучении. Правило: train на периоде T1-T2, validation на T2-T3 (с gap для предотвращения leakage), test на T3-T4. Неправильный split может стоить 10–15% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. Delta Lake или Apache Iceberg — форматы с ACID-транзакциями, Change Data Capture, time travel.

Как избежать training-serving skew с помощью Feature Store

Feature Store решает проблему рассинхронизации между обучением и инференсом. Самая коварная ошибка в ML-инфраструктуре — training-serving skew: признак считается по-разному в обучении и в продакшене. Модель учится на «правильных» данных, а инференс получает другие.

Feast (open source) — офлайн store на Parquet/Delta в S3 для обучения, онлайн store на Redis для low-latency инференса (<10ms). Feature definitions как Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition, используется везде. Нет расхождений.

Потоковые признаки. Когда признак должен обновляться в реальном времени (количество транзакций за последние 10 минут), нужна потоковая обработка. Apache Kafka + Apache Flink или Kafka Streams для вычисления признаков в реальном времени → запись в онлайн store. Сложнее, дороже, нужно только когда staleness признаков критична для качества.

Разметка данных: как не потратить бюджет впустую

Разметка — самая трудоёмкая и недооцениваемая часть ML-проекта. Плохо размеченные данные не исправит никакая архитектура.

Label Studio — open source, поддерживает разметку изображений (bounding box, polygon, segmentation), текста (NER, классификация), аудио, видео. Поднимается за 10 минут через Docker. Для небольших команд — первый выбор.

Оценка качества разметки. Inter-annotator agreement — насколько согласны разметчики между собой. Cohen's Kappa > 0.8 — хорошо, 0.6-0.8 — приемлемо, < 0.6 — задача неоднозначна или инструкция плохая. Пересечение разметок (10-20% примеров размечают два независимых аннотатора) — обязательная практика.

Active learning. Не размечать случайные примеры, а выбирать те, на которых модель наиболее неуверена (low confidence, high uncertainty). Позволяет добиться того же качества при 50-70% объёма разметки. Modals, Prodigy, Label Studio поддерживают active learning workflows. На одном из проектов для NLP мы сократили бюджет на разметку в 2,5 раза за счёт active learning.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для CV: рендеринг в Blender/Unity с реалистичными текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Риск: модель обучается на distribution синтетических данных, а не реальных — нужна осторожность и проверка на реальном holdout.

Качество данных: валидация и мониторинг

Great Expectations — de facto стандарт для data validation в ML-пайплайнах. Expectations — это декларативные утверждения о данных: «колонка age содержит значения от 0 до 120», «колонка user_id не содержит null», «распределение amount не отклоняется более чем на 20% от baseline». Запускается в пайплайне, при провале — блокирует прохождение.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation с type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель ожидает данные за последние N дней. ETL упал, данные не обновились — модель использует устаревшие признаки. Мониторинг свежести данных: timestamp последней записи в каждой таблице, алерт при задержке > порога.

Дедупликация. Дубликаты в обучающей выборке завышают метрики (одни и те же примеры в train и val) и искажают веса модели. MinHash LSH для приближённой дедупликации больших датасетов. Для точной — хэш по нормализованному контенту.

Инструменты валидации: сравнение

Хранилища и форматы

Для большинства ML-проектов на старте: Parquet в S3 + DVC для версионирования. Delta Lake или Iceberg — когда появляется потребность в инкрементальных обновлениях или time travel.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

• Аудит существующих данных и пайплайнов (1 неделя).
• Проектирование архитектуры: выбор инструментов, форматов, способов разметки.
• Реализация ETL/ELT пайплайна с валидацией и мониторингом.
• Документация кода и процессов (model card, data card).
• Обучение вашей команды работе с пайплайном.
• SLA на сопровождение и поддержку.

Как мы строим пайплайн: пошагово

1. Аудит существующих данных. Профилирование: ydata-profiling (бывший pandas-profiling) генерирует HTML-репорт со статистиками, дистрибуциями, корреляциями, missing values за минуты.
2. Проектирование пайплайна. Определяем источники данных, частоту обновления, требования к latency признаков, объёмы.
3. Реализация и тестирование. Unit-тесты на трансформации, integration-тесты на пайплайн, data validation через Great Expectations.
4. Деплой и мониторинг. Алерты на freshness, quality checks, аномалии в объёмах данных.

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

Свяжитесь с нами для бесплатного аудита ваших данных — оценим текущий пайплайн и предложим roadmap. Закажите построение ML-пайплайна под ключ.