Lemur Beginner's Guide to Indexing

Posted 2009/01/22 09:20

Contents

  1. What is an index?
  2. What kind of data/documents can Lemur index?
  3. Do the parsers add all words into the index?
  4. What type of indexes does Lemur have?

    1. What is an index? 
        인덱스나 데이터베이스는 기본적으로 key나 point의 reference 같은 정보의 일부를 사용해서 빠르게 access할수 있게 해주는 정보의 모음이다. 우리의 경우 document의 collection에서 term에 대한 정보를 나중에 access할 수 있도록 term이나 document를 이용해서 색인한다.

        특히 정보 검색을 하는데 가장 일반적으로 필요한 term의 출현 빈도, term의 위치, document 길이의 통계를 모을 수 있다. 예를 들어, index로부터 document의 collection에서 어떤 term이 얼마나 많이 나오는지 알 수 있고, 특정 document 하나에서 얼마나 나오는지도 알수 있다. 들어온 쿼리에 대해 어떤 문서를 반환할지 선택하는 검색 알고리즘은 각 문서들을 계산하여 기록한 인덱스에 모인 정보를 사용한다.
    2. What kind of data/documents can Lemur index?
        실제로 가지고 있는 document가 어떤 것이든 당신의 파서가 term이라고 인식하고 싶어하는 것을 index에 넣는 한, 그것에 대해 당신만의 parser를 만들수 있다. 그렇지만 우리는 toolkit과 함께 몇개의 parser를 제공한다.

        Lemur는 원래 연구를 위한 시스템이다. 그리고 여기 포함된 파서는 같은 파일 내의 여러 문서에 대한 indexing을 돕기 위해 만들어 졌다. 색인이 문서의 경계가 파일 내에서 어디에 있는지 알기 위해, 각각의 document는 시작과 끝에 대한 tag를 가지고 있어야 한다. 이런 tag는 HTML, XML tag과 비슷하고, 실제로 NIST의 Text REtreval Conference(TREC) 문서를 위한 형식이다.

      가장 많이 사용되는 파서는 TrecParser와 WebParser이다.

      TrecParser : 이 파서는  TEXT, HL, HEAD, HEADLINE, TTL, LP 필드에서 text를 인식. 예를 들면 다음과 같다.
              <DOC> 
                      <DOCNO> document_number </DOCNO> 
                      <TEXT> 
                              Index this document text. 
                      </TEXT> 
              </DOC>

      WebParser : 이 파서는 HTML comment에서 text뿐만 아니라 HTML tag(SCRIPT tag내의 text)를 제거한다. 문서 경계는 NIST 스타일 형식을 사용한다
              <DOC> 
                      <DOCNO> document_number </DOCNO> 
                      Document text here could be in HTML. 
              </DOC>

        Lemur는 이들 파서와 더불어 중국어(BG2313 encoding)와 아라비아어(CP1256 encoding) 파서를 제공한다. (더 많은 정보를 보려면 "Parsing in Lemur"를 보라.)

        만일 당신의 문서가 NIST의 형식이 아니라면 다음과 같은 방법으로 당신의 문서를 parse하고 index할수 있다.

      1. document전 후에 NIST 스타일 tag를 추가한다. 그리고 당신만든 것이나 Lemur의 application과 함께 Lemur에서 제공되는 parser중에 하나를 사용한다.
      2. 파서를 기록하고 index에게 application에 있는 PushIndex API를 이용해서 term을 넘겨준다.
      3. TextHandler class를 구현한다(parser가 당신의 document format을 제가하기 위함). 그 후 term을 한번 더 전처리 하기 위해 Lemer내의 다른 TextHandler와 함께 pipeline fashion을 사용할 수 있고, index를 구성하기 위해 InvFPTextHandler를 함께 쓸 수도 있다.(자세한 내용은 "Parsing in Lemur"를 보라.)

        문서가 한번 index되고 나면 BuildIndex나 IndriBuildIndex application을 이용하여 그 문서들을 index할 수 있다. build index applicaion에 다양한 parameter를 주고 싶다면 API documentation을 보라.

    3. Do the parsers add all words into the index?
        document에서 term으로 초기 parsing한 후, index에 term을 추가하기 전에 추가할 만큼 중요한 단어인지, 그대로 더할 것인지 아니면 stem form 대신에 index할 것인지, 어떤 단어를 acronym으로 인정할 것인지 (ex. WAC = Women's Army Corps) 의문이 생길 수 있들 것이다. Lemur에서 지원되는 feature로 acronym의 리스트도 있고, stopword('the', 'and', 'it' 같은 매우 일반적인 단어)를 무시하며, word stem들('stem', 'stemming', 'stems'는 모두 같은 term이다)을 indexing도 해준다. 이런 feature들은 BuildIndex에서 모두 지원된다.
    4. What type of indexes does Lemur have?
        Lemur는 현재 KeyfileIncIndex와 IndriIndex 두가지 의 index 타입이 가능하다. 다른 데이터를 index하고나, disk상에서 다르게 데이터를 표현할 수 있기 때문에 index들은 다른 값을 갖는다. 각각의 index는 "목차 테이블"파일을 가지고 있다. 이 파일에는 무엇이 index에 있는지 또는 index를 불러오는데 어느 파일이 필요한지에 대해 요약된 약간의 통계가 들어있다. 당신이 index를 사용하고자 할때 이 파일을 불러와야 한다. Keyfile index는 목차테이블 파일의 확장자가 ".key"이다. IndriIndex타입은 목차 테이블로 불러올 단일 파일이 없지만 index를 열기 위한 input 경로로 indriIndex의 루트 directory를 사용한다.

      Index Name Extension File
      Limit
      Stores
      Positions?
      Load
      Fast?
      Disk Space
      Usage
      Applications Add
      documents
      to Index 
      KeyfileIncIndex .key  no yes  yes Average BuildIndex  Yes, use
      BuildIndex
      IndriIndex   no yes yes most
      (automatically
      stores
      compressed
      version of
      original
      documents)
      BuildIndex or
      IndriBuildIndex
      Yes

      *기존의 문서를 업데이트 하지 않고 index에 새로운 document를 추가하는 것을 지원한다.

      두 index 타입에 대한 더 자세한 것은 the Lemur Tutorials에서 찾을 수 있다.

[출처] Lemur 홈페이지 :  http://www.lemurproject.org/lemur/indexingfaq.php

저작자 표시 비영리 변경 금지

Overview of the Lemur Toolkit

Posted 2009/01/21 15:33

Contents

  1. What is Lemur?
  2. What kinds of things can Lemur do?
  3. How can it be useful?
  4. What have people used Lemur for?
  5. How can I use Lemur?
  6. What does Lemur come with?
  7. What was Lemur written in, and what platforms does it work on?


    1. What is Lemur?
        Lemur는 언어 모델링(Language modeling)과 정보 검색(information retrieval, IR) 연구를 돕기위해 만들어진 툴킷이다. IR은 과 애드훅 (ad hoc)와 structured query, cross-language IR, summarization, filtering, categorization을 이용한 분산 검색(distributed retrieval)같은 기술을 포함하고 있다고 널리 알려져 있다. 시스템의 기본이 되는 구조체는 위에 설명한 기술들을 지원하도록 제작되어 있다. 우리는 유용한 여러 샘플 application들을 제공한다. 하지만 제작된 툴킷은 당신이 쉽게 독자적인 customization과 application 프로그래밍 할 수 있도록 해준다.
    2. What kinds of things cah Lemur do?
        Lemur 툴킷은 언어 모델링 method와 이뿐만 아니라 vector space model과 Okapi에 기초한 전통적인 method를 이용해서 기본적인 텍스트 검색 시스템을 지원한다. 시스템이 진화하면서 filtering과 질의/응답 같은 정보 기술의 넓은 영역에 대한 연구를 도와줄 것이라 기대받고 있다.
    3. How can it be useful?
        Lemur는 언어 모델링과 정보검색을 연구하지만, 고유의 색인을 만들어 쓰고 싶지 않고 오히려 새로운 기술과 알고리즘을 개발하는 데 초점을 두려하는 연구원들에게 실용적이다. 그렇지만 indexing과 함께 사용하거나 비교용으로 쓸수 있도록 Okapi와 KL Divergence같은 몇몇 기준이되는 검색 알고리즘을 제공한다.

        Lemur를 독자적인 검색 시스템을 만들기 위해 사용할 수 있다. ad hoc IR, distributed IR, IR using structured queries, IR using distributed indexes, clustering documents, summarization을 구현했거나 포함시켜 놨다. 그밖의 filtering tasks, webpage finding, passage finding, and web search engine 들을 위해 Lemur를 사용했다.
    4. What have people used Lemur for?
        이 툴킷은 ad hoc 검색을 위한 언어 모델링의 몇몇 다른 관점에서 실험을 하기 위해 사용된다. 예를 들어 문서 모델들의 smoothing strateg 비교를 위해 사용 한다면 쿼리는 표준 TREC collection 에서 쿼리 모델을 추정하여 method를 확장한다. 또 다른 예는 SIGIR2001을 참조 ("A study of smoothing methods for language models applied to ad hoc information retrieval") 

        이 툴킷은 filtering과 web page-finding을 포함해서 TREC에서 작업할 때도 사용가능하다. 정보 검색과 웹 검색 엔진 관련 수업에 사용되기도 했고, 또한 다양한 IR의 형태에서 question answering과 distributed network과 같은 연구 프로젝트를 지원해준다.
    5. How can I use Lemur?
        Lemur는 indexing과 검색에 대해 다용도로 완전 실용적인 많은 application들을 가지고 있다. 필요하다면 당장 가져다 쓸 수 있다. 추가적으로 Lemur가 LM과 IR의 연구를 돕기위해 작성된 이래로 abstract interfaces의 하위 클래스를 만들어서 새로운 검색 method를 만들거나 기존의 method를 기초하여 새로운 application을 만들 수도 있다.

        소스코드는 사용자의 연구, 개발, 교육활동을 하면서 툴킷을 수정할수 있도록 하기위해 제공된다. 수정한 것을 Lemur project 개발자에게 submit해도 좋다. 그러면 그들이 툴킷의 다음버전에 추가시킬 수도 있다.
    6. What does Lemur come with?
        Lemur는 indexing과 retrieval에 대한 library들을 빌드하기 위해 부수적으로 모든 소스코드와 makefile이 필요하다(under a CMU and UMass licensing agreement). 윈도우에서는 pre-compile된 라이브러리와 실행파일을 다운받을 수 있다.

        Lemur는 현재 다음과 같은 것들이 지원된다.
      1. indexing
        1. English, Chinese and Arabic text
        2. word stemming (Porter and Krovetz stemmers)
        3. omitting stopwords
        4. recognizing acronyms
        5. token level properties, like part of speech and named entities
        6. passage indexing
        7. incremental indexing
        8. in-line and offset annotation support
      2. Retrieval
        1. ad hoc retrieval (TFIDF, Okapi, and InQuery)
        2. passage retrieval
        3. cross-lingual retrieval
        4. language modeling (KL-divergence)
        5. query model updating for pseudo feedback
        6. two-stage smoothing
        7. smoothing with Direchlet prior or Markov chain
        8. relevance feedback
        9. structured query language
        10. suffix-based wildcard term matching (Indri Query Language only)
      3. Distributed IR
        1. query-based sampling
        2. database ranking (CORI)
        3. results merging (CORI, single regression and multi-regression merge)
      4. Document Clustering
      5. Summarization
      6. Simple text processing 

        Lemur toolkit은 Lemur에 포함된 method를 이용해서 검색을 하는 Lemur index와 stand-alone GUI가 사용하는 CGI 코드를 포함하고 있다. Lemur의 부수적인 모든 application list를 보려면, Lemur Applications page를 보라.

        Lemur toolkit은 application을 사용하기 위한 약간의 샘플 데이터 파일과 test script를 포함해서 다운받아진다. 결과물은 웹사이트에서 볼수 있다.

    7. What was Lemur written in, and what platforms does it work on?
        Lemur는 C++을 주로해서 작성되었고, GUI는 Java/Swing으로 작성되었다.

        Unix(linux and solaris)와 Windows XP에서 호환된다. 비록 우리가 지금 표면적으로 지원해 주지는 않지만, 사람들은 cygwin이나 Windows 2000, windows NT에서 구동시키기도 한다.

[출처] Lemur 홈페이지 : http://www.lemurproject.org/lemur/overview.php

저작자 표시 비영리 변경 금지
 Abstract. Large inverted index들은 지금까지도 웹 스케일의 검색 엔진을 구성할 때 표준이 되고 있다. 빠른 접근성을 위해  inverted index들은 내부적으로 색인되어 있고 그로인해 필요하지 않은 문서들은 재빨리 무시해버릴 수 있다. 이것의 목적은 inverted list안에 어떻게 하면 효율적으로 compressed perfect skip list 를 넣을 수 있는가 하는데 있다.


1 Introduction

  웹 검색엔진들의 탄생은 전통적인 inverted index 기술들에 대해 새로운 도전을 초래했다. 특히 eager (또는 term-at-a-time) query evaluation은 lazy (또는 document-at-a-time) query evaluation으로 바뀌게 되었다. 첫번째 사례로 쿼리 안의 단어 중의 하나의 inverted list가 먼저 계산된다. (보통, 가장 빈도가 적은 단어를 선택한다[4].) 그리고 다른 list들과 합쳐지거나 걸러내진다. 대신 lazy evaluation을 하면 쿼리를 만족하는 각 document를 차례차례로 검색하면서 inverted list들이 병렬적으로 스캔된다.

  Lazy evaluation은 여러 inverted list들이 동시에 지속적으로 유지되어야 한다. 이 operation을 효과적으로 수행하기 위해 skip method는 호출한 사람이 주어진 포인터보다 크거나 같은 첫 문서의 포인터에 빠르게 도달하게 해주는 것이 가능해야 한다. 이 문제에 대한 고전적인 해결책[1]은 inverted list가 그 안에 skip에 대한 정보를 가지고 있어야 한다는 것이다. 일정한 간격마다 추가적으로 약간의 정보(문서의 포인터와 그 포인터에 도달하기위해 건너뛰어야 하는 bit의 수로 이루어진 한쌍의 정보)가 skip을 표현하는 것이다. [1]에 나오는 skipping의 분석은 스킵이 단어가 나오는 주기의 제곱근 간격을 두게 되어야 하고 한 레벨의 skip이면 대부분 충분하다고 결론을 내린다.

  그렇지만 위에서 한 분석은 두가지 중요한 한계점을 가지고 있다.
1. 위치에 대해서 전혀 고려하지 않는다. 즉, 문서안에서 단어가 나오는 정확한 위치의 기술이나 application에 엮인 추가적인 데이터를 우습게 보고 있다.
2. 기본으로 eager evaluation을 기반으로 하고 그 결과가 lazy evaluation으로 확장될 수 없다. 
  이런 이유로 우리는 granularity의 수준이 매우 높은 self-index inverted list의 일반적인 method를 이야기할 것이다. 이 method는 문서 record 구조나 inverted index의 사용 패턴에 어떤 가정도 하지 않는다. skip은 주어진 포인터(또는 주어진 포인터의 양)에 의해 항상 여러 low-level read, bit-level skip과 함께 수행될 수 있다. 그럼에도 불구하고 index의 크기는 몇 퍼센트 정도밖에 증가하지 않는다.

  우리 기술은 특히 in-memory index에 도움이 된다. 즉 index를 RAM에서 유지하기 위해 문서검색 대부분의 시간을 inverted list의 scanning과 decoding에 쓰고 동시에 압축률을 높이는 것이다. 이 문서에 기록된 모든 결과는 MG4J에서 구현되었고 다음 주소에서 이용 가능하다.

http://mg4j.dsi.unimi.it/.


2 Perfect Embedded Skip Lists for Inverted Indices

Perfect skip lists.
 
Skip list [3]는 각각의 원소들이 순서를 갖고있는 리스트이지만, 필요에따라 리스트에서 현위치보다 앞으로 건너 뛸수 있는 자료구조이다. 더 정확히 말하자면, skip  listxi의 모든 item마다 x0, x1, . . . , xn−1처럼 오름차순으로 아이템이 정렬된 singly linked list이고, 다음 item을 참조하는것 이외에도, item의 skip tower라고 불리는 hi ≥ 0인 여분의 참조값을 가지고 있다. 이 타워의 t번째 참조값은 hjt이며, 이것은 j > i를 만족하는 첫번째 item을 말한다.

  이제 perfect skip list에 대해서 이야기해보자. deterministic skip list(원래는 임의의 term으로부터 공식화된 것이다)는 inverted list에 딱 알맞다. 이제 2개의 제한용 변수를 정해보자.

  1. list안의 item들의 갯수
  2. tower의 최대 높이

  단순화 하기 위해, 이상적인 경우(infinite perfect skip list)에서 부터 시작하자. LSB(x)는  x가 유효한 최소 bit (Least Significant Bit of x)으로서 x는 양의 정수이고 x = 0인경우 LSB(x) = ∞ 이 된다. 그 다음, hi=LSB(i)인 infinite perfect skip list에서 item xi의 skip tower 높이를 정의한다. 우리는 h+1개이상의 참조값을 갖는 tower가 없고, infinite perfect skip list에 존재하는 모든 참조값들은 item이 T보다 작거나 같은 인덱스를 참조하며, 첫번재 조건도 위반하지 않을 때 주어진 높이 h와 크기 T에 관해서 완벽하다고 말한다.  

Theorem 1. T개의 item과 최대높이가 h인 perfect skip list 내 원소 i에서 tower의 높이는 min(h, LSB(k),MSB(T − i)) + 1, where k = i % 2h 이다. 여기서 MSB(x) 는 x의 최대 유효 bit (most significant bit of)이고,  x는 양의 정수값을 갖는다. 만일 x가 0이면 MSB(x) = −1. 특히 i < T - T % 2h 인 경우 타워의 높이는 min(LSB(k),MSB(T mod 2h−k))+1 = min(h,LSB(k))+1

  inverted list의 모든 포인터를 직접 addressing하면 관리하기 힘든 index가 만들어진다. 따라서, q중에 1개의 item만 indexing한다. 여기서 q는 item의 최소 addressable block을 나타내는 고정 값(quantum)이다. Figure 1 은 perfect skip list의 예이다.

Fig1. T = 31개의 item, q = 2, h = 3인 perfect skip list. 첫 번째 줄은 k의 값을 나타낸다. 두 번째 줄은 각자의 h-bit binary 표현이다. 두개의 block으로 만들어진 리스트로, 나중을 위해(L의 defective Bolck = 15개 item) 
의 binary 표현도 있다. 대신 하기 위해 만들어진 참조 값이 존재할 수 없다 (
값을 최소값으로 하면 이 값들이 버려지기 때문이다).

Embedding Skip Lists into Inverted Indices
우리가 Inverted-index에 Embed-skip-lists를 넣으려 할 때 첫 번째 문제는 우리가 완벽히 선형적인 방법으로 자료에 접근하고 싶다는 것이다. 그러다보니 앞에서 이야기했던 알고리즘을 직접 사용할 수 없다. 우리는 참조된 item의 offset뿐만 아니라 그곳에 포함된 포인터도 저장해야 한다. 

Pointer Skips.
N개 document들의 집합을 생각해 보자. 각각의 term t의 상대적 출현 빈도를 pt라고 하자. Bernoulli model [4]에 따르면 모든 term t는 각각의 document에 독립적인 pt확률로 등장한다. 결과적으로 임의의 변수는 
 document로 pointer skip할 때 표준편차
와 정규분포
에 의해 더 가까운 값으로 표현된다. halving model을 사용한 tower의 top이 아닌 pointer skip을 예측해보자. level s의 pointer skip은 2로 나눈것을 포함하는 s+1의 skip과 차이를 갖는다 (표준편차가
가 된다).

Gaussian Golomb Codes.
이제 0근처에 정규적으로 분포하는 정수값들에 대한 coding 문제가 남았다. 우리는 주어진 정규분포에 대하여 최고인 Golomb code를 이용해 근사값을 계산한다. 물론 이것은 분포에 대한 최적의 코드가 아니다. 그러나 σ >> 1 인 경우 우수한 성능을 보이고, Golomb modulus는 닫힌계에 대하여 쉽게 근사값을 구할 수 있도록 해준다. 정수들이 정규분포 σ상에 분포할 때 최적의 Golomb code화 된 modulus는 다음과 같다. 

Bit Skips.
bit skip에 대한 우리의 전략은 pointer skip과 많이 비슷하지만 결정적 차이점을 갖는다. bit skip의 분포를 바르게 디자인 하는 것이 매우 어렵다는 것이다. 우리는 quantum의 평균 bit길이를 근거로 하는 γ이나 δ같은 universal code와 연결하는 prediction scheme을 제안한다.

3 Inherited Towers

  이전 섹션에서 말한바와 같이, tower의 정상으로 갈수록 많이 분산되고 압축하기도 힘들어 진다. 이상하게 보일지 모르지만 우리의 다음 목표는 tower의 정상에 모두 기록하는 걸 피하는 것이다. inverted list를 선형적으로 scanning할 때, search fingers[2]처럼 지금까지 모은 모든 "skip knowledge"(fig 2)로 상속된 tower를 유지하는 것이 가능하다. 

  만일 defective한 블럭이 있다면 계승된 entry들이 높이 h까지 도달하지 못할지도 모름에 주의해라(Fig 1의 오른쪽 부분). 보편성을 위해서 q = 1이라 하자.
Fig2. list를 scanning한 것(q = 1, h = 5). 현재 우리는 높이가 2인 element x = 22에 위치한다. 상속받은 tower는 회색으로 표현 되어 있고, 굵은 것에서 상속된 것이다.
Theorem 2. 상속받은 tower에서 길이 L인 defective block에 대해 가장 높은 유효 entry는
이다.
이때
bit-by-bit exclusive or 이다.

위의 계산 결과는 우리에게 다음과 같은 것을 알려준다. 최고 높이가 h'인  nontruncated tower는 top entry와 동일한 h'+1 level의 entry를 상속한다. 결과적으로 만일 list가 처음부터 travers되면, nontruncated tower의 top entry는 생략할 수 있다. top entry의 생략은 기록되는 entry의 수를 반으로 줄이고 우리가 절(paragraph)의 처음에서 봤듯이, skip structure의 크기도 한층 줄인다.


Experimental Data and Conclusions
  우리는 약 50GiB정도의 parse된 text(index는 count와 occurrence를 포함한다.)을 가지고 있는 .uk 도메인으로부터 13Mpage의 일부 스냅샷을 가져와서 그것에 대한 indexing 통계를 모았다. document의 crawl order에서 보여주듯이 스냅샷 분포가 매우 치우치게 된다. 임의의 높이를 갖는 tower에 embeded perfect skip list를 더하면 q = 32일때 크기가 2.3%(317MiB) 증가하고, q = 64일때 1.23%증가한다. 제곱근 간격으로 인덱싱 할 경우 0.85% 증가한다. 동일한 skip 구조체를 pointer skip에 대해 Gaussian Golomb code대신 γ나 δ를 이용해서 압축하면 각각 42%와 18.2%의 pointer skip크기의 증가를 초래한다.

  물론 속도가 우리 주 관심사이다. skip list에 추가적인 기록으로 인한 overhead는 선형 scan의 수행 시간을 5%이상 증가시키지 않는다(평균 0.5%). 반면 일반적인 or를 이용한 형태에서 복합적으로 생성된 query에 대해서는 제곱근 간격으로 했던것 보다 20 ~ 300%의 속도 증가를 보인다.


References

    1. Alistair Moffat and Justin Zobel. Self-indexing inverted files for fast text retrieval. ACM Trans. Inf. Syst., 14(4):349–379, 1996.
    2. William Pugh. A skip list cookbook. Technical report UMIACS-TR-89-72.1, Univ. of Maryland Institute for Advanced Computer Studies, College Park, College Park, MD, USA, 1990.
    3. William Pugh. Skip lists: a probabilistic alternative to balanced trees. Commun. ACM, 33(6):668–676, 1990.
    4. Ian H. Witten, Alistair Moffat, and Timothy C. Bell. Managing Gigabytes: Compressing and Indexing Documents and Images. Morgan Kaufmann Publishers, Los Altos, CA 94022, USA, second edition, 1999.


Original Reference

Boldi, P. and Vigna, S. Compressed Perfect Embedded Skip Lists Quick Inverted-Index Lookups. Lecture Notes in Computer Science, 3772 Springer-Verlag, Berlin, Germany. 2005.
저작자 표시 비영리 변경 금지
« PREV : 1 : 2 : 3 : 4 : NEXT »