Итак, про плюсы и минусы подхода:
Начнём с минусов.
➖ Вся кандидато-генерация, в том числе способ измерения её качества, начинают существенно зависеть от текущего метода ранжирования. Это увеличивает сложность, нужно это учитывать при сравнении. И когда ранкер меняется, ранние стадии нужно переобучать.
➖ Чаще всего системы изначально строятся без следования этому принципу. И перевести систему в состояние следования из другого состояния может быть очень сложно. В частности, если у системы довольно плохое ранжирование (но благодаря разным хакам результат рекомендаций приемлемый), то следование этому принципу не сделает систему лучше, а наоборот, может в моменте сильно ухудшить рекомендации.
➖ Принцип предполагает, что ранкер должен хорошо работать на всей базе. В противном случае, если есть плохие документы, которые ранкер ошибочно порекомендовал бы, то кандидато-генерация, пытаясь угодить ранкеру, рано или поздно тоже их найдёт. Это несколько усложняет обучение ранкера по сравнению со случаем, когда он работает только на множестве уже достаточно неплохих кандидатов.
➖ Кандидато-генерация не пытается улучшить end-to-end метрики сервиса. Можно её улучшить согласно этому принципу, но получить красный эксперимент. (Впрочем, это будет как раз означать, что в ранжировании есть проблема, например неправильный target.) Это усложняет работу: улучшаешь-улучшаешь, а выкатить потом не можешь.
➖ Ограниченная поддержка бизнес-правил. Этот принцип говорит, что все такие правила (кроме жестких) надо применять на финальной стадии, а ранние будут сами приспосабливаться к ним. И это не только про костыли, но и про полезные аспекты рекомендаций вроде exploration, diversity, etc. (Придётся выдавать разнообразных кандидатов, потому что ранжирование их выбирает.)
А теперь к плюсам.
➕ Принцип основан на декомпозиции. У ранних стадий появляется более понятная и измеримая цель, и это сильно упрощает систему. Вся сложность с выбором таргетов и лоссов для рекомендаций концентрируется в ранжировании (где от этого всё равно не уйти), здесь же решается чисто утилитарная задача эффективного нахождения топа. Ранние стадии — просто инструмент для ускорения ранжирования.
➕ В этом принципе нет фундаментальных ограничений. Если представить себе идеальную систему рекомендаций, то ничего не мешает ей быть устроенной именно так. (Чего нельзя сказать про остальные подходы — не обязаны идеальные рекомендации угадывать то, с чем пользователь и сам потом взаимодействовал!) И с улучшением ранжирования такие упрощенные метрики кандидато-генерации становятся всё ближе к end-to-end метрикам. Так же, как в известном в определенном кругу итеративном подходе "улучшаем метрики — улучшаем продукт по этим метрикам".
➕ Разные стадии ранжирования согласованы друг с другом, они не пытаются оптимизировать разные вещи. В системах же, где это не так, если взять и, скажем, увеличить общее число кандидатов вдвое, то качество всей системы может не улучшиться, а, наоборот, деградировать. Например, если ранние стадии оптимизировали некую релевантность, то дополнительные кандидаты будут менее релевантными, и общая релевантность снизится (хотя кликабельность возрастёт).
➕ Как следствие пункта про декомпозицию: ранние стадии намного проще измерять (а значит, и оптимизировать). В упрощённом случае, когда финальное ранжирование определяется только какой-то моделью (без других правил), можно запустить её на двух методах кандидато-генерации и сравнить средние предсказания. А обучение в этом упрощенном случае сводится, по сути, к дистилляции модели ранжирования. (Хотя тут есть нюансы. Например, хорошо бы логировать некоторых кандидатов, которые не попали в топ ранжирования.)
➕ Более того, для обучения и измерения ранних стадий нам теперь не нужны пользователи, и поэтому необязательно выкатывать новый метод на них. Можно, например, использовать scraping, т.е. обстреливать сервис ранжирования новыми кандидатами.
Главная задача ранних стадий состоит в том, чтобы найти наилучшие документы с точки зрения финального ранжирования.
Начнём с минусов.
➖ Вся кандидато-генерация, в том числе способ измерения её качества, начинают существенно зависеть от текущего метода ранжирования. Это увеличивает сложность, нужно это учитывать при сравнении. И когда ранкер меняется, ранние стадии нужно переобучать.
➖ Чаще всего системы изначально строятся без следования этому принципу. И перевести систему в состояние следования из другого состояния может быть очень сложно. В частности, если у системы довольно плохое ранжирование (но благодаря разным хакам результат рекомендаций приемлемый), то следование этому принципу не сделает систему лучше, а наоборот, может в моменте сильно ухудшить рекомендации.
➖ Принцип предполагает, что ранкер должен хорошо работать на всей базе. В противном случае, если есть плохие документы, которые ранкер ошибочно порекомендовал бы, то кандидато-генерация, пытаясь угодить ранкеру, рано или поздно тоже их найдёт. Это несколько усложняет обучение ранкера по сравнению со случаем, когда он работает только на множестве уже достаточно неплохих кандидатов.
➖ Кандидато-генерация не пытается улучшить end-to-end метрики сервиса. Можно её улучшить согласно этому принципу, но получить красный эксперимент. (Впрочем, это будет как раз означать, что в ранжировании есть проблема, например неправильный target.) Это усложняет работу: улучшаешь-улучшаешь, а выкатить потом не можешь.
➖ Ограниченная поддержка бизнес-правил. Этот принцип говорит, что все такие правила (кроме жестких) надо применять на финальной стадии, а ранние будут сами приспосабливаться к ним. И это не только про костыли, но и про полезные аспекты рекомендаций вроде exploration, diversity, etc. (Придётся выдавать разнообразных кандидатов, потому что ранжирование их выбирает.)
А теперь к плюсам.
➕ Принцип основан на декомпозиции. У ранних стадий появляется более понятная и измеримая цель, и это сильно упрощает систему. Вся сложность с выбором таргетов и лоссов для рекомендаций концентрируется в ранжировании (где от этого всё равно не уйти), здесь же решается чисто утилитарная задача эффективного нахождения топа. Ранние стадии — просто инструмент для ускорения ранжирования.
➕ В этом принципе нет фундаментальных ограничений. Если представить себе идеальную систему рекомендаций, то ничего не мешает ей быть устроенной именно так. (Чего нельзя сказать про остальные подходы — не обязаны идеальные рекомендации угадывать то, с чем пользователь и сам потом взаимодействовал!) И с улучшением ранжирования такие упрощенные метрики кандидато-генерации становятся всё ближе к end-to-end метрикам. Так же, как в известном в определенном кругу итеративном подходе "улучшаем метрики — улучшаем продукт по этим метрикам".
➕ Разные стадии ранжирования согласованы друг с другом, они не пытаются оптимизировать разные вещи. В системах же, где это не так, если взять и, скажем, увеличить общее число кандидатов вдвое, то качество всей системы может не улучшиться, а, наоборот, деградировать. Например, если ранние стадии оптимизировали некую релевантность, то дополнительные кандидаты будут менее релевантными, и общая релевантность снизится (хотя кликабельность возрастёт).
➕ Как следствие пункта про декомпозицию: ранние стадии намного проще измерять (а значит, и оптимизировать). В упрощённом случае, когда финальное ранжирование определяется только какой-то моделью (без других правил), можно запустить её на двух методах кандидато-генерации и сравнить средние предсказания. А обучение в этом упрощенном случае сводится, по сути, к дистилляции модели ранжирования. (Хотя тут есть нюансы. Например, хорошо бы логировать некоторых кандидатов, которые не попали в топ ранжирования.)
➕ Более того, для обучения и измерения ранних стадий нам теперь не нужны пользователи, и поэтому необязательно выкатывать новый метод на них. Можно, например, использовать scraping, т.е. обстреливать сервис ранжирования новыми кандидатами.