기존 RAG 한계 극복! ImpRAG 작동 원리와 2단계 훈련법 완벽 정리

LLM이 스스로 필요한 정보를 찾는 법: 쿼리 없는 RAG, ImpRAG 분석

AI 개발자라면 RAG(Retrieval-Augmented Generation)의 강력함을 잘 아실 겁니다. LLM이 최신 정보나 방대한 지식에 접근해 더 나은 답을 내놓게 돕는 핵심 기술이죠.

하지만 기존 RAG에는 명확한 한계가 있었습니다. 바로 ‘검색(Retrieval)’과 ‘생성(Generation)’이 따로 논다는 점입니다.

이는 마치 유능한 셰프(생성 LLM)가 요리를 하려는데, 직접 재료 창고(지식 코퍼스)에 갈 수 없는 것과 같습니다. 대신 ‘텍스트로 된 완벽한 재료 목록(명시적 쿼리)’을 조수(검색기)에게 줘야 하죠. 만약 셰프가 정말 필요했던 재료와 조수가 가져온 재료가 다르면(불일치), 요리(답변)는 엉망이 될 수밖에 없습니다. 특히 처음 보는 형식의 작업(요리)을 맡았을 때 이 문제는 더 심각해집니다.

만약 LLM이 “지금 이 정보가 필요해”라고 스스로 판단하고, 별도 쿼리 없이도 알아서 정보를 가져와 답변을 생성할 수 있다면 어떨까요?

최근 Meta와 럿거스 대학 연구진이 이 질문에 대한 답으로 “ImpRAG”라는 새로운 쿼리 없는(query-free) RAG 시스템을 제안했습니다. (출처: https://arxiv.org/pdf/2506.02279)

ImpRAG는 검색과 생성을 하나의 통합 모델로 결합하여, 모델이 자신의 정보 요구를 ‘암시적(implicit)’으로 표현하게 만듭니다. 이 글에서는 ImpRAG가 어떻게 기존 RAG의 한계를 극복했는지, 그 핵심 아이디어와 훈련 방식을 중심으로 심층 분석합니다.

ImpRAG의 핵심 아이디어: LLM을 ‘슬라이스’하여 통합하다

ImpRAG의 가장 독창적인 점은 LLaMA 3 같은 사전 훈련된 LLM을 여러 전문 그룹으로 ‘슬라이스’한다는 것입니다. 모델을 수직으로 쪼개서 각 레이어 그룹이 검색과 생성이라는 특화된 작업을 동시에, 그리고 유기적으로 수행하도록 최적화합니다.

LLM이라는 하나의 회사를 세 개의 전문팀으로 나눈다고 상상해 보세요.

1. Bottom Layers (하단 레이어, \(\mathcal{L_{B}}\)): 검색팀 (Retriever)

모델의 하단 레이어들은 ‘검색팀’ 역할을 합니다. 이들은 입력된 프롬프트(요청서)를 보고, ‘아, 이 작업을 위해서는 이런 정보가 필요하겠구나’라고 스스로 판단하여 ‘암시적 쿼리 벡터'(Latent Query Vector)를 생성합니다. 텍스트 쿼리가 아니죠. 이 벡터를 이용해 지식 코퍼스에서 가장 관련성 높은 문서를 찾아냅니다.

2. Middle Layers (중간 레이어, \(\mathcal{L}_{\mathcal{M}}\)): 정보 통합팀 (Reader)

중간 레이어들은 ‘정보 통합팀’입니다. 검색팀이 가져온 상위 K개의 문서를 입력받습니다. 여기서 ‘교차 어텐션(Cross Attention)’이 핵심입니다. 입력된 쿼리(원본 요청서)가 검색된 문서(참고 자료)를 꼼꼼히 ‘참조’하여, 외부 지식을 쿼리 표현에 통합시킵니다.

3. Top Layers (상단 레이어, \(\mathcal{L}_{\mathcal{T}}\)): 최종 답변팀 (Generator)

최상단 레이어들은 ‘최종 답변팀’으로, 통합된 정보를 바탕으로 최종 응답을 생성합니다. (효율성을 위해 이 단계에서는 교차 어텐션을 비활성화합니다.)

이처럼 ImpRAG는 검색팀과 답변팀이 동일한 모델 파라미터와 순전파(forward pass)를 공유합니다. 셰프와 조수가 거의 한 몸처럼 움직이는 것이죠. 이를 통해 두 구성 요소 간의 불일치를 근본적으로 최소화합니다.

ImpRAG는 어떻게 ‘똑똑하게’ 훈련되는가? (2단계 훈련법)

훌륭한 아키텍처가 있어도, 검색 능력이 없는 순수 LLM을 어떻게 훌륭한 검색기로 만들 수 있을까요? ImpRAG는 ‘검색’과 ‘생성’ 두 마리 토끼를 잡는 2단계 훈련 전략을 사용합니다.

1단계: 웜업 (Warmup) – 기본 검색 능력 주입

사전 훈련된 LLM은 검색에 대해선 사실상 ‘신입’입니다. 따라서 훈련 초반에는 강력한 ‘선배’ 검색기(예: Contriever)가 만든 ‘족보(유사 레이블)’를 보고 학습합니다.

선배가 “이 쿼리엔 이 문서가 정답(긍정 예시)이고, 저 문서는 헷갈리지만 오답(어려운 부정 예시)이야”라고 알려주면, 모델의 하단 레이어(검색팀)가 기본적인 검색 감각을 익히는 것입니다.

2단계: 자가 증류 (Self-Distillation) – 생성 능력으로 검색 능력 향상

웜업이 끝나면, ImpRAG는 더 영리한 방식으로 스스로를 개선합니다. 바로 ‘생성팀’이 ‘검색팀’을 코칭하는 방식입니다.

아이디어는 간단합니다. “어떤 문서를 참고했을 때 생성팀(LLM)이 정답을 더 쉽게 생성(낮은 퍼플렉시티)하는가?”입니다.

검색팀이 여러 후보 문서를 가져오면, 생성팀이 각 문서를 보고 정답을 생성해봅니다. 그다음 생성팀이 “이 문서를 보니 정답이 술술 나오네(로그 가능도 높음)!”라고 평가 점수를 매깁니다.

핵심은 이겁니다: ImpRAG의 하단 레이어(검색팀)는 자신이 예측한 문서 순위가, 생성팀이 매긴 ‘정답 생성에 도움 되는 문서 순위’와 일치하도록 훈련됩니다(KL Divergence 최소화).

즉, 생성팀이 “이 문서가 정답 생성에 유용하다”라고 피드백을 주면, 검색팀은 “다음엔 이 문서를 더 잘 찾아와야겠다”라고 배우는 것입니다. 생성 작업의 피드백이 검색 작업으로 효과적으로 전달되는 것이죠.

실험 결과: ImpRAG는 왜 강력한가?

ImpRAG는 8개의 지식 집약적 작업에서 기존의 강력한 RAG 모델들과 비교 평가되었습니다. 결과는 매우 인상적이었습니다.

훈련 데이터와 유사한 작업 (In-domain): 훈련에 사용된 익숙한 형식의 작업에서도 기존 모델 대비 소폭의 성능 향상을 보였습니다.

처음 보는 다양한 작업 (Unseen): ImpRAG의 진가는 여기서 드러났습니다. 처음 보는 다양한 형식의 작업(T-Rex, ZsRE 등)에서 Exact Match 점수와 검색 리콜(Retrieval Recall)이 압도적으로 향상되었습니다.

사례 분석: AIDA 작업에서 성능이 폭발한 이유

가장 극적인 성능 향상은 엔티티 링킹(Entity Linking) 작업인 AIDA에서 나타났습니다. (Llama-3.1 8B 기준, EM 42.1% → 54.2%)

이유가 무엇일까요? AIDA 작업의 입력 프롬프트(예: [CONTEXT] … [START] British [END] … Wikipedia 제목을 출력하라…)는 그 자체로 좋은 ‘검색 쿼리’가 아닙니다.

기존 RAG: 이 부적절한 프롬프트 전체를 쿼리로 사용해야 했습니다. 그러니 당연히 엉뚱한 문서를 찾아왔죠. (물론 인간이 ‘British’라는 단어만 뽑아서 쿼리로 쓰도록 ‘템플릿’을 수동으로 만들어주면 성능이 오르지만, 이는 작업마다 수작업이 필요함을 의미합니다.)

ImpRAG: 템플릿이 필요 없습니다. 모델의 하단 레이어(검색팀)가 전체 프롬프트를 보고 “아, 이 문맥에서는 [British]라는 엔티티의 정보가 필요하구나”라는 ‘암시적 쿼리’를 스스로 생성하여 정확한 검색을 수행합니다. 이것이 바로 ImpRAG가 AIDA 같은 까다로운 작업에서 압도적인 성능 향상을 보인 이유입니다.

주요 시사점 및 결론

ImpRAG 연구는 RAG 시스템의 미래에 대한 중요한 시사점을 제공합니다.

통합 모델이 답이다: 검색기와 생성기를 분리하는 대신, 단일 모델 내에서 파라미터를 공유하고 공동으로 최적화하는 것이 성능과 일반화 능력 모두에 유리합니다.

레이어 경계(b) 설정이 중요하다: 검색팀(하단 레이어)의 규모를 무작정 늘리면 검색 성능은 오르지만, 일정 수준을 넘어가면 오히려 생성 성능이 저하되어 훈련(자가 증류)이 잘 안되는 현상이 나타났습니다. 검색과 생성 파라미터 간의 적절한 균형이 중요합니다.

명령어 튜닝(Instruction Tuning)은 검색도 돕는다: 훈련 시 명령어 튜닝 데이터를 포함하는 것이 생성 능력뿐만 아니라 검색 능력 향상에도 도움이 되었습니다. ImpRAG의 통합 구조 덕분에 모델이 작업 형식을 이해하는 능력이 생성에서 검색으로 ‘전이’될 수 있었기 때문입니다.

ImpRAG는 LLM이 인간의 명시적인 지시 없이 스스로 정보 요구를 파악하고 해결할 수 있는 가능성을 열었습니다. 비록 아직은 단일 패스 검색에 초점을 맞추고 특정 모델에서만 검증되었다는 한계가 있지만, 검색과 생성을 진정으로 통합하려는 RAG의 진화 방향을 명확하게 제시한 연구라 할 수 있습니다.