Трансформеры в Поиске: как Яндекс применил тяжёлые нейросети для поиска по смыслу +59


AliExpress RU&CIS

Привет, Хабр. Меня зовут Саша Готманов, я руковожу группой нейросетевых технологий в поиске Яндекса. На YaC 2020 мы впервые рассказали о внедрении трансформера — новой нейросетевой архитектуры для ранжирования веб-страниц. Это наиболее значимое событие в нашем поиске за последние 10 лет. 

Сегодня я расскажу читателям Хабра, в чём заключается иллюзия «поиска по смыслу», какой путь прошли алгоритмы и нейросети в ранжировании и какие основные сложности стоят перед теми, кто хочет применить для этой задачи трансформеры и даже заставить их работать в рантайме. 

Задача поиска

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

С точки зрения пользователя это совершенно естественная задача. Смысл запроса ему очевиден; дальше достаточно лишь прочитать документ, понять его и либо найти в нём нужное содержание (тогда документ релевантен), либо нет (не релевантен). 

Алгоритм, в отличие от человека, оперирует словами из запроса и текста документа чисто математически, как строчками из символов. Например, алгоритмически легко посчитать число совпадающих слов в запросе и документе или длину самой длинной подстроки из запроса, которая присутствует и в документе. Можно также воспользоваться накопленной историей поиска и достать из заранее подготовленной таблицы сведения о том, что запрос уже задавался в поиск много раз, а документ получил по нему много кликов (или наоборот, получил их очень мало, или вообще ещё ни разу не был показан). Каждый такой расчёт приносит полезную информацию о наличии семантической связи, но сам по себе не опирается на какое-либо смысловое понимание текста. Например, если документ отвечает на запрос, то правдоподобно, что у запроса и документа должны быть общие слова и подстроки. Алгоритм может использовать этот статистический факт, чтобы лучше оценить вероятность смысловой связи, а на основе большого числа таких расчётов уже можно построить достаточно хорошую модель. При её использовании на практике у человека будет возникать ощущение, что алгоритм «понимает» смысл текста.

По такому принципу и работал поиск Яндекса до 2016 года. За годы разработки для повышения качества было придумано множество остроумных эвристических алгоритмов. Одних только способов посчитать общие слова запроса и документа было предложено и внедрено несколько десятков. Вот так, к примеру, выглядит один из сравнительно простых:

Здесь каждому «хиту» t (то есть вхождению слова из запроса в документ, от англ. hit, попадание) присваивается вес с учётом частотности слова в корпусе (IDF, Inverse Document Frequency) и расстояний до ближайших вхождений других слов запроса в документ слева и справа по тексту (LeftDist и RightDist). Затем полученные значения суммируются по всем найденным хитам. Каждая такая эвристика при внедрении позволяла получить небольшой, но статистически значимый прирост качества модели, то есть чуть лучше приблизить ту самую смысловую связь. Суммарный эффект от простых факторов постепенно накапливался, и внедрения за длительный период (полгода-год) уже заметно влияли на ранжирование.

Немного другой, но тоже хорошо работающий способ принести качество с помощью простого алгоритма — придумать, какие еще тексты можно использовать в качестве «запроса» и «документа» для уже существующих эвристик. Слова запроса можно расширить близкими им по смыслу (синонимичными) словами или фразами. Либо вместо исходного запроса пользователя взять другой, который сформулирован иначе, но выражает схожую информационную потребность. Например, для запроса [отдых на северном ледовитом океане] похожими могут быть:

[можно ли купаться в баренцевом море летом]
[путешествие по северному ледовитому океану]
[города и поселки на побережье северного ледовитого океана]

(Это реальные примеры расширений запроса, взятые из поиска Яндекса.)

Как найти похожие слова и запросы — тема отдельного рассказа. Для этого в нашем поиске тоже есть разные алгоритмы, а решению задачи очень помогают логи запросов, которые нам задают пользователи. Сейчас важно отметить, что если похожий запрос найден, то его можно использовать во всех эвристических расчётах сразу; достаточно взять уже готовый алгоритм и заменить в нём один текст запроса на другой. Таким методом можно получить сразу много полезной информации для ранжирования. Что может быть чуть менее очевидно — аналогично запросу можно «расширять» и документ, собирая для него «альтернативные» тексты, которые в Яндексе называют словом стримы (от англ. stream). Например, стрим для документа может состоять из всех текстов входящих ссылок или из всех текстов запросов в поиск, по которым пользователи часто выбирают этот документ на выдаче. Точно так же стрим можно использовать в любом готовом эвристическом алгоритме, заменив на него исходный текст документа.

Говоря более современным языком, расширения и стримы — это примеры дополнительных контентных признаков, которые поиск Яндекса умеет ассоциировать с запросом и документом. Они ничем не отличаются от обычных числовых или категориальных признаков, кроме того, что их содержимое — это неструктурированный текст. Интересно, что эвристики, для которых эти признаки изначально разрабатывались, уже утратили большую часть своей актуальности и полезности, но сами расширения и стримы продолжают приносить пользу, только теперь уже в качестве входов новых нейронных сетей.

В результате многих лет работы над качеством поиска у нас накопились тысячи самых разных факторов. При решении задачи ранжирования все они подаются на вход одной итоговой модели. Для её обучения мы используем нашу открытую реализацию алгоритма GBDT (Gradient Boosting Decision Trees) — CatBoost.

Нейросети в ранжировании

Современные поисковые системы развиваются и улучшают своё качество за счёт всё более точных приближений семантической связи запроса и документа, так что иллюзия понимания становится полнее, охватывает новые классы запросов и пользовательских задач. Основным инструментом для этого в последние годы стали нейронные сети всё более возрастающей сложности. Впрочем, начало (как нам теперь кажется) было довольно простым.

Первые нейронные сети в поиске обладали простой feed-forward-архитектурой. На вход сети подаётся исходный текст в виде «мешка слов» (bag of words). Каждое слово превращается в вектор, вектора затем суммируются в один, который и используется как представление всего текста. Взаимный порядок слов при этом теряется или учитывается лишь частично с помощью специальных технических трюков. Кроме того, размер «словаря» у такой сети ограничен; неизвестное слово в лучшем случае удаётся разбить на частотные сочетания букв (например, на триграммы) в надежде сохранить хотя бы часть его смысла. Вектор мешка слов затем пропускается через несколько плотных слоёв нейронов, на выходе которых образуется семантический вектор (иначе эмбеддинг, от англ. embedding, вложение; имеется в виду, что исходный объект-текст вкладывается в n-мерное пространство семантических векторов).

Замечательная особенность такого вектора в том, что он позволяет приближать сложные «смысловые» свойства текста с помощью сравнительно простых математических операций. Например, чтобы оценить смысловую связь запроса и документа, можно каждый из них сначала превратить в отдельный вектор-эмбеддинг, а затем вектора скалярно перемножить друг на друга (или посчитать косинусное расстояние).

В этом свойстве семантических векторов нет ничего удивительного, ведь нейронная сеть обучается решать именно такую задачу, то есть приближать смысловую связь между запросом и документом на миллиардах обучающих примеров. В качестве таргета (то есть целевого, истинного значения релевантности) при этом используются предпочтения наших пользователей, которые можно определить по логам поиска. Точнее, можно предположить, что определённый шаблон поведения пользователя хорошо коррелирует с наличием (или, что не менее важно, с отсутствием) смысловой связи между запросом и показанным по нему документом, и собрать на его основе вариант таргета для обучения. Задача сложнее, чем может показаться на первый взгляд, и допускает различные решения. Если в качестве положительного примера обычно подходит документ с «кликом» по запросу, то найти хороший отрицательный пример гораздо труднее. Например, оказывается, что почти бесполезно брать в качестве отрицательных документы, для которых был показ, но не было «клика» по запросу. Здесь снова открывается простор для эвристических алгоритмов, а их правильное использование позволяет на порядок улучшить качество получающейся нейронной сети в задаче ранжирования. Алгоритм, который лучше всего показал себя на практике, называется в Яндексе «алгоритмом переформулировок» и существенно опирается на то, что пользователям свойственно при решении поисковой задачи задавать несколько запросов подряд, постепенно уточняя формулировку, то есть «переформулировать» исходный запрос до тех пор, пока не будет найден нужный документ.

Пример архитектуры сети в подходе с семантическими эмбеддингами. Более подробное описание этого подхода — тут.

Важное ограничивающее свойство такой сети: весь входной текст с самого начала представляется одним вектором ограниченного размера, который должен полностью описывать его «смысл». Однако реальный текст (в основном это касается документа) обладает сложной структурой — его размер может сильно меняться, а смысловое содержание может быть очень разнородным; каждое слово и предложение обладают своим особым контекстом и добавляют свою часть содержания, при этом разные части текста документа могут быть в разной степени связаны с запросом пользователя. Поэтому простая нейронная сеть может дать лишь очень грубое приближение реальной семантики, которое в основном работает для коротких текстов. 

Тем не менее, использование плотных feed-forward-сетей в своё время позволило существенно улучшить качество поиска Яндекса, что легло в основу двух крупных релизов: «Палех» и «Королёв». В значительной степени этого удалось добиться за счёт длительных экспериментов с обучающими выборками и подбором правильных контентных признаков на входе моделей. То есть ключевыми вопросами для нас были: «На какой (кликовый) таргет учить?» и «Какие данные и в каком виде подавать на вход?» 

Интересно, что хотя нейронная сеть обучается предсказывать связь между запросом и документом, её затем можно легко адаптировать и для решения других смысловых задач. Например, уже готовую сеть можно на сравнительно небольшом числе примеров дообучить для различных вариантов запросной или документной классификации, таких как выделение потока порнозапросов, товарных и коммерческих, навигационных (то есть требующих конкретного сайта в ответе) и так далее. Что ещё более важно для ранжирования, такую же сеть можно дообучить на экспертных оценках. Экспертные оценки в ранжировании — это прямые оценки смысловой связи запроса и документа, которые ставятся людьми на основе понимания текста. В сложных случаях правильная оценка требует специальных знаний в узкой области, например в медицине, юриспруденции, программировании, строительстве. Это самый качественный и самый дорогой из доступных нам таргетов, поэтому важно уметь его выучивать максимально эффективно.

Нейронная сеть, сначала обученная на миллиардах «переформулировок», а затем дообученная на сильно меньшем количестве экспертных оценок, заметно улучшает качество ранжирования. Это характерный пример применения подхода transfer learning: модель сначала обучается решать более простую или более общую задачу на большой выборке (этот этап также называют предварительным обучением или предобучением, англ. pre-tain), а затем быстро адаптируется под конкретную задачу уже на сильно меньшем числе примеров (этот этап называют дообучением или настройкой, англ. fine-tune). В случае простых feed-forward-сетей transfer learning уже приносит пользу, но наибольшего эффекта этот метод достигает с появлением архитектур следующего поколения.

Нейросети-трансформеры

Долгое время самой активно развивающейся областью применения для сложных алгоритмов анализа текста была задача машинного перевода. Результат работы переводчика — это полностью сгенерированный текст, и даже небольшие смысловые ошибки сразу заметны пользователю. Поэтому для решения задач перевода всегда использовались самые сложные модели, которые могли учесть порядок слов в тексте и их взаимное влияние друг на друга. Сначала это были рекуррентные нейронные сети (Recurrent Neural Networks, RNN), а затем трансформеры. Далее речь пойдёт только о трансформерах, которые по сути являются более технологически совершенным развитием идеи рекуррентных сетей. 

В сетях с архитектурой трансформеров каждый элемент текста обрабатывается по отдельности и представляется отдельным вектором, сохраняя при этом своё положение. Элементом может быть отдельное слово, знак пунктуации или частотная последовательность символов, например BPE-токен. Сеть также включает механизм «внимания» (англ. attention), который позволяет ей при вычислениях «концентрироваться» на разных фрагментах входного текста.

Применительно к задаче ранжирования, по запросу [купить кофеварку] такая нейронная сеть может выделить часть документа (e.g. страницы интернет-магазина), в которой речь идёт именно о нужном пользователю товаре. Остальные части тоже могут быть учтены, но их влияние на результат будет меньше. Трансформеры могут хорошо выучивать сложные зависимости между словами и активно используются для генерации естественных текстов в таких задачах, как перевод и ответы на вопросы (англ. question answering). Поэтому в Яндексе они применяются уже достаточно давно. В первую очередь, конечно, в Яндекс.Переводчике. 

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

Transformers + transfer learning

Глубокие нейронные сети достаточно требовательны к объёму примеров для обучения. Если данных мало, то никакого выигрыша от применения тяжёлой архитектуры не получится. При этом практических задач всегда много, и они несколько отличаются друг от друга. Собрать миллиарды примеров для каждый задачи просто невозможно: не хватит ни времени, ни бюджета. На помощь снова приходит подход transfer learning. Как мы уже разобрались на примере feed-forward-сетей, суть в том, чтобы переиспользовать информацию, накопленную в рамках одной задачи, для других задач. В Яндексе этот подход применяется повсеместно, особенно он хорош в компьютерном зрении, где обученная на поиске изображений базовая модель легко дообучается почти на любые задачи. В трансформерах transfer learning тоже ожидаемо заработал.

В 2018-м команда OpenAI показала, что если обучить трансформер на сыром корпусе текстов большого размера в режиме языковой модели, а затем дообучать модель на малых данных для конкретных задач, то результат оказывается существенно лучше, чем раньше. Так родился проект GPT (Generative Pre-trained Transformer). Похожая идея чуть позже легла в основу проекта BERT (Bidirectional Encoder Representations from Transformers) от Google.

Такой же метод мы решили применить и в качестве поиска Яндекса. Но для этого нам потребовалось преодолеть несколько технологических трудностей.

Трансформеры в поиске Яндекса

Проект BERT замечателен тем, что каждый может взять в открытом доступе уже готовую предобученную модель и применить её к своей задаче. Во многих случаях это даёт отличный результат. Но, к сожалению, поиск Яндекса — не такой случай. Простое дообучение готовой модели приносит лишь небольшое улучшение качества, совершенно непропорциональное затратам ресурсов, которые необходимы для применения такой модели в рантайме. Чтобы раскрыть реальные возможности трансформера для поиска, нужно было обучать свою модель с нуля.

Для иллюстрации приведу несколько результатов из наших экспериментов. Давайте возьмём открытую модель BERT-Base Multilingual и обучим на наши экспертные оценки. Можно измерить полезность такого трансформера как дополнительного фактора в задаче ранжирования; получим статистически значимое уменьшение ошибки предсказания релевантности на 3-4%. Это хороший фактор для ранжирования, который мы бы немедленно внедрили, если бы он не требовал применения 12-слойного трансформера в рантайме. Теперь возьмём вариант модели BERT-Base, который мы обучили с нуля, и получим уменьшение ошибки предсказания почти на 10%, то есть более чем двукратный рост качества по сравнению с ванильной версией, и это далеко не предел. Это не значит, что модель Multilingual от Google — низкого качества. С помощью открытых моделей BERT уже было получено много интересных результатов в разных задачах NLP (Natural Language Processing, то есть в задачах обработки текстов на естественном языке). Но это значит, что она плохо подходит для ранжирования веб-страниц на русском языке.

Первая трудность, которая возникает на пути к обучению своего трансформера, — это вычислительная сложность задачи. Новые модели хорошо масштабируются по качеству, но при этом в миллионы раз сложнее, чем те, которые применялись в поиске Яндекса раньше. Если раньше нейронную сеть удавалось обучить за один час, то трансформер на таком же графическом ускорителе Tesla v100 будет учиться 10 лет. То есть без одновременного использования хотя бы 100 ускорителей (с возможностью быстрой передачи данных между ними) задача не решается в принципе. Необходим запуск специализированного вычислительного кластера и распределённое обучение на нём.

Нам потребовалось немного времени, пара сотен GPU-карт, место в одном из дата-центров Яндекса и классные инженеры. К счастью, всё это у нас было. Мы собрали несколько версий кластера и успешно запустили на нём обучение. Теперь модель одновременно обучается примерно на 100 ускорителях, которые физически расположены в разных серверах и общаются друг с другом через сеть. И даже с такими ресурсами на обучение уходит около месяца. 

Несколько слов про само обучение. Нам важно, чтобы получившаяся модель решала с оптимальным качеством именно задачу ранжирования. Для этого мы разработали свой стек обучения. Как и BERT, модель сначала учится свойствам языка, решая задачу MLM (Masked Language Model), но делает это сразу на текстах, характерных для задачи ранжирования. Уже на этом этапе вход модели состоит из запроса и документа, и мы с самого начала обучаем модель предсказывать ещё и вероятность клика на документ по запросу. Удивительно, но тот же самый таргет «переформулировок», который был разработан ещё для feed-forward-сетей, отлично показывает себя и здесь. Обучение на клик существенно увеличивает качество при последующем решении семантических задач ранжирования.

В дообучении мы используем не одну задачу, а последовательность задач возрастающей сложности. Сначала модель учится на более простых и дешёвых толокерских оценках релевантности, которыми мы располагаем в большом количестве. Затем на более сложных и дорогих оценках асессоров. И наконец, обучается на итоговую метрику, которая объединяет в себе сразу несколько аспектов и по которой мы оцениваем качество ранжирования. Такой метод последовательного дообучения позволяет добиться наилучшего результата. По сути весь процесс обучения выстраивается от больших выборок к малым и от простых задач к более сложным и «семантическим».

На вход модели мы подаём всё те же контентные признаки, о которых шла речь в самом начале. Здесь есть текст запроса, его расширения и фрагменты содержимого документа. Документ целиком всё ещё слишком большой, чтобы модель могла справиться с ним полностью сама, без предварительной обработки. Стримы тоже содержат полезную информацию, но с ними нам ещё надо поработать, чтобы понять, как её эффективно донести до поиска. Сложнее всего оказалось выделить хорошие фрагменты текста документа. Это вполне ожидаемо: чтобы выделить наиболее важную часть веб-страницы, уже нужно многое понимать про её смысловое содержание. Сейчас нам на помощь опять приходят простые эвристики и алгоритмы автоматической сегментации, то есть разметки страницы на структурные зоны (основное содержание, заголовки и так далее). Стоимость ошибки достаточно велика, иногда для правильного решения задачи необходимо, чтобы модель «увидела» одно конкретное предложение в длинном тексте статьи, и здесь ещё остается потенциал для улучшений.

Итак, мы научились обучать модели в офлайне, но вот работать им уже нужно в онлайне, то есть в реальном времени в ответ на тысячи пользовательских запросов в секунду. Тут заключается вторая принципиальная трудность. Применение трансформера — это тяжелая для рантайма задача; модели такой сложности можно применять только на GPU-картах, иначе время их работы окажется чрезмерным и легко может превысить время работы всего поиска. Потребовалось разработать с нуля и развернуть несколько сервисов для быстрого применения («инференса», англ. inference) трансформеров на GPU. Это новый тип инфраструктуры, который до этого не использовался в поиске.

Непосредственно для применения мы доработали внутреннюю библиотеку для инференса трансформеров, которая разработана нашими коллегами из Яндекс.Переводчика и, по нашим замерам, как минимум не уступает другим доступным аналогам. Ну и конечно, всё считается в FP16 (16-битное представление чисел с плавающей точкой).

Однако, даже с учетом использования GPU и оптимизированного кода для инференса, модель с максимальным уровнем качества слишком большая для внедрения в рантайм поиска. Для решения этой проблемы есть классический приём — knowledge distillation (или dark knowledge). В Яндексе мы используем менее пафосный термин «пародирование». Это обучение более простой модели, которая «пародирует» поведение более сложной, обучаясь на её предсказания в офлайне.

В результате пародирования сложность модели удаётся уменьшить в разы, а потери качества остаются в пределах ~10%.

Это не единственный способ оптимизации. Мы также научились делать многозадачные модели, когда одна модель «подражает» сразу нескольким сложным моделям, обученным на разные задачи. При этом суммарная полезность модели для ранжирования существенно возрастает, а её сложность почти не увеличивается.

Если же хочется добиться максимального качества, то возможностей одной дистилляции недостаточно. Приходится поделить модель на несколько частей, каждая из которых применяется независимо. Часть модели применяется только к запросу; часть — только к документу; а то, что получилось, затем обрабатывается финальной связывающей моделью. Такой метод построения «раздельной» или split-модели распределяет вычислительную нагрузку между разными компонентами системы, что позволяет сделать модель более сложной, увеличить размер её входа и заметно повысить качество.

Внедрение split-модели опять приводит нас к новым и интересным инженерным задачам, но рассказать обо всём в одном посте, увы, невозможно. Хотя архитектура нейросетей-трансформеров известна уже достаточно давно, а их использование для задач NLP приобрело огромную популярность после появления BERT в 2018 году, внедрение трансформера в современную поисковую систему невозможно без инженерной изобретательности и большого числа оригинальных технологических улучшений в обучении и рантайме. Поэтому мы назвали нашу технологию YATIYet Another Transformer (with Improvements), что, как нам кажется, хорошо отражает её суть. Это действительно «ещё один трансформер», архитектурно похожий на другие модели (а их в последние годы появилось великое множество), но уникальный тем, что благодаря совокупности улучшений он способен работать и приносить пользу в поиске — самом сложном сервисе Яндекса.

Итоги

Что в итоге? У нас появилась своя инфраструктура обучения и дистилляции тяжёлых моделей, адаптированная под наш стек задач ранжирования. С её помощью мы сначала обучили большие модели-трансформеры высокого качества, а затем дистиллировали их в многозадачную split-модель, которая внедрена в рантайм на GPU в виде нескольких частей, независимо применяемых к запросу и документу.

Это внедрение принесло нам рекордные улучшения в ранжировании за последние 10 лет (со времён внедрения Матрикснета). Просто для сравнения: Палех и Королёв вместе повлияли на поиск меньше, чем новая модель на трансформерах. Более того, в поиске рассчитываются тысячи факторов, но если выключить их все и оставить только новую модель, то качество ранжирования по основной офлайн-метрике упадёт лишь на 4-5%! 

В таблице ниже сравнивается качество нескольких нейросетевых алгоритмов в задаче ранжирования. “% NDCG” — это нормированное значение обычной метрики качества DCG по отношению к идеальному ранжированию на нашем датасете. 100% означает, что модель располагает документы в порядке убывания их истинных офлайн-оценок. Худший результат ожидаемо даёт подход предыдущего поколения, то есть просто обучение feed-forward-сети на кликовый таргет. Дообучение готовых моделей BERT существенно проигрывает по качеству специализированной версии, которая показывает рекордный результат в 95,4% — сравнимо с качеством дистилляции YATI в feed-forward-сеть. Все модели, кроме первой, дообучались на одном и том же множестве экспертных оценок.

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

В начале поста я рассказал про ощущение поиска по смыслу. Применение тяжёлых (как мы сейчас о них думаем) нейросетевых моделей, которые точнее приближают структуру естественного языка и лучше учитывают семантические связи между словами в тексте, поможет нашим пользователям встречаться с этим эффектом ещё чаще, чем раньше. И может быть, однажды нам уже будет непросто отличить иллюзию от реальности. Но до этого, я уверен, в качестве поиска ещё предстоит сделать много нового и интересного. 

Спасибо за внимание.




Комментарии (61):

  1. MUTbKA98
    /#22349056 / +3

    Клик на основе заголовка — не показатель ценности ссылки (для пользователя). Он может быть обманут заголовком, что происходит примерно в 100% случаев. Хотя, для Яндекса, наверное, это реальная цель — если ссылка рекламная.

    • gotmanov
      /#22349178 / +3

      Все верно, заголовка мало чтобы сделать хорошее предсказание релевантности. Но это тем не менее ценный, хотя и шумный источник информации — например он позволяет отбросить очень большое число результатов, явно не относящихся к теме. Для ранжирования цель как раз в том, чтобы показать пользователю релевантный результат, который он захочет не просто «кликнуть» и закрыть, а прочитать. Конечно понять реальное содержание только по заголовку невозможно, но на практике это вещи достаточно сильно скоррелированные. Наши новые нейросети, в том числе YATI, смотрят уже далеко не только на заголовок.

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

      • MUTbKA98
        /#22349238

        Ну вот самый типичный сценарий:
        1. Запрос к поиску.
        2. Сразу, не глядя даже на результат — клик на вторую страницу выдачи.
        3. Практически без участия сознания, просто на рефлексах Ctrl-Click на несколько ссылок подряд.
        4. Последовательный просмотр открывшихся табов, 80% из которых захлопываются через 3-5 сек после начала просмотра.
        5. Остаются 1-2, которые читаются внимательно и до упора.

        По-моему, Ваш алгоритм будет получать категорически неверное подкрепление со стороны пользователя.

        • gotmanov
          /#22349260 / +1

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

          Однако, если ранжировать по вероятности клика, получится очень плохо. Поэтому мы дообучаем свои модели на экспертных оценках. Тут одна из главных причин, почему трансформер так полезен — он очень хорошо выучивает именно экспертный сигнал на сравнительно небольшом количестве примеров. Это позволяет убрать смещения, которые могли появиться в модели после долгого обучения на клики в pre-train.

  2. maxim_ge
    /#22349070

    Вектор мешка слов затем пропускается через несколько плотных слоёв нейронов, на выходе которых образуется семантический вектор (иначе эмбеддинг, от англ. embedding, вложение; имеется в виду, что исходный объект-текст вкладывается в n-мерное пространство семантических векторов).

    Очень круто. Но все-таки есть некое ощущение, что помимо такого нейронного "брутфорса" есть и аналитическое решение, более эффективное.

    • gotmanov
      /#22349226 / +1

      Аналитических и эвристических решений в поиске уже очень много. Ими мы занимались с момента появления ранжирования в Яндексе. Сейчас по таким алгоритмам уже достигли почти полного насыщения — новые признаки приносят очень мало добавленной пользы. Реальность такова, что «нейронный брутфорс» — это пока наиболее выгодное вложение усилий (в терминах размена времени разработки на рост качества).

      При этом обучение моделей на самом деле требует своих подходов и эвристик — на какую задачу учить, как представить входные данные, какие примеры и в каком порядке показывать и т.д. В статье проиллюстрирован только самый простой случай. Так что это не чисто вычислительная, но и содержательно инженерная задача )

  3. cepera_ang
    /#22349364 / -1

    Да зачем вообще нужно какое-то ранжирование, да ещё такими сложными методами, когда можно показать на всех местах ссылки на свои сервисы + википедию? :)


    Результы поиска, всё что влезло на 24'' монитор

    image

    • fireSparrow
      /#22349554

      Вы приводите достаточно частный случай.
      Если система по запросу распознала, что речь идёт про фильм, то логично, что она предлагает больше информации, связанной с этим фильмом. А в русскоязычном сегменте интернета Кинопоиск — самый информативный ресурс о кино.
      Если ввести в поиск например «капибара» или «дезоксирибонуклеиновая кислота», то картина будет совсем другая.

      на всех местах ссылки на свои сервисы + википедию?
      А википедия-то вам чем не угодила?

      • cepera_ang
        /#22349642

        А википедия-то вам чем не угодила?

        Всем угодила, прост у меня яндекс почти всегда выглядит как "вики + реклама" и появляется вопрос — а зачем этот лишний шаг? :)


        Тоже так себе, надо сказать

        image

      • inkelyad
        /#22349732

        А когда поисковики научиться понимать, что тут имеется масса синонимов, сообщать об этом, и давать интерфейс 'трансформер в смысле персонажа франшизы — из выдачи поиска исключить'?

  4. TiesP
    /#22349494

    А напрямую выделять смысл из текста вы не пробовали? (что-то вроде "суммаризации")… чтобы потом использовать это для поиска.

    • gotmanov
      /#22349540 / +1

      Именно для ранжирования пока использовали только сравнительно простые подходы. И здесь не увидели улучшений за использование более сложных алгоритмов. Но это важная для нас задача, я про нее упоминаю в статье. Попробовать более качественные методы, например суммаризацию или выделение основных смысловых частей страницы отдельной нейронной сетью, — обязательно хотим.

  5. glupiyyashik
    /#22349828

    «Стримы тоже содержат полезную информацию, но с ними нам ещё надо поработать, чтобы понять, как её эффективно донести до поиска.»

    На данный момент стримы не используются в этой модели?
    Сложнее всего оказалось выделить хорошие фрагменты текста документа.

    Используется ли для выделения фрагментов компьютерное зрение? Ведь текст может быть скрыт, либо добавлен при помощи JS.

    • gotmanov
      /#22349860 / +1

      В модели YATI сейчас используется только «естественное» содержимое страницы — то есть то, что можно получить из ее HTML описания.

      Компьютерное зрение для анализа документа в ранжировании веб-страниц не используется. JS вообще говоря тут не помеха, у нас есть возможность заранее «отрендерить» страницу, так как это произошло бы в браузере, и извлечь все текстовые данные из итогового HTML описания после исполнения скриптов.

      • glupiyyashik
        /#22349916

        Вопрос не в самом js (хотя, насколько помню, Яндекс не работает с ним), а в том, что контент реально видимый пользователем, и то, что получает ваш бот, может отличаться в плане смысловой значимости фрагментов. Это как-то учитывается?

        • gotmanov
          /#22349960

          > Яндекс не работает с ним

          Работает ) есть нюансы связанные с тем, что не для каждой js страницы мы принимаем решение ее отрендерить.

          По второй части вопроса можете еще раз пояснить, или привести пример? Речь про то что на странице есть визуальный контент (e.g. нарисованный текст), который наша модели не сможет «прочитать»? Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?

          • glupiyyashik
            /#22350052 / +1

            Или про то, что смысл обычного текста может быть сильно обусловлен его визуальным расположением на странице?

            Да, про это. Но, не смысл, а скорее значимость. В тексте же речь шла именно о присвоении значимости для разных фрагментов. Можно ли считать значимым текстовый фрагмент, который визуально недоступен для пользователей?

            И еще — в каких сегментах получен максимальный прирост в качестве ранжирующей модели? Ну, т.е. вроде как понятно, что для информационных запросов (пример с отдыхом) он должен быть выше, чем для «купить кофеварку», но мало ли…

            • gotmanov
              /#22350110

              > не смысл, а скорее значимость

              Такое мы умеем сейчас учитывать через алгоритм автоматической сегментации, который разбивает текстовое содержимое страницы на «зоны» разной значимости. Я его кратко упоминаю в статье. Например, мы поймем, что фрагмент текста находится в футере страницы и там скорее всего нет «смыслового» содержания. Но тут конечно есть что улучшить. Визуальная доступность явно не моделируется.

              > в каких сегментах получен максимальный прирост

              Это очень хороший вопрос ) Мы видим, что есть очень значимое общее улучшение качества поиска. При более детальном рассмотрении можно увидеть характерные примеры, где YATI лучше «понимает» пользователя. Например, в тех случаях когда в запросе есть неочевидная (редкая) опечатка, или есть омонимичные сущности (e.g. это название компании или обычное существительное?), в сложных запросах, где важно понимать порядок и связь слов (e.g. к какому существительному относится прилагательное), и в целом там, где в запросе есть много взаимосвязанных понятий. Но это наверняка не все.

              • glupiyyashik
                /#22350268

                Помню, в яндексе была апишка по извлечению основного текста документа, и работала она криво, а потом вовсе закрылась:) Вряд ли алгоритмами сегментации сотрудникам заниматься также интересно, допускаю, что работают они весьма кривовато)

                • gotmanov
                  /#22350324

                  Про апишку не знаю, поэтому не смогу прокомментировать ) Сегментация работает достаточно хорошо — за использование текстов из нее получается заметный прирост качества модели. Улучшить наверняка можно.

                  • artificialme
                    /#22354986

                    Вы говорите про сегментацию и её возросшую значимость, хотелось бы узнать какими рамками определяется сегмент, имеет ли место вложенная (древовидная) сегментация?


                    Насколько важны теги заголовков для каждого отдельного сегмента, имеет ли значение семантическая верстка html5 (e.g. section,article,header,footer) или любая DOM-структура помогает сегментировать текстовый контент?


                    Другими словами, как вебмастер может расставить акценты, чтобы помочь машине правильно сегментировать текстовый контент?

                    • gotmanov
                      /#22357534

                      Спасибо за вопрос ) Текущий алгоритм в первую очередь выделяет области с основным текстовым содержанием (содержание статьи на хабре, описание товара в магазине, etc) и дополнительно смотрит на общую структуру, включая заголовки разделов. При этом может использоваться как вся доступная нам разметка и структура на веб-странице, так и структура самого текста (т.е. не размеченная явно, но понятная из синтаксиса и содержания). Поэтому у страницы должно быть хорошее текстовое содержание, которое (при большом объеме текста) логично поделено на разделы с информативными заголовками. Явная разметка упростит задачу для наших алгоритмов. Если текста немного (условно 10 предложений или меньше), то мы скорее всего просто «прочитаем» его целиком и никакого дополнительного деления не требуется.

                      Подчеркну, что сегментация используется только для выделения фрагментов, которые мы покажем модели, но не для оценки их относительной значимости. Это «решает» уже модель. Например, в конкретном случае модель вполне может решить что текст размеченный как заголовок на самом деле не информативен, и тогда он не повлияет на предсказание.

                      • artificialme
                        /#22357924

                        Спасибо за ответ, а что если я наблюдаю ситуацию, когда субъективно (i.e. на мой взгляд) важные текстовые элементы (например, содержащие интент) сложно структурированной страницы игнорируются органическим поиском, т.е. я не могу найти в выдаче свой сайт по уникальным кускам текста по точному вхождению, используя различные операторы.


                        Теория следующая: текст не был представлен модели или модель сочла его неважным.


                        Вопрос: какой сигнал ускорит показ модели текста с отдельно взятой страницы для оценки повторно? Например, достаточно ли для этого отправить страницу на переобход? Или важно существенное изменения текста, а если изменилась структура страницы без изменения текста? Как часто (в каких приблизительных временных диапазонах) это происходит в естественном ритме, происходит ли отправка текстовых сегментов модели при каждом новом сканировании проиндексированной страницы?


                        Подчеркну, спасибо за ответ и за Вашу статью)

                        • gotmanov
                          /#22359208

                          > какой сигнал ускорит показ модели текста с отдельно взятой страницы для оценки повторно?

                          Тут нет простого практического ответа. Расчет модели действительно происходит при каждом переобходе страницы, частота которого зависит от разных факторов. Если страница популярная, и контент на ней меняется часто (e.g. новостной ресурс), мы можем ее переобходить несколько раз в час. Но вполне могут быть и дни-недели, так как физически невозможно быстро переобходить все важные для нас страницы из Интернета.

                          Если содержимое страницы не поменялось, то переобход для модели YATI ничего не изменит — произойдет повторное применение к тем же фрагментам текста, что и раньше.

                          Наверняка есть способы повысить «привлекательность» веб-страницы конкретно для текущей модели, но это мне не кажется правильной постановкой задачи. Хотя бы потому что модель вполне может сильно измениться при следующем релизе. У веб-мастера должна быть цель написать текст, который 1) хорошо читается и понимается пользователями, 2) логично поделен на секции, так чтобы у нашей модели или у сегментатора было больше очевидных «структурных признаков», которые можно использовать при анализе. А у нас должна быть цель эту информацию учиться лучше использовать.

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

                          • artificialme
                            /#22359512

                            Вы подтвердили мои личные наблюдения и теории) Манипулировать алгоритмом цели не стоит, но определенный паттерн у вебмастеров (и seo-специалистов) в конкурентной среде модель неизбежно создаст. Надеюсь, что развитие Вашей модели идет в сторону динамики, а не инерции) Спасибо за ответ. В поддержку Яндекса пишем-с, но чаще всего получаем стандартный ответ, попробую другие формулировки)


                            Может быть я уже наглею, но может ли большое количество "неинтересных" для поиска страниц на сайте "замылить" действительно важные страницы и тексты на них?

                            • gotmanov
                              /#22359820

                              > может ли большое количество «неинтересных» для поиска страниц на сайте «замылить» действительно важные страницы и тексты на них

                              В крайних случаях думаю может. Например, модель вполне может выучивать свойства хоста как целого и использовать это как первое приближение к ответу. Тогда ей потребуется больше «сигнала», чтобы преодолеть такое выученное смещение. Но это скорее общая теория, на практике таких примеров не встречал.

                              • artificialme
                                /#22360078

                                Есть ли способ "резетнуть" обучение модели относительно отдельно-взятого хоста. Например, заблокировав индексирование сайта для роботов Яндекса? Если да, то как долго модель может "помнить" о свойствах хоста?

  6. kryvichh
    /#22350598

    Немного не по теме, но я не понимаю, как Яндекс-поиск считает хиты. Возьмём произвольное непонятное слово, и вычислим, насколько оно часто используется. Например, «Абдо». При поиске Абдо Яндекс даёт 2 млн. хитов (слово исключительно популярное?). Но если взять «Абдо» в кавычки, то уже 5 тыс. хитов (Что??? Куда исчезли все 2 млн. упоминаний?).

    С Гуглом тоже интересно. Он для Абдо даёт 396 тыс. хитов, и для «Абдо» — 437 тыс. (больше чем в 1-м запросе, уже странно). Но если начать листать, то страниц с результатами окажется всего 16, а самих результатов по факту — всего 152.

  7. glupiyyashik
    /#22350646

    Например, оказывается, что почти бесполезно брать в качестве отрицательных документы, для которых был показ, но не было «клика» по запросу

    Правильно ли я понял, что в качестве отрицательных примеров берутся пары запрос-выдача (документы), по которым были переформулировки запроса без клика на документы?

    • gotmanov
      /#22350900

      Можно по разному делать. Но общая суть в том, что отрицательный пример 1) должен быть действительно (по смыслу) отрицательным, 2) не должен быть похож на «случайный». В эвристиках это обычно сводится к тому, что положительный пример — это клик по одному запросу q1, а отрицательный пример берется с выдачи по другому запросу q2, который нужно как-то найти. Один из способов это сделать — брать q1 и q2 из одной последовательности «переформулировок».

      • glupiyyashik
        /#22350958

        А как вы отделяете «правильные» переформулировки от случайных? К примеру, сначала я вбил «погода в городе» (или «расписание электричек») — увидел всё на выдаче, а потом «время работы музея в городе» и уже кликнул куда-то. Попадет ли подобный пример в обучающую выборку?

        • gotmanov
          /#22351234

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

  8. DmitryLTL
    /#22351004

    Мне всегда хотелось иметь опцию задания контекста поиска.


    Т.е. я могу предопределить несколько контекстов и потом при поиске выбирать какой-то, чтобы упростить работу алгоритму.


    Например один может быть что-то типа:


    Ms sql server, stored procedures


    Другой


    Javascript, -jquery


    И поисковик понимает и сужает область поиска.


    Сейчас я могу добавить это в поисковую строку чтобы уточнить критерий и у меня есть плагин для браузера чтобы не вбивать всё это вручную, но если будет это в формате понимаемом поисковиком, что это не просто ещё один критерий, а контест, то может результаты поиска будут лучше, особенно в узкоспециализированных направлениях.

    • gotmanov
      /#22351294

      Выше в комментариях было похожее предложение, чтобы при разбросе возможных ответов на запрос поисковая система сама выделяла основные «контексты» и предлагала из них выбрать правильный. Например по запросу [трансформер] — что хотите: игрушку, кино или нейронную сеть?

      Я соглашусь, что это интересная идея для фичи ) Частично такие сценарии закрываются, например, уже существующим саджестом, который предлагает частотные варианты уточнений. Но он все таки решает в бОльшей степени задачу ускорения ввода для частотных версий запроса, чем удобства на менее частотных.

      • DmitryLTL
        /#22351944

        Когда тебе предлагают, это неопределённость и лишний шаг.


        Т.е. поискали, если поиск решит что надо уточнить запрос, то предложит. Но если не решит, то как бы и нету этой опции.


        Плюс сначала поискали, потом выбрали, потом опять поискали.


        Было бы интересно установил контекс и потом он пременяется до установки другого или его очистки.


        Что конечно не отменяет опции того что поисковый движок может проанализировать наиболее вероятные контексты и предложить пользователю уточнить.

  9. Andrey_mj
    /#22351208

    Отсекает ли алгоритм «кликовые факторы» от ботов? Не являются ли в целом поведенческие факторы слишком шумными для серьёзного их учёта в ранжировании? Алгоритмы того же Google учитывают их значительно меньше именно по причине возможности манипулировать ими.

    • gotmanov
      /#22351336

      Да, конечно отсекает. Для этого есть отдельные алгоритмы и целые под-системы для обнаружения роботов и фильтрации фрода (fraud, то есть «мошеннических» кликов, намеренно манипулирующих поисковой системой). Без учета кликов построить конкурентную поисковую систему сейчас невозможно. Разные варианты их использования в большей или меньшей степени подвержены проблемам с шумом и накрутками. Но в то же время это самый разнообразный семантический сигнал доступный поиску.

  10. itsoft
    /#22351494 / -1

    Есть только одно существенное Но — у Яндекса из-за рекламы поиск сложно разглядеть.

  11. mechatroner
    /#22351586

    Спасибо за статью, очень круто и интересно! Вопрос: вы пишете что для инференса использовалась внутренняя библиотека, а для обучения модели какая библиотека использовалась? Тоже какая-то внутренняя или Tensorflow?

    • ainu
      /#22351922

      Дополню вопрос: там caboost?

      • mechatroner
        /#22352042

        Точно нет. Catboost — это деревья решений, а тут нейросети

    • gotmanov
      /#22352062 / +1

      Для обучения используем TensorFlow + Horovod / NCCL для распределенного режима. Одна из основных причин — у нас есть классные специалисты, которые умеют готовить именно TF и выжимать из него максимум производительности. PyTorch + DeepSpeed пробовали в экспериментах, тоже выглядит рабоче.

  12. gotz
    /#22351920 / +1

    Планируется ли разработка собственных GPU, вроде Goole TPU?
    Планируете выкладывать языковые модели в опен-сорс, как Сбер с ruGPT-3?

    • ainu
      /#22351928

      кмк, стоимость разработки GPU выше, чем стоимость закупки 100 GPU. Даже очень дорогих GPU.

  13. VorontsovIE
    /#22352172

    Спасибо за статью!
    У меня вопрос по первой части. Вы пишете, что из документов делаете стримы. А нет ли у вас среди генерируемых стримов текстов вопросов, которые мог бы задать пользователь к этой статье? Кажется, задача генерации вопросов к тексту должна очень хорошо решаться сетями — и тогда вы получаете супер-релевантный мэтч.

    • gotmanov
      /#22353284

      Вы имеете в виду, что можно генерировать вероятные запросы пользователей прямо по содержимому документа, а потом использовать их в поиске и ранжировании? Такое пробовали делать раньше, с помощью более простых нейросетей. Например, через поиск близких к документу запросов по семантическим векторам. Оно работает, но не приносит сверх профита и при наивной реализации очень сильно увеличивает средний объем текстовых данных, которые нужно хранить для документа. На трансформерах повторить пока не пробовали.

  14. Ogoun
    /#22352644

    Планируете ли выкладывать что нибудь предобученное в общий доступ? Понятное дело что итоговую модель нецелесообразно, но что насчет обученной на сырых данных для последующего дообучения под свои задачи?

    • gotmanov
      /#22354970

      Сейчас YATI — это специализированное решение для нашего ранжирования. Даже на уровне предварительного обучения, где мы используем сигнал от кликов пользователей (на самом деле не только — экспертный сигнал там тоже уже есть). Ее в открытый доступ выкладывать не будем. Мы думаем на тему того, чтобы обучить модель более общего назначения и померить ее на стандартных NLP задачах. Такая уже может быть интересна и полезна широкой аудитории )

      Можете рассказать для каких задач Вы хотели бы использовать такую модель?

      • Ogoun
        /#22360954

        Лично мне была бы интересна модель которая или обучена или годится для дообучения в задаче отнесения сайтов к одному из классов: коммерческий, некоммерческий, системный и мусор (возможно больше классов). Системный это всевозможные api, мусор это мертвые ссылки, заглушки и т.п. На входе модели ключевые слова, содержимое сайта, может еще что то из метаданных.
        Кажется в одной из ваших лекций я видел что в Яндексе было разделение сайтов на коммерческие/некоммерческие, но вроде это было сделано эвристиками.

  15. MrKiri
    /#22353118

    Александр, подскажите, какого числа и месяца технология применяется в поиске.

    По ней все-все запросы ранжируются или какая-то часть. Есть часть, то какова ее доля (в процентах, примерно) и что это за запросы, быть может, наиболее популярные?

    • gotmanov
      /#22353236

      Технология работает в нашем поиске с осени 2020-года для всех запросов.

      • MrKiri
        /#22354902

        А с конца ноября или раньше?

  16. psyfish
    /#22353556

    У ребёнка зависли сегодня зависли часы, попытался найти в яндексе решение проблемы и вот выдача — prnt.sc/vqd69x на первых предлагаемых страницах нет даже намёка на аналогичный запрос…

    • Mike-M
      /#22354738

      Плюсую. Тоже бесит, что в результатах поиска практически всегда влезает Яндекс.Маркет, даже если запрос, как в вашем случае, вообще не имеет никакого отношения к продажам.

  17. Zverushko
    /#22354754

    Более того, в поиске рассчитываются тысячи факторов, но если выключить их все и оставить только новую модель, то качество ранжирования по основной офлайн-метрике упадёт лишь на 4-5%!


    Насколько я понимаю, катбуст выстраивает сплиты в дереве по значимости фактора для ранжирования. Более значимые — выше.

    Вопросы:
    1) Раз новый метод показывает такую высокую эффективность, то он должен быть высоко в решающем дереве. То есть, можно ли говорить о том, что новый метод используется для практически всего объема запросов к яндексу?
    Скажем, в гугле про берт говорили про около 10% запросов.

    2) Сократился ли размер решающего дерева (кол-во сплитов) после внедрения нового метода?

    3) Как бы вы оценили влияние нового метода в ранжировании коммерческих запросов? Там же нет больших текстов, а те, что есть, достаточно насыщены ключами.

    И немного не понял про определение куска текста, наиболее важного для ранжирования.
    Сначала, вы пишите, что у Палеха и Королева есть проблемы с релевантностью на сложных документах, потому что не умеет выделять зоны.
    А потом:
    Сложнее всего оказалось выделить хорошие фрагменты текста документа.

    уже про берт.
    Хотя, как я понял, берт должен это уметь сам.

    • gotmanov
      /#22354882

      Спасибо за вопрос ) Попробую ответить по порядку.

      1 и 2 — Решающие деревья в GBDT работают немного по-другому. Глубина дерева фиксирована, мы ее в наших моделях CatBoost не меняем. Если есть сильный признак, то сплит по нему будет просто встречаться чаще (и возможно выше) в дереве той же глубины, и соответственно будет сильнее влиять на итоговое предсказание. Размер влияния можно увидеть например по метрике FSTR, которая численно оценивает вклад конкретного признака в предсказание. В случае с YATI — вклад новой модели заметно больше 50% от суммарного вклада всех признаков. В этом смысле трансформер решает «больше половины» задачи ранжирования.

      3 — коммерческие запросы тоже бывают разные; текст документа с товаром там действительно сравнительно простой, но даже там есть нюансы — например, есть ли в тексте подробное описание, технические характеристики и т.д.; релевантным по коммерческому запросу может быть не только страница товара, но и страница с обзором, обсуждением или отзывом, где уже есть сложное текстовое содержание; наконец, сам запрос может быть сформулирован сложно, тут трансформер тоже помогает

      У Палеха и Королева есть проблемы с качеством по разным причинам. Во первых потому, что сами сети сильно проще и модель текста тоже упрощенная (тот самый «мешок слов»). Поэтому с длинным связным текстом они справляются плохо. Трансформер это умеет делать лучше, но все равно показать ему весь текст страницы — сложно, хотя бы из соображений производительности. Поэтому мы выделяем из всей страницы фрагменты текста и подаем их YATI на вход. Это заметно лучше раньше, но это все еще не полное содержимое документа.

  18. Mike-M
    /#22354866

    тяжёлые нейросети для поиска по смыслу
    Ага, только вот «смысл» этот заточен чаще всего под банальное «продать».

    Конкретный пример: ввожу в поиске слово «кроссовки».
    Результат: из 20 ссылок на первой странице лишь одна ведет на обзорную статью, и та рекламного характера, к тому же на Яндекс.Дзене. Остальные ссылки ведут в магазины за покупкой.

    Разве я спрашивал «купить кроссовки»? Нет! Перед приобретением я хочу узнать, какие кроссовки бывают, из каких материалов делаются, где и кем производятся, и так далее.

    Поэтому убедительная просьба к Яндексу: выделяйте место на первой странице под некоммерческую информацию, хотя бы на 50%. Только тогда это будет реально соответствовать заявленным Принципам Яндекса:

    Принципы Яндекса (выдержка):
    Мы создаём сервисы, которые приносят пользу людям и дают им новые возможности. Мы делаем сервисы, которыми хотели бы пользоваться сами, делиться с друзьями и близкими. Мы не создаём сервисы только ради зарабатывания денег.
    Пользователь — наш главный заказчик, то есть тот, для кого мы работаем и делаем сервисы. Это касается не только людей, которые обращаются к Яндексу за решением повседневных задач, но и наших партнёров: магазинов, ресторанов, курьеров, водителей, создателей контента и всех остальных. Все они наши пользователи.
    Мы осознаём свою ответственность за сервисы, которыми пользуются миллионы людей, и стараемся развивать их таким образом, чтобы максимизировать пользу и минимизировать вред.
    Некоторые сервисы мы развиваем несмотря на то, что они никогда не станут прибыльными. Мы делаем так потому, что верим в их ценность и пользу для людей.
    Яндекс открыт к диалогу с обществом и государством. Умение слушать общество и реагировать на общественные запросы, оставаясь при этом в правовом поле, — необходимое условие развития компании.
    Ранжирование результатов поиска происходит на основе критерия полезности — того, насколько конкретный элемент на соответствующем месте решает задачу пользователя наряду с другими элементами по запросу. Сервисы Яндекса также ранжируются по этому принципу.

    • inkelyad
      /#22355104

      Перед приобретением я хочу узнать, какие кроссовки бывают, из каких материалов делаются, где и кем производятся, и так далее.

      Само по себе это слово такого смысла не содержит. А без смысла, просто по упоминанию на странице — разнообразные магазины и будут большей частью страниц в интернете.


      Как я уже писал выше, уж если ищется 'по смыслу' — то поисковик должен показать пользователю те варианты смысла, которые он нашел/видел/понимает, и предложить пользователю выбрать нужный.

      • Mike-M
        /#22355232

        Несколько лет назад поиск работал гораздо лучше, и со «смыслом» у него было всё в порядке (ну, почти). Ссылки на магазины появлялись только в том случае, если в запросе было слово «купить». И это, кмк, правильно.
        Верните как было.

  19. dmblit
    /#22367104 / +1

    Спасибо за статью!
    1. Видел в комментах, что система особенно хорошо справляется со сложными опечатками. А нельзя по такому случаю вообще выкинуть опечаточник, кормить трансформерам сразу сырой запрос и сэкономить на этом ещё сколько-то драгоценных миллисекунд?
    2. Много лет назад я немножко носился с идеей учитывать в ранжировании предсказанную по сниппету открываемость документа, таким образом оптимизируя не успех пользователя, тупо кликающего сверху вниз, а успех того, который сниппет читает. Вы не думали какой-то новый заход сюда сделать с трансформерами? Возможно, персонализируясь с учётом разных паттеров чтения выдачи.

    • gotmanov
      /#22367152

      1 — нет, по нескольким причинам. Вот две, которые сходу приходят в голову. Техническая: трансформер пока используется не на всех этапах ранжирования; чтобы не потерять хороший документ в самом начале, все еще нужен опечаточник. Продуктовая: при неоднозначном исправлении опечатки важно дать фидбек пользователю о том, что исправление было; для этого тоже нужен опечаточник и явная генерация гипотез.

      2 — верно ли я понял вашу мысль, что клик пользователя, прочитавшего сниппет, более информативен (или как минимум содержит дополнительную полезную информацию) по сравнению с обычным кликом? И, соответственно, если от модели спрятать урл и заголовок, и оставить только сниппет, то она ровно такой клик и научится предсказывать? Моделями на сниппетах мы раньше занимались, и там было сложно найти полезный сигнал, поэтому в то, что наивный подход даст что то новое не очень верю. Трансформеры на сниппетах пока подробно не смотрели. При этом сама тема «качества» клика нас конечно очень интересует.