'indexing granularity'에 해당되는 글 1건

역색인 구조에서 주요 단계를 기억해보자.
1. 색인할 문서들을 수집
2. 텍스트를 토큰화
3. 토큰의 전처리 과정으로 언어학적 처리
4. 각 term이 발생하는 문서를 색인

이번 Chapter에서 우리는 먼저 문서의 기본 단위를 어떻게 정의할 것이며 character sequence를 어떻게 결정할 것인지를 명백하게 말한다(Section 2.1). 그럼 우리는 몇몇 명사가 언어학적으로 토큰화에 따른 이슈와 시스템이 사용할 term들의 vocabulary를 결정할 전처리 과정을 상세하게 검토한다(Section 2.2). 토큰화(Tokenization)는 문자 스트림에서 토큰을 잘라내는 과정이다. 언어학적 선처리는 색인되어지는 term들의 집합인 토큰의 동등한 클래스를 만드는 것을 다룬다. 색인은 Chapter 1과 4에서 다룬다. 이제 우리는 posting list들의 구현으로  되돌아온다. Section 2.3에서 우리는 더 빠른 질의처리를 위해 확장된 posting list data 구조체를 검토한다. 그리고 Section 2.4는 구문 핸들링과 확장 Boolean 모델과 웹상에서 일반적으로 표현하는 근접 질의 처리에 적합한 postings list data 구조체를 다룬다.


2.1 Document delineation and character sequence decoding
2.1.1 Obtaining the character sequence in a document
 색인 과정에 입력값인 디지털 문서들은 파일이나 웹 서버에서 전형적인 byte의 집합이다. 처리 과정의 첫 번째 단계는 byte sequence를 선형의 character sequence로 변환하는 것이다. ASCII로 표현된 평범한 영어 텍스트의 경우는 평범하지만, 종종 꽤 복잡하다. character의 순서는 여러가지 single-byte 혹은 multibyte 인코딩 (UTF-8나 여러나라 혹은 vendor의 특정 표준과 같은) 중의 하나로 인코딩되어질 것이다.

우리는 올바른 인코딩을 결정할 필요가 있다. Chapter 13에서 논의될 classification를 배울 기계로 간주되어질 수 있지만 종종 휴리스틱 방법에 의해 다루어진다. 우리는 byte sequence를 character sequence로 디코딩한다. 문서들이 어떤 언어로 작성이 되었는지에 대한 증거를 남겨야 하기 때문에 선택된 인코딩을 저장할 지도 모른다.

 character들은 Microsoft Word Doc 파일과 같은 몇몇 이진 표현이나 zip 파일과 같은 압축된 형태 이외로 디코딩되어져야 할 지도 모른다. 다시, 우리는 문서 형태를 결정해야 하고, 적당한 디코더가 사용되어져야 한다. 평범한 텍스트 문서들조차도, 추가적인 디코딩이 행해져야 할 필요가 있다. XML 문서 (Section 10.1, page 180)에서, &amp와 같은 character 엔티티들은 올바른 character로 표현해주기 위해 디코딩되어질 필요가 있다.  즉. &amp의 &. 마지막으로 문서의 본문 파트는 처리되지 않을 다른 유형 이외를 추출해야 할 필요가 있다. 이것은 XML 파일을 위해 요구되어지는 핸들링일 것이다. 만일 그 markup이 무시되어진다면,  우리는 거의 확살하게 postscript나 PDF 파일로 이런 행위를 원할 것이다. 이 책에서는 이러한 이슈들에 대해서 더 이상 다루지 않는다. 그리고, 앞으로 우리의 문서들은 charater들의 리스트로 가정한다. 상업용 산출물은 보통 문서의 형태와 인코딩에 대해 광범위하게 지원한다.  왜냐하면 사용자들은 그들의 자료로 작업하고 싶어하기 때문이다. 종종 그들은 디스크상에 어떻게 인코딩되었는지는 알지 못하고 문서들을 어플리케이션 내의 텍스트로서 여긴다. 이러한 문제는 문서 포맷을 디코딩하고 character들을 인코딩할 소프트웨어 라이브러리를 라이센싱하면서 해결되어진다.

 텍스트가 선형 character sequence라는 생각은 그림 2.1과 2.2에서 보는 것과 같이 텍스트가 2차원적이고 혼합 순서(mixed-order) character인 아라비아 언어와 같은 몇몇 글 표기법(writing system)에 의해 질문들이 생길 소지가 있다. 그러나, 몇몇 복잡한 글 표기법의 관습에도 불구하고, 근원적으로 표현되어지는 소리의 sequence는 있다. 그러므로 본질적으로 선형 구조체는 존속한다. 이것은 그림 2.1에서 보는 것과 같이 아라비아 문자의 디지털 표현에서 표현되어지는 것이다.

2.1.2 Choosing a document unit
 다음 구문은 색인을 위한 문서의 단위가 무엇인지를 결정하는 것이다, 사실 우리는 색인의 목적을 위해 문서는 고정된 단위라고 가정한다. 예를 들어, 우리는 문서로서 하나의 폴더에서 각 파일들을 취한다. 그러나 다른 무엇인가를 하길 원하는 당신에겐 많은 경우가 생길 수 있다. 전통적인 Unix(mbox-format) 이메일 파일은 하나의 파일에 순차적인 이메일 메세지(이메일 폴더)를 저장하지만, 당신은 각 이메일 메세지가 분리된 문서라고 여긴다. 많은 이메일 메세지는 첨부된 문서들을 포함한다. 그리고 당신은 각 이메일 메세지와 첨부물들을 분리된 문서로서 생각하고 싶을 것이다. 만약 이메일 메세지가 첨부된 zip 파일을 가지고 있다면 당신은 zip 파일을 디코딩하고 싶을 것이고 그것을 포함한 각 파일을 분리된 문서로 여기고 싶을 것이다. 반대의 방향으로 가보면, latex2html과 같은 웹 소프트웨어의 여러가지 조각들은 당신이 single 문서라고 여기는 것들(예를 들면, PowerPoint 파일이나 LATEX 문서)을 취하고, 그것들을 각 슬라이드나 subsection에 대해 분리된 HTML 페이지로 나누고, 분리된 파일로서 저장한다. 이런 경우에, 당신은 여러 파일들을 하나의 파일로 합치길 원할 것이다.

 일반적으로 매우 긴 문서에 대해서 색인 단위(index granularity)의 이슈가 더 있다. 책의 컬렉션에 대해서, 일반적으로 하나의 문서로 전체 책을 색인하기 위하는 것은 나쁜 생각이다. Chinese Toys에 대한 검색은 첫 번째 chapter에 존재하는 China와 마지막 chapter에 존재하는 Toys를 언급한 책을 가져올 것이다. 그러나 이것은 질의에 대한 연관성을 만들 수 없다.  대신 우리는 작은 문서(mini-documnet)로서 각 chapter나 단락을 색인하기를 원한다. 매치는 좀 더 연관성이 있을 것이다. 문서가 좀 더 작아지기 때문에 사용자들은 문서 내에서 연관된 구절을 찾기가 훨씬 쉬워질 것이다. 그러나, 거기서 왜 멈추느냐? 우리는 작은 문서로서 개별적인 문장을 다룰 수 있다. 여기에 precision(정확도) / recall(재현율)의 tradeoff가 있다는 것은 명백하게 된다. 만일 단위가 매우 작다면, term들은 몇몇 작은 문서들 전반에 분산이 되어 우리는 중요한 구절를 놓칠 수 있다. 그런데, 단위가 매우 크다면 우리는 그럴싸한 매치를 얻을 경향이 있고 사용자들이 연관성 있는 정보를 찾가기 어렵다.

 큰 문서 단위가 가지는 문제점은 명백하거나 암시적인 검색(Section 2.4.2와 7.2.2)의 사용에 의해 완화되어질 수 있다. 우리가 넌지시 말한 결과 생성 시스템 선응에서의 tradeoff는 Chapter 8에서 논의된다. 색인 단위(index granularity)의 이슈, 그리고 특히 멀티 레벨의 단위(granularity)에서 동시에 문서를 색인할 필요성은 XML 검색에서 현저하게 나타난다. 그리고 Chapter 10에서 다시 과제로 삼는다. 정보 검색 시스템은 단위의 선택들을 제공하기 위해 디자인되어진다. 잘 만들어지기 위한 이러한 선택을 위해 시스템 개발자들은 문서 컬렉션과 사용자 그리고 사용자들의 정보 필요성과 사용 패턴들에 대한 이해도가 좋아야한다. 우리는 적당한 크기의 문서 단위 뿐만 아니라 필요하다면 분할 혹은 결합 파일의 접근 방법까지도 선택되어졌다고 가정한다.

** 이전 글 **
1. Boolean retrieval (Introduction, 1.1 An example information retrieval problem)