Что такое валидация модели

Валидация данных

Привет, Хабр! В преддверии старта курса «Архитектор сетей» предлагаем прочитать перевод полезной статьи.

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

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

В более простом решении, использующем текстовые файлы для хранения сетевой модели данных (также известной как источник истины или source-of-truth), сложно выполнить тщательную проверку каждой транзакции, тем более, если для изменения этих файлов вы используете текстовый редактор. В этих случаях вам нужно писать собственный конвейер валидации, используя инструменты, которые проверяют:

синтаксис текстового файла;

соответствие схеме модели данных;

Используя нашу последнюю модель данных с per-link префиксами, которые хранятся как куча Ansible host_vars файлов и network.yml файл, конвейер валидации должен проверить что:

Все файлы соответствуют синтаксису YAML (чтобы сделать это, вы можете использовать такие инструменты как yamllint );

Факты о хостах содержат значения hostname и bgp_as для каждого хоста;

Core ссылки содержат prefix и как минимум два других значения;

Edge ссылки содержат одно значение, которое является словарем (или объектом, если вы предпочитаете терминологию JSON) с одним значением.

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

Валидация данных хоста

Из полученной JSON структуры данных нам нужно извлечь только переменные хоста, и jq идеально подходит для этой работы:

Валидация сетевой модели данных

Для проверки network.yml файла мы будем использовать аналогичный подход:

Convert YAML file into JSON format with yq

Преобразуем YAML файл в формат JSON с помощью yq

Run jsonschema on the resulting JSON file

Запустим jsonschema на полученном JSON файле

Как упоминалось выше, JSON Schema позволяет нам проверять грамматику модели данных, а ссылочную целостность — нет. Например:

Мы не можем проверить, валидны ли имена хостов, указанные для core или edge ссылок.

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

Пару слов о JSON Schema

Языки моделирования данных не для слабонервных, и JSON Schema не исключение. Замысловатая подача спецификации тоже не особо облегчает жизнь (мне было интереснее читать стандарты ISO или IEEE). К счастью, онлайн-книга Разбираемся с JSON Schema довольно хорошо объясняет все тонкости.

Просто чтобы вы прочувствовали, что такое JSON Schema: вот документ JSON, описывающий ожидаемую структуру данных переменных хоста, полученный из инвентаря Ansible:

Вот что можно сказать об этой схеме:

Она описывает инвентарные данные Ansible (Ansible inventory data);

Она содержит определения дополнительных схем (см. ниже).

Элемент верхнего уровня — это объект (словарь) с некоторыми свойствами (мы знаем, что это инвентарные имена хостов), и каждое свойство должно соответствовать схеме router

Минимальное количество свойств — одно (хотя бы один хост в файле инвентаризации).

Определение схемы router находится в свойстве definitions :

Согласно этой схеме роутер (если быть точнее, факты хоста Ansible, описывающие роутер) — это объект со следующими свойствами:

Числовым свойством bgpas , которое должно быть от 1 до 65535;

Строковым свойством hostname

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

Закатываем рукава

JSON схемы хоста и сети, а также исходный код скрипта проверки доступны на GitHub. Не стесняйтесь клонировать репозиторий, менять host_vars файлы или сетевую модель данных и запускать скрипт проверки в своих целях.

Вам также может захотеться исследовать JSON Schema побольше, в частности:

выяснить, что делает JSON схема network ;

добавить необязательное свойство description в модель данных роутера;

Вам понадобятся следующие инструменты:

Больше о валидации данных

Мы рассматриваем валидацию данных и конвейеры CI/CD более подробно в части Validation, Error Handling and Unit Tests нашего онлайн-курса Building Network Automation Solutions.

Дополнительная информация

Чтобы узнать больше об использовании моделей данных в решениях для автоматизации сети, ознакомьтесь с модулем 3 нашего онлайн-курса Building Network Automation Solutions.

Далее в программе

Data Model Hierarchy

Иерархия моделей данных

Подробнее о курсе «Архитектор сетей». Посмотреть запись открытого урока на тему «Overlay. Что это такое и зачем необходимо» можно здесь.

Источник

Валидация модели

Валидация модели [model validation] — проверка соответствия данных, получаемых в процессе машинной имитации, реальному ходу явлений, для описания которых создана модель. Производится тогда, когда экспериментатор убедился на предшествующей стадии (верификации) в правильности структуры (логики) модели. Состоит в том, что выходные данные после расчета на компьютере сопоставляются с имеющимися статистическими сведениями о моделируемой системе.

Смотреть что такое «Валидация модели» в других словарях:

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

валидация — 4.54 валидация (validation): Подтверждение (на основе представления объективных свидетельств) того, что требования, предназначенные для конкретного использования или применения, выполнены [3]. Примечание Валидация в контексте жизненного цикла… … Словарь-справочник терминов нормативно-технической документации

валидация манекена — 3.8 валидация манекена (manikin validation): Подтверждение посредством измерения точности компьютерного манекена того, что требования, предназначенные для конкретного использования или применения, выполнены. Примечание Определение точности… … Словарь-справочник терминов нормативно-технической документации

адекватность модели — Соответствие модели моделируемому объекту или процессу. [http://sl3d.ru/o slovare.html] адекватность модели Соответствие модели моделируемому объекту или процессу. Адекватность в какой то мере условное понятие, так как полного соответствия модели … Справочник технического переводчика

Адекватность модели — [adequacy of a model] соответствие модели моделируемому объекту или процессу. Адекватность в какой то мере условное понятие, так как полного соответствия модели реальному объекту быть не может: иначе это была бы не модель, а сам объект. При… … Экономико-математический словарь

ГОСТ Р ИСО 15536-2-2010: Эргономика. Компьютерные манекены и модели тела. Часть 2. Верификация функций и валидация размеров компьютерного манекена для систем моделирования — Терминология ГОСТ Р ИСО 15536 2 2010: Эргономика. Компьютерные манекены и модели тела. Часть 2. Верификация функций и валидация размеров компьютерного манекена для систем моделирования оригинал документа: 3.8 валидация манекена (manikin… … Словарь-справочник терминов нормативно-технической документации

Машинная имитация — Машинная имитация, или имитация на компьютере [simulation] экспериментальный метод изучения экономики с помощью электронной вычислительной техники. (В литературе часто в том же смысле применяется термин «имитационное моделирование«,… … Экономико-математический словарь

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

Имитационная модель — [simulator] экономико математическая модель изучаемой системы, предназначенная для использования в процессе машинной имитации. Она является по существу программой для компьютера, а эксперимент над ней состоит в наблюдении за результатами расчетов … Экономико-математический словарь

Источник

Валидация моделей машинного обучения

На связи команда Advanced Analytics GlowByte и сегодня мы разберем валидацию моделей.
Иногда термин «валидация» ассоциируется с вычислением одной точечной статистической метрики (например, ROC AUC) на отложенной выборке данных. Однако такой подход может привести к ряду ошибок.

В статье разберем, о каких ошибках идет речь, подробнее рассмотрим процесс валидации и дадим ответы на вопросы:

Расширяем понятие валидации

Что не так с валидацией как вычислением одной точечной статистической метрики на отложенной выборке данных?

Аргумент против № 1: одна метрика не может учесть все аспекты качества модели. Качество модели измеряется не только предсказательной способностью, но и, например, стабильностью во времени.

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

Аргумент против № 3: точечная оценка может варьировать в зависимости от состава валидационной выборки, особенно это касается не сбалансированных выборок (с соотношением классов 1:50 или более значимым перекосом). Поэтому стоит дополнительно делать интервальные оценки.

Аргумент против № 4: актуальные данные могут отличаться от исторических, на которых была построена модель, поэтому валидацию стоит делать и на актуальном срезе данных.

Аргумент против № 5: реальные проекты обычно представляют собой набор неоднородных (по сложности и перечню используемых технологий) скриптов, в которых могут быть неточности или неучтенные варианты поведения. Поэтому для корректной работы всего проекта необходимо проводить дополнительную проверку реализации модели, подготавливаемой к развертыванию, причем стоит учитывать не только зависимости между скриптами в проекте, но и порядок их запуска: при несоблюдении порядка они могут отработать без ошибок, но сформировать абсолютно неверный результат.

Валидация и жизненный цикл модели

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

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

Когда модель построена, выполняется первичная валидация, чтобы доказать работоспособность и оценить целесообразность внедрения разработанной модели.

На этапе внедрения проводится два вида проверок.

Тут может появиться вопрос, чем валидация отличается от мониторинга. Если коротко, то мониторинг — более легковесный процесс, проводимый с большей частотой.

Методика валидации

Все используемые при валидации тесты можно разделить на две группы: количественные и качественные.

В качестве артефакта по результатам валидации предоставляется отчет:

Рассмотрим детальнее список тестов для моделей бинарной классификации на примере модели прогноза вероятности дефолта (PD-модели) по кредитному договору (подробнее о PD-моделях см. [1]).

Количественная оценка

К группе относятся расчеты метрик и статистические тесты, которые оценивают качество модели на разных этапах и разных уровнях (перечисляем не все, возможны и другие).

1. Дискриминационная способность модели

После разработки модели первый вопрос, который интересует бизнес-заказчика: а насколько хорошо модель справляется со своей задачей? Если мы построили PD-модель, то этот вопрос звучит так: насколько хорошо модель отделяет клиентов, которые уйдут в дефолт, от тех, кто в дефолт не уйдет, и насколько лучше эта модель, чем случайное угадывание?

Чтобы ответить на это вопрос, проводим тесты:

В случае бинарного целевого события коэффициент Джини рассчитывается как отношение площадей двух фигур:

Альтернативный способ определения метрики — пузырьковая сортировка (подробнее см. [2]). Пусть имеется список значений целевого события, порядок в котором совпадает с порядком значений вероятности, прогнозируемых моделью. Тогда показатель Swaps будет обозначать количество перестановок соседних элементов для приведения списка целевых событий к отсортированному виду без инверсий.

На примере ниже число таких перестановок Swaps = 2.

где: – число перестановок для валидируемой модели, – для случайной модели.

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

О расчете коэффициента Джини для небинарных целевых событий см. в статье из цикла про риск-моделирование ([3]).

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

1000 и более) подвыборок, для каждой из которых рассчитывается коэффициент Джини. Затем проверяется, что заданный заранее перцентиль полученного распределения не пересекает фиксированный порог (например, если 2.5% перцентиль распределения коэффициентов Джини на уровне одного из факторов модели меньше 3%, то по тесту может быть выставлена оценка в виде красного сигнала).

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

Извлечение с повторением элементов выборки размера n с фиксированной вероятностью можно заменить на сэмплирование с помощью биномиального распределения частот появления каждого элемента выборки. При условии достаточно большого размера выборки выполняется следующий переход от биномиального распределения к пуассоновскому [4]:

2. Оценка стабильности

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

где: — доля наблюдений с i-м значением фактора; — количество наблюдений, соответствующих i-му значению фактора; — общее количество наблюдений в выборке ( — валидационная выборка, — выборка для разработки). (Если вы хотите почитать, в каких случаях еще используется PSI, см. например, статью про моделирование компоненты LGD из цикла про риск-моделирование [3].)

Один из способов интерпретации PSI – через дивергенцию Кульбака–Лейблера [5], меру удаленности двух распределений P и Q:

Мера несимметрична () и из двух срезов данных мы не можем выбрать априорное распределение, с которым будет проводиться сравнение, поэтому для симметричности оценки можно использовать сумму двух мер от P до Q и от Q до P:

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

Модель считается хорошо откалиброванной, если фактический уровень целевого события (доля наблюдений с фактическим целевым событием = 1) близок к средней прогнозируемой моделью вероятности. Для оценки качества калибровки модели можно проверять попадание наблюдаемого уровня целевого события в доверительный интервал предсказанных моделью вероятностей целевого события: в целом по модели или в рамках бакетов предсказанной вероятности.

Примеры тестов и метрик:

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

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

Для проверки концентрации используется индекс Херфиндаля–Хиршмана как в целом по выборке, так и в разрезе отдельных сегментов.

Рассчитывается по формуле:

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

Мы перечислили тесты, применимые к моделям в разных доменных областях. Но могут быть метрики, которые отражают специфику конкретного продукта. Например, при моделировании операционных рисков может быть установлено дополнительное ограничение, связанное с пропускной способностью подразделения, проводящего расследования по признанным моделью подозрительными наблюдениям. После того как модель присвоила скоры всем пользователям, топ 1% или 5% пользователей по скору передается для проверки такому подразделению, другие пользователи не будут проверяться. Поэтому необходимо, чтобы максимальное число клиентов с y_true=1 попали в топ 1% или топ 5%.

Также для отдельных моделей могут быть предусмотрены специфические тесты. Например, для LGD-моделей Loss Shortfall.

Loss Shortfall – метрика, указывающая, насколько потери от фактического дефолта оказались ниже, чем было предсказано моделью (методика расчета описана в [3]). По шкале выставления оценки для метрики Loss Shortfall видно (см. рисунок ниже), что оценка риска в данном случае производится консервативно, модель считается хорошей только в тех случаях, когда предсказанные потери выше, чем наблюдаемые.

Качественные тесты

Не все аспекты качества модели можно оценить количественно, поэтому вместе с ними при валидации применяются качественные тесты. Что можно проверять с их помощью?

1. Качество документации модели. Для обеспечения воспроизводимости модели необходима хорошая документация.

Оценить качество документации можно, определив, насколько хорошо задокументированы:

2. Дополнительно можно проверить качество использованных при разработке данных:

Заказчик может дополнительно запросить интерпретацию модели: если это регрессионная модель, то коэффициенты факторов; если decision tree/decision list, то набор правил; если более сложные модели, то отчет интерпретаторов SHAP/LIME.

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

Model performance predictor (MPP)

В определенных задачах бывает необходимо прогнозировать события, которые произойдут спустя месяцы. Например, клиент не выполнит свои обязательства по кредитному договору в течение года. Из-за этого лага возникает проблема: как понять, что модель стала хуже работать, до того как мы сможем увидеть это, до получения фактических значений целевого события?

Для решения такой проблемы наряду с основной строится дополнительная модель — Model Performance Predictor (MPP) [6].

Схема обучения MPP-модели

Для разработки MPP-модели используется тестовая выборка основной модели. Шаги по построению MPP-модели.

Заключение

В завершение сформулируем принципы, которые гарантируют, что валидация модели будет эффективна:

Бинарное целевое событие:

Материал подготовили: Илья Могильников (EienKotowaru), Александр Бородин (abv_gbc)

Источник