라이트리트리버: 초경량 쿼리 인코더로 구현한 고속 LLM 기반 텍스트 검색

초록

라이트리트리버는 문서 인코딩에 전체 규모 LLM을 유지하면서, 쿼리 인코딩을 사전 캐시된 토큰 임베딩 조회와 평균만으로 수행하도록 설계한 비대칭 검색 아키텍처이다. 이를 통해 A800 GPU 기준 1,000배 이상의 쿼리 인코딩 속도 향상과 전체 파이프라인에서 10배 이상의 처리량 증가를 달성했으며, BeIR·CMTEB 등 23개 벤치마크에서 평균 95% 수준의 검색 정확도를 유지한다.

상세 분석

라이트리트리버는 “문서‑쿼리 비대칭”이라는 핵심 아이디어에 기반한다. 기존의 대칭형 듀얼 인코더는 문서와 쿼리 모두에 동일한 파라미터 규모의 LLM을 적용해 높은 표현력을 확보하지만, 실시간 쿼리 서비스에서는 GPU·메모리·지연시간 측면에서 비효율적이다. 저자는 문서 측면에서는 여전히 전체 LLM을 사용해 풍부한 컨텍스트 정보를 압축하고, 쿼리 측면에서는 두 단계(학습‑캐시‑서비스)를 도입한다.

1️⃣ Dense 쿼리 인코더: 학습 단계에서 전체 LLM을 이용해 각 토큰의 임베딩을 얻고, 토큰 평균으로 쿼리 벡터를 구성한다. 토큰 간 상호작용이 없으므로 토큰 임베딩은 사전 계산이 가능하다. 전체 vocab(수십만 토큰)에 대해 임베딩을 한 번 저장하면, 서비스 시에는 단순 조회와 평균 연산만으로 쿼리 벡터를 생성한다. 이는 GPU 연산을 완전히 배제하고 CPU 메모리 접근만으로 처리할 수 있어, 1,000배 이상의 속도 향상을 만든다.

2️⃣ Sparse 쿼리 인코더: 쿼리 토큰 빈도 자체를 바로 sparse 벡터로 사용한다(전통 BM25와 유사). 문서 측면에서는 LLM의 최종 레이어를 vocab 공간으로 투사하고, ReLU·log‑saturation·max‑pooling을 적용해 희소성을 강화한다. 학습 시 FLOPs regulator를 통해 과도한 밀집성을 억제한다. 결과적으로 쿼리 쪽에는 전혀 모델 연산이 필요 없으며, 단순히 토큰 카운트만으로 sparse 벡터를 만든다.

3️⃣ 하이브리드 결합: dense와 sparse 점수를 선형 보간해 최종 순위를 산출한다. 이는 각각의 장점을 살리면서도 전체 파이프라인의 복잡성을 크게 낮춘다.

4️⃣ 효율성 평가: A800 GPU에서 전체 LLM을 쿼리 인코더로 사용할 경우 초당 3040건 정도의 처리량에 머물렀지만, 라이트리트리버는 10배 이상(≈300400건/초)으로 끌어올렸다. 메모리 사용량도 캐시된 임베딩(수 GB) 수준으로 감소했다.

5️⃣ 성능 유지: 15개의 영어 BeIR 태스크와 8개의 중국어 CMTEB 태스크에서 평균 nDCG@10이 0.95배 수준(예: 0.920.96)으로 기존 대칭형 LLM‑based 모델과 격차가 미미했다. 특히 Llama‑1B8B, Qwen‑1.5B~7B 등 다양한 규모의 LLM에 대해 동일한 설계가 적용 가능함을 보였다.

6️⃣ 제한점 및 향후 과제: 토큰 임베딩 캐시가 vocab 크기에 선형적으로 증가하므로, 초대형 vocab(예: 500K+)에서는 메모리 부담이 커질 수 있다. 또한, 쿼리 평균 방식은 토큰 순서 정보를 완전히 무시하므로, 복합적인 질의(예: “2022년 미국 대통령 선거 결과는?”)에서 미세한 의미 차이를 포착하지 못할 가능성이 있다. 향후에는 가벼운 순서‑인코더(예: 1‑layer Transformer)와 캐시 결합, 혹은 동적 토큰 선택 기법을 도입해 정확도‑효율성 트레이드오프를 더 세밀히 조정할 여지가 있다.

전반적으로 라이트리트리버는 “문서는 무겁게, 쿼리는 가볍게”라는 설계 철학을 실증적으로 입증했으며, 대규모 LLM을 실제 서비스에 적용하려는 기업·연구기관에 실용적인 로드맵을 제공한다.