언어처리

띄어쓰기

고요한하늘... 2008. 1. 16. 20:46

쿼리 데이터를 한참 들여다보면 정말로 가지 각색의 쿼리들이 들어온다.

그런 쿼리들중 unique한 쿼리를 기준으로 보면 띄어쓰기가 된 쿼리(공백이 하나 이상)들이 채 50%도 되지 않는다.

물론 50% 쿼리중에는 단일어라서 띄어쓰기가 필요없는 쿼리들도 상당수 있지만 그래도 생각보다 띄어쓰지 않는 쿼리가 많다.

이것도 최근에 와서 조금 나아진것이다. 2005년 정도에 조사해보면 전체 쿼리중 40%내외가 하나 이상의 공백을 포함한 쿼리 였다.

 

최근에 와서 띄어쓰기는 언어처리를 위해 형태소 분석 만큼이나 그 쓰임이 중요해지는것 같다.

형태소 분석은 띄어쓰기가 제대로 된 것들 기준으로 한다. (그렇지 않으면 너무 많은 분석 후보가 발생할수도 있고, 여기에 선택의 문제가 끼어들면 더 심각한 상황이 된다)

그러나 앞에 언급한 대로 쿼리중 많은 부분이 띄어쓰기를 하지 않아 이를 전처리와 같은 형태로 처리해 줘야 한다.

 

그런데 이 띄어쓰기가 일반적인 학술지나 논문지에 실린 모듈로는 원하는 만큼의 성능을 얻을수 없다.

확률 정보를 이용하는 시스템이 도메인 독립적으로 성능을 발휘하지만

쿼리와 일반 문서사이에는 도메인으로 구분할수 없는 문서적 특성이 훨씬 강하게 존재한다.

 

그렇게 때문에 실제 서비스에 사용하는 띄어쓰기 시스템은 연구되어온 띄어쓰기 시스템을 실제 필드에 적합하도록 커스터마이징을 작업을 해야한다. 작업의 기반 역시 쿼리가 되어야 하는데, 이작업이 만만치 않다. 무엇보다 어려운건 쿼리속에는 오타도 많고, 신조어도 많고, 외래어도 많다는 것이다. 

 

확률 띄어쓰기로는 되는데 형태소분석으로 처리가 어려운 예

죽음의도로 => [죽음의 도로] 이걸원하는 것일것이다.

그러면

살인의도로 => 이건 [살인 의도로]or [살인의 도로]

이게 문서에 있다면 [살인 의도로]로 분석되는게 확률상 맞을테고

문서가 아니고 검색창에 있다면 [살인의 도로]로 분석되는데 맞을 가능성이 높을것 같다.

그러면 서로 분석이 달라 검색이 안될텐데..~~

 

 

어떻게 분석해도 잘 안되는 예

바벡런쳐스킬트리

일단 처음 들어봤다.

스킬, 트리 이건 알겠는데 앞에 바벡런쳐....이건 도대체 먼지...

 

검색을 해보니

바벡런쳐 + 스킬트리

이런정도로 분석해주면 될것 같은데

어렵다 T.T

 

음절 바이그램 확률로 띄어쓰기를 구현할때 앞부분의 띄어쓴 정보가 bias로 작용해 오분석이 나는 경우

- 먹는데이가아파요

 

분해된 단위로는 의미가 있지만 연속해서 나올 가능성이 별로 없는 단어 조합

매도인이해약(매도인이 해약)

괄호안의 결과가 맞지만 확률로 해보면 [매도인+이해약]요렇게 나온다...제길~~

 

 

'언어처리' 카테고리의 다른 글

세종(sejong) 태그셋(tagset)  (0) 2008.02.26
띄어쓰기의 어려움 bigram 2-1  (0) 2008.02.03
opensource for nlp  (0) 2008.01.03
델파이로 만드는 검색엔진  (0) 2007.09.06
제19회 한글 및 한국어 정보 처리 학술대회  (0) 2007.07.25