RAG 검색 증강 생성이란 무엇인가 — LLM 환각·내부데이터 한계 해결법

핵심 메시지

• RAG(검색 증강 생성)는 LLM을 다시 학습시키지 않고 외부의 신뢰할 수 있는 지식베이스를 참조해 답을 생성하는 비용 효율적 기법이다.
• LLM만 쓸 때의 두 가지 약점은 학습 시점 이후 사건을 모르는 데서 오는 '환각'과, 회사 내부 문서처럼 학습에 포함되지 않은 데이터를 다루지 못한다는 점이다.
• RAG는 '데이터 주입 파이프라인'과 '검색 파이프라인'이라는 두 흐름으로 구성된다.
• 데이터 주입 단계에서는 문서를 파싱·청킹한 뒤 임베딩으로 벡터화해 벡터 DB에 저장한다.
• 검색 단계에서는 사용자 질문도 벡터로 바꿔 유사도 검색으로 관련 맥락을 찾고, 이 맥락과 프롬프트를 함께 LLM에 전달해 답을 만든다.

쉽게 이해하기

RAG는 'Retrieval-Augmented Generation', 즉 검색 증강 생성의 약자다. 영상은 RAG를 'LLM의 출력을 최적화하기 위해, 학습 데이터 바깥에 있는 권위 있는 지식베이스를 참조하도록 하는 과정'으로 정의한다. 핵심은 거대한 모델을 다시 학습(파인튜닝)시키지 않고도 특정 도메인이나 조직 내부 지식에 맞는 답을 내게 한다는 점이며, 그래서 비용 효율적이다.

왜 LLM만으로는 부족한가. 첫째는 환각이다. 모든 LLM은 특정 시점까지의 데이터로 학습되므로, 학습 마감 이후 일어난 일은 알지 못한다. 영상은 8월 1일까지 학습된 모델에게 8월 한 달 사이의 사건을 물으면, 모델이 '바보처럼 보이고 싶지 않아' 그럴듯한 답을 지어내며 사용자가 믿게끔 쓴다고 설명한다. 둘째는 비공개 데이터다. 스타트업의 인사·재무 정책처럼 공개되지 않은 내부 문서는 학습에 없다. 파인튜닝이라는 방법도 있지만 수십억 개 파라미터를 조정해야 해 비싸고 번거로우며, 정책이 계속 바뀌면 매번 다시 학습할 수도 없다.

RAG는 이를 두 개의 파이프라인으로 해결한다. 먼저 '데이터 주입(data injection) 파이프라인'은 PDF·HTML·엑셀·SQL 등 어떤 형식의 데이터든 받아 파싱하고, 적절한 크기로 잘라(청킹) 임베딩 모델로 벡터(텍스트의 수치 표현)로 바꾼 뒤 벡터 DB(벡터 스토어)에 저장한다. 임베딩 모델로는 구글·OpenAI·허깅페이스의 모델이나 오픈소스 모델을 쓸 수 있다. 영상은 비정형 데이터를 어떻게 읽고 어떻게 청킹하느냐가 RAG 구현의 성패를 가르는 가장 중요한 단계라고 강조한다.

두 번째는 '검색(retrieval) 파이프라인'이다. 사용자가 질문을 하면 그 질문도 임베딩으로 벡터화한 뒤 벡터 DB에 던져 코사인 유사도 같은 유사도 검색을 수행한다. 이렇게 찾아온 관련 정보가 '맥락(context)'이며, 이 맥락을 프롬프트(LLM에 대한 지시)와 함께 전달하면 LLM이 그 맥락을 근거로 답을 만든다. 검색(retrieval)·증강(augmentation)·생성(generation)이라는 RAG의 이름 그대로의 흐름이다.

RAG가 환각을 완전히 없애지는 못한다. 다만 질문과 관련된 데이터가 벡터 DB에 있으면 그 맥락을 근거로 답하므로 환각이 크게 줄어든다. 영상은 RAG로 만들어진 대표적 사례로 퍼플렉시티(Perplexity)를 든다. 여러 검색기·도구·웹 검색에 연결해 결과를 모으고 LLM이 요약해 답하는 구조이기 때문이다.

주요 인사이트

• RAG의 가치는 '재학습 없이' 모델에 새 지식을 더한다는 데 있다. 정책처럼 자주 바뀌는 데이터는 파인튜닝보다 벡터 DB 갱신이 현실적이다.
• 환각은 모델이 '모른다'를 인정하지 않고 그럴듯한 답을 만들려 하기 때문에 생긴다. 학습 마감 시점이라는 구조적 한계를 이해해야 한다.
• 데이터 파싱과 청킹이 RAG의 병목이자 핵심이다. 같은 데이터라도 어떻게 자르느냐에 따라 검색 품질이 달라진다.
• 임베딩은 텍스트를 벡터로 바꿔 유사도 검색을 가능하게 하는 다리이며, 유료·오픈소스 모델 사이에 비용 차이가 있다.
• 퍼플렉시티처럼 익숙한 서비스도 결국 RAG 구조라는 점은, RAG가 연구용이 아니라 실제 제품의 표준 패턴임을 보여준다.

자주 묻는 질문

관련 AI 소식