В моей документации я оформил /commands с помощью форматирования кода в обратных кавычках. Однако, если я ищу «commands», результатов нет. Чтобы тема появилась, в поиске нужно вводить именно /commands.
Это намеренное поведение? Я не ожидаю, что пользователи будут искать конкретную команду, добавляя в начале `/» — на мой взгляд, оба варианта должны находить тему.
Редактирование: форматирование кода не имеет отношения к делу, так как просто «/commands» приводит к той же проблеме.
Редактирование 2: не могу воспроизвести это, например, с «.command» — в этом случае поиск по слову «command» даёт ожидаемый результат.
Верно, я не ожидаю, что мои пользователи заранее будут знать, что им нужно добавить «/», чтобы найти это. Есть ли какая-то причина, по которой такое поведение считается ожидаемым, или существует возможное обходное решение? Потому что это серьёзно влияет на возможность поиска в моей документации.
Поиск — дело непростое Вы хотите, чтобы это появилось в результатах, но что, если у вас есть и другие документы с «командами», и вы не хотите, чтобы в этом случае отображались документы с «/commands»?
Один из приёмов, который можно использовать, — добавить ключевые слова в ваш пост:
Да, я полностью согласен, это сложно! Хотя /commands — это лишь пример, у меня, наверное, более 100 задокументированных команд. Поэтому, хотя использование ключевых слов могло бы стать альтернативой, это не идеальный вариант.
Если слово где-то встречается, оно должно появляться в результатах поиска — таково моё понимание. Например:
Понятно, на мой взгляд, символ «/» тоже не должен иметь значения? Не уверен, как работает индексация, но настройка для изменения этого помогла бы мне очень сильно.
Я заметил, что «somequery» как часть URL возвращает результат https://domain.com/somequery-article-today, если этот URL где-то есть на форуме. Это ожидаемое поведение — я не знаю, насколько они связаны, но нашёл интересным, что в данном случае «/» не имеет значения.
Ещё одна вещь, которую я заметил, углубившись в это: у нас есть строка, разделённая косой чертой: query1/query2.
query1 возвращает результат, query2 не возвращает ничего. Вы бы сказали, что это тоже ожидаемо? Мне кажется, это больше похоже на баг, если честно.
Поднимаю эту тему, так как всё ещё считаю, что это сильно влияет на поиск. Вот некоторые из проблем, с которыми я сталкиваюсь в последнее время:
Ссылки на GitHub: ни имя пользователя, ни название репозитория не ищутся.
Ссылки на X: имена пользователей не ищутся.
Есть множество других примеров. Если вы не сильно полагаетесь на поиск, эти проблемы могут остаться незамеченными, ведь это влияет не на то, что вы видите в результатах поиска, а на то, чего вы там не видите. Нам не следует постоянно задумываться о том, нужно ли добавлять ключевые слова в тему для её находимости.
Это особенно актуально для черновиков и разделов для сотрудников, где посты ещё не завершены, иногда остаются там годами, а общение ведётся в кратком или внутреннем формате. Этот пост не был бы найден по ключевым словам «сотрудники» и «внутренний», если бы я не добавил их сам. Разве Discourse просто решил, что они не релевантны? Почему?
Я с трудом могу согласиться с тем, что это не баг, а скорее очень необычное решение для поискового индекса.
Стоит отметить, что именно так работает стеммер/токенизатор PostgreSQL. У нас есть несколько обходных путей для пограничных случаев, таких как URL-адреса, где это может запутать, но в целом мы делегируем большую часть этой работы PostgreSQL.
Интересно, что несколько лет назад у нас был хак для «дополнительной индексации в URL-адресах», который @tgxworld удалил из-за раздувания индекса.
Я могу сказать следующее: да, мы думаем о таких пограничных случаях в поиске, но для того чтобы нам пришлось пойти на взлом существующего фреймворка полнотекстового поиска PostgreSQL, нужно действительно много.
Я понимаю, что это сложная технология. Надеюсь, вы когда-нибудь найдёте хорошее обходное решение. А пока я адаптировался и пытаюсь использовать скрытые ключевые слова и креативные способы обхода этого ограничения!