자신의 문서로 RAG 시스템을 7단계로 구축하는 방법
출처: Dev.to
코드를 작성하지 않고도 개인 데이터에서 질문에 답변하는 Retrieval‑Augmented Generation 파이프라인 만들기
시작하기 전에: 여러분이 얻을 수 있는 것
이 튜토리얼을 마치면 PDF, Word 문서, 위키 페이지 등 어떤 컬렉션이든 챗봇에 연결해 몇 초 만에 정확한 답변을 얻을 수 있습니다.
- RAG 시스템의 세 가지 핵심 구성 요소—검색기(retriever), 생성기(generator), 그리고 이 둘을 연결하는 오케스트레이션(orchestator)—을 이해하게 됩니다. 이는 마치 택시를 탈 때 운전사, 지도, GPS 신호를 파악하는 것과 같습니다.
- 무료 혹은 프리미엄 서비스만으로 완전한 파이프라인을 구축할 수 있으니, 데이터 과학 팀을 고용하거나 비싼 GPU 서버를 임대할 필요가 없습니다.
- Slack 봇이나 가벼운 웹 UI에 바로 끼워 넣을 수 있는 컴포넌트를 얻게 되어, 지식 베이스를 즉시 어시스턴트로 전환할 수 있습니다.
- 구성 요소 보기: 검색기(문서를 검색), 생성기(답변을 작성), 오케스트레이터(질의를 전달).
- 툴체인: 벡터 스토어(예: Pinecone 무료 티어), LLM API(OpenAI 챗 모델 무료 크레딧), 코드‑없는 커넥터(Zapier 또는 Make).
- 배포: 간단한 Flask 앱으로 엔드포인트를 감싸거나 서버리스 함수로 배포한 뒤 Slack이나 정적 HTML 페이지에 연결합니다.
짐을 싸는 과정에 비유하면, 올바른 아이템(문서)을 골라 효율적으로 정리(벡터 인덱스)하고, 필요할 때마다 정확히 어디에 무엇이 있는지 알려주는 여행 가이드(LLM)를 추가하는 것입니다.
튜토리얼을 마치면 RAG 시스템 튜토리얼을 어떤 새로운 프로젝트에도 복제할 수 있게 되며, 코드는 몇 개의 설정 파일 정도만 필요합니다.
시작할 준비가 되셨나요?
Retrieval‑Augmented Generation이란? (전문 용어 없이)
RAG 시스템을 두 사람 팀에 비유해 보세요. 한 사람은 말재주가 뛰어난 친구(생성기)이고, 다른 한 사람은 모든 문서를 깔끔히 보관한 파일 캐비닛(검색기)입니다.
친구는 말을 매끄럽게 이어갈 수 있지만 최신 정책이나 제품 사양을 기억하지 못합니다. 질문을 받으면 먼저 파일 캐비닛에 가장 관련성 높은 페이지를 요청하고, 그 정보를 자연어 능력과 결합해 답변을 만들어 냅니다.
실제로 검색기는 PDF, Word 파일, 위키 등을 빠르게 탐색해 몇 개의 스니펫을 반환합니다. 그 스니펫들을 생성기에 전달하면, 생성기는 대화형이면서도 실제 문서에 기반한 답변을 작성합니다.
맞춤 샌드위치를 주문하는 상황을 떠올려 보세요. 셰프(생성기)는 어떤 조합이든 만들 수 있지만, 냉장고에 어떤 재료가 있는지 알아야 합니다(검색기). 셰프는 재고를 확인하고 가장 신선한 상추와 정확히 저장된 치즈를 골라, 주문에 딱 맞는 샌드위치를 완성합니다.
이렇게 하면 AI 어시스턴스가 최신 기업‑특화 사실을 제공하면서도 대화 흐름은 자연스럽게 유지됩니다. 거대한 모델 학습이나 데이터 과학 팀이 필요 없고, 검색 가능한 인덱스와 언어 모델만 있으면 됩니다.
RAG를 사용할 때 흔히 저지르는 3가지 실수
대부분은 RAG 시스템을 일반 검색 엔진처럼 다루면서 초반에 벽에 부딪힙니다.
-
일반 웹 검색 인덱스를 벡터 스토어 대신 사용하는 경우
피자를 주문했는데 초밥 메뉴가 나오는 상황과 같습니다. 결과는 “검색 가능”하지만 전혀 쓸모가 없습니다. 벡터 스토어는 여러분의 PDF와 Word 파일을 임베딩해 주제에 맞는 유사도 매치를 제공합니다. -
전체 문서를 한 번에 LLM에 넣는 경우
전체 짐을 기내 반입 가방에 넣으려는 것과 같습니다. 크기 제한을 초과해 지퍼가 부러지고, 모델은 토큰 한도를 초과하면 잘라내거나 추측·환상을 만들어 냅니다. -
청크 크기와 오버랩을 무시하는 경우
거리 상세 정보가 없는 구글 지도와 같습니다. 도시만 보고 골목길을 찾을 수 없죠. 청크가 너무 크거나 오버랩이 없으면 유사도 검색이 필요한 컨텍스트를 잃어버려 정확한 답변을 만들기 어렵습니다.
해결책 #1: faiss 혹은 pinecone을 벡터 스토어로 설정하고, 여러분 문서의 임베딩만 인덱싱합니다.
해결책 #2: 문서를 임베딩하기 전에 300‑500 토큰 크기의 청크로 나눕니다. 각 청크는 모델 한도보다 충분히 작아야 합니다.
해결책 #3: 연속 청크 사이에 50 토큰 정도의 오버랩을 추가해 섹션을 넘나드는 개념이 연결되도록 합니다.
이 함정을 피하면 RAG 튜토리얼이 실제로 필요한 답변을 제공하게 됩니다.
RAG 시스템 구축 단계별 가이드
문서를 모으고 정리한 뒤 AI에 입력하면 됩니다.
-
수집 및 정리 – 모든 PDF, DOCX, Markdown 파일을 모읍니다. 스캔된 PDF가 있으면 OCR을 수행해 검색 가능한 텍스트로 변환합니다. 요리를 시작하기 전에 설거지를 하는 것과 같은 과정입니다; 소스에 찌꺼기가 있으면 안 되죠.
-
텍스트 청크화 – 정리된 텍스트를 겹치는 조각으로 나눕니다. 청크당 약 500 토큰, 청크 간 100 토큰 오버랩을 권장합니다. 퍼즐 조각의 테두리처럼 오버랩은 모델에게 인접 청크의 컨텍스트를 제공합니다.
-
임베딩 생성 – 각 청크를
text-embedding-ada-002같은 가벼운 모델이나 HuggingFacesentence‑transformers모델에 보내 임베딩을 얻습니다. 출력은 청크 의미를 담은 고밀도 벡터입니다. -
벡터 저장 – 임베딩을 Pinecone, Weaviate, Qdrant 같은 벡터 데이터베이스에 저장합니다. DB는 유사도 검색을 위한 빠른 “구글 지도” 역할을 하며, 질의와 가장 가까운 청크(점)를 찾아줍니다.
-
검색 API 구축 – 작은 엔드포인트를 작성합니다.
- 사용자 질의를 받는다.
- 벡터 스토어에 상위 k개의 유사 청크를 요청한다.
- 질의와 청크들을 연결한다.
- LLM에 전달해 답변을 생성한다.
from fastapi import FastAPI, Request
import pinecone, openai
app = FastAPI()
pinecone.init(api_key="YOUR_KEY")
index = pinecone.Index("rag-index")
@app.post("/ask")
async def ask(req: Request):
data = await req.json()
query = data["question"]
q_emb = openai.Embedding.create(
model="text-embedding-ada-002", input=query
)["data"][0]["embedding"]
results = index.query(vector=q_emb, top_k=5, include_metadata=True)
context = "\n".join([r["metadata"]["text"] for r in results.matches])
answer = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role":"system","content":context},
{"role":"user","content":query}]
)
return {"answer": answer.choices[0].message.content}-
UI에 감싸기 – API를 Slack 봇, Streamlit 대시보드, Teams 커넥터 등으로 노출합니다. 이는 사용자가 코드를 보지 않고도 질문할 수 있게 하는 “서빙 플레이트” 역할을 합니다.
-
테스트 및 모니터링 – 샘플 질의를 실행하고 지연 시간을 측정합니다. 사용자가 잘못된 답변을 표시할 수 있는 피드백 버튼을 추가해 지속적으로 청크 크기나 top‑k 값을 조정해 성능을 개선합니다.
이 일곱 단계를 따르면 실제 사용자에게 제공할 수 있는 작동 가능한 RAG 시스템 튜토리얼이 완성됩니다.
실제 사례: 마케팅 플레이북을 AI 코치로 전환하기
SaaS 마케팅 매니저 Maya는 팀이 2023년 플레이북에서 답을 바로 찾길 원합니다. 커피 한 잔 주문하는 속도처럼요.
- 42개의 PDF를 공유 Google Drive 폴더에 넣고, 무료 `pdf2txt