SOOJLE
수즐 커뮤니티
수즐 커뮤니티
  • SOOJLE Document
  • 프로젝트 요약
  • Untitled
  • 프로젝트 개요
    • 프로젝트 소개
    • 추진 배경 및 필요성
    • 프로젝트 내용
      • 기능적 요구사항
      • 비기능적 요구사항
    • 개발환경 및 팀 구성
    • 워크플로우
      • 계획 수립 & 설계
      • 데이터 수집 및 정규화
      • 인공지능 개발
      • 서비스 모듈 개발
      • 성능 평가 및 보고
    • 프로젝트 예산 내역
  • 사전조사 & 의사결정
    • 사전조사
      • 재학생 대상 사전조사
      • 수집 URL 대상 목록
        • 세종대학교 직할
        • 세종대학교 학과
        • 공식 공지사항
        • 세종대 평생교육원
        • 외부 웹사이트
      • 학습 모델 사전조사
        • LSA - 잠재 의미 분석
        • LDA - 잠재 디리클레 할당
        • Word2Vec - 워드투벡터
        • FastText - 패스트텍스트
    • 의사결정
      • 사용자 인증 방식 의사결정
      • 데이터베이스 의사결정
        • MySQL vs MongoDB 성능 분석
      • 토픽별 의사결정
      • 부가 기능 의사 결정
  • 프로젝트 설계
    • 시스템 구조 설계
    • 핵심 기능 설계
      • 데이터 크롤러 설계
      • 게시물 토픽 정의 및 분류
      • 사용자 관심분야 측정
      • 뉴스피드 설계
        • 사용자-문서 유사도(Recommendation Score)
        • FaS (관심 분야 및 유사도 측정 - 추가)
        • 토픽 뉴스피드 목록
      • 검색 알고리즘 설계
        • 검색 알고리즘 1차 설계
        • 검색 알고리즘 1차 개선안
        • 검색 알고리즘 2차 설계
    • 요구사항 목록
      • DB 요구사항
      • 기능 요구사항
      • 품질 요구사항
      • 관리 요구사항
  • DB
    • 구조 설계
    • 테이블 명세
  • 데이터 크롤러
    • 데이터 크롤러 개요
    • 크롤링 URL 선정
    • 크롤러 구현을 위한 사전조사
    • 크롤러 개발 과정
      • 크롤러 프로그램 설계
      • 크롤러 규격화
      • 크롤러 정규화
      • 데이터 정제 과정
      • 에러 핸들러 구현
      • 배포 환경 이식을 위한 Porting
    • Issue & Exception
    • 결과 보고
  • 인공지능 개발
    • 인공지능 개발 개요
    • NLP 스터디
      • Bag of Words(BoW)
      • Document Term Matrix(DTM)
      • TF-IDF(Term Frequency-Inverse Document Frequency)
      • 문서 유사도(Document Similarity)
    • 데이터 전처리 과정
    • 개발 과정
      • 토크나이저 구현
      • LDA 모델 학습 및 구현
    • LDA 학습 모델링
      • 1차 파라미터 튜닝 결과 (NUM_TOPICS)
      • 2차 파라미터 튜닝 결과 (NUM_TOPICS)
      • 3차 파라미터 튜닝 결과 (NUM_TOPICS)
      • NUM_TOPICS 파라미터 의사결정
      • 4차 파라미터 튜닝 결과 (PASESS, ITERATION)
      • 최종 학습 모델 명세
    • Word2Vec(FastText) 학습 모델링
    • Issue & Exception
    • 성능 분석 결과
  • BackEnd
    • 서버 구축 및 배포
      • SOOJLE 서버 구조
      • 상용 서버 (UWSGI + NGINX) 구축
      • HTTPS 서버 구현
    • API 문서 개요
    • API 목록
      • Analysis
      • Auth API
      • Newsfeed API
      • Post API
      • Search API
      • Admin API
    • 세종 Auth API
    • 통계 기능 설계
    • Issue & Exception
    • 성능 분석 결과
  • FRONTEND
    • 프론트엔드 설계 개요
    • 디자인 설계 의사결정
      • 디자인 컨셉 및 기능 정의
      • 컴포넌트 디자인
      • Logo Variation
    • 화면 흐름도
    • 페이지 UI 명세
      • Main Page
      • Header
      • Footer
      • Mobile Control Bar
      • Login Page
      • Timeline Page
      • Menu Page
      • Hyperlink Icons Page
      • Search Component & Mobile Search Modal
      • Search Page
      • Post Block
      • Snackbar
  • 프로그램 배포
    • 프로그램 개요
    • 시스템 아키텍쳐
    • 주요 기능 및 명세
    • 프로그램 테스트
    • 구현 결과물 배포
  • 마무리
    • References
  • SOOJLE AI
  • SEJONG AUTH
  • IML Tokenizer
  • SOOJLE Crawler
  • SOOJLE Frontend
  • SOOJLE Backend
Powered by GitBook
On this page
  • 개요
  • 기존 방법의 문제점
  • 문서 증가에 따르는 검색 모듈 성능 하락
  • 토큰 일치 여부에 따르는 점수 분배 방식
  • 검색 모듈 개선안
  • 검색 엔진 수행 병렬화
  • 검색 결과 카테고리 분류 및 중간 출력
  • 제목, 태그, 토큰 간의 점수 측정 방식 수정

Was this helpful?

  1. 프로젝트 설계
  2. 핵심 기능 설계
  3. 검색 알고리즘 설계

검색 알고리즘 1차 개선안

Previous검색 알고리즘 1차 설계Next검색 알고리즘 2차 설계

Last updated 5 years ago

Was this helpful?

개요

기본적인 검색 알고리즘은 이전 항목의 "검색 알고리즘 설계"의 내용을 준수한다. 본 항목에서는 검색 결과 중, 우선도를 결정하는 스코어링 작업이 아닌, 스코어링 작업을 수행할 문서의 범위를 결정하는 조건 및 그 외에 검색 엔진의 퍼포먼스를 향상시킬 방안에 대하여 다룬다.

기존 방법의 문제점

문서 증가에 따르는 검색 모듈 성능 하락

SOOJLE의 검색 알고리즘은 모든 문서에 대한 Full Table Scan을 최대한 지양하기 위해 학습 모델링에 사용된 명사 토큰과 검색 키워드 간의 매칭을 기반으로 각 문서의 중요도 점수를 작성한다. 실제로 정규 표현식을 통한 Full Table Scan에 비해 비약적으로 시간적 성능이 향상된 것을 확인할 수 있었고 해당 알고리즘의 큰 틀 자체는 변경될 여지가 크게 없다.

문제는 중요도 점수 작성을 하는 대상이 항상 Table의 문서 전체였다는 점이다. 하루에 평균 수천 개의 문서를 웹에서 수집하는 SOOJLE에 대하여 이 기능을 실행할 경우, 수집 용량에 따라 선형적으로 실행 시간이 증가하게 될 것이라는 문제점이 생긴다.

때문에 기존 문서 전체에 대한 점수 작성이 아닌, 선별된 일부의 데이터 목록 내에서만 각 문서에 대한 점수 작성을 수행할 필요가 있다.

토큰 일치 여부에 따르는 점수 분배 방식

기존의 검색 알고리즘은 Title Token, Tag, Token에 대하여 각각의 토큰이 매칭될 경우의 점수 우선순위를 부여하고 그 총합을 구해 최종 점수로 해당 문서의 중요도를 측정하였다.

해당 과정 중에, 우리들은 제목 > 태그 > 토큰 순으로 일치 여부에 따르는 중요도가 존재한다고 생각하였고 각 부분이 매칭될 때의 점수에 큰 폭의 차이를 두었다. 예를 들어 특정 제목, 혹은 본문 내용을 스크랩하여 검색했을 때, 검색한 제목 문자열와 완전히 똑같은 문서가 1순위로 뜨는 것이 당연하다고 생각했기 때문이다.

그러나 이 방식에도 몇 가지 문제점이 존재한다. 예를 들어 제목에는 "IT", "공모전"이라는 키워드가 존재하지 않지만 본문 내용 혹은 주제상 의미가 가까운 경우임에도, 고작 "IT" 키워드 하나가 제목에 일치한 (공모전과는 관련 없는) 게시물이 더 높은 우선순위를 받게 된다는 것이다.

검색 모듈 개선안

위와 같은 이슈를 해결하기 위하여 팀원들과 검색 알고리즘을 개선할 아이디어를 논의해보았고 다음과 같은 개선 방안이 제시되었다.

검색 엔진 수행 병렬화

기존의 SOOJLE 검색 엔진은 입력받은 검색 키워드를 기반으로 Title Token, Token, FastText Similar Token, 이 3가지의 토큰 리스트에 대하여 개별적으로 연속적인 작업을 수행한다. 때문에 충분히 병렬적으로 수행할 여지가 존재한다는 점이다. FrontEnd 단에서 각 API 3개를 비동기적으로 한 번에 호출함으로써 서버에서는 병렬적으로 각 과정을 수행할 수 있을 것이다.

검색 결과 카테고리 분류 및 중간 출력

사용자가 원하는 검색 결과는 검색 키워드에 따라 어떤 결과를 원하는지 다를 것이지만, 머신은 그에 따라 자동으로 분류하기가 힘들다. 예를 들어 그저 "공모전"이라는 키워드를 검색했을 때, 사용자는 공모전 모집 공고를 보고 싶을 수도 있고, 커뮤니티의 공모전 참여 후기를 원하는 것일 수도 있다.

때문에 각 게시물의 성격을 카테고리화하여 위와 같이 각 과정을 병렬화하여 먼저 나타난 검색 결과를 Client Side에서 먼저 표출해주는 것이다.

제목, 태그, 토큰 간의 점수 측정 방식 수정

기존 검색 엔진의 스코어링 방식은 문제점은 다음과 같다.

Keyword : IT 공모전

Document1 : IT 부문 프로그래머 채용 공고
Document2 : SW 경진대회 모집 공고

Score(Document1) > Score(Document2)

해당 키워드의 성격으로 봤을때 사용자가 원하는 정보는 2번 문서에 가까웠지만 점수 책정 방식 때문에 1번 문서가 더 높은 점수를 받게 된다.

때문에 다음과 같은 검색 점수 책정 방식을 제안한다.

  • 제목, 태그, 토큰 사이의 점수 차이를 줄인다.

  • 제목, 태그, 토큰 중, 문서와 해당 부분 전체 혹은 일정 이상 비율이 일치할 경우, 추가 점수를 부여한다.