Финансовый сектор уже давно одна большая "дата", когда банк принимает решение о том, выдать ли человеку или компании кредит, он анализирует сотни метрик. Я руковожу стримом Data Quality в Газпромбанке и расскажу о том, как мы решаем проблемы при интеграции с внешними источниками информации, какие оценочные метрики используем и как экспериментируем с моделями, прогоняя неверные данные.

Откуда берутся ошибки и чем внешние источники данных отличаются от внутренних

Чем больше данных, тем больше проблем, связанных с их качеством, причем к ошибкам может привести огромное количество причин.  Некоторые — банальные. Например, оператор при вводе персональных данных неправильно перепечатал ФИО из паспорта. Есть ошибки в проектировании систем. Скажем, разработчики проигнорировали требование к длине поля ввода данных. Например, поле «Паспорт выдан» ограничили 35 символами. Понятно, что нужно больше, но в системе сохраняются только первые 35 введенных символов: «ФМС Тверского района по городу Моск». Бывает, не учли, что какие-то данные вообще надо сохранять, а они потом потребовались. Например, пол клиента. Могут возникнуть сложности, связанные с потерей части данных при передаче информации из системы в систему в ходе ETL/ELT-процессов. При этом стоит разделять проблемы с качеством внутренних данных, которые находятся во внутрикорпоративных системах, и внешних, поступающих из сторонних источников. У нас в банке отлажены процессы по улучшению качества данных (КД), поэтому оно постоянно растет и стабильно выше, чем КД из внешних источников.

Качество данных из внешних источников: что может пойти не так

Яркий пример — бюро кредитных историй, которые агрегируют данные из разных компаний и предоставляют их другим организациям. Некоторые требования к качеству этих данных можно описать: заполнены критические поля, есть логические проверки, например, возраст клиента от 18 до 70 лет, и так далее. Но некоторую информацию невозможно проверить физически, — скажем, срок и сумму кредита. Здесь возможны только косвенные проверки на логику событий, поэтому возрастает вероятность ошибок.

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

Может сказаться чисто технический момент. Например, бюро кредитных историй предоставляют информацию по клиентам и их кредитам в конкретном машинно-читаемом  формате, скажем, XML-файле с четкой структурой данных. Время от времени Банк России модернизирует эти форматы, и тогда у бюро могут возникать проблемы. Ведь потребителей данных бюро кредитных историй много: одни уже переехали на обновленный формат обмена данным, а другие еще не успели. И самому бюро нужно изловчиться и обеспечить как прямую, так и обратную совместимость по данным, то есть новый формат не должен испортить процесс выгрузки для тех, кто еще не перешел на него. А тем, кто перешел, тоже нужно время на доработку процессов.

Отдельные риски ухудшения КД возникают при интеграции внешней информации во внутренние структуры данных. Например, в системах банка используются идентификаторы, позволяющие точно определять, о каком именно клиенте или заявке идет речь в данном случае. У внешних данных таких различителей нет, и тогда реального заемщика можно спутать с посторонним человеком с таким же именем и датой рождения (подобные «двойники» действительно встречаются).

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

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

Для разных задач нужен свой уровень качества данных

«Вишенка на торте» при перечислении проблем с КД — большая вариативность допустимого уровня качества. Он сильно зависит от специфики конкретных задач. Так, при оперативной оценке продаж кредитов в банке можно условно сказать, что за день выдали 100 млн рублей (плюс-минус один миллион). А в бухгалтерской отчетности даже плюс-минус одна копейка — недопустимая ошибка.

Все зависит от того, какие данные считаются качественными в конкретной ситуации. А это зависит от того, можно ли с их помощью решить поставленную задачу. Для одних задач количество ошибок на уровне 20% считается нормой, а для других даже 1% ошибочных данных — недопустимо много (при том, что абсолютного нуля не бывает).

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

Итак, проблем с КД для моделей — огромное количество. Для их устранения нет простых и гарантированных решений. Что делать?

В игру вступает команда спасателей данных 

Управлять качеством данных компаниям помогают отдельные команды, которые занимаются исключительно Data Quality. И не всякий человек из IT, умеющий писать программы, может стать инженером по качеству данных. Программисты, которые привыкли работать строго по бизнес-требованиям, вряд ли подойдут: здесь нужно не столько умение описывать обработку данных, сколько аналитические способности. Скорее карьера КД-специалиста подойдет программисту с аналитическим складом ума или бизнес-аналитику со знанием основ работы с данными в информационных системах.

У нас есть полноценное подразделение Data Quality — служба управления качеством данных, которая отвечает за улучшение КД во всем банке. Кроме того, в департаменте анализа данных и моделирования создан отдельный стрим по вопросам КД для моделей. Сейчас в этом стриме работает шесть человек, каждый из которых в среднем может поддерживать параллельно три витрины данных. Витрины обычно обновляются в одно и то же время, чаще всего раз в месяц.

Наш подход — сплошной контроль качества данных

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

Теоретическое обоснование такого подхода дает концепция Data Governance.

Также есть стандарт DMBOK (Data Management Body of Knowledge),  в котором прописаны все этапы взаимодействия с данными от момента их появления до утилизации. В 2009 году эксперты Международной ассоциации управления данными DAMA выпустили «Руководство DAMA к своду знаний по управлению данными (DMBOK)». Книга фактически заложила фундамент для развития новых профессий, относящихся к управлению данными. Позже вышло второе издание — DAMA-DMBOK2, есть перевод на русский язык. DAMA-DMBOK2 можно назвать сводом знаний — это полное и актуальное введение в дисциплину управления данными с обзором лучших практик. Рекомендую прочитать книгу всем, кто хочет профессионально заниматься задачами качества данных и другими вопросами из области управления данными.

Например, для практических шагов в Data Quality удобно использовать «пирамиду DMBOK2». Она включает все области знаний об управлении данными из DAMA DMBOK2 и помогает понять: на каком этапе компания находится сейчас и как двигаться дальше, чтобы выстроить надежные процессы управления данными.

Применительно к конкретному стриму «Качество данных моделей» концепция сплошного контроля КД включает такие основные элементы:

•  Мониторинг качества данных ключевых витрин в части моделирования.

•  Разработка новых промышленных правил контроля качества данных (ККД).

• Анализ инцидентов и оценка их влияния на бизнес.

• Участие в приемке доработок витрин (в части моделей).

•  Контроль статусов инцидентов корпоративного хранилища данных (КХД) и взаимодействия с офисом директора по цифровым технологиям (CDO, Chief Digital Officer).

• Проверка данных на предмет аномалий.

Данные для моделей — в чем главный подвох? В теории и на практике 

Теоретически задача взять под контроль качество внешних данных вполне решаемая. И понятно, как: сравнивать текущее качество данных с неким эталоном. Процесс можно автоматизировать, а человека подключать только в том случае, когда  выявлены отклонения и нужно проанализировать их причины. Но есть нюансы. Вот как это работает у нас.

Данные для моделирования — не сырые: это агрегированные данные из витрин, каждая из которых строится на десяти и более источниках, как внешних, так и внутренних, и хранит 1000 и более столбцов. При этом в каждой витрине обычно более 10 млн строк, а поддержка истории данных составляет от четырех лет, и чем глубже, тем лучше.

Доверительный интервал отклонений в сравнении с предыдущим срезом по ключевым метрикам установлен по умолчанию на уровне 10%. Есть три рабочих дня — время на анализ инцидентов для ежемесячных моделей. То есть в течение трех дней надо проанализировать все эти тысячу с лишним столбцов в витрине на предмет расхождений с эталоном.

Подвох в том, что при таких условиях прямая сверка данных с эталонными невозможна. Опять вопрос: что делать?

Сила контроля — в метриках качества

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

Всего мы используем около двух десятков метрик для контроля КД входного вектора моделей. В том числе, для числовых переменных: минимальное, максимальное, медианное и среднее значения, суммарное значение переменной за текущий срез, а для таблицы — количество пустых и заполненных значений по переменной в абсолютном и относительном выражении, а также отклонение. Порог допустимых отклонений мы приняли на уровне 10%. Иными словами, если отклонение в количестве построенных строк по сравнению с предыдущим срезом превышает 10%, это уже инцидент с КД, который требует дополнительного исследования.

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

Отдельно отмечу интересную метрику — индекс стабильности популяции (Population Stability Index, PSI). Он полезен для анализа изменений входных данных для розничных моделей. Скажем, при разработке модели популяцию клиентов составляли мужчины и женщины: 60% и 40% соответственно, при этом возраст половины клиентов составлял 30–45 лет, 30% — старше 50 лет и 20% — молодая аудитория в возрасте 20–30 лет. Если на очередном срезе мы увидим существенные изменения в наполнении переменных, например, выросла доля молодежи или женщин, значит, произошло изменение популяции клиентов (а на уровне данных — дрейф данных, data drift), и текущая модель для нее работает плохо.

Так что метрика PSI — прозрачная и легко интерпретируемая, поскольку дает конкретное значение. Если значение PSI < 0,1, изменений в выборке нет. Если PSI находится в интервале от 0,1 до 0,2, в выборке есть изменения и нужно разбираться. Значение PSI > 0,2 говорит о таких значительных изменениях в выборке, при которых использовать модель нельзя.

Коллеги говорят, что бывали ситуации, когда значение PSI превышало 0,2 и модель приходилось перестраивать. Однако за время моей работы в департаменте анализа данных и моделирования, а это уже больше года, такого не случалось.

Процессы и инциденты контроля качества данных: ближе к реальному времени

Сейчас мы сконцентрированы на ежемесячных моделях, для которых установлен регламент — три рабочих дня на анализ инцидентов. Но уже в работе витрина данных заявок из РКК (розничного кредитного конвейера), которая обновляется ежедневно, и одна из наших текущих задач — согласовать с заказчиком регламент анализа инцидентов.

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

Например, сейчас в Газпромбанке проходит исследовательский проект по оценке влияния ИКД на модель. Если коротко, мы искусственно искажаем данные по нескольким полям, и прогоняем модель по этим данным. То же самое делаем с качественными данными. Затем сравниваем результаты работы модели и пытаемся оцифровать расхождение в разных показателях: например, не выдали Х кредитов на сумму Y рублей. Детали раскрыть не могу, потому что сама методология обработки ИКД развивается вместе с этим проектом.

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

Напомню, что матрица RACI (или матрица ответственности) — инструмент для управления отношениями в команде. Это таблица, с помощью которой по всем задачам проекта распределяются роли исполнителей, их полномочия и ответственность. Собственно, основные роли и составляют название метода: Responsible (ответственный сотрудник), Accountable — исполнитель, Consult — консультант, Iinformed — тот, кого нужно проинформировать после произведенного действия.

В нашей матрице RACI появились два новых пункта:

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

• Проверка качества данных после после обновления витрины в промышленной эксплуатации.

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

Главное для нас при работе с витринами для моделирования — проверка данных на предмет аномалий. Поскольку поля витрины — это некие агрегаты, а не сырые данные, не всегда можно проверить их как-то иначе на полноту, логику и другие параметры. Хорошо то, что здесь есть возможность использовать готовые программные инструменты, например, библиотеки на языке Python или решения, позволяющие оценивать дрейф данных. Правда, мы оказались очень взыскательными пользователями и отбросили многие инструменты: одни не поддерживали нужные нам объемы данных, у других был неудобный интерфейс.

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

Обеспечение качества данных: промышленный подход

Сфера качества данных для моделей хайповая и молодая, в России ей нет и 10 лет. Большинство компаний уже поняли, что для эффективной работы качественных моделей нужны качественные данные. Сегодня идет переход на новый уровень постижения проблематики Data Quality — осознание того, что управление качеством данных не может быть разовой операцией или небольшим IT-проектом, реализуемым однажды.

Ведь даже при работе с внутренними данными регулярно происходят инциденты качества данных. Типичный пример: IT-специалисты обновили систему, но не учли, что это повлияет на какой-то процесс. Или одно из полей  обнулилось. Или выносили обновления, и витрина-источник не собралась вовремя, новые данные не поступили. Продолжать можно бесконечно. Мораль: данных с «вечным» качеством не бывает, работать над улучшением нужно постоянно. И заниматься этим должна специализированная команда профессионалов.

Заменить специалистов по качеству данных каким-нибудь программным роботом (RPA) невозможно, потому что ежедневное управление качеством данных — далеко не рутинные процедуры «нажимания кнопок». Специалист в области Data Quality должен точно понимать процессы, особенности данных, разбираться в предметной области. Иными словами, разбирая инциденты КД, инженер глубоко погружается в специфику бизнес-процесса и основное время при разборе тратит на понимание глубинных причин проблем с данными. Для этого требуются аналитические способности, которые есть только у человеческого ума.