메타에서 검색 개선 사항 테스트 중

최근 내부 피드백을 반영하여 검색 알고리즘 개선 작업을 우선순위로 정했습니다.

이 변경 사항은 Discourse 3.1.0.beta3의 일부로 이제 모든 사이트에 배포되었습니다. 업데이트 후, 사이트는 검색을 위해 모든 콘텐츠를 자동으로 다시 인덱싱하기 시작합니다.

이와 관련하여 두 가지 새로운 사이트 설정이 추가되었지만, meta에서 테스트를 통해 잘 작동하는 것으로 확인된 값으로 기본값이 설정되어 있어 대부분의 사이트에서는 이를 변경할 이유가 없을 것으로 예상됩니다.

제목의 부분 일치보다 전체 용어 일치 우선순위 설정

Discourse는 검색 시 stem(어간 추출) + prefix match(접두어 일치)를 수행합니다. 이로 인해 때때로 매우 예상치 못한 결과가 나올 수 있습니다.

예를 들어: redis는 redi로 어간 추출되므로, redis를 검색하면 redirect와 같이 redi로 시작하는 모든 단어를 찾을 수 있습니다.

새로운 숨겨진 사이트 설정 prioritize_exact_search_title_match가 추가되었으며, 기본적으로 활성화되어 있습니다.

변경 전:

변경 후:

즉, 제목을 기억하고 그대로 입력할 경우 해당 제목을 찾을 가능성이 훨씬 높아집니다.

최대 인덱스 중복도 감소

우리의 랭킹 알고리즘은 특정 용어에 대해 여러 번 일치하는 게시물을 한 번만 포함된 게시물보다 높은 순위를 부여합니다. 이는 단순히 한 단어를 반복해서 입력함으로써 검색을 "해킹"할 수 있음을 의미합니다. 단어를 더 많이 입력할수록 검색 결과 상위로 더 올라갑니다.

기본값이 6인 새로운 숨겨진 사이트 설정 SiteSetting.max_duplicate_search_index_terms가 추가되었습니다.

이 설정이 적용되면, 게시물에서 'sam’이라는 단어를 6번이든 60번이든 입력하든 동일한 순위가 매겨집니다. 결과물에 부여할 수 있는 보너스에 상한선을 두는 것입니다.

이 변경 사항은 검색 인덱스가 다소 작아지므로 성능에도 긍정적인 영향을 미칩니다.

기타 버그 수정

이번 작업의 일환으로 병리적(pathological) 검색 사례를 살펴봤습니다.

  • 이전에는 닫힌(closed) 주제의 우선순위를 낮추는 조치를 취했지만, 아카이브된(archived) 주제는 놓치고 있었습니다. 이제 수정되었습니다.

  • 이전에는 “도메인” 검색에 접두어 일치에 지나치게 의존하고 있었습니다. 즉, happy는 happi로 어간 추출되고 접두어 일치에 실패하기 때문에 https://happy.com을 찾지 못했습니다. 이 문제는 수정되었습니다.

향후 계획

  • 멘션 자동완성(auto-complete)에 대해 “퍼지(fuzzy)” 검색을 실험할 계획입니다. (예: 한 글자를 건너뛰도록 허용)

  • 제목 내 중복 용어의 우선순위를 낮추는 것을 조사할 계획입니다. 현재 닫힌 주제 hello goodbye hello가 열려 있는(open) 주제 hello world보다 높은 순위를 매기고 있습니다.

  • PageRank… 현재 결과물을 랭킹할 때 내부에서 유입되는 링크의 수를 고려하지 않고 있습니다. 이는 때때로 매우 잘 연결된 주제가 어디서도 링크되지 않는 희귀 주제보다 낮은 순위를 매길 수 있음을 의미합니다. 랭킹 알고리즘에서 이를 반영하는 것이 좋겠습니다.

  • AI 통합을 살펴보는 오픈 이니셔티브가 있으며, GPT와 같은 도구에서 영감을 얻을 수 있을 것입니다.

도움을 줄 수 있는 방법?

meta에서 나쁜 검색 결과를 발견하셨나요? 그렇다면 검색하신 용어와 결과가 왜 미흡한지 설명을 포함해 알려주세요.

이 변경 사항에 대한 여러분의 느낌은 어떠신가요? (중립/좋아짐/나빠짐?)

47개의 좋아요

확실히 하기 위해… 제 세팅을 업데이트/업그레이드하면 그 두 가지 설정을 찾을 수 있을까요? 숨겨진 설정은 어떻게 찾는지 알고 있어서 그 부분은 문제가 없는데, 현재로서는 메타(Meta) 전용 설정인가요? 저한테는 여기서보다 제 서클에서 테스트하는 게 더 쉬워서요 :wink:

7개의 좋아요

네, 하지만 rake search:reindex도 실행해야 합니다

7개의 좋아요

Meilisearch를 사용하여 검색을 개선하는 방법에 대해 생각해 보셨나요? 이 방식은 리소스를 매우 적게 사용하며, Docker 빌드에 포함할 수도 있습니다.

5개의 좋아요

7개의 게시물이 새로운 주제(검색에서 닫힌 또는 해결된 주제 우선순위)로 분리되었습니다.

우리는 이 분야에서 실험을 시작했으며,

첫 실험은 사용자/그룹 검색으로 제한되어 있지만, 잘 진행된다면 더 확장될 수 있습니다.

8개의 좋아요

sphinx, melli, elastic, solr/lucene을 포함한 다양한 통합을 고려해 보았습니다. 하지만 이러한 솔루션들은 비용이 듭니다. 인덱싱을 위해 별도의 프로세스를 호스팅해야 하고, 인덱스가 최신 상태가 아닐 위험이 있으며, 복잡성 등 모든 것이 무료는 아닙니다.

다른 옵션을 탐색하기 전에 PostgreSQL(PG)에서 얼마나 더 많은 것을 얻을 수 있는지 확인해 보고, 다른 옵션들은 최후의 수단으로 두는 것이 좋습니다.

매우 흥미로운 문제입니다. 네, 그것들은 (항상 그랬듯이) 우선순위가 낮아져 있습니다. 최소한 discourse-solved에 사이트 설정을 추가하여 관리자가 이러한 경우를 어떻게 처리할지(우선순위 높임/낮춤/중립 등) 결정할 수 있게 하는 방안을 검토해 볼 수 있을 것 같습니다.

16개의 좋아요

안타깝게도 postgres는 검색 엔진으로 최적화되어 있지 않습니다. 그리고 meilisearch는 놀라울 정도로 낮은 메모리 사용량과 무한한 검색 가능성을 제공합니다. ruby와 비교했을 때 서버의 오버헤드는 단순히 무시할 수 있을 정도일 것입니다.

3개의 좋아요

이것은 사소한 문제가 아닙니다. 우리의 검색 시스템에는 방대한 양의 차원(dimension)과 수많은 매개변수가 포함되어 있으며, Postgres 테이블에 직접 조인됩니다.

외부 검색 제공자를 사용하면 “동기화” 문제에 대해 걱정해야 합니다.

  • Discourse에서 토픽이 닫힘 → 엔진에 알림
  • 게시물이 삭제됨 → 엔진에 알림
  • 좋아요가 생성됨 → 엔진에 알림
  • 토픽이 분리되거나 병합됨 → 엔진에 알림

이 목록은 계속되며, 여러 인덱스(사용자/게시물/토픽/카테고리)를 구축하는 작업도 포함됩니다.

그럼에도 불구하고, 적절한 투자가 이루어진다면 반드시 극복할 수 없는 문제는 아니지만, 이는 거대한 작업이며, 이것이 얼마나 더 나은지 보여줄 개념 증명(Proof of Concept)은 아직 존재하지 않습니다. MelliSearch에 오타 랭커(typo ranker)와 다른 많은 기능이 있다는 점은 논쟁의 여지가 없이 좋은 점입니다. 하지만 이를 통합하는 데에는 전혀 무료가 아닙니다.

대략적인 추정으로는 MelliSearch에 안정적이고 견고한 통합을 구축하는 데 약 3개월의 작업이 필요할 것입니다. 검색 엔진이 "플러그인 방식"으로 설계되도록 Discourse를 재설계한다면 6개월이 걸릴 수도 있습니다.

참고로 우리는 Algolia 통합을 지원합니다: https://discourse.algolia.com/ 이 통합은 완전히 안정적이지 않으며, 구현에서 고급 검색 기능이 완전히 생략된 것을 볼 수 있습니다.

8개의 좋아요

discourse와 같은 대규모 커뮤니티가 있는 만큼, 훨씬 더 빠를 수 있으며 3개월을 넘지 않을 것이라고 확신합니다.

2개의 좋아요

며칠 전에 가장 활동적인 사용자들에게 검색 기능에 대해 어떻게 생각하는지 물어봤습니다 (생각했었어 :man_facepalming:). 검색 기능이 좀 더 강력해졌다는 사실은 절대 말하지 않았거든요.

모두가 정확히 같은 말을 했습니다. 본인은 생각하지 못했지만, 제가 물어보니 이제 관련 결과를 훨씬 더 쉽게, 대부분 바로 찾게 되었다는 거였죠.

Discourse의 일부가 WordPress의 댓글 시스템 역할을 하고 있습니다. 네, 댓글 수는 더 늘지 않았습니다(블로그 댓글보다 과대평가된 건 없으니까요) 하지만 이 포럼의 존재를 보여주고 있죠. 요즘은 소수의 사용자가 Discourse를 검색 엔진처럼 사용하고 있습니다. 그들은 댓글을 달지 않지만, WordPress에서 찾고 있는 내용을 Discourse의 주제들을 통해 검색한 뒤 블로그로 돌아가고 있습니다. 물론 태그 시스템도 큰 도움이 됩니다. 그리고 WordPress에는 효과적인 검색과 제대로 작동하는 태그 기능이 모두 부족하죠.

Community Building > Praise 채널에 올리는 게 더 맞았을까요? 하지만 이 새롭고 개선된 검색 기능이 얼마나 잘 작동하는지 꽤 만족스럽다는 점만 말씀드리고 싶었습니다.

11개의 좋아요

와, 감사합니다. 정말 기분이 좋네요! 이제 PR을 준비 중이고, 곧 전 세계적으로 변경 사항을 배포할 예정입니다.

11개의 좋아요

무뚝뚝한 질문인 것 같아 죄송합니다 — 이 기능이 호스팅 사이트(최신 배포 버전)에서 활성화되어야 하나요? 릴리스 공지에서는 여기로 링크가 걸려 있지만, 여기에서는 숨겨진 설정에 대해 언급하고 있네요. 해당 숨겨진 설정이 켜져 있는 건가요?

6개의 좋아요

당신은 아무것도 할 필요가 없습니다:

원래 게시물에 참고사항을 추가하겠습니다.

9개의 좋아요

훌륭한 업데이트 감사합니다. 검색 동의어를 정의할 수 있게 되면 우리에게 큰 개선이 될 것입니다 :pray: 감사합니다.

7개의 좋아요

게시물 9개가 새 주제로 분리되었습니다: 검색에서 사용자명을 제외할 수 있나요?

이전에 문제가 있었는지는 확신이 없는데, 검색 결과에 시스템이 생성한 게시물이 많이 표시되는 것을 확인했습니다. 메타 사이트에서 더 눈에 띄는 엣지 케이스일 수도 있지만, 시스템 메시지가 검색 결과와 관련이 있을 것이라고는 기대하지 않습니다.

"automatically closed"와 같은 용어로 검색했을 때의 예시 결과:

4개의 좋아요

여기서는 재현할 수 없습니다.

3개의 좋아요

재현할 수 있습니다. 관련성이 아닌 최신 게시글 순으로 정렬하면 결과에 시스템 메시지가 많이 표시됩니다.

4개의 좋아요

아, 그래, 이제 이해가 됩니다. 모든 것은 아니지만, 합리적인 수준이네요. 이 메시지들은 검색에서 제외되어야 할 것 같습니다.

3개의 좋아요