Ранжирование

20 марта 2010 года началось извержение вулкана Эйяфьядлайёкюдль в Исландии. 14 июля 2015 года межпланетная станция New Horizons передала на Землю фотографии Плутона. 15 апреля 2019 года случился пожар в соборе Парижской Богоматери. Что общего в этих случаях?



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

Особенность ситуации в том, что обычные поисковые механизмы не заточены на подобный сценарий. Более того, критерий свежести контента противоречит другим важным свойствам хорошего поиска: релевантности, авторитетности и т. д. Нужны особые технологии, чтобы не просто находить новый контент, но и сохранять баланс в результатах.

Меня зовут Денис Сахнов, сегодня я расскажу о новом подходе к доставке свежего контента до Яндекс.Картинок. А мой коллега Дмитрий Кривоконь krivokon поделится подробностями о метриках и ранжировании свежих картинок. Вы узнаете о старом и новом подходе к оценке качества. А ещё мы напомним о YT, Logbroker и RTMR.



Чтобы поиск картинок работал хорошо на той части запросов, ответы на которые должны содержать свежий контент, нужно решить следующие задачи:

1. Научиться быстро находить и скачивать свежие картинки.
2. Научиться быстро их обрабатывать.
3. Научиться быстро собирать документы для поиска на базе картинок (этот пункт станет понятнее по ходу повествования).
4. Сформулировать критерии качества поиска свежего контента.
5. Научиться ранжировать и смешивать контент в выдаче, исходя из требований качества.

Начнём с первого пункта.

1. Добываем картинки

В интернете множество сайтов, многие из них что-то регулярно публикуют, в том числе картинки. Чтобы люди увидели всё это в поиске Картинок, робот должен дойти до сайта и скачать контент. Обычно поиск так и работает: мы относительно быстро обходим известные нам сайты и получаем новые картинки. Но когда речь идёт о контенте, который вдруг становится актуальным прямо сейчас, эта модель не справляется. Потому что интернет огромный, невозможно прямо сейчас скачать HTML-документы всех сайтов в мире и быстро всё это переварить. По крайней мере никто в мире такую задачу ещё не решил.

Кто-то может представить себе решение проблемы таким образом: отслеживать всплески запросов и в первую очередь обрабатывать только те источники, которые как-то соответствуют запросам. Но это хорошо звучит только на бумаге. Во-первых, чтобы проверить соответствие чего-то чему-то, нужно уже иметь на руках контент. Во-вторых, если мы начинаем что-то делать после пика запросов, то мы уже опоздали. Как бы дико это ни звучало, нужно находить свежий контент до того, как в нём возникла потребность. Но как предсказать неожиданное?

Правильный ответ: никак. Мы ничего не знаем о графике извержений вулканов. Но мы знаем, на каких сайтах обычно появляется свежий и полезный контент. С этой стороны мы и пошли. Мы стали применять машиннообученную формулу, которая приоритизирует обход нашего робота в зависимости от качества и актуальности контента. Да простят нас сеошники: в детали тут углубляться не будем. Задача робота как можно быстрее доставить до нас HTML-документы. Только после этого мы можем взглянуть на их начинку и найти там новые тексты, ссылки на картинки и т. п.

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

Теперь у нас есть список ссылок на картинки. Дальше мы их скачиваем к себе. При этом используем собственный сервис Logbroker. Эта штука выступает в качестве транспортной шины, успешно переживающей огромные объёмы трафика. Несколько лет назад наш коллега Алексей Озерицкий уже рассказывал об этой технологии на Хабре.

На этом первый этап логически завершился. Мы определились с источниками и успешно добыли какие-то картинки. Осталось совсем чуть-чуть: научиться с ними работать.

2. Обрабатываем картинки

Сами по себе картинки, конечно, полезны, но их ещё нужно подготовить. Это происходит так:

1. В сервисе stateless-вычислений RTHub готовятся версии разных размеров. Это нужно для поиска, где удобно в результатах показывать миниатюры, а исходный контент отдавать с сайта-источника по клику.

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

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

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

3. Собираем картинки в документы

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

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

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

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



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

Но довести картинки до поиска недостаточно. Нужно суметь показать их в результатах поиска тогда, когда они полезны. И здесь мы переходим к следующему этапу к определению полезности. Передаю слово Дмитрию krivokon.

4. Измеряем качество

Общий подход к оптимизации качества поиска начинается с выбора метрики. В поиске картинок Яндекса вид метрики примерно такой:



где
n это количество первых картинок (документов) выдачи, которые мы оцениваем;
p_i вес позиции в выдаче (чем выше позиция, тем больше вес);
r_i релевантность (насколько точно картинка соответствует запросу);
w_i m_i прочие компоненты качества ответа (свежесть, красота, размер...);
f(...) модель, которая агрегирует эти компоненты.

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

Несколько слов о модели f(...). Она обучается на попарном сравнении картинок толокерами. Человек видит запрос и две картинки, а затем выбирает лучшую. Если повторить это много-много раз, то модель научится предсказывать, какой компонент качества наиболее важен для конкретного запроса.

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

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

Казалось бы, есть метрика, в которой уже учтён компонент свежести, и есть выборка запросов для контроля качества. Можно на этом закрыть тему и перейти к ранжированию. Но нет.

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

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

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


Запрос [фотография чёрной дыры]

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

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

5. Ранжируем

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

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

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

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

За счёт перехода на новую схему качество результатов поиска свежих картинок значительно возросло. Если раньше обучение основывалось в первую очередь на пользовательских статистиках на свежих запросах и у нас из-за этого возникала обратная связь с текущим алгоритмом ранжирования, то сейчас основой обучения являются объективно собранные корзины запросов, которые зависят исключительно от потока пользовательских запросов. Это позволило нам научиться показывать свежие результаты даже тогда, когда их раньше не было. Кроме этого, за счёт объединения пайплайнов ранжирования основного и свежего контуров последний стал заметно быстрее развиваться (все улучшения в одном источнике теперь автоматически доезжают и до второго).

---

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

1. Вступление

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

Эта заметка представляет собой личное мнение автора по поводу применения некоторых универсальных алгоритмов в задачах ранжирования. Цель подсказать разработчику возможные пути решения соответствующих задач и уберечь от наиболее типичных ошибок.

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

2. Первый взгляд

Скажите, пожалуйста, а сколько всего может быть способов перестановки результатов ранжирования? Для массивов из двух элементов интуиция легко поможет найти правильный ответ: [Первый, Второй] и [Второй, Первый]. А для массива из 30 элементов? Применим формулу комбинаторики: n! (факториал мощности множества). Для множества из 30 элементов количество возможных перестановок будет равно 265252859812191058636308480000000. Даже для рейтинга ТОП-10 есть 3628800 вариантов перестановки.

Представим, что порядок элементов задаётся случайно. Какая вероятность появления нужного элемента на первом месте? Пусть всего 10 элементов. Нас интересует один конкретный элемент. Порядок всех остальных уже не имеет значения. По сути, это аналогично случайному выбору из мешка синего шарика, где 9 красных и 1 синий шарик. Тогда вероятность составляет 1/10. Другими словами, при многократном повторении эксперимента примерно в 10% случаев мы увидим этот элемент на первом месте.

Кстати, а с какой вероятностью один и тот же элемент окажется на первом месте два раза подряд? Запуски алгоритмов мы считаем независимыми событиями, так как один запуск никак не влияет на другой. Следовательно, это произведение вероятностей независимых событий: 1/10 * 1/10. Это касается и всех последующих попыток, но тут красивее возводить вероятность в соответствующую степень.

Я дважды упоминал про случайную сортировку. А вдруг там другой алгоритм ранжирования? Можно ли вычислить формулу ранжирования, если код закрыт? Оказывается, что при определённых условиях это возможно. Нам потребуется многократно проводить эксперимент: передавать аргументы функции (факторы ранжирования) и фиксировать её ответ. Предлагаю посмотреть на пример с линейной регрессией.

3. Открываем чёрный ящик

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

Для начала есть смысл взглянуть на сами данные. Если вы отобразите массив данных с несколькими миллионами объектов, то человек не сможет всё это осмысленно прочитать. Придётся придумывать способ понятно описать его. Частая ошибка не изучив набор данных использовать среднее значение или медиану. Подобный подход чреват серьёзным искажением реальной картины.

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

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

В итоге мы видим распределение случайной величины. Регулируя число интервалов можно добиться адекватного представления. Теперь нам нужен способ увидеть взаимосвязь этой случайной величины с другой. Отобразим наблюдения в виде точек на плоскости, где по оси X будет score, а по Y наш единственный предиктор (признак). И вот перед вами появляется график:

На нём показано, что обе переменных сильно коррелируют между собой, следовательно, делаем предположение о линейной зависимости (score=a+bx). Не все точки выстроились на одну линию, что говорит нам о небольшом влиянии неизвестного фактора. Это я специально сделал, для красоты.

Подобрать коэффициенты в нашем случае труда не составит. Так, например, класс LinearRegression (из scikit-learn) после обучения (fit) позволяет получить смещение (intercept) и массив коэффициентов (coef). Подставляем значения в формулу и проверяем результат с помощью метрик mean_absolute_error и median_absolute_error. Собственно, это и есть решение нашей задачи. В случае множества признаков суть не меняется: под капотом всё устроено аналогичным образом (смещение + скалярное произведение вектора признаков и соответствующих коэффициентов).

Предупреждение о подводных камнях: обязательно внимательно изучайте данные, а при необходимости выполняйте подготовку, включая масштабирование и преобразование категориальных признаков (one-hot). Кроме этого, увеличение количества признаков сильно затрудняет визуальный анализ даже специальные алгоритмы уменьшения размерности (PCA, Isomap, TSNE) не всегда помогут отобразить информацию в удобном для человека виде.

4. Простая формула ранжирования

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

Или придумать формулу только для определённого типа задач? Уверен, что вы сталкивались с полнотекстовом поиском в реляционных базах данных (PostgreSQL, MySQL, SQLite) или в специальных системах (Elasticsearch, Sphinx, Solr). Например, в Elasticsearch формула ранжирования видна в режиме explain, а явно задать её в запросе можно через script_score. Не исключено, что вы сами пробовали написать BM25 (TF-IDF-подобный алгоритм).

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

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

Ярким примером фильтра выступает логистическая регрессия. Это быстрая и лёгкая в реализации модель классификации. Под капотом это обычная линейная регрессия, только результат её работы передают в сигмоиду. Далее выполняется проверка если результат больше 0.5, то класс 1, иначе класс 0. По сути, это формула гиперплоскости, разделяющей классы. На вид это простые алгоритмы, но их применяют даже в сложных задачах классификации текстов. Разумеется, тексты предварительно подготавливаются и преобразуются в вектор признаков (примеры алгоритмов: CountVectorizer, TfidfVectorizer, Word2Vec).

Замечание: в коммерческих проектах важно учитывать соотношение затраченных ресурсов и полученной выгоды. Самые минимальные увеличения могут затребовать такие ресурсы, что они просто не окупятся. Либо проблема может заключаться в сроках: нужно сегодня к вечеру получить хотя бы слабую модель, а завтра уже нет смысла даже в самой идеальной.

5. Более сложное ранжирование

Сложными задачами ранжирования будем называть такие, которые нельзя решить написанием хорошего запроса на SQL или доработкой компонента для подсчёта рейтинга. Другими словами, нет конкретной формулы или алгоритма. Самый банальный пример: как бы разработчик не старался, но простая функция не сможет классифицировать фотографии наравне с ResNet50 из Keras. Даже для создания хорошего алгоритма учёта поведенческих факторов может потребоваться использовать K-means для кластеризации контента и метрик поведения пользователей.

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

Идея состоит в том, чтобы получить возможность быстро добавлять готовые модели в любой проект. Без подключения дополнительных зависимостей. И проекты могут быть на разных языках программирования. Или это вообще специальные устройства. Когда мы говорили про линейные модели, то вы могли заметить, что такие алгоритмы очень легко добавить в любой проект. Достаточно просто скопировать массив с коэффициентами, который будет использован в соответствующем методе. А вот с комитетами решающих деревьев не всё так просто. В качестве конкретных реализаций будут выступать Catboost и Random forest.

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

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

Повторюсь, этот подход использовался для специальных устройств. Однако, в ряде случаев так можно делать для любых проектов не будет лишних зависимостей и производительность может быть выше, а так же есть возможность самому более тонко настраивать работу деревьев. Если с Random forest такое упражнение доводилось делать для реальных проектов, то с Catboost я просто побаловался в субботу на своём домашнем компьютере.

У ранее упомянутого Catboost есть возможность сохранения модели в формате JSON. В массиве oblivious_trees будут решающие деревья (обычно пни зависит от гиперпараметров), которые содержат индексы признаков (split_index) и границу разделения (border). Схема экспорта модели аналогичная, только специфика работы деревьев отличается, а именно, они друг за другом последовательно снижают энтропию.

6. Выводы

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

7. Послесловие

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

Обеспокоенным вебмастерам с большим количеством битых ссылок в Google Search Console можно расслабиться. Оказывается, когда почти половина страниц сайта отзывается 404-й ошибкой это норма для поискового бота Google.

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

И что с этим делать? Ничего. Если вы уверены, что страницы больше не существует, то можно выдохнуть. Бот Google проанализирует битую ссылку и проигнорирует ее. На оценку Core Web Vitals и позиции сайта в поисковой выдаче наличие ошибок 404 не повлияет.

Кстати, планируется, что в мае этого года Google обновит факторы ранжирования и добавит новый алгоритм Page Experience. Новый алгоритм ранжирования будет состоять из 7 параметров. Также Google анонсировала новый инструмент Core Web Vitals, который придет на смену и объединит сервисы Lighthouse, Chrome DevTools, PageSpeed Insights, Search Consoles Speed Report.

В 2021 году в Google ожидаются большие изменения в ранжировании. Так что стоит обратить внимание на новый алгоритм и сервисы для проверки.