0x08. Multi-modal & Iterative RAG - 텍스트를 넘어, 반복으로 정교하게

기본적인 RAG 파이프라인은 텍스트 기반 문서를 검색하고, 그 내용을 LLM에 전달하여 답변을 생성한다. 하지만 현실의 문서에는 텍스트만 있지 않다. 차트, 표, 다이어그램 같은 시각적 정보가 핵심 내용을 담고 있는 경우가 많고, 복잡한 질문에는 한 번의 검색만으로 충분한 맥락을 확보하기 어렵다.

이 글에서는 RAG를 한 단계 끌어올리는 네 가지 고급 기법을 다룬다. 이미지까지 검색 대상에 포함하는 멀티모달 RAG, 검색을 여러 차례 반복하는 반복 검색(Iterative Retrieval), 질문 유형에 따라 전략을 바꾸는 적응형 검색(Adaptive Retrieval), 그리고 사용자 피드백으로 시스템이 스스로 개선되는 피드백 루프 검색(Retrieval with Feedback Loop) 이다.

Multi-modal RAG with Captioning: 이미지도 검색 대상이 된다

기존 RAG는 문서에서 텍스트만 추출하여 인덱싱한다. PDF에 포함된 차트, 표, 다이어그램은 그대로 버려지거나 무시된다. 하지만 재무 보고서의 수익 그래프, 논문의 실험 결과 표, 기술 문서의 아키텍처 다이어그램처럼 시각적 데이터가 핵심 정보를 담고 있는 경우가 빈번하다.

멀티모달 RAG(Multi-modal RAG with Captioning) 는 이 문제를 해결한다. 문서 내 이미지, 테이블, 차트 등 시각적 정보를 검색 대상에 포함시키는 RAG 확장 기법이다.

작동 방식

핵심 아이디어는 단순하면서도 효과적이다. 이미지를 텍스트로 변환하여 기존 텍스트 검색 파이프라인에 통합하는 것이다.

모든 종류의 데이터를 텍스트라는 단일 형태로 변환하여, 검색 파이프라인을 복잡하게 만들지 않고도 멀티모달 검색을 구현한다.

구체적인 과정은 다음과 같다.

1. 콘텐츠 분리 추출: PDF 같은 문서에서 텍스트 데이터와 이미지 데이터를 각각 별도의 스트림으로 분리하여 추출한다.
2. 이미지 캡셔닝: 추출된 각 이미지(테이블, 차트 포함)를 멀티모달 LLM(예: Gemini)에 입력하여, 이미지 내용을 설명하는 상세한 텍스트 캡션을 생성한다.
3. 통합 인덱싱: 원본 텍스트와 이미지로부터 생성된 캡션 텍스트를 모두 합쳐 하나의 데이터 풀로 만든다. 이 통합된 텍스트 데이터를 청킹(Chunking)하고 임베딩(Embedding)하여 단일 벡터 데이터베이스에 인덱싱한다.
4. 통합 검색 및 답변: 사용자가 질문하면 이 통합 벡터 데이터베이스를 대상으로 검색을 수행한다. 관련 내용이 원본 텍스트에 있든, 이미지의 캡션에 있든 모두 찾아낼 수 있다.

왜 효과적인가

• 정보 손실 방지: 문서의 모든 정보(텍스트, 이미지, 표)를 활용하므로 정보 손실이 거의 없다.
• 시각적 데이터 기반 질의 응답: 표의 수치나 다이어그램의 구조처럼 시각적 데이터에 기반한 질문에도 정확하게 답변할 수 있다.
• 단일화된 검색: 별도의 이미지 검색 엔진 없이, 텍스트 변환만으로 멀티모달 검색을 구현하기 때문에 파이프라인이 단순하게 유지된다.

구현 포인트

실제 구현에서 주목할 세 가지 단계가 있다.

• 콘텐츠 분리: PyMuPDF 라이브러리를 사용하여 PDF 페이지를 순회하며 텍스트와 이미지를 추출하고 별도로 저장한다.
• 캡션 생성: 저장된 각 이미지 파일을 멀티모달 모델(예: Gemini 1.5 Flash)에 전달한다. 이때 검색에 최적화된 간결한 요약을 생성하도록 프롬프트를 구성하는 것이 중요하다.
• 벡터 데이터베이스 구축: 추출된 원본 텍스트와 생성된 이미지 캡션 텍스트를 Document 객체로 변환한 뒤, 이 둘을 합쳐 벡터 데이터베이스에 함께 저장한다.

Iterative Retrieval: 한 번의 검색으로 부족할 때

단순한 사실 확인 질문이라면 한 번의 검색으로 충분할 수 있다. 하지만 "A 기술과 B 기술의 장단점을 비교하고, 실제 적용 사례까지 알려줘"처럼 여러 측면을 다뤄야 하는 복잡한 질문에는 단일 검색의 한계가 명확하다.

반복 검색(Iterative Retrieval) 은 단일 검색에 의존하지 않고, LLM이 마치 연구원처럼 첫 검색 결과를 분석하여 부족한 점을 파악하고, 필요한 추가 정보를 얻기 위한 후속 질문을 스스로 생성하여 검색을 여러 번 반복하는 동적 RAG 기법이다.

작동 방식

1. 1차 검색: 사용자의 원본 질문으로 첫 번째 문서 검색을 수행한다.
2. 결과 분석 및 쿼리 재구성: LLM이 검색된 문서와 원본 질문을 검토하여, 아직 답변되지 않은 부분이나 더 깊이 파고들어야 할 주제를 식별한다. 그리고 이를 해결하기 위한 새로운, 더 구체적인 검색 쿼리를 생성한다.
3. 반복 검색: 새로 생성된 쿼리로 추가 문서 검색을 수행한다. 이 "분석 -> 쿼리 재구성 -> 검색" 사이클을 정해진 횟수만큼, 또는 충분한 정보가 수집되었다고 판단될 때까지 반복한다.
4. 정보 종합: 모든 검색 단계에서 수집된 문서들을 모두 합쳐, 최종 답변 생성을 위한 풍부하고 다각적인 컨텍스트를 구성한다.

검색이 진행될수록 쿼리가 점점 더 구체화되므로, 최종적으로 수집되는 정보의 관련성이 매우 높아진다.

왜 효과적인가

• 복잡한 질문 처리 능력: 여러 측면을 고려해야 하는 복잡하고 광범위한 질문을 효과적으로 분해하고 탐색한다.
• 정보의 완전성: 점진적으로 정보를 쌓아가므로, 단일 검색으로는 놓치기 쉬운 중요한 세부사항이나 맥락까지 포착한다.
• 높은 관련성: 반복할수록 쿼리가 구체화되어, 최종 수집 정보의 질이 높아진다.

구현 포인트

구현의 핵심은 루프 내에서 LLM에 전달하는 프롬프트에 있다. 에이전트 LLM은 다음과 같은 형태의 프롬프트를 받는다.

"원본 질문: [X], 현재까지 수집된 정보: [Y]. 이 정보를 바탕으로 질문 X에 완전히 답하기 위해 추가로 알아내야 할 가장 중요한 것은 무엇이며, 이를 찾기 위한 최적의 검색 쿼리는 무엇인가?"

에이전트 LLM이 새로운 쿼리를 생성하면, 이를 이용해 검색을 실행하고 얻어진 문서를 누적된 컨텍스트에 추가한다. 이 과정을 정해진 횟수만큼 반복하여 정보를 점진적으로 확장한다.

Adaptive Retrieval: 질문 유형에 맞는 전략을 고른다

Iterative Retrieval이 "검색을 몇 번 반복할 것인가"에 집중한다면, 적응형 검색(Adaptive Retrieval) 은 "어떤 방식으로 검색할 것인가"에 집중한다.

모든 질문이 같은 방식으로 처리될 필요는 없다. "파이썬의 GIL이 뭐야?"라는 사실 확인 질문과 "마이크로서비스와 모놀리식 아키텍처를 비교 분석해줘"라는 분석 질문은 최적의 검색 전략이 다르다.

Adaptive Retrieval은 사용자의 질문을 받으면 먼저 LLM을 이용해 질문의 유형(사실, 분석, 의견 등)을 분류하고, 해당 유형에 가장 최적화된 맞춤형 검색 전략을 동적으로 선택하여 적용하는 지능형 RAG 기법이다.

작동 방식

1. 질문 분류: LLM이 사용자의 질문을 Factual(사실), Analytical(분석), Opinion(의견) 등 미리 정의된 카테고리 중 하나로 분류한다.
2. 전략 선택: 분류된 카테고리에 해당하는 전용 검색 로직(Strategy)을 선택한다.
3. 맞춤형 검색 실행: 카테고리별로 완전히 다른 검색 파이프라인이 동작한다.
   • 사실 질문: 쿼리 명확화 -> 검색 -> LLM 재정렬
   • 분석 질문: 하위 질문 생성 -> 병렬 검색 -> LLM 다양성 선택
   • 의견 질문: 다양한 관점 생성 -> 관점별 검색 -> LLM 다양성 선택
4. 답변 생성: 선택된 전략을 통해 최종적으로 검색된 문서들을 컨텍스트로 삼아 LLM이 답변을 생성한다.

각 질문 유형에 맞는 '전문가'가 작업을 처리하므로, 불필요한 검색이나 정보 처리를 줄일 수 있다.

왜 효과적인가

• 정확성 향상: 질문의 의도에 맞는 최적의 검색 방식을 사용하므로 결과의 질이 높아진다.
• 유연성: 단답형 질문부터 복잡한 분석, 다양한 의견 비교까지 광범위한 유형의 질문을 효과적으로 처리한다.
• 높은 효율성: 사실 질문에 불필요한 관점 분석을 수행하지 않고, 의견 질문에 단순 키워드 매칭을 적용하지 않는다.

구현 포인트

구현은 크게 세 가지 모듈로 나뉜다.

• 질문 분류기: LLM을 사용하여 쿼리를 특정 카테고리로 분류하는 모듈이다. 프롬프트 엔지니어링으로 분류 정확도를 높인다.
• 전략 패턴 적용: 각 검색 전략을 별도의 클래스로 모듈화하여 구현한다. 각 클래스는 자신만의 독특한 검색 로직(쿼리 변환, 하위 질문 생성, 재정렬 등)을 LLM을 활용하여 수행한다.
• 오케스트레이터: 메인 컨트롤러가 분류기의 결과를 받아 적절한 전략 클래스를 호출하는 방식으로 전체 프로세스를 통합하고 관리한다. 디자인 패턴 중 Strategy Pattern에 해당한다.

Retrieval with Feedback Loop: 사용자가 시스템을 가르친다

앞서 다룬 기법들은 모두 "한 번의 질의응답"을 더 잘하기 위한 전략이다. 피드백 루프 검색(Retrieval with Feedback Loop) 은 관점이 다르다. 사용자가 RAG 답변에 대해 남긴 피드백(평점 등)을 시스템이 학습하여, 시간이 지남에 따라 스스로 검색 및 답변 품질을 개선해나가는 동적 RAG 기법이다.

마치 추천 시스템처럼, 사용자의 반응을 반영하여 시스템이 점점 더 똑똑해지는 것이다.

작동 방식

1. 기본 RAG 실행: 사용자의 질문에 대해 문서를 검색하고 답변을 생성한다.
2. 피드백 수집: 생성된 답변에 대해 사용자가 관련성, 품질 등을 평가하여 저장한다.
3. 단기적 개선 (실시간 재조정): 다음 질문이 들어왔을 때, 검색된 문서들과 관련된 과거 피드백을 LLM으로 찾아내고, 이 피드백 점수를 반영하여 실시간으로 문서 순위를 재조정한 뒤 LLM에 전달한다.
4. 장기적 개선 (인덱스 파인튜닝): 주기적으로, 높은 평가를 받은 "질문+답변" 쌍들을 새로운 문서처럼 취급하여 벡터 데이터베이스에 추가함으로써 시스템의 지식 기반을 영구적으로 강화한다.

단기적으로는 문서 순위를 실시간 재조정하고, 장기적으로는 인덱스 자체를 강화하는 이중 개선 구조다.

왜 효과적인가

• 지속적인 성능 향상: 시스템이 상호작용을 통해 스스로 학습하고 발전한다. 쓰면 쓸수록 좋아진다.
• 사용자 맞춤화: 사용자의 선호도와 요구사항에 맞게 시스템이 적응한다.
• 오류 자동 수정: 잘못된 정보를 제공할 확률이 점차 줄어들고, 더 정확한 답변을 생성하게 된다.

구현 포인트

구현은 두 가지 축으로 나뉜다.

• 실시간 관련성 조정: 새 질문이 들어올 때마다, 검색된 문서와 관련된 과거 피드백을 LLM으로 찾는다. 이 피드백 점수를 이용해 현재 검색 결과의 문서 순위만 동적으로 재조정하여 즉각적인 개선을 이룬다.
• 주기적 인덱스 파인튜닝: 별도 프로세스를 통해, 높은 평가를 받은 Q&A 쌍들을 새로운 학습 데이터로 삼아 원본 문서와 함께 벡터 인덱스 자체를 다시 빌드한다. 이를 통해 시스템의 지식 기반을 영구적으로 강화한다.

정리: 네 가지 기법의 비교

기본 RAG가 "질문 -> 검색 -> 답변"이라는 단순한 흐름이라면, 이 네 가지 기법은 각각 다른 축에서 이 흐름을 고도화한다. Multi-modal RAG는 검색 대상의 범위를, Iterative Retrieval은 검색의 깊이를, Adaptive Retrieval은 검색 전략의 유연성을, Feedback Loop는 시간축에서의 개선을 더한다.

이 기법들은 상호 배타적이지 않다. 멀티모달 인덱스를 구축하면서 반복 검색을 수행하고, 질문 유형에 따라 전략을 바꾸며, 그 결과를 피드백으로 개선하는 것이 가능하다. 실제 프로덕션 RAG 시스템은 이런 기법들을 조합하여 구축된다.