• 검색엔진 »
  • Lucene 공개 한국어 형태소 분석기 개발 시작의 변

Lucene 공개 한국어 형태소 분석기 개발 시작의 변

여러분과(?) 논의한 결과 여러 문제를 없애기 위해서는 기존에 내가 가지고 있던 C기반의 형태소 분석기 보다는 Lucene의 기반이 되는 Java언어로 만들기가 확장성 측면에서 좋을거 같다는 의견에 동의를 하고 자바기반 공개 한국어 형태소 분석기 개발을 시작하려 한다.

일단 Analyzer분석을 틈틈히 하고 있고, 테스트도 간간히 해보면서 기존의 Lucene이 가지고 있는 Tokenizer나 Filter의 특성을 파악하고 있는 중이다. 조금 보니까….쩝
Tokenizer는 전처리 부분이 되겠고, Filter는 본격적인 형태소 분석 모듈이 안착하게 될거 같다.
일단 확장성이 좋게 만드는게 좋을거 같다는 생각이 드니 Lucene의 기본 분석기 모듈의 구조에 잘 맞게끔 만들어야 할 것이다.

본격적인 코딩 작업은 8월 둘째주에 있는 여름 휴가기간에 도서관에 가서 코딩하기로 하고…(아마 이때쯤 최소한 조사분리기능 정도는 되어 있으리라 생각된다.)

그 전까지 해야될 일은

1. 확률기반의 품사규칙 테이블을 유니코드에 맞게 커스터마이징 작업을 하고 자바언어에서 쓰기 편한 포멧으로 변경하는 작업.(생각 밖으로 간단할 수도 엄청난 노가다 작업이 될 수도 있다.)

2. 전에 수집해 놓은 14만 한국어 사전을 B-Tree 기반의 파일 DB에 저장.(이부분은 버클리DB를 사용할 예정이고, 간단히 Python 스크립트로 사전파일은 구성이 가능하리라.)

3. 클래스 설계

4. 고향집에서 조용히 작업할 작업환경 알아보기.(아마두 군산대학교 도서관이 될듯)

오랜만에 Eclipse기반의 Java열혈 코딩을 하게되겠군. ㅎㅎㅎ
그나저나 휴가기간에 코딩하는건 미덕이 아닌데…쩝

Print Friendly

CC BY-NC 4.0
Lucene 공개 한국어 형태소 분석기 개발 시작의 변 by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

This entry was posted in 검색엔진

  • http://blog.daum.net/psyoblade psyOblade

    앗~ 형태소분석기 개발 시작하시나요 ? 오호
    저도 나름대로 진행하던 것을 적용해볼까 .. 조금씩 진도를 빼는 중이었는데 ^^; … 언능 손 떼야겠습니다…. 하핫

    제 생각에도 java 용으로 따로 만들어두는것이 훨씬 낳을거라 생각되더군요… 최근에 eclipse 랑 java 에 익숙해지느라 고생 좀 했습니다.

    q) 확률기반 품사규칙 테이블이라함은 형태소 사전을 말씀하시는건가요 ?

    p.s) 저는 어제 사전구축 때문에 btree, trie 공부 좀 하려다가 생각보다 오래걸릴듯 싶어 그냥 hash로 만들어버렸습니다.

  • http://www.joinc.co.kr yundream

    오.. 공개 형태소 분석기를 개발하시는군요.
    저도 형태소 분석기에 관심이 많은데, 형태소 분석과 관련된 문서를 얻을 수 없을까요 ?
    공개된 공간(wiki, cvs 등등)에서 형태소 분석기에 대한 프로젝트가 진행한다면, (큰 도움이 되드리진 못하겠지만 -.-)저도 참가해보고 싶습니다.

    ps) 현재는 개인적으로 루신색인과 searcher쪽을 집중적으로 분석하고 있습니다.

  • http://www.freesearch.pe.kr 고감자

    eclipse 정말 좋은 툴이죠.

    저의 경우엔 Java는 eclipse쓰는 맛으로 쓴다는…

    a) 참 품사 규칙 테이블은요..
    제가 말을 잘못한거 같은데… 전에 말씀드린 확률기반으로 조사된 조사의 위치나 어미의 위치 정보들입니다.

  • http://www.freesearch.pe.kr 고감자

    관련 문서는 제 블로그를 검색해보시면 쉽게 찾으실 수 있을겁니다.

    강승식 교수님 논문을 참고하기가 편하실 테구요. (riss4u에서 다운 가능)
    그리고 “한국어 형태소 분석과 정보검색”이라는 책도 참고하시면 될듯 합니다.

    그 외의 문서가 있기는 한데요. 교수님께서 공개하지 말라구 하셔서 드리지는 못할거 같네요. 이점 양해 바랍니다.

  • http://www.oplix.com/blog Edan

    항상 역동적인 모습, 멋지십니다.
    개인적인 일로 검색엔진에 조금 관심이 생겼네요.
    꼭 성공하시길…

  • http://freesearch.pe.kr 고감자

    최대한 많은 사람이 이 작업에 참여하길 바랄뿐입니다.

    그때까지 저는 기반을 다질 생각이구요. ^^

    방문 감사드립니다.쩝

  • 조영환

    음… 형태소 분석이용 사전은 기껏해야 3M정도이고 기분석 사전을 올려도 30M 정도면 충분하니까, 그냥 메모리에 올리도록 하세요. ^^ 그리고 불규칙 활용에 대해서는 확장사전을 쓴다는 논문이 있었는데, 그러는 편이 프로그래밍에 도움이 될 것입니다. 사전을 미리 TRIE나 HASHING이나의 형태로 Compile해서 그것을 메모리에 덤프로 올려버리면 됩니다.
    Fseek address와 memory index가 동일함을 알고 계시다면 어렵지 않을 듯 하네요.

    버클리 DB 등을 쓰면 속도가 너무 느려질 것입니다.
    뭐 그래도 괜찮다면, 그냥 넘어가도 되는 코멘트였습니다.

    제가 C 밖에는 못써서….직접 도와드릴 능력은 없네요..쩝.

  • http://freesearch.pe.kr 고감자

    조박사님 안녕하세요!

    주변에서 박사님 이야기만 줄곧 들어와서… (맞으시죠? 박사님이…)

    그렇지 않아도 주변에서 하도 사전구조를 바꿔바라 해서 구조를 바꿀 생각입니다. 이런쪽은 나중에 다른사람들이 해주길 바랬는데 영 말씀들을 많이 하시네요. ㅡㅡ;

    방문 감사드리고요, 조언 감사드립니다. ^^

  • 최종욱

    TrieSet을 속도를 고려해서 한 노드당 HashSet이나 TreeSet 을 이용해서 Children을 인덱싱하도록 만들었더니 60만 단어를 올리면 OutOfMemory로 바로 뻗어버리더군요. 아무래도 Set 류가 기본 용량이 꽤 나가는 놈들이다보니 몇십만개 인스턴스를 만들면 당연히 메모리가 꽉 찹니다.

    그래서 배열로 무식하게 구현했습니다. 몇십만건 데이터로 테스트해본 결과, HashSet 보다 3배에서 몇십배 정도 느립니다. 양이 많을 수록 더욱 느려집니다. Hash 속도를 영 못 따라잡는군요. 결국은 Sibling들을 헤집고 다니는 속도가 느린 겁니다만, 위에서 보았다시피 indexing을 해줄 엄두가 나질 않네요.

    다행히도 전체 글자 수는 사전의 1/5로 줄여서 올라갑니다. 하지만 sibling과 child의 인덱스들을 계산해보니 결국 비슷합니다. -_-;

    Java HashSet이 훨씬 나을지도… (먼산)

  • 최종욱

    아, 물론 딸자식이 많은 놈이 우선순위가 된다면 괜찮을지도 모릅니다만… 정렬은 귀찮아서… -_-;;;