List
지난 글에서는 프롬프트 엔지니어링을 통해 LLM(Large Language Model)의 성능을 높이는 방법에 대해 알아봤습니다. 그런데 아무리 프롬프트를 잘 구성하더라도 모델이 학습 시점 이후의 최신 정보를 알지 못하거나, 특정 전문 분야의 세부적인 내용을 모른다면 정확한 답변을 얻기 어렵습니다.
이번 글에서는 이런 문제를 효과적으로 해결할 수 있는 RAG(Retrieval-Augmented Generation)에 대해 구체적으로 알아보겠습니다.
1. RAG(Retrieval-Augmented Generation)이 왜 필요할까?
사실 RAG는 이름만 들으면 뭔가 특별한 최신 기술처럼 느껴질 수 있지만, 생각보다 단순한 개념입니다. 쉽게 말해, LLM이 답을 생성하기 전에 외부에서 관련된 문서나 데이터를 먼저 가져와(Retrieval), 그 자료를 바탕으로 최종 답변을 생성(Generation)하는 방식을 말합니다.
기본적인 아이디어는 모델이 모든 정보를 알고 있지 않아도, 필요한 순간에 관련된 자료를 찾아보고 참고해서 답변하도록 하는 방식입니다.
그렇다면 왜 이런 방식이 필요한 걸까요? 다음과 같은 이유 때문입니다.
•
LLM이 가진 최신성의 한계
대부분의 LLM은 특정 시점까지의 데이터만 학습되어 있어, 그 이후에 업데이트된 최신 정보를 전혀 알 수 없습니다. 그래서 시사나 최신 뉴스를 묻는 질문에 정확히 답변하기 어렵습니다.
•
세부적이고 전문적인 정보 부족
LLM은 방대한 양의 일반적인 지식은 알고 있지만, 특정 분야의 전문적인 세부 지식이나 개인·기업의 내부 자료까지는 알지 못합니다. 예를 들어, 특정 기업의 최근 재무상황이나 내부 정책 같은 세부 정보를 모델이 바로 알 수는 없습니다.
•
환각(Hallucination) 문제 해결
때때로 LLM은 잘못된 내용을 자신 있게 답변하는 '환각 현상'이 발생합니다. 정확한 자료를 미리 제공하여 이런 현상을 방지할 수 있습니다.
이러한 한계를 극복하기 위해, 모델이 특정 질문을 받으면, 먼저 최신 정보를 담고 있거나 신뢰할 수 있는 문서를 외부에서 가져온 후 그 내용을 참조하여 답변하게 만드는 것입니다.
2. RAG을 구현하기 위한 다양한 방법
RAG을 구현하기 위한 구체적인 기술적 방법과 스택을 조금 더 자세히 살펴보겠습니다. 크게 다음과 같은 세 가지 접근 방식이 있습니다.
1. 간단한 문서 검색 (Simple Document Retrieval)
가장 단순한 형태로, 질문이 들어왔을 때 미리 준비된 문서 데이터베이스에서 키워드를 기반으로 관련 문서를 바로 검색해 제공합니다.
•
기술 스택 예시: Elasticsearch, Lucene, PostgreSQL(Full-text search), MongoDB Text Search
•
장점: 가장 빠르고 쉽게 구현 가능, 관리가 용이
•
단점: 정확도가 떨어질 수 있으며, 문맥 이해 능력이 낮음
2. 임베딩(Embedding) 기반 검색 (Vector Search)
질문과 문서를 모두 임베딩(Embedding)을 이용해 벡터화하고, 벡터 간의 유사도(Cosine Similarity 등)를 기반으로 정확히 관련 문서를 찾는 방식입니다.
•
기술 스택 예시: OpenAI Embeddings, HuggingFace Embeddings, Cohere Embeddings, 벡터 DB (FAISS, Pinecone, Chroma, Weaviate)
•
장점: 문맥적 의미를 고려하여 정확도가 매우 높음, 세부 전문 영역에서 효과적
•
단점: 초기 구축과 유지보수의 복잡성이 증가, 문서가 매우 많으면 비용 상승 가능
3. 하이브리드(Hybrid) 검색
키워드 기반 검색과 임베딩 기반의 벡터 검색을 결합하여 사용하는 방식입니다. 우선 키워드 검색으로 후보 문서 범위를 빠르게 줄이고, 이후 벡터 검색으로 정확도를 더 높이는 방법입니다.
•
기술 스택 예시: Elasticsearch (dense & sparse retrieval), Vespa, Weaviate Hybrid
•
장점: 속도와 정확도를 동시에 확보 가능, 범용적으로 다양한 도메인에 적합
•
단점: 초기 설정과 구현이 다소 복잡할 수 있음, 두 시스템을 함께 관리해야 함
이외에도 최신 논문이나 실제 산업 현장에서는 다양한 변형 방법이 있지만, 위 세 가지 방식 중 하나로 구현하면 대부분의 RAG 시스템을 효과적으로 구성할 수 있습니다.
3. RAG을 실제로 사용할 때 데이터가 들어가는 방식
실제 RAG을 사용할 때는 주로 다음과 같은 구조로 처리가 이루어집니다.
(사용자 질문)
↓
[검색 단계] → 외부 문서 DB에서 사용자 질문과 가장 관련된 문서를 검색
↓
[프롬프트 구성 단계] → 검색된 문서를 시스템 프롬프트 내에 포함
↓
[모델 요청 단계] → 완성된 프롬프트 + 사용자 질문을 모델에 전달
↓
(모델 답변)
Plain Text
복사
여기서 각 데이터는 다음과 같은 위치에서 쓰입니다.
•
시스템 프롬프트:
◦
모델이 답변을 생성할 때 참고할 수 있도록 검색된 문서 내용이 들어갑니다.
◦
보통 "아래 내용을 참고하여 질문에 답변하세요:\n{검색된 문서 내용}" 형태로 사용됩니다.
•
유저 인풋:
◦
사용자가 실제로 입력하는 질문입니다. 이 질문을 바탕으로 검색 단계에서 가장 적절한 문서를 찾아내게 됩니다.
◦
"2024년 한국의 경제 성장률 전망이 어떻게 되나요?" 와 같은 구체적인 질문이 들어갑니다.
즉, RAG 시스템에서는 검색된 문서를 시스템 프롬프트로 제공하고, 사용자의 질문을 유저 인풋으로 제공하여 모델이 정확하고 최신의 정보를 활용해 답변하도록 하는 구조입니다.
4. RAG을 사용할 때의 유의점
RAG을 효과적으로 쓰기 위해서는 아래 사항을 주의해야 합니다.
•
검색되는 문서 품질 관리:
◦
낮은 품질의 문서가 들어가면 답변 품질도 낮아질 수 있습니다. 데이터베이스에 저장되는 문서를 꾸준히 점검하고 품질을 높이는 것이 중요합니다.
•
벡터 데이터베이스 업데이트 및 관리:
◦
최신 정보를 제대로 제공하려면 벡터 데이터베이스를 정기적으로 업데이트하고 관리해야 합니다. 오래된 정보가 섞이면 정확도가 떨어질 수 있습니다.
•
처리 속도 및 비용 문제:
◦
문서 검색 과정이 추가되므로 응답 속도가 조금 느려질 수 있습니다. 속도가 중요한 서비스라면 적절한 최적화 작업이 필요합니다.
마무리
결론적으로 RAG은 복잡하거나 새로운 기술이 아니라, LLM이 갖고 있는 한계를 현실적으로 해결할 수 있는 매우 유용한 방법입니다. 최신 정보와 세부 전문성을 보완하기 위해 모델이 답변할 때 외부 자료를 참고하게 만드는 간단하지만 효과적인 방법입니다.
다음 글에서는 RAG의 개념을 한 단계 더 확장한 형태인 에이전트(Agent) 방식에 대해서 알아보고, 실제 구현 사례까지 살펴볼 예정입니다.