잉여의 생각저장소

참고

Efficient and robust approximate nearest neighbor search using HNSW 논문

C++ HNSW implementation with python bindings

Lucene95HnswVectorsFormat code

배경

 ANN(Approximate Nearest Neighbor)이란 공간에서 query 벡터와 유사한 벡터(문서, 이미지 등이 학습된 데이터)들을 빠르게 검색하는 알고리즘 이다. Approximate라 표현하는 이유는 ANN이 반환한 벡터들이 실제 정답셋이 아니다. 벡터 크기가 보통 1000차원 이상 크고 학습하는 데이터도 규모있는 서비스 경우 수 억건이 넘어가기에 실제 정답을 구하는 비용이 크다. 효율적으로 계산하기 위해 recall(재현율) 및 precision(정밀도)를 기준치 이상 유지하며 빠르게 검색하는 알고리즘들이 개발되고 있다.
(http://ann-benchmarks.com/ 참고)
 

이번 글은 ANN 알고리즘 중 HNSW에 대해 알아보자. HNSW는 본래 c++ 기반으로 위 참고 github에서 먼저 공개되었고 Lucene9x, ES8x 부터 적용되었다. Lucene에서는 native java로 변환하여 적용되었으며 SIMD 등 칩에 최적화하는 과정이 빠져있어 c++보다 성능이 떨어질 수 있다. 참고로 현재 recall 대비 가장 빠른 검색 성능을 내는 알고리즘은 2020년 구글이 공개한 ScaNN 이다.

분석

1. NSW

NSW는 공간상의 벡터들을 배치하고 이들을 적절하게 연결하여 벡터 간 탐색 가능하도록 만드는 알고리즘이다. 크게 벡터를 저장하는 방식(Dense, Sparse ...), 거리 함수, 그리고 벡터를 연결하는 알고리즘(방향성 그래프 기반)으로 구성한다.

그림1 은 편의상 2차원 공간에 4개의 벡터들로 NSW를 구성한 예시이다. M은 이웃 수를 나타내며 보통 10 ~ 20개로 구성한다. 제한된 이웃 수로 효율적인 NSW를 구성하기 위해 아래 두 가지 목표를 설정한다.

1. 최소 방문으로 원하는 목적지 탐색
2. 탐색 불가능한 노드가 없도록

1번은 NSW 내 임의의 두 벡터를 선택했을 때 최단경로 길이의 평균을 최소화 하는 것이다. 2번은 edge(이웃)가 방향성을 가지기 때문에 발생하는 탐색불가능 노드를 최소화 하는 것이다. 예를들어 아래와 같은 상황을 만들면 ANN 성능이 크게 떨어진다.

그림2 는 가장 가까운 벡터들로만 이웃을 구성했을 때 NSW 예시이다. 왼쪽 3개의 벡터들은 서로 연결되어 탐색 가능하지만 오른쪽위 벡터로 가는 길은 없다. HNSW 논문의 Algorithm 3(SELECT-NEIGHBORS-SIMPLE)은 단순 거리계산만 적용된 이웃탐색 알고리즘이며 사용하지 말라고 알려주는 것이다. 이를 대신하여 Algorithm 4(SELECT-NEIGHBORS-HEURISTIC)를 제안한다. 

Algorithm 4는 처음 이웃을 구할 땐 가장 가까운 벡터를 선택하지만 다음 벡터부터 이전에 선택한 방향과 다른 벡터들을 탐색하는 것이 특징이다. 아래 예시를 통해 자세히 알아보자.

그림3 처럼 벡터(노란색, q)가 새로 추가될 때 첫 번째 이웃은 가장 가까운 벡터를 선택한다.

이후 첫 번째 이웃과 직선의 중심에서 수직선을 그어 아래 파란영역에 포함된 벡터들을 모두 후보군에서 제외한다. 만약에 벡터가 3차원 공간이라면 2차원 평면이 기준이 되어 q와 먼 거리의 벡터들을 제외한다. N차원 공간에 대해 N-1차원으로 경계를 만드는 것이다.
(실제 알고리즘과 절차는 약간 다르지만 이 프로세스가 결과를 직관적으로 이해하기 편하다.)

이어서 두 번째 이웃으로 오른쪽위 벡터를 선택하고 마찬가지로 초록색 영역의 벡터들은 후보군에서 제외된다. 이처럼 SELECT-NEIGHBORS-HEURISTIC은 이웃들을 다방면으로 연결하여 그래프 내 강한연결요소(Strongly Connected Component)를 줄인다. (탐색 속도 증가) 또한 군집에서 멀리 떨어진 벡터를 연결하여 탐색 불가능 영역을 최소화 한다. (recall 증가, 논문 Fig. 2. 참고)

2. HNSW

HNSW는 Hierarchical Navigable Small World의 약자로 NSW를 수직 계층적으로 구성하는 것을 뜻한다. 앞서 설명한 NSW를 여러 계층으로 구성하여 탐색 시간을 줄이기 위함이다.

HNSW의 가장 하단 $Lv_0$ 에 실제 찾고자 하는 벡터들을 배치한다. 그리고 $Len(Lv_{n}) = log(Len(Lv_{n-1}))$ 이 되도록 레벨이 높을수록 벡터 수를 log-scale로 줄인다. 이 때 벡터를 선택하는 기준은 랜덤이며 각 $Lv$의 NSW는 독립적으로 동작한다. 최상위 레벨에는 하나의 벡터만 있으며 이 벡터가 시작 $ep$(entry point) 이다.

이 계층을 두는 이유는 검색 시 NSW에서 이웃들을 탐색할 때 최적의 시작위치($ep$)를 구하기 위함이다. HNSW 논문에 Algorithm 1(색인)과 Algorithm 2(검색) 모두 이 계층을 통해 최적화되어 있으며 두 알고리즘은 유사해 검색 예시 하나로 설명한다.

Algorithm 1 (색인)

 

HNSW가 그림5 처럼 색인되어 있고 query 벡터가 들어오면 $Lv_2$의 $ep$ q부터 탐색을 시작한다. $Lv_2$의 $ep$는 탐색할 이웃이 없기 때문에 동일한 $Lv_1$의 $ep$에서 탐색을 진행한다. $Lv_1 ep$의 이웃들을 탐색하면서 query와 떨어진 거리를 기준으로 priorityQueue에 후보 벡터들을 저장한다. 이는 $ef$ 또는 $efConstruction$ 이라 명명한 후보군 제한 수 설정 때문이다. 그림5 예시와 달리 벡터가 많을 경우 검색 시 모든 벡터들을 탐색할 수 있다. 때문에 $ef$ 수를 넘은 만큼 priorityQueue에서 query와 가장 멀리 벡터들을 제거하여 검색 성능을 높인다.

 

$Lv_1 ep$는 그림5-2 처럼 query와 가까운 쪽으로 이동하고 이를 최종 $Lv_0 ep$로 한다. 마지막 $Lv_0$ 검색은 $ep$를 결과 priorityQueue에 저장하여 원하는 결과 벡터 수가 나올 때까지 탐색한다.

다음

Lucene9.x에 적용된 HNSW와 개선점

선행

Lucene 역색인(Inverted Index) 심층분석 1 - 전체 색인 구조

Lucene 역색인(Inverted Index) 심층분석 2 - FST

참고

Lucene90 FST code

Lucene90 BlockTreeTerms code

Burst Tries - A Fast, Efficient Data Structure for String Keys 논문

분석

Burst Tries 논문은 너무 추상적이고 정답이 없는 문제를 다뤄 증명 대신 실험에 의한 효과 증명으로 결과를 입증한다. 따라서 이번 글에선 최적화 요소가 더 많이 적용되고 더 직관적으로 이해할 수 있는 Lucene 역색인 모듈들을 직접 분석한다.

1. BlockTreeTerms Writer

심층분석 1에서 대략적으로 다뤘듯이 Lucene은 색인할 Term 전체를 FST에 저장하지 않는다. Lucene의 역색인은 BYTE 단위로 Term을 잘라 common prefix는 FST에 저장하고 나머지 suffix들은 Block으로 묶어서 저장한다. 색인 전 과정은 BlockTreeTermsWriter가 담당하며 아래 정의 및 절차에 따라 진행한다.

1. Terms는 사전순 정렬을 전제로 하며 순차적으로 iteration 하며 common prefix를 찾는다.
2. 가장 긴 prefix를 기준으로 Block 가능성을 탐색한다.
   (예를들어 "abc", "abd"의 common prefix는 "a" 일수도 있지만 "ab"가 더 길어서 기준이 됨)
3. Block 구성에 필요한 최소 Term 수(MIN_BLOCK_SIZE)는 25, 최대 Term 수(MAX_BLOCK_SIZE)는 48개 이다.
4. MAX_BLOCK_SIZE 넘어서는 common prefix는 여러 Block들로 나눠 저장하며 이는 FloorBlock이라 한다.
5. Term에서 common prefix 이후 첫 BYTE를 label이라 한다. floorLeadLabel은 FloorBlock 첫 Term의 label 이다.
6. Block으로 묶으면 Pendings의 Term들이 하나의 SubBlock으로 대체된다.
   (그림1에서 "ab" ~ "abcz" Term들이 "ab" SubBlock이 됨)
7. Block은 Terms 뿐만 아니라 SubBlock도 저장할 수 있다. 때문에 .tim의 구조를 BlockTreeTerms 라 불린다.
8. Block 내 SubBlock 없이 Terms 만 있다면 LeafBlock이라 한다.

그림1의 "ab" leafBlock 생성과정을 통해 자세히 알아보자. BlockTreeTermsWriter는 common prefix를 가진 Term 수가 MIN_BLOCK_SIZE 이상이 될 때까지 Pendings를 탐색한다. "aa"로 시작하는 Terms는 하나이므로 "ab"를 기준으로 Terms 범위를 찾는다. ("aa"는 추후 "a" Block에 저장한다.) "ab" ~ "abcz" Terms는 40개로 MIN_BLOCK_SIZE 이상 MAX_BLOCK_SIZE 미만이라서 하나의 Block만 생성한다. Block 생성 시 FST에는 .tim FP, floor info를 저장하며 BlockTreeTerms에는 suffixes 및 postings FP를 저장한다.

"ab~" Terms는 Pendings에서 SubBlock으로 변환하여 하나의 요소가 된다. 이후 "ac~", "ad~", "ae~" 기준들로 Block 생성 시도하지만 MIN_BLOCK_SIZE를 넘지 못해 넘어간다. 이후 "b" Term을 처리하는 시점(leadLabel의 index가 바뀌는 시점)에 "a~" Pendings로 Block 생성 시도한다.

"a~" Pendings는 총 74개로 MAX_BLOCK_SIZE를 넘어 여러 Block들로 저장해야 한다. 이때도 label을 기준으로 Block들을 나누는 기준이 된다. 그림2 예시로 "a" ~ "acw" 까지 26개 Pendings가 묶인다. 이때까지 label은 'c'이며 "ada"를 탐색하는 순간 label이 'd'로 바뀐다. Block에 Pendings를 넣을 때 "ada" ~ "adx" 중 top 몇 개의 Pendings 만 넣을 수 없다. 현재 26개 Pendings로 구성하고 있는 Block에 MAX_BLOCK_SIZE를 채우기 위해 모자란 22개 "ad~" Terms만 Block에 넣을 수 없다는 뜻이다. "a" ~ "adx"로 Block을 구성하면 50개로 MAX_BLOCK_SIZE를 넘기에 "a" ~ "acw" 까지 최초의 "a~" Block을 생성한다. 첫 번째 Term이 suffix가 없으면 lead label이 -1 이다.

leadLabal이 'd' 인 상태로 나머지 Block 생성을 진행한다. "ad~" Pendings는 MIN_BLOCK_SIZE를 넘지않아 leadLabel 'e' 까지 탐색하고 "ada" ~ "aex" 까지 총 48개 Pendings로 Block을 생성한다. "ad~" Pendings는 MIN_BLOCK_SIZE를 넘지 않지만 "ae~" Pendings는 MIN_BLOCK_SIZE를 넘으면 어떻게 Block을 구성할 지 의문이 들 수 있다. 예를들어 "ad~" Pendings가 24개이고 "ae~" Pendings가 30개라면 총 54개로 MAX_BLOCK_SIZE를 넘기 때문이다. 하지만 이 경우는 존재하지 않는다. "a~" Pendings로 Blocks를 구성하는 시점에 "ae~" Pendings는 이미 MIN_BLOCK_SIZE를 넘어 하나의 SubBlock Pending으로 변해 있기 때문이다. 때문에 두 개의 서로 다른 labels로 Block 내 MAX_BLOCK_SIZE 이상 Pendings를 저장 할 수 없다. 그리고 MAX_BLOCK_SIZE는 이론상 (MIN_BLOCK_SIZE - 1)의 배수여야 한다.

SubBlock을 저장은 .tim의 경우 현재 FP 위치와 prefix Block FP의 차이만큼 저장한다. 그림2 예시로 "a"(-1) Block 내 "ab" SubBlock의 FP가 500이고 "ab~" Block의 FP가 20 이라면 next FP에 480을 저장하는 방식이다. BlockTreeTerms는 이렇게 간단하게 구현하지만 FST는 약간 복잡하다. 왜냐하면 "ab~" Block을 먼저 생성하고 "a~" Block이 나중에 생성 되었으므로 사전순으로 FST에 색인할 수 없기 때문이다. 이를 해결하기 위해 색인 중에만 BlockTree level에 따라 subIndices라는 child FST를 생성한다. Block 생성시 subIndice 병합하는 과정을 아래와 같이 거쳐 FST 생성 시 사전 순 입력을 보장한다. (BlockTreeTermsWriter::compileIndex 참고)

  public void compileIndex(
      List<PendingBlock> blocks,
      ByteBuffersDataOutput scratchBytes,
      IntsRefBuilder scratchIntsRef)
      throws IOException {

      ...

      // Copy over index for all sub-blocks
      for (PendingBlock block : blocks) {
        if (block.subIndices != null) {
          for (FST<BytesRef> subIndex : block.subIndices) {
            append(fstCompiler, subIndex, scratchIntsRef);
          }
          block.subIndices = null;
        }
      }
      
      ...
  }

  private void append(
        FSTCompiler<BytesRef> fstCompiler, FST<BytesRef> subIndex, IntsRefBuilder scratchIntsRef)
        throws IOException {
      final BytesRefFSTEnum<BytesRef> subIndexEnum = new BytesRefFSTEnum<>(subIndex);
      BytesRefFSTEnum.InputOutput<BytesRef> indexEnt;
      while ((indexEnt = subIndexEnum.next()) != null) {
        fstCompiler.add(Util.toIntsRef(indexEnt.input, scratchIntsRef), indexEnt.output);
      }
    }
  }

전반적인 프로세스 설명은 마치며 FST -> BlockTreeTerms -> Doc, Pos, Pay 절차 및 Codec을 간략히 정리하면 아래와 같다. Lucene은 끊임없이 최적화 요소를 적용하고 있어서 자세한 사항은 내부 구현 및 테스트로 확인해야 한다.

2. BlockTreeTerms Reader

색인에서 term을 찾고 데이터를 읽는 과정이다. 앞서 BlockTreeTermsWriter 과정 이해를 전제로 한다.

SegmentTermsEnum이 각각의 Segment에 대응하여 생성되고, 특정 term을 찾거나 전체 term들을 찾는 동작을 수행한다. SegmentTermsEnum은 Block의 depth 마다 SegmentTermsEnumFrame을 생성하고 읽기 상태에 따라 FST.Arcs, term 데이터를 관리한다. SegmentTermsEnumFrame이 Block을 읽는 역할을 수행하며 FloorBlock들도 한 Frame 내에서 읽는다.

Block을 읽는 동작과 Postings를 읽는 동작은 분리되어 있다. 즉 term을 찾을 땐 .tip/.tim 파일만 decoding 하고 해당 term의 Postings를 읽을 때 .doc/.pos/.pay 파일을 decoding 한다.

전체 Terms 탐색 (NextTerm)

1. 전체 탐색은 .tip에서 .tim 시작 FP만 참조할 뿐 .tip에서 검색하지 않는다.
2. .tim의 root Block에서 SegmentTermsEnumFrame을 생성하고, root Block의 term 들을 순차적으로 탐색한다.
3. 탐색할 때 NonLeafBlock(term이 아닌 Block)이 나오면 SegmentTermsEnumFrame를 하나 더 생성하고 depth가 증가한다.
4. 마치 tree 탐색처럼 모든 Leaf를 탐색하면 depth가 감소하여 다시 탐색하는 동작을 반복한다.

특정 Term 탐색 (SeekExact)

1. 특정 term 탐색은 .tip에서 term의 첫 번째 char부터 순차적으로 FST를 탐색한다.
2. FST에 char의 arc를 찾을 수 있다면 SegmentTermsEnumFrame을 생성하고 다음 char를 탐색한다.
   (이때 SegmentTermsEnumFrame에는 arc 정보와 FST의 output을 읽어서 저장한다.)
3. FST에서 찾을 수 있는 최대 길이의 prefix를 다 찾았다면 FloorBlock을 탐색한다.
4. FloorBlock들의 정보는 FST의 output에 VInt로 저장되어 순차적으로 탐색해야 한다.
5. 최종 확인해야 할 Block이 정해지면 해당 Block을 load 한다. (suffixs, stats, postings FP 정보)
6. suffixs를 탐색하여 해당 term이 매칭되는지 확인한다.
   
   

심화

Lucene 역색인 시공간 복잡도

MIN_BLOCK_SIZE, FST::BYTE가 색인의 크기, 검색 속도를 결정하는 중요한 값.

Block의 시공간 복잡도

• "a~" blocks 에는 "ab~" pendings가 MIN_BLOCK_SIZE개 이상 존재할 수 없다.
• "a~" blocks 의 가능한 모든 label의 경우의 수는 기본값 FST::BYTE의 크기이며 최대 256 이다.
• "a~" blocks 내 같은 label의 최대 pendings 수는 MIN_BLOCK_SIZE - 1 이다.
• "a~" blocks 내 최대 pendings 수는 BYTE x (같은 label 최대 pendings 수) 이므로 256 * (MIN_BLOCK_SIZE - 1) 이다.
• 그렇다면 최대 FloorBlock 수도 구할 수 있다. label이 최대 BYTE 가지 존재하고 label이 바뀌는 시점마다 FloorBlock을 생성 할 수 있다. label이 최소 2번은 바뀌어야 FloorBlock을 생성 할 수 있기 때문에 최대 FloorBlock 수는 BYTE1 / 2 이다.
  
  

MIN_BLOCK_SIZE 특성

• MAX_BLOCK_SIZE는 (MIN_BLOCK_SIZE - 1) 의 배수
• MIN_BLOCK_SIZE가 높을수록 FST와 BlockTreeTerms의 크기 및 깊이가 감소한다.
• MIN_BLOCK_SIZE가 높을수록 전체 Block 수는 감소하지만 FloorBlock 수는 지수배로 늘어난다.
  물론 MIN_BLOCK_SIZE가 1 ~ 5로 극단적으로 작다면 Block 및 FloorBlock 수 모두 늘어나고 검색효율도 떨어진다.
• MIN_BLOCK_SIZE가 높을수록 SeekExact 시 FST 탐색속도 빨라지고 BlockTreeTerms 탐색속도는 상당히 느려진다.
  애초에 FST가 빠른 탐색이 목적이기에 전체 검색속도는 FST 탐색이 감소한만큼 급격하게 늘어난다.
  FloorBlocks는 현재 순차적으로 탐색하기에 여기에서 병목 또한 늘어날 것으로 예상한다.
  FloorBlocks 탐색 개선요소 주석
  
  

FST::BYTE 가 커질 수록

• Block을 묶는 기준이 강화되서 총 Block 수 및 depth가 감소한다.
• 최대 FloorBlock 수가 늘어난다. (BYTE_SIZE / 2)
• FST 크기가 소폭 감소한다. 특정 Block에서 FloorBlock 수가 늘어 output이 커질 수 있지만 총 Block 수가 줄어드므로 전체 크기는 감소한다. FST 탐색속도는 언어에 따라 다를 수 있다. 예를들어 한글의 경우 BYTE2 이상으로 설정하면 불필요한 구간에서 node, arc가 발생하지 않아 검색속도 개선에 유리하다.
• BlockTreeTerms 크기가 증가한다. 더 세밀하게 term들을 쪼개지 못해 평균 FloorBlock 수가 증가 했으므로 탐색시간이 증가한다. depth가 줄어들어 크기는 감소할 수 있지만 묶지 못한 케이스가 많을 경우 suffix 데이터가 증가하여 전체 크기는 증가한다.

선행

이번 글은 Lucene 역색인 전체구조에서 FST 구조만 설명합니다.

Lucene의 FST는 Direct Construction of Minimal Acyclic Subsequential Transducers 논문을 기반으로 하며 TestFSTs 로 테스트할 수 있다.

목표

전체 역색인 과정에서 FST의 역할은 Terms의 prefix와 이와 매칭되는 tim의 FP(파일포인터)를 함께 저장할 수 있어야 한다. 또한 term 검색 시 log(BYTE x len(term)) 이내로 빠르게 찾을 수 있어야 하며, Segment 간 병합을 위해 사전순으로 Terms를 iteration 할 수 있어야 한다. 

Lucene에서 FST의 input은 Terms의 공통 prefix를 BYTE 단위로 쪼개 node로 생성하며, output은 .tim의 FP로 long 타입이다. 논문에서 output은 string으로 전제하였다. FST는 output 또한 공통부분을 추출하여 저장하기에 타입에 따라 효율이 크게 달라진다. 예를들어 "100"과 "101"는 공통부분이 "10" 이지만 100과 101은 공통부분이 100이다. 

논문분석

Definition 1.

Subsequential Transducer는 inputs, outputs와 상태 및 함수들로 구성된 tuple로 이 글에선 $\mathbb{T}$ 로 표현한다. Subsequential Transducer는 모든 상태가 결정되었음을 전제로 하며 이 뜻은 inputs 집단과 outputs 집단이 변하지 않음을 뜻한다. Lucene도 주기에 맞춰 Segment 내에서 색인할 때 추출된 Terms로만 FST를 구성할 뿐 기존 FST에 추가할 수 없다. FST에 input을 추가하거나 output을 변경할 때는 처음부터 새로 생성해야 하며 이는 Segment 병합 시 FST를 새로 생성하는 이유기도 하다.

$\mathbb{T}  =  <\Sigma, \Delta, S, s, F, \mu, \lambda, \Psi>$

$\Sigma \ \ is \ a \ finite \ input \ alphabet;$
$\Delta \ \ is \ a \ finite \ output \ alphabet;$
$S \ \ is \ a \ finite \ set \ of \ states;$
$s \in S \ \ is \ the \ starting \ state;$
$F \subseteq S \ \ is \ the \ set \ of \ final \ states;$
$\mu \ : \ S \ \times \ \Sigma \rightarrow S \ \ is \ a \ partial \ function \ called \ the \ transition \ function;$
$\lambda \ : \ S \ \times \ \Sigma \rightarrow \Delta^{*} \ \ is \ a \ partial \ function \ called \ the \ output \ function;$
$\Psi \ : \ F \rightarrow 2^{\Delta^{*}} \ \ is \ the \ final \ function;$

Subsequential Transducer의 구성은 위와 같다. $\Sigma, \Delta, S, F$ 는 집합이며 나머지 함수들은 파라미터와 결과 타입을 의미한다. $\mu, \lambda$ 의 첫 번째 파라미터는 node이며 두 번째 파라미터는 온전한 Term이 아닌 부분으로 쪼갠 Term의 일부다. $\lambda$의 결과 또한 공통 부분만 추출한 output의 일부를 표현한 것이다.

이해를 돕기위해 월별 데이터로 FST를 구성하면 위 과정을 거친다. 입력은 월별 영어 약자($\Sigma$) 이며 출력은 월별 말일($\Delta$) 이다. ○(compiled, 확정된), □(compiling, 계산중) 들은 node를 의미하며 $S$에 속한다. 각 함수의 결과 값은 node 및 arc에 저장되며 아래 예시처럼 동작한다. (Lucene FST 코드에서 정점을 node, 간선을 arc로 명명하여 이 글에서도 똑같이 표현한다.)

$\Sigma$ = {['a','p','r'], ['a','u','g'], ['d','e','c'], ['f','e','b'], ... }
$\Delta$ = {"30", "31", "31", ["28", "29"], ...}
$\mu$(s5, 'p') $\rightarrow$ s2
$\lambda$(s5, 'p') $\rightarrow$ "0"
$\Psi$(s1) $\rightarrow$ ""
$\Psi$(s8) $\rightarrow$ ["8", "9"]

$\mu, \lambda$ 의 확장함수($^*$) 들은 두 번째 파라미터로 하나의 문자가 아닌 prefix 문자열($\sigma$)을 받으며 아래 규칙을 따른다.

${\forall}r \in S, \forall\sigma \in \Sigma^*, {\forall}a \in \Sigma$ ($\Sigma^*$ 은 모든 prefix inputs 집합)
$\mu^*(r, {\sigma}a) = \mu(\mu^*(r, \sigma), a)$
$\lambda^*(r, {\sigma}a) = \lambda^*(r, \sigma)\lambda(\mu^*(r, \sigma), a)$

e.g.
$\mu^*$(t0, "apr") = $\mu$($\mu^*$(t0, "ap"), 'r') = $\mu$(s2, 'r') = s1
$\lambda^*$(t0, "apr") = $\lambda^*$(t0, "ap")$\lambda$($\mu^*$(t0, "ap"), 'r') = "30"$\lambda$(s2, 'r') = "30"

최종으로 input language 함수 $L$과 output 함수 $O_{\mathbb{T}}$ 정의는 아래와 같다.

$L(\mathbb{T}) \ = \{ \sigma \in \Sigma^* \ | \ \mu^*(s, \sigma) \in F \}$
$O_\mathbb{T}(\sigma) \ = \lambda^*(s, \sigma) \cdot \Psi(\mu^*(s, \sigma))$

e.g.
$L(\mathbb{T})$ = {"apr", "aug", "dec", "feb", ...}
$O_\mathbb{T}$("apr") = "30"

임의의 두 Transducers가 $L(\mathbb{T}), O_{\mathbb{T}}$ 의 입출력 값들이 모두 같다면 두 Transducers는 같다고(equivalent) 한다. 

Definition 2, 3.

정의 2, 3은 outputs 측면에서 Minimal Subsequential Transducer를 구성하기 위한 정리들을 설명한다. Minimal Subsequential Transducer란 Equivalent Transducers 중에 가장 node, arc 수가 작으면서 outputs 저장공간이 가장 작은 Transducer를 뜻한다.

정의2 는 $L(\mathbb{T})$ 집합의 prefix 집합 $D(\mathbb{T})$에 대하여 공통의 output을 가장 앞선 node에 배치하기 위한 $g_{\mathbb{T}}(u)$ 함수를 선언한다.

$D(\mathbb{T}) \ = \{ u \in \Sigma^* \ | \ {\exists}w \in \Sigma^* \ (uw \in L(\mathbb{T}) \ \}$
$g_{\mathbb{T}}(u) \ = \ \wedge_{w \in \Sigma^* \ \& \ uw \in L(\mathbb{T})} {\wedge}O_{\mathbb{T}}(uw) $ 
($\exists$는 존재함을 $\wedge$는 and 연산을 의미)

$D(\mathbb{T})$ 는 $L(\mathbb{T})$ 로 만들 수 있는 모든 prefix 집합.
$g_{\mathbb{T}}(u)$ 는 u로 시작하는 모든 input들의 output들을 모아 공통 부분을 추출한 것. 

e.g.
$u$ = "j" 일 때 $uw$ 집합은 {"jan", "jul", "jun"} 이며 각 output은 아래와 같음.

$O_{\mathbb{T}}$("jan") = "31"
$O_{\mathbb{T}}$("jul") = "31"
$O_{\mathbb{T}}$("jun") = "30"

i.g.
$g_{\mathbb{T}}$("j") = $O_{\mathbb{T}}$("jan") $\wedge$ $O_{\mathbb{T}}$("jul") $\wedge$ $O_{\mathbb{T}}$("jun") = "31" $\wedge$ "31" $\wedge$ "30" = "3"

정의3 은 $g_{\mathbb{T}}$ 함수를 활용하여 transducer의 총 $\lambda$ 합을 최소화 하기 위한 함수를 선언한다. 그리고 아래 조건을 만족하는 transducer를 Canonical Subsequential Transducer 라고 명명한다.

${\forall}r \in S, \forall\sigma \in \Sigma^*, {\forall}a \in \Sigma$
$(\mu^*(s, \sigma) = r \ \& \ !\mu(r, a)) \ \rightarrow \ \lambda(r, a) = [g_{\mathbb{T}}(\sigma)]^{-1}g_{\mathbb{T}}({\sigma}a)$
($!\mu$ 는 node가 존재하지 않을 때)

e.g.
$g_{\mathbb{T}}$("a") = "3"
$g_{\mathbb{T}}$("ap") = "30"
$\lambda$(s5, 'p') =  $g_{\mathbb{T}}$("a")$^{-1}g_{\mathbb{T}}$("au") = "0"

Canonical Subsequential Transducer는 논문에 언급한 것처럼 가장 앞선 node에 output을 최대한 많이 저장한다. 그림1 에서 ("jan", "31"), ("jul", "31") 을 저장하는 과정을 다시보자. $\lambda$(t0, 'j')가 빈 값이라면 $\lambda$(t1, 'a'), $\lambda$(t1, 'u') 두 arcs에 "31"을 저장하므로 중복이 발생한다. 그러므로 가장 앞선 node인 $\lambda$(t0, 'j')에 "31"을 저장하는 것이 공간을 최소화하는 방법이다. 

이후 ("jun", "30")을 저장할 때는 $g_{\mathbb{T}}$ 에 따라 $\lambda$(t0, 'j') = "3", $\lambda$(t1, 'a') = "1", $\lambda$(t2, 'l') = "1", $\lambda$(t2, 'n') = "0" 으로 바뀐다. 즉, 사전순으로 Term을 입력하면서 가장 앞선 node에 공통 output을 저장하여 공간을 최소화 한다. 자세한 증명은 인용 논문인 Minimization algotithms for sequential transducers에서 다루며 node, arc 빌드 과정은 다음 정리 이후 설명한다.

여기까지 Canonical Subsequential Transducer를 구성하기 위한 정의이다. 그리고 논문에서는 Canonical Subsequential Transducer 내에 equivalent node가 없다면 minimal Transducer라고 한다. 쉽게 설명하면 outputs까지 최적화 하였으니 중복된 node, arc를 제거하여 최소화하라는 것이다. 그림1 s1 node가 하나의 예시이며 특정시점 이후 node, arc가 모두 같을 때 해당 node를 재사용하는 과정을 다음 정리에서 설명한다.

Definition 4.

정의 4는 $\mathbb{T}  =  <\Sigma, \Delta, S, s, F, \mu, \lambda, \Psi>$ 가 아래 조건들을 만족할 시 마지막 Term의 prefix인 $w$ 를 제외하고 minimal이라고 한다. 다시 그림1 예시로 조건들을 설명하면 다음과 같다.

  1.  모든 node가 시작 node로 부터 접근 가능해야 한다.

  2. 사전순으로 마지막 단어인 "jul"의 prefix인 $w$의 node들은 아직 $\mathbb{T}$에 포함되지 않은 빌드 중인 상태(□) 이다.

      그리고 아래 정의와 조건을 만족한다.

$w = w_{1}^{\mathbb{T}}w_{2}^{\mathbb{T}}...w_{k}^{\mathbb{T}}, \ w_{i}^{\mathbb{T}} \in \Sigma, \ i \in 1...k$
$t_{0}^{\mathbb{T}} = s; \ t_{1}^{\mathbb{T}} = \mu(t_{0}^{\mathbb{T}}, w_{1}^{\mathbb{T}}); \ ... \ ; \  t_{k}^{\mathbb{T}} = \mu(t_{k-1}^{\mathbb{T}}, w_{k}^{\mathbb{T}})$ 
$T = \{ t_{0}^{\mathbb{T}}, t_{1}^{\mathbb{T}}, ..., t_{k}^{\mathbb{T}}\}$

$\forall{r} \ \in \ S, \forall{i} \ \in \ \{ 1 ... k\}, \forall{a} \ \in \ \Sigma$
$\mu(r,a) = t_i \leftrightarrow (i > 0 \ \& \ r = t_{i-1} \ \& \  a = w_i^{\mathbb{T}})$

   3. $S \setminus T$에 equivalent states 들이 없다. (즉, 모든 node, arc가 unique 함)

   4. $\mathbb{T}$는 Canonical Subsequential Transducer다.

정의4는 부분으로 구성된 Minimal Subsequential Transducer(이하 MST)에 새로운 node, arc를 추가하면서 minimal 상태를 유지하기 위함이다. 이를 위해 MST에 포함된 node(해당 node에서 출발하는 arcs 포함)를 ○로 표시하고 아직 계산 중인 $T$의 node들을 □로 표시한다. $T$ 에서 MST에 node를 추가하는 과정은 가장 끝의 node부터 시작한다. 그림1 예시로 "jul"에서 'l'에 해당하는 node 부터 minimal 상태를 유지한채 transducer에 입력하는 것이다. 이는 아래 보조정리들로 자세히 설명한다.

Lemma1은 $t_{k}$와 동일한 기존 node가 없을 때 이를 $\mathbb{T}$에 추가해도 minimal 이다.

Lemma2는 $t_{k}$와 동일한 기존 node인 p가 있을 때 $t_{k-1}$에서 $w_{k}$ arc의 target을 p로 가리켜도 minimal 이다.

Lemma3는 $t_{k}$와 동일한 기존 node의 조건을 말한다. 요약하면 동일한 노드는 final일 때 출력이 같아야하며 final이 아니면 가리키는 모든 arc 정보가 같아야한다.

다시 그림1의 마지막 사전순 단어 "jul" 에서 마지막 단어부터 $\mathbb{T}$에 추가한다. 이때 다음 단어인 "jun"과 common prefix인 "ju" 만 $T$로 남기고 'l' arc가 추가된다. $g_{\mathbb{T}}$("ju") = "3" 이므로 'l' arc의 output은 "1"이며 $w$ = "jun" 으로 바뀐다. 결과는 아래 그림2와 같다.

Lemma2에 의해 <$\mu$(t2,'l') = s1, $\lambda$(t2,'l') = "1">로 추가해도 $\mathbb{T}$는 minimal이다. 이후 ("MAR", "31)을 색인할 때 common prefix가 하나도 없으므로 t1, t2, t3를 $\mathbb{T}$에 추가해야 한다. Lemma3에 의해 $\mu$(t2,'n')는 s1을 가리키고 t1과 t2는 새로운 node로 추가된다. t1과 t2는 동일한 node가 없어서 추가된 것이므로 Lemma1에 의해 $\mathbb{T}$는 minimal이다.

종합하여 Minimal Subsequential Transducer를 생성하는 과정은 뜨개질과 유사하다. 구성할 모든 단어들을 사전 순으로 탐색하며 마지막 단어의 끝부터 공통의 input, output만 남기고 나머지 부분을 확정짓는 방식이다. 확정된 node들은 이후 수정할 수 없기에 뜨개질 중간에 튀어나온 올을 없애기 힘든 것과 같다. 한 번의 뜨개질로 minimal 상태를 만들어야 하므로 정렬되고 결정된(finite) inputs를 전제로 한다.

다음

이번 글에서 Lucene FST를 이해하기 위한 정의들을 다뤘지만 Theorem3, 4 및 Algorithm이 빠졌습니다. Theorem3, 4는 $T$에서 common prefix만 남기고 나머지 node, arc를 추가하는 상세한 과정과 증명인데 너무 길어서 위에 간략하게만 설명했습니다. 사실 여기까지도 다 읽으실 분들이 많지 않을 것 같아서 요청하시면 추가할게요!

Algorithm은 Lucene의 FST 기반으로 설명드리려 합니다. Lucene의 FST는 파일로 en/decoding 하기에 arc가 많을 시 binary search 할 수 있도록 codec을 구성합니다.

배경

Lucene의 문서 색인의 가장 작은 단위인 Segment 내에 다른 Segment 들과 독립된 색인을 필드별로 생성한다. 그 중 text 타입 역색인은 아래 그림 처럼 크게 3단계로 나뉜다. 예제 데이터는 "ace", "ant", "beautiful", "begin" 단어들로 색인했을 때 루씬 색인 파일 인코딩 구조를 간략화 한 것이다.

색인구조

1. tip

• terms(문서에 포함된 단어들)의 공통 prefix들을 저장하는 FST 자료구조.
• input은 term의 prefix, output은 tim의 FP(파일 포인터).
• term을 일정간격(BYTE1, 2, 4 지원)으로 잘라서 노드를 구성하며 트리 형태로 map 구현.
• FST는 input들의 공통 노드에 겹치는 output을 분리하여 저장하여 크기를 최소화 함.
• Direct Construction of Minimal Acyclic Subsequential Transducers 논문 기반.
• Lucene core util FST에 구현됨.

2. tim

• terms의 suffix들을 저장하는 Burst Tries 자료구조.
• 25 ~ 48개의 elements를 묶어 하나의 block을 생성. (위 예시는 실제와 달리 단순화를 위해 2개로 생성함)
• element는 suffix 또는 하위 block을 가리킴.
• suffix는 해당 term의 doc / pos / pay 의 시작 FP를 저장.
• block 내 하위 block은 특정 term이 아닌 모든 terms를 알파벳 순으로 찾기 위함이며 이는 Segment 병합 시 필요.
• Burst Tries: A Fast, Efficient Data Structure for String Keys 논문 기반
• Lucene core codecs lucene90 blocktree에 구현됨.

3. doc / pos / pay

• doc은 DocId(Segment내 부여된 문서 Id) 들을 저장한 skip list 자료구조.
  (DocId 들은 오름차순으로 저장하여 delta encoding 적용.)
• pos는 term의 위치 정보를 저장.
• pay는 term의 payload 정보로 score 계산 시 유저가 추가한 metadata.
  
  

심화

• Lucene의 역색인은 위처럼 크게 3단계로 구성된다. 이를 깊이있게 살펴보면 왜 term을 저장할 때 prefix, suffix를 나눠서 저장하는 지 의문이 생길 수 있다. Lucene은 전반적으로 검색성능이 떨어지지 않는 선에서 색인의 크기를 최소화하려 한다. 때문에 term에서 공통부분이 많은 prefix는 FST로 저장하고 공통부분이 적은 suffix는 단어를 쪼개지 않고 그대로 저장한다.

  FST                 Burst Tries
b -> e         |         autiful

• 예를들어 "beautiful" 단어를 저장할 때 "be"로 시작하는 단어는 무수히 많다. 때문에 이 단어를 검색할 때 공통 prefix는 Byte 단위로 하나씩 쪼개 node, arc 형태의 트리를 탐색하는 것이 유리하다. 하지만 "beaut"를 공통 prefix로 가진 단어들은 매우 적다. 때문에 suffix를 FST 구조로 "a -> u -> t -> i -> f -> u -> l" 형태로 만들면 공통부분이 없는데 단어 길이만큼 불필요한 node, arc가 생성된다.
  
  
• 효율적인 역색인을 위해 Lucene은 terms를 사전순으로 정렬하여 순차적으로 25 ~ 48개의 공통 prefix를 찾는다. 공통 prefix를 찾을 때 마다 prefix는 FST에 추가하고 나머지 suffix들은 Burst Tries에 추가한다. suffix 마다 해당 term의 doc / pos / pay FP 도 같이 저장하며 FST는 tip에 Burst Tries는 tim에 serialize 되어 저장한다.
  
  

다음