Comments 65
Клик на основе заголовка — не показатель ценности ссылки (для пользователя). Он может быть обманут заголовком, что происходит примерно в 100% случаев. Хотя, для Яндекса, наверное, это реальная цель — если ссылка рекламная.
Все верно, заголовка мало чтобы сделать хорошее предсказание релевантности. Но это тем не менее ценный, хотя и шумный источник информации — например он позволяет отбросить очень большое число результатов, явно не относящихся к теме. Для ранжирования цель как раз в том, чтобы показать пользователю релевантный результат, который он захочет не просто «кликнуть» и закрыть, а прочитать. Конечно понять реальное содержание только по заголовку невозможно, но на практике это вещи достаточно сильно скоррелированные. Наши новые нейросети, в том числе YATI, смотрят уже далеко не только на заголовок.
Даже в тех случаях, когда у нас остались нейросети, которые используют только заголовок, мы не ранжируем выдачу непосредственно по их предсказанию. Выход нейросети затем подается в модель CatBoost, которая уже обладает гораздо более полной информацией и может скорректировать предсказание в случаях, когда нейросеть ошибается.
Даже в тех случаях, когда у нас остались нейросети, которые используют только заголовок, мы не ранжируем выдачу непосредственно по их предсказанию. Выход нейросети затем подается в модель CatBoost, которая уже обладает гораздо более полной информацией и может скорректировать предсказание в случаях, когда нейросеть ошибается.
Ну вот самый типичный сценарий:
1. Запрос к поиску.
2. Сразу, не глядя даже на результат — клик на вторую страницу выдачи.
3. Практически без участия сознания, просто на рефлексах Ctrl-Click на несколько ссылок подряд.
4. Последовательный просмотр открывшихся табов, 80% из которых захлопываются через 3-5 сек после начала просмотра.
5. Остаются 1-2, которые читаются внимательно и до упора.
По-моему, Ваш алгоритм будет получать категорически неверное подкрепление со стороны пользователя.
1. Запрос к поиску.
2. Сразу, не глядя даже на результат — клик на вторую страницу выдачи.
3. Практически без участия сознания, просто на рефлексах Ctrl-Click на несколько ссылок подряд.
4. Последовательный просмотр открывшихся табов, 80% из которых захлопываются через 3-5 сек после начала просмотра.
5. Остаются 1-2, которые читаются внимательно и до упора.
По-моему, Ваш алгоритм будет получать категорически неверное подкрепление со стороны пользователя.
Конечно, сигнал от пользователя смещен. Вы один из источников такого смещения описали вполне точно. Но, во-первых, вопрос не только в возможности описанного сценария, но и в его частотности в обучающей выборке. Во-вторых, наш итоговый таргет (по которому ранжируется выдача) — это экспертная оценка. Клик (в рамках темы рассказа) нужен только для того, чтобы на больших и шумных данных выучить общие закономерности (сделать предобучение). Для этой цели клики — это незаменимый источник полезной информации.
Однако, если ранжировать по вероятности клика, получится очень плохо. Поэтому мы дообучаем свои модели на экспертных оценках. Тут одна из главных причин, почему трансформер так полезен — он очень хорошо выучивает именно экспертный сигнал на сравнительно небольшом количестве примеров. Это позволяет убрать смещения, которые могли появиться в модели после долгого обучения на клики в pre-train.
Однако, если ранжировать по вероятности клика, получится очень плохо. Поэтому мы дообучаем свои модели на экспертных оценках. Тут одна из главных причин, почему трансформер так полезен — он очень хорошо выучивает именно экспертный сигнал на сравнительно небольшом количестве примеров. Это позволяет убрать смещения, которые могли появиться в модели после долгого обучения на клики в pre-train.
Вектор мешка слов затем пропускается через несколько плотных слоёв нейронов, на выходе которых образуется семантический вектор (иначе эмбеддинг, от англ. embedding, вложение; имеется в виду, что исходный объект-текст вкладывается в n-мерное пространство семантических векторов).
Очень круто. Но все-таки есть некое ощущение, что помимо такого нейронного "брутфорса" есть и аналитическое решение, более эффективное.
Аналитических и эвристических решений в поиске уже очень много. Ими мы занимались с момента появления ранжирования в Яндексе. Сейчас по таким алгоритмам уже достигли почти полного насыщения — новые признаки приносят очень мало добавленной пользы. Реальность такова, что «нейронный брутфорс» — это пока наиболее выгодное вложение усилий (в терминах размена времени разработки на рост качества).
При этом обучение моделей на самом деле требует своих подходов и эвристик — на какую задачу учить, как представить входные данные, какие примеры и в каком порядке показывать и т.д. В статье проиллюстрирован только самый простой случай. Так что это не чисто вычислительная, но и содержательно инженерная задача )
При этом обучение моделей на самом деле требует своих подходов и эвристик — на какую задачу учить, как представить входные данные, какие примеры и в каком порядке показывать и т.д. В статье проиллюстрирован только самый простой случай. Так что это не чисто вычислительная, но и содержательно инженерная задача )
UFO just landed and posted this here
Вы приводите достаточно частный случай.
Если система по запросу распознала, что речь идёт про фильм, то логично, что она предлагает больше информации, связанной с этим фильмом. А в русскоязычном сегменте интернета Кинопоиск — самый информативный ресурс о кино.
Если ввести в поиск например «капибара» или «дезоксирибонуклеиновая кислота», то картина будет совсем другая.
Если система по запросу распознала, что речь идёт про фильм, то логично, что она предлагает больше информации, связанной с этим фильмом. А в русскоязычном сегменте интернета Кинопоиск — самый информативный ресурс о кино.
Если ввести в поиск например «капибара» или «дезоксирибонуклеиновая кислота», то картина будет совсем другая.
на всех местах ссылки на свои сервисы + википедию?А википедия-то вам чем не угодила?
UFO just landed and posted this here
Именно для ранжирования пока использовали только сравнительно простые подходы. И здесь не увидели улучшений за использование более сложных алгоритмов. Но это важная для нас задача, я про нее упоминаю в статье. Попробовать более качественные методы, например суммаризацию или выделение основных смысловых частей страницы отдельной нейронной сетью, — обязательно хотим.
«Стримы тоже содержат полезную информацию, но с ними нам ещё надо поработать, чтобы понять, как её эффективно донести до поиска.»
На данный момент стримы не используются в этой модели?
Сложнее всего оказалось выделить хорошие фрагменты текста документа.
Используется ли для выделения фрагментов компьютерное зрение? Ведь текст может быть скрыт, либо добавлен при помощи JS.
В модели YATI сейчас используется только «естественное» содержимое страницы — то есть то, что можно получить из ее HTML описания.
Компьютерное зрение для анализа документа в ранжировании веб-страниц не используется. JS вообще говоря тут не помеха, у нас есть возможность заранее «отрендерить» страницу, так как это произошло бы в браузере, и извлечь все текстовые данные из итогового HTML описания после исполнения скриптов.
Компьютерное зрение для анализа документа в ранжировании веб-страниц не используется. JS вообще говоря тут не помеха, у нас есть возможность заранее «отрендерить» страницу, так как это произошло бы в браузере, и извлечь все текстовые данные из итогового HTML описания после исполнения скриптов.
Вопрос не в самом js (хотя, насколько помню, Яндекс не работает с ним), а в том, что контент реально видимый пользователем, и то, что получает ваш бот, может отличаться в плане смысловой значимости фрагментов. Это как-то учитывается?
> Яндекс не работает с ним
Работает ) есть нюансы связанные с тем, что не для каждой js страницы мы принимаем решение ее отрендерить.
По второй части вопроса можете еще раз пояснить, или привести пример? Речь про то что на странице есть визуальный контент (e.g. нарисованный текст), который наша модели не сможет «прочитать»? Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?
Работает ) есть нюансы связанные с тем, что не для каждой js страницы мы принимаем решение ее отрендерить.
По второй части вопроса можете еще раз пояснить, или привести пример? Речь про то что на странице есть визуальный контент (e.g. нарисованный текст), который наша модели не сможет «прочитать»? Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?
Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?
Да, про это. Но, не смысл, а скорее значимость. В тексте же речь шла именно о присвоении значимости для разных фрагментов. Можно ли считать значимым текстовый фрагмент, который визуально недоступен для пользователей?
И еще — в каких сегментах получен максимальный прирост в качестве ранжирующей модели? Ну, т.е. вроде как понятно, что для информационных запросов (пример с отдыхом) он должен быть выше, чем для «купить кофеварку», но мало ли…
> не смысл, а скорее значимость
Такое мы умеем сейчас учитывать через алгоритм автоматической сегментации, который разбивает текстовое содержимое страницы на «зоны» разной значимости. Я его кратко упоминаю в статье. Например, мы поймем, что фрагмент текста находится в футере страницы и там скорее всего нет «смыслового» содержания. Но тут конечно есть что улучшить. Визуальная доступность явно не моделируется.
> в каких сегментах получен максимальный прирост
Это очень хороший вопрос ) Мы видим, что есть очень значимое общее улучшение качества поиска. При более детальном рассмотрении можно увидеть характерные примеры, где YATI лучше «понимает» пользователя. Например, в тех случаях когда в запросе есть неочевидная (редкая) опечатка, или есть омонимичные сущности (e.g. это название компании или обычное существительное?), в сложных запросах, где важно понимать порядок и связь слов (e.g. к какому существительному относится прилагательное), и в целом там, где в запросе есть много взаимосвязанных понятий. Но это наверняка не все.
Такое мы умеем сейчас учитывать через алгоритм автоматической сегментации, который разбивает текстовое содержимое страницы на «зоны» разной значимости. Я его кратко упоминаю в статье. Например, мы поймем, что фрагмент текста находится в футере страницы и там скорее всего нет «смыслового» содержания. Но тут конечно есть что улучшить. Визуальная доступность явно не моделируется.
> в каких сегментах получен максимальный прирост
Это очень хороший вопрос ) Мы видим, что есть очень значимое общее улучшение качества поиска. При более детальном рассмотрении можно увидеть характерные примеры, где YATI лучше «понимает» пользователя. Например, в тех случаях когда в запросе есть неочевидная (редкая) опечатка, или есть омонимичные сущности (e.g. это название компании или обычное существительное?), в сложных запросах, где важно понимать порядок и связь слов (e.g. к какому существительному относится прилагательное), и в целом там, где в запросе есть много взаимосвязанных понятий. Но это наверняка не все.
Помню, в яндексе была апишка по извлечению основного текста документа, и работала она криво, а потом вовсе закрылась:) Вряд ли алгоритмами сегментации сотрудникам заниматься также интересно, допускаю, что работают они весьма кривовато)
Про апишку не знаю, поэтому не смогу прокомментировать ) Сегментация работает достаточно хорошо — за использование текстов из нее получается заметный прирост качества модели. Улучшить наверняка можно.
Вы говорите про сегментацию и её возросшую значимость, хотелось бы узнать какими рамками определяется сегмент, имеет ли место вложенная (древовидная) сегментация?
Насколько важны теги заголовков для каждого отдельного сегмента, имеет ли значение семантическая верстка html5 (e.g. section,article,header,footer) или любая DOM-структура помогает сегментировать текстовый контент?
Другими словами, как вебмастер может расставить акценты, чтобы помочь машине правильно сегментировать текстовый контент?
Спасибо за вопрос ) Текущий алгоритм в первую очередь выделяет области с основным текстовым содержанием (содержание статьи на хабре, описание товара в магазине, etc) и дополнительно смотрит на общую структуру, включая заголовки разделов. При этом может использоваться как вся доступная нам разметка и структура на веб-странице, так и структура самого текста (т.е. не размеченная явно, но понятная из синтаксиса и содержания). Поэтому у страницы должно быть хорошее текстовое содержание, которое (при большом объеме текста) логично поделено на разделы с информативными заголовками. Явная разметка упростит задачу для наших алгоритмов. Если текста немного (условно 10 предложений или меньше), то мы скорее всего просто «прочитаем» его целиком и никакого дополнительного деления не требуется.
Подчеркну, что сегментация используется только для выделения фрагментов, которые мы покажем модели, но не для оценки их относительной значимости. Это «решает» уже модель. Например, в конкретном случае модель вполне может решить что текст размеченный как заголовок на самом деле не информативен, и тогда он не повлияет на предсказание.
Подчеркну, что сегментация используется только для выделения фрагментов, которые мы покажем модели, но не для оценки их относительной значимости. Это «решает» уже модель. Например, в конкретном случае модель вполне может решить что текст размеченный как заголовок на самом деле не информативен, и тогда он не повлияет на предсказание.
Спасибо за ответ, а что если я наблюдаю ситуацию, когда субъективно (i.e. на мой взгляд) важные текстовые элементы (например, содержащие интент) сложно структурированной страницы игнорируются органическим поиском, т.е. я не могу найти в выдаче свой сайт по уникальным кускам текста по точному вхождению, используя различные операторы.
Теория следующая: текст не был представлен модели или модель сочла его неважным.
Вопрос: какой сигнал ускорит показ модели текста с отдельно взятой страницы для оценки повторно? Например, достаточно ли для этого отправить страницу на переобход? Или важно существенное изменения текста, а если изменилась структура страницы без изменения текста? Как часто (в каких приблизительных временных диапазонах) это происходит в естественном ритме, происходит ли отправка текстовых сегментов модели при каждом новом сканировании проиндексированной страницы?
Подчеркну, спасибо за ответ и за Вашу статью)
> какой сигнал ускорит показ модели текста с отдельно взятой страницы для оценки повторно?
Тут нет простого практического ответа. Расчет модели действительно происходит при каждом переобходе страницы, частота которого зависит от разных факторов. Если страница популярная, и контент на ней меняется часто (e.g. новостной ресурс), мы можем ее переобходить несколько раз в час. Но вполне могут быть и дни-недели, так как физически невозможно быстро переобходить все важные для нас страницы из Интернета.
Если содержимое страницы не поменялось, то переобход для модели YATI ничего не изменит — произойдет повторное применение к тем же фрагментам текста, что и раньше.
Наверняка есть способы повысить «привлекательность» веб-страницы конкретно для текущей модели, но это мне не кажется правильной постановкой задачи. Хотя бы потому что модель вполне может сильно измениться при следующем релизе. У веб-мастера должна быть цель написать текст, который 1) хорошо читается и понимается пользователями, 2) логично поделен на секции, так чтобы у нашей модели или у сегментатора было больше очевидных «структурных признаков», которые можно использовать при анализе. А у нас должна быть цель эту информацию учиться лучше использовать.
Понимаю, что это не очень помогает решить конкретную проблему на конкретной странице. В совсем явных случаях, когда очевидно что наш поиск «не видит» содержимого, можно это присылать к нам в виде жалоб. Мы стремимся к тому, чтобы регулярно их разбирать ) Починить каждую конечно не можем, но про крупные проблемы точно хотим знать.
Тут нет простого практического ответа. Расчет модели действительно происходит при каждом переобходе страницы, частота которого зависит от разных факторов. Если страница популярная, и контент на ней меняется часто (e.g. новостной ресурс), мы можем ее переобходить несколько раз в час. Но вполне могут быть и дни-недели, так как физически невозможно быстро переобходить все важные для нас страницы из Интернета.
Если содержимое страницы не поменялось, то переобход для модели YATI ничего не изменит — произойдет повторное применение к тем же фрагментам текста, что и раньше.
Наверняка есть способы повысить «привлекательность» веб-страницы конкретно для текущей модели, но это мне не кажется правильной постановкой задачи. Хотя бы потому что модель вполне может сильно измениться при следующем релизе. У веб-мастера должна быть цель написать текст, который 1) хорошо читается и понимается пользователями, 2) логично поделен на секции, так чтобы у нашей модели или у сегментатора было больше очевидных «структурных признаков», которые можно использовать при анализе. А у нас должна быть цель эту информацию учиться лучше использовать.
Понимаю, что это не очень помогает решить конкретную проблему на конкретной странице. В совсем явных случаях, когда очевидно что наш поиск «не видит» содержимого, можно это присылать к нам в виде жалоб. Мы стремимся к тому, чтобы регулярно их разбирать ) Починить каждую конечно не можем, но про крупные проблемы точно хотим знать.
Вы подтвердили мои личные наблюдения и теории) Манипулировать алгоритмом цели не стоит, но определенный паттерн у вебмастеров (и seo-специалистов) в конкурентной среде модель неизбежно создаст. Надеюсь, что развитие Вашей модели идет в сторону динамики, а не инерции) Спасибо за ответ. В поддержку Яндекса пишем-с, но чаще всего получаем стандартный ответ, попробую другие формулировки)
Может быть я уже наглею, но может ли большое количество "неинтересных" для поиска страниц на сайте "замылить" действительно важные страницы и тексты на них?
> может ли большое количество «неинтересных» для поиска страниц на сайте «замылить» действительно важные страницы и тексты на них
В крайних случаях думаю может. Например, модель вполне может выучивать свойства хоста как целого и использовать это как первое приближение к ответу. Тогда ей потребуется больше «сигнала», чтобы преодолеть такое выученное смещение. Но это скорее общая теория, на практике таких примеров не встречал.
В крайних случаях думаю может. Например, модель вполне может выучивать свойства хоста как целого и использовать это как первое приближение к ответу. Тогда ей потребуется больше «сигнала», чтобы преодолеть такое выученное смещение. Но это скорее общая теория, на практике таких примеров не встречал.
Немного не по теме, но я не понимаю, как Яндекс-поиск считает хиты. Возьмём произвольное непонятное слово, и вычислим, насколько оно часто используется. Например, «Абдо». При поиске Абдо Яндекс даёт 2 млн. хитов (слово исключительно популярное?). Но если взять «Абдо» в кавычки, то уже 5 тыс. хитов (Что??? Куда исчезли все 2 млн. упоминаний?).
С Гуглом тоже интересно. Он для Абдо даёт 396 тыс. хитов, и для «Абдо» — 437 тыс. (больше чем в 1-м запросе, уже странно). Но если начать листать, то страниц с результатами окажется всего 16, а самих результатов по факту — всего 152.
С Гуглом тоже интересно. Он для Абдо даёт 396 тыс. хитов, и для «Абдо» — 437 тыс. (больше чем в 1-м запросе, уже странно). Но если начать листать, то страниц с результатами окажется всего 16, а самих результатов по факту — всего 152.
Например, оказывается, что почти бесполезно брать в качестве отрицательных документы, для которых был показ, но не было «клика» по запросу
Правильно ли я понял, что в качестве отрицательных примеров берутся пары запрос-выдача (документы), по которым были переформулировки запроса без клика на документы?
Можно по разному делать. Но общая суть в том, что отрицательный пример 1) должен быть действительно (по смыслу) отрицательным, 2) не должен быть похож на «случайный». В эвристиках это обычно сводится к тому, что положительный пример — это клик по одному запросу q1, а отрицательный пример берется с выдачи по другому запросу q2, который нужно как-то найти. Один из способов это сделать — брать q1 и q2 из одной последовательности «переформулировок».
UFO just landed and posted this here
Выше в комментариях было похожее предложение, чтобы при разбросе возможных ответов на запрос поисковая система сама выделяла основные «контексты» и предлагала из них выбрать правильный. Например по запросу [трансформер] — что хотите: игрушку, кино или нейронную сеть?
Я соглашусь, что это интересная идея для фичи ) Частично такие сценарии закрываются, например, уже существующим саджестом, который предлагает частотные варианты уточнений. Но он все таки решает в бОльшей степени задачу ускорения ввода для частотных версий запроса, чем удобства на менее частотных.
Я соглашусь, что это интересная идея для фичи ) Частично такие сценарии закрываются, например, уже существующим саджестом, который предлагает частотные варианты уточнений. Но он все таки решает в бОльшей степени задачу ускорения ввода для частотных версий запроса, чем удобства на менее частотных.
Отсекает ли алгоритм «кликовые факторы» от ботов? Не являются ли в целом поведенческие факторы слишком шумными для серьёзного их учёта в ранжировании? Алгоритмы того же Google учитывают их значительно меньше именно по причине возможности манипулировать ими.
Да, конечно отсекает. Для этого есть отдельные алгоритмы и целые под-системы для обнаружения роботов и фильтрации фрода (fraud, то есть «мошеннических» кликов, намеренно манипулирующих поисковой системой). Без учета кликов построить конкурентную поисковую систему сейчас невозможно. Разные варианты их использования в большей или меньшей степени подвержены проблемам с шумом и накрутками. Но в то же время это самый разнообразный семантический сигнал доступный поиску.
Есть только одно существенное Но — у Яндекса из-за рекламы поиск сложно разглядеть.
Спасибо за статью, очень круто и интересно! Вопрос: вы пишете что для инференса использовалась внутренняя библиотека, а для обучения модели какая библиотека использовалась? Тоже какая-то внутренняя или Tensorflow?
Дополню вопрос: там caboost?
Для обучения используем TensorFlow + Horovod / NCCL для распределенного режима. Одна из основных причин — у нас есть классные специалисты, которые умеют готовить именно TF и выжимать из него максимум производительности. PyTorch + DeepSpeed пробовали в экспериментах, тоже выглядит рабоче.
Планируется ли разработка собственных GPU, вроде Goole TPU?
Планируете выкладывать языковые модели в опен-сорс, как Сбер с ruGPT-3?
Планируете выкладывать языковые модели в опен-сорс, как Сбер с ruGPT-3?
Спасибо за статью!
У меня вопрос по первой части. Вы пишете, что из документов делаете стримы. А нет ли у вас среди генерируемых стримов текстов вопросов, которые мог бы задать пользователь к этой статье? Кажется, задача генерации вопросов к тексту должна очень хорошо решаться сетями — и тогда вы получаете супер-релевантный мэтч.
У меня вопрос по первой части. Вы пишете, что из документов делаете стримы. А нет ли у вас среди генерируемых стримов текстов вопросов, которые мог бы задать пользователь к этой статье? Кажется, задача генерации вопросов к тексту должна очень хорошо решаться сетями — и тогда вы получаете супер-релевантный мэтч.
Вы имеете в виду, что можно генерировать вероятные запросы пользователей прямо по содержимому документа, а потом использовать их в поиске и ранжировании? Такое пробовали делать раньше, с помощью более простых нейросетей. Например, через поиск близких к документу запросов по семантическим векторам. Оно работает, но не приносит сверх профита и при наивной реализации очень сильно увеличивает средний объем текстовых данных, которые нужно хранить для документа. На трансформерах повторить пока не пробовали.
Планируете ли выкладывать что нибудь предобученное в общий доступ? Понятное дело что итоговую модель нецелесообразно, но что насчет обученной на сырых данных для последующего дообучения под свои задачи?
Сейчас YATI — это специализированное решение для нашего ранжирования. Даже на уровне предварительного обучения, где мы используем сигнал от кликов пользователей (на самом деле не только — экспертный сигнал там тоже уже есть). Ее в открытый доступ выкладывать не будем. Мы думаем на тему того, чтобы обучить модель более общего назначения и померить ее на стандартных NLP задачах. Такая уже может быть интересна и полезна широкой аудитории )
Можете рассказать для каких задач Вы хотели бы использовать такую модель?
Можете рассказать для каких задач Вы хотели бы использовать такую модель?
Лично мне была бы интересна модель которая или обучена или годится для дообучения в задаче отнесения сайтов к одному из классов: коммерческий, некоммерческий, системный и мусор (возможно больше классов). Системный это всевозможные api, мусор это мертвые ссылки, заглушки и т.п. На входе модели ключевые слова, содержимое сайта, может еще что то из метаданных.
Кажется в одной из ваших лекций я видел что в Яндексе было разделение сайтов на коммерческие/некоммерческие, но вроде это было сделано эвристиками.
Кажется в одной из ваших лекций я видел что в Яндексе было разделение сайтов на коммерческие/некоммерческие, но вроде это было сделано эвристиками.
Александр, подскажите, какого числа и месяца технология применяется в поиске.
По ней все-все запросы ранжируются или какая-то часть. Есть часть, то какова ее доля (в процентах, примерно) и что это за запросы, быть может, наиболее популярные?
По ней все-все запросы ранжируются или какая-то часть. Есть часть, то какова ее доля (в процентах, примерно) и что это за запросы, быть может, наиболее популярные?
У ребёнка зависли сегодня зависли часы, попытался найти в яндексе решение проблемы и вот выдача — prnt.sc/vqd69x на первых предлагаемых страницах нет даже намёка на аналогичный запрос…
Более того, в поиске рассчитываются тысячи факторов, но если выключить их все и оставить только новую модель, то качество ранжирования по основной офлайн-метрике упадёт лишь на 4-5%!
Насколько я понимаю, катбуст выстраивает сплиты в дереве по значимости фактора для ранжирования. Более значимые — выше.
Вопросы:
1) Раз новый метод показывает такую высокую эффективность, то он должен быть высоко в решающем дереве. То есть, можно ли говорить о том, что новый метод используется для практически всего объема запросов к яндексу?
Скажем, в гугле про берт говорили про около 10% запросов.
2) Сократился ли размер решающего дерева (кол-во сплитов) после внедрения нового метода?
3) Как бы вы оценили влияние нового метода в ранжировании коммерческих запросов? Там же нет больших текстов, а те, что есть, достаточно насыщены ключами.
И немного не понял про определение куска текста, наиболее важного для ранжирования.
Сначала, вы пишите, что у Палеха и Королева есть проблемы с релевантностью на сложных документах, потому что не умеет выделять зоны.
А потом:
Сложнее всего оказалось выделить хорошие фрагменты текста документа.
уже про берт.
Хотя, как я понял, берт должен это уметь сам.
Спасибо за вопрос ) Попробую ответить по порядку.
1 и 2 — Решающие деревья в GBDT работают немного по-другому. Глубина дерева фиксирована, мы ее в наших моделях CatBoost не меняем. Если есть сильный признак, то сплит по нему будет просто встречаться чаще (и возможно выше) в дереве той же глубины, и соответственно будет сильнее влиять на итоговое предсказание. Размер влияния можно увидеть например по метрике FSTR, которая численно оценивает вклад конкретного признака в предсказание. В случае с YATI — вклад новой модели заметно больше 50% от суммарного вклада всех признаков. В этом смысле трансформер решает «больше половины» задачи ранжирования.
3 — коммерческие запросы тоже бывают разные; текст документа с товаром там действительно сравнительно простой, но даже там есть нюансы — например, есть ли в тексте подробное описание, технические характеристики и т.д.; релевантным по коммерческому запросу может быть не только страница товара, но и страница с обзором, обсуждением или отзывом, где уже есть сложное текстовое содержание; наконец, сам запрос может быть сформулирован сложно, тут трансформер тоже помогает
У Палеха и Королева есть проблемы с качеством по разным причинам. Во первых потому, что сами сети сильно проще и модель текста тоже упрощенная (тот самый «мешок слов»). Поэтому с длинным связным текстом они справляются плохо. Трансформер это умеет делать лучше, но все равно показать ему весь текст страницы — сложно, хотя бы из соображений производительности. Поэтому мы выделяем из всей страницы фрагменты текста и подаем их YATI на вход. Это заметно лучше раньше, но это все еще не полное содержимое документа.
1 и 2 — Решающие деревья в GBDT работают немного по-другому. Глубина дерева фиксирована, мы ее в наших моделях CatBoost не меняем. Если есть сильный признак, то сплит по нему будет просто встречаться чаще (и возможно выше) в дереве той же глубины, и соответственно будет сильнее влиять на итоговое предсказание. Размер влияния можно увидеть например по метрике FSTR, которая численно оценивает вклад конкретного признака в предсказание. В случае с YATI — вклад новой модели заметно больше 50% от суммарного вклада всех признаков. В этом смысле трансформер решает «больше половины» задачи ранжирования.
3 — коммерческие запросы тоже бывают разные; текст документа с товаром там действительно сравнительно простой, но даже там есть нюансы — например, есть ли в тексте подробное описание, технические характеристики и т.д.; релевантным по коммерческому запросу может быть не только страница товара, но и страница с обзором, обсуждением или отзывом, где уже есть сложное текстовое содержание; наконец, сам запрос может быть сформулирован сложно, тут трансформер тоже помогает
У Палеха и Королева есть проблемы с качеством по разным причинам. Во первых потому, что сами сети сильно проще и модель текста тоже упрощенная (тот самый «мешок слов»). Поэтому с длинным связным текстом они справляются плохо. Трансформер это умеет делать лучше, но все равно показать ему весь текст страницы — сложно, хотя бы из соображений производительности. Поэтому мы выделяем из всей страницы фрагменты текста и подаем их YATI на вход. Это заметно лучше раньше, но это все еще не полное содержимое документа.
тяжёлые нейросети для поиска по смыслуАга, только вот «смысл» этот заточен чаще всего под банальное «продать».
Конкретный пример: ввожу в поиске слово «кроссовки».
Результат: из 20 ссылок на первой странице лишь одна ведет на обзорную статью, и та рекламного характера, к тому же на Яндекс.Дзене. Остальные ссылки ведут в магазины за покупкой.
Разве я спрашивал «купить кроссовки»? Нет! Перед приобретением я хочу узнать, какие кроссовки бывают, из каких материалов делаются, где и кем производятся, и так далее.
Поэтому убедительная просьба к Яндексу: выделяйте место на первой странице под некоммерческую информацию, хотя бы на 50%. Только тогда это будет реально соответствовать заявленным Принципам Яндекса:
Принципы Яндекса (выдержка):
Мы создаём сервисы, которые приносят пользу людям и дают им новые возможности. Мы делаем сервисы, которыми хотели бы пользоваться сами, делиться с друзьями и близкими. Мы не создаём сервисы только ради зарабатывания денег.
Пользователь — наш главный заказчик, то есть тот, для кого мы работаем и делаем сервисы. Это касается не только людей, которые обращаются к Яндексу за решением повседневных задач, но и наших партнёров: магазинов, ресторанов, курьеров, водителей, создателей контента и всех остальных. Все они наши пользователи.
Мы осознаём свою ответственность за сервисы, которыми пользуются миллионы людей, и стараемся развивать их таким образом, чтобы максимизировать пользу и минимизировать вред.
Некоторые сервисы мы развиваем несмотря на то, что они никогда не станут прибыльными. Мы делаем так потому, что верим в их ценность и пользу для людей.
Яндекс открыт к диалогу с обществом и государством. Умение слушать общество и реагировать на общественные запросы, оставаясь при этом в правовом поле, — необходимое условие развития компании.
Ранжирование результатов поиска происходит на основе критерия полезности — того, насколько конкретный элемент на соответствующем месте решает задачу пользователя наряду с другими элементами по запросу. Сервисы Яндекса также ранжируются по этому принципу.
Перед приобретением я хочу узнать, какие кроссовки бывают, из каких материалов делаются, где и кем производятся, и так далее.
Само по себе это слово такого смысла не содержит. А без смысла, просто по упоминанию на странице — разнообразные магазины и будут большей частью страниц в интернете.
Как я уже писал выше, уж если ищется 'по смыслу' — то поисковик должен показать пользователю те варианты смысла, которые он нашел/видел/понимает, и предложить пользователю выбрать нужный.
Спасибо за статью!
1. Видел в комментах, что система особенно хорошо справляется со сложными опечатками. А нельзя по такому случаю вообще выкинуть опечаточник, кормить трансформерам сразу сырой запрос и сэкономить на этом ещё сколько-то драгоценных миллисекунд?
2. Много лет назад я немножко носился с идеей учитывать в ранжировании предсказанную по сниппету открываемость документа, таким образом оптимизируя не успех пользователя, тупо кликающего сверху вниз, а успех того, который сниппет читает. Вы не думали какой-то новый заход сюда сделать с трансформерами? Возможно, персонализируясь с учётом разных паттеров чтения выдачи.
1. Видел в комментах, что система особенно хорошо справляется со сложными опечатками. А нельзя по такому случаю вообще выкинуть опечаточник, кормить трансформерам сразу сырой запрос и сэкономить на этом ещё сколько-то драгоценных миллисекунд?
2. Много лет назад я немножко носился с идеей учитывать в ранжировании предсказанную по сниппету открываемость документа, таким образом оптимизируя не успех пользователя, тупо кликающего сверху вниз, а успех того, который сниппет читает. Вы не думали какой-то новый заход сюда сделать с трансформерами? Возможно, персонализируясь с учётом разных паттеров чтения выдачи.
1 — нет, по нескольким причинам. Вот две, которые сходу приходят в голову. Техническая: трансформер пока используется не на всех этапах ранжирования; чтобы не потерять хороший документ в самом начале, все еще нужен опечаточник. Продуктовая: при неоднозначном исправлении опечатки важно дать фидбек пользователю о том, что исправление было; для этого тоже нужен опечаточник и явная генерация гипотез.
2 — верно ли я понял вашу мысль, что клик пользователя, прочитавшего сниппет, более информативен (или как минимум содержит дополнительную полезную информацию) по сравнению с обычным кликом? И, соответственно, если от модели спрятать урл и заголовок, и оставить только сниппет, то она ровно такой клик и научится предсказывать? Моделями на сниппетах мы раньше занимались, и там было сложно найти полезный сигнал, поэтому в то, что наивный подход даст что то новое не очень верю. Трансформеры на сниппетах пока подробно не смотрели. При этом сама тема «качества» клика нас конечно очень интересует.
2 — верно ли я понял вашу мысль, что клик пользователя, прочитавшего сниппет, более информативен (или как минимум содержит дополнительную полезную информацию) по сравнению с обычным кликом? И, соответственно, если от модели спрятать урл и заголовок, и оставить только сниппет, то она ровно такой клик и научится предсказывать? Моделями на сниппетах мы раньше занимались, и там было сложно найти полезный сигнал, поэтому в то, что наивный подход даст что то новое не очень верю. Трансформеры на сниппетах пока подробно не смотрели. При этом сама тема «качества» клика нас конечно очень интересует.
1 — Зачем для фидбека пользователю явная генерация гипотез? достаточно посмотреть на пришедшую выдачу и сказать «вот, мы тут добавили такой вариант», если он в выдачу пролез. Техническая причина остаётся, да.
2 — это интересная мысль, но не моя :)
Моя мысль другая. Целевая функция может быть не релевантность документа запросу, а релевантность документа запросу при условии клика на сниппет. И если под эту функцию ранжировать, то dcg-подобные метрики, предполагающие клики строго сверху вниз, конечно, просядут. Но счастье пользователя, читающего сниппеты, может вырасти. Интересно, думает ли сейчас кто-то в эту сторону, и если да — что получается.
Выше в комментах про апишку сегментатора писали, она называлась RCA. Но для внутреннего использования там ничего интересного не было, сегментатор + структурированные данные от новостей, всё это в ранжировании давно учитывается.
2 — это интересная мысль, но не моя :)
Моя мысль другая. Целевая функция может быть не релевантность документа запросу, а релевантность документа запросу при условии клика на сниппет. И если под эту функцию ранжировать, то dcg-подобные метрики, предполагающие клики строго сверху вниз, конечно, просядут. Но счастье пользователя, читающего сниппеты, может вырасти. Интересно, думает ли сейчас кто-то в эту сторону, и если да — что получается.
Выше в комментах про апишку сегментатора писали, она называлась RCA. Но для внутреннего использования там ничего интересного не было, сегментатор + структурированные данные от новостей, всё это в ранжировании давно учитывается.
Сейчас набрал уникальную фразу в кавычках со своего сайта, — из 14-ти первых результатов 8 ведут на subscribe.ru, на котором, по-моему, уже нет реальных подписчиков, остальные — на каталоги ссылок и на математич. форум. А куда делись остальные страницы результатов?
А откуда в поиске брались непонятные страницы с абракадаброй из фраз, набранных с разных сайтов? И почему они имели неплохие позиции?
А откуда в поиске брались непонятные страницы с абракадаброй из фраз, набранных с разных сайтов? И почему они имели неплохие позиции?
YATI лучше понимает большие тексты. Как быть с типовым интернет-магазином, где действительно много копипаста (характеристики и фото с завода-производителя и т.д.). Не приведет ли это к смешению жанров коммерческих и информационных страниц, когда те же сео-специалисты (предположим) будут наращивать текстовое содержимое карточек товаров. Ведь суть специальности SEO — адаптация сайта под поисковую машину, а не под пользователя. Косвенные данные о YATI могут быть восприняты вебмастерами как некий KPI, который все тут же бросятся накручивать. Не приведет ли это к беспорядку, хаосу в выдаче?
Меня искренне волнует, почему нейросети Яндекса не справляются с запросом "гол задницей", "гол задницей видео", а гугл отрабатывает наура
Sign up to leave a comment.
Трансформеры в Поиске: как Яндекс применил тяжёлые нейросети для поиска по смыслу