RAG 시스템 구축과 단계별 튜닝 하기

RAG, 검색 증강 생성 시스템은 거대 언어 모델의 고질적인 문제인 환각 현상을 방지하고, 기업 내부 데이터나 최신 정보를 정확하게 반영하기 위한 필수적인 아키텍처입니다.

RAG 시스템은 단순히 문서를 데이터베이스에 넣고 검색하는 기술이 아닙니다.
파이프라인의 각 단계가 유기적으로 연결되어 있으며, 어느 한 단계에서 품질이 저하되면 최종 답변의 신뢰성이 무너집니다.
대다수의 초기 프로젝트가 단순히 텍스트를 분할하여 벡터 데이터베이스에 넣는 기본 스플리터 단계에서 실패를 경험합니다.

성공적인 RAG 아키텍처를 구축하기 위해 각 구성 요소별 핵심 쟁점과 이를 정밀하게 튜닝하는 실무적인 방법을 상세히 살펴보겠습니다.

1. 청크 튜닝 단계

RAG의 첫 단추는 입력 문서를 적절한 크기의 덩어리인 '청크'로 쪼개는 것입니다.
벡터 검색의 품질이 떨어지는 근본적인 원인은 대부분 이 청킹 단계에서 발생합니다.

청킹의 딜레마

단순히 글자 수를 기준으로 문서를 자르면, 문장 한가운데가 잘리거나 문맥이 끊어지는 현상이 발생합니다.
임베딩 모델은 맥락을 벡터 공간에 투영하기 때문에, 앞 문장의 끝부분과 뒷 문장의 앞부분이 어설프게 섞인 청크는 임베딩 품질이 극도로 저하됩니다.

단어 단위나 단순 문장 부호 기준의 정규식 스플리터 역시 한계가 명확합니다. 문맥상 하나의 의미를 지니는 문단이 여러 개로 쪼개지거나, 반대로 서로 전혀 다른 주제가 하나의 청크로 묶일 수 있기 때문입니다.

고도화된 청킹 접근법

• 형태소 분석기 및 토크나이저 활용: 언어적 특성을 반영하여 문장 구조를 정확히 인식하는 형태소 분석기나, LLM이 사용하는 토크나이저 기반의 스플리터를 사용하면 문맥적 단절을 최소화할 수 있습니다.

• 의미론적 분리: 연속된 문장 간의 임베딩 유사도를 측정하여, 의미가 급격히 변하는 시점을 기준으로 청크를 경계 짓는 방식입니다.

LLM을 활용한 청크 검증 프로토콜

인간이 수백만 장의 PDF 문서 청킹 결과를 직접 전수조사하는 것은 불가능합니다.
따라서 context window가 큰 고성능 LLM에게 원문과 분할된 청크 데이터를 함께 제공하고 프롬프트를 통해 검증을 의뢰해야 합니다.
이때 LLM에게 평가를 요청해야 하는 핵심 항목은 크게 세 가지입니다.

1. 임베딩 적합성 평가: 이 청크가 벡터화되었을 때 사용자 지리와의 유사도 검색이 원활하게 이루어질 수 있는 구조인가?

2. 의미론적 독립성: 청크가 하나의 완전한 의미를 담고 있는가? 예를 들어, 첫 번째 문장은 '날씨' 정보이고 두 번째 문장은 '음식' 정보라면 하나의 임베딩 값으로 표현하기 부적합하므로 잘못된 청킹으로 판정합니다.

3. 정보 유실 검증: 원문 페이지에는 존재하지만, 청킹 프로세스를 거치면서 누락된 핵심 정보가 있는가?

청크 튜닝 방법 및 주의점

품질 평가 결과가 미흡하다면 스플리터 알고리즘 자체를 교체하거나, 청크 크기 및 중첩 구간 파라미터를 미세 조정해야 합니다.

주의 사항
대규모 데이터를 비교하고 청킹 품질을 평가하는 작업은 고도의 추론 능력을 요구합니다.
매개변수 규모가 작은 경량 모델은 컨텍스트 오버플로우가 발생하거나 토큰 생성 제한에 걸려 중간에 분석을 포기하기 쉽습니다.
따라서 이 검증 단계에는 비용이 들더라도 상용 high-tier 모델을 사용해야 합니다.

2. 임베딩 모델 및 벡터 검색 튜닝 단계

청킹이 완료된 데이터는 임베딩 모델을 통해 벡터로 변환되어 벡터 데이터베이스에 저장됩니다.
사용자의 질문 역시 동일한 임베딩 모델로 벡터화되어 데이터베이스 내에서 코사인 유사도등을 기반으로 검색됩니다.

검색 품질 테스트 데이터셋 자동 생성

500개의 청크가 데이터베이스에 저장되어 있다면, 시스템이 제대로 작동하는지 검증할 평가 셋이 필요합니다. 이 역시 LLM을 활용해 자동화합니다.

• 고성능 모델 활용 시: 500개의 청크를 대량으로 입력하고 "이 청크들을 검증할 수 있는 예상 사용자 질문 200개를 생성하고, 각 질문에 매칭되는 참조 청크와 모범 답안 쌍을 도출하라"고 한 번에 지시합니다.

• 경량 모델 활용 시: 컨텍스트 제약으로 인해 한 번에 처리하지 못하므로, 청크를 3개씩 루프를 돌며 나누어 투입하면서 "질문 2개를 생성하라"는 방식으로 여러 번 반복 수행합니다.
  시간적 여유가 없고 예산이 충분하다면 전자의 방식을, 비용을 아끼고 시간이 충분하다면 후자의 방식을 선택합니다.

이렇게 확보된 '질문-청크-답변' 그라운드 트루스 셋을 기준으로 실제 벡터 검색을 수행한 뒤, LLM이 예측한 참조 청크와 벡터 DB가 찾아온 청크의 일치도 및 수량을 비교하여 검색 품질 지표를 산출합니다.

임베딩 단계의 주요 튜닝 전략

품질 측정 후 벡터 DB가 산출한 코사인 유사도 스코어와 실제 의미적 연관성이 불일치할 경우, 다음과 같은 튜닝을 집행합니다.

• 임베딩 모델 교체: 251차원 수준의 낮은 차원을 출력하는 경량/노후 모델은 의미적 조밀함이 떨어집니다. 이를 768차원 또는 그 이상의 고차원을 지원하는 최신 임베딩 모델로 교체합니다.

단, 사용하는 벡터 DB에 따라 고정 차원만 지원하는 경우가 있으므로 데이터베이스 스펙을 사전에 확인해야 합니다.

• 질문 기반 임베딩: 원문 청크 자체를 임베딩하는 대신, LLM을 거쳐 "이 청크 내용을 질문할 만한 예상 사용자 질의"를 역으로 추출한 뒤 그 질문들을 임베딩 키로 등록하는 기법입니다.
  사용자 실제 질의와 시스템 내에 저장된 예상 질문간의 임베딩 유사도가 원문 자체를 비교할 때보다 훨씬 높게 형성되기 때문에 검색 정확도가 비약적으로 상승합니다.

3. 하이브리드 검색 및 키워드 튜닝 단계

벡터 기반의 시멘틱 검색은 의미적 유사성과 오타 교정, 의도 파악에는 강하지만, 고유명사, 품번, 시리얼 넘버, 특정 키워드의 정확한 매칭에는 취약합니다.
실무 환경에서 RAG의 성능을 보장하려면 벡터 검색 단독으로는 부족하며, 전통적인 키워드 검색을 결합한 하이브리드 리트리버를 구성해야 합니다.

키워드 검색 엔진의 결합

가장 널리 쓰이는 방식은 BM25 알고리즘 기반의 풀텍스트 인덱싱 기능을 제공하는 Elasticsearch 등을 연동하는 것입니다.

• 통합형 DB: 키워드 검색 플러그인과 벡터 인덱스를 동시에 구동하여, 하나의 엔진 내부에서 키워드 검색 후 벡터 검색을 순차적으로 수행하거나 두 결과에 가중치를 부여하여 합산 스코어를 산출합니다.

• 독립형 벡터 DB: 자체적인 자동 키워드 인덱싱 기능이 약하므로, 개발자가 파이프라인 상에서 문서로부터 직접 핵심 키워드를 추출하여 메타데이터 형태로 밀어 넣어주어야만 하이브리드 검색이 구현됩니다.

질의 키워드 추출

사용자가 입력한 문장 형태의 검색어를 그대로 키워드 검색 엔진에 전달하면 형태소 분석의 한계로 인해 검색 품질이 떨어집니다.
따라서 검색 파이프라인 중간에 LLM을 배치하여 사용자의 질문에서 쿼리로 던질 핵심 키워드만 정제하여 추출해달라"는 전처리 단계를 거치는 것이 필수적입니다.

4. 리랭킹 단계

검색 엔진을 통해 1차로 걸러진 상위 검색 결과가 실제로 유저의 질문과 밀접한 연관이 있는지 다시 한 번 정밀하게 서열을 재정리하는 단계가 리랭킹입니다.
1차 리트리버는 속도를 위해 가벼운 계산을 수행하므로, 리랭커를 통해 정확도를 최종 보정해야 합니다.

크로스 인코더 와 LLM 리랭커 비교

• 크로스 인코더 리랭커: 질문과 검색된 문서를 하나의 인코더에 동시에 쌍으로 입력하여 깊은 상호작용을 계산하는 모델입니다.
  학습된 가중치에 따라 고정된 스코어를 출력하므로 속도가 빠르지만, 프롬프트를 통한 미세 제어가 불가능하여 비즈니스 도메인과 성향이 맞지 않으면 모델 자체를 교체해야 합니다.
  구조상 질문 1개와 문서 10개가 있다면 총 10번의 추론 연산을 개별적으로 수행해야 하는 번거로움이 있습니다.

• LLM 기반 디코더 리랭커: LLM 생성 모델에게 질문과 1차 검색 결과 10개를 통째로 프롬프트로 제공한 뒤, "이 질문에 대해 가장 관련성이 높은 순서대로 문서 목록을 다시 정렬하고 랭킹 스코어를 부여하라"고 요청하는 방식입니다.
  프롬프트를 통해 랭킹 기준을 유연하게 조정할 수 있어 강력하지만, 토큰 비용과 컨텍스트 관리 부담이 존재합니다.

도메인에 특화된 인코더 리랭커를 적용했을 때 성능 변화가 미미하거나 불필요한 레이턴시만 유발한다면, 과감히 리랭킹 단계를 파이프라인에서 제외하고 청킹과 프롬프트 고도화에 집중하는 구조적 판단도 필요합니다.

5. 프롬프트 튜닝 및 최종 생성 단계

정제, 검색, 하이브리드 결합, 리랭킹까지 거쳐 최종적으로 엄선된 컨텍스트는 시스템 프롬프트에 삽입되어 LLM에게 전달됩니다.
모델은 이 컨텍스트를 바탕으로 최종 답변을 생성하게 됩니다. RAG 시스템의 최종 성패는 이 검색 결과들을 LLM에 어떻게 주입하고 제어하느냐에 달려 있습니다.

프롬프트 엔지니어링의 핵심 쟁점과 편향

아무리 앞선 단계에서 최적의 참고 문서를 잘 검색해왔더라도, 컨텍스트를 반영하는 생성 프롬프트가 정교하지 못하면 모델은 검색된 내용을 무시하고 본인이 기존에 학습한 지식으로 답변하거나, 엉뚱한 맥락에 집중하게 됩니다.

특히 RAG 시스템에서는 '검색 결과에 대한 편향'이 강력하게 작용합니다.
프롬프트의 제어 강도가 너무 강하면 다음과 같은 부작용이 발생합니다.

컨텍스트 편향 부작용 예시
시스템 내부에 충분히 답변 가능한 내장 지식이 있거나, 검색 결과가 조금 부족하더라도 다른 에이전트 기능을 통해 보완할 수 있는 상황임에도 불구하고, 프롬프트에 "반드시 주어진 검색 결과 안에서만 답변하고, 없으면 모른다고 하라"고 절대적인 제약을 걸어두면 모델은 조금이라도 매칭이 안 될 때 무조건 "제공된 문서에는 관련 내용이 없습니다"라며 방어적으로 답변을 거부해 버립니다.

따라서 최종 답변 단계의 튜닝은 실제 생성된 답변이 사전에 정의된 평가 데이터셋의 정답과 일치하는지 비교 검증하면서, 검색 문서가 부재할 때의 예외 처리 흐름, 예를들어 외부 툴 호출 또는 기본 지식 기반 답변 전환 로직과 시스템 프롬프트의 제약 조건을 섬세하게 조율하는 작업이 수반되어야 합니다.