Как мы видели в Часть-2, г-на Рокета Сингха попросили организовать встречу с группой проверки и обсудить, как следует проверять и контролировать модель. идти вперед. Г-н Бакши является менеджером по валидации, и г-н Рокет Сингх начал рассказывать ему о своей модели на встрече.
Г-н. Бакши :- Итак, г-н Ракет Сингх, я просмотрел ваш отчет и результаты работы, которыми вы поделились со своим менеджером, и я понял, как работает модель XGBoost, а также такие методы, как LIME, SHAP, график частичной зависимости и т. д., которые мы можем использовать, чтобы лучше понять вашу модель, но как мы будем отслеживать производительность вашей модели в будущем. Результаты, которыми вы поделились, одинаковы для разных периодов времени, но скажем, в период мониторинга, если значения AUC падают/увеличиваются, то как мы поймем, почему это происходит?
Г-н. Ракета Сингх: Верно, я только к этому и шел. Можете ли вы рассказать мне, как вы контролируете модель логистической регрессии?
Г-н. Бакши: - В логистической регрессии, поскольку мы используем объединенные переменные, мы вычисляем Значение информации (IV) конечных переменных, которые использовались в модели в период мониторинга (с те же бины, что и за период разработки) и сравнить его со значениями IV периода разработки. Это помогает нам понять, какие переменные на самом деле вызывают увеличение/уменьшение производительности модели.
Г-н. Ракета Сингх: — Хорошо, мы можем сделать это в логистической регрессии, потому что нет эффектов взаимодействия, но XGBoost — это древовидная модель, в основе которой лежит отдельная переменная, и мы не сможем комментировать производительность модели. Таким образом, вместо того, чтобы рассматривать только отдельные переменные, мы также должны сравнить силу их взаимодействия.
Г-н. Бакши: - Я не понял тебя. Не могли бы вы взять пример и объяснить мне.
Г-н. Ракета Сингх :-Конечно, предположим, что мы хотим создать систему показателей приложения для жилищного кредита (гипотетический пример). Окончательные переменные, которые использовались в модели, следующие:
Теперь, как мы получаем информационную ценность в логистической регрессии, для XGBoost мы получаем информационный прирост. Таким образом, может быть случай, когда доход имел бы очень высокое значение прироста информации в период разработки, но значение снизилось в период мониторинга.
Г-н. Бакши :- Тогда значение AUC также упало бы, и мы должны перестроить модель.
Г-н. Ракета Сингх: - Значение AUC упало бы, если бы это была модель логистической регрессии, но не обязательно в модели XGBoost. Если мы посмотрим на эти переменные отдельно, мы почувствуем, что люди с более высоким доходом с большей вероятностью получат жилищный кредит. Но XGBoost не работает с отдельными переменными, он работает с правилами и взаимодействиями между переменными. Даже если у человека более высокий доход, но он взял несколько других кредитов и имеет много иждивенцев, у него больше шансов не выполнить свои обязательства, чем у человека, который имеет сравнительно меньший доход без других кредитов и меньше иждивенцев. Таким образом, может быть случай, когда в период разработки разделение по переменной «Доход» давало хороший выигрыш, а не в период мониторинга. Но общее взаимодействие между доходом, количеством других кредитов и количеством иждивенцев все равно даст вам хороший выигрыш. Единственное отличие состоит в том, что в период разработки вклад прибыли от разделения на переменную «Доход» был очень высоким по сравнению с периодом мониторинга.
В приведенном выше примере, если вы просто посмотрите на переменную Income, вы скажете, что переменная сила уменьшилась, но на самом деле она увеличила свою силу, взаимодействуя с другими функциями, чего не было в процессе разработки.
Г-н. Бакши :- Имеет смысл, но как мы можем получить значения прироста информации для каждого пути?
Г-н. Rocket Singh: — Вы можете получить эти значения усиления для модели, которую вы построили в период разработки, проанализировав все деревья (количество деревьев, используемых в вашей модели XGBoost). Для периода мониторинга вам потребуется перенастроить модель (с теми же гиперпараметрами и теми же переменными, которые использовались в период разработки) на период мониторинга и получить эти значения.
Г-н. Бакши :- Хорошо, но если мы изменим модель, может случиться так, что новая модель изучит новый набор взаимодействий на основе данных периода мониторинга.
Г-н. Ракета Сингх : - Верно!! Итак, допустим, во время разработки у вас было 20 пар (взаимодействие между двумя функциями), а во время мониторинга у вас есть еще 20 пар. Если имеется много перекрывающихся пар, это хороший признак того, что шаблон все еще сохраняется, но если количество перекрывающихся пар меньше, это вызывает беспокойство.
Г-н. Бакши :- Но, используя то же обоснование, которое вы объяснили выше, скажем, есть только 10 перекрывающихся пар (50%), но производительность модели все еще хорошая, тогда что следует делать в этом случае.
Г-н. Ракета Сингх: - Если показатель производительности не уменьшился, это означает, что сила взаимодействия между этими 10 перекрывающимися парами увеличилась по сравнению с периодом разработки, и переменные все еще работают. Эти проверки следует проводить только в том случае, если производительность модели снизилась, чтобы понять, в чем причина этого.
Г-н. Бакши :- Хорошо, если производительность модели снизилась, мы должны понять причину этого и попросить «Перестроить», верно??
Г-н. Ракета Сингх: - Не совсем так, производительность модели снизилась из-за весов/взаимодействий, изученных в период разработки. Окончательные переменные могут по-прежнему давать вам хорошую производительность, если вы измените веса/взаимодействия. Это похоже на повторную калибровку вашей модели, а не на ее перестройку с нуля.
Г-н. Бакши :- Хорошо, так как же мы сможем понять, должны ли мы перекалибровать модель или перестроить ее??И если мы решим перекалибровать, как мы должны поступить??
Г-н. Ракета Сингх :- Поэтому, когда вы обновляете модель (с теми же переменными и теми же гиперпараметрами, что и при разработке) в период мониторинга, рассчитайте показатель производительности (в нашем случае AUC) и посмотрите, дает ли он хорошие результаты. Если это так, то это означает, что окончательные переменные все еще работают, но изменились только веса/взаимодействия. Таким образом, вместо того, чтобы перестраивать модель с нуля, что займет значительное время, было бы лучше использовать эти пересмотренные веса/взаимодействия и, при необходимости. вы также можете настроить гиперпараметры, чтобы повысить производительность.
Г-н. Бакши :- Хорошо, я понимаю, скажите мне одну вещь: размер набора правил будет зависеть от глубины деревьев, которые вы строите в модели XGBoost, верно?
Г-н. Ракета Сингх : - Верно
Г-н. Бакши :- Тогда предположим, что если глубина велика, нам придется отслеживать значения усиления на каждом уровне, и это будет слишком громоздко.
Г-н. Ракета Сингх: - Полностью с вами согласен. Как вы знаете, XGBoost — это метод ансамбля, в котором несколько деревьев строятся последовательно, и каждое дерево пытается исправить ошибки, допущенные предыдущим деревом. Поэтому, если я построю деревья с большей глубиной, то модель не будет настолько эффективной, поскольку все деревья будут изучать одни и те же правила. В таком случае было бы идеально использовать одно дерево решений, а не ансамбль деревьев. В идеале в XGBoost наша цель состоит в том, чтобы сделать неглубокие деревья (глубина 2 или 3) и заставить их изучать разные правила из набора данных, чтобы они не переобучались и хорошо обобщали невидимые данные.
Г-н. Бакши :- Хорошо, понятно, какова максимальная глубина деревьев в вашей модели?
Г-н. Ракета Сингх :-2, я буду делиться приростом информации в каждом сплите за все периоды времени.
Г-н. Бакши :- Хорошо, я проверю это и дам вам знать, если у меня возникнут какие-либо опасения.
Г-н. Rocket Singh :-Конечно, вы также можете найти коды и подробную информацию о работе, используя ссылку ниже.
