#74 Как работает Search Engine под капотом: ранжирование и релевантность | Рауф Алиев

Сегодня у меня в гостях Рауф Алиев — человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами и рекомендациями поверх всего этого.

Мы обсудили, как вообще устроен полнотекстовый поиск: что такое inverted index на практике, зачем нужен BM25, почему важно учитывать длину документа, что дают proximity и exact match. Отдельно разобрали, почему фасеты — это не совсем «поиск», как работают стемминг и лемматизация, зачем иногда хранить и нормализованный, и оригинальный текст, и почему работа с разными языками — это отдельная инженерная боль.

Потом ушли в гибридные модели: как смешиваются ключевые слова, query expansion, синонимы и векторные представления. Поговорили о том, почему векторный поиск лучше понимает смысл, но хуже объясняет свои решения, и как LLM можно использовать не для болтовни в чате, а как инструмент, который превращает человеческий запрос в понятные системе фильтры.

Ну и, конечно, обсудили качество. Что такое precision, recall, NDCG на практике, как собрать свой ground truth и как сравнивать конфигурации поиска без мучительных A/B-экспериментов на пользователях. И почему почти всегда, улучшая одну метрику, ты неизбежно просаживаешь другую — и с этим просто приходится жить.

Полезные ссылки:
https://testmysearch.com/my-books.html

Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog
– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321

🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog
🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot
🔹Курсы по программированию — начни учиться уже сегодня: https://ru.hexlet.io/courses

#программирование #разработка  #кириллмокевнин  #подкаст  #организованноепрограммирование #поисковыесистемы #invertedindex #векторныйпоиск

Как работает Search Engine под капотом: ранжирование и релевантность

• (00:00) - Введение. Поиск сложнее, чем вы думаете - 25 лет опыта за 2 часа
• (01:07) - От Сфинкса до Elastic: как менялся рынок поисковых систем
• (06:00) - Теория или практика? Как правильно входить в сложные системы
• (14:42) - Как SEO и маркетплейсы ломают алгоритмы
• (19:55) - SEO началось с манипуляций: как PageRank всё изменил
• (31:12) - Архив за 100 лет и гибридный поиск на практике
• (44:05) - Гибридный поиск — будущее индустрии
• (01:01:04) - Транслитерация и языковые ловушки
• (01:13:53) - Как искать Go или C и не сломать поиск
• (01:21:54) - LLM как ревизор поисковой системы
• (01:28:19) - Локальные поисковики против Google
• (01:32:21) - Китайский без пробелов и другие языковые боли
• (01:36:45) - Заключение. Поиск — это компромисс между математикой и бизнесом

★ Support this podcast ★

Creators and Guests

Guest

Рауф Алиев

Рауф занимается плотно двумя темами: техническими решениями для электронной коммерции и решениями в области поиска. До переезда 15 лет работал в айти, в компаниях Chronopay, Svyaznoy, Enter, Mail.ru - в какой-то степени все эти бренды уже остались в прошлом, но опыт, он накапливался. По темам поиска выпустил 4 книги по теме Search, Recsys и сейчас пишет пятую по теме Information Retrieval. Переехал в США десять лет назад, живет неподалеку от Вашингтона.

What is Организованное программирование?

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

Друзья, привет. Это подкаст Организованное программирование. Я его ведущий Кирилл Макевнин. Сегодня у нас очередной выпуск, и у меня в гостях Рауф Алиев. Человек с большой буквы, специалист большой по поиску, с огромным стажем. Работал в большом количестве крупных российских компаний, сейчас в американской компании конкретно одной, и продолжает заниматься поиском, выпускает книги очень крутые. Я, кстати, себе скачал, буду читать. И сегодня мы хотим поговорить про поиск. Подкаст

будет, ну, мне кажется, достаточно базовый, потому что мы будем говорить про поиск не какую-то глубокую историю с алгоритмами зарываться пока, а в целом того, как он устроен, принципы ранжирования, ну, какие-то базовые вещи. При этом Рауф расскажет много, я думаю, интересного на тему того, как разные языки влияют, как Ии влияет, с какими сложностями всё это сталкивается и какие, например, современные вени вообще в этой индустрии. Потому что, мне кажется, очень многие запомнили поиск, вот когда он только там появлялся, Яндекс, Google, и, в общем-то, мало знают, как он с тех пор эволюционировал. Ну и плюс рекомендательные системы, конечно же. Рауф, привет, тебе слово. Да, добрый день. Добрый день. Очень приятно. Спасибо, что пригласили. А я люблю эту тему. Я занимаюсь поиском уже, не знаю, лет 25, а с перерывами на e-комерс, которым без поиска было тоже непросто. Не касаться этой этой темы. Вообще, конечно, было непросто. Вот. А, но вот последние много лет я работаю именно в теме поиска. Сейчас работаю в одной из компаний, не знаю, могу ли я называть или нет. По-нашему, наверное, нет. Ну, скажем так, на три буквы. Вот. До этого работал в другой компании на три буквы, но все вы их знаете. Значит, и занимаюсь там фокусно поиском конкретно Ковео. А-а, но, ээ, это просто потому, что в проекте сейчас каве. Но в целом, да, всё поло и Elластик Solor, и своё. А сфинкс был, кстати, вы с Андреем знакомы? Да, это было даже в Свизном, насколько я помню. А, да, Свизном был сфинкс. А, когда я работал. Но, честно говоря, это совсем всё из прошлого. Сейчас сфинкс вообще не виден на горизонте, очевидно. Ну всё эволюционирует и системы, надо сказать, что в большей части они остались теми же. Ну те архитектурные особенности сфинкса, которые были тогда, они в целом плюс-минус то же самое, что и сейчас во всех ведущих базовой части. Но всё же этим надо заниматься, и всё вокруг растёт. Сфинкс не рос многие, много многие годы его сейчас нет. Ну да, да. Я просто лично знаком с Андреем. Там на конференциях много пересекались. Да, да, да, да. И он, конечно, очень, очень прикольный чувак и много, ну, очень крутой специалист, на самом деле. Но с бизнесовой точки зрения у него он проиграл тогда, получается, гонку Эластику. Ну, за Эластиком большие деньги, большие дяди и всё такое. Я бы, знаешь что, ты хотел начать, кстати, историю с того, как ты в поиск попал. Ты сказал, что это какая-то просто интересно. То есть вообще всё началось в 2001 году, когда я придумал проект продавать интернет в розницу. Вот. А значит, в 2001 или 2002, я уже точно не помню. Очень давно. Идея была такая, что есть много сайтов в российском сегменте, в которых по сути справочники всё подряд, всякие рецепты э кулинарные или документация по Юниксу или ещё что-нибудь. Ну то есть это сайт, на котором много контента. Народ туда ходит и его читает. Там один из сайтов был, например, OpennetNet, с которым мы работали. Вот. А и ээ что мы по сути делали? Мы скачивали оттуда, ну, как я, товарищ вдвоём, мы скачивали оттуда весь контент, аа, и записывали его на диск и продавали его в рознице. Но ведь просто контент скачанный, он, э, бесполезный. Его, по нему нужен поиск. А поиска даже на сайте не было часто. И для того, чтобы сделать это удобным, приходилось как-то сделать на диске поиска. Для этого нужно всё это разрабатывать, потому что никаких готовых инструментов на то время не было. Вот с этого первого компонента, который был на этом диске, ну, вообще весь бизнес, аля бизнес коммерческой палатки, который тогда был, это, по сути, была продажа дисков с доставкой через Почту России, э, с контентом, снятым с сайта. И прибыль от этого диска, э, ну, это по сути, что за вычетом стоимости диска и почтовых услуг. а, делилась между мной и владельцем сайта. И эта штука как-то работала, приносила какие-то мелкие деньги. И меня заметили, ребята, пригласили, говорят: "У нас проект есть, ребята, надо сказать, такой абсолютно бандитской нарожности. Такой один товарищ большой лысый со шрамом через всю шею. Тогда Линколь навигатор оказался тоже машиной очень сильно. В каком-то мы дорогом ресторане сидели, они говорят: "Вообще не проблема. Мы будем тебе каждый делю деньги платить, а ты нам будешь делать систему, которую будут разрабатывать у тебя программисты и юристы. Почему юристы? Потому что это система про законы. Там нужно было комментарии к законам делать. Вот и поэтому делу всем нужен поиск. И это всё программа на м программа на дельфах на то время. Да, это был очень интересный и очень нервный проект, потому что, ну, например, там последний платёж мне не платили до тех пор, пока я не принёс контракт с последним юристом, который уже уехал за границы. И я этот контракт как-то как-то выбивал, и мне этот платёж дали. Но главное, что там был поиск, это то, что я очень любил и сделал эту систему с полностью с нуля, не разбираясь даже, как это на рынке должно делаться. изобрёл там эти скиплистый сам inverted ind с нуля просто разбирался как бы я это сделал разумеется сделал дофига ошибок их не очень видно поиск работает тем не менее очень много чему научился на практике вот и как раз вот мы сегодня с товарищем обсуждали к вопросу надо ли изучать теорию перед тем, как и то, что есть уже у других перед тем, как что-то делать. Вот иногда очень полезно просто начать делать на набить шишек, а потом понять, что это, оказывается сделано по-другому. И тебе легче понять, как это сделали другие, когда ты это делаешь делал сам и эти шишки набивал. А второй подход - это вообще ничего не начинать, а пойти изучать на рынке, там какие есть продукты, как их вместе скомпоновать, запустить. Это совсем другой интеграционный подход. Вот. Да. И с тех пор меня эта тема очень э завлекла с поиском. Вот. И я м так или иначе её к ней возвращался много раз. Вот последний раз я к ней вернулся несколько лет назад и прямо совсем в ней остался. Угу. Ну да, я вижу, что какие-то работы пишутся серьёзные. Институт, пару слов скажи про это тоже. Институт, которым я сейчас пытаюсь PhD получить. Да, ну я, значит, пытаюсь, я просто на нулевой стадии. Мне только на прошлой неделе сказали, что процесс начался. То есть, а я очень надеюсь, то, что он так дальше пойдёт, и я годика через три буду, э, иметь PhD из университета Зигина. А там есть большая кафедра по рекомендационным системам, собственно, recommendation Systems.com - это их. Вот. И я уже там что-то начал делать. Но в целом, да, это, наверное, не прямо относится к поиску и даже не прямо относится к рекомендационным системам. Например, есть такая задача, она очень близкая к поиску, я её очень много раз использовал. Это нахождение самых длинных общих последовательности в документах. Почему? У меня прямо во многих проектах такое было. Вот есть большой поисковый индекс, в котором есть наполненный веб-страницами каким-то образом. Есть кроллер, который ходит пом-страницам и кидает туда в этот индекс миллионы документов. Вот есть миллионы документов. И теперь вопрос: а вдруг этот кроллер кидает вместе с сущностью документа ещё и какие-то навигационные э фрагменты, например, там меню какое-нибудь или ещё что-то? Контролировать это сложно, потому что он же берёт с веб-сайта, а вот как этот веб-сайт строится, тут там какое-то условие есть на какой-то глубокой странице показывать какой-то баннер с каким-то текстом. И мы не хотим этот баннер с каким-то текстом иметь в поиске. Ну, потому что он шум создаёт, он отвлекает от сути документа. И для того, чтобы это найти, надо найти, если в бриндексе похожие фрагменты длинные, максимально длинные, потому что там маленьких-то много будет, а вот максимально длинные. И вот для такой задачи есть целый класс алгоритмов pattern money. И эти алгоритмы в той или мере находят длинные, максимально длинные, частые последовательности. Там целая отдельная наука, а чем они отличаются и так далее. Но главная идея, что это очень близко к поиску. Потому что как только ты начинаешь анализировать чужой индекс, первым делом ты спрашиваешь: "А что у вас там внутри? А там миллион документов или там 100.000 документов? вручную их не посмотрим. Угу. Ну и вот я разрабатывал такой алгоритм, сел на Питоне, потом переводил его на C. И вот, знаешь, после 25 лет работы вернуться обратно к Си, да, там надо было отметить, что тот поиск, который я писал, был на дельфах. Но вообще в то время были у нас разработки на C, и у нас даже система управления контентом была на C в компании Арstyle, где я тогда работал. Она на C++се была симэска. Вот. И сейчас я опять возвращаюсь к этому C++. И, честно говоря, меня настолько удивляет, насколько всё это быстро. Ну, то есть я скачиваю архив Гутенберга, а, на 14.000 документов, и у меня сишный алгоритм ищет максимальные длинные последовательности за 3 секунды. То есть он обрабатывает 6 Гб за 3 секунды. Это тяжело представить вообще. Но, но потому что, очевидно, там алгоритм, но это не не очень простая штука, да, чтобы такое найти. Там проходов огромное количество, да? А сказать, что он сначала память должен считать, конечно, да, а потом за это за 34 секунды это всё боботать. Вот счищение в память оно тоже какое-то время, но оно тоже исчисляется в типа 3х секундах, 2 секундах. Ну то есть это вот настолько быстро. Да. Да, это интересно. Скажи, пожалуйста, вот у меня, наверное первый вопрос такой по вот есть фичи какие-то, которые мы делаем на сайте и для, мне кажется, многих людей, которые, ну, серьёзно этим не занимались, поиск, ну, типа, о'кей, поиск надо сделать, просто фича. Но поиск - это же, по сути, отдельная инженерная дисциплина, очень серьёзная, со своим набором алгоритмов, с историей бесконечной. Можешь пару слов про это сказать? Ну, вообще тема поиска в науке называется informational retrieval. И да, и она очень сильно граничит с рекомендательными системами. Алгоритмы совсем разные. Вообще подходы разные, но по сути это очень близкие вещи. Потому что, что такое поиск? Ты задаёшь запрос, а получаешь перечень документов, которые релевантны этому запросу. А что значит релевантны? Это всегда большой вопрос. И для интернет-магазина, например, нет, для пользователя, например, релевантность означает то, что он на самом деле в голове держит, а не то, что написал. Он пишет, предполагая, что система умная и сама допрёт, что ей нужно. А там средний пользователь не очень хорошо проецирует мысли в запрос и делает это во многом, опираясь на опыт с Гуглом. А гугловский поиск, он более умный, он немножко берёт контекст в и пользователь это не знает, что такие штуки вообще существуют. Оно просто работает. И вот он приходит на веб-сайт и делает то же самое. Он ищет что-то, предполагая, что оно работает так же хорошо, как и Google. А что с точки зрения веб-сайта происходит? Там приходит покупатель с деньгами, хочет их потратить, и он что-то запрашивает. У него есть что-то в голове, а запрашивает он одно, а в голове у него может быть немножко другое. И надо как-то это догадаться и поставить э дать ему те результаты, которые его удовлетворят. И вот тут вот прямо уже рекомендательная система начинается, потому что не всегда то, что его удовлетворит, это то, что имеет эти ключевые слова в документе там или так далее. Пользователя это не волнует, он это не понимает вообще. Ему надо вот, чтобы ему выдалось то, что он хотел. Вот про важность. Конечно, все интернет-магазины понимают важность поиска. Во-вторых, э, поиск в интернет-магазине и категорийные страницы - это очень родственные штуки. Заходишь на категорийную страницу, по сути, ты ищешь по интернет-магазину с query в виде категорий, да? Везде немножко по-разному это реализовано, но идея такая, да, то есть ты заходишь в какой-то раздел, у тебя по идее результаты поиска по этой категории, да, оформлены иначе. Ну, ну по сути это так. Значит, и с интернетмагазинами всё хорошо, но есть ещё масса других веб-сайтов, где много контента и без поиска просто им неудобно пользоваться. Ну, я не знаю, файл Ийнштейна, например, один из примеров, там 3 млн документов, но какой как это вообще можно было без поиска, да? Значит, и как только появляется тема "Давайте подкрутим поиск", то да, это целая отдельно инженерная тема, потому что она совсем ничего не имеет общего с всем вокруг там вне этого поиска. Специалисты, которые сидели на этом веб-сайте, занимались контентом, специалисты, которые там автоматизировали формочки, они всё это не знают. А если ещё и приходят языки другие, потому что пользователи-то приходят со всего мира и ищут, как хотят, то там ещё и листическая тема появляется, которой уже не разбираются даже те, кто разбираются в поиске. Часто в поиске, да. Поэтому, да, это большая инженерная дисциплина со своими сложными взаимосвязями. Хотел тут добавить ещё есть ведь история про поиск с точки зрения ранжирования по смыслу. Вот как ты сказал по поводу, например, файлов Эппштейна. Вот они вышли, да, и ты хочешь просто что-то найти, но там у тебя просто есть данные и ты с ними работаешь. Но когда мы говорим про глобальные поисковики, там проблема в том, что с той стороны есть люди, которые хотят в этом поиске вылезти выше. И получается, что помимо всяких поисковых стандартных историй ранжирования, у тебя есть ещё армия, а, я бы сказал, весь интернет, который пытается все твои алгоритмы узнать, поломать и вылезти на первое место. Это тоже мы относим к науке про поиск или это типа отдельное вообще направление, которое в поиске не рассматривается? Дело в том, что это очень типичная проблема для маркетплейса, потому что когда на любом маркетплейсе поиск начинает быть фактором прибыли для отдельного селлера, то этот селлер не может не задумываться о том, что какие-то мелкие движения даже в части контента могут ему принести больше денег. Он, конечно же, об этом задумывается. И, конечно же, вокруг этого появляются люди, которые помогают более качественно сделать про описание товаров. Во-вторых, у этих селлеров часто есть поставщики товаров внешне, и с этими поставщиками приходит и контент. И часто селлер просто не в состоянии нормально обработать, не знаю, тысячи единиц товара, которые ему приходят, уходят, приходят новые. Ну, потому что у него есть свои поставщики. И как только такая ситуация возникает, эти селлеры как-то находят ещё кого-нибудь, кто уже разбирается и кто занимается не только этим селлером, а ещё такими же десятками, сотнями других. И у них есть уже готовые рецепты, каким образом сделать так, чтобы товары этого селлера были повыше своей категории. И эти рецепты, они часто эксплуатируют слабости поисковой машины. Как и результат, мы видим плохой поиск на маркетплейсах очень часто, потому что слабости, которые уже есть в поиске для маркетплейса, где-то не слабости, а даже наоборот плюсы, но и они не могут их просто взять, выключить, а где-то они слабости, которые позволяют таким образом продвигать. И, как правило, все маркетплейсы имеют плохой поиск. Кого не взять? Например, тот же Amazon. У Амазона очень сильная, очень мощная, очень умная, очень крутая команда. Я знаком с ребятами оттуда. Очень хорошая команда поиску. Они регулярно выпускают довольно серьёзные и сложные пейперы, за которыми есть реальное решение. Спроси кого угодно, работает ли поиск хорошо на Амазоне. Все скажут: "Нет". Потому что с точки зрения отдельных людей он работает плохо. Но с точки зрения бизнеса я не знаю, но, наверное, с точки зрения бизнеса он работает хорошо, потому что в Амазоне достаточно инструмента инструментарий и достаточно мозгов, чтобы сравнивать то, как у них работает поиск сегодня и 3 месяца назад до того, как они там что-нибудь добавили. Угу. И они 100% видят, что то, что они добавили, оно работает. А, и поэтому надо оставить. Ну, либо не работает, и поэтому его надо убрать. То есть в этом плане всё хорошо, но с точки зрения пользователя, отдельного конкретного пользователя с его нуждами, может быть всё очень хорошо. Я могу прямо прокомментировать, потому что поскольку я Амазоном всё время пользуюсь, вот Amazon всё-таки такая штука, что в большинстве случаев я ищу внутри него. А вот, например, если я на Гитхабе ищу, я никогда в жизни не пользуюсь поиском гитхаба, потому что он работает вот действительно так, что лучше бы он вообще не работал. Я всегда иду просто в Google, пишу сайт github.com, например. Да, то же самое по редиту, кстати. Я ищу только через Google. На самом деле с ними есть одна особенность. Дело в том, что вот, например, в том же Фейсбуке, не знаю, как в остальных проектах, скорее всего, поиск не очень нужен по бизнесу. Он не помогает им ни в чём. Он нужен пользователям, но он не нужен самому бизнесу. Ну зачем? Ну, например, у меня есть архив свой ээ постов, в которых я периодически хочу что-нибудь найти. Я, например, на Фейсбуке опубликовал уже, наверное, 120 обзоров художников. Ну, делаю я это не для кого-то, а для себя. Мне интересно, э, где-нибудь записывать имена художников, которые мне нравились, с их работами, но потом найти это, ну да, там ставишь тег и дальше по этому тегу ищешь. И тег у меня он называется там Art Rlikes, вот что-нибудь такое вот. И я по этому тегу предполагаю, что должны найти все мои посты. Ну, он же уникальный, правильно? Но по факту так не происходит. И объяснение этому в том, что просто Фейсбуку не нужен поезд, потому что он даёт дополнительную нагрузку на сервера и не даёт ничего больше. Нужен ли он Гитхабу? Тоже большой вопрос. Я не знаю. Тем более я не знаю прорейд. Хотя проредит, конечно, лучше всего сказать. Рейдет должен иметь хороший поиск. Ой, очень важно. Да, там по если ты за каналами не следишь, регулярно, да, надо искать. Я знаешь что про поиск хотел сказать? Мы чуть-чуть вот, если отматывай назад, когда мы с тобой говорили про ранжирование и вот эти все факторы, есть одна вещь, которую просто хочется людям рассказать. Я уверен, что ты с этим тоже сталкивался. Ребят, для тех, кто не помнит или не знает, или не застал, когда придумывалась вот эта вся история в htмле, там появились метотеги. Давайте типа все здорово будем писать title name и desрипtion. Что произошло, как только это появилось, буквально моментально все начали искать парнуху и всё с этим связанное. И вебмастера на тот момент это они этим занимались. Все у специалистов как таковых не было. Они такие: "О, смотрите, как классно". Если мы в метатегах вместо того, что мы продаём станки, будем писать там порно и все слова, которые туда входят, то мы очень здорово вместо тысячи просмотров в месяц поиски будем получать миллион. Ну ладно, миллион тогда, наверное ещё не было таких объёмов. Но в общем, они это очень быстро эту штуку заэксплуатировали до такой степени, что она стала неюзабельная. И если не ошибаюсь, это первый придумали Google. По крайней мере массово внедрили page, то есть вот эту концепцию индекса цитирования, как в научной среде, которая резко перевернула поиск и на с тех пор стала гегемонией, как в плане подхода к ранжированию в интернете на многие десятки лет. Да, сейчас, конечно, гораздо всё сложнее, но что добавление этих высокочастотных слов или слов из других из других тем довольно часто приводит к повышению не тех метрик, которые ждёт бизнес. Он приводит к повышению каких-то какого-то трафика дополнительного. Ну, если бы не было вот этих противодействий, да. Но этот трафик он бесполезный. Ну, придут эти люди на сайт, увидят, что они не пришли не туда, куда, в общем-то, хотели. Вот. И зачем это нужно? Значит, в этом плане довольно мало пользы. У меня вот есть там сайт, где продаются книжки, а, и на нём супер маленький трафик. Это хорошо, потому что из него существенная часть людей, э, приходящих на этот сайт, покупают книги, потому что они туда приходят покупать книги. Не просто их принесло ветром, а они такие: "О, книжка по поиску. А что же я раньше об этом не думал?" Нет, он так не работает. То есть они приходят туда, потому что они искали это, и они туда пришли и купили. Наверное, если бы я как-то вкладывался в SEO, зачем мне это надо, я не знаю. Это не коммерческий, правда, проект. Вот. Но тем не менее, если бы я вкладывался, мне бы туда приходило бы в 10 раз, в 100 раз больше людей, наверное, бы продажа бы больше. Это как раз-таки тех, кого принесло ветром. Такое вот, кстати, довольно часто бывает в Фейсбуке. Мне Facebook как-то что-то включается. Он начинает мои посты показывать людям, которые вообще снаружи мовик круга. Вот. И я там получаю к комментариям комментарии к постам типа: "Ой, как это мне показалось, а почему я тут?" Ну и так далее. Ну да, это нормально. Они, кстати, иногда то экспериментируют, то, что Хотел, кстати, сразу сказать, вот мы частично затронули тему SEO. Я просто буду делать отдельное видео, прямо посвящённое SEO. Это тема мне очень близкая, очень важная. И существует такое предубеждение, что SEO - это обязательно про обман. Нет, это не так. Несмотря на то, что, конечно же, любой сешник сделает любую штуку, чтобы сайт вывести наверх, при этом осмыслено, да, чтобы это приносило прибыль. Но в целом SEO - это важная вещь для почти любого бизнеса. Поэтому мы это отдельно проговорим. А по поводу фейсбука знаешь, вот несмотря на то, что приходят левые люди, как правило, чем дальше от твоего круга, тем больше странных личностей и вопросов из серии типа что за фигню я увидел? Но с другой стороны, мы ты здесь благодаря алгоритму Фейсбука, потому что именно он показал когда-то твой пост, мне он показался интересным. Я, по-моему, что-то прокомментировал, потом казалось, что у нас Я просто вижу, что ты там, наверное с Димой Волошным знаком. Ну и вообще в целом общий круг, да, какой-то большой оказался. И я такой: "Вот вот прикольно, значит, есть свои люди". Тем более мы на восточном побережье живём. У нас тут такой свой тусняк формируется, знаешь, вдоль вдоль берега. А вот поэтому в каком-то смысле это хорошо получается. А ну что, ребят, у нас такая была как бы вступительная скорее часть вообще в целом про поиск. И сейчас мы переходим ко второй части нашего, так сказать, повествования. Поговорим прямо реально про то, как это всё устроено, что из себя представляет поиск на более низком уровне. Это будет, ну, я надеюсь, что у нас это будет так весело, потому что мы сейчас будем какие-то технические детали говорить. Но в любом случае мы просто поговорим про то, как это устроено, для того, чтобы понимать, из чего вообще поиск состоит. Давай немножко про терминологию поговорим, потому что вообще, что значит полнотекстовый поиск? Есть ещё фасетный поиск. Люди не всегда там понимают ещё, может быть, какие-то типы поиска, про которые ты хочешь сказать, чтобы вот люди понимали, о чём вообще речь, да? Ну да. Начнём с того, что такое релевантность, да? Если по если человек если мы говорим про поисковую системы и он вводит какой-то запрос, он ожидает увидеть какие-то документы, которые с его точки зрения релевантные запросы и либо с точки зрения бизнеса. И это первая большая проблема в том, что нужно хорошо определить, что это такое релевантность. Если мы говорим, что релевантны документ релевантен запросу тогда, когда у него есть клю те же самые слова и запросы, то мы попадаем в поиск версии, я не знаю, начало 2000ных годов, девяностых годов, вообще эта вся система семидесятых идёт. И это на inverted index. Это тогда, когда есть по сути база данных, говорящий о том, что вот у этого документа есть вот эти ключевые слова. И почему он инве? Потому что оно вывернута на изнанку. Если человек ищет по трём ключевым словам, то по что поисковости сделает? Она ищет все документы первого слова, а все документы ко второму слову и все документы по третьему слову. Потом эти все три множества, если они соединены end, да, то есть первое пересечение смотреет, да, это самое базовое. И на этом принципе работает. На нём сверху сделан Solar Elastic Search, но там в качестве платформы используется. Кроме этого подхода есть ещё другие подходы к поиску. Мы сегодня их будем затрагивать очень неоднократно. Но вообще, если смотреть с точки зрения теории, то вот этот вот inverted indкс - это прямо базабаза, но он выдаёт, по сути, несортированные массивы найденных документов. И чтобы их отсортировать правильно в нужном порядке, ну, по сути, они там сортируются по в начале до того, как они пересекаются. Вот. А нужна какая-то формула, говорящая о том, что вот этот документ более ценен и более релевантен, чем вон тот документ. Ну, есть для этого формула TF, ADF, term frequency, inverted document frequency, есть BM25 - это best matching 25, отдельная формула. Об этом тоже можно немножко поговорить. Значит, есть другие там разные формулы, там есть отдельный стерхлет, там отдельная большая тема, каким образом ранжируются документы, но главное, что они вытаскиваются именно по ключевым словам. Дальше, второй подход, а, совсем другой алгоритм, который почти никто не знает. Он использовался в бинге. Ну, скорее всего, не используется, потому что об этом уже никто не говорит очень давно. Скорее всего, Бин перешёл уже на другие механизмы. Но вот этот второй подход назывался Bit Fernal, и о нём почти никто не знает. Смысл в нём в том, что, э, там для каждого документа по сути делается fфingerprint из из битов. И, да, каждый бит отвечает за то, если бы этот fingerprint был бесконечного размера, то он бы отвечал за наличие того или иного слова в этом документе. Вот. Но поскольку fingerprint должен быть какой-то короткий, то там делается сначала хэш, а потом этот хэш уже преобразуется вот такую битовую маску. И там смысл в том, что когда ты ищешь какое-то слово, то у тебя просто выбираются документы с установленным битом в том-то ином месте. Там тоже получа получается inverted, то есть там, по сути, для каждого слова есть набор битов, отвечающих за документы. И когда ты ищешь по трём словам, то по сути происходит очень быстрая операция, объединение вот этих битовых масок вместе и быстрое нахождение кандидатов для поиска. Прости, мне это напоминает фильтр Блума? Да, это и есть очень быстры Блума. А по сути так же, как и в фильтре Блума, эта штука подаёт fфies, да? То есть те, которые и чем меньше этот этот размер этого фигрпнта, тем больше вероятность, что будут false positives. Но зато она отсекает все те документы, которых которых точно нету этих слов. Я реализовывал такой поиск, но он чисто в академических целях. Реально ничего большого на нём не построишь. Есть отдельная ещё третья тема, как делают поиски - это через вектор. И по большому счёту вот эти три, ну, там ещё есть сплейд, которые можно, в принципе, как-то рядом ещё поставить. Вот. Но третий - это через векторы. То есть мы там смысл в том, что для каждого из документов строится вектор и затем для quy строится вектор и либо один, либо много, либо документов один или много. И затем отыскиваются документы, которые ближе всего находятся к этому вектору. В этом вот пространстве такая вот вселенная со звёздами, да, и каждая звезда там находится в своём месте не просто так, потому что какие-то концепции, там ключевые слова либо концепции, э, двигают её к этому месту. Таким образом, документы с близкими концепциями находятся очень близко к другу. Документы с разными концепциями находятся далеко. И когда ты quy закидываешь, то она тоже превращается в такую звёздочку и смотрит вокруг себя в шаре там какие другие попадают. И вот эти другие есть результаты поиска. Их можно отсортировать по дальности от этой точки. Звучит, кстати, как очень много данных. Может быть, мне показалось для формирования такой системы. Ну, ну зависит. Во-первых, сам вектор может быть разной размерности. По сути, он может быть любой размерности. Там размерность, она определяет количество латентных характеристик у этого документа. А почему они латентные? Потому что ты их не можешь объяснить. Они в процессе обучения выставляются в некоторое сложно переводимое сложно интерпретируемое, точнее вообще неинтерпретимое значение. Значит, и вот чем больше этих размерностей у вектора, тем больше вещей в них заложено. Ну, к примеру, если у тебя есть в индексе документы, кулинарные рецепты и документация на космические корабли и больше ничего. Вот если у тебя такой калинарные рецепты и космические корабли, то в случае вектора с условно двумя размерностями очень вероятно, что это примерно поделит эти документы вот на две кучки. Если мы берём более сложную схему, что там не только эти две темы, а ещё 50 других их сложно как-то замапить на некоторые реальные темы, то в случае птидесяти размерностей, может быть темы тоже замататся. Но в реальных документах таких тем потенциально тысячи, миллионы, я не знаю, их очень сложно выти вычленить, а вот количество размерности ограничено, поэтому система сама уже выбирает, каким образом вот в этот вот в этот про разнообразие, да, но данных там не так уж много. А тут есть, кстати, хорошая, я давно с этой темой сталкиваюсь. Тут хорошая история, мне было интересно с ней разобраться. И я думала, а вот что можно взять такое, в чём можно поэкспериментировать и при этом была бы какая-то польза. И меня принесло в библиотеку конгресса когда-то есть такой художник Норман Роквел. Мне он нравится. Я хотел посмотреть на set evening пост на реальные журналы, на реальные журналы в библиотеке Конгресса. Ну, США это такая самая большая библиотека в мире. Там очень красивый зал. И, э, чтобы туда попасть, оказывается, нужно просто пойти и получить членский билет. Это занимает полчаса. Никто об этом почему-то не знает. Все смотрят на этот зал сверху с туристической площадки. Вот. А так можно пойти взять этот билет. И мы пошли, взяли, прошли внутрь, получили этот архив этого журнала. И мне он понравился, потому что его нет в цифровом виде. Его нету в виде срчу вообще ни в каком виде. А там 100 лет 100 лет выпусков каждую субботу. И я написал письмо просто на инфо. Ребята, я тут собираюсь сделать поиск. Может, вы мне дадите архив. А написал письмо и обнаружил, что на самом деле его купить можно архив доступ к ПDФам за там условно 9 долларов в месяц, что-то такое. Я купил, конечно, доступ. И тут мне ещё отвечает технический директор оттуда на это инфописьмо. Типа без проблем, давай. Ну я говорю, ничего, если я у вас скачаю PDF, вот они лежат. На что он мне ответил: "А что их можно скачать?" Я говорю: "Ну, конечно, вот смотрите, у вас просмотрщик запускается. Вот если в браузере открыть вкладку, то видно, что там идёт обращение к S3 на эти пдифы". Он говорит: "Ну, скачивай". Я выкачал, значит, все эти PDФы за 100 лет. Дальше я сделал к нему серку простую на тероформе, которая вытаскивает текст оттуда и получил куча текстов, которых никогда не существовало в а в электронном виде. Их никто не да в цифровом. Значит, и дальше я на неё очень много экспериментировал. Я сделал там и векторный поиск, и обычный поиск, и гибридный поиск, и объединял это всё и и пытался находить близкие документы. И вот векторный поиск я делал тогда на Файсе. Это один из это давно уже было, но как бы сейчас уже другие технологии. Сейчас квадрант есть хороший для вас. Вот можно в соларе легко используя и расширение Солера хранить векторы. Это уже потом. А тогда я начинал всё сси. Я там с чем столкнулся? С тем, что когда ты запускаешь индексацию на обычном CPU, у меня тогда не было GPU, сейчас есть, но вот тогда ещё не было. Значит, и я запускаю на CPU индексацию, иду спать. С утра просыпаюсь и вижу, что скорость обработки новых текстов и записи их в базу настолько медленная, что это уже никуда не годится. Она просто там, если вначале она довольно быстро делала вектора и записывала базу, то к утру она уже там, не знаю, по минуте делает на каждой на каждую страницу журнала. И я понял, что у меня ещё столько обрабатывать, что это вообще не не вказ никакой. Но потом выяснилось то, что кроме этого Фаиса есть очень много других инструментов, что там есть, кроме этого большие ограничения в ты можешь искать по фильтру Погоду, например, или по номеру журнала, а потом внутри этой кучки искать по по вектора. Я перешёл на Сол и Солоры там уже всё очень хорошо, быстро проиндексировалось за 100 лет и прямо радость. Ну, смотри, мы с тобой говорили, по сути, обратный индекс, у нас есть слово и все документы, которые в него входят. Дальше мы ищем пересечение. Это то, что мы называем полнотекстным поиском. Тут, конечно, ещё включается история там с падежами и всем остальным. Мы чуть попозже про это поговорим. Лимизация там, вот это всё. А есть же ещё фасетный поиск. Когда у тебя идёт поиск по параметрам. Это не поиск. Фасетный поиск. То, что ты называешь фасетным поиском - это, по сути, база данных. Solar и вместе это, по сути комбинация inverted index и обычной базы данных. Угу. А и фасеты - это, по сути, просто уникальные значения выборки из базы данных по каждому из полей. То есть выбираешь, например, все документы, имеющие слово ABC, и у этого документа есть пять полей. И вот уникальное значение каждой из пяти полип это есть фасеты. Это не имеет отношения к поиску, это имеет отношение к базе данных. По сути это уникальное значение поле. Я почему про это говорю и подчёркиваю внимание? Знаешь, с чем это связано? Вот в моей личной практике я очень часто сталкивался со следующим. То есть, несмотря на то, что с точки зрения алгоритмов и имплементации это действительно просто параметры, которые соединяются, ты можешь это в базе сделать, всё-таки на практике у тебя это интегрировано в поисковые движки. То есть у тебя и Solar это делает, у тебя Elastic Search это делает и так далее. Я просто почему про это говорю, я сталкивался именно с таким мнением. Я говорю, ребята делают опять же интернет-магазины, да, у них же там по параметрам у тебя миллиарды параметров, и они пытаются реально делать эту часть по базе, у них это тормозит. И я говорю: "Ребята, ну это же это же делает". Например, тот же самый Ластик. Они говорят: "Ну, он же полнотекстовый поиск". Я говорю: "Он, конечно, полнотекстовый, но там есть фасеты, которые то же самое реализуют, и это будет быстро". И поэтому я хотел это проговорить, просто чтобы люди это понимали. То есть, да, технически это не поиск, но оно там внутри лежит и ускоряет вам, собственно, поиск. Да, надо понимать, что и обычная реляционная база данных, ино sequel базы данных - это софт, решающий совсем разные задачи, хотя и то, и другое баз данных. И у носик очень высокая производительность, при том, что он имеет меньшие возможности там джоинов и прочее, да. И когда джойны не нужны, но сиквел, не знаю, в 100 раз быстрее. И поэтому, когда делается поиск, поиск по сути можно сделать на обычной на сиквел базе дан пока не дело не доходит до полнотекстового. То есть вот просто по ключевым словам никто не мешает сделать тот же inverted индекс в обычной на сиquл базе данных. То естьдеешь отдельную таблицу Token Words, там, не знаю, как-то так, отдельную таблицу documents и хранишь в списки и связка просто или прямо ты предлагаешь списком вкладывать. Я, конечно, это не будет работать на больших объёмах, это будет просто демонстрация, что это, в принципе, можно, но это всё равно будет быстрее, чем то же самое на реляционных базах. Хотя, конечно, реляционные базы сейчас прогрессируют. Все, конечно, понимают, что вот этого нет, но там берёшь, например, тот же Постгрес или Oracle и полнотекствый там уже не тот, который был там типа 10 лет назад. Ну, там ПГ вектор есть, который по сути имплементирует его. Да. Я просто чему мы его реально используем. То есть вот у нас поиск курсов есть на сайте, и всё-таки там нету полнотекстого поиска. В этом смы обычно пишут git, Typeescript там и так далее. Поэтому в нашем случае эта интегрированная система, она максимально простая, мы довольны. И, конечно же, хотелось бы поумнее, но, знаешь, такой баланс между сложностью имплементации и тем, что она даёт, что надо, мы такие: "О'кей, нас это устраивает". Да. Вот есть ещё какая тема, что вот эта вся базовая механика поисковых машин, она не знает ничего про языки, да? Она как бы принимает себя, в ней немного используются некоторые лингвистические законы, но в целом она ничего не знает про языке из коробки. Вот базовая, и к ней уже сверху прилепливают всякую лингвистику и и понимание, как это всё устроено. И вот, например, одна из тем, является ли позиция слова в документе и позиция слова в запросе важным или это просто мешок слов? То есть, если это мешок слов и они как угодно могут быть перетасованы и там, и там, то это вот прямо базовый реализация inverted index. Но как только появляется важность позиции, когда прилагательные существительные находятся, даже неизвестно, что это прилагательное существенно, а важно, что они просто находятся в определённой последовательности друг относительно друга, то поиск значительно становится лучше, потому что если ты хотя бы тот же последовательность ищешь в документах, то уже хорошо, да, и тут появляются уже разнообразные факторы proximity слов между собой и их порядка, да, и близости к началу документа. Кстати, ведь тоже такой фактор есть. Близость к началу документа тоже, хотя там в классических формулах этого нет. Могу прямо пример назвать, который для меня суперкритичный. Вот представь, у нас вот поиск курсов по программированию. Почти в каждом курсе, в каждой программе, которую учит, например, PHP-разработчик, Java разработчик, у тебя есть тема про Git. И приходит человек в каталог и ищет гиit. Знаешь, что получается? У тебя показываются просто практически все курсы, в которых есть гит. При этом у тебя есть отдельный курс, который так и называется, гит. И поэтому там нету близости слов. Там вопрос исключительно в том, что он где-то либо в заголовке, либо в подзаголовке. Поэтому у тебя очень важно вот этот приоритет, без которого, ну, нету способа показать его выше. Обычно обычно близость сначала документа формула не входит, но зато, например, увеличение веса тех или иных полей, например, description или title, сильно улучшает. Значит, если весь документ прод, то с большой вероятностью этот гит будет находиться в тайтле. Ну, так устроено, значит, вот. И если это так, то этот документ должен быть сильно выше в поиске, чем документ, в котором этого гита очень многого по тексту, но нету стаки там. На самом деле там та же самая BM25 формула, она более вот, в отличие от базовой, она две вещи пока добавляет. Она saturation добавляет на количество упоминаний. То есть ведь и без этого, если у тебя слово гит используется 100 раз в одном документе и 80 в другом, то обычная там стандартная формула говорит, что тот, где у тебя 100 раз используется, наверное, более релевантный. Хотя 100 от 80 отличие не очень большое. Вот. А и реальная жизнь говорит, что ты спамер. Да. Вот. А зато если мы сравниваем, например, документ с одним упоминанием и с пятью упоминаниями, там уже разница, казалось бы, там абсолютная даже меньше. Вот. На самом деле это более высокое, поэтому это первое - это там используется логарифм от этого, и второе используется длина документа. То есть если у тебя документ очень длинный, то большой вероятностью там просто все слова будут встречаться. Ну не все, ну как бы очень многие слова, которые не имеют отношения к теме документов. Просто за счёт того, что он длинный и там много чего есть. И мы не хотим такие документы иметь в самом верху просто потому что в нём есть эти слова. Есть фактор, который уменьшает важность документа и матча, если документ длинный. А пару слов про Итент можно, наверное, сказать, потому что это это уже более сложная тема. Она, наверное, не касается внутреннего поиска, а касается, допустим, поиска на том же Яндексе. Для меня вот как человек, который занимается там SEO и для бизнеса, да, у тебя, например, есть DevOPS, вот у меня есть курс, а есть статья про DevOPS, да? И очень важно, что когда человек пишет купить DevOps курс, ему попадался соответствующая, э, ну, коммерческая страничка. Это называется коммерческий запрос. А если он хочет узнать, что такое devops, то ему должна попадаться статья собственность информации об этом. И вот эта штука, она очень часто, э, недостаточна по словам. И поисковики, они же прямо определяют твой интент и дальше понимают, что поиск нужно вести по, ну, это уже, кстати, получается просто осужение выборки, да? То есть, например, локальные бизнесы. Если ты стеклопакет хочешь поставить, тебе, очевидно, нужен локальный бизнес и тебе нужна коммерческая страничка. Здесь много есть посов, как это делается. Но, во-первых, query formulation, то есть поиск идёт по одному, а реальный запрос, который идёт в поисковую систему, он другой, более широкий. Угу. Второе. При индексации документа добавляются новые ключевые слова, которые с точки зрения некоторого умного механизма лучше отражают этот документ. Но этих ключевых слов в оригинальном документе не было, они вообще- это нужны. По сути, это концепс, да, то, что добавляется. И тут можно вспомнить сплей, например, да, это вторая версия сплейда. Она это это дополнительный алгоритм, который вешается поверх стандартного индекса, и он просто инжектит небольшое количество слов из общего фиксированного словаря. А прифаиваем некоторые веса, что вот эти слова лучше отражают матику документа. И среди этих слов могут быть слова, которых не было в документе. Если их ищут, то этот документ будет повыше. Значит, ну, минус там в том, что там словарь ограниченный, и какой бы там его не выбрал, он ограниченный. Всякие айдишники товаров туда сложно бесконечно добавлять. И третий подход - это как раз векторный. Это когда используется трансформерная архитектура и преобразуются векторы по семантике, по по смыслу. И когда ты ищешь что-нибудь по смыслу купить курс, то он может оказаться близко к документу, продающему курс. Потому что и то, и другое находятся вот в этом пространстве звёзд вот вот ближе друг дружку, чем к чему-то ещё. Вот, в принципе, эти три подхода к reformulation, обогащение, обогащение ключевыми словами, да, и и векторы самые распространённые. Но правильное, конечно, решение - это не выбрать один из этих трёх, а использовать все три, а и смешивать смешивать результаты. У, ну, поисковики там, там уже включается бизнесовая история, типа один сайт больше одного раза там не показывать и так далее. У них много своих как бы задач, которые они решают. А в конце концов вообще показать только рекламу, а сайты не показывать. Там, на самом деле, много гораздо. Там, напервых диверси есть. А, и когда у тебя поиск приносит какие-то результаты, то важно, чтобы эти результаты были максимально разные, и это противоречит релевантности. Потому что с точки зрения релевантности надо показывать вот этот набор, но этот набор не div, и у тебя всё в нём одно и тоже. Аверс - это когда ты из него вытаскиваешь наиболее показательный документ и из другого набора, который тоже релевантны, немножко дальше берёшь показательный элемент, ставишь дупподушкой. И вот пользователь видит на на главной странице гугловского поиска, что на его запрос есть самые разные взгляды на этот. Причём забавно, что там вплоть до ручного управления, помнишь, когда утекали, периодически же утекали, а у Яндекса была большая утечка, когда алгоритмы кто-то выложил и потом их много там сильно анализировали, там прямо поля увидели, например, что статья на Википедии должна показываться там на первом месте по информационному запросу, там по этой тематике. Это, ну, это все догадывались, как бы до этого, но теперь это увидели в коде. Но есть, смотри, а пожран к этому всему какое имеет отношение? В том плане, что как будто бы он тоже здесь появляется, если его учитывают. Ну, во-первых, никто из нас не знает, как работает конкретная поисковая система сейчас. В лучшем случае мы знаем, как она работала лет 10 назад, когда там были какие-то утечки, да. Вот. Во-вторых, Page Rank по сути строит граф связей и показывает и увеличивает вероятность помещения страницы в результаты поиск повыше. Если на эту страницу имеют много внешних ссылок, значит она из из не просто внешних ссылок, а из внешних ссылок из авторитетных источников той же темы, да? Вот это довольно сложный механизм. И главное, что мешает всем поисковым системам быть лучше - это то, что один и тот же список нельзя отсортировать тремя способами одновременно. Ты не можешь, это multictive получается, да? То есть ты не можешь отсортировать его одновременно по релевантности, одновременно по желанию бизнеса продать там какой-нибудь товар и одновременно по прибыли от этого товара. Ты можешь либо составить ещё один, четвёртый критерий, который будет объединять эти три с весами, но с большой вероятностью ты получишь месиво сложно объясняемое, почему оно такое. Если у тебя всего три веса, то там и три вот этих вот, то это ещё куда не шло, можно как-то объяснить. Но даже и с этим появляются очень странные штуки, которые совершенно расходятся с ожиданиями. Вот. И вот это самая большая проблема с поисковыми системами, что ты не можешь по сути учесть все критерии. И если ты их пытаешься учитывать с весами и прочим, то у тебя будет очень много того, что ты не хотел делать, но ты не можешь этого избежать. Ты не можешь, создав такую формулу с весами, получить всегда хороший поиск. У тебя будет где-то он хороший, а где-то нехороший. Ну не знаю, это сложно объяснить, наверное. Нет, это на практике очень часто происходит, потому что опять же, как человек, который занимается SEO, у тебя есть контроль же, каким образом в том числе делается. У тебя, а, есть по разным направлениям примерное понимание, что такое хорошая выдача, да, и есть сравнение в каком-то смысле с эталоном. А то, что факторов тысячи, ну, это правда, это как бы никто не скрывает. Там у тебя доверенно время жизни этого хоста, доверенность, э, есть у тебя там сертификат, сколько у тебя страничка грузится, поведенческие факторы и так далее. Но эта уже тема, кстати, а, выходит за рамки вообще в целом поиска. Это то, как устроены большие поисковые машины. Мне кажется, пример как разница между и лэмками, да, которые там вообще про всё. А в этом плане тоже хочется сказать, что вот эта тема заслуживает своего отдельного большого видео, где можно про эти факторы поговорить. Но это с людьми, которые ближе, наверное, вот туда либо мы посмотрим ещё. Кстати, я пока не знаю, как это сделать, но тут, конечно, бизнесовая часть точно имеет большое значение, потому что это касается вот в первую очередь тех, кто воздействует на этот поиск. А таких людей, ну, все, давай скажем честно, все, кто бизнес делает в интернете, на это воздействуют и пытаются с этим разобраться. Мы с тобой уже начали цеплять вот историю, когда мы говорили про обратный индекс, что если ты просто слова сделаешь, ну, допустим, засунешь туда слово хороший, а ещё есть слово хорошо и так далее, и так далее, и тут мы приходим к понятиям, что у нас есть, господи, я даже немножко забыл их название. У нас есть леммы, у нас есть, э, стеминг, у нас есть всякие стопслова, нормализация, такинизация и так далее. Давай вот как-то вот это всё чуть-чуть объясним и приведём в некую систему. Это, да, это всё довольно легко объяснить. Во-первых, здесь это то, где появляется лингвистика, то есть то, где появляется необходимость учитывать особенности языка, на котором ещё что-нибудь, да, в поиске. И стеминг - это особенность некоторых языков. Разграничивать важность начала или там середины слова, корня, а, и всего остального, приставки, окончания и прочее. И если это, во-первых, свойственно не всем языкам, а только их части, ну, например, русскому это свойственно, и мы можем хороший от хорошего отличить просто по окончанию, но по сути это одно и то же, да, вот то есть смысл корни один и тот же. И здесь стеминг помогает, он откидывает конец. Но, например, у стеминга есть много ситуаций в языках, где он не идеально работает. Он всё равно лучше, чем без него часто. Но когда его включаешь, начинаешь видеть эту ситуацию, не понимаешь, что с ними делать. Например, есть University и Universal, да? И а оба э слова имеют один и тот же корень, который по сути ничего не обозначает. Если ты откидываешь окончание, ты начинаешь на слово универal искать документ со словом University. Такие исключения в разных языках имеют разный масштаб, но они существуют и ничего с ними не поделаешь. Стминг не не принимает эти исключения во внимания. Там нет никакого словаря, слов, которые не надо так делать. Вот. Значит, есть алгоритмы стемингов. В целом, они очень быстрые, очень легко реализуются. И по сути, как они работают? При индексации документа откидываются все окончания, при запросе откидываются все окончания. И вот то, что там в индексе теперь есть даже слова на слова не похожие, да, они мачатся с со словами, которые остаются после обрубания окончаний. от QY. И они без словаря работают. Они работают без словаря, но они работают на правилах свойственных языку. Каждого языка свой свои алгоритмы сминга. Они очень быстрые, потому что правило очень легко формулируются. Если у тебя есть такое окончание, отбрасывай. Если у тебя есть Серьёзно? Это надёжно работает без словаря, то есть прямо вот Хорошо. Здесь вопрос, что значит надёжно? Потому что это, скажем так, работает лучше, чем без этого, часто на этих языках. Но как только ты это включаешь, ты видишь проблемы и надо их решать. И конкретно какие проблемы надо решать, оче зависит от предметной области. Ну, например, если мы берём французский язык, ну, во-первых, это, как я уже говорил, в каждом языке своё, какой-нибудь японский, корейский, китайский, вообще никакого сминга в принципе туда не применить. Это понятно, почему, да? Там даже пробелов нет. Значит, если мы говорим про, например, французский язык, то там есть сокращения, которые, с одной стороны можно откинуть, потому что они не особо нужны. С другой стороны, всё-таки, если документ встречается с этими сокращениями, там, не знаю, репорт, да, л апостроф, аэропорт, да, то есть вот у тебя ты можешь убрать это апостроф, потому что это по сути артикуль он не нужен. Но если ты будешь сокращать таким же образом и слова, то во французском языке у тебя будет больше больше сложности. Там есть тоже свойстминг. А вот есть ещё лиматизация. Это уже отдельная тема. А она уже более вычислительно дорогая, потому что требует использования словарей, даже иногда и неростевых моделей для того, чтобы лучше преобразовывать и лучше откидывать, лучше преобразовывать в нормальную форму. Ну, разница только в потреблении ресурсов. В случае лиматизации результаты могут быть лучше, но поиск может быть медленнее. А с точки зрения результата, что в индексе окажется? То есть, например, вот мы говорили там про какое-нибудь слово город, допустим, да? Вот стеминг до слова город и обрежет. А примизации то же самое в итоге получится конкретно для этого слова или как-то по-другому? На самом деле там очень по-разному делаются. Нет никакого одного подхода. Например, есть в Caveo работает так: если ты ищешь в Caveo любое слово universal, то в индексе у тебя всё равно будет, как там было University, так он там и остаётся University. Он не преобразуется ни в какие короткие слова, но при запросе у тебя происходит query expansion, то есть на слово universal у тебя формируется 30 слов и имеющих так с обратной стороны подход, короче, кожи начала, но с разными, да, с обратной стороны подход. То есть, а если причём из этих тридцати сгенерированных слов конкретно в Ковело очень криво, у них 80% этих слов не существует. Они генерации по какому-то алгоритму стандартному. Вот у тебя есть куча окончаний, куча кат просто склеиваешь и получаешь всё получаешь. И, ну, из-за того, что слова несуществующие, они как-то не особо и влияют на поиск. Они же не существующие, на то не существующие. Вот зато некоторые из них существующие. И вот они выдают документы с изменениями. То есть вообще все эти штуки надо понимать, это просто кирпичики building blocks. Их берёшь и делаешь по с ними вместе какой-то поиск. Вот поэтому там в том же Соларе делаются комбинации фильтров с такинизацией- это с разбиением слова на составляющие. И дальше уже идут синонимы, дальше идут стопслова, дальше идёт и лиматизация и всё такое. То есть это всё конструируешь под конкретный датсет, под конкретную задачу. Нет такого, что из коробки прямо да и знаешь, мне идея пришла в голову. Скажи, вот существует такое или нет, я сейчас такой, пока тебя слушал, думаю: "О, может быть, я придумал идею, которая 100% реализована". То есть, допустим, у нас есть предложение, нам нужно делать поиск, что мы не пытаемся комбинации искать, а мы именно делаем такую систему с двух сторон. То есть мы нормализуем все слова в индексе и при этом, когда делается запрос, мы тоже нормализуем все слова. И получается, что мы всегда ищем по нормальным формам. Есть такой подход или? Ну да, это же это стандартный как раз и есть по так и делается. Минус в этом в том, что когда ты нормализуешь при индексации, ты теряешь оригинальную форму. А оригинальная форма, она очень полезна, когда ты ищешь, например, по полному совпадению. Вот у тебя есть э запрос из пяти слов, большая красная шляпа. И после того, как ты его закинул, она у тебя может его нормализовать большая в большой, больше, там, я не знаю, как-то будет так. И сработает очень много документов, в которых есть эти три слова в разных листах разброшенные. И как системе надо каким-то образом понять, что вот этот документ, в котором есть большая красная шляпа ровно в таком же виде, как ты её написал в Кerри, этот документ должен быть повыше. Ну, в сам веху, наверное, да? То есть потому что в нём есть полный ч. Но как она это поймёт? Во-первых, для обратного индекса уже хорошо, что в расширенной его версии есть позиция слов. То есть в целом, если есть позиция слов, то система может понять, что три слова в запросе идут последовательно в документе уже. Хорошо. Но как понять, что они в той же самой форме идут? Потому что после этой обрезки там может быть совсем всё разное, но если для этого тебе нужно оригинальный текст всё-таки иметь. Угу. Поэтому, да, есть варианты, например, один из вариантов хранить секс два раза. Первый - это в оригинальном варианте, второй - это вот в обрезанном варианте. И искать и там, и там, и контрибьютить в общих спор, и как тогда у тебя документ будет выше, если есть полный матч. А если нет полного матча, то уж будет как будет, да. Вот. Ну, в конечном итоге это всё влияет на размер индекса, то есть напихать-то туда всё, что угодно можно. Да. Да. Да. Более того, если, например, делаешь и он ещё будет допридумывать слова из этой же темы через их модель, которая будет обрабатывать там, по сути трансформер, который убирает слово из предложения и смотрит, какие другие слова в этом месте были бы контекстно правильны. И на основе вот этого этой обработки целого документа он формирует те слова, которые, в общем-то, очень релевантны в этом контексте, но их почему-то нет в документе. Звучит как LLM. А это очень близкая тема. Там используется Берт и Берт тоже трансформер. LM тоже трансформер. И и там и там идёт расчёт весов в зависимости от того, какие слова у тебя вокруг тебя. Есть разные тонкости. Можем в них углубиться, но я боюсь, что мы отойдём от главной темы. Значит, и вот эта штука, она позволяет обогащать словами, но в отличие от Лэма, а она позволяет объяснить, почему этот документ выше. Потому что обогащённые слова есть в индексе, вот они лежат, и поэтому этот документ выше. Это интерпретируемость очень, очень большой плюс даёт, потому что очень многие другие модели, например, там векторные поиска, он он интерпретируемость не даёт. Он говорит, что документ высоко и всё. Угу. уже упоминал, но не могу не сказать. Вот есть два момента ещё, которые осталось, мне кажется, разобрать. Синонимы и опечатки, да? Значит, с опечатками давай начнём с них. Это проще всего. Есть такая штука, как дистанция по Левельштейну. Это расстояние между двумя текстами, которое определяется числом действий, которые можно предпринять буквами, поменять их местами или вставить или убрать, чтобы преобразовать текст А в текст Б. Угу. И когда мы говорим про опечатки, то вот этот механизм может быть использован, потому что это так работает фаза match. Это ты можешь найти те слова, которые близко находятся к искомому. Вторая штука с опечатками, которую я делал, и мне кажется она очень интересная, это когда, по сути, ты генериешь все возможные формы опечаток, ищешь все слова с этими опечатками в докумен в индексе заранее и делаешь гипотезой, что, наверное, вот на основе собранной статистики, у тебя получается очень много данных, на основе собранной статистики делаешь гипотезы, что, наверное, вот это слово, оно уже в самих данных часто искажается вот так, так и так. Из всех возможных искажений этого слова, ну, можешь себе представить, как может исказить слово университи все возможные буквы А не звучит как безумие вообще, да? Но тут ты используешь данные из реального там корпуса в миллионы. Вот, и говоришь, что вот чаще всего это слово ошибаются вот так. И затем, когда ты ищешь любое из ошибочных слов, система понимает, что нужно ещё добавить вот эти остальные, потому что именно так ошибаются люди. Вот это можно делать, обработав сами queries исторические, можно делать обработав сами документы, потому что в документах тоже ошибаются. И ещё с отпечатками нужно быть аккуратнее, потому что там не всегда слова есть слова английского языка, например, есть SK. И если продуктовое SK написать немножко неправильно, не совсем не факт, что это опечатка правильная. Это может быть просто. Ну да, да. Сокращения ещё всякие похожие на слова, это вообще отдельная история, там контекст нужен. Это уже сильно умней. Я знаешь что понял? Вот когда, например, допустим, я в русской раскладке пишу слово на английском и наоборот, ну и ошибаюсь. Или вообще, в принципе, когда мы ищем это, мм, господи транслитерацию, это ближе к синонимам это или ближе к опечаткам? Потому что как будто бы и так, и так бывает. Ну, вообще, как обычно это делают, если мы не переключили регистр и написали английскими буквами то, что должно быть на русском, то получается понятно белиберда, которая, скорее всего, отсутствует в индексе и скорее всего на это слово будет ноль документов. Просто потому что статистически эти буквы не должны идти рядом. И если такое происходит, то система, в принципе, может по двум сигналам получать информацию о том, что надо обработать quy перед отправкой в поисковую систему. Первый сигнал - это в том, что идёт статистическое распределение букв, вот этих биграмм друг с другом, иное, чем оно должно быть для этого языка. И если такое происходит, это первый сигнал. Второй сигнал - это в том, что если применить к этому слову функцию преобразования в нормальный вид, у тебя получается нормальное распределение статистическое. И более того, на это слово, это слово есть в индексе. И вот если эти два сигнала совпадают, то нужно просто менять и отправлять это сразу в индекс в исправленном варианте, потому что там при вот это второе уже правило не пройдёт. А транслирация, то есть вот я на английском набрал, умные поисковики всегда её понимают, да? Значит, транслитерации, ну, в общем-то, примерно то же самое. То есть, если мы видим транслитерованный текст, то у него есть статистическое распределение грамм, свойственное транслитерованного тексту, мы можем его опознать. В принципе, это же относится к к секции языков. То есть в той же самой Сербии, например, ищет так, и так. И нужно понимать, что это нормально, что бывает и так, и так нормально. А вот, например, в России могут искать транслитерированный текст. Не знаю, просто потому что клавиатуры нет под руками и надо хоть как-то что-нибудь набрать. Поэтому, да, в этом случае опять же преобразуем, смотрим на распределение статистическое биграмм в слове, а видим, что о - это то, что нужно. Значит, наша гипотеза о том, что это транслитерованный текст правильные, преобразуем и как минимум добавляем как синоним поиски к основному тексту, потому что мало ли вдруг там транслитерованный текст тоже выдаст какие-то документы. Но это в любом случае относится уже не к индексу, то есть у нас две большие зоны, да, есть первое, понять интент, понять, что хотел набрать, как хотел набрать, на каком языке. То есть там целая эпопея с, скажем так, нормализацией запроса, если это можно так назвать. И остальное - это уже непосредственный индекс, который с этим работает. Ну вот там из Эстонии, например, можно вспомнить такую штуку. Я делал когда-то поиск для, ну, точнее анализировал поиск для большого продуктового магазина европейского в стране, в которой больше, чем один язык. Ну, это серва моя часть Европы. И понятно, что люди приходят на сайт и не переключают язык на тот, на котором они говорят, потому что они понимают и на том. Ну, например, они приходят, видят английский магазин. Ну и ладно, английский, английский, но поиск они делают на своём языке. И когда делаешь поиск по коротким словам, а гросри - это часто короткие слова, то не всегда понятно это какой язык. Ну потому что набранное недостаточно длинное для того, чтобы понять, что это за язык. Вот. И люди набирают, оно работает, оно выдаёт какие-то товары, потому что в товар, те, кто товар публикует, тоже не дураки. Они туда вставляют на нескольких языках ключевые слова. Оно всё работает. Но потом, когда начинаешь анализировать результаты поиска, происходят очень интересные штуки. Например, я сделал такой отчёт, который показывает, какие запросы пользователи делают, а потом идут и нажимают далеко от начала в результатов поиска. Понятно, что в среднем, ну, то есть некоторые нажимают начать. Интересно, где, да? Угу. Да. Но если ты обрабатываешь большой объём, то видишь то, что вот это вот распределение, оно показывает, что люди часто тыкают на пятнадцатую результат поиска. На второй странице он находится. И зачем они туда идут и туда кликают? Значит, вероятно, что начало оно не очень релевантное, и они это знают, а они к этому приспособились, и они идут на вторую страницу, ищут там то, что им нужно, и делают это каждую неделю. Поэтому у нас продажи как бы есть, но что-то не то в консерватории, надо исправлять. Начал разбираться, что это за запросы. Ну, таких много обнаружилось. И то, что сейчас быстро вспомню, например, запрос Pain. Значит, Painбираешь и тебе выдаются что? Pain killры. А, да, ну, painкиillры - это обезбалющ. Значит, вот они, значит, идут вначале, а потом этот магазин, соответственно, работал на французском и на на английском языке. Ещё, вообще-то, на французском есть слово пам - это хлеб. И он находится на второй странице. И они знают, что там пан находится. Они даже искали это патигре - это такой бельгийский хлеб. Он на второй странице, а вначале были эти пейнкиллеры. Такие же штуки там и с батарейками, и с джином, и с напитками в целом. Хороший анализ. Вот если его вот так делать, получается смотреть на как куда кликают и пытаться найти вот один вот новы. Ой, да, прико. Это очень такая точечная работа. Ну, она и муторная немножко, но, наверное, интересная тем, кто этим заморачивается и работает в таких направлениях. Мне кажется, это, знаешь, похоже. Вот мне напоминает, помнишь, было время, когда, ну, и сейчас все этим занимаются, это оптимизация рекомендательных алгоритмов, когда они уже достаточно хороши и там выжить какие-то проценты - это просто там, по-моему, Netflix устраивал какой-то конкурс, кто нам улучшит алгоритм, тому мы там миллион долларов заплатим, да, что-то такое было, да, Netflix очень сильно продвинул эту область, потому что количество пейперов, выпущенных после этого по рекомендательным алгоритмам и количество новых идей, оно просто зашкаливает. Ну, по сравнению там совсем, но с рекомендательными алгоритмами, опять же, как я говорил, это очень близко поиску. Например, если взять ту же каве поисковую систему, то она из себя представляет поиск плюс рекомендации плюс аналитика. И вот эти рекомендации они, ну, они инжектятся в поиск по сути, да, и ты ищешь, видишь результаты поиска смешанные с рекомендациями. Но вот рекомендационный движок, он основан на machine learning, по сути, на анализе аналитики, как пользователи ищут и что они находят. Если ты ищешь одно и то же слово и тыкаешь на третий документ в поиске, то, наверное, он самый релевантный, поэтому его надо рекомендовать. Да, и рекомендационных алгоритмов существует много. Ну, собственно, книжка вот эта, которую я про рекомендации, я и пытался их вместе. Когда-то давно, я помню, покупал книжку на Питоне, как раз рекомендательные алгоритмы. И первый алгоритм там, который был - это коллаборативная фильтрация. Это подозреваешь это вообще одна из первых самых тупых имплементаций этой штуки. И с тех пор мир, конечно, сильно далеко. Она очень хорошая имплементация. Она не тупая, она очень хорошая. Item KNN и User KNN очень хорошая имплементация. Проблема с ними, что они очень требовательны к ресурсам и при увеличении числа документов, там товаров или что ещё, у тебя матрица эта растёт, растёт, растёт. Она происходит очень большая. И в итоге хорошие рекомендации просто очень дорого стоят, да? То есть пользователь не будет стать. Вот есть множество других сейчас неростевые модели, очень интересные. Есть ещё рекомендации, которые учитывают контекст и историю. и другие сигналы, например, твои заказы. Я могу сказать, как мы решили проблему рекомендации у себя максимально тупым образом, который раньше решала вообще задача была руками решена. То есть у нас есть блок, в нём есть статьи, а стандартная как бы история - это в статье делаешь вставку, например, на товары, которые с ней связаны, релевантные. Раньше как это происходило? У многих это происходит, ты прямо под конкретную статью, собственно, в конкретном месте такой: "Ага, посмотрел и поставил". мы используем живую нейросетку, которая этим занимается. И мне в какой-то момент, знаешь, я просто такой думал об этом, потому что там постоянно проблема, там забывают обновлять ещё что-нибудь, но вот оно может не оптимизироваться. Я думаю, а почему бы мне не сделать очень тупую э штуку? Я просто беру список, ну, в нашем случае от курса, список всех курсов с каким-то микроскопическим описанием. Я беру саму статью и в апишку Open AI кидаю, говорю: "Подбери, пожалуйста, мне самые релевантные". Я это сделал буквально, ну что там подумаешь, пару тысяч статей. Это вообще смешная штука. В итоге он всё это при релинковал. Это классно работает, стоит дёшево. И вот всё. И я такой: "Блин, у меня после этого, знаешь, мозг заработал вот в эту сторону, где ещё я могу такие штуки применить?" И вот все эти сложные концепции, вещи, о которые мы сейчас говорим, они для локальных, может быть, проектов типа нашего, они просто теряют смысл с нейросеткой, потому что ты можешь просто бам и всё, и решил проблему. Верно. Ты же понимаешь, что рекла рекомендационные алгоритмы не только в таких простых задачах. Да, конечно, конечно. Да. И, например, если у тебя есть поток в 10.000 ивентов в секунду где-нибудь и тебе нужна быстрая модель, которая позволяет принимать решение, показывать ли этим пользователям, например, с этими ивентами какую-то рекламу, то там нет времени думать. В Да, у нас статическое решение. Оно же статья постоянная, это постоянно, а здесь динамическая. Конечно, с контентом, что касается контента, лмы очень помогают. И особенно, если это происходит на этапе подготовки данных, а не realта при запросе. Да. Да. У меня вот товарищ сделал очень клёвый прототип, и мы его показывали, точнее, он его показывал одному автомобильному гиганту, вот где я тогда как раз работал тоже с ним вместе 4 года. И и там история была о чём? что у тебя есть поиск по автомобилям ю бысшему употреблении большой каталог на 100.000 там машин значит и на этом каталоге что ищут? Ну как тебя найти нужным автомобиль? По-разному ищут. Но если мы туда вводим какую-то поисковую строчку, ну что будет человек набирать в поисковой строчке при поиске при автомобиль? Я не знаю, автомобиль для семьи красного цвета. Что ещё он может сказать? Это тип машины там SUV или не SUV, марка, объём двигателя там. Что? Да. Да. И идея в том, что когда человек формулирует запросы на поиск, а он его формулирует в своих бытовых терминах, и кто-то должен эти запросы преобразовать в чёткие запросы к базе данных. Дай нам вот такие-то автомобили с такими-то характеристиками такого-то цвета. Если он написал красный, то, наверное, можно и бордовый показывать, да? Ну, то есть вот как-то вот так. И вот тут LLM тоже очень здорово работает. И причём даже LLM не такая мощная, там типа Openi SAS, где ты платишь за каждый ток, а ты можешь поставить маленькую модельку, которая преобразует запрос в конкретный набор фильтров. Да. И главное главное, что тут даже галлюцинациям не откуда появиться, потому что ну что самое худшее может произойти? Ну какой-то фильтр не поставится, ну или поставится лишний. Ну и что? Ничего. Ну то есть безопасность стопроцентная. Ну, то есть в отличие от, например, чатиков, которые в которых можно начать спрашивать, как домашнее задание решить, и они начинают отвечать, да, вот на сайтах компании. Слушай, я знаешь сейчас сейчас что понял? А вот мы обсуждали вот запросы, слова и всё остальное, и я понял, что есть ещё один интересный класс проблемы, который мы не обсудили. Ведь вот когда люди формулируют запрос, как они могут формулировать? Дорогая, значит, поисковая машина, дай мне, пожалуйста, эти перчатки. У тебя только одно слово про смысл, а всё остальное способ с ним общаться. Пожалуйста. Ну а и подожди, ты имеешь в виду в чатике или в Не, нет, вот именно в поиске. Да, мы просто стали про элмки говорить. Я вспомнил, что такой стиль коммуникации, он тоже присущ людям в в этом в обычном поиске. Нет, совсем не присущ. Не не используют много слов, когда можно не использовать много слов. То есть, пожалуйста, не пишут, не пишут. Нет. А дело в том, что, во-первых, они не привыкли и не видели никогда, чтобы это работало. Они не успели к этому привыкнуть. Может быть, после того, как сейчас лм везде внедрятся, они начнут начнут так писать. Да. Вот. Но до недавних пор ничего такого не было, и люди, в принципе, начинали знакомиться с поиском от слов двух, трёх, четырёх, и они представляли, что только так и возможно. Значит, конечно, бывают, наверное, разные ситуации, но когда смотришь на статистику, ты не видишь такие вообще обычно блиц вопрос в эту же тему. С какого минимального размера букв поиск хоть как-то становится адекватным? Ну, искать языки го или ТС - это довольно сложно. Если ты вместо T script ts напишешь, ты ничего не найдёшь по теме. То есть у тебя, грубо говоря, есть некий минимальный набор, который, ну, как бы язык го. Вот как ты будешь его искать, если у тебя система не знает про твои, ну, предпочтения или Typeesрипt, две буквы? Мне кажется, что у тебя эти слова, буквы могут встречаться, ну, го, например, везде, абсолютно, в любом варианте. Как ему понять? Это же у тебя отдельное слово, да, go. То есть это Да, но ты ищешь конкретно язык программирования, а не го, в смысле go. Поэтому, наверное, наверное, лучше вспомнить, например, пример Сиша, который, ээ, тоже, да, шар, например, может удалиться просто потому, что, ну, это какой-то символ непонятный. Отдаётся си. Вот. А си вообще это другое. И там одна бук. А язык C. Его же невозможно найти. Я поэтому силен везде пишу, когда ищу его. Да. Да. Нет, на самом деле, возможно, но это просто уже отдельное слово да, оно частотное, потому что буква Ц мало, много где может быть. И если ты его будешь отдельно искать, у тебя выдастся миллион документов в результате. Но как только ты добавляешь туда что-то ещё, то у тебя миллион документов пересекается с, не знаю, с с 5.000ми от что-то ещё, потом ещё с чем-то ещё, и у тебя в концо выдаётся не такое уж и большое количество. То есть, в общем-то, это нету такого минимального, но оно включает всё равно необходимость немножко фантазировать. То есть ты не можешь просто набрать слово, тебе такой надо подумать: "Ага, что бы ещё какое-то дополнение набрать". Вот. Да. У меня вопрос ко всем создателям этих языков. Сразу видно, что технори, но не но не эти бизнесовые ребята, потому что как можно назвать язык GO, VC#шаarp, что там ещё? Ну их много сейчас современных из двух букв, даже из одной буквы. Ребята, это искать невозможно. Что? Остановитесь это делать. Да. Ну сейчас, на самом деле, если мы говорим про гибридный поиск, когда у тебя есть векторы, и электрический поиск вместе, то это уже небольшая проблема, потому что там идёт смесь, и у тебя те документы, которые по смыслу выше, они просто вытесняют всё остальное и находятся в самом верху. Да, ты всё равно получаешь миллион документов на выходе, но у тебя они отсортированы таким образом, что первые много страниц, они всё-таки по теме. А, и так оно должно быть. Во-вторых, поиск всегда проектируется под конкретную задачу. И думать про языки, когда ты делаешь поиск по медицинским журналам, про язык сити не надо думать. Там свои проблемы есть. Я не знаю, условно у тебя может, например, разделяться, да, тот же самый сишап, да, вот по такому же принципу у тебя иногда слова должны разделяться, иногда не должны. Они иногда они должны два слова через дефис в Сан-Франциско какой-нибудь, да? Вот они должны восприниматься как одно слово Сан-Франциско, а не делиться на Сан и Франциско, потому что тебя документов Сан и Франциско будет очень много и они вы, собственно, нужные документы берут вниз. Я, кстати, делал очень интересный фотоп, который очень хорошо работал. Его нигде почему-то никто не делает. Он очень очень клёво работает. Это когда ты делаешь документы, имеющие длинные exact match фраз, повыше. То есть, если у тебя есть запрос четырёх слов и у тебя есть документ, у которого второе и третье слово идут подряд, то этот документ будет выше документов, у которых все четыре слова разбросаны в разных местах. Чем длиннее у тебя идёт матч на фразу, тем выше документ. Вот такое простое изменение очень сильно повышает качество поиска. Но вот, например, с Каве такое изменение не работает, потому что как только ты преобразуешь длинный запрос со скобочками, с орами и так далее, у тебя кове сходит с ума от того, что о Но соло работает, например, прекрасно. Сч работает прекрасно, потому что там есть своя хорошая логика булёвая и разбор Давай поговорим немножко про качество поиска, а про его оценку и отслеживание движения. Первую часть, наверное, мы уже сказали о том, что ты в динамике можешь отслеживать, что человек искал и на каком элементе он кликнул, на какой страничке. Это скажем, статистический способ понять, что не так. А какие-то ещё другие заранее, например, посмотреть. Ну вот, собственно, откуда у меня сайт test My Search появился, это в том, что я когда-то решил сделать систему для сравнения качества поиска разных конфигураций поиска, потому что увидел, что нигде такого нет, никто так не делает почему-то. Значит, смысл в том, что у тебя есть разные конфигурации, например, там синонимы, без, стопсловами, без, ну, к примеру, хотя я и синонимы, и стопслова не читаю за хорошие инструменты. Вот. Ну, к примеру, вот есть там у тебя разные настройки, и ты хочешь понять, а у тебя поиск с настройками такими-то лучше, чем тот, который уже в плоде или нет? А вот как ты это поймёшь? Есть обычный способ прямо на живых пользователях тестировать. Давай мы запустим для 10% пользователей эту конфигурацию и посмотрим, что получится. Минус в том, что, во-первых, это требует трафика, во-вторых, это требует времени, в-третьих, это ещё и расстраивает пользователей часто. Значит, и вот это би-тестирование, оно много где есть, и его можно использовать, но вот понимая, что она расстраивает пользователей, что нужно долго ждать и что иногда даже долго ждать не помогает, потому что трафика не хватает. Значит, второй подход - это формулировать ответ на вопрос: что значит релевантность? Значит, вот у меня есть 100 запросов, и я думаю, что на 100 запросов вот эти результаты поиска обязательно должны быть на главной странице. Откуда бы я это взял? Наверное, я взял каждый из этих документов и синтезировал по нему типичные запросы и выяснил, что вот эти запросы, синтезированные из документа, они уникальные. И этот документ, он лучший, правда, лучший, который должен быть показан. Я делаю такой вот эксельчик с qy и документами, которые должны быть на главной странице. Если их несколько показывают, то если они там какая-то часть из них есть, то это уже лучше, чем меньшая часть. Вот. И дальше я провожу эти тесты. Каким образом? Я делаю запрос, получаю результаты поиска и сравниваю результаты поиска с толом. И есть метрики, тот же Precision, Recall, NDCG, которые можно поэтому посчитать. Вот не всё легко посчитать. условно пресиision - это легче всего запомнить. Это что? Это это ты ловишь рыбу. Это из твоих в твоих сетях поймалась куча всякого дерьма и рыба. И вот какая доля этого, это и есть пресин рыбы. Значит, рекол - это какая доля из всей рыбы в в озере у тебя очутилась в сетях. Значит, а NDCG - это метрика, которая ещё и берёт во внимание позицию. Чем выше релевантный результат находится, тем больше это метрика. Значит, если у тебя есть два варианта, в одном релевантные документ на пятом месте, а в другом на третьем, то у тебя во втором случае отметка будет выше. Вот такие штуки ты считаешь. Но для них нужен ground trofh, для них нужно специально подготовить queries и результаты. Это кажется сложным, но прикол в том, что их не надо много. Их достаточно один раз потратить время и подготовить, а потом их можно автоматом прогонять, да, прогонять на на конфигурации A и B. И результаты, которые у тебя получатся по всем этим, собрать табличку. И дальше, например, ну, можно вообще как бы чисто математически посчитать, что лучше, но можно ещё и это всё в LM закинуть, и LM скажет, что конфигурация B лучше. И вот почему и скажет, почему. Это довольно удобный механизм для того, чтобы оценивать качество поиска. Прямо скажем, он единственный, который даёт быстрый результат и который не расстраивает пользователей, что у них вдруг что-то не начинает глупы. Ну, мы понимаем, что из-за комбинаторики у тебя просто могут выпадать определённые темы. То есть ты вроде в целом неплохо, а потом бам, какая-то тема выпала настолько, что тебя там разорвали. У меня, собственно, из-за этого на главной странице как раз SM My Search и написано, что если вы видите лёгкое решение какой-то проблемы, то не факт, что решив эту проблему, вы не создадите ещё одну, да, просто которую вы не знаете. И вот этот вот тест, он снижает эту вероятность. Он не может её до нуля снизить, потому что чем больше в этом тесте будет па expectation, тем лучше. Но их не может быть бесконечное количество. всё равно что-то там будет не учи не учитываться. Но их на самом деле можно полуавтоматически собрать. И полуавтоматически их можно собрать, например, по результатам аналитики. Вот если человек приходит, ищет что-то и тыкает на какой-то товар и потом его заказывает, и так делает 100 человек, 1.000 человек, то довольно вероятно, что этот запрос с этим товаром связан довольно жёстко. Ну раз его потом купили и положили в корзину. И когда статистики много, то такие штуки нарыть, не знаю, 100, 200, 300 примеров довольно просто. Угу. И как только ты их нарываешь, у тебя становится такой вот механизм по автоматическому тестированию. Ты его просто уже запускаешь каждую неделю и смотришь, что у тебя как там на графиках хуже стало или лучше стало. Угу. Следующий вопрос: производительность, потому что мы так об этом рассказываем, но явно всё это на одну машинку-то не поместится, если мы говорим про больших ребят. Ну да, и в один дата-центр, наверное, тоже. Расскажи чуть-чуть проки больших ребят мы говорим. Если мы говорим про интернет-магазины, то если это не Marketпйс, то не так уж там всё плохо. Если это маркетплейс с 100 миллионами товаров, я не знаю, условно Озон, да, какой-нибудь, то да, там возникают проблемы с производительностью, они успешно решаются, мы видим, потому что всё работает. Но да, там есть такая проблема. Правильно я понимаю, что это всё сводится к шардированию индекса или я не так себе это вижу? Да, значит, к шардированию индекса тоже сводится. И надо сказать, что search здесь чуть впереди, потому что у них стройная, да, фича в солоре она есть. Это Solar Cloud называется. Тоже довольно старая штука, но она как бы немножко добавлена позже. Вот. Ну и да, с распределённым поиском там есть свои проблемы, потому что ты должен на каждом шарде искать отдельно, потом объединять эти результаты. И там есть логика, которая позволяет оптимизировать это объединение, не тратить время на то, что не нужно. Как бы это решённая задача. Это задача с инверто индекс, она решённая. Задача с индексом векторным. Там решённая задача за счёт того, то что более быстрый поиск у тебя идёт за счёт меньшей точности. Ты говоришь, чёр с ней из точности, то быстро. Это, собственно, - это apprximate поиск, когда у тебя обычный тебе даёт все точки у этой вселенной, которые находятся внутри шара, да, и ты можешь их отсортировать по дальности. Ан даёт вероятностную картину. Там часть просто будет пропускаться, зато быстро. Да, конечно, хорошо было бы иметь полный КН, в котором у тебя есть то всё точно, но это долго ждать. Никого не это много ресурсов. А что касается Proxim, там есть низкая точность, но это низкой может добыть достаточно. То есть тут надо ставить эксперимент. Ну прикольно, что это не стоит такой проблемы большой, потому что для большинства этого хватит. А если мы говорим про ребят уровня Google, ну, у них там просто команды, которые ставят железные машины, кластера с тысячи машин и, в общем-то, творят сумасшедшие вещи, которые обычные люди. Кстати, насколько я понимаю, вообще, если брать поисковики, вот я сколько всегда про Яндекс слышал, что это самые секретные, самые эпичное, самое такая элитная как бы подразделение, которое вот там ядром поиска занимается там потому что никому даже рассказывать нельзя. Это же уровень секретности ещё там максимальный при всём при этом. Ну как сказать, секретностью? Во-первых, много конференций, на которых рассказываются про детали. И тут же примерно то же самое, что с ядерной физикой и с атомными бомбами с ядерными. Ну то есть в целом там принципы, на которых работает, не знаю, условно ядерный реактор или атомная бомба, они знакомы образованным людям довольно в глубоких вопросах, да. То, что вот прямо только недавно появилось, и то технологически, это не секрет. Больше, наверное, про имплементацию. Значит, когда дело доходит до материалов, до того, как, ну, фактор аранжирования в первую очередь, да, да, как как будто как решаются конкретные задачи на конкретных темах, но алгоритмы и подходы они все одни и те же. Там это не секрет вообще. И если мы говорим про поисковые системы большие, там понятно, что очень много костылей и в Яндексе, и в Гугле. Эти костыли делаются, потому что архитектурно их уже не засунуть. Если бы о них знали раньше, в самом начале, то, может быть, часть из них как-то в органично встроили. Но о них узнают по ходу и засовывают по ходы. И этих костылей, скорее всего, очень много и там, и там. И какие это костыли? Вот это вопрос очень и есть секрет, потому что как только об этих костылях становится известно, начинаешь использовать эту систему не так, как она изначально планировалась, она, разумеется, это не хочет. Вот поэтому и это закрытая информация. Но, ну о них нельзя рассказать в двух словах. Это ты понимаешь, что такое костыли в коде? Ну где-то там в каком-то файлике условия. Это же древние системы, да? Там, наверное, очень всё представление о классном коде и устройство поисковых движков у Гугла или у Яндекса - это как бы несовместимые, скорее всего, вещи, потому что это, понятно, очень сложная и страшная вещь, да. По поводу рынка ты хотел рассказать про одну вещь интересную, да? Это у наша сегодня последняя будет история, касаемая локальных поисковиков, потому что по большому счёту вот есть как бы Google, да, он захватил мир, но одновременно с этим в некоторых странах, в очень небольшом количестве стран, скажем прямо, есть локальные поисковики, которые удачно сопротивляются, даже несмотря на то, что у ГУА денег слегка больше. У тебя были мысли по этому поводу? А почему так происходит? И так много, на самом деле. Там вьетнамские там в России ещё можно вспомнить, да? Нет, количество локальных поисковиков во всём мире можно посчитать на пальцах одной руки. Не так их много. Понятно, что там в Китае, например, есть локальные поисковые машины, учитывающие особенность китайского языка. И Google там вообще закрыт, но при этом Google умеет. Он тоже учитывает особенности китайского языка, но для них это уже не настолько сильно важно. Есть тот же Яндекс, который учитывает особенности русского языка. Ну, прямо скажем, разрыв между Яндексом и Гуглом с точки зрения поиска уже не тот, что был раньше, да? То есть Google за счёт того, что алгоритмы поиска уже стали более языково специфичные, да, много где, это даже и трансформеры, и прочее, это всё в Гугле есть, то уже не так сильно видна разница. Скорее, даже про большие поисковики, я бы сказал, нету большого смысла сейчас инвестировать в локальные поисковики, потому что всё уже утряслось. Там, где они нужны, они уже есть. Там, где они не нужны, они не нужны. Угу. Условно, не нуженковик для французского языка, да? Ну, то есть во Франции. Потому что, ну, тут уже вопрос такой скорее государственной стратегии. То есть это уже за рамками просто бизнеса. Как бизнес, да, как государственная стратегия вполне может быть, потому что мир, тем более сейчас такой, что все переживают. Знаешь, что хотел сказать? Есть всё равно вещь, которая точно вот в Яндексе она работает лучше. Я регулярно с этим сталкиваюсь. Как только тебе нужен региональный поиск, ну вот когда ты что-то ищешь и ты понимаешь, что ты привязан к какой-то части, Яндексе всё-таки эту часть развивают, они это хорошо понимают. Google, скорее всего, просто на это время не тратит. Он тебе ищет вообще по всем, а ты такой: "Блин, ну мне нужно вот, не знаю, компанию, которая в конкретном городе". Да, Яндекс знает про счёт текущего местоположение пользователя. Это очень крутая штука. А потому что действительно, если человек в Саратове ищет стрижку условно, то не нужно ему показывать стрижку в Москве, на 100% не соответствует Интенту. Это да, совершенно правильно. Google это не делает. Ну, точнее, я не могу сказать, что он не делает. Я не проверял, но я знаю, что Яндекс, ну, явно хуже, да, то есть это явно хуже, да. Что касается локальных поисковиков, собственно, вот почему у меня книжка вышла Beyond English Architecture Search for Global World, это как раз-таки для ситуации, когда бизнес выходит на другую страну и там нужна поисковая система, которая понимает локальный рынок на том же интернет-магазине или на, ну, количестве это чаще всего с интернет-магазинами, да, связано. То есть, когда выходишь на китайский рынок, ты должен примерно понимать, какие сложности будут с китайской версией, потому что сделать в китайскую версию языковую, это очень просто. У тебя есть английская версия, ты отправляешь это в агентство переводов, у тебя появляются шаблоны на китайском языке, ты, разумеется, при разработке системы тоже учёл, что у тебя все поля в базе данных имеют языковую версию. Там тоже всё перевели, всё сайт работает, он имеет китайский язык. Ну вот с поиском что делать? А вот тут сразу же вопрос даже: "О'кей, а какая в принципе проблема будет?" Ну то есть что ожидать при выходе на тот или иной рынок? И вот такой информации не очень много. Я вот поэтому её пытался собрать в книжке и продумать. Там реально очень много особенностей. Там, не знаю, берёшь какой-нибудь турецкий язык, казалось бы, ну, даже более-менее близкие и понятный. не китайский, не хмерский, и так далее. А там две буквы i. Одна с точкой, другая без. Вот. И это разные буквы, там нельзя их подменять, одно другое. А вот берёшь какой-нибудь китайский, там нету пробелов между словами. Как его разбивать слова, если нет пробелов? Ну, есть решение. Берёшь, кстати, в России её есть тоже ведь, наверное, проблема. Это не проблема. Ну, как бы понятно, что это не проблема, раз её решают, но ты можешь и в кри, и в документах её заменять на е и и нет проблемы. Но, ну, имеется в ви, что подумать об этом надо, то есть те придётся это учитывать. Надо надо просто знать, что такое в принципе бывает. Там надо знать, что в Японии есть два алфавита и ещё канджи. Хираган и ракан. Даже если есть в там, если русский брать, то надо понимать, что это глубоко морфологический язык с окончаниями. Там, если брать французский, то там с английским одновременно надо понимать, что там, не знаю, артикл A в английском - это глагол французском иметь в одной из форм. Ну вот надо понимать, что слово чат DPT, например, во французском это Лёша - это вообще код. И Лёша ЖPТ - это код я пупнул. Ну, то есть, ну, как-то есть какие-то особенности, которые при поиске чат и ша нужно учитывать и понимать, что это разные языковая версия. Угу. Кстати, знаешь, что ещё смешно? Сейчас понял, вот какие проблемы бывают, когда у тебя слово бренд превращается в слово языка "Я гуглю" или там какие-нибудь памперсы, да? Раньше памперс изначально это вообще-то компания, и у тебя поиск только понимшел, а потом херакс, у тебя памперсами называются подгузники и всё, и поиск сломан, потому что будет показывать-то не то всё время. Ну и люди как-то адаптируются, понятное дело, но это тоже интересно. То есть вообще это безумно задача. И это, на самом деле, большая проблема, потому что когда ищешь, например, нароссоре какие-нибудь общие слова и выясняется, что есть бренд с этими словами, а, и он не просто так с бренд с этими словами, он как бы отчасти ещё и потому, что его так лучше будут находить. Вот. Ну и наоборот, есть бренд какой-нибудь, и внезапно это слово имеет в каком-то какой-то другой контекст и другое использование. И этот бренд начинает вылезать везде, где не попаде. Но такое вот как раз было и на гроссере, когда делали с поиском. И это довольно непросто, потому что надо понять по, ну, каждый кейс надо прямо индивидуально, по сути, надо интегрировать, да? То есть у тебя такой должен быть список всех кейсов, которые выпадают вообще из всего, да. Да, постоянным добавлением. И тут, кстати, важно, например, что если ты, например, ищешь слово с большой буквой, а в в норме часто поиск просто всё приводит к кейс, да, нормализует. И дальше и и кейс он никак не вовлекается. Но если у тебя это бренд и ты его ищешь с большой буквой, то внутри слова в предложения to much должен быть больше на слово с такой же с большой буквой в документе. А для этого надо с самого начала предполагать, что поиск должен быть sensти. Это решение, которое надо ещё принимать, когда ты индектируешь. Вот он должен быть, да, CAS and sensitive, но те документы, которые всё-таки мачатся один в один с заглавными буквами, должны быть повыше. Ну да, ну звучит как флашки в в индексе ко всему прочему. Там типа с большой, не с большой. Хотя может быть и по-другому, да. Ну там на самом деле не флажки, там просто делаются по сутили. Ты учитываешь компонент, который полный матч оценивает выше, чем матч с неполный, когда те когда там кейс не совпадает. Но они оба и учитываются, и тот, и другой. Просто в одном случае у тебя большее число, а и это двигает документ выше позиции. Рауф, мы с тобой проговорили 2 часа. Мне это Да, супер интересно. Ребят, мы заканчиваем наш подкаст про поиск. Я надеюсь, вам понравилось. Обязательно поставьте лайк, если понравилось. Если не понравилось, поставьте дизлайк. Что-нибудь напишите, что вы об этом думаете, узнали что-то новое, полезное и как вам вообще вся эта тема. Рау, тебе большое спасибо, что пришёл. Да, с удовольствием. Было бы очень интересно. Кому интересны мои книжки на testmarch.com, можете посмотреть там. Да, заходите, покупайте, смотрите книжки. Я, кстати, сейчас видел, что они на Амазоне со скидкой продаются. Это не интеграция, кстати. Это хорошая идея. Серьёзно? Ну там 62% что-то скидка показывала. Ребят, всем до новых встреч. Пока. Продолжаем копать технические темы.

เฮ