HFLabs — о данных

2021-01-18 19:37:09 На Inc. — свежайшее интервью основателей HFLabs. Материал делали едва ли не полгода, в издании выясняли каждую мелочь. Вплоть до того, костюм какого бренда купил на последние Дмитрий Журавлев.

Тизер: «Я постоянно плакала. Я не такой твёрдый человек, как Дима. Говорила: давай всё закроем, вернёмся на зарплату», — вспоминает Елена. <…> «Мы каждый месяц думали: всё, заканчиваем, — но потом еще ждали, ставили новый дедлайн, — и так больше года», — вспоминает Дмитрий.

Рекомендуем http://amp.gs/MdtL Открыть/Комментировать

2021-01-15 16:27:03 Минэкономразвития совместно со Счетной палатой, Ассоциацией участников рынка данных и АНО «Информационная культура» приглашают экспертов, разработчиков, предпринимателей и других пользователей открытых данных принять участие в опросе по формированию перечня востребованных государственных данных и дать обратную связь по опыту работы с открытыми данными.

Присоединиться к опросу: https://forms.gle/uwbsakcSKBEmi9ia6

По итогам опроса в рамках межведомственной рабочей группы будет организована работа с органами власти по раскрытию востребованных данных. Новые датасеты будут доступны на федеральном портале открытых данных data.gov.ru.

Повышение качества открытых данных и непрерывное взаимодействие с их потребителями будут способствовать появлению новых ИТ-решений и сервисов на общедоступных государственных данных. Открыть/Комментировать

2021-01-13 17:35:10 В Италии стартап засудили из-за алгоритма ранжирования курьеров

Профсоюзы возмутились, что алгоритмы доставщика еды Deliveroo игнорируют законы Италии. Например, право курьеров на болезнь или забастовку. Возмутились, подали в суд и выиграли.

Самое интересное тут — мелкие камушки в сторону аргумента «Это все алгоритм». Если так пойдет и дальше, использовать machine learning будет непросто. Получить результат — полдела. Придется еще отслеживать, что там напридумывала машина.

http://amp.gs/MeLu Открыть/Комментировать

2020-12-31 15:30:07 Предновогодняя история.

У нас в HFLabs на моей памяти всегда корпоратив был в последний рабочий день года. Исключением стал прошлый год, ну и вы видите, чем это закончилось
Но история не об этом.

Был год, если не ошибаюсь, 2014. Я только начал активно участвовать в продажах. И вот в конце года к нам пришел потенциальный проект. Я вел пресейл, начиная с первого звонка. Всё горело, нужно было до конца года вписаться в проект. Бюджет хороший, но все в мыле, нет времени объяснять, нужно срочно бежать. А я не понимаю куда

И вот 30 декабря, последний рабочий день. Я приехал со встречи на наш корпоратив. Помню, сидя где-то в углу, написал письмо, в котором окончательно отказался от проекта. Самое интересное, что проект уходил к нашим прямым конкурентам. Кошмарный сон любого продавца

Так вот, меньше чем через полгода этот проект к нам вернулся. Я спросил у нашего заказчика, почему он думает, что с нами получится? Ответ был примерно такой: вы вопросов много задаёте и хотите разобраться, а не бежите, сломя голову, увидев хороший бюджет.

А я опять к чему?
Задавайте вопросы, если не понимаете что-то. Да и если понимаете, тоже иногда полезно переспросить. Не бойтесь показаться глупым.
Чем меньше времени на принятие решения, тем сильнее нужно тормозить. Это про ожидания.

Проект, кстати, получился отличный и первый в своем роде в России. Открыть/Комментировать

2020-12-28 17:09:41 Для тех кто работает с данными по частотам слов, например, фамилий, имён, отчеств для определения пола человека или с другими целями, свежий вычищенный набор данных созданный на основе данных ФИО о персонах в ЕГРЮЛ и ЕГРИП [1].

В наборе данных представлены 3 таблицы:

midnames - отчества, 7040 записей
names - имена, 4874 записи
surnames - фамилии, 48 540 Записей

это покрывает: 96% всех персон по именам, 95% всех персон по отчествам и около 82.5% всех персон по фамилиям

Все таблицы сформированы из первичных данных из 22 млн 617 тыс. записях о персонах с отсевом записей встречающихся не реже 50 раз, прошедшие последующую пост обработку, вычистку мусорных и неверных записей, а также обогащённые данные по полу, поле gender.
Для отчеств пол указан в однозначных значениях: m - мужской, f - женский Для фамилий пол указан в однозначных значениях: m - мужской, f - женский, u - нейтральный (пол невозможно идентифицировать) Для имён пол указан как: m - мужской, f - женский и добавлено поле gender_p - частотное измерение в процентах вероятности что имя относится к данному полу. Например, для имени "Джиргал", пол будет указан как женский "f", а точность будет как 57.97% что будет означать что для всего объёма записей о персонах у 57.97% это были лица женского пола, а остальные мужского.
Общие поля таблиц:

text - имя/фамилия/отчество в зависимости от таблиц
num - число записей где встречается
gender - пол (f - женский, m - мужской, u - невозможно определить)
regorgs - частота встречаемости по кодам субъектов федерации, на основе данных ИНН юридических лиц и ИП
regfl - частота встречаемости по кодам субъектов федерации на основе ИНН физического лица - ИП или руководителя организации


Дополнительные поля
Для таблицы midnames (отчетства)

fname - имя от которого порождено отчество

Для таблицы surnames (фамилии)

f_form - женская форма фамилии
m_form - мужская форма фамилии
fname - имя, если фамилия происходит от имени. Например, для фамилии "Иванов" это будет имя "Иван"

Все данные представлены в формате JSON lines, могут быть загружены в СУБД, например, в MongoDB через утилиту mongoimport или любым иным способом.

Эти таблицы могут использоваться взамен таблиц с неочищенными данными проекта с открытым кодом с одноимённым названием russiannames [2] и, соответственно, использоваться для задач связанных с парсингом и идентификацией форм записи ФИО или же определением пола лица за пределами самых очевидных случаев наиболее популярных имён и когда отчество, к примеру, отсутствует или внесено неправильно.

Ещё раз отмечу что это уже очищенные данные, прошедшие неоднократные тесты, если кто-то захочет поработать и проанализировать менее чистые данные, то пишите мне. Это будет в общей сложности 104 тысячи имён, 196 тысяч отчеств и 760 тысяч фамилий. В них много, очень много ошибок потому что, как выяснилось, ЕГРЮЛ и ЕГРИП содержат огромное число ошибок и иных проблем с данными по ФИО. Но для алгоритмов автоматической очистки данных они могут быть полезны.

Ссылки:
[1] https://ngodata.ru/dataset/russiannames
[2] https://github.com/datacoon/russiannames

#opendata #data #persons #datasets #dataset Открыть/Комментировать

2020-12-23 16:51:22 Завтра в 11:40 с Татьяной Архаровой (директор по трансформациям Deeplay) в модном формате баттла обсудим, нужен ли HR IT-компании.
Я за то, что нужен далеко не всем и не всегда.
(Мы в HFLabs так и живем без HR)
Приходите
https://www.facebook.com/events/404420147639182/ Открыть/Комментировать

2020-12-23 16:51:22 Подключайтесь завтра послушать нашего операционного директора Открыть/Комментировать

2020-12-21 20:35:31 На «Хабре» голосуют за лучшую статью года

Среди претендентов — материал продуктовода «Дадаты» Антона Жиянова.

В связи с этим просто рекомендуем статью Антона «Юлия → Iuliia. Всё о транслитерации». Выдающаяся работа https://habr.com/ru/post/499574/ Открыть/Комментировать

2020-12-17 16:14:30 Обратный поток из CDI-системы. Как распространить данные и ничего себе не сломать

И сразу же дополнение. Вчера на вебинаре соведущий Никита Назаров обещал материал про обратные потоки. Вот его выступление на конференции Ростелекома https://www.youtube.com/watch?t=7513&v=bA0FRcsFmXc Открыть/Комментировать

2020-12-17 16:06:01 «Золотая» карточка: как объединить похожих клиентов, чтобы не было мучительно больно

Вчера продуктовод нашего «Единого клиента» рассказал, как мастер-системы формируют эталонные карточки клиентов. Запись уже на YouTube, смотрите на здоровье



О чем шла речь

Святой Грааль любой системы клиентских мастер-данных — «золотые» записи, они же эталонные карточки. В эти карточки собирают лучшие и наиболее полезные данные о клиентах из доступных источников. В дальнейшем «золотые» записи используют во всех процессах компании: маркетинге, продажах, аналитике, отчетности, клиентском сервисе.

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

А еще рассмотрели тонкости создания и обновления «золотой» записи, о которых не говорят в маркетинговых материалах мастер-систем:
— на какой основе строить «золотую запись»: создать с нуля или выбрать в учетных системах подходящую;
— как создавать, обновлять и удалять данные в «золотой» записи;
— что делать, если «золотую» запись собрали неверно;
— реально ли получать и обновлять «золотую» запись в онлайне, чтобы использовать в операционных процессах.

Кому будет полезно

Материал пригодится архитекторам, дата-инженерам, аналитикам, специалистам по безопасности информации. И всем, кто хочет разобраться в сложностях работы с клиентскими данными.

Кто выступил

Спикером был Михаил Берёзин, в HFLabs он руководит разработкой мастер-системы «Единый клиент». На этой позиции изучает алгоритмы создания и обновления «золотых» записей. Анализирует эффективность различных подходов и типовые ошибки в работе.

Михаил рассказал, как «Единый клиент» обращается с эталонными карточками. И какими принципами руководствуются современные мастер-системы при управлении «золотыми записями».



Открыть/Комментировать