Every RAG Strategy Explained in 13 Minutes (No Fluff)

영상 링크: Every RAG Strategy Explained in 13 Minutes (No Fluff)
채널명: Cole Medin

모든 RAG(검색 증강 생성) 전략 13분 요약 핵심 요약

• 이 영상은 최신 RAG(Retrieval Augmented Generation, 검색 증강 생성) 시스템 최적화를 위해 활용 가능한 11가지 대표 전략을 빠짐없이 설명함
• RAG의 기본 구조(데이터 준비·임베딩, 쿼리 처리)를 간단히 개괄한 뒤 각 전략의 원리, 장점, 단점, 예시, 코드 샘플까지 구체적으로 다룸
• 영상에서 소개된 전략은 리랭킹, 에이전틱 RAG, 지식 그래프, 문맥 기반 검색, 쿼리 확장, 멀티쿼리, 문맥 기반 청킹, 레이트 청킹, 계층적 RAG, 자기반성 RAG, 임베딩 파인튜닝 등 총 11가지
• 각 전략별로 실제 사용 예시(예: Postgres+PGVector 활용법, Neon 대시보드 화면, 도클링/그래피티와 같은 라이브러리 등)를 구체적으로 시연
• 많은 전략은 성능 향상 대가로 LLM 호출, 임베딩 생성 등 비용 및 복잡성 증가의 트레이드오프가 있음을 명시
• “최적의 RAG 구성은 3~5개 전략을 조합하는 것”이라 강조하며, 초기에 특히 리랭킹, 에이전틱 RAG, 문맥 기반 청킹(도클링 이용)을 추천
• 각 전략의 알고리즘적 흐름(추출, 변환, 검색, 후처리 등)을 다양한 코드/의사코드와 함께 제시하여 실전 적용을 쉽게 도와줌
• 영상에서 다룬 모든 전략별 문서, 연구자료, 코드 등은 별도 GitHub 저장소에서 확인 가능함을 안내

세부 요약 - 주제별 정리

RAG(검색 증강 생성)의 개념과 프로세스는 두 단계로 이뤄짐

• RAG는 LLM(대형언어모델)에게 내부 지식과 문서를 검색·활용하는 능력을 부여하는 방식임
• 데이터 준비 단계: 문서를 작은 청크로 분할하여 임베딩 처리 후 벡터DB(또는 지식그래프)에 저장
• 쿼리 과정: 유저의 질문을 임베딩하고, 벡터DB에서 유사한 청크를 찾아 LLM에 컨텍스트로 전달
• 이 과정 덕분에 LLM은 외부지식을 활용해 보다 정확한 답변을 생성할 수 있음
• 데이터 준비(청킹/임베딩 전략), 쿼리(검색/후처리 전략) 단계마다 다양한 옵션이 존재해 최적 조합이 필요함

리랭킹은 대량의 후보에서 진짜 연관도 높은 컨텍스트만 추려 LLM에 공급함

• 기본 전략: 1차로 벡터DB에서 많은 청크를 가져온 뒤, 2차로 특화된 리랭커 모델(보통 크로스 인코더)을 사용해 가장 연관도 높은 소수 청크만 선별
• LLM에는 최종 선별된 청크만 전달하여 컨텍스트 오버플로우를 방지
• 여러 청크를 고려하되 모델이 과부하되지 않기에 질의응답의 질이 향상됨
• 약간의 추가 비용(LM 모델 호출)이 발생하지만, 대부분의 RAG 시스템에서 필수적이라 강조
• 해당 전략의 코드 예시도 영상에서 제공됨

에이전틱 RAG는 질의 내용에 따라 검색 방식 자체를 에이전트가 동적으로 결정함

• 에이전트(LLM)가 사용자의 쿼리에 따라 “벡터DB에서 청크 검색” vs “전체 문서 직접 읽기” 등 다양한 검색 방법을 선택 가능
• 실습: Neon 대시보드에서 Postgres, PGVector 조합으로 문서/청크 테이블을 분리
• 쿼리마다 어느 테이블(문서vs청크)에서 검색할지 분기 가능하여 유연성 최대화
• 대신 검색경로 불확실성, 예측불가성이 커지므로 명확한 규칙이 있을 때 추천
• 코드 예시 및 실제 동작화면도 영상에서 시연함

지식 그래프 도입 시 엔티티 간 관계 기반의 검색까지 가능해진다

• 벡터DB의 유사도 기반 검색에 추가해, 엔티티·관계 쿼리가 가능한 그래프DB 도입
• 문서로부터 LLM이 엔티티/관계를 추출하여 지식그래프 구축(시간·비용 상승)
• 복잡하게 얽힌 데이터(예: 인물관계, 이벤트 연동)에 적합
• 예시: Graffiti(그래피티) 라이브러리 활용, 그래프 구조 의사코드도 제시

문맥 기반 검색(Contextual Retrieval)은 청크별 맥락정보를 추가해 검색정확도를 높인다

• Anthropic 등에서 제안하는 방안으로, 각 청크 앞에 “이 청크가 문서 내에서 어떤 역할인지” 등 문맥정보 텍스트를 추가하여 임베딩
• DB안 청크를 클릭해도, 이 문맥 데이터가 항상 선행되어 저장됨을 시연
• 쿼리와의 매칭 측면에서 더 풍부한 맥락 정보를 검색에 활용 가능
• 단점: 각 청크마다 LLM 호출이 필요해 준비속도·비용이 증가

쿼리 확장(Query Expansion) 전략은 질의를 LLM이 발전시켜 검색 정밀도를 높인다

• 사용자가 입력한 질의를 LLM이 좀 더 구체화/세분화해 확장한 뒤, 검색에 투입
• 예: “회의 액션 아이템”에, 날짜/참여자 등 세부 정보가 자동 추가됨
• 더 관련도 높은 결과를 유도하지만, 질의마다 LLM 추가 호출 필요로 비용/속도 저하
• 관련 코드 샘플도 영상 내에서 확인 가능

멀티 쿼리 RAG는 LLM이 다양한 질의 변형을 생성해 커버리지를 확장한다

• 단일 확장 쿼리가 아니라, 다양한 의미 변형을 LLM이 여러 개 만들어 병렬로 검색에 투입
• 여러 쿼리 결과를 합쳐 보다 폭넓은 컨텍스트 확보(포괄성 상승)
• 역시 질의마다 LLM 추가 호출, 쿼리 횟수 증가라는 트레이드오프 발생
• 짧은 코드 예시로 원리 설명

문맥 기반 청킹(문서 분할)은 자연스러운 구조 유지로 임베딩 정합도를 높인다

• 문서 전체를 단순히 일정 길이로 쪼갤 경우, 의미 단위 단절·임베딩 품질 저하 발생
• 임베딩 모델로 문서 내 자연 경계(단락, 문맥 변화점 등)를 탐지해 자연스러운 구분
• 파이썬 라이브러리 dockling(도클링) 활용, 하이브리드 청킹 전략 으로 구현 용이
• 복잡하지만 문서 구조와 의미를 최대한 보존 가능해 추천

레이트 청킹은 임베딩 후 청킹함으로써 전체 맥락 손실을 최소화한다

• 대부분의 분할/임베딩은 ‘청킹 먼저, 임베딩 나중’이나 레이트 청킹은 반대로 ‘임베딩 먼저→청킹’
• 토큰 임베딩 단위로 청크를 만들기 때문에, 각 청크에 전체 문서 컨텍스트가 최대한 남아 있음
• 장점: 긴 문맥 유지, 고성능 임베딩 모델의 효과 극대화
• 단점: 구현 복잡성, 실제 적용 사례 적음(소개자는 아직 직접 써본 적 없다고 언급)

계층적 RAG는 청크 간 부모-자식 메타데이터를 저장해 정밀 검색과 대용량 맥락 활용을 동시 지원한다

• 각 청크에 소속/상위 문서 정보(메타데이터)를 저장, 검색 후 필요한 경우 전체 부모문서까지 컨텍스트로 전달 가능
• 예시: 특정 청크 검색→해당 청크의 상위(파일, 문서) 메타데이터 추적→상위 전체 내용도 함께 검색해 LLM에 전달
• 정밀(개별 청크) 검색과 확장된 컨텍스트 제공을 유연하게 조정
• 다만, 구조가 복잡·불확실하며, 에이전틱 RAG와 유사점이 많음

자기반성 RAG는 검색 결과를 LLM이 자체 평가·반복함으로써 품질을 개선한다

• 1차 검색 후 LLM이 결과(청크+질문)에 점수(예: 1~5 점)를 부여
• 점수가 일정 기준 미달(예: 3 이하)이면 개선된 재검색 수행(반복 루프)
• 결과의 품질이 자동 검증·보정돼 보다 높은 정답률 기대 가능
• 단, 검색→LLM 평가→재검색 루프마다 LLM 호출 증가로 비용 상승

임베딩 파인튜닝으로 도메인 특화 검색정확도를 획기적으로 높일 수 있다

• 임베딩 모델 역시 LLM처럼 자기만의 특화 데이터셋(예: 법률, 의료 등)으로 파인튜닝 가능
• 일반 임베딩 모델 대비 5~10%까지 검색 정확도 상승 가능, 더 작은 오픈소스 임베딩 모델이 대형 범용 모델보다 뛰어난 성능을 낼 수 있음
• 데이터셋/인프라 관리 등 추가 부담 크지만, 도메인 요구가 강한 경우 매우 강력한 전략
• 예시: “주문이 늦었다”와 “물건이 항상 품절”이 의미상 서로 더 가까운 유사도로 평가되게 파인튜닝 가능(감정기반 임베딩 등)
• 코드 및 파인튜닝 샘플도 함께 안내