Condibook 소개 - AI 관련 난관, 그리고 시행.(1)

HJ seo·2022년 7월 24일

project

목록 보기

1/2

엘리스 트랙 마지막 프로젝트의 결과물 소개. 객관적인 기준으로 좀 더 다듬기만 하면 실재로 서비스를 할 수 있을 정도의 결과물이 나왔다 생각하기 때문에 소개를 해보려 한다. 하지만 아직 서버와 홈페이지를 산 것이 아니고, 엘리스에서 제공해준 서버로 페이지를 열어놨기 때문에 서비스에 대한 소개는 실재 release를 한 후 써볼 예정이고, 이번 글은 AI 모델을 구현하면서 어려웠던 점, 그리고 한계와 발전방향에 대해 살살 써보려고 한다.

초기 AI 모델에 대한 구상은 상당히 간단히 parsing에 대한 어떤 주의사항을 가지고 있지 않아 url을 받아왔을 때 거기서 받는 글들을 통해 여러개의 keyword를 뽑아주는 것 이었다.

하지만 프로젝트를 진행하는 초기, 랜더링의 문제(통신규약등 복잡한 문제가 섞여있고, 이것만으로도 글이 몇개가 나오기 때문에 추후 글의 주제로 써볼 예정이다.)로 실재 사용할 때 쓸 수 있는 데이터의 한계가 있다는 큰 문제가 발생하게 되었고, 팀원들과 단체로 짧은 고민 끝에 header 안쪽에 있는 meta 태그의 title과 description을 사용하기로 결정했다.

그리고 여기서부터 AI의 난관이 시작되었다.. 데이터의 제한조건 - 일반적으로 header.meta.description은 160자를 넘지 않는다고 한다.(물론 - 모델을 완성한 이후 알게 된 사실 - 이를 무시하는 경우도 많지만 대부분의 사이트에서 description에는 모든 내용이 들어가지 않았다.) - 으로 인해 트랙에서 배우지 않았던 아예 새로운 모델을 찾아서 논문부터 뒤지기 시작했고(정신없이 찾은지라 링크를 많이 기억하진 못하고 일부만 reference에 남겨둔다..), 그와 동시에 모아둔 데이터를 어떻게 전처리를 하면 좋을지에 대한 고민도 하나의 큰 고비라는 것이 보였다.

Keybert, Yake, TF-IDF 관련 논문들, fasttext, word2vec... 그 어떤 논문도 제목, 그리고 제한된 글자수를 가진 설명을 통해 키워드를 뽑는 모델이랄 것이 없었고, 5주라는 스프린트 기간동안 2주 가까이를 여기에 소비했다.

그리고 3주차 주말.. 중간발표를 한 이후 아직까지 AI model이 완성되지 않았기에, 그리고 엘리스에서 제공해준(내 컴퓨터보다 좋은 성능의) VM을 사용할 수 있는 기간이 일주일밖에 남지 않아 조바심이 들었고, 결국 최종적으로 로직을 짜서 API를 작성하기로 마음먹었다.

이때의 로직의 구상방법은 다음과 같다.(input, output 아래의 줄간격은 시간순으로 생각하게 된, 일종의 핵심)

input : url로부터 title 그리고 (없을 수 있는)description.

output: 3개에서 5개 사이의 keyword들 + hashtag.

문학적 소양으로부터 대부분의 글에서 제목이 글의 핵심을 말한다는 것을 알고 있고, 로직의 핵심이 키워드(글을 설명할 수 있는 단어)를 뽑아내는 것이기 때문에 title을 주축으로 keyword를 뽑아내는 것으로 결정,

description은 불완전한 경우가 많다는 것을 가정하고, title로부터 뽑아낸 keyword들과 url의 유사도를 판단하는 것을 돕는 재료로 사용.

시간의 촉박함으로 모델을 처음부터 훈련을 시키지는 못했고, pretrained된 모델을 가져옴(word2vec, fasttext), 그러나 fasttext의 경우 한국어의 일종의 압축성으로 인한 이상케이스가 존재 - title로부터 키워드를 뽑아올 때 완전히 이상한 단어가 뽑히는 경우 - 했고, description을 통해 이를 제어하는 것이 상당히 힘듦 - 이상케이스 역시 설명이 가능한 경우 - 으로 인해 word2vec 모델을 사용하게 됨.

구현을 하게되면서 title과 description에 한글만 들어가지 않는 다는 것을 떠올리고, googletrans를 사용, 그러나 우리나라 글과 같이

두 가지 언어를 붙여 사용하는 경우가 있는데 (ex. 'backend의 핵심' 처럼..) 이 경우 명사에 대한 추출이 잘 되지 않는다는 것을 확인하고, 이중으로 명사추출과 번역을 이중으로 사용, 불용어에 대한 처리(위의 예시에서 Okt를 사용했을 때 '의'도 명사로 판단하더라..) 및 번역 후 명사로 판단되는 단어 및 여기에서 뽑아낸 단어와 유사한 단어를 키워드로 뽑아냄.

그리고 최종적으로, 내가 구현한 API의 로직은 다음과 같다.

1. title로부터 명사 추출 및 유사단어 추출(+유사도) 및 불용어 제거..(명사가 없거나 영어가 아닌 외국어일시 return hashtag:etc)
(googletrans, word2vec, regex, konlpy)
2. description으로부터 명사 추출 및 불용어 제거..(description이 없을 시 return title_nouns) (regex, konlpy)
3. similarity 판단, keyword 추출 (word2vec)
4. keyword로부터 가장 유사한 방향의 hashtag 추출 (word2vec)

하지만 프로젝트를 진행하는 과정중에 결국 keyword는 사용하지 않게 되었고, hashtag(초기 13개의 단어, 글을 쓰는 현재 15개의 단어)만 사용하게 되었고, 5주차 발표 이후 코드에 대한 리펙토링을 진행하게 되었다는 엉뚱한 결론..

추후 쓰게 될 글에선...

(2)에서는 어떤 데이터를 사용했는지,

(3)에서는 발표 이후에 어떤 방식으로 리펙토링을 하게 되었는지, 현재 AI모델의 한계와 모델을 개선할 때 어떤 고민이 있는지,

(4)에서는 프로젝트 결과물에 대한 소개를 해볼 예정이다.(물론 이 순서는 바뀔 수 있다.)