RAG(검색 증강 생성) 완전 정복: 임베딩·청킹·하이브리드 검색·리랭커까지

핵심 메시지

• RAG는 LLM에게 '오픈북 시험'을 보게 하는 구조로, 외부 문서를 검색해 답변의 정확성과 최신성을 높인다.
• 임베딩은 텍스트의 의미를 숫자(벡터)로 바꿔 비슷한 의미끼리 가까이 두는 기술이며, 의미 기반 검색(시맨틱 서치)의 토대다.
• 실무 RAG 문제의 대부분은 답변 생성이 아니라 검색 단계에서 터지며, 핵심 원인은 품질 낮은 '청크'다.
• 의미 기반 댄스 임베딩과 키워드 기반 스파스 임베딩을 함께 쓰는 하이브리드 검색, 그리고 리랭커가 검색 정확도를 끌어올린다.
• 'RAG는 죽었다'는 말은 코드 같은 구조화 데이터 맥락의 결론이며, 비정형 문서 기반 시스템에서는 여전히 핵심 인프라다.

쉽게 이해하기

RAG는 Retrieval-Augmented Generation(검색 증강 생성)의 약자로, 사용자의 질문과 관련된 문서를 먼저 찾아 그 자료를 근거로 LLM이 답하게 하는 구조다. 영상은 이를 '오픈북 시험'에 비유한다. LLM은 학습이 끝난 시점에 지식이 멈추기 때문에, 회사 내부 문서·최신 정책·고객 데이터처럼 모델이 모르는 정보를 외부 검색으로 채워 주는 것이 RAG의 역할이다.

RAG를 이해하려면 부품을 하나씩 알아야 한다. 첫 부품은 임베딩으로, 텍스트의 의미를 수백~수천 차원의 숫자 배열(벡터)로 바꾼다. 마트가 비슷한 상품을 가까이 배치하듯, 임베딩은 비슷한 의미의 문장을 숫자 공간에서 가까이 둔다. 덕분에 '과일 알레르기 정책'을 물어도 '과일'이라는 단어가 없는 사과·복숭아 관련 문서를 찾아내는 의미 기반 검색이 가능하다.

긴 문서는 통째로 임베딩할 수 없어 적당한 크기로 잘라야 하는데, 이 조각이 '청크'다. 길이 기반 분할은 쉽지만 문장이 중간에 잘려 정보가 손실되고, 의미 기반 분할은 품질이 좋지만 구현이 어렵다. 표·이미지·OCR 문서를 깔끔히 텍스트로 바꾸는 '파서'의 품질도 청킹 품질을 좌우한다. 이렇게 만든 청크 벡터는 유사도 검색에 특화된 벡터 데이터베이스에 저장된다.

기본 파이프라인(자르고 → 숫자로 바꾸고 → 비슷한 숫자를 찾고)만으로는 문서가 수천 개로 늘면 검색 품질이 급락한다. 그래서 의미를 잡는 댄스 임베딩과 키워드를 잡는 스파스 임베딩(BM25 등)을 함께 돌리는 하이브리드 검색, 그리고 1차 후보를 다시 정밀 평가해 순서를 재배열하는 리랭커가 등장한다. 리랭커는 정확도를 높이지만 속도가 느려지므로 용도에 따라 선택해야 한다.

고급 기법으로는 앤스로픽의 컨텍스추얼 리트리벌(청크에 문서 맥락을 덧붙이기)과 레이트 청킹(전체 문서를 먼저 임베딩한 뒤 자르기)이 있다. 끝으로 영상은 'RAG는 죽었다'는 유행을 짚는다. 코드처럼 구조화된 데이터는 에이전틱 검색(grep/glob)이 유리하지만, 계약서·위키·의료기록 같은 비정형 문서에는 RAG가 여전히 대체 불가능한 핵심 인프라라는 것이 결론이다.

주요 인사이트

• 청크 품질이 전부다. '청크가 정크면 어떤 임베딩 모델을 써도 검색이 안 된다.' 자주 받는 질문 5~10개를 골라 상위 1~20위 청크를 직접 눈으로 점검하는 것이 RAG 고도화의 첫걸음이다.
• 도메인 특수 용어(반도체 CVD, 금융 BW 등)는 시맨틱 검색이 약하고 키워드 검색이 강하다. 범용 문서는 댄스 비중을, 전문 용어가 많은 도메인은 스파스 비중을 높이는 하이브리드 가중치 조정이 검색 품질을 크게 바꾼다.
• 앤스로픽 컨텍스추얼 리트리벌은 컨텍스추얼 임베딩만으로 검색 실패율을 35% 줄였고, BM25와 결합하면 49%, 리랭킹까지 더하면 67% 줄였다. 다만 청크마다 LLM을 호출해 비용이 들기 때문에, 의미 있는 청크인지 먼저 판별하는 필터를 두면 비용을 아낄 수 있다.
• 컨텍스트 윈도가 아무리 커져도 기업 지식베이스는 테라바이트급이라 전부 넣는 건 비현실적이며, RAG가 롱컨텍스트 접근 대비 약 8~12배 저렴하다는 연구가 인용된다. RAG는 사라진 게 아니라 '컨텍스트 엔지니어링'으로 리브랜딩되며 요구 수준이 올라간 것이다.

자주 묻는 질문

관련 AI 소식