Введение

Эту заметку я написал, чтобы вникнуть в проблематику с качеством данным как таковую. На своей работе я имею дело с контролем качества, но в основном речь идет о качестве физических объектов (например сварных швов), но в ряде случаев и о качестве собранных данных об этих изделиях (полнота охвата, отсутствие пропусков, соответствие требованиям нормативных документов).

В результатах опроса, опубликованных летом 2021 приведены результаты анкетирования сотрудников более 230 компаний, работающих с данными: аналитиков, дата-сайентистов, разработчиков и менеджеров.  По приведённым результатам можно сделать несколько важных выводов о болевых точках и тенденциях в наборе применяемы инструментов для управления данными. 

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

Как при строительстве атомной станции или газопровода, так и в построении систем аналитики, отчётности, прогнозирования, управления клиентами требуется формировать бюджет на обеспечение качества, в том числе и качества данных, вносимых в системы бизнес-аналитики. Как отметил David Taber «контроль корректности данных это строка расходов, которая существует пока существуют данные».

При этом по давним исследованиям Ларри Инглиша (Larry English. Information Quality Applied: Best Practices for Improving Business Information, Processes and Systems, John Wiley & Sons, 2009) от 15 до 35% годового бюджета организации тратится неэффективно из-за низкого качества данных. А в организациях, ориентированных на предоставление услуг (таких как банки, страховые компании, правительственные учреждения), объем потерь доходит до 40%.

Какие выводы можно сделать на основе данных опроса:

• качество и надёжность – главный KPI команды, работающей с данными;

• про неудачи внедрения IT решений, завязанных на данные впору проводить отдельные Failconf

• специалисты жалуются на избыток ручной работы

Качество и надёжность – главный KPI команды, работающей с данными

Вывод сделан на основании анализа результатов опроса – «Какие KPI применяются в вашей работе?». На первом месте стоит улучшение качества данных, с небольшим отставанием идёт доступность данных для всех заинтересованных сторон и улучшение коммуникации и сотрудничества.

Задачи повышения быстродействия не вошли даже в первую пятерку KPI. Выходит так, что технологии, как это нередко бывает, опережают людей – тех кто сливает данные в «озеро».

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

Точно такая же проблема возникает при взаимодействии, к примеру,  двух цифровизируемых министерств. Для этого на одном языке должны заговорить и налоговики и силовики.

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

FAILCONF : Провалы из-за качества данных

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

Например, система планирования перевозок может показать загрузку самолетов на 130% от номинала и считать это нормальным.

Некоторые из классических проблем с качеством данных:

• ошибки в форматах данных (путаница в единицах измерения и форматах дат и времени,  известен случай сбоя в выполнении программы полёта спутника из-за некорректного преобразования из signed в unsigned при передаче данных между подсистемами);

• формальное отношение сотрудников к внесению исходных данных (копипаста);

• отсутствие или неполнота общих словарей;

• дубликаты;

• проблема перевода с разных человеческих языков (как например перевести корректно «ООО» –  «ООО», «LLC», «Ltd» или «LLP»?);

• отсутствие или недостаточность аудита исторических данных (например, изменение юридического статуса контрагента);

• проверка данных на возможность передачи во внешний мир (персональные и иные конфиденциальные данные).

Проблемы в попытках применить ИИ для диагностики COVID-19

Все знают о принципе garbage in – garbage out в применении машинного обучения. Однако, даже для такой актуальной задачи как диагностика COVID выявились проблемы с качеством данных (из обзора):

1. Данные сканирования грудной клетки детей, у которых не было ковида, в качестве примеров того, как выглядят случаи не-ковида. В результате ИИ научился определять детей а не ковид.

2. Данные сканирования включали пациентов в лежачем положении (с большей вероятностью эти пациенты были серьезно больны). В результате ИИ научился неправильно предсказывать серьезность риска коронавируса, исходя из положения человека (а если пациент стоял, то серьезность поражение лёгких ИИ просто игнорировал).

3. ИИ научился ориентироваться на шрифт текста, используемый разными лабораториями для маркировки изображений. В результате шрифты из больниц с более серьезной нагрузкой стали предикторами риска заражения коронавирусом. Конечно, при подготовке данных нужно было убирать маркировку.

4. Медицинские снимки помечаются в соответствии с тем, как их идентифицировал рентгенолог, а не по результатам ПЦР, таким образом в исходный датасет внесены нежелательные смещения (bias).

Адекватные цифровые двойники

Амбициозная задача создания цифровых двойников промышленных предприятий а тем более цифрового государства при отсутствии контроля качества данных закладывает потенциальную идеальную бомбу. 

Сложно будет найти виновных, если при проектировании и применении системы риск-ориентированного подхода  (RBI) к обеспечению эксплуатации нефтеперерабатывающего завода из-за ошибки в указании номинальной толщины будет некорректно рассчитан срок очередной диагностики одной из труб и именно она разорвется на мощности. Это тоже проблема качества данных.

Представим себе отточенную систему для расчета себестоимости продукции, в основе которой, конечно же, лежит информация о трудозатратах. Весь труд аналитика улетает в трубу, если сотрудники отражают рабочие часы в Redmine раз в неделю и от балды. Так и получается какой-нибудь болт с себестоимостью в десятки тысяч рублей.

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

Слишком много ручной работы

Ответ на вопрос – «Каковы наибольшие сложности для повышения эффективности вашей работы?»  – «Слишком много ручной работы».

Ручная работа требуется при внесении, чистке данных, проверке зависимостей, правке и тестировании кода ETL. Типичная задача это чистка списков адресов клиентов, заданных в разном формате.

При этом около половины опрошенных не используют специальных инструментов для Data Governance и контроля качества, треть использует самописные инструменты. Более половины проверяют качество данных сами, еще четверть спрашивают совета у других и лишь 12% уверены в качестве данных. 

О качестве данных замолвите слово

Статистика, приведенная выше взята в основном из результатов опроса сотрудников 230 компаний, базирующихся в США.

А как у нас? Приглашаю поделиться в комментариях примерами с неудачами внедрения data-проектов из-за грязных данных и историями успеха с очисткой и исправлением таких данных.

С одной стороны – не является ли эта проблема надуманной?

А с другой – возможно ли создание универсального инструмента по контролю качества данных, работающего из коробки?