ИИДля
← Назад
Разбор / DOCS · 03.11.2026 · 12:27

ИИ для поиска дублей контактов в таблице: когда совпадение ещё не повод удалять строку

Одинаковая фамилия не означает одного клиента. Разбираем нормализацию, вероятные пары и безопасное подтверждение.

Кира БеловаРедактор текстов и обучения
Редакционная иллюстрация к материалу «ИИ для поиска дублей контактов в таблице: когда совпадение ещё не повод удалять строку»
Авторская иллюстрация редакции «ИИ Для»
Суть задачи

Сначала определите, что считать дублем

Одна и та же компания может оставить заявки через почту и телефон; муж и жена могут использовать общий номер. Поэтому одинаковое имя или номер — лишь признак, а не решение удалить одну строку. Запишите правило: какие записи относятся к одному человеку, какие к компании, какой идентификатор сохраняется и как объединяются история обращений и согласия. Сделайте копию исходной выгрузки и зафиксируйте количество строк. Рабочую таблицу обезличьте, если проверяете подход во внешнем сервисе.

Что подготовить

Нормализация без изменения оригинала

Создайте отдельные служебные колонки: телефон без пробелов и знаков, почта в согласованном регистре, имя без случайных двойных пробелов. Оригинальные значения сохраните. Не исправляйте автоматически домен почты по «похожести»: похожие адреса могут принадлежать разным людям. В таблице держите источник записи и дату, чтобы понять, почему поле отличается. Для аккуратной работы с выгрузками пригодится разбор воспроизводимого отчёта из CSV.

Рабочий маршрут

Отделите точные пары от вероятных

Точным кандидатом можно считать совпадение уникального идентификатора или нескольких независимых полей, если правила вашего процесса это допускают. Совпадение фамилии и близкого адреса — вероятная пара для просмотра, не автоматическое слияние. ИИ может подготовить список пар с объяснением признаков, но обязан оставлять «неизвестно», когда данные противоречивы. Сравните хотя бы несколько десятков вручную размеченных пар; отдельно считайте ложные объединения, потому что потерянная история клиента обходится дороже пары лишних строк.

Контроль качества

Решите, что переносить

Перед объединением просмотрите сделки, счета, согласия на рассылку, обращения и назначенного менеджера. При конфликте не выбирайте последнюю запись механически: последнее значение может быть случайной опечаткой. Итоговая таблица должна содержать две исходные строки, предложенный основной ID, причину, решение проверяющего и дату. Если доступ к CRM ограничен, оператор ИИ не должен получать более широкие права ради чистки базы. Вопрос доступа подробнее разобран в материале о правах.

Пример

Применение и ответы

Сначала выполните слияние на копии, проверьте число связей и только затем переносите утверждённый список в рабочую систему. Сохраните журнал и путь отката. Можно ли удалять все совпадения телефона? Нет: общий номер встречается у семьи и организации. Подходит ли ИИ для всей базы сразу? Начните с размеченной выборки и измерьте ошибки. Что делать с спорной парой? Оставить обе записи и уточнить данные, а не угадывать. Польза здесь в сокращении ручного поиска кандидатов, не в замене ответственного за данные.

Перед использованием

Короткая проверка

  • Понятны цель и человек, который примет результат.
  • Исходники очищены, их версия и дата сохранены.
  • Факты, числа и ограничения сверены вручную.
  • Неудачный пример записан вместе с причиной.
  • Есть измеримый следующий шаг и путь назад.
Продолжить тему

Другие материалы этого направления