기본 콘텐츠로 건너뛰기

NLP를 위한 LDA등을 사용한 문서 정리 및 검색을 위한 머신러닝 방법론

코드를 공부하는 글이 아니므로 
샘플 코드등은 없으니 
코드를 찾으시는 분들은 패스하셔도 됩니다. 
개념 적인 접근, 그리고 사용법은 아는데 
추가적인 돌파구를 위한 
아이디어를 원하시는 분들을 위한 글입니다. 

대부분 도큐먼트(글뭉치?)의 의미를 
한 눈에 캐치하여 
인덱싱하여 
도큐먼트를 관리하기 위해 
Topic Modeling을
사용하려 하고 있습니다. 

하지만 단순히 LDA를 사용해봤자, 

사용된 단어의 개수가 많은 글들끼리의 묶음

정도로 밖에 분류가 안됩니다.
 
LDA : 잠재적 디리클렛 배분법

google스러운 
정보의 정리를 위해서는
하나만 사용하는 것이 아니라 
다양한 ML모듈을 활용해야 하는데요.. 

예를 들어 이렇게 합니다. 
LDA모듈로 문장을 읽어내면
단어의 기본형과 Document에서 사용된 단어수가 나오고
이를 기반으로 이 document의 topic에 해당할 법한
상위 단어들이 표시됩니다. 

여러 document를 던질 수록 
각각의 document그룹에서 
사용된 빈도가 높은 단어들이 나옵니다. 

여기서 topic이 다른 문서가 많이 섞일 수록
topic을 유추하는 확률이 많이 떨어집니다. 
그리고 언어가 여러 언어일 수록 
서로 모르는 언어가 되버리고 마는 것이지요. 

여기서 제가 많이 사용하는 방법은, 
모든 언어를 영어로 번역합니다. 
google translate API는 무료로 소량의 번역을 해주는데
만약 google sheet의 translate 함수를 사용하면 
속도는 조금 느릴 수 있으나 많은 제약이 사라집니다. 
뭐, 구글 어카운트를 여러개 만들어서 돌리는 것도 방법이구요. 
서비스로 사용할 분이라면 유료로 구입하는 게 당연하겠지만
이렇게 블로그의 글을 보시는 분들이라면 공부 정도의 레벨이겠죠?

이렇게 영어로 번역하면 
문장이 어색해도 상관없습니다. 
LDA는 자주 쓰인 단어에 대한 카테고라이징을 목적으로 하는 것
이기 때문에

그리고 google translate는 좋은 것이
내가 

"사과"

를 번역해도 무조건 

"apple"

로만 하는 것이 아니라 

제대로 글에 맞추어 apologize를 번역해 줍니다. 


이로서 모든 도큐먼트를 영어화 하고, 
topic이 달라보이는 글들을 추리는 방법론으로는

LDA로 추출한 단어들끼리를 
word2vec으로 거리를 측정,
그리고 각 document별 단어의 거리를 정리합니다. 
그 뒤에 특정 거리 이내의 단어들 중에 
6개의 단어가 일치(예를 들어입니다.)한다거나
하는 기준을 정하여 
이런 가까운 거리의 단어들이 있는 document를 
유사내용의 문서로 카테고라이징을 합니다. 
그 뒤에 그 문서들끼리 묶어서 
다시한 번 LDA를 돌리게 되면
굉장히 유효한 topic들이 나오게 되지요. 

그걸 기준으로 
다시 google검색을 날려서
문서들을 재 수집..
이걸 반복하면
학습 대상이 늘어나고 
google의 LDA에 적합한 문서들이 모이게 됩니다. 
그걸로 나의 LDA의 오차를 보정해 갈 수 있구요. 

이렇게 카테고리 및 인덱싱을 자동으로 만들어서
각 단어를 태그화 시켜 문서에 
연결을 하면, 
자동으로 문서 태그를 만들 수 있고, 
거기에 자동으로 관련 글의 리스트를 만들 수 있습니다.

물론 원본과 번역본은 서로 연결을 해놔야겠지요. 
그러면 기본 영어로 검색을 해야 하지만, 
검색결과 속에 한글 문서든 외국어 문서든 볼 수 있게 됩니다. 

그리고 만약 한글이나 외국어로 같은 LDA로 단어를 찢고 
단어별 영어를 매핑 시킨다면

내가 한글로 검색해도 
자동으로 관련 키워드가 영어로 또는 
다른 외국어로도 표시가 되겠지요. 

여기에 좀더 자연스러운 질문형 검색을 위해서 
doc2vec으로 학습을 시킵니다. 
이건 한글 및 영문 등 내가 모은 모든 도큐먼트로 하는게 좋습니다. 
그리고 검색하는 문장을 
doc2vec으로 test하면

"내가 작년에 정리했던 ML관련 정보 좀 줘"

등으로 날리면

한글로 doc2vec을 통해 학습한 내용들이 
애매한 결과물로 보여지게 되고, 
그 문서를 타고 들어가면
이 전에 word2vec과 LDA로 정리한 tag가 보이게 됩니다. 
그러면 다른 언어로 만들어진 문서라 하더라도
내가 원하는 결과를 찾을 수 있게 되겠죠. 

여기에 개인형 오차 가중치라는 개념이 있는데, 
유저별로 검색후 클릭한 내역을 로깅하면
word2vec으로 만든 거리와는 
개인별로 클릭률이 달라지게 됩니다. 
거리가 멀다고 정리된 문서임에도 
그 쪽으로 클릭해서 넘어가는 통계가 나타납니다. 

이걸 본인의 경우는 가중치를 높이고, 
본인이 아닌 경우 학습형 가중치를 만들어서 
추천 점수를 매기게 되면, 
(아마존의 추천 시스템 입니다.)

난 예상하지 못했지만, 
내가 원했던 전혀 다른 단어로 된
문서를 찾을 수 있습니다. 

내가 가진 문서를 정리하는 기법으로 
사용하기 위해서 만들었는데, 

요즘은 여기저기에 
이런 방법을 이용해서 
데이터를 정리해서 줄 곳이 많네요. 

이미 알고 계셨다면 패스하시고~
몰랐던 분들을 위한 활용 정보입니다~

그 밖에 tensor flow에 있는 
단어를 찾아낸 다음에 
이걸 활용해서 정리하면

사진으로 찍은 여러개의 서랍을
검색할 수가 있겠지요?
어느 서랍을 찍었는지만 파일명으로 잘 정리한다면요!

내가 찍은 비디오도 텍스트화 가능합니다. 




Microsoft의 Video indexer를 이용해서 
내 동영상으로 youtube에 올린 뒤에 
video indexer를 이용해서 text 및 
출연된 사람의 사진을 뽑아내서 정리하면

내 동영상의 정리가 아주 편하게 가능해 지고, 
비디오에서 나온 대화들이 검색에 걸리게 됩니다.

이런 식의 모듈에 대한 활용도를 높일수록
ML은 활용가치가 높아집니다. 



giip :: Free mixed RPA orchestration tool! 

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...