RAG #1

(사진=셔터스톡)

Retrieval Augmented Generation

 

이 글을 쓰게 된 이유는 올해가 가기 전에 마지막으로 RAG를 정리하고, 잠시 내려놓고 싶은 생각에 글을 쓰게되었다.

2023년 즈음부터 RAG는 정말 많이 회자됐다.

논문, 블로그, 컨퍼런스, 그리고 회사 프로젝트까지 어디를 가든 RAG 이야기가 빠지지 않았다.

나 역시 예외는 아니어서, 회사에서 여러 LLM 프로젝트를 진행하며 RAG를 꽤 깊게 다뤄보게 됐다.

 

 

돌이켜보면, 내가 RAG라는 개념을 처음 접한 건 Kaggle이었다.

 

Kaggle - LLM Science Exam 후기

 

그때는 지금처럼 생성형 LLM과 함께 쓰는 구조가 아니었고, DeBERTa 계열 모델로 4지선다 문제를 푸는 태스크를 다루고 있었다.

사람들은 Discussion에서 “context를 잘 붙여주면 정답률이 올라간다”는 방법론을 공유했고, 사람들이 좋다고 하길래, 나도 자연스럽게 그 방식을 따라 실험해 봤다.

 

재미있는 건, 그 당시엔 RAG라는 표현이 지금처럼 보편적이지 않았다는 점이다.

아예 쓰이지 않았다고 하긴 어렵지만, 적어도 익숙한 단어는 아니었다.

 

사람들 관심은 이름보다는 그냥 “retrieval을 잘해서 context를 붙이면 성능이 올라간다”는 꽤 실용적인 아이디어에 쏠려 있었고, 나 역시 그런 식으로 이해하고 접근했었다.

지금 와서 보면 꽤 전형적인 RAG 구조였지만, 당시엔 그걸 굳이 하나의 개념으로 인식하진 않았던 것 같다.

 

 

 

일로서 마주한 RAG

그 이후 회사에서 LLM 관련 프로젝트를 여럿 진행하면서, 자연스럽게 RAG를 접하게 되었다. 그 과정에서 RAG를 이해하는 데 가장 큰 도움을 줬던 건, Retrieval-Augmented Generation for Large Language Models: A Survey 논문이었다.

출처 :Retrieval-Augmented Generation for Large Language Models: A Survey

이 논문은 RAG를 Retrieval, Augmentation, Generation이라는 세 영역으로 나누고, 각 단계에서 사용될 수 있는 기술들을 굉장히 촘촘하게 정리해 두었다.

솔직히 말하면, 이 논문 하나를 제대로 이해하는 데만 2주 넘게 걸렸던 것 같다.

 

그만큼 RAG라는 게 단순한 파이프라인이 아니라, 선택의 조합이 너무 많은 구조라는 걸 그때 처음 체감했다.
어쨌든 그렇게 RAG를 접했고, 워낙 주목받는 기술이다 보니 회사에서도 본격적으로 연구를 해보고 프로토타입을 만들어보자는 이야기가 나왔다.

 

그게 2024년 말쯤이었고, 한창 테스트를 하다가 여러 사정으로 잠시 보류했다가, 2025년에 다시 꺼내 들었다.
그리고 올해 말, 결국 사내에 오픈까지 하게 됐다.

 

 

 

RAG의 현실과 한계

올해는 유난히 RAG라는 기술과 많이 부딪힌 한 해였던 것 같다.

특히 회사에서는 open source 모델을 사용하다 보니, multi-turn 대화에서 적절한 문서를 검색하고, 그걸 기반으로 안정적으로 답변을 생성해 제공하는 게 생각보다 쉽지 않았다.

이론적으로는 그럴듯한데, 실제로는 작은 설정, 프롬프트 하나 때문에 결과가 확 바뀌는 경우도 많았고, “이게 맞는 방향인가?”라는 생각이 들 때도 많았다.

그래서인가 프로젝트를 진행하면 할수록, RAG만으로 서비스를 구성하는 데는 한계가 있는 것 같다는 생각이 들었다.

시장 흐름을 봐도, RAG가 혼자서 모든 걸 해결해 주는 구조는 점점 어렵다는 느낌이 들었고, 자연스럽게 이야기는 Agentic AI 쪽으로 넘어가고 있다.

그래서 더더욱, 올해가 가기 전에 RAG를 한 번 제대로 정리하고, 스스로 RAG에 대해 “어디까지 해봤고, 뭐가 좋았고, 뭐가 별로였는지”를 남겨둬야겠다는 생각이 들었다.

 

 

 

실험 환경 정리

당연히도 회사에서 테스트한 내용을 그대로 공개할 수는 없어서, 처음부터 다시 실험을 진행했다.

회사에서 이미 해봤던 기법도 있고, 못 해봤던 것도 있고, 했지만 다시 검증해보고 싶은 것들도 있었다.

그중에서 비교적 보편적으로 많이 언급되는 방법들을 골라 테스트 대상으로 삼았다.

 

 

🛠️ 실험 환경 - Baseline

이번 실험에서는 Gemini API를 주로 사용하기로 했다. 사실 선택지가 많지는 않았다. 오픈소스 모델을 여럿 돌릴 만큼 gpu가 넉넉하지 않았기 때문이다. 

기본 설정값은 다음과 같다. 앞으로 해당 설정값에서 여러 가지를 바꿔가며 테스트를 진행하며 정리할 예정이다.

• Embedding Model: gemini-embedding-001
• Chunking: Recursive Character (Size: 512 / Overlap: 50)
• Generation Model: Gemini 2.5 Flash
• Vector DB: FAISS (기본값으로 고정)
• Retrieval K: 5

 

 

📊 데이터셋 및 평가

• 데이터셋: Allganize Benchmark 데이터셋에서 domain별로 3~4개씩 문서를 선정하여, 총 18개의 문서를 선별했다. 
• 규모: Baseline 청킹 기준 약 700개의 청크 생성.
• 평가 방법: 정량 평가를 기본으로 하되, 정성적 판단이 필요한 부분은 LLM-as-a-judge 기법을 활용할 예정이다.

 

 

 

앞으로의 계획

이 시리즈에서는 논문 리뷰나 공식 벤치마크 정리보다는, 개인적으로 이것저것 테스트해 보면서 느낀 점들을 정리하는 정도로 공유해보려고 한다.

 

완벽한 답을 내리려는 목적은 아니고, 나처럼 RAG를 다시 처음부터 세팅해야 하는 상황이라면 “아, 이런 데서 한 번쯤은 걸릴 수 있겠구나” 정도만 참고가 되면 충분하겠다 싶다.

 

다음 편에서는 RAG 성능에 꽤 큰 영향을 줬던 요소 중 하나인, Chunking 전략별 실험 결과를 먼저 정리해보려고 한다.