RAG

RAG(Retrieval-Augmented Generation)란

 

외부 지식(문서 등)을 기반으로 LLM이 더 정확하게 답변을 생성하도록 설계된 아키텍처.

크게 두가지 단계로 볼 수 있다.

 

1. Indexing 단계

• 문서 불러오기(Load): 먼저 각종 문서와 데이터를 시스템에 불러온다.
• 잘게 나누기(Split): 불러온 문서는 작은 단위(청크)로 분할. 이는 검색과 임베딩의 효율성을 높이기 위한 절차
• 숫자로 변환(Embed): 각 청크를 AI가 이해할 수 있도록 임베딩 벡터(숫자 배열)로 변환
• 저장소에 보관(Store): 변환된 임베딩 벡터를 데이터베이스나 벡터스토어에 저장. 이 저장소는 나중에 검색할 때 사용된다.

목적: AI가 답변을 생성할 때 참고해야 하는 정보를 빠르고 효율적으로 찾을 수 있도록 미리 준비하는 과정

 

2. Retrieval & Generation 단계

• 사용자 질문(Question): 사용자가 질문을 입력한다.
• 유사 청크 검색(Retrieve): 시스템은 질문과 가장 비슷한 의미를 가진 청크를 임베딩 공간에서 검색한다.
• 프롬프트 생성(Prompt): LLM에게 전달할 프롬프트를 해당 청크와 함께 만든다.
• 응답 생성(Answer): LLM이 검색된 정보와 프롬프트를 바탕으로 정확하고 근거 있는 답변을 생성한다.

목적: 실시간으로 사용자의 질문 의도와 가장 관련 깊은 외부 지식만 선별하여 LLM이 답을 생성하도록 한다.

 

LLM만을 사용하면 외부 지식 접근 없이 훈련된 파라미터만을 사용해 답을 생성한다. 이는 기억에 의존한 풀이와 비슷하다.

반면, RAG는 외부 문서를 오픈북 시험처럼 실시간 검색해서, 새롭거나 상세한 정보를 바탕으로 더 정확한 답변을 만들 수 있다.

 

• 문서 임베딩과 벡터 데이터베이스 저장
  • 문맥정보를 임베딩 모델을 이용해 벡터로 변환
  • 이 벡터들은 벡터 데이터베이스에 저장되어 검색에 활용
• 쿼리 임베딩과 검색
  • 사용자의 질문을 쿼리 임베딩으로 변환하고, 벡터 데이터베이스에서 쿼리 임베딩과 가장 가까운 문서 임베딩을 검색해 관련 자료를 찾아낸다.
  • 이 검색 결과들은 프롬프트에 추가되어 생성 모델에 입력된다.

 

토큰화(토큰 쪼개기)

 

RAG에서 토큰화는 문서를 모델에 입력할 때 모델의 최대 토큰 수 제한 때문에 문서를 여러 작은 조각으로 분할하는 작업을 의미한다.

이 과정에서 텍스트를 토큰 단위 기준으로 나누어 각 청크가 최대 토큰 수를 넘지 않도록 하며, 토큰 overlap을 통해 인접 청크 간에 일부 토큰을 겹치게 하여 문맥 손실을 방지한다.

from langchain_text_splitters import CharacterTextSplitter

text_splitter = CharacterTextSplitter(
    separator="\n\n",
    chunk_size=100,
    chunk_overlap=20,
    length_function=len,
    is_separator_regex=False
)

texts = text_splitter.split_documents(docs)

• 문서를 토큰 단위로 쪼개 최대 chunk_size 이하로 유지
• 분할 시 구분자(줄바꿈, 마침표 등)를 활용해 자연스러운 자름
• chunk_overlap 파라미터로 인접 청크에 토큰 일부 겹침 적용
• 이렇게 쪼개진 청크들을 임베딩하여 벡터 DB에 저장해 RAG에서 검색 및 생성에 활용

이렇게 나누면 LLM이 입력 제한을 초과하지 않으면서 중요한 문맥을 유지하며 문서 내용을 효과적으로 참조할 수 있다.

LangChain 같은 라이브러리에서는 CharacterTextSplitter, RecursiveCharacterTextSplitter 같은 도구로 토큰 기반 분할을 구현

 

토큰과 청크?

• 토큰은 텍스트를 더 이상 쪼갤 수 없는 기본 단위. 단어, 구두점, 숫자 등으로 나누며, 토큰화 작업을 통해 생성된다.
• 청크는 여러 토큰을 모아 의미 있는 단위로 묶은 것. 예를 들어 “New York City”는 3개의 토큰(“New”, “York”, “City”)이지만 하나의 의미 단위인 청크로 다뤄질 수 있다. 

 

 

크기로 나누기

 

청크 사이즈를 100으로 설정했는데 결과를 보면 100보다 큰 청크 사이즈로 쪼개지는 것을 확인할 수 있는데, 결과가 더 크게 쪼개지는 이유는 CharacterTextSplitter가 지정한 구분자(separator)를 기준으로 먼저 텍스트를 나누고, 그 구간이 청크 크기보다 크면 그 구간 자체가 청크 크기보다 큰 결과를 만들기 때문이다.

구체적으로 말하면, separator=”\n\n” 을 기준으로 문단 단위로 먼저 분할한 뒤에 각 문단 조각을 청크로 만든다. 그런데 어떤 문단이 100자보다 더 길면 그 문단 전체가 하나의 청크로 유지되어 100자보다 큰 청크가 나올 수 있다. 이 방식은 문맥 단절을 막기 위해 지정한 구분자가 우선 시되기 때문이다. 즉, 100자를 기준으로 쪼갰을 때, 그 문단까지는 한 청크로 보는데, 이 문단이 길 경우에는 큰 청크사이즈가 될 수 있는 것이다.

 

그렇다면 100이하로 쪼개려면 어떻게 해야할까?

청크 크기를 엄격히 지키면서 구분자 영향 없이 쪼개려면 separator를 빈 문자열(””)로 설정하거나, 정규식 등으로 더 세밀한 분리 기준을 지정 하면 된다. 또는 RecursiveCharacterTextSplitter 같은 도구를 써서 문단 내에서도 재귀적으로 쪼갤 수 있다.

정리하면, 청크 사이즈는 최대 크기 목표일 뿐이고 separator를 기준으로 우선 분할하기 때문에 구간이 길면 그 구간이 청크 크기보다 커질 수 있다.

 

from langchain_text_splitters import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
    separators=["\n\n", "\n", " ", ""],
    chunk_size=100,
    chunk_overlap=20,
    length_function=len,
    is_separator_regex=False
)

texts = text_splitter.split_documents(docs)

RecursiveCharacterTextSplitter를 사용해서 여러 단계의 구분자(“\n\n”, “\n”, “ “, “”)를 순차적으로 사용해 텍스트를 재귀적으로 분할하였다.

• 처음에는 가장 큰 단위 구분자인 두 줄바꿈(”\n\n”)으로 텍스트를 나누고, 각 분할이 chunk_size(100)를 초과하면
• 다음 단계 구분자인 한 줄바꿈(”\n”) 기준으로 다시 쪼갠다.
• 여전히 크면 공백(” “)으로 다시 쪼갠 후
• 그래도 크면 마지막으로 분리할 수 없는 아주 작은 단위(””) 즉 문자 단위로 분할한다.

따라서 `RecursiveCharacterTextSplitter`는 텍스트를 chunk_size 이하로 엄격하게 쪼개면서 문맥 단위(문단 > 문장 > 단어 > 문자)를 최대한 유지하는 재귀적 전략으로 동작하기 때문에 결과물이 모두 chunk_size 이하가 된다. 

 

의미로 나누기(semantic)

 

OpenAI의 임베딩 모델

news=[news에 대한 내용]
openai_embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
embeddings = openai_embeddings.embed_documents(news)
embedded_query = openai_embeddings.embed_query("대선 후보 토론")
embedded_query[:10]

• OpenAIEmbeddings: OpenAI의 text-embedding-3-small 모델을 사용해서 뉴스 기사와 검색 쿼리를 임베딩 벡터로 변환
• embed_documents(news): 리스트 내 각 뉴스 기사를 하나씩 임베딩하여 벡터로 변환
• embed_query("대선 후보 토론"): 질의도 임베딩 벡터로 변환. "대선 후보 토론"=내가 질문하고 싶은 내용

 

HuggingFace 임베딩 모델

from langchain_huggingface import HuggingFaceEmbeddings

news=[news에 대한 내용]
hf_embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3")
embeddings = hf_embeddings.embed_documents(news)
embedded_query = hf_embeddings.embed_query("대선 후보 토론")
embedded_query[:10]

• HuggingFaceEmbeddings: HuggingFace Hub에서 지정한 사전학습 임베딩 모델을 이용해 텍스트를 벡터로 변환하는 래퍼 객체

 

텍스트 파일에서 여러 뉴스 기사를 불러와 적당한 크기로 청킹한 뒤, 다국어 임베딩 모델로 벡터화하여 벡터 데이터베이스(Chroma)에 저장하고, 질의와 유사한 문서 검색을 수행하는 전형적인 RAG 기반 검색 시스템을 구현해보자.

 

RAG 파이프라인

텍스트 파일 → 청크 분할 → 임베딩 → 벡터DB 인덱싱 → 자연어 또는 벡터 기반 유사도 검색까지 

 

문서 로드 및 분할

from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import CharacterTextSplitter
text_splitter = CharacterTextSplitter(
    chunk_size=100,
    chunk_overlap=20
)

loader = TextLoader("./docs/news.txt", encoding="utf-8")
documents = loader.load_and_split(text_splitter=text_splitter)

• TextLoader가 로컬 파일(`./docs/news.txt`)에서 뉴스 기사 텍스트를 UTF-8로 불러온다.
• CharacterTextSplitter()은 불러온 긴 텍스트를 100자 이하, 20자 중복으로 청크 단위로 나누고,
• loader.load_and_split(...)`는 이 두 과정을 결합해, 여러 개의 분할된 청크 형태의 문서 리스트(documents)를 만든다.

 

임베딩 벡터 변환

from langchain_chroma import Chroma
from langchain_huggingface import HuggingFaceEmbeddings

model_name = "BAAI/bge-m3"
hf_embeddings = HuggingFaceEmbeddings(model_name=model_name)

db = Chroma.from_documents(documents, hf_embeddings)

 

• HuggingFace Hub에서 지정한 사전학습 임베딩 모델을 사용해 각 청크 문서를 의미적 임베딩 벡터로 변환하고,
• 벡터 데이터베이스 구축
  • Chroma.from_documents(documents, hf_embeddings)는 위 임베딩 벡터들을 Chroma 벡터DB에 저장하여, 내용 기반 검색이 가능한 인덱스를 생성한다.

 

1. 텍스트 직접 질의(문자열 → 내부 임베딩 → 검색)

result = db.similarity_search("대선 후보 토론")

• db.similarity_search("대선 후보 토론"): 질의를 임베딩하고, DB 내에서 가장 유사한 문서 청크들을 검색해 반환
• 여기서 임베딩 모델은 Chroma 객체 생성 시 전달한 HuggingFace임베딩이 그대로 쓰인다.

 

2. 임베딩 벡터로 직접 질의(문자열 → 임베딩 (직접) → 벡터DB에 벡터 전달 → 검색)

embedded_query = hf_embeddings.embed_query("대선 후보 토론")
result = db.similarity_search_by_vector(embedded_query)

• 임베딩을 이미 따로 만든 경우나, 벡터 연산을 직접 다루고자 할 때 쓰는 방법
• 해당 임베딩 벡터와 벡터DB 내 모든 문서의 코사인 유사도를 계산해, 의미적으로 가장 가까운 문서들을 반환

 

vectordb를 왜 저장(persist)해서 쓰는가?

• 데이터 유지: 시스템이 꺼지거나 재시작해도 이미 임베딩한 문서 벡터들을 재생성할 필요 없이 저장된 상태를 유지가능
• 성능 향상: 매번 문서를 임베딩하지 않고, 저장된 벡터를 바로 불러와서 빠르게 검색 가능, 확장성과 응답속도
• 재사용 및 이식성: 저장된 DB를 여러 서비스나 서버에서 공유 및 재사용 가능

 

db = Chroma.from_documents(documents, hf_embeddings, persist_directory="./news_chroma_db")
result = db.similarity_search("대선 후보 토론", k=1)

• 분할된 문서들을 임베딩 벡터로 변환 후, 폴더에 저장하며 Chroma 벡터 DB를 생성
• 쿼리를 임베딩 벡터로 바꿔 DB에서 가장 유사한 문서 청크 1개를 찾아 반환
• 즉, 텍스트 파일을 작은 조각으로 나눠서 임베딩 벡터를 만들어 벡터 데이터베이스에 저장하고,
• 저장된 벡터를 꺼내서 쿼리와 의미상 가장 가까운 문서들을 빠르게 찾는 시스템을 만드는 것

 

1.similarity_search(query_str, k=...)
텍스트 쿼리를 받아 임베딩으로 변환 후, 가장 유사한 k개 문서를 반환
반환값은 문서 리스트
    
2.similarity_search_with_score(query_str, k=...)
텍스트 쿼리를 임베딩 후 유사도와 함께 반환
반환값은 튜플 리스트이며, 점수로 결과 신뢰도를 파악

3.similarity_search_with_relevance_scores(query_str, k=...)
점수를 relevance score (연관도 점수) 형태로 제공

 

이번엔 다른 벡터 DB인 FAISS를 사용해보자

import faiss
from langchain_community.vectorstores import FAISS
from langchain_community.docstore.in_memory import InMemoryDocstore
from langchain_openai import OpenAIEmbeddings

# 1. 임베딩 초기화
embeddings = OpenAIEmbeddings()

# 2. 임베딩 벡터 차원 확인
dimension = len(embeddings.embed_query("hello world"))

# 3. FAISS 인덱스 생성 (예: L2 거리 기준 Flat 인덱스)
index = faiss.IndexFlatL2(dimension)

# 4. FAISS 벡터 저장소 초기화
vector_store = FAISS(
    embedding_function=embeddings,
    index=index,
    docstore=InMemoryDocstore(),
    index_to_docstore_id={}
)

# 5. 문서 리스트를 벡터화 후 저장
texts = ["문서1 내용", "문서2 내용", "문서3 내용"]
vector_store.add_texts(texts)

# 6. 쿼리 임베딩 후 유사 문서 검색
query = "유사 문서 찾기"
results = vector_store.similarity_search(query, k=3)

for res in results:
    print(res.page_content)

 

• FAISS는 고성능 벡터 유사도 검색에 최적화된 라이브러리로, 대규모 데이터셋과 빠른 검색에 강점
• Chroma가 벡터 DB와 임베딩 데이터베이스로서 더 사용자 친화적인 DB 기능을 제공하는 반면, FAISS는 고속 인덱싱과 GPU 가속 기능을 제공
• FAISS는 벡터 인덱스를 별도로 생성하며, L2 거리나 코사인 유사도 등 다양한 거리 측정을 지원
• Chroma는 벡터 DB로 볼 수 있다. 임베딩 벡터뿐 아니라 문서, 메타데이터 등을 함께 저장하고 관리하는 기능을 갖췄으며, 디스크 기반 영속 저장을 기본 지원합니다. 검색과 저장을 위한 DB 기능이 포함된 완전한 솔루션입니다.
• FAISS는 벡터 검색용 라이브러리. 고성능 벡터 인덱스 생성과 유사도 검색에 특화되어 있으나, 자체적으로 DB 저장을 제공하지 않으므로, 필요한 경우 별도 저장소 설정 및 인덱스 파일 저장/로드를 직접 구현해야 한다.

 

Retriever

from langchain_chroma import Chroma
db = Chroma(persist_directory="./news_chroma_db", embedding_function=hf_embeddings)


retriever = db.as_retriever(
    search_type="similarity_score_threshold",
    search_kwargs={"score_threshold": 0.25}
)

result = retriever.invoke("대선 후보 토론")
result

• retriever는 벡터DB에서 주어진 쿼리와 가장 관련성 높은 문서를 찾아 반환하는 역할을 하는 검색기 인터페이스
• LangChain에서 db.as_retriever() 메서드를 호출하면 벡터 저장소를 기반으로 Retriever 객체가 생성되며, 이 Retriever는 검색 방식(유사도, 점수 임계값 기반, MMR 등)을 선택할 수 있다.
• retriever.invoke()을 호출하면, 내부적으로 벡터 임베딩을 통해 관련 문서를 벡터 검색 후 유사한 문서 리스트를 반환한다.
• Retriever는 자연어 쿼리에 대해 의미적으로 연관성 높은 문서를 빠르게 찾는 역할에 집중한다.
• 따라서 retriever는 벡터 스토어에서 가장 관련 있는 정보를 "검색하는 검색기"라고 생각하면 된다.
  
  

 

MultiQueryRetriever

from langchain.retrievers.multi_query import MultiQueryRetriever
retriever = MultiQueryRetriever.from_llm(retriever=db.as_retriever(), llm=llm)
retriever.invoke("대선 후보 토론")

• LangChain에서 제공하는 고급 검색기, 사용자가 입력한 단일 쿼리를 LLM을 통해 여러 개의 의미가 겹치면서도 다양한 관점의 쿼리로 자동 변환.
• 이렇게 생성된 여러 쿼리를 기반으로 벡터 저장소에서 각각 검색을 수행한 후, 결과를 통합해 더 풍부하고 정확한 검색 결과를 제공
• LLM이 쿼리를 패러프레이징(paraphrasing)하여 다양한 각도에서 문서 검색 가능 -> 단일 질문의 모호함이나 의미적 부족함을 여러 쿼리로 보완해 검색 성능을 높일 수 있다.
• 각 쿼리에 대한 검색 결과를 중복 제거하며 통합하여 리턴

코드를 보면 MultiQueryRetriever.from_llm() 메서드는 기존 retriever와 LLM을 결합해 MultiQueryRetriever 인스턴스를 생성하고, retriever.invoke() 또는 get_relevant_documents()로 여러 쿼리 기반 검색을 실행

---

 

총 정리 해보자

 

전체 구조 개요

1. 문서 로드 및 분할 → 2. 임베딩 생성 및 벡터 저장 → 3. 검색기 설정 → 4. 프롬프트 템플릿 → 5. RAG 체인 구성 → 6. 질문 처리

 

1. 환경 설정 및 모델 초기화

from dotenv import load_dotenv
load_dotenv()
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o-mini")

 

2. 임베딩 모델 설정

from langchain_huggingface import HuggingFaceEmbeddings
model_name = "BAAI/bge-m3"
hf_embeddings = HuggingFaceEmbeddings(model_name=model_name)

• 텍스트를 벡터로 변환하여 유사도 검색 가능하게 함

 

3. 문서 로드 및 분할

text_splitter = CharacterTextSplitter(
    separator="\n",
    chunk_size=0,  # 줄바꿈 기준으로만 분할
    chunk_overlap=0
)
loader = TextLoader("./docs/travel.txt", encoding="utf-8")
documents = loader.load_and_split(text_splitter=text_splitter)

• travel.txt 파일을 줄바꿈(\n) 기준으로 분할
• chunk_size=0이므로 각 줄이 하나의 문서 청크가 됨

 

4. 벡터 데이터베이스 구축

from langchain_chroma import Chroma
db = Chroma.from_documents(documents, hf_embeddings)

• 각 문서를 임베딩으로 변환하여 저장

 

5. 검색기 설정

retriever = db.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 5, "fetch_k": 20, "lambda_mult": 0.5}
)

• MMR (Maximal Marginal Relevance): 관련성과 다양성의 균형을 맞춘 검색
• k=5: 최종 5개 문서 반환
• fetch_k=20: 먼저 20개 후보 문서를 가져온 후 MMR로 5개 선별
• lambda_mult=0.5: 관련성(0.5)과 다양성(0.5)의 균형

 

6. 프롬프트 템플릿

prompt_template = hub.pull("langchain-ai/retrieval-qa-chat")

• LangChain Hub에서 검증된 RAG용 프롬프트 템플릿 사용
• 검색된 문서를 컨텍스트로 활용하여 답변 생성하도록 설계됨

 

7. 출력 파서 설정

from langchain_core.output_parsers import StrOutputParser
parser = StrOutputParser()

LLM 출력을 문자열로 변환해주는 도구

 

8. RAG 체인 구성

rag_chain = {
    "context": retriever,      # 검색기에서 관련 문서 가져옴
    "input": RunnablePassthrough()  # 사용자 질문 그대로 전달
} | prompt_template | llm | parser

 

체인 실행 흐름:

1. 사용자 질문 → retriever가 관련 문서 검색
2. 검색된 문서(context)와 질문(input) → prompt_template에 주입
3. 완성된 프롬프트 → llm(GPT-4o-mini)에서 답변 생성
4. 답변 → parser로 문자열 형태로 파싱

 

9. 실행

rag_chain.invoke("대선 후보 토론")

• 질문을 입력하면 travel.txt에서 관련 내용을 검색
• 검색된 정보를 바탕으로 이색적인 숙소에 대해 답변
• 문서에 있는 내용만 참조하여 답변하기에 정확성 보장 가능
  
  

 

추가로 도커 바인딩 부분 정리

CMD["--server.address=0.0.0.0"]

 

• 네트워크상의 모든 인터페이스에서 들어오는 요청을 허용하도록 설정하는 것
• 서버가 127.0.0.1(localhost)로 바인딩되면, 해당 컴퓨터 내부에서만(로컬 접속만) 접속 가능
• 0.0.0.0으로 바인딩하면, 서버가 자신의 모든 IP 주소(내부 네트워크, 외부 네트워크 포함)에서 들어오는 요청을 받게 됩니다.
• 즉, 다른 컴퓨터나 네트워크 장비에서도 해당 서버에 접속 가능하도록 허용하는 설정
• --server.address=127.0.0.1
  • 내 컴퓨터에서만 접속 가능. 도커 컨테이너 호스트에서는 접속 불가
• --server.address=0.0.0.0
  • 모든 네트워크 인터페이스에서 접속 가능. 도커 컨테이너 외부 호스트에서 접근 가능

 

실습

내가 좋아하는 리버풀에 대한 위키피디아로 벡터 DB를 구성하고, 질문을 해봤다.

내가 잘 아는 주제라 답변이 정확한지 알기 쉬워서 '리버풀'로 주제를 잡아봤는데, 성능이 꽤 괜찮다.

https://github.com/seongjju/liverpool-fc-rag