Неожиданное поведение поиска: когда 'commands' не находит '/commands'

В моей документации я оформил /commands с помощью форматирования кода в обратных кавычках. Однако, если я ищу «commands», результатов нет. Чтобы тема появилась, в поиске нужно вводить именно /commands.

Это намеренное поведение? Я не ожидаю, что пользователи будут искать конкретную команду, добавляя в начале `/» — на мой взгляд, оба варианта должны находить тему.

Редактирование: форматирование кода не имеет отношения к делу, так как просто «/commands» приводит к той же проблеме.

Редактирование 2: не могу воспроизвести это, например, с «.command» — в этом случае поиск по слову «command» даёт ожидаемый результат.

2 лайка

Надеюсь, это поднимет тему. :smile:

У меня не воспроизводится при поиске /commands:

Мы просто не нашли commands. Можно поспорить, что он должен находиться, но это не баг как таковой.

Я искал настройки, связанные с «поиском», но ничего очевидного не нашёл. Есть какие-то подсказки, что именно стоит искать?

Нет, я думаю, что такое поведение является ожидаемым.

Верно, я не ожидаю, что мои пользователи заранее будут знать, что им нужно добавить «/», чтобы найти это. Есть ли какая-то причина, по которой такое поведение считается ожидаемым, или существует возможное обходное решение? Потому что это серьёзно влияет на возможность поиска в моей документации.

Поиск — дело непростое :slight_smile: Вы хотите, чтобы это появилось в результатах, но что, если у вас есть и другие документы с «командами», и вы не хотите, чтобы в этом случае отображались документы с «/commands»?

Один из приёмов, который можно использовать, — добавить ключевые слова в ваш пост:

<small>Ключевые слова: команды</small>

1 лайк

Да, я полностью согласен, это сложно! Хотя /commands — это лишь пример, у меня, наверное, более 100 задокументированных команд. Поэтому, хотя использование ключевых слов могло бы стать альтернативой, это не идеальный вариант.

Если слово где-то встречается, оно должно появляться в результатах поиска — таково моё понимание. Например:

/testcommand > query: testcommand > :no_entry_sign:

betacommand! > query: betacommand > :white_check_mark:

!betacommand > query: betacommand > :white_check_mark:

В чём же разница между / и ! в данном случае?

Это связано с тем, как мы индексируем данные:

“test /command” → “‘/command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”
“test !command” → “‘command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”

Обратите внимание, что во втором случае символ ! был утерян. Мы решили не сохранять !; вероятно, знак препинания не считается значимым при поиске.

2 лайка

Понятно, на мой взгляд, символ «/» тоже не должен иметь значения? Не уверен, как работает индексация, но настройка для изменения этого помогла бы мне очень сильно.

Я заметил, что «somequery» как часть URL возвращает результат https://domain.com/somequery-article-today, если этот URL где-то есть на форуме. Это ожидаемое поведение — я не знаю, насколько они связаны, но нашёл интересным, что в данном случае «/» не имеет значения.

Ещё одна вещь, которую я заметил, углубившись в это: у нас есть строка, разделённая косой чертой: query1/query2.

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

1 лайк

Поднимаю эту тему, так как всё ещё считаю, что это сильно влияет на поиск. Вот некоторые из проблем, с которыми я сталкиваюсь в последнее время:

Ссылки на GitHub: ни имя пользователя, ни название репозитория не ищутся.
Ссылки на X: имена пользователей не ищутся.

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

Это особенно актуально для черновиков и разделов для сотрудников, где посты ещё не завершены, иногда остаются там годами, а общение ведётся в кратком или внутреннем формате. Этот пост не был бы найден по ключевым словам «сотрудники» и «внутренний», если бы я не добавил их сам. Разве Discourse просто решил, что они не релевантны? Почему?

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

4 лайка

По результатам некоторых тестов, которые я провёл сегодня, похоже, что это могло быть исправлено? Не уверен, было ли это намеренно, но спасибо!

Редактирование: забудьте.. поведение всё ещё такое же. :frowning:

1 лайк

Стоит отметить, что именно так работает стеммер/токенизатор PostgreSQL. У нас есть несколько обходных путей для пограничных случаев, таких как URL-адреса, где это может запутать, но в целом мы делегируем большую часть этой работы PostgreSQL.

Интересно, что несколько лет назад у нас был хак для «дополнительной индексации в URL-адресах», который @tgxworld удалил из-за раздувания индекса.

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

1 лайк

Спасибо за ваш ответ, Сэм!

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

1 лайк

Я считаю, что скрытые ключевые слова как полноправные сущности — это интересно

Это предложение уже было высказано в этой теме: Unexpected Search Behavior: When 'commands' Doesn't Find '/commands' - #7 by j.jaffeux