RAG(검색 증강 생성) 기초: 검색·증강·생성 3단계와 청킹·임베딩 전략

핵심 메시지

• 일반 챗 애플리케이션은 많은 파일을 한 번에 받지 못하므로, 방대한 문서를 다루려면 RAG가 필요하다.
• RAG는 검색(Retrieval), 증강(Augmentation), 생성(Generation)의 세 단계로 이뤄진다.
• 문서와 질문을 모두 벡터 임베딩으로 바꿔 의미 기반(시맨틱)으로 비교하는 것이 핵심이다.
• 검색된 데이터를 실행 시점에 프롬프트에 주입하므로, 모델을 재학습하지 않고도 최신·비공개 데이터를 활용할 수 있다.
• 청킹·임베딩·검색 전략의 보정이 RAG 성능을 좌우하며, 데이터 종류에 따라 전략이 달라진다.

쉽게 이해하기

영상은 흔한 실무 상황으로 시작한다. 회사 서버에 500GB의 문서가 있고, ChatGPT 같은 AI 비서를 붙여 그 문서에 대해 답하게 하라는 요청을 받았다. 그런데 일반 챗 앱은 한 번에 십여 개 파일도 받기 어렵다. 매번 500GB 전체를 검색하는 방식은 비효율적이고, 문서를 미리 요약해 두는 방식은 정확도가 떨어진다.

해법은 두 아이디어를 합치는 것이다. LLM은 사람의 언어를 수치로 바꾼 워드 임베딩으로 입력을 처리한다. 그렇다면 문서를 의미(semantics)를 보존한 벡터 임베딩으로 바꿔 데이터베이스에 저장하고, 컨텍스트를 청크(chunk)로 나눠 두면 AI가 자신의 컨텍스트 윈도에 맞게 빠르게 꺼내 쓸 수 있다. 이 방식이 바로 RAG, 즉 검색 증강 생성이다.

RAG는 세 단계로 나뉜다. 먼저 검색 단계에서는 질문도 문서와 똑같이 임베딩으로 바꾼 뒤, 질문 임베딩을 문서 임베딩과 비교한다. 정적인 키워드가 아니라 의미와 맥락으로 일치를 찾는 시맨틱 검색이다. 다음 증강 단계에서는 검색된 데이터를 실행 시점에 프롬프트에 주입한다. AI 비서가 사전학습된 낡은 지식에 의존하는 대신, 벡터 DB의 최신·실제·비공개 데이터를 근거로 답하게 만드는 것이다. 모델을 미세조정(fine-tune)하지 않고도 가능하다.

마지막 생성 단계에서는 검색된 관련 데이터를 바탕으로 답을 만든다. 예컨대 '작년 코드클라우드와의 서비스 계약을 알려달라'는 질문이 들어오면, 서비스 계약 관련 문서를 활용하고 '작년'이라는 조건에 맞춰 추론해 최선의 답을 낸다. 다만 RAG는 강력하지만 보정이 필요한 시스템으로, 특히 데이터를 어떻게 청킹하느냐가 성능을 가르는 결정적 요소다.

영상 후반부는 실습 랩으로 이어진다. 파이썬 가상환경과 UV로 ChromaDB·Sentence Transformers·OpenAI·Flask를 설치하고, ChromaDB로 벡터 저장소를 만들며, 크기 500·겹침 100 같은 청킹 전략과 all-MiniLM-L6-v2 임베딩 모델을 적용한다. 문서를 임베딩해 적재하고, 시맨틱 검색을 켜고, 5000번 포트의 간단한 Flask 웹 UI로 '반려동물 정책이 뭐야?' 같은 질문을 던져 검색·증강·생성 흐름을 직접 확인한다. 유사도 임계값으로 저품질 매칭을 걸러 환각을 줄이는 점도 짚는다.

주요 인사이트

• RAG의 핵심 전환은 '키워드 검색'에서 '의미 기반 검색'으로의 이동이며, 그래서 '반려동물 허용'과 '애완동물 가능'처럼 표현이 달라도 높은 유사도로 매칭된다.
• 증강 단계 덕분에 모델 재학습 없이도 최신·비공개 데이터를 활용할 수 있다는 점이 RAG의 실무적 가치다.
• 청킹 전략은 데이터 종류에 따라 달라야 한다 — 긴 구조를 보존해야 하는 법률 문서와 문장 단위로 잘게 나눠도 되는 상담 기록은 접근이 다르다.
• 청킹·임베딩·검색은 각각 독립된 전략 선택지(청크 크기와 겹침, 임베딩 모델, 유사도 임계값과 필터)이며, 이 보정이 RAG 품질을 좌우한다.
• 유사도 임계값을 두어 저품질 매칭을 걸러내는 것이 환각을 줄이는 실질적 안전장치다.

자주 묻는 질문

관련 AI 소식