50 оттенков дебага рекомендательной системы

В честь взаимного пиара RecSys-каналов я вспомнил, что у меня тоже есть, о чём рассказать. Расскажу поучительную историю из совсем недавнего опыта.

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

1) Когда мы обучаем такую модель, нам нужно иметь актуальный список событий на момент времени каждого сэмпла. То есть, если мы пытаемся учить модель на то, лайкнул ли юзер данный пост 1 июля, на вход модели не должны подаваться действия за 2-е июля.

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

Представьте ситуацию - вы сделали такой пайплайн, обучили модель и ваш первый результат - модель даёт адекватный профит. Но как понять, что всё работает, как нужно?

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

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

Я считаю, что нужно делать хотя бы одну проверку с полнотой, близкой к 100%. Именно она позволила мне обнаружить нетривиальный баг в коде:

Я обучал нейросеть предсказывать что-то на протяжении с 1 по 7 июня, а для построения входного списка событий использовал другую таблицу с данными до 4 июня. Это гарантировало на 100% отсутствие заглядывания в будущее для сэмплов за 5-7 июня. И действительно, на этих днях лосс взлетал вверх. Баг был, но никакого намёка на причину, специфичность проверки равна 0.

После пары дней депрессии и втыкания в код, я увидел в одном месте append вместо appendleft, что создавало одновременно и лик, и порчу данных. После починки, профит на 5-7 июня стал почти таким же, как на 1-4, так что, у сказки счастливый конец. Дебажьте внимательно, дорогие друзья.

@knowledge_accumulator