📚 RAG

RAG 란 무엇이고, OpenAI 같은 LLM 을 단순히 사용할 때의 한계와 극복 하는 방법에 대해서 알아보자

🛑 LLM 의 한계

ChatGPT와 같은 LLM(Large Language Model)은 놀라울 정도로 똑똑하지만, 치명적인 약점이 몇 가지 있습니다.

최신 정보 부족: 학습 시점 이후의 정보는 모릅니다.
사내/개인 데이터 접근 불가: 회사의 비공개 문서나 내 개인 메모는 학습하지 않았습니다.
Hallucination (환각): 모르는 내용도 마치 사실인 것처럼 그럴듯하게 지어냅니다.

실제로, 작성일 기준, OpenAI 사의 GPT-5 모델(https://openai.com/ko-KR/index/introducing-gpt-5/?utm_source=chatgpt.com)은 다음 엄청나게 많은 지식을 학습한 모델이지만, 특정 기간까지의 데이터를 학습하였기 때문에, 학습 이후에 생성된 지식에 대해서는 잘 알지 못합니다.

😵‍💫 한계 확인해보기

만약 다음과 같이 "오늘 날씨는 어떻고 외출하기 좋아?" 이라는 질문을 해봅니다.

LLM 모델에는 특정 기간내의 날씨 정보에 대해서 학습하였겠지만, 오늘 기준으로는 정보가 없습니다.

따라서, 제대로 된 답변이 오지 않을 가능성이 높아집니다.

최근 GPT5, 4 등의 모델은 이런 질문에 대해서 Web 검색을 통해 문제를 확인하기 때문에, 확인이 가능합니다.

💡 극복 하기 위한 방법

만약, 동일하게 "오늘 날씨는 어떻고 외출하기 좋아?" 를 질문하는데, 정답을 함께 알려주면 어떨까요?

즉, "오늘의 날씨는 = {} 이야. 오늘 외출하기 좋아?" 라고 질문을 한다면 어떻게 될까요?

외출하기 좋은 것에 대한 지표는 학습때와 현재가 크게 다르지 않기 때문에 명확한 정보를 알려줄 가능성이 높아집니다.

즉, LLM 이 학습해서 가지고 있지 못한 정보(document) 들을 제공하고, 이를 토대로 응답을 생성하게 하는 방법이 있습니다.

🤖 RAG 란

위에서 설명한 정보를 전달하고 답변을 생성하게 만드는 방식이 RAG 입니다.

특정 도메인에 대한 지식이나, 사내 프로세스, 기밀 문서 등은 LLM 이 사전에 학습했을 가능성이 현저히 낮습니다.

따라서, LLM 에게 정보를 전달해 줘서 오픈북 테스트를 보게 만드는 기법 입니다.

파인 튜닝과는 전혀 다른 얘기입니다.
파인 튜닝은, 직접 LLM 에 정보를 학습 시켜 원하는 응답을 생성할 수 있도록 학습 하는 작업입니다.
이를 위해선 많은 리소스가 필요합니다.

RAG 의 이점

최신성: 재학습(Fine-tuning) 없이도 새로운 정보를 바로 반영할 수 있습니다.
정확성: 근거 자료를 바탕으로 답변하므로 Hallucination(거짓 답변)이 현저히 줄어듭니다.
보안: 민감한 데이터를 모델에 직접 학습시키지 않고도 활용할 수 있습니다.

⚙️ RAG 의 과정

RAG 를 구현하기 위해서는, 특정 도메인에 대한 정보(Document) 가 필요합니다.

만약, 복잡한 세금 업무를 처리하는 봇을 만들기 위해서는, 세금 업무와 관련된 세법 정보가 필요합니다.

이후, 이 데이터를 Indexing(색인) 하여 검색되게 할 수 있도록 준비합니다.

마지막으로 검색을 통해 질문과 관련 있는 문서를 찾아 내, LLM 에게 제공하여 함께 질문 합니다.

출처 : https://docs.langchain4j.dev/tutorials/rag

색인(Indexing)

RAG를 수행하기 전, 우리가 가진 데이터를 LLM이 찾기 쉬운 형태로 미리 저장해두는 단계입니다. 보통 사용자가 질문하기 전(Offline)에 이루어집니다.

(출처: LangChain4J Documentation - Indexing Stage)

Document: PDF, 텍스트 파일, 웹 페이지 등 원본 데이터를 가져옵니다.
Text Splitter: 문서를 적절한 크기의 조각(Segment)으로 자릅니다. (Chunking)
Embedding Model: 텍스트 조각을 기계가 이해할 수 있는 숫자 벡터(Vector)로 변환합니다.
Embedding Store: 변환된 벡터를 벡터 데이터베이스(Vector DB)에 저장합니다.

Retrieval (검색 단계)

사용자가 실제로 질문을 던졌을 때 실시간(Online)으로 일어나는 과정입니다.

(출처: LangChain4J Documentation - Retrieval Stage)

Query: 사용자가 질문을 합니다.
Embedding: 질문 자체도 Embedding Model을 통해 벡터로 변환합니다.
Similarity Search: 질문 벡터와 가장 유사한(거리가 가까운) 문서 조각을 Vector DB에서 찾습니다.
Prompt Injection: 찾은 관련 정보(Relevant Segments)를 프롬프트에 포함시킵니다.
LLM Response: LLM은 사용자의 질문과 함께 제공된 참고 자료를 읽고 최종 답변을 생성합니다.

🔍 검색 방식

RAG에서 가장 중요한 것은 "얼마나 관련된 문서를 잘 찾아오느냐"입니다.

Full-text (Keyword) Search: 우리가 흔히 아는 키워드 매칭 방식입니다 (예: TF-IDF, BM25). 특정 단어가 문서에 포함되어 있는지 확인합니다.
Vector Search (Semantic Search): 문장의 의미(Semantic)를 기반으로 검색합니다. 단어가 정확히 일치하지 않아도 문맥상 비슷하면 찾아낼 수 있습니다. (이번 프로젝트의 핵심입니다.)
Hybrid Search: 위 두 가지 방식을 혼합하여 정확도를 높이는 방식입니다.

🦜 구현할 RAG 소개

해당 블로그에는 다양한 기술들과 CS 지식들이 담겨져 있는 블로그 입니다. ~~아직 매우 포스트 숫자가 부족하긴 하지만...~~

추후, 포스트가 추가되게 되면, 많은 지식들이 해당 블로그에 담기게 될 것인데, AI 를 통해 어떤 질문에 대해 기술 블로그의 글을 추천해주는 AI 챗봇을 만들어 볼 예정입니다.

즉, "멀티 스레드가 뭐야?" 라고 물어본다면

챗봇 응답)
멀티 스레드란 하나의 프로세스 내에서 여러 개의 스레드가 동시에(병렬/병행) 실행되는 구조를 말합니다. 멀티 프로세스와 달리 여러 스레드는 동일한 프로세스의 코드/데이터/힙 영역을 공유하고, 각 스레드는 고유한 스레드 ID·프로그램 카운터·레지스터 값 등을 갖되(이들은 주로 각 스레드의 스택에 저장됨), 스택 영역만 분리되어 있습니다.
주요 특징
자원 공유: 전역 변수, 정적 변수, 힙 등은 스레드 간에 직접 공유되어 빠른 데이터 교환이 가능합니다.
독립적 실행 흐름: 각 스레드는 독립적인 실행 흐름(작업 단위)을 가집니다.
장점: 자원 효율적이며 데이터 공유/협업이 쉬움.
단점: 동기화 문제(레이스 컨디션 등)와 오류 전파 가능성 — 한 스레드의 문제로 전체 프로세스에 영향이 갈 수 있음.
동기화 도구(예: join으로 스레드 종료 대기, 뮤텍스/세마포어/모니터 등)를 통해 임계 구역 보호와 실행 순서 제어가 필요합니다.
관련 게시글:
[운영 체제] 프로세스와 스레드
[운영 체제] 프로세스&스레드의 공유자원 동기화
[운영 체제] CPU 스케줄링 알고리즘(Scheduling Algorithm)

이런식으로, 제 블로그 포스트를 기반으로 응답을 생성하고 포스트를 추천할 수 있도록 만들 예정입니다.

이 챗봇은 Java Spring Boot 환경에서 LangChain4j 프레임워크를 사용하고, 벡터 저장소로는 ELK Stack(Elasticsearch)을 활용하여 구축할 예정입니다.

🤖 RAG: LLM의 한계를 극복하는 방법

스택 시리즈LLM & RAG with Langchain4J