От apple16
К Ustinoff
Дата 01.06.2018 00:42:26
Рубрики WWII; Армия; 1941; Память;

Банков с 50 миллионами банковских карточек даже в РФ должно быть несколько

Технологий вагон и они сами не слишком умные - можно и самим запилить
Всякая Informatica Data Quality унылое, но работает.

Те это рутинная задача для большого банка и уже давно
Да и пенсионный примерно такие же объемы шевелит

Поэтому весь вопрос в деньгах на организацию процесса силами людей, которые и слов таких не слышали.

Но можно проще поступить
- хочешь ляпнуть на 9 мая с трибуны "Никто не забыт, ничто не забыто" будь добр покажи сертификат на 10,000 очищенных тобой или на твои деньги записей.
Otherwise отсидка на 15 суток
Ресурс используем - значит платим за него.
От Slick
К apple16 (01.06.2018 00:42:26)
Дата 03.06.2018 15:39:50

Re: Банков с...


>Те это рутинная задача для большого банка и уже давно
>Да и пенсионный примерно такие же объемы шевелит

В банке и пенсионном фонде - по определению структурированные (пускай не полные) данные в отличии от топичных. Теоретически можно настроить "нейросеть" но точность 95% вряд ли будет - скорее 65% реальна... и черный ящик алгоритма на выходе - который не "проверить"...
От Лейтенант
К apple16 (01.06.2018 00:42:26)
Дата 03.06.2018 01:34:15

Ну есть такие, но там проблем там полно

У того же Сбербанка в базе полно необъединенных дубликатов, которые автоматизированные средства не берут. Столкунулся на личном примере.
От Slick
К Лейтенант (03.06.2018 01:34:15)
Дата 03.06.2018 15:34:53

Re: Ну есть...

>У того же Сбербанка в базе полно необъединенных дубликатов, которые автоматизированные средства не берут. Столкунулся на личном примере.
Уверены что там применялись автоматизированные средства? В банках первичен "счет" а не человек. Нет по сути необходимости объединять.
От Prepod
К Slick (03.06.2018 15:34:53)
Дата 04.06.2018 13:50:29

Re: Ну есть...

>>У того же Сбербанка в базе полно необъединенных дубликатов, которые автоматизированные средства не берут. Столкунулся на личном примере.
>Уверены что там применялись автоматизированные средства? В банках первичен "счет" а не человек. Нет по сути необходимости объединять.
Это если человек однозначно идентифицирован и база данных его "видит" как одного человека с разными картами. Это тоже была непростая задача на этапе автоматизации и создания единых баз в рамках одного банка (особенно запарно при объединении банков). На практике за одним человеком числится масса разных счетов и карт, открытых в разное время по разным надобностям. Отсюда введение разнообразных виртуальных "мастер-счетов" и аналогов в сочетании со стимулированием клиентов пользоваться этими счетами и привязывать карты к этому счету. Переход бюдетников на карты "Мир" позволил мним банкам оптимизировать процесс и загнать клинетов на один счет.
Идентифицировать человека, сменившего фамилию, адрес, номер паспорта полностью автоматически нельзя, нужно волевое решение сотрудника и/или инфориация от клиента.
Точно так же как и с военно-истоическими базами. Разные РВК это вообще стандарт: один по мету призыва на срочную, другой по мету призыва по мобилизации, и оба, что харатерно, правильные. Даже у кадровых командиров РККА есть вариант призыва по месту жительства и по месту зачисления на пулеметные курсы, и опять же, оба в принчипе правильные. Разные написания отчества и вида Ленович-Леонтьевич, Панетелеевич-Пантелеймонович это классика.
Выдача сберовских но-нейм карт в реальном времени тоже провоцирует ошибки, как и заполнение наградных на многих отличившихся после успешного боевого эпизода. Человеческий фактор.
От Slick
К Prepod (04.06.2018 13:50:29)
Дата 04.06.2018 15:40:04

Re: Ну есть...


>Это если человек однозначно идентифицирован и база данных его "видит" как одного человека с разными картами. Это тоже была непростая задача на этапе автоматизации и создания единых баз в рамках одного банка (особенно запарно при объединении банков). На практике за одним человеком числится масса разных счетов и карт, открытых в разное время по разным надобностям.

Для банков достаточно идентифицировать человека к привязке конкретного счета. Объединение всех счетов в одного клиента - допфункционал. Частно не на уровне бухучетных систем - а выше в CRM с соответствующим падением качества данных. Если вы хотите точно посчитать потери - задача не тривиальна.
От Паршев
К apple16 (01.06.2018 00:42:26)
Дата 01.06.2018 10:35:19

Да, но только ввод информации трудоемкий

где-то в 90-е годы было 50 центов на запись (карточку), если склероз не подводит.
От Fateev
К apple16 (01.06.2018 00:42:26)
Дата 01.06.2018 06:58:50

Дело не в кол-ве карточек

День добрый.

>Те это рутинная задача для большого банка и уже давно
>Да и пенсионный примерно такие же объемы шевелит

50 лимонов записей - это копейки для современных компов и баз данных.
Проблема именно в автоматическом распознавании дублей и их слиянии.
Я по своей работе регулярно имею дело с попытками автоматического распознавания адреса из строки в структурированную базу - пока ничего хорошего - все кончается ручной работой по косвенным признакам, куда отнести этот адрес/абонента.

>Поэтому весь вопрос в деньгах на организацию процесса силами людей, которые и слов таких не слышали.
А кто будет выверять обработанные этими людьми данные ? И не приведет ли это к еще большему бардаку?

>Но можно проще поступить
>- хочешь ляпнуть на 9 мая с трибуны "Никто не забыт, ничто не забыто" будь добр покажи сертификат на 10,000 очищенных тобой или на твои деньги записей.
>Otherwise отсидка на 15 суток
Приведет к бооооольшой показухе и припискам.

С уважением, Павел Фатеев.
От apple16
К Fateev (01.06.2018 06:58:50)
Дата 01.06.2018 10:27:40

Конечно вопрос в процессе

Есть куча софта для борьбы за качество данных
Причем там не умная какая-то big data

В простейшей формулировке есть запись и ее связи с другими сущностями
(родственниками, населенными пунктами, воинскими формированиями, датами)
Важно понимать что полей как в базе данных у записи на самом деле нет - фамилий может быть много, мест рождения и прочего. Только id и связи

Для любых двух записей можно посчитать метрику близости. Одинаковая фамилия +100, год рождения +200, и то и другое +1000. Если больше порога (1200 например) то это один человек.
Специальные коэффициенты, если в одной записи нет поля а в другой есть.
(в зависимости от типа исходного документа)
Придумали коэффициенты - натравили на выборку - смотрим кого предлагает объединить.
Если все ok - накатываем. теперь у нас другое множество id с другими связями
При этом можно и назад откатить если была ошибка


Сначала очень слабые критерии - только полное совпадение по ключевым атрибутам
Потом сложнее и сложнее

Городских раскидывать не очень сложное дело - там адреса и прочее
Деревенских с милой привычкой иметь три фамилии на село в 100 дворов и без адресов очень тяжело

Население выступает в качестве бесплатного QA - сигнализирует если что не так.
Есть люди которые например копают "свою" дивизию или полк - они гораздо глубже в теме - тоже могут помочь.

Опять таки федеральная программа - хочешь идти на "Бессмертный полк" - будь добр проверь своих по ОБД чтобы все было четко.

Сходные задачи решают и банки и страховые и всякие федеральные программы.
В штатах в Medicaid или Child Welfare только в путь ловить Гонсалесов с переездами и новыми браками. В РФ должно быть то же самое.

Но это все не дешево - зарплата одного или даже двух генералов. МО такое не потянуть ))
От Fateev
К apple16 (01.06.2018 10:27:40)
Дата 01.06.2018 11:13:32

Re: Конечно вопрос...

День добрый.
>Есть куча софта для борьбы за качество данных
Скажем так, эта задача глубоко нетривиальная, и у одних наших заказчиков в 2002г процент нормального разбора адресов (при загрузке из текста) вышел всего 50-55% картотеки(около 600 т.абонентов). Они плюнули на этот софт, написали (2 местных программера) за 2 недели свою процедуру - получилось около 65%. Еще около 3 недель ручной программерской работы по отлову массовых ошибок - и потом полгода ручной работы операторов. Но какие-то дубли ловят до сих пор.

>В простейшей формулировке есть запись и ее связи с другими сущностями
>(родственниками, населенными пунктами, воинскими формированиями, датами)
>Важно понимать что полей как в базе данных у записи на самом деле нет - фамилий может быть много, мест рождения и прочего. Только id и связи
Нет разницы - реляционная база или сетевая или иерархическая - важен именно алгоритм распознавания и на каких принципах его делать.

>Для любых двух записей можно посчитать метрику близости. Одинаковая фамилия +100, год рождения +200, и то и другое +1000. Если больше порога (1200 например) то это один человек.
>Специальные коэффициенты, если в одной записи нет поля а в другой есть.
>(в зависимости от типа исходного документа)
>Придумали коэффициенты - натравили на выборку - смотрим кого предлагает объединить.
Согласен, обычно по каким то определенным критериям дубли и сливают.

>Если все ok - накатываем. теперь у нас другое множество id с другими связями
>При этом можно и назад откатить если была ошибка

Разумеется ! это вообще первое, о чем должны думать и делать при любой массовой конвертации.

>Сначала очень слабые критерии - только полное совпадение по ключевым атрибутам
>Потом сложнее и сложнее

>Городских раскидывать не очень сложное дело - там адреса и прочее
>Деревенских с милой привычкой иметь три фамилии на село в 100 дворов и без адресов очень тяжело
В городах другое - одинаковые улицы и ошибки при вводе - примеры я уже показывал.

>Население выступает в качестве бесплатного QA - сигнализирует если что не так.
>Есть люди которые например копают "свою" дивизию или полк - они гораздо глубже в теме - тоже могут помочь.

>Опять таки федеральная программа - хочешь идти на "Бессмертный полк" - будь добр проверь своих по ОБД чтобы все было четко.
>Сходные задачи решают и банки и страховые и всякие федеральные программы.
>В штатах в Medicaid или Child Welfare только в путь ловить Гонсалесов с переездами и новыми браками. В РФ должно быть то же самое.
С современными гражданами все таки проще - можно оттолкнуться от ID документов- паспорта, страховые, ИНН итп. С гражданами 1930-40х такое не проходит ( .

>Но это все не дешево - зарплата одного или даже двух генералов. МО такое не потянуть ))

Обычно (по моей практике) заказчиков на вразумление и трудовые подвиги очень хорошо стимулирует сильный пинок директората.

С уважением, Павел Фатеев.
От Samsv
К Fateev (01.06.2018 06:58:50)
Дата 01.06.2018 10:12:42

Можно начать хотя бы с наведения порядка в адм. террит. делении.

>День добрый.

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

>>Поэтому весь вопрос в деньгах на организацию процесса силами людей, которые и слов таких не слышали.
>А кто будет выверять обработанные этими людьми данные ? И не приведет ли это к еще большему бардаку?


Приветствую!

А то каких только районов и нас. пунктов не встретишь.
Районы по кр. мере легко исправить, да и большинство названий нас. пунктов можно скорреткировать.
Тогда и связывать похожие записи дегче будет.
С уважением, Samsv, http://samsv.narod.ru
От Fateev
К Samsv (01.06.2018 10:12:42)
Дата 01.06.2018 10:35:48

Re: Можно начать...

День добрый.
>А то каких только районов и нас. пунктов не встретишь.
>Районы по кр. мере легко исправить, да и большинство названий нас. пунктов можно скорреткировать.

Основных проблем две-
1. Одинаковые наименования улиц и нас. пунктов (Ленина, Маркса, Ивановки и Алексеевки всех видов).
2. Разные варианты написания и ошибки при заполнении. Скажем улица может называться - ул. Ленина; прс Ленина; пр.Ленина; пЛенина; и это все одна и таже улица.
Кладр, ФИАС итп помогают, но с ними надо сопоставлять приходящие данные - и в этом проблема.

P.S. Завязываю, ибо оффтопик.
С уважением, Павел Фатеев.
От john1973
К Fateev (01.06.2018 10:35:48)
Дата 03.06.2018 04:20:52

Re: Можно начать...

>1. Одинаковые наименования улиц и нас. пунктов (Ленина, Маркса, Ивановки и Алексеевки всех видов).
>2. Разные варианты написания и ошибки при заполнении. Скажем улица может называться - ул. Ленина; прс Ленина; пр.Ленина; пЛенина; и это все одна и таже улица
Сокольнический р-н Москвы? Существующий и поныне в тех же границах? НЯЗ и улицы те же?
От Fateev
К john1973 (03.06.2018 04:20:52)
Дата 03.06.2018 08:00:41

Не надо москвацентризма )

День добрый.
>>1. Одинаковые наименования улиц и нас. пунктов (Ленина, Маркса, Ивановки и Алексеевки всех видов).
>>2. Разные варианты написания и ошибки при заполнении. Скажем улица может называться - ул. Ленина; прс Ленина; пр.Ленина; пЛенина; и это все одна и таже улица
>Сокольнический р-н Москвы? Существующий и поныне в тех же границах? НЯЗ и улицы те же?

Конкретно этот случай был в Сибири.

С уважением, Павел Фатеев.