본 프로젝트는 특정 도메인 문서(학술 논문)를 기반으로 답변하는 RAG(Retrieval-Augmented Generation) 챗봇 파이프라인의 구축 및 배포 프로세스를 입증하는 엔지니어링 포트폴리오입니다. LangChain을 활용한 문서의 로딩, 분할, 벡터 임베딩 처리부터, 사용자의 대화 맥락을 기억하는 메모리(Memory) 시스템 연동까지 아키텍처 전반을 설계했습니다. 최종적으로 Gradio UI를 결합하여 Hugging Face Spaces에 배포함으로써 기술 검증을 넘어 실제 사용자 대상의 웹 서비스 운영 경험을 기록했습니다.
| 구분 | 세부 내용 |
|---|---|
| RAG 파이프라인 구축 |
범용 LLM의 한계(지식 부족, 환각 현상)를 극복하기 위해 Chroma 벡터 DB와 연결하여 외부 지식을 동적으로 검색 및 주입하는 구조 설계 |
| 대화 맥락 유지 (Memory) | 독립적인 단일 질의응답을 넘어, RunnableWithMessageHistory를 통해 세션별 대화 기록을 관리하여 문맥을 이해하는 다턴(Multi-turn) 대화 구현 |
| 엔드투엔드(E2E) 배포 |
백엔드 로직에 Gradio 기반의 직관적인 사용자 인터페이스를 입히고, Hugging Face 플랫폼에 호스팅하여 서비스 가용성 확보 |
📂 rag-chatbot
├── 📄 .gitignore
├── 📄 LICENSE
├── 📄 Maximizing Muscle Hypertrophy.pdf # RAG 지식 검색 기반 원본 문서
├── 📄 README.md
├── 📄 app.py # Gradio UI 및 RAG 파이프라인 통합 실행 메인 서버
└── 📄 requirements.txt # Hugging Face 배포를 위한 패키지 명세서
초거대 언어 모델이 처리할 수 없는 방대한 문서를 효율적으로 검색할 수 있도록 데이터를 전처리
| 구현 단계 | 활용 모듈 및 파라미터 | 기술적 포인트 |
|---|---|---|
| Data Loading | PyPDFLoader | PDF 문서를 페이지 단위로 추출하여 Document 객체로 변환 |
| Text Splitting | RecursiveCharacterTextSplitter | chunk_size=1000, chunk_overlap=200 설정을 통해 문맥 유실 최소화 |
| Embedding & Storage | GoogleGenerativeAIEmbeddings, Chroma | gemini-embedding-001 모델로 텍스트를 벡터화하고 Chroma DB에 색인 저장 |
사용자의 질문에 대해 가장 연관성 높은 문서를 찾아 답변을 생성하는 핵심 체인을 구성
| 프로세스 순서 | 활용 모듈 | 수행 내용 |
|---|---|---|
| 1. Retrieval | retriever | 벡터 유사도 기반으로 질문과 관련된 상위 문서 조각(Chunk) 추출 |
| 2. Prompting | ChatPromptTemplate | System Prompt, Context, Chat History, User Input을 결합한 동적 프롬프트 설계 |
| 3. Generation | create_retrieval_chain | 검색된 문서와 질문을 Gemini 2.0 Flash 모델에 전달하여 최종 답변 생성 |
LCEL(LangChain Expression Language)을 활용하여 체인에 대화 상태 관리 기능을 주입
| 메모리 관리 기법 | 활용 객체 | 비고 |
|---|---|---|
| Session Tracking | get_session_history, session_id | 사용자별로 InMemoryChatMessageHistory를 독립적으로 할당하여 대화 격리 |
| History Integration | MessagesPlaceholder | 프롬프트 내 대화 기록이 삽입될 위치를 지정하여 문맥 유지 |
| 분석 항목 | 세부 해결 과정 및 전략 |
|---|---|
| 환각 현상(Hallucination) 억제 |
System Prompt 에 "문서에 없는 내용은 모른다고 답하세요"라는 제약 조건을 명시하여 모델의 추론 범위를 문서 내로 한정 |
| 청크 분할 문맥 유지 | chunk_overlap을 적용하여 인접한 조각 간의 정보 연속성 보존 |
| UI 이벤트 안정화 | Gradio의 submit과 click 이벤트를 단일 콜백 함수로 통합하여 다양한 사용자 입력 패턴에서도 동일한 응답 로직 보장 |
| 핵심 개념 | 비유 (Analogy) | 기술적 의미 설명 |
|---|---|---|
| RAG (검색 증강 생성) | 오픈북 시험 | AI가 사전 지식에만 의존하지 않고, 문서를 참고하여 정답을 도출하는 기법 |
| Vector Embedding | 도서관 십진분류표 | 단어의 의미를 좌표로 변환하여 의미 기반 검색 수행 |
| Text Splitter (Overlap) | 포스트잇 겹쳐 붙이기 |
일부를 겹치게 잘라 문맥을 보존하는 방식 |
👉 1. https://huggingface.co/spaces/AD-Styles/RAG_Chatbot
👉 2. https://huggingface.co/spaces/AD-Styles/RAG_Chatbot_Upgrade
이번 RAG(Retrieval-Augmented Generation) 챗봇 프로젝트는 단순한 API 호출을 넘어 데이터 전처리부터 메모리 관리, 배포까지 이어지는 전체 파이프라인을 설계하였습니다. 단순히 LangChain 라이브러리를 사용해 보는 단계를 넘어, LLM의 고질적인 문제인 '환각 현상(Hallucination)'과 '최신 정보 부재'를 엔지니어링적으로 어떻게 해결할 것인지에 대한 해답을 지속적으로 생각할 수 있는 과정이었습니다. 우선, 모델의 사전 학습 지식에 의존하지 않고 외부 문서를 실시간으로 참조하는 구조를 설계하며 LLM의 한계를 극복하려 했습니다. 사용자의 질문이 들어오면 LLM이 바로 답하는 것이 아니라, 관련 문서 조각을 먼저 찾아낸 뒤 그 내용을 기반으로 답변하도록 프롬프트를 구성했습니다. 시스템 프롬프트에 "문서에 없는 내용은 모른다고 답하라"는 제약 조건을 명시함으로써, 모델이 모르는 것을 지어내는 '환각 현상'을 효과적으로 제어할 수 있었습니다. 이는 AI 서비스의 신뢰성을 결정짓는 가장 중요한 엔지니어링 포인트였습니다.
그리고 방대한 PDF 문서를 컴퓨터가 이해할 수 있는 벡터(Vector) 형태로 변환하고 저장하는 과정에서, 텍스트를 너무 작게 자르면 의미가 단절되고, 너무 크게 자르면 검색 노이즈가 섞인다는 문제를 해결하기 위해서 1,000자 단위로 분할하되, 조각 간 200자의 Overlap을 설정했습니다. 적절한 오버랩을 통해 잘린 문장 사이의 문맥적 연결 고리를 보존하는 것이 검색 품질에 직결됨을 확인했습니다. 또한, 단발성 질의응답을 넘어 사용자와의 이전 대화 흐름을 기억하는 메모리 시스템을 LCEL 파이프라인에 통합했습니다. InMemoryChatMessageHistory와 RunnableWithMessageHistory를 결합하여 세션별 대화 기록을 관리했습니다. MessagesPlaceholder를 사용해 프롬프트 내에 chat_history가 삽입될 위치를 지정함으로써, 질문이 이전 맥락과 연결될 때(예: "그거 좀 더 자세히 설명해줘") 모델이 정확한 지칭 대상을 인지하도록 설계했습니다. 최종적으로 단발성 질의응답 시스템에 Memory 모듈을 도입하고 Gradio UI를 통해 시각화함으로써, '기술'을 실제 사용자가 편리하게 사용할 수 있는 '서비스'의 형태로 구현하는 과정을 경험했습니다.
이번 프로젝트를 통해 데이터 로딩 → 벡터화 → 검색 → 생성 → 메모리 관리로 이어지는 RAG의 전 과정을 코드로 직접 제어하며 시스템 아키텍트로서의 감각을 익혔습니다. 각 파라미터(chunk_overlap, temperature)가 서비스의 최종 품질에 미치는 영향을 데이터로 확인한 것이 가장 큰 수확입니다. 특히 RAG 시스템의 성능은 모델의 크기만큼이나 이를 제어하는 엔지니어가 데이터를 어떻게 가공하고(Chunking), 어떻게 질문을 던지느냐(Prompt Engineering) 에 따라 최종 서비스의 품질이 결정된다는 사실을 깨달았습니다.