Pull to refresh

Comments 22

Не очень понятно из текста каким образом определяется какой из номеров считается оригинальным в таком случае? Или сохраняются оба, просто с ссылкой друг на друга?

Вопрос для целой статьи!

Первым делом важно, что мы исходные данные ни в коем случае не удаляем, они остаются в своих записях. Объединяя дубли, мы создаем новую — «золотую» — карточку. И уже в нее пойдет номер и другие данные, которые алгоритмы признали «оригинальным».

Решение о том, какой номер пойдет в «золотую» карточку, принимают алгоритмы MDM (master data management). У них вагон входных параметров, начиная с «веса» базы данных, из которой пришла каждая запись (у заказчиков обычно бывают более доверенные источники и менее доверенные). Есть еще свежесть данных, код качества данных (насколько условный номер паспорта или телефон похож на настоящий) и еще очень много разных параметров.

Это если очень кратко объяснять.

Интересная задача.


Вот интересно, слышал что в забугорье часто используются персональные номера (что-то между нашим ИНН и номером паспорта) и есть служба с API, в которой можно сверить эти данные на правильность. Но что самое интересное — эти номера содержат чек-сумму и проверяют на ошибку. Почему в России до такого не додумались? И вообще, номера и серия паспорта идут по порядку или все же кодируют какую-то информацию?


Edit: служба с API — налоговая. Они же эти номера и выдают.

Кто сказал, что не додумались? В ИНН и СНИЛС есть чек-сумма. Есть и всякие API, не для всех, конечно… а вот паспорт – это просто номер бумажки-бланка.
Если интересно почитать о сериях, номерах и других реквизитах паспорта, посмотрите на нашу предыдущую статью «Как проверить паспорт на действительность». Здесь не перескажешь — в ней много всего, особенно если с комментариями.

Что до контрольных сумм — верно, в паспорте не хватает. В некоторых документах они есть, как подсказали выше. Еще говорят, что в паспорта недавно добавили машиночитаемую полосу с контрольной суммой, но мы пока с этим не разбирались.

Да, там с контрольными суммами. Формат очень удобный, писал для него распознавание. Единственное — у серии нет одной цифры, пожертвовали, чтобы вписаться в международный формат. Подробное описание формата есть в приказе МВД: http://www.consultant.ru/document/cons_doc_LAW_284759/bc855030a3b448fca0965bbf45ee3ff7e77314e3/

Не совсем понятно, почему «Одна перестановка двух символов» имеет существенно меньший коэффициент похожести, чем «Одна распространенная опечатка». ИМХО, обе примерно схожи по природе и по частоте.

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

Тут смотрите, какая штука. Мы скорим перестановку символов так же, как нераспространенную опечатку. Принципиально это одно и тоже.

А распространенные опечатки — это те, которые мы за 15 лет выделили статистически как наиболее часто встречающиеся. Это как бы «сертифицированные» опечатки, что ли. Мы за эту группу можем поручиться, поэтому и коэффициент у них выше. За таблицей «похожести» — большой труд и опыт.

Ну и ещё, зачастую номера документов имеют одну контрольную цифру. Можно добавить маркер «неверная контрольная цифра» как повышающий вероятность того, что случилась опечатка

Все верно, просто мы пока до этого не дошли.
Жена подала документы на учетку в налоговой. Сделали… ИНН ее, паспортные данные ее, а все остальные данные ее полной тезки (ФИО, дата рождения) из Самары: недвижимость (с адресом), долги по налогам и прочее. То что паспорта и прописка разные- никого не смутило. Для опротестования результатов предлагали ехать разбираться в Самару (из Московской области). Года два бодались, почти до суда дошли. Теперь у жены «голая» учетка: только ИНН и паспорт, никакой собственности, никаких долгов, ничего. Готовимся к второму кругу.
На очереди третий. (За мной числится два объекта недвижимости (квартира), по одному адресу, с разными кадастровыми номерами. Пока плачу за оба)
Потом четвертый круг: ОСАГО. Данные страховщикам предоставляет РСА. В семье две машины, в страховках по два водителя (я и жена). Водительские права у каждого в одном экземпляре, но коэффициент водителя для каждой машины свой!
А скоро обязуют на электронные трудовые. Уже ничему не удивляюсь…
Что-то подобное регулярно случается, к сожалению. Мы и боремся за то, чтобы подобных случаев было меньше. С налоговой не работаем, но в госсектор понемногу заходим.

Сил вам!
Судя по описанию вы построили систему основанную на правилах выведеных вручную. Насколько я понимаю у компании уже есть довольно много данных, на которых можно обучить модель, которая выведет все правила сама. При этом машинные правила могут учитавать больше нюансов в данных, например распространенность ФИО (для фамилии Кузнецов вероятность совпадения будет больше, чем для фамилии Вовк, например)
Пробовали ли вы применять машинное обучение в своей области?
Это не моя система, это реальная жизнь. Самые реальные Федеральная налоговая служба, ГосУслуги, РСА, Ингосстрах. Их услугами вынужденна пользоваться вся Российская Федерация. Правда «Ингосстрах» тоже косвенно пострадавший — для расчетов он использует данные РСА, а претензии выслушивает от меня.
Машинное обучение не применяли. К сожалению, в нашем случае оно не имеет практического смысла.

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

Грубый пример навскидку. Допустим, на входе у нас граждане Иванов и Ованов. Машине справедливо кажется, что это люди с разной буквой в фамилии. Возможно, это опечатка.

Но мы знаем, что во вторую учетную систему данные вводят на латинице, поэтому Иванова вписывали как «Ovanov». А это совершенно другой коленкор, потому что I с O на клавиатуре находятся рядом. И вероятность опечатки выше, чем в случае с изначальными «Иванов» и «Ованов».

У другого же заказчика вообще другие правила и другие форматы хранения данных, и так у каждого.

Машинное обучение не подходит, увы, как бы нам ни хотелось.
Возможно, мы к этому еще придем :)
Надеялся увидеть подобное решение:

var a = [1,4,7,3,4,9,8]; // Образец 1
var b = [1,4,7,3,5,9,8]; // Образец 2
var sum = 0;
var result = 0;

a.forEach((item, i)=> {
sum += Math.pow(item - b[i], 2);
});

// Чем больше result, тем менее похожи образцы. При полном совпадении result = 0.
// В данном случае result = 1, что означает минимальное отличие.
result = Math.sqrt(sum);
У вас в случаях

b = [1,4,7,3,5,9,8];
и
b = [1,4,7,3,3,9,8];

результат одинаков, хотя набирая на маленькой клавиатуре одну ошибку допустить сложнее, чем другую

А для случая
var a = [1,4,7,3,4,9,8]; // Образец 1
var b = [1,4,3,7,4,9,8]; // Образец 2
у вас вообще «все плохо». Хотя просто 2 цифры местами поменяли при наборе
losse_narmo верно ответил — в жизни все намного сложнее, к сожалению. Не все опечатки равнозначны, об этом и публикация.
Не очень понятен исходный набор атрибутов. Если я правильно понял, описанный алгоритм применяется только к паспортам и даже там есть такой важный атрибут как ДР (дата рождения). Почему он не участвует в алгоритмах? Если же смотреть на тему чуть шире, то ДУЛы редко живут сами по себе. В компаниях есть другие идентифицирующие данные клиента, которые активно используются: email, тел., аккаунт на сайте компании или в соцсетях. Вы не применяете обогащение данных для повышения вероятности/качества идентификации?
Сравнивая клиентов, мы учитываем все о них известное: и дату выдачи ДУЛ, и адрес регистрации, и телефон, и рабочий адрес, и емейл, и другие свойства. Сравнение двух карточек выглядит примерно так:

  • ФИО в двух клиентских карточках — совпадают.
  • Адреса регистрации — разные.
  • ДР — разные.
  • Номера ДУЛ — разные.

Система видит: ФИО совпадают, значит, карточки могут быть дублями. Но остальные параметры различаются, поэтому коэффициент дублирования невысок — условно 70.

Теперь же мы добавили гибкости, и алгоритм заработал так:

  • ФИО в двух клиентских карточках — совпадают.
  • Адреса регистрации — разные.
  • ДР — разные.
  • Номера ДУЛ — совпадают с коэффициентом 95.

Тут ситуация уже совершенно другая: системе видит, что ФИО одинаковые и ДУЛ наверняка тоже. Поэтому она посчитает карточки дублями с коэффициентом 90.

А дальше уже включают правила объединения. Кто-то из заказчиков все равно отправит оба варианта на ручной разбор. Другие же коэффициент 90 считают достаточным для автоматического слияния.
… считают достаточным для автоматического слияния

Вот так одного товарища и «слили».
Пришли к нему приставы и требуют погашения алиментов на сумму приближающуюся к миллиону… возможно, что сверху.
А он понять не может. Женат, не разводился, детей на стороне не имеет…

Оказалось, что его перепутали с другим полным тезкой. А этот тезка уже несколько лет любуется небом в клеточку, вот алименты и не платит.
Но мало того, что его перепутали. Их в самом деле по какой-то картотеке «слили» в одно лицо. Места работы, проживания, судимости — все идет сквозняком по обоим сразу. И разделить не торопятся. Ибо не предусмотрена такая процедура.

Особая насмешка судьбы, что он сам из органов… Но все равно ничего поделать не может.

А у меня дочь в ФОМС «слили» с кем-то… Человек родился в том же городе и в тот же день (год другой), что и она. ФИО совсем другое, но где-то вышла ошибочка и номер полиса забили у него такой же.
Но т.к. она в том городе уже не жила давно, то территориальные отделения ФОМС были разные. И они больше года не могли договориться, что делать. Все это время ей каждый месяц выдавали временный полис.

Потом заменили полис совсем.
Sign up to leave a comment.