AI VIDEO BRIEFING

RAG 완벽 이해: 벡터 임베딩·청킹·재순위·쿼리 재작성·에이전틱 RAG의 원리

검색 증강 생성(RAG)의 작동 원리를 실무 관점에서 정리했다. 토큰과 벡터 임베딩, 벡터 DB와 청킹, 재순위와 쿼리 재작성, MCP와의 차이, 그래프·에이전틱 RAG, 환각 대응까지 핵심 개념을 한눈에 살펴본다.

실무자를 위한 RAG 설계 가이드: 벡터 검색부터 재순위·쿼리 재작성까지 영상 대표 이미지

핵심 메시지

  • RAG는 사용자 질의에 맞는 문서를 회사 데이터에서 '검색'해 프롬프트에 '덧붙이고' LLM이 답을 '생성'하게 해 환각을 줄인다.
  • 벡터는 의미가 비슷한 단어·문서를 가까이 모아 주며, 이 성질 덕분에 벡터 DB가 관련 문서를 빠르게 찾는다.
  • 큰 문서는 통째로 임베딩하지 말고 의미·형식을 고려해 청킹해야 하며, 실무에선 도메인 전문가와 함께 커스텀 청커를 짜는 경우가 많다.
  • 검색 품질이 나쁠 때에 한해 재순위(상위 20개를 크로스 인코더로 재채점)와 쿼리 재작성(복합 질의 분할)을 도입한다.
  • MCP는 '기능·도구', RAG는 '정보·맥락'을 다룬다는 점에서 목적이 근본적으로 다르다.

쉽게 이해하기

발표는 대규모 언어 모델(LLM)의 기초에서 출발한다. LLM은 입력 시퀀스의 다음 토큰을 예측하도록 학습된 신경망으로, 문장을 바이트 페어 인코딩으로 토큰 단위로 쪼갠 뒤 각 토큰을 다차원 공간의 '벡터'로 바꾼다. 이때 의미가 비슷한 단어들은 서로 가까이 모여 군집을 이루고, '수도-국가'처럼 단어 사이의 관계도 벡터 간의 일정한 방향으로 표현된다. 이 벡터의 성질이 RAG의 토대가 된다.

RAG(검색 증강 생성)의 핵심은 사용자 질의에 관련된 문서·맥락을 먼저 '검색'해 LLM에 함께 넘기는 것이다. 예를 들어 '주문 123번 상태를 알려 달라'는 질의는 해당 기업만 아는 정보라, 맥락 없이 LLM에 던지면 환각이 나기 쉽다. 대신 사내 DB에서 '주문 123, 배송 중'이라는 맥락을 끌어와 질의에 덧붙이면(augment), LLM은 그 근거를 읽고 사람이 이해할 답을 생성한다. 검색(Retrieval)·증강(Augment)·생성(Generation)의 세 단계가 그대로 이름이 됐다.

문서를 저장할 때는 어떤 DB든 쓸 수 있지만, 유사한 벡터를 가까이 군집화해 빠르게 근접 문서를 찾는 벡터 DB가 흔히 쓰인다. 이때 큰 PDF를 통째로 하나의 임베딩으로 만들면 안 되고, 의미와 형식(표·이미지·헤더 등)을 고려해 '청킹'해야 한다. 크기 기준 청킹은 사실상 쓸모가 없고, 의미 기반 청킹은 이상적이지만 느려서 실제 운영에선 도메인 전문가와 함께 표준 문서 형식을 파악해 커스텀 파서·청커를 짜는 경우가 많다. 아주 큰 표 같은 구조화 데이터도 열 헤더 등 메타데이터를 유지한 채 청킹하면 도움이 된다.

검색 품질을 끌어올리는 두 기법이 재순위(re-ranking)와 쿼리 재작성(query rewriting)이다. 재순위는 상위 5개 대신 20개를 뽑은 뒤 크로스 인코더로 질의와 문서를 토큰 단위로 직접 비교(어텐션)해 다시 점수를 매긴다. 벡터-벡터 코사인 비교보다 정확해, '500~1000달러 노트북'처럼 근접한 값이나 'A 제외' 같은 부정 질의에서 특히 유리하다. 쿼리 재작성은 서로 무관한 여러 요구가 섞인 질의를 하위 질의로 쪼개 병렬 검색·응답 후 합친다. 토큰·지연·비용이 늘지만 비교형 질의에서 품질이 확연히 좋아진다. 둘 다 기본 파이프라인이 잘 돌면 필요 없고, 트레이스에서 부실한 검색이 확인될 때 도입한다.

발표는 확장 개념도 짚는다. 데이터 소스를 도구로 노출해 에이전트가 무엇을 조회할지 스스로 정하는 '에이전틱 RAG', 문서 간 링크를 따라가 '유사'가 아닌 '연관' 문서를 가져오는 '그래프 RAG'가 대표적이다. MCP와의 혼동도 정리한다 — MCP는 외부 시스템의 도구·기능을 노출해 '행동'을 수행하게 하는 것이고, RAG는 '정보·맥락'을 검색해 질의에 덧붙이는 것이다. 끝으로 환각은 확률적 시스템의 본질이므로 제거가 아니라 평가(LLM 심판·수동 평가)와 근거 확인으로 관리해야 하며, '파인콘이 RAG를 만들었다'거나 'RAG는 죽었다' 같은 마케팅 문구에 휘둘리지 말라고 조언한다.

주요 인사이트

  • 재순위는 벡터-벡터 코사인이 아니라 질의-문서의 토큰 단위 비교(어텐션)라 더 정확하며, 특히 'A 제외' 같은 부정 질의에 효과적이다.
  • 의미 기반 청킹은 이상적이지만 느려서, 실제 운영에선 도메인 전문가와 함께 짠 커스텀 규칙 청킹이 더 흔하다.
  • 쿼리 재작성·서브쿼리는 토큰·지연·비용을 늘리지만, 제품 A vs B 같은 비교형 질의에서 응답 품질을 크게 끌어올린다.
  • 환각은 아키텍처의 본질이므로 없애는 것이 아니라 평가와 근거 확인으로 관리한다 — 의료 진단처럼 무비판적 신뢰는 금물이다.
  • 벡터 DB 선택(파인콘·크로마·PG벡터·밀버스 등)이나 '새 아키텍처' 마케팅에 휘둘리지 말고, 실측 트레이스로 판단하라.

자주 묻는 질문

RAG와 MCP는 무엇이 다른가?

MCP는 외부(또는 내부) 시스템의 도구·기능을 노출해 인증·권한 하에 행동을 수행하게 하는 것이고, RAG는 관련 맥락(정보)을 검색해 질의에 덧붙이는 것이다. MCP는 '기능', RAG는 '정보'로 목적이 다르다.

재순위(re-ranking)는 언제 도입하나?

기본 검색 파이프라인이 잘 동작하면 필요 없다. 사용자 요청 트레이스를 살펴 청크 검색이 부실해 답변이 나빴을 때, 상위 20개를 크로스 인코더로 다시 채점해 상위 5개를 고르는 식으로 도입한다. 다만 비용은 더 든다.

구조화된 DB 데이터에도 청킹이 필요한가?

일반적인 행 단위 데이터는 대체로 청킹이 불필요하지만, 수천 행짜리 아주 큰 표는 열 헤더 등 메타데이터를 유지한 채 청킹하면 도움이 된다. 동적 데이터라면 에이전틱 RAG로 실시간 SQL을 구성하는 방법도 있다.

환각(hallucination)은 어떻게 줄이나?

LLM을 심판으로 쓰는 자동 평가나 수동 평가로 '검색된 문서에 답변이 실제로 근거하는지'를 확인하고, 검색 결과를 다시 LLM으로 검수하는 층을 두는 방법 등이 있다. 완전한 보장은 불가능하며 오류율을 낮추는 것이 목표다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식