분당아재의 솔직한 블로그

경기도의 인공지능형 지방세 상담봇의 수준 점검

IT산책

지난해 알파고의 열풍으로 인해 인공지능이 다시 각광을 받고 있습니다. 

몇몇 소프트웨어 회사들은 주종목이 인공지능(AI)인 것처럼 포장을 하기도 했죠. 


인공지능 열풍으로 인해 한 10 ~ 15년전쯤에 잠시 유행(?)을 했던 대화형 에이전트가 

다시 업계에서 재조명을 받고 있는 것 같습니다.

챗봇(ChatBot)이라는 기술이 회자되면서 말이죠. 

여기저기 관련 사업들도 나오고 업계들도 발빠르게 대응하고 있습니다. 


관련 뉴스를 보다보니 경기도에서 12억원을 들여

인공지능 상담봇을 만들었다고 

대대적으로 홍보를 하길래 어느 정도인가 한번 들어가봤습니다. 


"지능형 지방세 상담봇"이네요.

세금 중에서도 지방세 영역에 한정해서 대화형으로 상담을 해 준다는 봇(Bot)입니다. 


그럼 한번 상담을 해보겠습니다.


1. 간단하게 인사를 건넸습니다.

"안녕하세요" 라고 하니 

바로 답변을 합니다. 




2. 대화창에 "지방세"라고 입력하니 "지방세 납부영수증", "지방세 정기분" 과 같이 많이 검색하는 키워드가 자동으로 올라옵니다. 

   입력의 편의성을 높힐려고 넣은 기능이겠죠.   




3. 인공지능 챗봇의 가장 핵심이라 할 수 있는 질문에 대한 답변을 제대로 하는지 보겠습니다.

    "지방세만 상담하나요?"라고 질문을 했습니다.

    그러면, 기대하는 답변은 "네. 그렇습니다." 또는 

"아니요. 지방세 외 다른 세금들도 상담이 가능합니다. 어떤 것을 원하세요?" 라는 식의

   대화가 되길 기대할 것입니다.



>

하지만, 현재 수준은 질문을 해도 질문에 들어있는 "지방세"라는 명사만을 인식해서 지방세에 대한 설명을 해 줍니다. 



4. 다른 질문을 해보겠습니다.

"지방세와 재산세는 어떻게 다른가요?" 라고 질문을 던졌습니다.


답변으로 재산세 따로, 지방세 따로 나옵니다.

결국 질문을 인식하지 않는다는거죠.


대화형까지는 아니더라도 인공지능이 되려면 최소한 질문이 어떤 것인지는 파악해야 하는데

지금은 단순히 질문에 있는 문장을 형태소분석하여 명사만을 추출한 후 이를 순차적으로 검색하는 것에 불과합니다. 


12억원이라는 거금이 들어갔는데,

실제로는 단순 키워드 검색엔진에 답변을 목록이 아닌 채팅형식으로 노출한 시스템을 만든 것이라 판단합니다.


좀더 발전된 모습을 기대합니다. 

>

검색엔진 프로젝트 관리 가이드 자료 공유

IT산책


지난 2014년에 한국데이터베이스진흥원의 요청으로 작성했던


"검색엔진 프로젝트 관리 가이드"의 문서를 공유합니다. 


당시 빅데이터가 유행이었고(지금도 그렇지만...) 


빅데이터를 DB진흥원 입장에서 봤을 때, 필요로 하는 여러가지 내용,


DB구성, 보안, 분석, 장비 등의 내용에


이를 검색하여 활용할 방안이 필요하여 작성한 자료입니다. 


시간이 좀 지났지만, 검색프로젝트 자체는 크게 변하지 않아 내용을 올립니다. 


PDF로 된 첨부파일을 확인하세요. 

07장-검색엔진 프로젝트 관리 가이드-140224.pdf






검색엔진 이야기(3) - 검색엔진의 구조

IT산책

검색엔진 이야기 세번째입니다.
오늘은 검색엔진의 전체적인 흐름에 대해서 이야기 하겠습니다.

그동안 검색엔진에 대해서 올렸던 포스트에 관심이 있으시면 아래 링크를 참고하시기 바랍니다.


먼저 검색엔진의 일반적인 구조를 살펴보겠습니다.


검색엔진의 구조는 크게 데이터를 수집하는 수집부문, 수집된 데이터를 역파일(inverted File)로 만드는 색인부문, 실제 사용자에게 검색서비스를 하는 검색부문으로 나눌 수 있습니다.
검색엔진을 만드는 회사마다 조금씩 다른 구조를 가질 수 있겠지만 일반적으로 3부문으로 구분하면 큰 문제는 없습니다.

1. 수집부문
무언가 검색을 하기 위해서는 가장 먼저 검색대상이 되는 것으로부터 데이터(텍스트)를 수집하는 것이 첫번째 작업입니다.

검색대상으로는 일반 기업이나 공공기관에서 많이 사용하는 전자결재, 지식관리(KMS), 문서관리(EDMS), 게시판, 자료실 등 일반적인 RDB(Oracle, MS-SQL, MySQL, Informix, Sybase 등)에 저장된 거의 모든 데이터가 해당됩니다.

전자결재, KMS, EDMS 등도 공급하는 솔루션회사 별로 제품의 성격, DB 스키마 등이 다 다르기 때문에 사실 검색엔진 입장에서는 수집이 가장 힘든 작업 중 하나입니다.

이런 RDB를 수집할 때는 Bridge라고 불리우는 수집기 모듈을 사용합니다.
업체에 따라 DB Gateway, DB Bridge 등으로 불리는데 여기서는 Bridge라는 용어로 설명을 하겠습니다.

DB Bridge에서 검색대상 데이터를 수집할 때는 JDBC 방식으로 데이터를 수집합니다.
각 검색대상에서 검색이 될만한 필드를 뽑아서 SQL로 구성한 후 DB Bridge에 해당 SQL를 전달하여
원하는 필드값들을 Select하여 텍스트로 저장하도록 합니다.
이렇게 저장된 텍스트를 가지고 색인 작업을 수행합니다.

때론, RDB가 아닌 다른 시스템을 검색하는 경우도 있습니다.
IBM의 Notes 시스템을 검색하거나 Exchange 서버의 메일이나 게시판을 수집하는 경우가 그것인데요. 이 경우에는 Notes를 전문적으로 수집하는 Notes Bridge, Exchage 서버의 메일을 수집하는 Exchage Bridge 등 전용 수집기를 써야 합니다.

인터넷 상의 웹문서를 수집하는 경우도 있습니다.
이 경우에는 WebBridge라는 것을 사용해야 하는데요. 이것에 대해서는 과거에 써 높았던 포스트를 참고하시기 바랍니다.



하지만 어떤 경우는 수집기를 통한 결과는 텍스트 형태의 임시 파일로 저장됩니다.
수집기의 역할을 검색대상으로 부터 텍스트를 추출하여 색인기로 전달하는 것 입니다.

2. 색인부문

수집기를 통하여 수집된 텍스트를 검색이 잘 되도록 역파일(Inverted File)로 변환하는 역할을 색인기(Indexer)가 담당합니다.
이 색인기가 어떤 알고리즘으로 설계되고 동작되는지에 따라 그 검색엔진의 성능이 좌우됩니다.

과거에는 검색대상이 되는 시스템의 DB량이 많지 않아서 웬만한 색인 알고리즘을 갖고도 데이터를 색인하고 검색하는데 무리가 없었습니다.
그러나 지금은 기업/공공기관에서 보유한 데이터 양이 수십G Byte에서 많게는 Tera Byte에 이르기 때문에 웬만한 검색엔진들은 색인하다가 시스템 다운이 되기도 합니다.

이런 이유로 인해서  대용량 검색을 지원하지 못하는 검색엔진 회사들은 어느새 시장에서 사라졌습니다. 지금은 와이즈넛, 코난, 다이퀘스트 등 몇 개 회사가 왕성하게 영업중입니다.

역시 이런 이유로 인해서 색인파일의 구조나 성능에 대한 측정값 등은 보안에 꽤 민감한 사항입니다.
자칫 경쟁사로 부터 공격의 대상이 될 수 있으니까요.
색인에 대한 이야기는 간단하게 접도록 하겠습니다.

3. 검색부문

사용자가 입력한 검색질의(Query)에 대해서 색인파일을 잘 뒤져서 검색결과 목록을 작성한 후 다시 사용자에게 제공하는 역할을 하는 것이 검색기(Searcher)입니다.

검색기도 기술적으로 굉장히 중요한 부분입니다.
포탈이나 쇼핑몰 같이 동시에 많은 사용자가 많은 Query를 보낼 때 검색결과를 제대로 찾아서 전달할 수 있는가?
각종 오름차, 내림차 등 정렬, 페이지 처리, 한 페이지에 보여줄 검색결과 개수, 상세 조건검색,
결과 내 검색 등 다양한 옵션에 대해서 모두 빠른 시간에 검색결과를 보여줘야 하기 때문에 이 부분도
상당한 기술이 필요합니다.

또한, 검색기는 Daemon이나 Service 형태로 늘 실행되면서 사용자의 Query를 기다려야하기 때문에
절대로 죽어서는 안됩니다. (물론, 대부분의 검색엔진들은 가끔씩 죽기도 합니다. ㅎㅎㅎ)

요즘은 이런 중요하고도 기본적인 검색기능 이외에
검색어 자동완성 기능, 인기검색어, 연관검색어, 테마 검색 등 사용자의 입력 편의를 위한 다양한 부가기능이 더 중요하게 여겨지기도 합니다.

어느새 검색엔진 본래의 역할은 기본이 되어버렸고
어떤 회사에서 눈에 보기 좋은 부가기능을 더 많이 갖고 있는가가 업체를 선택하는 중요한 요소가 되었습니다.
사용자들이 그만큼 게을려졌다는 것이겠지요. ㅜ.ㅜ


포스트를 적다보니 처음 의도와는 다른 방향으로 간 것 같습니다.
두서없이 적다보니 내용도 좀 부실해 졌네요.
나중에 좀더 보완해서 올려보도록 하겠습니다.


검색엔진 이야기(1) - 검색은 구글, 네이버, Bing만 있는 것이 아니다.

IT산책

제목이 좀 거창한 것일지 모르겠지만 제가 알고 있는 검색엔진 이야기를 좀 해볼까 합니다.
일반적으로 우리는 "검색"이라는 단어를 떠 올릴 때 검색 = 구글, 검색 = 네이버를 생각합니다.

"검색하다 = 구글하다"라는 말이 이상하지 않을 정도로 구글은 검색의 대명사가 되었습니다.
하지만 냉정히 말하면 구글은 웹검색엔진입니다.
즉, 인터넷 상에 존재하는 수많은 공개된 웹사이트의 내용을 검색하는 엔진일 뿐 그 이상도 그 이하도 아닙니다.
네이버 또한, 검색에서 출발하였지만 지금은 검색이라기 보다는 데이터를 유통하는 포탈일 뿐입니다.

그럼 검색이 필요한 곳은 또 어디에 있을까요?
예를 들어, 내가 사는 동네의 동사무소, 구청, 시청의 홈페이지를 생각해 봅시다.
몇년 전부터 시청이나 구청의 홈페이지들도 앞다튀어 리뉴얼을 하고, 각종 게시판 및 컨텐츠를 보강하면서 데이터양이 급속도로 증가하게 되었습니다.

시민들이 시청 홈페이지의 특정 게시판에서 과거 게시물을 검색하고 싶을 때, 이때도 검색이 필요합니다.
이런 경우, 구글이나 네이버가 이 일을 해 줄까요? 그렇지 않습니다. (물론, 약간씩 검색이 되는 경우도 있습니다.)

시청이나 구청이 아닌 행정안전부, 노동부 등 민원이 자주 발생하는 곳의 게시판에서 검색을 하는 경우라면,
이 경우에 구글, 네이버를 이용할 수 있을까요? 역시 그렇지 않습니다.

다른 예를 들어보겠습니다.
일반적으로 회사나 공공기관은 전자결재, 지식관리시스템, 문서관리시스템 등을 도입하여 사용하고 있습니다.
이 역시 도입된지 몇년씩 되었기 때문에 회사, 공공기관 내부에 축척된 데이터는 굉장히 큽니다.

업무상 과거 자료를 검색해야 하는 경우, 어떻게 할 수 있을까요?
우리가 알고 있는 구글, 네이버, 야후, MS의 최신작 Bing 등등 익히 알려져 있는 검색엔진들은 이러한 데이터 들을 검색해서 사용자에게 제공하지 못합니다.

이런 경우에는 기업용 검색엔진 솔루션을 도입하여 해당 기관, 회사내에 존재하는 데이터만 검색하도록 시스템을 별도로 구축해야 합니다.

이런 일들을 전문적으로 하는 회사들이 우리나라에 있습니다.

가장 대표적인 회사가 와이즈넛(http://www.wisenut.com)입니다.
우리나라에서 검색을 가장 잘 하는 회사입니다.

그 외, 코난, 다이퀘스트, 오픈베이스 등의 회사들이 이런 일을 합니다.
아마도 자주 들어본 이름은 아닐 것으로 생각됩니다.

이들 회사들은 기업이나 공공기관에 각종 데이터베이스(오라클, MS-SQL, Sybase, Informix, MySQL 등)에 저장된
각종 정보를 수집하고 색인해서 검색할 수 있도록 구성합니다. (이 부분에 대해서는 별도로 포스트를 올리겠습니다.)

우리들이 구글이나 포탈을 이용하지 않고도
일반 인터넷 사이트에서 편하게 검색해서 정보를 찾는 경우는 이런 업체들이 해당 웹사이트에 검색솔루션을 구축한 경우입니다.

오늘은 여기까지 입니다.
검색관련되어 관련 포스트를 계속 올려보겠습니다.

관련 포스트 :구글의 수집로봇과 같은 웹로봇의 동작 원리

검색엔진 이야기(2) - 데스크탑 검색


MS의 검색엔진 Bing, 아직은 갈 길이 먼 것 같다.

IT산책


MS가 Google의 대항마로 야심차게 준비한 검색서비스 Bing!!
오픈을 하고 나서 아직은 그 검색품질에 대해서 지켜보고 있는 중이지만 개인적인 판단으로는 검색결과가 영 아닌 것 같습니다.

한창 이슈가 되는 시사용어들을 입력하면 검색결과에 많은 신경을 썼을 것이기 때문에 큰 차이가 날 것 같지 않아서 제 닉네임으로 검색을 해 보았습니다.

Google과 Bing에 각각 '쏠로울프"를 입력한 결과 입니다.

먼저 구글입니다.


제가 블로그에 쓴 포스트는 물론이고 다음 View에 송고한 포스트, 심지어 테크노라티의 글까지 다양하게 검색됩니다.
검색결과의 제목도 본문과 정확하게 매칭되어 나옵니다. 역시 구글입니다.


다음은 Bing입니다.
우선 첫 눈에 봐도 알 수 있듯이 검색결과 제목이 영 아닙니다.
포스트의 제목을 그대로 가져와야 하는데 그렇지 않은 경우가 많습니다.
또한 랭킹도 구글에 비해서 많은 차이를 보입니다.
중요한 것은 실제 검색결과를 클릭해도 해당 페이지가 아닌 엉뚱한 페이지가 열리는 경우가 있다는 것입니다.

MS가 Bing을 광고하기 위해 많은 돈을 쓴다고 들었는데 그 돈을 검색결과에 투자하는 것이 더 나을 듯 보입니다.
이상 개인적인 시각에서 두 검색엔진을 비교해 보았습니다.

Search Technology Sumiit 2008 행사 안내

IT산책
사용자 삽입 이미지
코리아와이즈넛, 다이퀘스트, 코난테크놀로지, 쓰리소프트, 오픈베이스, 솔트룩스 등 검색엔진 전문기업 6개사  모여 검색 솔루션에 대한 전문적인 컨퍼런스를 개최합니다.

그동안 KM&EDM 컨퍼런스에 참가하여 검색솔루션을 소개하였으나 검색만을 특화하여 국내기업들이 컨퍼런스를 개최하는 것은 이번이 처음입니다. 첫 컨퍼런스라 그런지 참가비가 없습니다. 추첨을 통한 경품은 당근 제공합니다.

아래 내용을 참고하시기 바랍니다.

STS2008 검색기술 컨퍼런스 홈페이지 바로가기

1. 일시: 2008년 9월 2일 화요일 13:00 ~ 17:30

 

2. 장소: 삼성동 그랜드인터콘티넨탈 호텔, 그랜드볼룸(2F)

 

3. 주최: 코리아와이즈넛, 코난테크놀로지, 쓰리소프트, 다이퀘스트, 오픈베이스, 솔트룩스 총 6개사

 

4. 목적

    1) 국내 검색기술에 대한 인식 고취와 검색산업의 발전

    2) 최신 검색 기술 및 트렌드에 대한 전문지식 공유로 상호 네트워크를 형성

    3) 업계 전문가 및 학계 권위자의 세미나 참여로 검색 기술에 대한 전문지식 습득

 

5. 대상: 검색 기술에 관심이 있는 모든 분들

사용자 삽입 이미지

사용자 삽입 이미지

KM&ECM 컨퍼런스를 다녀와서...

IT산책
지난 3월 20일 Enterprise 2.0 실현을 위한 KM&ECM Conference를 다녀왔다.
KM&ECM 컨퍼런스는 새로 생긴 컨퍼런스는 아니고 그동안 KM&EDMS 컨퍼런스라는 이름으로 매년 두차례씩 열려왔던 것의 새로운 이름일 뿐이다.

KM&EDMS 라는 타이틀로 행사를 치루다보니 매년 참가하는 업체도 줄고 소재에도 제약을 많이 받은 듯 올해부터 새로운 이름으로 행사를 치뤄 영역도 넓히고 참가업체도 확보하려는 듯한 인상을 받았다.

그러나, 그 나물에 그 밥이다.
KM&EDMS 컨퍼런스 시절에도 그랬지만 주역은 언제나 검색엔진 업체였다. 대표적으로 코리아와이즈넛, 코난 테크놀러지, 오픈베이스, 다이퀘스트 등이 주력을 이뤘고 그외 KM 업체들이 참가하였다. 가장 큰 부스를 마련하고 사람들의 관심을 끈 업체도 검색엔진 업체인 코리아와이즈넛과 코난테크놀러지다.

이럴바엔 차라리 하반기부터 검색엔진 업체들만 따로 떼여서 컨퍼런스를 하는 것이 맞을 것 같다.

이번 컨퍼런스는 그동안 줄곧 행사를 치뤘던 인터콘티넨탈 호텔에서 하지 않고 코엑스 컨벤션홀에서 했는데 호텔에서 하는 것보다는 확실히 넓고 분위기도 좋았다.
사용자 삽입 이미지
검색솔루션 전문업체인 코리아와이즈넛의 부스 전경, 현재 국내 1위 업체이다.

사용자 삽입 이미지
역시 검색솔루션 업체인 코난테크놀러지의 부스 전경이다.



참가하는 사람들은 주로 기업과 공공기관의 전산실무자나 소프트웨어 도입 책임자 들이다. 간혹 검색엔진을 공부하려는 학생들도 눈에 띈다. 그러나, 컨퍼런스에서의 발표내용이 기술적인 내용보다는 제품소개나 원론에 가까운 내용이 많아 실무에는 크게 도움이 되지 않는 것 같다. 그렇다고 기념품이 훌륭한 것도 아니다. ^^;

9월쯤 하반기 컨퍼런스가 열릴텐데 매년 같은 모습이 아니라 좀더 다른 주제와 방식으로 열렸으면 하는 바램이 있다.

신문에 나왔다 ^^;

카테고리 없음
태어나서 처음으로 신문에 내 얼굴이 나왔다.
물론 개인적인 일로 신문에 나온 것은 아니고 회사가 어찌 어찌 되어서 잘되고 있다는 기사에 곁가지로 등장했다. ^^;

앞에 섰으면 얼굴이 크게 나왔을텐데 뒤에 있다보니 크게 나오진 않았다. 아쉬워라 ^^;
이번에 준비하는 프로젝트를 꼭 성공시켜서 다음에는 단독으로 나오도록 함 해봐야겠다.
사용자 삽입 이미지