사용 경험에 대해 이야기하고 싶으시면 통화 예약을 통해 편하게 연락 주세요. 모든 피드백에 감사드립니다
기능
빠른 검색
토픽, 게시물, 채팅 메시지 및 사용자 검색 기능
게시물 및 토픽 검색 결과에 개인 메시지(PM) 포함
채팅 메시지에 비공개 채널 및 DM 포함
태그, 카테고리, 사용자, 받은 편지함, 채널 등을 위한 UI 기반 필터
키워드, 시맨틱, 하이브리드 및 Hyde 검색 모드
FAQ
페이지에서 한동안 검색이 작동하지 않습니다
사실 그렇습니다. 페이지를 새로고침해 주세요.
@user나#category와 같은 검색 문법을 지원하지 않습니다
실제로 지원하지 않지만, 이 기능을 정식 출시하기로 결정한다면 쉽게 추가할 수 있습니다.
토픽 검색과 게시물 검색 대상이 분리되어 있는 것은 이상한 선택입니다
이해합니다. 특히 지난 10년간 Discourse 검색이 어떻게 작동해 왔는지 익숙하신 분이라면 더더욱 그렇습니다. 정식 출시를 결정한다면 두 가지를 동시에 수행하는 모드를 만들거나, 심지어 둘 다 실행하여 UI에 모두 표시하는 방식으로 개선할 수 있습니다. 이 실험의 제약 조건을 고려할 때, 다음과 같은 두 가지 사용 사례를 모두 처리하는 가장 쉬운 방법이었기 때문입니다:
이 토픽이 존재한다는 것을 알고 단지 찾고자 할 때 (토픽 검색)
이 쿼리의 모든 발생 사항을 조사하고 싶을 때 (게시물 검색)
검색 결과 품질이 아직 완벽하지 않습니다
여기서 가능한 것들을 거의 건드리지 않았습니다. 현재는 카테고리 우선순위 설정과 제목 및 본문 가중치 배정만 수행하고 있습니다. 기존 검색의 정교함을 맞추기 위해서는 추가적인 조정이 필요하지만, 동시에 더 나아가는 가능성도 열어줍니다. 불행히도 많은 부분이 JS API를 통해 제어되며, 우리가 사용하고 있는 라이브러리가 여기에서 상당한 제약을 주었습니다.
시맨틱 / HyDE / 하이브리드 검색이 느립니다
사용 중인 JS 라이브러리의 몇 가지 불편함을 우회하기 위해 더 긴 디바운스(debounce) 시간을 설정했습니다. 정식 출시를 결정한다면 이 JS 라이브러리가 가장 먼저 제거 대상이 될 것입니다. 전반적인 속도와 관련하여, 이 기능들은 두 개의 요청에 의존합니다. 첫 번째 요청은 임베딩(embeddings)을 위한 것으로, AWS의 오래된 하드웨어에서 실행되고 있어 속도에 도움이 되지 않습니다. 미들웨어 프록시에서 임베딩을 주입하여 지연 시간을 줄이는 것도 가능합니다. 역시 실험 기간의 제약 조건 때문입니다.
기술적 세부 사항
이 실험은 Algolia의 오픈소스 클론인 Typesense를 사용합니다. Meta 호스팅의 다른 모든 서비스와 동일한 EC2 인스턴스에서 실행되고 있습니다.
프론트엔드는 Typesense에 직접 요청하지 않습니다. 대신 모든 호출은 Rack 미들웨어를 통해 Discourse 앱으로 프록시됩니다.
검색 바 / 결과 / 세분화는 EmberJS로 감싸인 InstantSearchJS를 사용합니다. 불행히도 이 라이브러리가 많은 문제를 일으켰으며, 정식 출시 시 이 라이브러리를 사용하지 않을 것입니다.
서버는 Meta 전체를 인덱싱하기 위해 7.35GB의 RAM을 사용합니다. 대부분이 임베딩 때문이며, 임베딩이 없으면 2GB 미만으로 줄어듭니다.
간단히 테스트해 봤는데 꽤 유망해 보입니다. 지난 며칠 동안 실험용 관리자 바에 관한 주제와 커맨드라인에서 백업을 복원하는 방법에 관한 주제를 찾아보았습니다. 전자의 경우 검색 결과에서 찾느라 시간이 좀 걸렸고, 후자의 경우 결국 북마크를 뒤져야 했습니다. 하지만 새로운 검색 기능은 두 주제 모두를 찾아내며 기존 검색보다 훨씬 빠릅니다. 따라서 저에게는 분명히 개선된 기능입니다
이 실험은 검색 기능을 처음부터 재구축하는 것이 가능한지, 그리고 이 새로운 접근 방식의 트레이드오프가 무엇인지 연구하기 위해 진행되었습니다. 아직 이르지만, 새로운 검색 경험이 충분히 긍정적인 반응을 얻는다면 Discourse의 다양한 검색 기능에 통합하는 것을 고려할 수 있습니다. 여기에는 전체 페이지 검색, 인라인 헤더 검색, 관련 주제 검색, 사용자 멘션, 해시태그 자동 완성 등이 포함됩니다.
이 기술로는 모바일과 데스크톱 모두에서 구글 검색 UI처럼 쉽게 구현할 수 있습니다.
모드는 사용자가 쉽게 비교하고 테스트할 수 있도록 실험을 위해만 존재합니다. 이 기능이 정식 출시된다면 모드는 사용자 인터페이스가 아닌 관리자 옵션으로 제공될 가능성이 높습니다.
Typesense와 같은 오프더셸(off-the-shelf) 솔루션을 실험할 때 이 부분을 깊이 고려했습니다. 고객이 데이터베이스에 문서를 주입하도록 허용하거나, 호환성을 위해 일정한 가이드라인을 따르는 다른 인스턴스에서 프론트엔드가 데이터를 소비하도록 허용함으로써 외부 "문서"로 검색 범위를 확장하는 것이 훨씬 쉬워질 것입니다.
실험 단계에서 이 두 가지 기능을 바로 제대로 구현하게 되어 다행입니다. 피드백 주셔서 감사합니다.