위의 두가지 식이 루씬에서 순위를 결정하는 식이 되겠다. 정확히 DefaultSimilarity라고 볼 수 있다.(현재 Lucene in Action 책의 식과 다르다.)

여기서 .f[0-9]* 라는 파일에 저장이 되는 값이 lengthNorm이라는 함수로 계산된 값인데.
식은 (float)(1.0 / Math.sqrt(numTerms)) 이와 같이 정의가 된다. numTerms은 해당 텀이 속해있는 Field의 Term의 갯수를 의미한다. 그래서 짧은 Field의 경우 굉장한 스코어상의 이득을 볼 수 있다.

이 이득에 관한 그림은 아래와 같다.

그림을 보면 numTerms<5의 경우일때 스코어링이 굉장히 급박하게 상승하는것을 볼 수 있다. 그래서 짧은 필드일 경우 상위에 랭크될 수 밖에 없다.
Occams Razor의 뜻처럼 짧고 간결한것이 더 명확하다는 가정을 가지고 이걸 제안했다고 하고, 긴 문서에서는 당연히 색인어의 출현빈도가 높을 수 밖에 없다는게 자명해서 이렇게 한것이지만 이 부분에 대한 논란은 많을거 같다는 생각이 든다.

세미나 발표시 부장님께서 코사인 정규화 쪽을 보라고 하셔서 봤고 코사인 정규화와는 비슷했지만 더 다른 정보를 얻기위해 검색을 해보았다.

찾은 논문은 Document Ranking and the Vector-Space Model 이다.

여기서 quary와 문서와의 유사도를 추출해 낼때 Vector-Space 모델을 사용을 하고 있다. 코사인 척도를 구하는데 쓰이는 식은 아래와 같다.

여기서 분모의 값들에서 문서별로 모든 색인어의 가중치를 구하는 부분에서 엄청난 연산상의 부하가 걸리는걸 논문의 저자는 착안을 해서 다른 방법으로 Approximative normalization 방법을 제안하고 테스트 결과를 보여줬다. (가중치는 tf, idf로 구성되어 있는데 tf, idf는 미리 연산하여 저장해 놓을 수 없기 때문이다. 왜냐면 문서라는건 있다가도 없을 수 있기 때문이지. 쩝)

문서안에 나타난 텀의 갯수의 square root를 취해서 제안을 했다. 그래서 계산도 간략할 뿐더러 분모 부분의 normalization factor를 미리 색인에 저장해 놓고 사용할 수도 있다.

그래서 Lucene에서는 .f[0-9]* 까지의 정규화 파일을 미리 유지하고 있는것이였다.

비교 결과는 아래와 같다.

Lucene에서는 어느정도 정확도 측면에서 약간의 희생을 하지만 문서 검색 속도면에서 상당한 이득을 추구한 것이다. 하지만 이 논문에서는 짧은 문서에 대해서의 고려는 전혀 하지 않고 있기 때문에 짧은 문서에 대한 맹점을 보완할 필요가 있지 않을까 한다.
위와 같이 Approximative normalization의 다른 방법을 찾아보는것도 많은 도움이 될거라는 생각을 해본다.
한번 이 부분에 대해서 문서조사와 고민을 해볼 필요가 있을거 같다.

Lucene에서 정규화를 위한 인자에 대한 정리 by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.