'한글사전'에 해당되는 글 1건

  1. 2008.03.21 한글 형태소 분석기 개선 계획 (6)
연구/형태소 분석2008. 3. 21. 15:22

처음으로 형태소 분석기를 만들어보고 개선한지 대략 2년 정도 된 것 같다. 단순 사전을 바탕으로 개발을 해오던 것이 이제는 나름 다양한 기술들을 적용시켰다. 여전히 즉흥적이고, 수작업을 요하는 작업들이 많이 있지만, 다양한 업그레이드 거친 것 같다.

  • 사전 기반 형태소 태깅
  • 동적 프로그래밍 적용
  • 비트 기반 오퍼레이션으로 성능 개선
  • 사전 정리 및 사전의확장성 개선

다른 방법들은 논문을 보고 구현해보면 되는 것들이었는데, 사전을 정비하는 것은 개인이 하기에 너무 힘든 일이고 쏟은 노력이 정말 눈물날 정도였던 것 같다. 일일이 수만 단어들을 보면서 눈 침침해지면서 단일 명사인지 복합명사인지 구분하고 태그 정보도 수정하고, 어휘가 단일 태그를 갖지 않도록 하고 참 많은 노력을 했다. 그러면서 국어에 대한 이해도 더 풍부해지고, 규칙, 불규칙 어휘들을 처리하면서 고생도 했고 말이다.

개인적으로 가지고 있던 생각이 어휘의 의미를 명확히 하려면 통계적 기법을 적용하는데에는 한계가 있다고 보고 있었다. 문장내에서의 단어나 형태소의 역할은 문장에 의해서 결정되는 것이고, 각 "단어" 수준에서 그러한 것들이 상호 고려되어야 한다고 생각한다. 이를 위해 당연히 풍부한 사전이 필요하였는데, 작년 말에 21세기 세종 계획에서 전자사전을 발표했는데, 정말 훌륭한 수준이다. 미등록어에 대한 처리를 좀더 고려하면 되겠지만, 사전만으로 본다면 정말 풍부한 의미와 어휘 용례를 잘 표현하고 있어 이를 통해 형태소 분석기를 개선한다면, 형태소 분석과 띄어쓰기와 구문 분석을 단번에 처리할 수 있지 않을까 생각한다.

NLP연구실도 아니고 DB연구실에서 연구실 연구 주제와 달리 혼자만 이걸 하고 있어서 정체성에 대한 고민을 하고 있었는데, 교수님께서도 우리 연구실의 Semantic Core Module의 하나로 가지고 있으면 좋을 것이라는 말씀을 해주셔서 나름 힘도 난다. 일단 해야할 일들이 많겠지만, 일단 사전을 형태소 분석할 수 있는 형태로 구성하고, 이를 가단히 시각화 하는 것으로부터 시작하려고 한다. 이를 위해 어휘간의 관계를 모델링하고, 저장구조를 확립하는 과정이 있어야 할 듯 하다. 기존에는 파일에 간단한 형태소 사전을 구성하였는데, 앞으로는 좀더 다른 구조로 가야할 듯 하다. 다양한 관계를 표현할 수 있는 사전과 형태소간의 상관관계를 표현할 수 있도록 모델링 할 것이다.

21세기 세종 계획의 결과물이 너무 잘 되 있어서 상당히 놀랐고, 이를 활용할 수 있다는 기대에 조금 들뜨기도 한다. 빨리 추진해서 좋은 결과물을 만들 수 있도록 해야겠다.

아마 다음과 같은 작업들이 추가적으로 이루어지지 않을까 생각한다.

  • 어휘 관계 모델링
  • 세종 계획 전자 사전 포팅
  • 사전 시각화
  • 형태소 분석기 적용 방안 수립
  • 형태소 분석기에 적용
  • 통계적 기법 적용으로 성능 개선 방안 마련
  • 통계 기법 적용을 위한 데이터 수집 및 학습
  • 통계 기법 적용

21세기 세종 계획 http://www.sejong.or.kr

Posted by 락끄

댓글을 달아 주세요

  1. 또 한번 더 걸음을 내 딛으셨군요, 축하드립니다. 짝짝짝!!!
    좋은 결과 있으시길 바랍니다~~~ 그리고 댓글 감사합니다.

    2008.03.23 00:48 [ ADDR : EDIT/ DEL : REPLY ]
  2. 나그네

    안녕하세요.
    형태소 분석기 정말 잘 만드셨군요. 게다가 이렇게 공개까지 하시다니, 한번도 얼굴을 뵌적은 없지만 감사하게 생각하고 있습니다.
    근데, 형태소 분석기가 로딩 속도기 너무 느리고 메모리를 차지하는 비용이 너무 큰것 같습니다. 사전에 있는 모든 단어에 대해서 MCandidate객체를 생성해서 해쉬 테이블로 관리하는 것 같은데. 이런 구조를 사용하는것은 시간과 메모리 측면에서 매우 비효율적인것 같습니다. 먼저 해쉬 테이블은 B-TREE 형태로 바꾸는 것이 좋을 것 같습니다.그리고 사전에서 사용하는 기분석결과를 MCandidate객체로 생성해 관리하는 방식보다는, 이미 처리된 기분석결과를 파일이나 메모리에 저장하고 그것을 처리하는 메소드를 추가하는 방식이 더 나을 것 같습니다.

    2008.03.27 21:52 [ ADDR : EDIT/ DEL : REPLY ]
  3. 나그네

    좀 더 효율적인 데이터 처리를 위하여 루씬의 색인 파일 구조와 그것을 처리하는 메소드를 분석해 보면 많은 도움이 되실 것입니다.

    2008.03.27 21:53 [ ADDR : EDIT/ DEL : REPLY ]
    • 좋은 말씀 감사합니다. 속도가 Hash가 가장 빠를 것이라 생각해서 Hash를 사용한것인데, B+Tree랑 비교해서 머가 더 빠를지는 모르겠네요.
      나름대로 로딩 속도 때문에 몇가지 분석을 해봤는데, MCandidate에 대해서 메모리 할당하는 부분이 로딩속도 대부분을 차지하는 것 같은데 이를 메모리에 할당하지 않고도 빠르게 처리할 수 있는 방법이 있다면 그도 좋은 대안이 되겠네요.

      루씬을 한번도 보지 않아서 어떤 방법들이 사용되었는지 모르겠는데, 한번 분석해보도록 하겠습니다.

      2008.03.29 22:28 신고 [ ADDR : EDIT/ DEL ]
  4. 혹시 진행된 상황을 요약해서 한글처리에 있어 어디까지 된것인지, ngram 하고 차이점을 알려주실수있는지요?

    2009.10.06 10:27 [ ADDR : EDIT/ DEL : REPLY ]
    • 안녕하세요.
      관심 가져 주셔서 감사합니다.
      공개 소프트웨어 공모전에 개선 버젼을 출품했고, 이를 홈페이지에 정리했습니다. http://kkma.snu.ac.kr로 가셔서 확인하실 수 있습니다.
      더 자세한 내용은 메일로 보내주세요.

      2009.10.30 15:51 신고 [ ADDR : EDIT/ DEL ]