Уточнения поиска тестируются на Meta

[sam (Sam Saffron)]

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

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

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

Приоритет точного совпадения термина в заголовке над частичным совпадением

Discourse использует алгоритм stem + префиксное совпадение при поиске. Это иногда приводит к очень неожиданным результатам.

Например: слово redis сводится к redi, поэтому поиск по redis может находить все слова, начинающиеся с redi, такие как redirect и другие.

Добавлен новый скрытый параметр сайта: prioritize_exact_search_title_match, который теперь включен по умолчанию.

До:

После:

Это означает, что если вы помните заголовок и вводите его, вероятность найти именно этот заголовок значительно возрастает.

Снижение максимального дублирования в индексе

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

Добавлен новый скрытый параметр сайта SiteSetting.max_duplicate_search_index_terms, значение по умолчанию — 6.

После применения этого изменения, если вы введете слово sam 6 раз или 60 раз в посте, его ранг останется прежним. Это устанавливает предел для бонуса, который можно получить за повторения.

Это изменение также положительно сказывается на производительности, так как индекс поиска становится немного меньше.

Различные исправления ошибок

Часть работы была посвящена анализу патологических случаев поиска.

• Ранее мы снижали приоритет закрытых тем, но забыли про архивированные. Это теперь исправлено.

• Ранее мы слишком сильно полагались на префиксные совпадения для поисков по «домену». Это означало, что слово happy не находило https://happy.com, так как happy сводится к happi, и префиксное совпадение не срабатывало. Это было исправлено.

Планы на будущее

• Мы планируем экспериментировать с «нечетким» поиском для автодополнения упоминаний (например, позволять пропускать одну букву).

• Мы планируем изучить возможность снижения приоритета дублирующихся терминов в заголовках. В настоящее время закрытая тема hello goodbye hello ранжируется выше, чем открытая тема hello world.

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

• У нас есть открытая инициатива по интеграции с ИИ, и мы можем почерпнуть вдохновение из инструментов, подобных GPT.

Чем вы можете помочь?

Заметили ли вы плохие результаты поиска на meta? Если да, пожалуйста, укажите термин, по которому вы искали, и объясните, почему результаты оказались неудовлетворительными.

Как вам кажутся эти изменения (нейтрально/лучше/хуже)?

[Jagster (Jakke Flemming)]

На всякий случай… Если я обновлю/улучшу свою настройку, найду ли я эти два параметра? Я знаю, как найти скрытый — это не проблема, но являются ли эти параметры пока только для Meta? Для меня проще протестировать это в моих кругах, чем здесь

[sam (Sam Saffron)]

Да, но также необходимо выполнить rake search:reindex

[volanar]

Думали ли вы об улучшении поиска с помощью Meilisearch? Это требует очень мало ресурсов и может быть включено в сборку Docker.

[Falco]

@Tris20

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

Мы уже начали эксперименты в этой области:

@sam

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

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

[sam (Sam Saffron)]

@Volanar

Вы думали об улучшении поиска с помощью Meilisearch?

Мы рассматривали различные интеграции, включая Sphinx, Melli, Elastic, Solr/Lucene, но они сопряжены с затратами. Развёртывание ещё одного процесса для индексации, риск устаревания индексов, сложность и так далее — всё это не бесплатно.

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

@Maciej Kuźmicz

Вопрос по вышеизложенному. Как насчёт автоматически закрытых тем с решением?

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

[volanar]

@Sam Saffron

Я хотел бы увидеть, насколько эффективно мы можем использовать PG, прежде чем рассматривать какие-либо другие варианты, и оставить их в качестве последнего средства.

К сожалению, PostgreSQL не адаптирован для использования в качестве поискового движка. В то же время Meilisearch обладает фантастически низким потреблением памяти и безграничными возможностями поиска. Нагрузка на сервер по сравнению с Ruby будет просто незаметна.

[sam (Sam Saffron)]

@Volanar

Накладные расходы сервера по сравнению с Ruby будут просто незаметны.

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

При использовании внешнего поискового провайдера необходимо беспокоиться о «синхронизации»:

• Тема закрыта на Discourse → уведомление движка
• Сообщение удалено → уведомление движка
• Поставлена оценка → уведомление движка
• Тема разделена или объединена → уведомление движка

Список можно продолжать, включая создание нескольких индексов (пользователи/сообщения/темы/категории).

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

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

Обратите внимание, что у нас есть поддержка интеграции с Algolia: https://discourse.algolia.com/. Она не совсем надёжна, и вы можете видеть, что весь расширенный поиск опущен в этой реализации.

[volanar]

@sam

В качестве приблизительной оценки я думаю, что создание плотной и надежной интеграции с Meilisearch займет около 3 месяцев. Возможно, даже 6 месяцев, если мы спроектируем Discourse так, чтобы поисковый движок был «подключаемым».

Я готов поспорить, что с таким большим сообществом разработчиков Discourse это может занять гораздо меньше времени — не более трех месяцев.

[Jagster (Jakke Flemming)]

Недавно я спросил, что думают мои самые активные пользователи (strike>думают ) о поиске — я даже не ожидал, что он получит такое усиление.

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

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

Не знаю, стоит ли мне публиковать это в канале #praise, но я просто хотел сказать, что я очень доволен тем, как работает этот новый и улучшенный поиск.

[sam (Sam Saffron)]

@Jakke Flemming

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

Вау, спасибо, это действительно заставляет меня чувствовать себя отлично! У нас уже есть запрос на слияние (PR), и мы очень скоро начнём внедрять изменения по всему миру.

[mattdm (Matthew Miller)]

@sam

У нас уже есть PR, и мы должны скоро развернуть изменения по всему миру.

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

[mcwumbly (Dave McClure)]

Вам не нужно ничего делать:

@sam

@mcdanlj

Похоже, что prioritize_exact_search_title_match всё ещё скрыт. Стоит ли нам ожидать его использования? Нужно ли нам запускать rake search:reindex после развёртывания, как указано в этом комментарии в теме?

Нет и нет

Мы исправили настройку по умолчанию: prioritize_exact_search_title_match теперь по умолчанию равен true.

Также мы обновили версию индекса до версии 5.

Это означает, что каждые 2 часа 10 000 тем и 20 000 самых новых постов со старой версией индекса будут переиндексированы.

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

Я обновлю исходный пост примечанием.

[Luke_Cousins]

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

[dsims (Daniel)]

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

Пример результата при поиске по таким терминам, как «автоматически закрыто»:

[mattdm (Matthew Miller)]

Я не могу воспроизвести это здесь.

[Moin]

Я могу воспроизвести это: если сортировать их по последнему сообщению вместо релевантности, в результатах будет много системных сообщений.

[mattdm (Matthew Miller)]

А, да, я понял. Это не всё, но вполне разумно. Похоже, эти сообщения следует исключить из поиска.