RAG 시스템의 핵심 아키텍처와 리랭커의 필요성
정보 검색 증강 생성 시스템의 목적은 사용자 질의에 가장 적합한 맥락을 제공하여 거대 언어 모델이 정확한 답변을 생성하도록 돕는 것입니다.
전체적인 흐름은 사용자의 질의가 시스템에 도착하는 것으로 시작됩니다.
1단계: 텍스트 임베딩과 차원의 이해
사용자가 시스템에 "LLM의 토크나이저를 설명해 줘"라는 질의를 던지면, 시스템은 이 문자열을 컴퓨터가 계산할 수 있는 수치적 형태로 변환해야 합니다.
이를 임베딩이라고 하며, 변환된 결과물은 연속된 숫자의 배열인 벡터가 됩니다.
임베딩 과정에서 생성되는 숫자의 개수를 차원이라고 부릅니다.
-
고차원 벡터: 표현할 수 있는 공간이 넓기 때문에 문장이 내포한 복잡하고 깊은 문맥적 의미를 더 많이 담아낼 수 있습니다.
연산 비용과 메모리 소모가 크지만 정보의 손실이 적습니다. -
저차원 벡터 : 연산 속도가 빠르고 인프라 비용이 적게 들지만, 복잡한 의미를 압축하는 과정에서 상대적으로 세밀한 문맥 정보가 유실될 수 있습니다.
2단계: 벡터 간 유사도 측정과 정규화
임베딩 공간에서 두 벡터가 얼마나 유사한지 판별할 때 주로 코사인 유사도를 사용합니다.
기하학적으로 두 벡터 사이의 각도를 측정하여 방향성이 얼마나 일치하는지 보는 지표입니다.
수식으로는 두 벡터의 내적을 각 벡터의 크기(L2 노름)로 나누어 정규화합니다.
벡터의 내적 연산만 수행할 경우, 벡터 자체의 절대적인 크기가 결과에 지대한 영향을 미칩니다.
즉, 특정 단어가 많이 반복되어 벡터의 길이가 길어지면 실제 문맥적 유사도와 무관하게 내적 값이 비정상적으로 커질 수 있습니다.
이를 방지하기 위해 벡터 db에 밀어 넣기 전 정규화 과정이 필수적으로 수반됩니다.
정규화는 다차원 공간에서 피타고라스 정리를 확장한 유클리드 거리 개념을 활용합니다.
벡터 내 모든 원소를 각각 제곱하여 더한 뒤 루트를 씌우면 벡터의 절대적 거리가 산출됩니다.
이 값으로 기존 벡터의 모든 원소를 나누어 주면, 벡터의 크기가 정확히 1인 단위 벡터로 변환됩니다.
모든 벡터의 크기가 동일해지면 크기에 의한 왜곡이 사라지므로, 순수하게 방향만 대조하여 유사도를 정확히 비교할 수 있는 상태가 됩니다.
3단계: Vector DB 검색의 한계와 리랭커의 도입
정규화된 질의 벡터를 벡터 데이터베이스에 입력하면 유사도 점수가 가장 높은 상위 개의 문서 청크가 검색 결과로 반환됩니다.
예를 들어 유사도 점수가 1에 가까운 순서대로 정렬되어 출력됩니다.
그러나 이 Vector DB의 일차적인 유사도 수치는 완전히 신뢰하기 어렵습니다.
밀집 벡터 검색에 사용되는 바이 인코더 구조의 임베딩 모델은 질의와 문서를 독립적으로 벡터화한 뒤 매칭하기 때문에, 단어 간의 상호 교차 주의 연산이 일어나지 않아 복잡한 도메인 지식이나 미묘한 문맥적 뉘앙스를 정밀하게 평가하지 못하기 때문입니다.
이러한 태생적 한계를 극복하기 위해 리랭커가 도입됩니다.
Vector DB로부터 다소 거칠게 검색된 개의 결과를 리랭커에 통과시켜 문맥적 유사도를 재평가한 뒤, 최종적으로 가장 신뢰도가 높은 개의 핵심 청크만 추출하는 과정을 거칩니다.
추출된 개의 정보는 시스템 프롬프트에 증강되어 LLM에 전달되며, 모델은 이 정제된 컨텍스트를 바탕으로 최종 답변을 생성합니다.
크로스 인코더 기반 리랭커의 메커니즘과 한계
전통적인 리랭커는 주로 크로스 인코더 방식으로 학습된 엔코더 모델을 사용합니다.
크로스 인코더는 특정한 모델 아키텍처의 이름이 아니라 신경망을 훈련시키는 학습 방법론을 의미합니다.
1단계: 학습 데이터 구조와 원리
크로스 인코더 모델을 구축할 때 표준적으로 사용되는 대표적인 학습 데이터셋은 마이크로소프트가 공개한 MS MARCO Passage Ranking 데이터셋입니다.
이 데이터셋의 구조를 보면 질의와 문서가 분리되어 있지 않고 하나의 입력 스트림으로 결합되어 있습니다.
버트 특유의 토큰 구조를 활용하여 입력의 시작을 알리는 [CLS] 토큰 뒤에 사용자의 질의를 배치하고, 문장 구분자인 [SEP] 토큰을 둔 뒤 대조할 문서를 결합하여 하나의 시퀀스로 모델에 입력합니다.
[CLS] + Query + [SEP] + Passage
학습 데이터셋은 일반적으로 하나의 질의에 대해 정답 매칭 문서 1~2개와, 관련이 없는 다수의 오답 매칭 문서로 구성됩니다.
정답일 경우 레이블을 1, 오답일 경우 0으로 지정하여 이진 분류 형태로 버트 모델을 미세 조정합니다.
모델은 입력된 질의와 문서 내 모든 단어 간의 연관성을 모든 트랜스포머 레이어에서 상호 참조 하면서 두 문장이 얼마나 긴밀한 관계를 갖는지 계산하는 법을 배웁니다.
2단계: 크로스 인코더 리랭커의 치명적인 한계점
크로스 인코더는 추론 시 질의와 문서를 동시에 입력받아 단 한 번의 순방향 연산으로 매우 정밀한 유사도 점수를 출력하므로 개별 연산 자체는 대형 디코더 모델보다 빠릅니다.
그러나 RAG 시스템 실무 환경에 적용하면 다음과 같은 한계에 직면합니다.
-
컴퓨팅 비용의 폭발적 증가: Vector DB에서 1차로 검색된 결과가 개라면, 리랭커는 질의와 각 문서를 하나씩 결합하여 총 번 모델을 호출해야 합니다.
검색된 청크의 개수가 40개, 100개로 늘어날수록 호출 횟수가 선형적으로 비례하여 증가하므로 병렬 처리를 하더라도 전체 인프라 비용과 응답 지연 시간이 심각하게 악화됩니다. -
컨텍스트 통합 판정 불가: 크로스 인코더는 질의와 '개별 문서 1개'의 관계만 독립적으로 평가합니다.
검색 결과 내에 내용이 거의 유사의 중복 청크가 다수 포함되어 있더라도, 개별 문서 단위로만 점수를 매기기 때문에 상위권 랭킹이 의미가 중복된 문서들로만 도배되는 현상을 막을 수 없습니다. 문서 전체를 거시적으로 비교하거나 상대적인 중요도를 파악하는 것이 불가능합니다. -
도메인 제어 및 프롬프트 주입 불가능: 인코더 모델은 오직 정해진 규칙 외에 추가적인 입력 형식을 받지 못합니다. 개발자가 "이 기업 문서에서는 오너 일가 관련 내용을 우대해라"라거나 "특정 정치적/상업적 텍스트는 제외해라" 같은 비즈니스 로직을 프롬프트 형태로 주입할 수 없습니다.
모델의 동작 방식을 바꾸거나 특정 도메인 지식을 반영하려면 반드시 전용 데이터셋을 구축하여 모델 자체를 다시 학습시켜야만 합니다.
또한 대다수의 오픈소스 크로스 인코더 모델이 서구권 데이터셋 기반으로 학습되어 있어, 한국적 정서나 특정 기업 내부의 상식과 동떨어진 기준으로 유사도를 평가하는 성향을 보입니다.
디코더 기반 LLM 리랭커의 부상과 실무 적용
인코더 기반 크로스 인코더의 경직성을 극복하기 위해 현대적인 RAG 시스템에서는 생성형 언어 모델인 디코더 기반의 LLM을 리랭커로 활용하는 추세입니다.
디코더 모델은 문장을 생성하는 데 특화되어 연산이 무겁다고 생각하기 쉽지만, 리랭커로 사용할 때는 출력 토큰을 극도로 제한하므로 매우 효율적으로 동작합니다.
1단계: 디코더 기반 리랭킹의 작동 원리와 장점
디코더 리랭커는 인코더처럼 문서를 한 건씩 쪼개어 수십 번 호출하지 않습니다.
대용량 컨텍스트 윈도우를 활용하여 프롬프트 내에 사용자의 질의와 Vector DB에서 찾은 수십 개의 문서 청크 전체를 통째로 집어넣고 단 한 번만 호출합니다.
-
통합적 컨텍스트 인지 능력: 모든 문서 청크가 하나의 프롬프트 공간 안에 동시에 상주하기 때문에, 모델은 문서들 간의 상호 연관성을 한눈에 파악합니다.
이를 통해 내용이 중복된 문서가 존재하면 상위권에서 배제하고 가장 완성도 높은 청크 하나만 선택하는 등의 유기적인 정렬이 가능해집니다. -
프롬프팅을 통한 자유로운 도메인 제어: 개발자가 원하는 정렬 지침과 평가 기준을 자연어로 상세히 규정할 수 있습니다.
기업의 정책, 특정 도메인의 가중치, 제외 규칙 등을 즉각적으로 반영할 수 있으므로 모델 재학습 없이도 비즈니스 요구사항에 유연하게 대응합니다. -
비용 효율성: 디코더 모델의 주요 비용은 텍스트 생성 시 발생하는 순차적 토큰 생성 연산에서 기인합니다.
하지만 리랭커 프롬프트는 최종 출력으로 가장 관련성이 높은 문서의 ID 순서만 짧게 요구하므로, 입력 컨텍스트가 크더라도 출력에 드는 연산 비용과 시간은 매우 적습니다.
2단계: 경량 모델의 컨텍스트 확장 기술 활용
인프라 리소스가 제한된 환경이나 로컬 서버에서는 수십만 토큰을 수용하는 대형 상용 모델을 상시 가동하기 부담스러울 수 있습니다.
이 경우 파라미터 수가 적은 경량 모델의 컨텍스트 확장 버전을 사용하면 훌륭한 대안이 됩니다.
자체 파라미터 규모는 4B 수준으로 작아 VRAM이 수 기가바이트에 불과한 저사양 GPU나 심지어 내장 그래픽 환경에서도 구동이 가능하지만, RoPE 위치 인코딩 기법 등의 보간 기술을 통해 입력 컨텍스트 창만 16K 또는 32K 이상으로 확장해 둔 특화 모델들이 존재합니다.
이러한 모델들은 긴 컨텍스트를 입력받았을 때 중간에 위치한 정보의 인지 능력이 다소 저하되는 현상이 발생할 수 있으나, 출력을 아주 짧게 가져가는 리랭킹 작업의 특성상 정보가 완전히 희석되기 전에 필요한 문서 번호 매칭 결과를 정확하게 밀어내므로 실무 환경에서 매우 높은 가성비와 성능을 보장합니다.
3단계: 실무형 LLM 리랭커 프롬프트 엔지니어링 및 구현 예시
개발자 관점에서 LLM을 순수한 알고리즘 공급 장치로 제어하기 위해서는 프롬프트를 작성할 때 모호한 일상어 표현을 지양하고, 시스템의 역할과 처리 단계, 예외 처리 규정을 명확한 개발 컨텍스트 문체로 기술해야 합니다.
아래는 실제 구동 가능한 고성능 리랭커 프롬프트 아키텍처의 예시입니다.
[시스템 프롬프트 지침]
귀하는 정보 검색 증강 생성(RAG) 시스템의 핵심 구성 요소인 '고정밀 검색 결과 재정렬 프로세서(Reranker)' 역할을 수행합니다. 입력으로 제공되는 사용자 질의(Query)와 검색 시스템이 일차적으로 수집한 문서 청크 리스트(Document Chunks 1 to N)를 상호 비교 분석하여, 질의의 맥락적 의도에 가장 부합하는 순서대로 재정렬하십시오.
[평가 및 정렬 지침]
1. 정보의 중복성 제어: 제공된 문서들 중 텍스트의 의미적 내용이 사실상 동일하거나 고도로 중복된 청크가 발견될 경우, 정보의 완결성이 더 높은 청크 하나만 상위에 배치하고 나머지 중복 청크는 하위로 강등시키거나 정렬 순위에서 제외하십시오.
2. 질의 의도 최우선 매칭: 단순히 단어가 중복 노출된 빈도보다, 질의가 요구하는 핵심 질문에 직관적이고 직접적인 해답을 담고 있는 청크를 우선순위로 판정하십시오.
3. 노이즈 배제: 문장의 길이가 길거나 주변부 설명이 장황한 문서보다, 핵심 정보의 적합성과 밀도가 높은 문서를 우대하십시오.[입력 데이터 포맷]
- User Query: {사용자 질의 문자열}
- Retrieved Chunks:
- Document [1]: {첫 번째 청크 텍스트}
- Document [2]: {두 번째 청크 텍스트}
- Document [3]: {세 번째 청크 텍스트}
[출력 포맷 요구사항]
서론, 부연 설명, 코드 블록 기호를 모두 배제하고 오직 연관성이 높은 문서의 인덱스 번호 배열만 의미적 중요도 내림차순으로 정확히 출력하십시오.
출력 양식: [정렬된 문서 번호 리스트]
[입력 데이터 및 실행 컨텍스트 예시]
User Query: 자바 환경에서 가비지 컬렉션(GC) 로그를 활성화하고 파일로 저장하는 JVM 옵션이 뭐야?
Retrieved Chunks:
- Document [1]: 자바 어플리케이션의 메모리 관리를 최적화하기 위해서는 가비지 컬렉터의 동작을 모니터링하는 것이 필수적입니다. GC의 종류에는 Serial, Parallel, CMS, G1, ZGC 등이 있으며 각 가비지 컬렉터마다 메모리를 회수하는 알고리즘과 Stop-The-World 시간에 차이가 존재합니다. 시스템의 규모에 맞는 선택이 필요합니다.
- Document [2]: 자바 9 버전 이후부터는 통합 로깅 프레임워크인 -Xlog 옵션을 사용하여 GC 로그를 관리합니다. 기본적인 GC 상세 로그를 파일로 기록하기 위한 대표적인 JVM 아규먼트 구성은 -Xlog:gc*,gc+age=trace:file=/logs/gc.log:time,uptime:filecount=5,filesize=100M 형태를 가집니다. 이를 통해 로그 로테이션과 파일당 용량을 제한할 수 있습니다.
- Document [3]: JVM 구동 시 가비지 컬렉션의 세부 동작을 파일로 남기고자 할 때는 로그 관련 옵션을 지정해야 합니다. 자바 9 이상 표준 스펙에서는 -Xlog:gc:file=/path/to/gc.log 옵션을 주입하여 구동 시 발생하는 세부적인 메모리 해제 이벤트를 텍스트 파일 형식으로 로컬 디스크에 영속화할 수 있습니다.
[LLM 최종 추론 출력 결과]
[2, 3, 1]
추론 결과를 분석해 보면 다음과 같습니다.
Document [1]은 가비지 컬렉터의 종류만 나열할 뿐 구체적인 옵션을 제공하지 않으므로 가장 낮은 순위로 밀려납니다.
Document [2]와 Document [3]은 둘 다 질문이 요구하는 구체적인 JVM 옵션을 담고 있지만, Document [2]가 로그 로테이션, 파일 개수 제한 등 실무적으로 훨씬 더 구체적이고 디테일한 옵션 문자열을 제공하므로 가장 높은 최상위 랭킹으로 정렬되었음을 볼 수 있습니다.
인코더 기반 시스템이 정체기를 겪고 있는 현 시점에서, 이와 같은 디코더 기반의 유연한 컨텍스트 처리는 RAG 성능 고도화의 표준 아키텍처로 자리잡고 있습니다.
