Почему оно не находится! / Андрей Аксенов (Sphinx)Ontico
HighLoad++ 2017
Зал «Конгресс-Холл», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/3000.html
...и что сделать, чтобы уже находилось?
И снова про качество поиска. Поменьше скучной теории (ну, чтобы не более 60%); больше практических примеров. Как оценить типа-качество "на пальцах"; почему это плохая идея. Как построить оценивалку; насколько это просто; где взять готовую (нигде); зачем человечеству Толока или Mechanical Turk.
...
Учебный план для highload гуру / Андрей Аксёнов (Sphinx Technologies Inc.)Ontico
Программирование — штука одновременно очень узкая и очень широкая. С одной стороны, фундаментальных структур данных и алгоритмов крайне мало, а с другой, решаемых задач и специальных (для разных индустрий) техник много. И это мы молчим про регулярно появляющиеся новые клёвые библиотеки, фреймворки, СУБД, языки, трояны и кукизы. Через это системы вырастают всё более сложные и на стыке всего подряд, проблемы и задачи в них тоже. А значит, чтобы уметь ловко забарывать совсем любые задачи — особенно с хитростями и подвывертами из-за высокой нагрузки, распределенной архитектуры или тупо ограничений по железу — надо понимать много всякого про все уровни этих задач.
Как такому пониманию научиться, что именно надо изучать? Чего именно в идеале должен (и может!) знать каждый, а на практике почему-то не боятся знать единицы? Почему N-томника Кнута слишком много, но недостаточно? Какой очередной pet project затеять заради глобальной личной пользы вместо заныра в дебри очередного сиюминутного фреймворка? Чего читать после (или даже вместо) Гарри Поттера? Читать ли книжки вообще? Исчерпывающий ответ на эти вопросы возможно, пожалуй, уложить в недлинный 3-летний интенсивный учебный курс, но примерно правильный ответ я все равно попытаюсь дать в рамках доклада.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура проекта на 30 млн. пользователей", Дмитрий Смирнов (ведущий разработчик Фотостраны).
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Почему оно не находится! / Андрей Аксенов (Sphinx)Ontico
HighLoad++ 2017
Зал «Конгресс-Холл», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/3000.html
...и что сделать, чтобы уже находилось?
И снова про качество поиска. Поменьше скучной теории (ну, чтобы не более 60%); больше практических примеров. Как оценить типа-качество "на пальцах"; почему это плохая идея. Как построить оценивалку; насколько это просто; где взять готовую (нигде); зачем человечеству Толока или Mechanical Turk.
...
Учебный план для highload гуру / Андрей Аксёнов (Sphinx Technologies Inc.)Ontico
Программирование — штука одновременно очень узкая и очень широкая. С одной стороны, фундаментальных структур данных и алгоритмов крайне мало, а с другой, решаемых задач и специальных (для разных индустрий) техник много. И это мы молчим про регулярно появляющиеся новые клёвые библиотеки, фреймворки, СУБД, языки, трояны и кукизы. Через это системы вырастают всё более сложные и на стыке всего подряд, проблемы и задачи в них тоже. А значит, чтобы уметь ловко забарывать совсем любые задачи — особенно с хитростями и подвывертами из-за высокой нагрузки, распределенной архитектуры или тупо ограничений по железу — надо понимать много всякого про все уровни этих задач.
Как такому пониманию научиться, что именно надо изучать? Чего именно в идеале должен (и может!) знать каждый, а на практике почему-то не боятся знать единицы? Почему N-томника Кнута слишком много, но недостаточно? Какой очередной pet project затеять заради глобальной личной пользы вместо заныра в дебри очередного сиюминутного фреймворка? Чего читать после (или даже вместо) Гарри Поттера? Читать ли книжки вообще? Исчерпывающий ответ на эти вопросы возможно, пожалуй, уложить в недлинный 3-летний интенсивный учебный курс, но примерно правильный ответ я все равно попытаюсь дать в рамках доклада.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура проекта на 30 млн. пользователей", Дмитрий Смирнов (ведущий разработчик Фотостраны).
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Andrew Aksyonoff "Архитектура вокруг поиска"Fwdays
Начиная с определенного масштаба, вокруг любого базового поискового движка плюс рядом с ним неизбежно вырастает изрядная куча всяких интересных прослоек и сервисов. Особенно, когда одним лишь поиском по ключевым словам (либо вообще булевым, либо с простеньким ранжированием по формуле) дело ограничиваться перестает. Расскажу, как сегодня выглядит архитектура сервисов “вокруг и около поиска” у нас в Авито (числа и слова для привлечения внимания: 40M+ активных объявлений, тысячи RPS, ML ранжирование, пляски с анализом и доставкой данных, и всё такое).
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Andrew Aksyonoff "Архитектура вокруг поиска"Fwdays
Начиная с определенного масштаба, вокруг любого базового поискового движка плюс рядом с ним неизбежно вырастает изрядная куча всяких интересных прослоек и сервисов. Особенно, когда одним лишь поиском по ключевым словам (либо вообще булевым, либо с простеньким ранжированием по формуле) дело ограничиваться перестает. Расскажу, как сегодня выглядит архитектура сервисов “вокруг и около поиска” у нас в Авито (числа и слова для привлечения внимания: 40M+ активных объявлений, тысячи RPS, ML ранжирование, пляски с анализом и доставкой данных, и всё такое).
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
Владимир Лучанинов. Сделай сам анализатор SERPOctopus Events
1. Вопросы при аналитике SERP.
2. Существующие решения: SaaS, self-hosted, Desktop.
3. Создание системы аналитики под себя из Netpeak Checker, Google Sheets и Google Data Studio.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
Если не считать объем информации проблемой, то трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира.
Рассмотрим проблемы _очень_ сложных схем/моделей данных и использование RDF Storage в качестве варианта решения.
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
4. Зачем этот доклад?
• Скорости растут => скорости… неважны
• Ну, в жизни, а не синтетических бенчмарках
• Людей-посетителей приучают к “плохому”
• Google, Yandex, итп
• Из коробки получается не очень
• Из коробки не может получаться, надо по-разному тюнить
• Ну и это просто интересная в целом тема!
9. Релевантность, это –
• Такой спец-термин из поиска
• Такое большое человеческое заблуждение
• Щаз будем заменять одно заблуждение набором
других!
• Возникает т.н. «релевантность» ровно в тот
момент…
34. Документ
"The time has come," the Walrus said,
"To talk of many things:
Of shoes, and ships, and sealing-wax,
Of cabbages, and kings,
And why the sea is boiling hot-
And whether pigs have wings."
35. Запрос
"The time has come," the Walrus said,
"To talk of many things:
Of shoes, and ships, and sealing-wax,
Of cabbages, and kings,
And why the sea is boiling hot-
And whether pigs have wings."
41. Целевая функция
• На входе – куча чиселок, факторов
• На выходе – одно число
• Rel = Rel(f1, f2, …, f200, …): RNumFactors R
• Ш.И.: но конкретные числа… неважны!
• Ш.И.: важен… порядок документов
42. Метрики качества
• Все начинается с оценок
• Теплых, ламповых, человеческих
• Оценивается всегда пара запрос+документ
• Бинарные (0/1), “просто” числа, и т.п.
• Для простоты, пусть будут тупо бинарные
• Bсе это вводится, впрочем, чтобы как-то сравнивать
разные отклики
43. Пример отклика 1
1. Sphinx | Open Source Search Server
2. Sphinx - Wikipedia, the free encyclopedia
3. Great Sphinx of Giza - Wikipedia, the free encyclopedia
4. Overview - Sphinx 1.1.2 documentation
44. Пример отклика 2
1. Great Sphinx of Giza - Wikipedia, the free encyclopedia
2. Sphinx - Wikipedia, the free encyclopedia
3. Sphinx | Open Source Search Server
4. Overview - Sphinx 1.1.2 documentation
45. Пример отклика 3
1. Sphinx - Wikipedia, the free encyclopedia
2. Sphinx | Open Source Search Server
3. Overview - Sphinx 1.1.2 documentation
4. Great Sphinx of Giza - Wikipedia, the free encyclopedia
46. Метрики качества
• Без учета порядка – Precision, Recall
• С учетом порядка – Average Precision, AP
• Или DCG, BPREF, pFound, и т.п.
• Усредняем кучу запросов – Mean AP, MAP
• Или средний DCG, BPREF, pFound, и т.п.
• Все, теперь это наша заветная цель
• Чем больше, например MAP
=> тем больше Среднее Счастье Пользователя
47. Извилистый путь релевантности
• Есть мега-функция Rel()
• Есть куча документов
• Есть куча запросов
• Есть куча пользовательских оценок
• Считаем Rel (по функции и факторам)
=> генерируем отклики (сортировка по Rel)
=> считаем MAP, DCG итп (по оценкам)
=> усредняем и сравниваем
63. Метрикам – да, ML – тоже да!!!
• Если хочется качества, знать таки нужно
• Проверять качество вручную нереально
• Быстрая, но болезненная смерть
• Подгонять формулы вручную таки можно!
• Мелкие уж точно, да и Google врет
• Но почему не опробовать готовый мат/статпакет?
64. “Итоги подведем” (с) Гамлет
• Релевантность в мире веб-поиска?
• Все начинается с оценок, и все оценки субъективные
• Оценок и факторов на входе УУУ МНОГО
• Рукой уже никак, обязательно машинное обучение
• Обучение == “умная” “регрессия”, условно
• На выходе – ну, какая-то мега-функция
• Которая – максимизирует Метрику Счастья
65. “Итоги подведем” (с) Гамлет
• Релевантность в мире веб-поиска для простых людей?
• Все начинается с оценок, и все оценки субъективные
• Оценок и факторов на входе УУУ МНОГО МАЛО
• Формулу рукой еще можно, но можно и машинное обучение
• А вот проверять метрики сразу автоматом, но это просто!
• На выходе – ну, какая-то мега-функция
• Которая – максимизирует Метрику Счастья
67. Или…
• Как все (теперь) “хорошо” в веб-поиске
• Как все (пока еще) “плохо” в менее
затейливых движках
• особенно опен-сорсных
68.
69. “Не было ни единого разрыва!”
Все остальные Веб-поиск
1-10… факторов 100-1000+ факторов
0 оценок? 1-10M+ оценок
Ad-hoc функции Специально
(см. левая пятка) обученные функции
(см. маш. обучение)
70. Не все так плохо!
• Вы не Google!
• А, скажем, сайт про запчасти для Белазов
• Незначительно поменьше данных
• Чуть пореже запросы
• Отклики потоньше
• Ad-hoc может приемлемо сработать
73. Как это делает Sphinx
• Ранкер: какая-то функция ранжирования
• Только харкод: заранее встроенная в Sphinx
• Можно выбирать на лету, 1 строкой
• $client->SetRankingMode(SPH_RANK_BM25)
• SELECT … OPTION ranker=bm25
74. Осторожно, скользкая ступенька!
• $client->SetRankingMode(SPH_RANK_BM25)
• Через API только в режиме extended
• $client->SetMatchMode(SPH_MATCH_EXTENDED)
75. Кого хотеть?
• BM25 – грубо говоря, аналог Lucene
• PROXIMITY_BM25 – бустит (под)фразы
• Но однако не смотрит на частоты слов в подфразе
• SPH04 – еще бустит начало поля, точное совпадения поля
• Других встроенных ”про качество” пока нет
• И, возможно, уже (почти) не будет…
77. Expression ranker, 2.0.2+
SELECT *, WEIGHT() FROM myindex
WHERE MATCH('hello world')
OPTION ranker=expr('sum(lcs*user_weight) *
1000+bm25')
78. Expression ranker, 2.0.2+
SELECT *, WEIGHT() FROM myindex
WHERE MATCH('hello world')
OPTION ranker=expr('sum(lcs*user_weight) *
1000+bm25')
79. Да, настолько просто!
• Пользоваться – вот так, буквально
• Через API тоже можно
• Дефолтная формула proximity_bm25
– вот такая, буквально
• sum(lcs*user_weight) * 1000 + bm25
• Как я раньше и говорил, Целых Два Фактора!!!
80. Просто было в учении
• Кучка новых факторов
• Document Level:
• bm25, max_lcs, query_word_count, doc_word_count
• Field Level:
• lcs, user_weight, hit_count, word_count, tf_idf, min_hit_pos,
min_best_span_pos, exact_hit
• Планируются (и нетяжело) делать еще – звоните
81. Просто было в учении
• Field level обязательно агрегировать
• Функция пока только SUM, но звоните
• Доступны все атрибуты документа
• Доступны все встроенные математические функции
• Кажется, доступны UDF (не проверял)
• Работает подозрительно быстро
82. Наш самый сложный ранкер
• SPH_RANK_SPH04 =
sum((4*lcs+2*(min_hit_pos==1)+exact_hit)*
user_weight)*1000+bm25
• Уверен, вы можете лучше :)
• Тем более, что теперь все знаете всё :)
85. Качество != ранжирование
• Еще опечатки
• Еще “занудность” поиска
• Еще морфология
• Еще синонимы, расширение запросов
• Еще номера моделей, и т.п. вертикали
• Еще анализ запросов (натягивание на фильтры)
87. Как бороться “легко”?
• Опечатки? sphinx/misc/suggest/
• Занудность? Оператор кворума
• Анализ запросов? regexps, SHOW KEYWORDS
88. Как бороться “тяжело”?
• Морфология, синонимы – wordforms, stemmer,
expansions, index_exact_words
• Местами неудобно, но таки можно
• Номера моделей – препроцессинг, и-или танцы с
blend_chars, stopword_step, и т.п.
• Нужен ряд ручных правил под предметку, не избежать
89. Качество != ранжирование
• Еще опечатки
• Еще “занудность” поиска
• Еще морфология
• Еще синонимы, расширение запросов
• Еще номера моделей, и т.п. вертикали
• Еще анализ запросов (натягивание на фильтры)
91. Итого
• Вот как устроена релевантность – вообще
• Вот что уже встроено – конкретно в Сфинкс
• Вот как теперь бороть релевантность – у нас
• Вот какие еще есть беды с качеством – вообще
• Вот как можно их тоже забарывать – в целом
• Почему ваш поиск до сих пор… так себе?!