현재 2002년 12월 입니다. 제가 이하 언급해 드리려 하는 전문검색의 보완점들은 이미
1년전부터 한국 마이크로소프트사에서 인지하고 발전시키는 내용이며
언급해 드리는 내용들중 많은 내용들이 현재 완전히 해결되거나 부분적으로 해결되어
훨씬 수월한 한글 전문검색을 운영 할 수 있는 상태 입니다.
또한 나머지 문제들 역시 계속적으로 해결되고 있으며 곧 완전한 한글 인덱싱이
가능하리라 생각 합니다.
부디 오해 없으시길.. 어중간한 부정확성에 대한 이야기가 아닙니다.
이걸로 밥먹고 사는 저희 개발자들은 정확히 문제를 인지 해야만 해결책이건 "왜 안되냐?"
라는 질문에 답할 수 있어야만 밥먹을 수 있기 때문에 정확히 안되는게 뭐인지를
알아야 합니다.
어중간하게 "뭐.. 부정확하다고들 하더군요..." 식으로는 밥 굶기 딱 좋겠지요.
제가 언급 드리는 부정확성에 대해서 오해 없으시길 바라며..
부디 전문검색에 대한 오해가 없길 바라면서 이하 내용을 진행 하겠습니다.
SQL2000 전문검색 - 한글 검색의 부정확성.
영어로 전문검색을 구현한 사람들의 이야기나 여러 자료들을 확인해 보면 이제 영문 전문 검색은
정점에 도달했다고 감히 말하고 싶습니다. 실제로 여러 사이트에서 다양한 방법의 전문검색을
구현 사용하고 있으며 최근의 추세로 볼때 전문검색 엔진을 기반으로한 영문 자연어 질의
(English Query) 어플리케이션 구축과 구현에 그 초점이 이동해 있을 정도로 안정적이고
무척이나 정확한 검색을 자랑합니다.
하지만 개인적인 소견으로 중요한 비지니스 한글 데이터 처리에 대해서는
SQL2000의 전문검색 에 대해 "아직은..." 이라고 답을 드릴 수 밖에 없을 듯 하네요.
실제로 차기 전문검색 엔진의 워드 브레이커(단어 추출기) - (.NET 서버와 XP에 포함
버젼 정보 확인은 MS의 DLL 버젼 정보 DB를 참고하길 바람)를 사용시 많은 문제가 해결 되지만
SQL2000에 포함된 전문 검색으로는(버젼 5.XXXXX) 여러가지 문제점이 존재 합니다.
워드 브레이커 화일 : korwbrkr.dll
| File Name | Version | Description | |
| korwbrkr.dll | 6.0.1529.1 | ||
| korwbrkr.dll | 6.0.1303.1 | ||
| korwbrkr.dll | 5.0.2134.1 | ||
| korwbrkr.dll | 2.0.1.1629 |
2002년 12월 현재 DLL정보 사이트 검색 결과.
6.0.1529.1 : Windows XP버젼에 포함되어 있는 워드 브레이커 화일
6.0.1303.1 : Microsoft SharePoint Portal 서버에 포함되어 있는 워드 브레이커 화일.
1. 가중어, 유사단어(생성어)
가중어나 유사단어 등을 처리 할 수 있다고 온라인 도움말이나 MS의 KB사이트에서
볼 수 있지만...
실제 근접어나 가중어는 한글에서 비교적 정확히 동작하지 않으며 유사단어(생성어) 처리를
위해서는 먼저 시소러스 화일을 구성해야 하며 시소러스 화일은
TSKOR.XML 화일이며 XML의 구조로 생성되어 있습니다.
해당하는 화일은
C:\Program Files\Common Files\System\MSSearch\Data\Config\tskor.xml
에서 보실 수 있으며 이 XML 화일의 구조는 아래와 같습니다.
<XML ID="Tahoe Thesaurus"> |
expansion 부분의 항목에 가중치 값과 값들을 지정하면 Internet Explorer 키워드나 IE, IE5
로 모두 검색이 가능해 집니다. 물론 한글로 역시 사용 가능하며 예를들어
'SQLER.pe.kr' 'SQLER' 'KONAN' '코난' '김대우' 이런 키워드 들을 나열해 같은 범주로 처리할
수 있지요. 단. 해당하는 XML화일은 반드시 UNICODE 형식으로 저장 되어야만 하며 워드패드
같은 툴을 이용하시면 유니코드로 저장이 가능합니다.
- 차기 워드 브레이커에서 완전히 사용 가능.
영어의 경우 예를 들면 위의 샘플중 파생어 처리의
' FORMSOF (INFLECTIONAL, dry) ' 구문부분처럼 dry라는 항목이 쿼리될 경우
dried, drying과 같은 키워드 역시 함께 쿼리 됩니다.(정확히는 인덱싱 타임에 기본형을
워드 브레이커가 추출해 카탈로그에 저장한후 쿼리시에 쿼리 키워드 역시 기본형으로 변형
된후 카탈로그에서 해당하는 키워드를 불러오는 방식으로 처리 됩니다.)
한글을 예로 들어 본다면
먹다 - 먹는다 - 먹었다 - 먹을거다 - 먹은 - 먹고
이런 유형 단어들의 기본형은 '먹다' 입니다.
'나는 새를 보았다.' 이런 문장을 인덱싱 하게 되면 인덱싱시 모든 단어들의 기본형을
추출해 처리하게 되지요. 이때 모든 단어의 기본형 추출을 담당하는 것이
워드 브레이커(Word Breaker)이며 이 워드 브레이커가 인덱싱 성능 향상에 가장 중요한
추출기가 되는 것입니다.
워드 브레이커는 전문검색에서 두번 사용 됩니다.
인덱싱 타임 : 이미 존재하는 문장들을 인덱싱 할 경우 사용.
쿼리 타임 : 전문검색 카탈로그에 질의 할 경우에 사용.
같은 문장이라 할지라도 두군데에서 틀리게 결과가 나올 수 있으며 당연히 인덱싱 타임에
좀더 많은 데이터를 추출하게 될 것입니다.
'나는 새를 보았다.' 라는 문장에 대해서 인덱싱과 쿼리가 될 경우....
인덱싱 타임
나는 : 나, 나다, 날다
새를 : 새
보았다 : 보다, 보
위처럼 개별 키워드에 대해서 인덱싱이 정의되며 해당하는 인덱싱된 키워드중 아무
단어라도 매칭되면 이 문장이 리턴 될 것이지요.
쿼리 타임
나는 : 나
새를 : 새
보았다. : 보다, 보
이렇게 처리 됩니다. 쿼리 타임의 경우와 인덱싱 타임의 경우가 조금씩 틀리지요.
워드 브레이커건 뭐건 잘 분리도 하고 해 주는것 같은데 뭐가 문제냐?
2. korwbrkr.lex 한글 단어 사전에 등록되지 않은 단어(고유명사)는 고유명사 뒤의
조사가 분리 되지 않는다.
"김대우는 잘생겼다." 라는 문장을 분리해 보면 쿼리타임과 인덱싱 타임 모두
김대우는 : 김대우는
잘생겼다 : 잘생기
이렇게 분리 됩니다. 물론 거짓말이기 때문에 틀렸다고 지적하고 싶은 SQLER님도
계시겠지만. -_-+
"김대우는" 단어의 추출은 저희의 생각에 "김대우" + "는" 이나 "김대우" 또는 "김대우는"
이렇게 인덱싱이 되어야 정상일 겁니다. 하지만 "김대우" 라는 단어가
korwbrkr.lex 화일에 등록되지 않은 단어(고유명사) 이기 때문에 조사가 분리되지 않습니다.
"나는 잘생겼다"의 경우는 정확히 "나는" 문자열이 "나"라는 키워드로 추출 되지요.
- 이 문제는 차기 워드 브레이커에서 완전히 해결 되었습니다.
3. 복합명사 검색시의 원하지 않는 결과
삼성전자 : 삼성, 전자
현대전자 : 현대, 전자
이렇게 두개의 삼성전자, 현대전자는 나뉘어서 저장 됩니다. 복합어로 인식하기 때문이지요.
따라서 그냥 생각없이 "삼성전자" 라고 검색을 하게 되면 쿼리 타임에서 역시
"삼성" 으로 검색하고 "전자"로도 검색해서 결과를 리턴하게 되며 전혀 틀린
"현대전자"까지 떨거지로 결과가 나오게 됩니다.
- 차기 워드 브레이커에서 어느정도 해결 되었습니다.
3. 인덱싱도 쿼리도 되지 않는 단어가 존재 합니다.
공포의 "있" 시리즈로..
"열어주고있다", "보여주고있다", "호평받고있는"
이런 유형의 키워드는 쿼리도, 인덱싱도 되지 않습니다.
- 차기 워드 브레이커에서 어느정도 해결 되었습니다.
자.. 이정도면 어느정도 드릴 수 있는 문제와 그 해결에 대해서는 언급을 해 드렸습니다.
한글 XP나 한글 .Net Server들.... 또는 쉐어포인트 포털 서버에 포함된 한글 워드 브레이커
사용시 해결 가능한 것들이니.. 이곳의 워드 브레이커를 이용하시거나...
좀더 안정적인 사용을 위해 역시 차기 버젼을 기다려 보심도 좋을듯 합니다.
개인적으로 SQLER에서는 지속적으로 전문검색을 SQL7 서비스팩1 시절부터
사용해 왔습니다. 저의 경우엔 이렇습니다. 정확도? 빠른 성능?
질문 답변 게시판에서 어느정도의 정확도가 필요 할까요? 그보다 저는 빠른 성능을
택했으며 약간의 부정확성은 빠른 속도로 커버하고 있습니다.
만약 SQLER의 질문 답변 게시판이 중요한 비지니스 데이터를 포함하고 있는 곳이라면?
저역시 선뜻 사용하지 못했을 겁니다. 한건의 데이터라도 놓치면 안되기 때문이지요.
개인적으로는 80% 정도 그 성능과 정확도에 만족하고 있으며 SQLER만의 특징이라고
아직도 생각하고 있습니다. 하지만 그 20%가 비지니스 솔루션으로 선정하는가
아닌가의 판단 기준이 되는 것이지요. 부디 어서 빨리 100% 까지 올라가길 바랍니다.
SQLER의 전문검색 서비스는 물론 계속될 겁니다. ^_^
코난이도 항상 주시하고 있습니다. 다른 SQLER님들도 함께 주시 하실라우? ㅎㅎㅎ
좋은 하루 되시길 바랍니다. - 오래간만에 강좌 하나 완료!!! 열심히 해서 마무리
하도록 하겠습니다.
'DataBase' 카테고리의 다른 글
| 전문검색(Full Text Search) - 2. 전문검색 서비스의 구축 (0) | 2005.12.18 |
|---|---|
| 전문검색(Full Text Search) - 1. 전문검색 이해 (0) | 2005.12.18 |
| [mssql]임의의 행 무작위 추출 (0) | 2005.12.18 |
| MS SQL Server 성능 조정 및 최적화 (0) | 2005.12.18 |
| mssql 함수모음 (0) | 2005.12.18 |
