즉시 검색 실험에 대한 피드백

최근 우리는 Discourse에서 새로운 검색 경험을 프로토타입하기 위한 2개월간의 실험을 시작했습니다.

https://meta.discourse.org/instant-search에서 직접 테스트해 보세요.

:speaking_head: 사용 경험에 대해 이야기하고 싶으시면 통화 예약을 통해 편하게 연락 주세요. 모든 피드백에 감사드립니다 :pray:

기능

  • 빠른 검색

  • 토픽, 게시물, 채팅 메시지 및 사용자 검색 기능

    • 게시물 및 토픽 검색 결과에 개인 메시지(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 미만으로 줄어듭니다.

18개의 좋아요

정말 좋은 생각이에요. 사이드바 같은 곳에 링크를 걸어주실 수 있을까요?

6개의 좋아요

AWS가 언급되었으니, AWS Q의 일부 기능을 사용하면 검색을 개선하는 빠르고 지속 가능한 방법이 될 수 있을지 궁금합니다.

2개의 좋아요

정말 훌륭해! 속도 면에서는 꽤 놀랍군.

제목의 단어와 부분적으로 일치하지 않는 것 같아.

예를 들어, Objects type for theme setting이라는 주제를 찾고 있어.
object에 s를 붙이지 않으면 주제를 찾지 못해.

5개의 좋아요

키워드 옵션은 문자열을 그대로 일치시키는 방식입니다. 더 유연한 매칭을 원하시면 유사한 의미를 찾는 시맨틱(semantic) 모드나 두 방식을 혼합하는 하이브리드(hybrid) 모드를 사용해 볼 수 있습니다.

이 플러그인을 계속 진행한다면, 이런 식으로 검색 유형을 전환하는 것에 익숙하지 않은 사용자가 많을 것이므로 기본값을 하이브리드 모드로 설정하는 것이 합리적이라고 생각합니다.

7개의 좋아요

간단히 테스트해 봤는데 꽤 유망해 보입니다. 지난 며칠 동안 실험용 관리자 바에 관한 주제와 커맨드라인에서 백업을 복원하는 방법에 관한 주제를 찾아보았습니다. 전자의 경우 검색 결과에서 찾느라 시간이 좀 걸렸고, 후자의 경우 결국 북마크를 뒤져야 했습니다. 하지만 새로운 검색 기능은 두 주제 모두를 찾아내며 기존 검색보다 훨씬 빠릅니다. 따라서 저에게는 분명히 개선된 기능입니다 :+1:

4개의 좋아요

흥미롭네요! 더 자세히 살펴보고 싶어요! 지금까지는 유망해 보입니다!

결국 이런 기능이 전체 검색 기능을 완전히 대체할 수 있을까요? 또한, 이 도구는 현재 상단 툴바에 있는 검색 도구의 추가 기능으로 제공될까요?

3개의 좋아요

정말 멋지네요. 모바일에서 엘라스틱서치처럼 자동완성 옵션이 제공되나요?

3개의 좋아요

감사합니다. 제 실수였네요.
사실 첫 번째 게시글에서 모드에 대해 언급했지만, 드롭다운 목록을 전혀 보지 못했습니다. :derp:

이제 이해가 됩니다. :+1:

동의합니다. 검색 모드를 변경해야 했던 웹사이트를 기억하지 못합니다.
사용자로서 대부분의 상황에서 잘 작동하는 기본 모드를 기대합니다.


고급 동적 필터는 정말 놀랍습니다! 검색을 빠르게 좁히는 데 매우 도움이 될 것입니다.

전반적으로 팀 여러분, 정말 잘하셨습니다. :clap: 더 많은 실험을 해보겠습니다.

5개의 좋아요

이 실험은 검색 기능을 처음부터 재구축하는 것이 가능한지, 그리고 이 새로운 접근 방식의 트레이드오프가 무엇인지 연구하기 위해 진행되었습니다. 아직 이르지만, 새로운 검색 경험이 충분히 긍정적인 반응을 얻는다면 Discourse의 다양한 검색 기능에 통합하는 것을 고려할 수 있습니다. 여기에는 전체 페이지 검색, 인라인 헤더 검색, 관련 주제 검색, 사용자 멘션, 해시태그 자동 완성 등이 포함됩니다.

이 기술로는 모바일과 데스크톱 모두에서 구글 검색 UI처럼 쉽게 구현할 수 있습니다.

모드는 사용자가 쉽게 비교하고 테스트할 수 있도록 실험을 위해만 존재합니다. 이 기능이 정식 출시된다면 모드는 사용자 인터페이스가 아닌 관리자 옵션으로 제공될 가능성이 높습니다.

10개의 좋아요

빠르다는 점이 정말 좋습니다!

또한 /filter 실험 기능과 필터 옵션을 모두 깔끔하게 배치하는 방식도 마음에 듭니다. 콘텐츠 탐색과 관련하여 몇 가지 방향성이 탐구되고 있는 것 같습니다. 이 기능들이 함께 활용될 예정인가요?

결국 공통된 언어 체계가 마련된다면 사용자 입장에서 훨씬 간편해질 것입니다. 이렇게 하면 다음 사항들을 직관적으로 이해할 수 있을 것입니다:

  • 검색(Search)이란 무엇이고, 필터(Filter)란 무엇인가?
  • 인터페이스에서 각각을 어떻게 구별할 수 있으며, 어디에서 각 기능을 찾아야 하는가?
  • 언제 단순하고 일반적인 필터 세트를 받게 되는가? 전체 필터 세트를 어떻게 접근하고 확장할 수 있는가?
3개의 좋아요

배포된다면, 즉시 검색을 위한 백엔드가 /filter를 구동하게 됩니다. 기본적으로 이 실험에서 주제 검색을 위해 이미 하고 있는 것과 동일한 작업입니다.

3개의 좋아요

부끄럽지만, 맥락을 파악하고 테스트할 때 정확히 무엇을 찾아야 하는지 알기 위해 몇 가지 질문을 드리고 싶습니다:

  • 현재 검색 기능에서 어떤 부분이 문제이며, 이를 변경하거나 개선하고 싶으신가요?
  • 속도 외에 여기서 평가하는 기준은 무엇인가요?
  • 검색 기능을 처음부터 다시 구축하기로 결정한다면, Discourse 검색으로 Discourse 외부에 호스팅된 문서 등 다른 콘텐츠 위치도 검색할 수 있는 가능성이 있을까요?
3개의 좋아요

수년간 반복되어 온 일반적인 문제들은 다음과 같습니다:

  1. 사용자가 원하는 내용을 검색에서 찾지 못한다는 불만이 많습니다. 특히 다음 사용 사례에서 그렇습니다.
  1. Discourse 검색은 오타를 전혀 처리하지 않습니다.

  2. 기존 검색 기능의 개발자 경험(DX)이 열악하여, 채팅이 검색되지 않는 것과 마찬가지로 2급 시민 취급을 받고 있습니다.

  3. 개인 메시지(PM)를 검색할 때의 사용자 경험(UX)이 좋지 않습니다.

4개의 좋아요

:bangbang: 나 역시 긴 목록이 있지만, 트럼펫을 불기 전에 :joy: 질문과 이해를 충분히 갖춘 상태로 참여하고 싶었습니다.

개선에 대한 고려가 이루어지고 있는 것을 보니 정말 기쁩니다. 참고로, 아직 해야 할 일이 많지만, 우리의 검색(즉, Discourse 검색)이 다른 검색 경험과 비교할 때 그 특이점들에도 불구하고 사용자들에게 얼마나 사랑받는지 끊임없이 듣습니다.

강제적 조치(forcing function)로, 제 팀은 (적어도 우리 팀 내부에서는) 소통을 위해 Discourse만 사용하고 있습니다. 오늘 제 팀원 중 한 명이 처음 요청한 것이 바로 이것입니다:

처음 떠오르는 몇 가지 항목은 다음과 같습니다:

  • DM(개인 메시지) 검색 개선
  • 채팅 검색
  • 사이트 밖에서 검색할 수 있는 기능(또는 검색 범위 확장)이 있으면 좋겠습니다. 많은 커뮤니티가 Discourse의 문턱에서 끝나지 않으니까요.
  • 언급하신 대로, 정확한 문자열 검색이 때때로 이상한 동작을 반환합니다.
5개의 좋아요

Typesense와 같은 오프더셸(off-the-shelf) 솔루션을 실험할 때 이 부분을 깊이 고려했습니다. 고객이 데이터베이스에 문서를 주입하도록 허용하거나, 호환성을 위해 일정한 가이드라인을 따르는 다른 인스턴스에서 프론트엔드가 데이터를 소비하도록 허용함으로써 외부 "문서"로 검색 범위를 확장하는 것이 훨씬 쉬워질 것입니다.

실험 단계에서 이 두 가지 기능을 바로 제대로 구현하게 되어 다행입니다. 피드백 주셔서 감사합니다.

3개의 좋아요

참고로, 이 실험을 일시적으로 종료했습니다. 곧 다시 돌아올 예정입니다. :crossed_fingers: :slight_smile:

7개의 좋아요

다시 돌아왔어요 :eyes:

4개의 좋아요

여기서 남기신 답변 외에도, 새로운 인스턴트 검색을 어떻게 활용하고 계신지 더 잘 이해하기 위해 짧은 사용자 리서치 인터뷰를 진행해 보고 있습니다.

  • 일반적인 정성적 피드백 수집 - 좋아했던 점, 아쉬웠던 점, 바꿀 부분, 앞으로 보고 싶은 기능
  • 현재 검색과 비교한 경험
  • 새로운 검색을 직접 사용하시는 모습 확인

통화로 대화에 동의해 주시는 분들의 DM은 열려 있습니다! 피드백 주시면 감사하겠습니다 :pray:

6개의 좋아요

잠시 휴식합니다 :palm_tree: 곧 돌아올게요. :slight_smile:

2개의 좋아요