1 — нет, по нескольким причинам. Вот две, которые сходу приходят в голову. Техническая: трансформер пока используется не на всех этапах ранжирования; чтобы не потерять хороший документ в самом начале, все еще нужен опечаточник. Продуктовая: при неоднозначном исправлении опечатки важно дать фидбек пользователю о том, что исправление было; для этого тоже нужен опечаточник и явная генерация гипотез.
2 — верно ли я понял вашу мысль, что клик пользователя, прочитавшего сниппет, более информативен (или как минимум содержит дополнительную полезную информацию) по сравнению с обычным кликом? И, соответственно, если от модели спрятать урл и заголовок, и оставить только сниппет, то она ровно такой клик и научится предсказывать? Моделями на сниппетах мы раньше занимались, и там было сложно найти полезный сигнал, поэтому в то, что наивный подход даст что то новое не очень верю. Трансформеры на сниппетах пока подробно не смотрели. При этом сама тема «качества» клика нас конечно очень интересует.
> может ли большое количество «неинтересных» для поиска страниц на сайте «замылить» действительно важные страницы и тексты на них
В крайних случаях думаю может. Например, модель вполне может выучивать свойства хоста как целого и использовать это как первое приближение к ответу. Тогда ей потребуется больше «сигнала», чтобы преодолеть такое выученное смещение. Но это скорее общая теория, на практике таких примеров не встречал.
> какой сигнал ускорит показ модели текста с отдельно взятой страницы для оценки повторно?
Тут нет простого практического ответа. Расчет модели действительно происходит при каждом переобходе страницы, частота которого зависит от разных факторов. Если страница популярная, и контент на ней меняется часто (e.g. новостной ресурс), мы можем ее переобходить несколько раз в час. Но вполне могут быть и дни-недели, так как физически невозможно быстро переобходить все важные для нас страницы из Интернета.
Если содержимое страницы не поменялось, то переобход для модели YATI ничего не изменит — произойдет повторное применение к тем же фрагментам текста, что и раньше.
Наверняка есть способы повысить «привлекательность» веб-страницы конкретно для текущей модели, но это мне не кажется правильной постановкой задачи. Хотя бы потому что модель вполне может сильно измениться при следующем релизе. У веб-мастера должна быть цель написать текст, который 1) хорошо читается и понимается пользователями, 2) логично поделен на секции, так чтобы у нашей модели или у сегментатора было больше очевидных «структурных признаков», которые можно использовать при анализе. А у нас должна быть цель эту информацию учиться лучше использовать.
Понимаю, что это не очень помогает решить конкретную проблему на конкретной странице. В совсем явных случаях, когда очевидно что наш поиск «не видит» содержимого, можно это присылать к нам в виде жалоб. Мы стремимся к тому, чтобы регулярно их разбирать ) Починить каждую конечно не можем, но про крупные проблемы точно хотим знать.
Спасибо за вопрос ) Текущий алгоритм в первую очередь выделяет области с основным текстовым содержанием (содержание статьи на хабре, описание товара в магазине, etc) и дополнительно смотрит на общую структуру, включая заголовки разделов. При этом может использоваться как вся доступная нам разметка и структура на веб-странице, так и структура самого текста (т.е. не размеченная явно, но понятная из синтаксиса и содержания). Поэтому у страницы должно быть хорошее текстовое содержание, которое (при большом объеме текста) логично поделено на разделы с информативными заголовками. Явная разметка упростит задачу для наших алгоритмов. Если текста немного (условно 10 предложений или меньше), то мы скорее всего просто «прочитаем» его целиком и никакого дополнительного деления не требуется.
Подчеркну, что сегментация используется только для выделения фрагментов, которые мы покажем модели, но не для оценки их относительной значимости. Это «решает» уже модель. Например, в конкретном случае модель вполне может решить что текст размеченный как заголовок на самом деле не информативен, и тогда он не повлияет на предсказание.
Сейчас YATI — это специализированное решение для нашего ранжирования. Даже на уровне предварительного обучения, где мы используем сигнал от кликов пользователей (на самом деле не только — экспертный сигнал там тоже уже есть). Ее в открытый доступ выкладывать не будем. Мы думаем на тему того, чтобы обучить модель более общего назначения и померить ее на стандартных NLP задачах. Такая уже может быть интересна и полезна широкой аудитории )
Можете рассказать для каких задач Вы хотели бы использовать такую модель?
1 и 2 — Решающие деревья в GBDT работают немного по-другому. Глубина дерева фиксирована, мы ее в наших моделях CatBoost не меняем. Если есть сильный признак, то сплит по нему будет просто встречаться чаще (и возможно выше) в дереве той же глубины, и соответственно будет сильнее влиять на итоговое предсказание. Размер влияния можно увидеть например по метрике FSTR, которая численно оценивает вклад конкретного признака в предсказание. В случае с YATI — вклад новой модели заметно больше 50% от суммарного вклада всех признаков. В этом смысле трансформер решает «больше половины» задачи ранжирования.
3 — коммерческие запросы тоже бывают разные; текст документа с товаром там действительно сравнительно простой, но даже там есть нюансы — например, есть ли в тексте подробное описание, технические характеристики и т.д.; релевантным по коммерческому запросу может быть не только страница товара, но и страница с обзором, обсуждением или отзывом, где уже есть сложное текстовое содержание; наконец, сам запрос может быть сформулирован сложно, тут трансформер тоже помогает
У Палеха и Королева есть проблемы с качеством по разным причинам. Во первых потому, что сами сети сильно проще и модель текста тоже упрощенная (тот самый «мешок слов»). Поэтому с длинным связным текстом они справляются плохо. Трансформер это умеет делать лучше, но все равно показать ему весь текст страницы — сложно, хотя бы из соображений производительности. Поэтому мы выделяем из всей страницы фрагменты текста и подаем их YATI на вход. Это заметно лучше раньше, но это все еще не полное содержимое документа.
Вы имеете в виду, что можно генерировать вероятные запросы пользователей прямо по содержимому документа, а потом использовать их в поиске и ранжировании? Такое пробовали делать раньше, с помощью более простых нейросетей. Например, через поиск близких к документу запросов по семантическим векторам. Оно работает, но не приносит сверх профита и при наивной реализации очень сильно увеличивает средний объем текстовых данных, которые нужно хранить для документа. На трансформерах повторить пока не пробовали.
Для обучения используем TensorFlow + Horovod / NCCL для распределенного режима. Одна из основных причин — у нас есть классные специалисты, которые умеют готовить именно TF и выжимать из него максимум производительности. PyTorch + DeepSpeed пробовали в экспериментах, тоже выглядит рабоче.
Да, конечно отсекает. Для этого есть отдельные алгоритмы и целые под-системы для обнаружения роботов и фильтрации фрода (fraud, то есть «мошеннических» кликов, намеренно манипулирующих поисковой системой). Без учета кликов построить конкурентную поисковую систему сейчас невозможно. Разные варианты их использования в большей или меньшей степени подвержены проблемам с шумом и накрутками. Но в то же время это самый разнообразный семантический сигнал доступный поиску.
Выше в комментариях было похожее предложение, чтобы при разбросе возможных ответов на запрос поисковая система сама выделяла основные «контексты» и предлагала из них выбрать правильный. Например по запросу [трансформер] — что хотите: игрушку, кино или нейронную сеть?
Я соглашусь, что это интересная идея для фичи ) Частично такие сценарии закрываются, например, уже существующим саджестом, который предлагает частотные варианты уточнений. Но он все таки решает в бОльшей степени задачу ускорения ввода для частотных версий запроса, чем удобства на менее частотных.
Близкие запросы можно фильтровать разными способами — например, по наличию общих слов или близости семантических эмбеддингов. Можно в принципе пробовать учить модели и без фильтрации — тут уже нужно экспериментально проверять на конкретной задаче помогает фильтрация или больше мешает )
Можно по разному делать. Но общая суть в том, что отрицательный пример 1) должен быть действительно (по смыслу) отрицательным, 2) не должен быть похож на «случайный». В эвристиках это обычно сводится к тому, что положительный пример — это клик по одному запросу q1, а отрицательный пример берется с выдачи по другому запросу q2, который нужно как-то найти. Один из способов это сделать — брать q1 и q2 из одной последовательности «переформулировок».
Про апишку не знаю, поэтому не смогу прокомментировать ) Сегментация работает достаточно хорошо — за использование текстов из нее получается заметный прирост качества модели. Улучшить наверняка можно.
Такое мы умеем сейчас учитывать через алгоритм автоматической сегментации, который разбивает текстовое содержимое страницы на «зоны» разной значимости. Я его кратко упоминаю в статье. Например, мы поймем, что фрагмент текста находится в футере страницы и там скорее всего нет «смыслового» содержания. Но тут конечно есть что улучшить. Визуальная доступность явно не моделируется.
> в каких сегментах получен максимальный прирост
Это очень хороший вопрос ) Мы видим, что есть очень значимое общее улучшение качества поиска. При более детальном рассмотрении можно увидеть характерные примеры, где YATI лучше «понимает» пользователя. Например, в тех случаях когда в запросе есть неочевидная (редкая) опечатка, или есть омонимичные сущности (e.g. это название компании или обычное существительное?), в сложных запросах, где важно понимать порядок и связь слов (e.g. к какому существительному относится прилагательное), и в целом там, где в запросе есть много взаимосвязанных понятий. Но это наверняка не все.
Работает ) есть нюансы связанные с тем, что не для каждой js страницы мы принимаем решение ее отрендерить.
По второй части вопроса можете еще раз пояснить, или привести пример? Речь про то что на странице есть визуальный контент (e.g. нарисованный текст), который наша модели не сможет «прочитать»? Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?
В модели YATI сейчас используется только «естественное» содержимое страницы — то есть то, что можно получить из ее HTML описания.
Компьютерное зрение для анализа документа в ранжировании веб-страниц не используется. JS вообще говоря тут не помеха, у нас есть возможность заранее «отрендерить» страницу, так как это произошло бы в браузере, и извлечь все текстовые данные из итогового HTML описания после исполнения скриптов.
Именно для ранжирования пока использовали только сравнительно простые подходы. И здесь не увидели улучшений за использование более сложных алгоритмов. Но это важная для нас задача, я про нее упоминаю в статье. Попробовать более качественные методы, например суммаризацию или выделение основных смысловых частей страницы отдельной нейронной сетью, — обязательно хотим.
Конечно, сигнал от пользователя смещен. Вы один из источников такого смещения описали вполне точно. Но, во-первых, вопрос не только в возможности описанного сценария, но и в его частотности в обучающей выборке. Во-вторых, наш итоговый таргет (по которому ранжируется выдача) — это экспертная оценка. Клик (в рамках темы рассказа) нужен только для того, чтобы на больших и шумных данных выучить общие закономерности (сделать предобучение). Для этой цели клики — это незаменимый источник полезной информации.
Однако, если ранжировать по вероятности клика, получится очень плохо. Поэтому мы дообучаем свои модели на экспертных оценках. Тут одна из главных причин, почему трансформер так полезен — он очень хорошо выучивает именно экспертный сигнал на сравнительно небольшом количестве примеров. Это позволяет убрать смещения, которые могли появиться в модели после долгого обучения на клики в pre-train.
Аналитических и эвристических решений в поиске уже очень много. Ими мы занимались с момента появления ранжирования в Яндексе. Сейчас по таким алгоритмам уже достигли почти полного насыщения — новые признаки приносят очень мало добавленной пользы. Реальность такова, что «нейронный брутфорс» — это пока наиболее выгодное вложение усилий (в терминах размена времени разработки на рост качества).
При этом обучение моделей на самом деле требует своих подходов и эвристик — на какую задачу учить, как представить входные данные, какие примеры и в каком порядке показывать и т.д. В статье проиллюстрирован только самый простой случай. Так что это не чисто вычислительная, но и содержательно инженерная задача )
2 — верно ли я понял вашу мысль, что клик пользователя, прочитавшего сниппет, более информативен (или как минимум содержит дополнительную полезную информацию) по сравнению с обычным кликом? И, соответственно, если от модели спрятать урл и заголовок, и оставить только сниппет, то она ровно такой клик и научится предсказывать? Моделями на сниппетах мы раньше занимались, и там было сложно найти полезный сигнал, поэтому в то, что наивный подход даст что то новое не очень верю. Трансформеры на сниппетах пока подробно не смотрели. При этом сама тема «качества» клика нас конечно очень интересует.
В крайних случаях думаю может. Например, модель вполне может выучивать свойства хоста как целого и использовать это как первое приближение к ответу. Тогда ей потребуется больше «сигнала», чтобы преодолеть такое выученное смещение. Но это скорее общая теория, на практике таких примеров не встречал.
Тут нет простого практического ответа. Расчет модели действительно происходит при каждом переобходе страницы, частота которого зависит от разных факторов. Если страница популярная, и контент на ней меняется часто (e.g. новостной ресурс), мы можем ее переобходить несколько раз в час. Но вполне могут быть и дни-недели, так как физически невозможно быстро переобходить все важные для нас страницы из Интернета.
Если содержимое страницы не поменялось, то переобход для модели YATI ничего не изменит — произойдет повторное применение к тем же фрагментам текста, что и раньше.
Наверняка есть способы повысить «привлекательность» веб-страницы конкретно для текущей модели, но это мне не кажется правильной постановкой задачи. Хотя бы потому что модель вполне может сильно измениться при следующем релизе. У веб-мастера должна быть цель написать текст, который 1) хорошо читается и понимается пользователями, 2) логично поделен на секции, так чтобы у нашей модели или у сегментатора было больше очевидных «структурных признаков», которые можно использовать при анализе. А у нас должна быть цель эту информацию учиться лучше использовать.
Понимаю, что это не очень помогает решить конкретную проблему на конкретной странице. В совсем явных случаях, когда очевидно что наш поиск «не видит» содержимого, можно это присылать к нам в виде жалоб. Мы стремимся к тому, чтобы регулярно их разбирать ) Починить каждую конечно не можем, но про крупные проблемы точно хотим знать.
Подчеркну, что сегментация используется только для выделения фрагментов, которые мы покажем модели, но не для оценки их относительной значимости. Это «решает» уже модель. Например, в конкретном случае модель вполне может решить что текст размеченный как заголовок на самом деле не информативен, и тогда он не повлияет на предсказание.
Можете рассказать для каких задач Вы хотели бы использовать такую модель?
1 и 2 — Решающие деревья в GBDT работают немного по-другому. Глубина дерева фиксирована, мы ее в наших моделях CatBoost не меняем. Если есть сильный признак, то сплит по нему будет просто встречаться чаще (и возможно выше) в дереве той же глубины, и соответственно будет сильнее влиять на итоговое предсказание. Размер влияния можно увидеть например по метрике FSTR, которая численно оценивает вклад конкретного признака в предсказание. В случае с YATI — вклад новой модели заметно больше 50% от суммарного вклада всех признаков. В этом смысле трансформер решает «больше половины» задачи ранжирования.
3 — коммерческие запросы тоже бывают разные; текст документа с товаром там действительно сравнительно простой, но даже там есть нюансы — например, есть ли в тексте подробное описание, технические характеристики и т.д.; релевантным по коммерческому запросу может быть не только страница товара, но и страница с обзором, обсуждением или отзывом, где уже есть сложное текстовое содержание; наконец, сам запрос может быть сформулирован сложно, тут трансформер тоже помогает
У Палеха и Королева есть проблемы с качеством по разным причинам. Во первых потому, что сами сети сильно проще и модель текста тоже упрощенная (тот самый «мешок слов»). Поэтому с длинным связным текстом они справляются плохо. Трансформер это умеет делать лучше, но все равно показать ему весь текст страницы — сложно, хотя бы из соображений производительности. Поэтому мы выделяем из всей страницы фрагменты текста и подаем их YATI на вход. Это заметно лучше раньше, но это все еще не полное содержимое документа.
Я соглашусь, что это интересная идея для фичи ) Частично такие сценарии закрываются, например, уже существующим саджестом, который предлагает частотные варианты уточнений. Но он все таки решает в бОльшей степени задачу ускорения ввода для частотных версий запроса, чем удобства на менее частотных.
Такое мы умеем сейчас учитывать через алгоритм автоматической сегментации, который разбивает текстовое содержимое страницы на «зоны» разной значимости. Я его кратко упоминаю в статье. Например, мы поймем, что фрагмент текста находится в футере страницы и там скорее всего нет «смыслового» содержания. Но тут конечно есть что улучшить. Визуальная доступность явно не моделируется.
> в каких сегментах получен максимальный прирост
Это очень хороший вопрос ) Мы видим, что есть очень значимое общее улучшение качества поиска. При более детальном рассмотрении можно увидеть характерные примеры, где YATI лучше «понимает» пользователя. Например, в тех случаях когда в запросе есть неочевидная (редкая) опечатка, или есть омонимичные сущности (e.g. это название компании или обычное существительное?), в сложных запросах, где важно понимать порядок и связь слов (e.g. к какому существительному относится прилагательное), и в целом там, где в запросе есть много взаимосвязанных понятий. Но это наверняка не все.
Работает ) есть нюансы связанные с тем, что не для каждой js страницы мы принимаем решение ее отрендерить.
По второй части вопроса можете еще раз пояснить, или привести пример? Речь про то что на странице есть визуальный контент (e.g. нарисованный текст), который наша модели не сможет «прочитать»? Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?
Компьютерное зрение для анализа документа в ранжировании веб-страниц не используется. JS вообще говоря тут не помеха, у нас есть возможность заранее «отрендерить» страницу, так как это произошло бы в браузере, и извлечь все текстовые данные из итогового HTML описания после исполнения скриптов.
Однако, если ранжировать по вероятности клика, получится очень плохо. Поэтому мы дообучаем свои модели на экспертных оценках. Тут одна из главных причин, почему трансформер так полезен — он очень хорошо выучивает именно экспертный сигнал на сравнительно небольшом количестве примеров. Это позволяет убрать смещения, которые могли появиться в модели после долгого обучения на клики в pre-train.
При этом обучение моделей на самом деле требует своих подходов и эвристик — на какую задачу учить, как представить входные данные, какие примеры и в каком порядке показывать и т.д. В статье проиллюстрирован только самый простой случай. Так что это не чисто вычислительная, но и содержательно инженерная задача )