Сейчас у нас настроен мониторинг отдельных моделей на источниках - при каждом продовом инференсе мы контролируем, не «поехали» ли данные относительно зафиксированного бейзлайна, рассчитывая PSI - в данный момент мы доверяем такому подходу. В дальнейшем мы планируем добавить мониторинг эмбеддингов как входов единой модели (например, оценивать embedding drift).
Если что-то сильно «поехало», мы можем переобучить и перевнедрить такую модель, здесь проблем быть не должно. Сейчас это новый для нас подход, мы обязательно придем к отлаженной и устойчивой схеме контроля качества данных для него.
Идея с заменой пропуска на усредненный эмбеддинг на самом деле похожа на то, как мы заполняли пропуски скоров раньше, когда смешивали их логистической регрессией: в том случае мы заполняли пропуски нулями, после чего при обучении логрега добавляли признак пропуска, который равен 1, когда есть пропуск, и 0 в противном случае. Так модель сама подбирала константное значение, которым заполнить пропуск. Такая схема в ретроспективе себя достаточно хорошо показала при инференсе на потоке.
Что касается Вашей идеи: ранее в задаче кредитного скоринга мы действительно обучали несколько моделей под разные сегменты (но не по критерию наличия/отсутствия данных из источника по клиенту), но мы такую схему больше не применяем, так как обучение одной модели на всех сегментах позволило получить более высокое качество за счет объема данных. Использование дополнительных отдельных моделей в зависимости от наличия данных из источника по клиенту может сильно усложнить схему инференса, потребует дополнительных ресурсов и не факт, что даст прирост в качестве (по аналогии с примером выше). Но, в любом случае, идея интересная, и мы попробуем с этим поэкспериментировать.
Сейчас у нас настроен мониторинг отдельных моделей на источниках - при каждом продовом инференсе мы контролируем, не «поехали» ли данные относительно зафиксированного бейзлайна, рассчитывая PSI - в данный момент мы доверяем такому подходу. В дальнейшем мы планируем добавить мониторинг эмбеддингов как входов единой модели (например, оценивать embedding drift).
Если что-то сильно «поехало», мы можем переобучить и перевнедрить такую модель, здесь проблем быть не должно. Сейчас это новый для нас подход, мы обязательно придем к отлаженной и устойчивой схеме контроля качества данных для него.
Идея с заменой пропуска на усредненный эмбеддинг на самом деле похожа на то, как мы заполняли пропуски скоров раньше, когда смешивали их логистической регрессией: в том случае мы заполняли пропуски нулями, после чего при обучении логрега добавляли признак пропуска, который равен 1, когда есть пропуск, и 0 в противном случае. Так модель сама подбирала константное значение, которым заполнить пропуск. Такая схема в ретроспективе себя достаточно хорошо показала при инференсе на потоке.
Что касается Вашей идеи: ранее в задаче кредитного скоринга мы действительно обучали несколько моделей под разные сегменты (но не по критерию наличия/отсутствия данных из источника по клиенту), но мы такую схему больше не применяем, так как обучение одной модели на всех сегментах позволило получить более высокое качество за счет объема данных. Использование дополнительных отдельных моделей в зависимости от наличия данных из источника по клиенту может сильно усложнить схему инференса, потребует дополнительных ресурсов и не факт, что даст прирост в качестве (по аналогии с примером выше). Но, в любом случае, идея интересная, и мы попробуем с этим поэкспериментировать.