https://magnetikonline.github.io/markdown-toc-generate/

팀 NLP 11조 Week20 Day4

목차

일자

• 2021.12.16 목

팀원

• 문석암_T2075
• 박마루찬_T2078
• 박아멘_T2090
• 우원진_T2137
• 윤영훈_T2142
• 장동건_T2185
• 홍현승_T2250

주간 일정

• 1주차 멘토링 12/10(금) 16:00
• 2주차 멘토링 12/15(수) 16:30
• 3주차 멘토링 12/20(월) 16:00

피어세션

최종프로젝트

협업 링크

최종 프로젝트에서 작성

구글드라이브 링크

피그마 링크

프로토타입 링크

install_requirements 작성을 생활화합시다~!

12/17일자 이슈 사항

1. DAPT에 사용될 데이터에 대해 고민 (전처리 수준 및 들어갈 데이터)
   • 폴더명 : 12/16 기존 + 띄어쓰기 전처리만 한 파일
2. Dense 모델 그대로 추가하였으나 지역이 맞지 않은 데이터가 나와서 API 오류가 생기는 문제 발생 (ISSUE 참고)
3. 태화강동굴피아

프로젝트 (주말 과제)

• 웹 서비스 이름
  • "의견"
• 아이콘
  • "의견"
• 따봉 언따봉 이미지
  • "의견"

예시

FE

• 컴포넌트 구조로 변경
• 드랍다운 추가 필요
• 유사 명소 검색에서 드랍다운 조건 변경
• '빨리빨리'
• 이미지 없음 처리 필요
• 응답 보여주기
• Logging page 또는 컴포넌트
  • 디자인 어쩌지...
• error page

BE (FE 에서 모듈화 작업한거 필요하면 톡주세용~!)

• cookiecutter 프로젝트 구조 github 업로드
• API 문서
• Model API
• Tour API
• Log API
  • 여기에 추후 작업
  • 꾸준한 feedback data
• DB 구축
  • cloud storage

Model

• Sparse
• Dense

데이터

• dense 훈련 query context pair에 대한 의심
  • 현 방식 : Sparse 기준 관련도 높은 문서 끼리 결합 의견
  • 우선 직접 보기
  • 리뷰, 블로그 상위 N 개만에서 Sparse
  • context ->
  • 데이터 량으로 왕창 늘려보는것도... -> Pair 수를 가능한 늘려보는 방식

개인적으로 생각하는 테스트 (진행한 테스트는 꼭 실험 작성필요)

생각한 평가지표

• 5 pair 기준 pair 4:1 로 train val 분리후 점수 확인
• 즉 pair를 8:2로 분리 후 train val 점수 확인
• top-k 5,10 등으로 고정 후 확인

sparse(유사 명소 검색)

• 추가적으로 유사 명소 검색에서는 pair 데이터에 있는 명소 데이터에 모든 context(가능한 많은 블로그 데이터)를 사용해보는게 어떤지
  • 폴더명 :12/16 blog_limit30
    • 예외적으로 pair 사용이 아닌 result_prepro.json, info_prepro.json를 사용하시면 됩니다

dense (baseline 선택 부터 진행할 필요가 있음 또한 평가 기준을 어떻게 할지 고민할 필요도 있음)

• 1. 블로그 최소 길이 100 pair 수 5개 - 영훈

  • 폴더명 : 12/13 전처리 + 블로그 최소 len 100
  • base 기준을 구성

• 2. [1] + 블로그 띄어쓰기 전처리 진행 - 영훈

  • 폴더명 : 12/16 기존 + 띄어쓰기
  • 블로그 띄어쓰기에 대한 영향력 분석 vs [1]

• 3. [1] + [2] + tokenizer input 변경 - 박마루찬

  • 폴더명 : 12/16 tokenizer
  • Sparse 토크나이저 변경
    • 단 stemming 은 고려 안함 (추후생각해볼게요..)
    • 특수문자들 죄다 고려 제외 (제거)
  • stopword 제거 버전은 만들어봐야하나..?
    • 그럼 그냥 엘라스틱 서치 쓰는게 좋을듯?
  • vs [2]

• 4. pair 매칭 기준 변경..?

  • 어떻게 진행할지 고려할게 필요함 어떻게 보면 3번의 확장
  • vs [1]

• 단 띄어쓰기를 다시 잡는 것은 시간이 너무 오래 걸리므로 띄어쓰기 전처리 제외 (이하 갯수 30개 전부 동일)

• 5. context 갯수가 30 이상 (pair 5개) - 홍현승

  • 폴더명 : 12/16 blog_limit30
  • context 초기 갯수의 영향력 분석
  • vs [1]

• 6. context 갯수가 100 이상 + pair 수 10개 - 박아멘

  • 폴더명 : 12/16 pair10
  • pair 갯수 영향력분석 vs [2]

• 7. 수작업 데이터 vs [2] - 박마루찬

  • 폴더명 : 12/17수작업 데이터
  • vs [2]
  • split chunk - 문석암
  • context 버리기
    • 지운 후의 context 총 갯수 5개
    • 지역 별로 진행할텐데
      • 지역 별 갯수:
        • 서울 : 725
        • 인천 : 395
        • 대전 : 145
        • 대구 : 245
        • 광주 : 130
        • 부산 : 380
        • 울산 : 180----------2200 박아멘
        • 세종특별자치시 : 45
        • 경기도 : 1115
        • 강원도 : 995
        • 충청북도 : 420------2575 박마루찬
        • 충청남도 : 770
        • 경상북도 : 805
        • 경상남도 : 870------2445 홍현승
        • 전라북도 : 430
        • 전라남도 : 625
        • 제주도 : 825--------1880 윤영훈

• 8. DAPT 진행 ->

  • DAPT 영향력 분석 VS [2]

• 9. context 갯수가 30 이상 + pair 수 10개

  • 위 성능 비교 후 필요시 업로드 예정

feature 추가

• 데이터에 무조건 overview 추가하는거 괜찮을지도..?
  • 문제는 query 인데....

하면 좋은거

• Load balancing
• Docker
• Kubernetes