AI VIDEO BRIEFING

RAG(검색 증강 생성) 입문: 데이터 주입·청킹·임베딩·벡터DB·검색 파이프라인

LangChain으로 배우는 RAG 크래시 코스. 환각과 비공개 데이터 문제를 RAG가 어떻게 푸는지, 데이터 주입과 검색이라는 두 파이프라인, 문서 구조·청킹·임베딩·벡터 DB·검색기까지 실습 흐름으로 정리한다.

RAG 완전 정복: 데이터 주입부터 검색·생성까지 파이프라인 한눈에 영상 대표 이미지

핵심 메시지

  • RAG는 LLM을 재학습하지 않고도 외부 지식 베이스를 참조하게 해, 환각과 최신·비공개 데이터 부족 문제를 비용 효율적으로 완화한다.
  • RAG는 두 파이프라인으로 구성된다. 문서를 파싱·청킹·임베딩해 벡터 DB에 저장하는 데이터 주입 파이프라인과, 질의를 임베딩해 유사도 검색으로 맥락을 가져와 답하는 검색 파이프라인이다.
  • 청킹은 문서를 작은 조각으로 나누는 작업으로, 임베딩 모델과 LLM의 고정된 컨텍스트 한계 때문에 필수이며 조각 간 일부를 겹치는 오버랩이 쓰인다.
  • 임베딩은 텍스트를 벡터(숫자)로 바꿔 코사인 유사도 같은 유사도 검색을 가능하게 하며, 강의는 오픈소스 all-MiniLM-L6-v2(384차원) 모델을 사용한다.
  • LangChain의 Document는 page_content와 metadata로 이뤄지며, 메타데이터(출처·저자·페이지 등)는 검색 시 필터링에 활용되어 정확도를 높인다.

쉽게 이해하기

이 크래시 코스는 RAG(검색 증강 생성)를 개념부터 실습까지 다룬다. RAG는 LLM의 출력을, 학습 데이터 밖에 있는 권위 있는 지식 베이스를 참조해 최적화하는 방식이다. 강의는 RAG가 푸는 두 가지 문제를 제시한다. 첫째, LLM은 학습 시점 이후의 사건을 모르고도 그럴듯한 답을 지어내는 환각을 일으킨다. 둘째, 회사 HR·재무 정책 같은 비공개 데이터는 모델에 없으며, 이를 파인튜닝으로 넣는 것은 매개변수가 수십억 개라 비싸고 번거롭다. RAG는 재학습 없이 외부 지식을 연결해 이 둘을 완화한다.

RAG는 두 개의 파이프라인으로 동작한다. 데이터 주입 파이프라인은 PDF·HTML·엑셀·DB 등 다양한 형식의 데이터를 읽어 파싱하고, 청킹으로 잘게 나눈 뒤, 임베딩으로 벡터화해 벡터 DB(벡터 스토어)에 저장한다. 검색 파이프라인은 사용자 질의를 같은 임베딩으로 벡터화해 벡터 DB에 유사도 검색을 던지고, 관련 정보를 맥락(context)으로 가져온다. 이 맥락과 프롬프트(지시문)를 함께 LLM에 전달해 답을 생성한다. 검색·증강·생성이라는 RAG의 세 단계가 여기에 대응된다. 퍼플렉시티가 이 방식의 대표 사례로 소개된다.

실습은 문서 구조 이해에서 시작한다. LangChain의 Document는 실제 텍스트인 page_content와, 출처·저자·페이지 수·생성일 같은 부가 정보인 metadata로 구성된다. 메타데이터는 단순한 부가 정보가 아니라, 나중에 유사도 검색에서 '저자=크리시 나이크' 같은 필터를 적용해 어느 문서에서 가져올지 좁히는 데 쓰여 검색 정확도를 끌어올린다. TextLoader, DirectoryLoader, PyPDFLoader, PyMuPDFLoader 같은 다양한 로더가 어떤 형식이든 결국 Document 구조로 변환해준다.

다음 단계는 청킹이다. 임베딩 모델과 LLM 모두 한 번에 처리할 수 있는 컨텍스트 크기가 정해져 있어, 100페이지 PDF를 통째로 넣을 수는 없다. 그래서 RecursiveCharacterTextSplitter로 문서를 청크 크기 1000, 오버랩 200 같은 설정으로 잘게 나눈다. 오버랩은 인접한 청크가 일부 내용을 공유하게 해 문맥 단절을 줄인다. 강의에서는 64개의 문서가 359개의 청크로 분할된다.

마지막은 임베딩과 벡터 저장, 검색이다. 임베딩은 텍스트를 벡터로 바꾸는 작업으로, 강의는 모두가 따라 할 수 있도록 오픈소스 sentence-transformers의 all-MiniLM-L6-v2(384차원) 모델을 쓴다. 변환된 벡터는 Chroma·FAISS 같은 벡터 스토어에 고유 ID·메타데이터와 함께 저장되며, 디스크에 영속화할 수 있다. 검색기(retriever)는 벡터 스토어 위에 놓여, 질의를 임베딩해 유사도 검색으로 맥락을 돌려주는 인터페이스 역할을 한다. 강의는 이 전통적 RAG를 모듈화된 클래스 코드로 묶어, 이후 에이전틱 RAG로 확장할 토대를 만든다.

주요 인사이트

  • 현업 생성형 AI 과제의 상당수가 RAG와 관련되어 있어, 데이터 파싱을 잘 다루는 것이 RAG 애플리케이션 개발의 성패를 가르는 핵심 단계로 강조된다.
  • RAG는 환각을 완전히 없애지는 못한다. 벡터 DB에 있는 데이터에 관한 질의는 맥락을 받아 정확해지지만, 그 안에 없는 내용은 여전히 모델이 지어낼 수 있다.
  • 파인튜닝과 RAG는 트레이드오프 관계다. 정책처럼 자주 갱신되는 데이터를 매번 파인튜닝하는 것은 비현실적이므로, 외부 지식을 검색으로 붙이는 RAG가 더 실용적이다.
  • 메타데이터 설계는 검색 품질에 직접 영향을 준다. 출처·저자·페이지 같은 메타데이터로 필터링하면 어느 문서에서 답을 가져올지 좁혀 정확도가 올라간다.
  • 임베딩 모델과 벡터 스토어는 비용·라이선스에 따라 선택지가 다양하다. OpenAI·Gemini 같은 유료 임베딩부터 all-MiniLM 같은 오픈소스, Chroma·FAISS 같은 오픈소스 벡터 스토어까지 폭넓게 쓸 수 있다.

자주 묻는 질문

RAG는 파인튜닝과 무엇이 다른가요?

파인튜닝은 모델의 수십억 매개변수를 다시 조정하는 비싸고 번거로운 작업입니다. RAG는 모델을 재학습하지 않고, 외부 지식 베이스를 검색해 맥락으로 제공함으로써 LLM이 그 정보를 참조해 답하게 합니다. 자주 갱신되는 데이터에 특히 유리합니다.

청킹은 왜 필요한가요?

임베딩 모델과 LLM 모두 한 번에 처리할 수 있는 컨텍스트 크기가 정해져 있어 긴 문서를 통째로 넣을 수 없습니다. 그래서 문서를 작은 청크로 나누고, 인접 청크가 일부 내용을 공유하도록 오버랩을 두어 문맥 단절을 줄입니다.

임베딩과 벡터 DB는 어떤 역할을 하나요?

임베딩은 텍스트를 벡터(숫자 표현)로 바꿔 코사인 유사도 같은 유사도 검색을 가능하게 합니다. 이렇게 만든 벡터를 Chroma·FAISS 같은 벡터 DB에 ID·메타데이터와 함께 저장해 두면, 질의와 유사한 내용을 빠르게 검색해 맥락으로 가져올 수 있습니다.

원문과 출처

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

YouTube 원본 영상 보기 ↗

관련 AI 소식