Я работаю с распознаванием и обработкой данных переписей населения и сельскохозяйственных переписей с двухтысячного года. Это тот самый случай, когда ты больше года пишешь софт, который должен отработать один раз, но зато без ошибок.
Почему? Во всероссийской переписи населения в 2010 году участвовало 500 тысяч человек и ещё 10 тысяч IT-пользователей во всех субъектах РФ. Сканер забирает 150 листов в минуту. Распознавание в реальном времени с примерно такой же скоростью. Умножайте на количество сканеров по стране – и получите поток данных, где любой баг сразу рушит работу огромного количества людей.
И второй момент – вместе с НИИ Статистики мы ведём научно-исследовательскую работу по алгоритмам восстановления данных.
Как происходит перепись
Если это всероссийская перепись населения – примерно полмиллиона человек (чаще всего – студенты) обходят всех людей в стране. Задача — дойти до каждого и задать ряд вопросов, ответы фиксируются на бумаге на специальном машиночитаемом бланке. Если сельхозперепись – людей ходит меньше, но все же. Вот, например, стандартный портфель переписчика сельскохозайственной переписи, с которым он ходит по своей земле:
Дальше – получить из этих бланков десятки миллионов таблиц, в каждой из которых есть конкретные данные по районам, важные для служб разного уровня.
То есть процедура такая:
• Подготовить списки обследуемых объектов и разбить их на участки для переписчиков;
• Собрать данные физически, «ногами».
• Загрузить машиночитаемые документы в потоковый сканер, который быстро и нежно их перелистает.
• Распознать то, что распознаётся (а у нас тут, на секундочку, рукописный почерк).
• Сделать несколько коррекций по тому, что не было распознано, чтобы оператор мог добить данные с бланков руками.
• Ещё раз проверить данные на соответствие друг другу по логике (дед не может быть моложе сына и так далее).
• Собрать общую базу данных со всей страны.
• При необходимости – загрузить эту базу в систему аналитики, чтобы заказчик мог сам делать нетипичные отчёты и нарезать из неё нереальное море отчётов.
• Защищённой почтой доставить сканы бумажных бланков на хранение;
• Организовать хранение бумажных бланков на местах.
Многие участники-операторы переписи видят компьютер первый раз в жизни (я не преувеличиваю, у нас и мышь двумя руками двигали с непривычки, и ещё много чего в посёлках случалось). Плюс не всем до конца понятна процедура переписи, там много нетривиальных операций. Естественно, это вызывает резкий рост нагрузки на поддержку, что в пиковые дни крайне нежелательно. Поэтому (хоть нас об этом и не просили), мы записали 40-минутное обучающее видео, разъясняющее все аспекты того, как правильно по шагам делать перепись. Вот короткая выдержка из 2004 года (как раньше писали на пиратских дисках – «озвучено профессиональными программистами»):
С другой стороны, на сельхозпереписях опрашивают бывшие агрономы и председатели кооперативов. Они живо разбираются в теме, и заинтересованы в результате, потому что сами не раз пользовались собранными данными в своей работе. С этими людьми очень приятно работать. Они часто также не понимают, куда подавать корм в компьютер, но зато не боятся задавать вопросы и учиться. А ещё у них есть чертовски важное свойство для целостности данных – они по бабке на глаз могут определить, сколько у неё поросят, и не сховала ли она одного от переписчика. Кстати, насчёт глубокого знания темы – не все тестеры знали, что в одной из областей выращивают несколько гектаров конопли. Потому что это ценнейшее стратегическое сырьё. Для медицины и легкой промышленности.
На следующие такие переписи по с/х теме заказчик вообще хочет избавиться от бумаги: раздать представителям планшеты, чтобы данные забивались сразу в них. Там, конечно, есть особенности с персональными данными, — нужно придумать решение, предотвращающее утечку даже при рутинге, но это всё решаемо.
Реализация
Начну немного с конца. Учитывая объём базы данных, подходящее решение – это MS SQL + MS OLAP. Когда мы начали работать с olap для генерации, у нас было крайне мало опыта, зато была вера в себя и воля к победе. Но потом ни разу не пожалели. Такого масштаба проектов в OLAP в мире считанные единицы. Естественно, мы шли по граблям и натыкались на ошибки, которые нельзя было выявить в тестах – у разработчиков просто не было живой базы такого объёма и пары мощных ЦОДов под боком, перемалывающих данные. Кстати, дата-центр Росстата.
Вся первичка обрабатывается на местах, данные проверяются на полноту и консистентность. Затем данные попадают в ЦОД в Москву двумя путями:
- Обработанные в цифровом виде – по VPN от рабочих мест операторов.
- Сканы бумажных оригиналов – фельдъегерской почтой. С дисков всё загружается в базу уже здесь. Физически всё это лежит в защищённых помещениях, сама почтовая система такого класса предназначена даже для отправки совершенно секретных документов.
Итак, мы получаем примерно 6 Тб сырых данных для обработки, из которых получается базаданных размером под 500 Гб. На этом уровне требуется восстановление данных до репрезентативных. Например, в округе было около 2 тысяч человек, участвовавших в переписи и 15 «отказников», которых не застали или до которых не дошли по иным причинам. Логично предположить, что статистически (а нас интересуют только большие числа) они будут в среднем соответствовать остальным жителям региона. Это очень упрощённый пример того, как восстанавливаются данные. На практике мы вместе с НИИ подтвердили серией экспериментов следующую гипотезу: если взять достаточно большой массив ответов, где всё заполнено (реальные переписные данные прошлых лет), затем случайным образом удалить до 10% ответов, а после восстановить данные, то результаты в итоговых нарезках должны различаться не более чем на десятые доли процентов.
Используется множество решений – от поиска по базе похожих профилей (например, мы знаем половозрастную структуру семьи фермеров, которая не была опрошена – алгоритм будет искать похожие семьи в регионах с похожими условиями и опираться на них и т.п.). На практике только у нас в стране есть готовый механизм работы с такими алгоритмами. Тот же НИИ, работающий со статистикой, не может – у него нет достаточной мощности ЦОДов, чтобы парсить огромные базы.
Ещё один важный компонент обработки отчётов – это специальный BI наших австралийских коллег, работающих с Big Data. Важная особенность – защита конфиденциальности информации. Первый слой – невозможность выгрузить отчёты, где есть возможность добраться до конкретных чисел на человека. Как бы вы ни старались, внутренняя единица обработки – 3 человека. Ещё одна специальная аналитика следит за тем, чтобы нельзя было выгрузить отчёт, содержащий матрицу, соответствующую другой матрице с похожими данными. Потому что ушлые пентестеры на обсуждении защиты научились вычитать одни матрицы из других, чтобы получать конкретику по людям. Теперь за этим следит специальный механизм. BI называется SuperStar.
Данные в регионе
В отличие от выборов, когда жители сами приходят на участки (и если кто-то не придёт, ничего страшного) на переписи нужно дойти до каждого и получить максимально полные данные. Ок, студент собрал бумаги, по возможности правильно их заполнил, проверил и принёс в райцентр. Затем они попадают под охраной милиции (полиции) в территориальные органы статистики, где стоит сканер машиночитаемых документов. Из сканера бумаги уходят под охрану.
Бумаги приходят увязанные по участкам. Например, «вот пакет, тут 400 человек, это деревня такая-то». Система деления на учётные единицы отстраивалась ещё в СССР, работает как часы.
Дальше сопоставление полноты данных – сложная работа, позволяющая понять, например, по данным анкеты деда с тремя внуками, что где-то должны быть эти внуки, и если их нет – значит, что-то пошло не так. На такой процедуре, например, у нас нашёлся единичный верблюд в Челябинской области. Чуть с ума не сошли, думали, баг, попросили проверить – там реально кто-то держит верблюда. Чаще бывают ситуации вроде ошибок заполнения – коров две, из них молочных – пять. С планшетами будет проще, там на уровне UI будет множество проверок.
Комплекс ввода – одна из интересных частей. Сначала стояли наши российские промсканеры, как на фото, но на последней переписи использовались уже иностранные. 150 листов в минуту. Мировая практика – отдавать дальше на распознающую машину, потом на верифицирующую. Три машины – дикая роскошь, поэтому мы собираем один ПАК, где прямо во время сканирования оператор может на экране видеть данные и править то, что не смогла «разжевать» система.
Естественно, самую большую сложность на этой стадии вызывают разные почерки. У нас, к счастью, есть много опорных данных – на машиночитаемых документах предостаточно меток, позволяющих точно определить направление текста, где он на странице и так далее. Где должны быть числа, где название села и так далее, что сокращает количество гипотез. Поэтому мы смогли загнать в распознавание не только более-менее печатные цифры, но и множество образцов почерка. На первых переписях мы собрали базу самых распространённых почерковых особенностей и смогли успешно распознавать подавляющее большинство рукописных текстов на наших бланках.
Экран обучения «помогите роботам»: поменьше петель, линии по возможности без разрыва, не обводить цифры второй раз, стараться не выходить за поле. Всё равно встречаются плохие варианты, но после обучения их куда меньше.
В итоге совсем немного, существенно менее процента, нужно править руками. Собирается специальная база плохо распознанных документов, которую добивают операторы.
Затем – ещё одна проверка, на этот раз физическая. Должен быть килограмм документов, судя по массе – не хватает 20 бумажек. Под столом не забыли?
Потом формально-логический контроль, установление связей данных.
И только потом отправка.
Результат
Численность необходимого персонала за счёт автоматизации почти каждого шага мы уменьшили очень существенно. Для примера – даже тот же маршрутный лист составляется автоматически, что оптимизирует время обхода участка.
Персонал в таких мероприятиях – самое дорогое удовольствие, и даже 5-7 дней работы ЦОДа TierIII в сравнении с этим – копейки.
Постановка задач на таких проектах очень и очень необычная. Заказчик отлично понимает свою специфику, готов объяснять – но не мыслит категориями разработки. Первый раз мы получили 700-страничный кирпич – почти художественный текст в качестве ТЗ, который аналитик превращал в требования. Второй раз и дальше заказчик уже начал понимать, как объяснять это нам, а мы начали глубоко разбираться в теме и понимать их жаргон. Практика показывает, что стоит взять, например, ведущего тестировщика после получения задачи, а не до, и всё, где-нибудь он наколется на незнании специфики. За глубокие знания темы нас очень ценят – это ключевое в разработке таких решений.
В короткий срок мы перелопачиваем кучу данных. Повторить процедуру нет шанса, поэтому огромные бюджеты уходят на тестирование. Набираем даже специально обученных колхозников-пенсионеров, задача которых – максимально вредничать. Справляемся. Мы понимаем, что участники переписи – профессионалы в своей теме, и совершенно нормально не работать с IT. Делаем очень простые интерфейсы. Думаем о юзабилити решений на распознавании-проверке. Экономим время и нервы многим. Это сложно, и очень интересно.
Следующая перепись ВСХП будет уже в 2016 году. Всероссийская перепись населения — запланирована на 2020. По профессиональным вопросам можно писать мне на ICherepov@croc.ru или прямо здесь в комментарии.
Автор: ICherepov
