Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REFACTOR] 검색 기능 개선 #899

Open
5 of 6 tasks
HoeSeong123 opened this issue Nov 7, 2024 · 3 comments · Fixed by #902
Open
5 of 6 tasks

[REFACTOR] 검색 기능 개선 #899

HoeSeong123 opened this issue Nov 7, 2024 · 3 comments · Fixed by #902
Assignees
Labels
BE 백엔드 FE 프론트엔드 refactor 요구사항이 바뀌지 않은 변경사항

Comments

@HoeSeong123
Copy link
Contributor

HoeSeong123 commented Nov 7, 2024

📌 어떤 기능을 리팩터링 하나요?

검색 기능을 개선합니다.

TO-DO

  • ngram parser 개선
    • ngram parser boolean mode로 변경
  • 검색 버튼 추가 또는 엔터
  • 맨 마지막 페이지로 이동하는 버튼 삭제
    • 페이지네이션 처리 시 최대 다음 페이지 수를 5개로 제한
  • 템플릿 목록 조회 쿼리 개선

⏳ 예상 소요 시간 (예상 해결 날짜)

🔍 참고할만한 자료(선택)

페이지네이션 시 마지막 페이지 정보 제거에 대한 디스커션

@Hain-tain
Copy link
Contributor

현재 엔터를 눌러야 검색이 되도록 변경 하는 요구사항을 반영중입니다.

기존에는 자동으로 검색이 되었기때문에 별도로 검색어에 대해 안내하지 않았습니다.
그러나 요구사항이 변경될 경우, 아래 사진과 같이 검색을 한 후 검색어를 지울 경우 이전 검색어에 대한 결과만 남아있고, 검색창이 변경되게 됩니다.

image

따라서 유저에게 혼동을 주지 않기 위해 아래와 같이 피드백을 하는 것이 좋을지, 또 다른 좋은 방법이 있을지 건의하고자 이슈에 남겨봅니다!!

image

@HoeSeong123
Copy link
Contributor Author

현재 방식

현재 ngram full text parser를 이용해서 검색을 진행하고 있다. 이는 keyword와 검색을 하고자 하는 target의 단어들을 공백을 기준으로 n글자씩 쪼개는 방식이다.

ex) 리스트가 최고야 -> 리스/스트/트가, 최고/고야

위 방식을 선택한 이유는 다음과 같다.
기존의 방식은 단순히 공백을 기준으로만 target을 구분했다. 따라서 리스트가 최고야 를 검색하기 위해서는 리스트가 아닌 리스트가 라고 검색해야 했다. 이는 굉장히 어색했고 이를 해결하기 위해 ngram full text parser를 도입하였다.

하지만 이번에는 다른 문제가 발생하였다. keyword를 토큰으로 쪼개서 각 토큰별로 검색을 진행하다보니 예상하지 않은 결과까지 나오게 되었다.
예를 들어 리스트라고 검색할 경우 리스, 스트 2개의 토큰으로 검색이 진행된다. 이로 인해 테스트, 감스트와 같은 리스트와는 연관이 없는 것들까지 검색이 되게 된다.

@HoeSeong123
Copy link
Contributor Author

HoeSeong123 commented Nov 15, 2024

상황별 테스트

자연어 모드

  • 데이터: 리스트, 테스트, 리스의테스트, 리스스트, 리12스34트
  • 키워드: 리스트
  • 검색 결과: 리스트, 테스트, 리스의테스트, 리스스트

분석

  • 리스트를 리스, 스트로 쪼개서 검색하는 것으로 보임

불리언 모드 - 한글 검색

  • 데이터: 리스트, 테스트, 리스의테스트, 리스스트, 리스트가좋아
  • 키워드: 리스트
  • 검색 결과: 리스트, 리스트가좋아

분석

단어 자체로 검색을 진행하는 것 같음, 단어가 포함되기만 해도 검색이 됨

불리언 모드 - 영어 검색

  • 데이터: list, test
  • 키워드: list
  • 검색 결과: list, test

분석

불리언 모드도 ngram parser가 적용되는 것 같음. 검색 키워드인 list를 li, is, st로 쪼개서 검색을 진행하는데 i가 불용어라 li, is는 키워드로 인식되지 못함. 즉 st로만 검색이 되고 list, test가 결과에 나옴. 불용어를 포함하지 않은 키워드로 다시 한 번 테스트를 진행함

불리언 모드 - 영어 검색2

  • 데이터: zxcvb, cvbnm

  • 키워드: zxcvb

  • 검색 결과: zxcvb

  • 키워드: cvb

  • 검색 결과: zxcvb, cvbnm

분석

예상한대로 불용어가 없는 경우에는 키워드를 통째로 포함한 값만을 찾아옴. listtt에 대한 테스트도 진행함. 예상대로라면 li, is는 키워드에서 제거되기 때문에 sttt를 포함한 단어만 나올 것으로 예상됨

불리언 모드 - 영어 검색3

  • 데이터: list, test, listtt, gamsttt, sttt
  • 키워드: listtt
  • 검색 결과: listtt, gamsttt, sttt

분석

마찬가지로 불용어를 제외한 키워드를 통째로 포함한 값만을 찾아옴.

불리언 모드 - 영어 검색3(대소문자 구분)

  • 데이터: DB, db
  • 키워드: db
  • 검색 결과: DB, db

분석

대소문자를 구분하지 않고 가져오는 것으로 보임. 오히려 좋음.

불리언 모드 - 띄어쓰기 테스트

  • 데이터: 돼지 고기 맛집, 돼지 맛집 고기, 돼지 진짜맛집 고기
  • 키워드: 돼지 고기 맛집
  • 검색 결과: 돼지 고기 맛집, 돼지 맛집 고기, 돼지 진짜맛집 고기

분석

띄어쓰기를 하는 경우 띄어쓰기를 기준으로 단어를 분리함. 그 단어가 포함된 것들을 찾아오는데 순서는 무관하게 찾아옴

불리언 모드 - 띄어쓰기 테스트2

  • 데이터: 돼지고기 맛집, 소고기 맛집, 그냥 맛집, 그냥 소고기, 그냥 돼지고기
  • 키워드: 돼지고기 맛집
  • 검색 결과: 돼지고기 맛집, 소고기 맛집, 그냥 맛집, 그냥 돼지고기

분석

띄어쓰기를 기준으로 단어를 분리하고 그 단어를 포함한 결과를 찾아오지만, 반드시 모든 단어가 포함되어야 하는 것은 아닌 것 같음. 돼지고기, 맛집 두 키워드 중 하나만 포함해도 가져옴. 즉 or 연산이 적용됨.

불리언 모드 - 띄어쓰기 테스트3

  • 데이터: 돼지고기 맛집, 소고기 맛집, 그냥 맛집, 그냥 소고기, 그냥 돼지고기
  • 키워드: +돼지고기 +맛집
  • 검색 결과: 돼지고기 맛집

분석

앞에 + 연산자를 붙여주면 해당 키워드들을 반드시 포함해야함. 즉 and 연산이 적용됨.

불리언 모드 - 띄어쓰기 테스트3 (순서 검증)

  • 데이터: 돼지 고기, 고기 돼지
  • 키워드: +돼지 +고기
  • 검색 결과: 돼지 고기, 고기 돼지

분석

순서는 보장되지 않음.

결론

  • 불리언 모드를 사용하면 ngram parser의 이점(단어의 일부분만 검색해도 값을 찾아올 수 있음)을 챙길 수 있고, 위에서 설명한 문제 또한 해결할 수 있을 것으로 판단됨.
  • 추가로 띄어쓰기를 기준으로 나누고 앞에 +를 붙여주는 식으로 키워드를 파싱한다면 보다 정확한 데이터를 가져올 수 있음.
  • 엘라스틱 서치 도입에 대해 고려해보았지만 러닝 커브가 높은 점, 현재 검색의 오류가 치명적이라 빠르게 해결해야 하는 점 등을 고려하여 현재는 도입하지 않기로 결정함.
  • 불리언 모드로 현재의 검색 오류를 최대한 해결하고 추후에 엘라스틱 서치 도입에 대한 재검토를 예정하고 있음

단점

  • 유연한 검색은 제공되지 않음
  • 예를 들어, 돼지고기맛집을 검색했을 때 돼지고기 맛집, 돼지고기 ㄹㅇ맛집, 돼지고기의 맛집 등은 검색되지 않음.
  • 하지만 보통 키워드 하나만을 검색하는 우리 서비스의 검색 기능 특성상 큰 단점으로 다가올 것 같지는 않다고 예상됨.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BE 백엔드 FE 프론트엔드 refactor 요구사항이 바뀌지 않은 변경사항
Projects
Status: Todo
3 participants