요즘 여기에서 많이 읽으면서, 'post’와 'reply’가 서로 혼용되어 사용되는 것 같다는 느낌을 받았습니다.
이렇게 구분해서 사용한다면, 누군가가 새 주제(LOL 방금 제게 그런 일이 일어났는데, 'delete post after’와 'delete reply after’는 검색 결과가 달랐습니다…)로 질문을 하기 전에 잘못된 용어를 사용해 검색하다가 발생하는 번거로운 질문을 줄일 수 있을 것입니다.
그래서 이 주제에 대해 질문드립니다…
요즘 여기에서 많이 읽으면서, 'post’와 'reply’가 서로 혼용되어 사용되는 것 같다는 느낌을 받았습니다.
이렇게 구분해서 사용한다면, 누군가가 새 주제(LOL 방금 제게 그런 일이 일어났는데, 'delete post after’와 'delete reply after’는 검색 결과가 달랐습니다…)로 질문을 하기 전에 잘못된 용어를 사용해 검색하다가 발생하는 번거로운 질문을 줄일 수 있을 것입니다.
그래서 이 주제에 대해 질문드립니다…
답변(Reply)과 게시글(Post)은 100% 동일하게 사용될 수 있는 것은 아닙니다. Meta에서 확인하는 대부분의 사용 사례에서는 둘이 동일하지만, 항상 그런 것은 아닙니다.
게시글이 무엇인지 설명하는 Understanding Discourse for new users 을 검토해 보시는 것을 권장합니다. 답변은 OP(첫 번째 게시글)가 아닌 모든 게시글을 의미합니다.
하지만 정확한 용어를 모른다고 해서 내가 찾고 있는 것을 찾지 못할 이유는 없죠.
더 잘 아는 분들에게는, 예를 들어 “reply”
처럼 관심 있는 용어를 따옴표로 묶어 명시적으로 검색할 수 있는 옵션이 여전히 주어지지 않을까요?
감사합니다. 읽어보겠습니다만, 다른 많은 분들도 여기서 새 주제를 만들기에 앞서 그 가이드를 읽으시나요?
'디스코르스 신규 사용자 가이드’를 읽어 보았지만, '답글’에 대한 명시적인 정의를 찾을 수 없습니다.
하지만 위에서 인용한 대로 '답글’은 필연적으로 '게시글’이므로, '게시글’을 검색할 때 모든 ‘답글’ 검색 결과도 함께 표시되어야 합니다…
그리고 그 가이드를 읽은 후에도 '답글’을 검색할 때 모든 ‘게시글’ 항목이 표시되어야 하는지는 여전히 불분명합니다.
따라서 이 주제의 제목에 담긴 요청이 처리되기를 여전히 희망합니다. (다만, 다시 한번 강조하지만 이는 제 개인적인 의견일 뿐입니다)
답글은 필연적으로 게시물이지만, 모든 게시물이 답글인 것은 아닙니다. 따라서 게시물(post) 검색 시 자동으로 답글(reply) 검색어가 추가되어서는 안 됩니다.
질문자의 선호가 충족된다면, 저처럼 게시물만 검색하고 답글은 검색하지 않는 다른 사용자들을 불편하게 할 것입니다.
하지만 당신은 분명히 상황을 잘 알고 계셔서, 굳이 ‘post’ 검색 결과가 왜 이렇게 많은지, ‘reply’ 검색에서 왜 그런 결과가 나오는지에 대한 새 주제를 만들어서 여기 사람들을 귀찮게 할 필요 없이, 명시적인 검색어를 사용할 가능성이 높습니다.
게시/답변의 의미론적 차이와 관계없이, 검색에 동의어를 추가하는 기능은 현재 Discourse에서 설정할 수 없습니다.
네, 그 말에 나도 입을 다물게 되네요
하지만 추가할 수 있는 방법이 있으면 좋겠다는 생각이 듭니다. 이 훌륭한 포럼에서 초보자들의 질문에 답변해 주시는 분들의 부담을 덜어줄 수 있을 것 같거든요 ![]()
사실, 저는 일반적인 검색을 수행한 후 검색 대상과 일부 중복되는 관련 링크를 따라 갑니다.
검색 엔진은 어떤 링크가 클릭되는지에 대한 개념을 가지고 있습니다. Discourse에도 비슷한 기능이 있습니다. 토픽 끝에 표시되는 "추천 메시지"는 특정 검색어와 직접적으로 관련은 없지만 관련 있는 토픽을 찾는 데 매우 유용한 출처입니다.
이 이슈를 #contribute:feature로 재분류했습니다. 기능 요청 내용이 제게는 꽤 명확합니다. UX(사용자 경험)에서 사용자 정의 동의어를 정의할 수 있는 장소를 요청하고 있습니다.
Postgres는 기술적으로 다음 문서에 나와 있듯이 동의어를 지원합니다:
따라서 지금 바로 손을 대서 매우 기술적인 방식으로 무언가를 구현할 수는 있지만, 미래에 관리자가 이를 정의할 수 있도록 UI를 추가하는 것이 흥미로울 수 있다는 데 동의합니다.
이 작업은 복잡하고 올바르게 구현하는 데 상당한 시간이 걸리며, 이점이 제한적일 수 있으므로 pr-welcome 라벨을 붙이지 않았습니다.
시간 범위에 대해 말씀드리자면, 이 작업은 향후 1년 내에 진행되지 않을 것으로 예상하며, 아마도 향후 5년 내에 이루어질 것으로 보입니다.
축하해, Dale ![]()
![]()
용어 변경(‘User’이 이제 ‘Member’로 변경됨)에 따라 문서도 업데이트했지만, ‘User’를 검색하는 사용자가 자동으로 ‘Member’가 언급된 결과를 볼 수 있도록 하고 싶습니다. 이를 쉽게 구현할 수 있는 방법에 대해 의견이 있으신가요?
CC: @michellefs
상당히 어려운 작업입니다. 인덱싱된 데이터에 동의어를 주입하는 플러그인을 만들 수 있지만, 작업량은 1일에서 5일 정도 소요될 것으로 예상됩니다.
결국 핵심 질문은 이 기능이 여러분에게 얼마나 중요한가입니다. 구현은 가능하지만, 저희 측에서 일부 맞춤형 컨설팅이 필요합니다.
제대로 알고 있는 건 아니지만, 커스터마이즈 쪽에서 텍스트를 바꾸는 것만으로 해결되는 거 아닌가요? 아니면 또 제가 평소처럼 완전히 오해하고 있는 건가요?
이 도구를 통해 검색 알고리즘에 간접적으로 영향을 줄 수 있는 기능을 갖추는 것이 목표일 것 같습니다. 예를 들어 태그 동의어 같은 도구 말이죠. 하지만 이는 게시글(적어도 원글) 내의 키워드에 대해 적용되어야 합니다.
사용 사례의 예로, 커뮤니티 멤버나 사이트 방문자가 유사한 브랜드 용어 대신 일상적으로 사용하는 표현을 검색하는 경우가 있습니다. 검색 알고리즘은 매우 다른 주제들을 우선순위로 두었습니다. 저희 사이트의 예로, "데스크톱 앱"과 “네이티브 클라이언트” 주제 검색을 들 수 있습니다.
오타에 대한 관점이 지난 몇 년간 어떻게 변해왔는지 궁금합니다:
Discourse-AI에서는 의미론적 검색(semantic search)을 실험하기 시작했습니다. 아직 초기 단계이며, 이러한 시스템을 계속 탐색하고 있습니다.
LLM을 사용하여 검색 프롬프트를 개선하는 것도 가능한 접근 방식(다만 현재로서는 느립니다)입니다:
이 기술은 여기서 언급됩니다: GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels · GitHub
100% 자동화된 접근 방식 외에도
우리의 일반적인 전략은 반복(iterate)입니다. 제품에는 이미 “관심 단어(watched words)” 기능이 있으며, 일반적인 오타나 "삽입(stuff)"하고 싶은 일반적인 구를 지정하는 “검색 동의어(Search Synonyms)” 기능을 추가하는 것에 반대하지 않습니다. 이는 예정된 작업은 아니지만, 후원(sponsoring)을 통해 검토해 볼 수 있는 사항입니다.
Postgres에는 이 특정 기능에 대한 선례가 있습니다: PostgreSQL: Documentation: 18: 12.6. Dictionaries
또 다른 탐색 가능한 영역(다만 이 부분은 미지근한 입장입니다)은 게시글에 숨겨진 “메타데이터” 공간을 허용하여 관리자가 검색어를 삽입할 수 있도록 하는 것입니다. 이는 매우 눈에 띄지 않으며, 일반적으로는 숨겨진 것이 아니라 “적절하게” 단어를 삽입하여 내용을 드러내도록 권장합니다. 예를 들어:
semantic, related, improving

정말 천재적인 아이디어입니다. 임베딩 기반 검색의 주요 문제인 '부정확한 사용자 입력’을 해결해 주니까요.
또한 기존 설정에서 최소한의 변경만 필요하며, 검색 쿼리를 ‘풍부하게(enriching)’ 만드는 작은 단계만 추가하면 되기 때문입니다 ![]()
이 주제와 관련하여 우리가 할 수 있는 또 다른 일은 하이브리드 검색을 수행하는 것입니다:
우리는 이미 기존 임베딩 API의 별도 엔드포인트에서 매우 강력한 재순위화 기능을 제공하고 있으며, 이를 위해 필요한 모든 요소가 준비되어 있습니다.
여기에 예제가 있습니다:
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70