1 — Зачем для фидбека пользователю явная генерация гипотез? достаточно посмотреть на пришедшую выдачу и сказать «вот, мы тут добавили такой вариант», если он в выдачу пролез. Техническая причина остаётся, да.
2 — это интересная мысль, но не моя :)
Моя мысль другая. Целевая функция может быть не релевантность документа запросу, а релевантность документа запросу при условии клика на сниппет. И если под эту функцию ранжировать, то dcg-подобные метрики, предполагающие клики строго сверху вниз, конечно, просядут. Но счастье пользователя, читающего сниппеты, может вырасти. Интересно, думает ли сейчас кто-то в эту сторону, и если да — что получается.
Выше в комментах про апишку сегментатора писали, она называлась RCA. Но для внутреннего использования там ничего интересного не было, сегментатор + структурированные данные от новостей, всё это в ранжировании давно учитывается.
Спасибо за статью!
1. Видел в комментах, что система особенно хорошо справляется со сложными опечатками. А нельзя по такому случаю вообще выкинуть опечаточник, кормить трансформерам сразу сырой запрос и сэкономить на этом ещё сколько-то драгоценных миллисекунд?
2. Много лет назад я немножко носился с идеей учитывать в ранжировании предсказанную по сниппету открываемость документа, таким образом оптимизируя не успех пользователя, тупо кликающего сверху вниз, а успех того, который сниппет читает. Вы не думали какой-то новый заход сюда сделать с трансформерами? Возможно, персонализируясь с учётом разных паттеров чтения выдачи.
2 — это интересная мысль, но не моя :)
Моя мысль другая. Целевая функция может быть не релевантность документа запросу, а релевантность документа запросу при условии клика на сниппет. И если под эту функцию ранжировать, то dcg-подобные метрики, предполагающие клики строго сверху вниз, конечно, просядут. Но счастье пользователя, читающего сниппеты, может вырасти. Интересно, думает ли сейчас кто-то в эту сторону, и если да — что получается.
Выше в комментах про апишку сегментатора писали, она называлась RCA. Но для внутреннего использования там ничего интересного не было, сегментатор + структурированные данные от новостей, всё это в ранжировании давно учитывается.
1. Видел в комментах, что система особенно хорошо справляется со сложными опечатками. А нельзя по такому случаю вообще выкинуть опечаточник, кормить трансформерам сразу сырой запрос и сэкономить на этом ещё сколько-то драгоценных миллисекунд?
2. Много лет назад я немножко носился с идеей учитывать в ранжировании предсказанную по сниппету открываемость документа, таким образом оптимизируя не успех пользователя, тупо кликающего сверху вниз, а успех того, который сниппет читает. Вы не думали какой-то новый заход сюда сделать с трансформерами? Возможно, персонализируясь с учётом разных паттеров чтения выдачи.