RAG 서베이 논문 정독: 언제 도입할 가치가 있는가
안녕하세요, 고준서입니다. 이건 긴 글이 아니라 읽은 논문을 정리해 둔 노트예요.
RAG 서베이 논문(arXiv:2312.10997)을 원문으로 정독했습니다. 요약본이나 블로그 글로 대충 아는 상태였는데, 한 번은 처음부터 끝까지 읽어 보고 싶었거든요. 논문은 RAG를 Naive, Advanced, Modular 세 단계로 나눠서 각 단계가 앞 단계의 어떤 한계 때문에 나왔는지를 짚습니다. 검색해서 붙이면 끝인 줄 알았던 Naive RAG가 왜 검색 품질과 문맥 길이에서 막히는지, Advanced가 전처리와 후처리로 그걸 어떻게 메우는지, Modular가 왜 아예 파이프라인을 조립식으로 바꾸는지가 순서대로 나와요.
정리하면서 제일 오래 붙들었던 건 “언제 도입할 가치가 있는가”였습니다. 논문 자체가 답을 주는 건 아니지만, 각 단계의 비용과 실패 지점을 나란히 놓고 보면 판단 기준이 보이더라고요. 그 기준표와 흐름 다이어그램, 그리고 원문에서 인용한 부분을 노트로 남겼습니다.
노트 전체는 rag-survey-notes 레포에 있어요. 같은 논문을 읽으실 분께 참고가 되면 좋겠습니다.
함께 읽을 만한 글
-
페이지네이션 피드백을 받고도 못 고친 것
size=1000000을 막으라는 지적을 받고 미션 안에서는 적용하지 못했고, 석 달 뒤 팀 프로젝트에서야 상한을 둔 기록
-
예외를 던지는 책임은 어디에: Repository로 옮겼다가 Service로 되돌린 커밋 쌍
없는 데이터의 예외를 리포지토리로 옮겼다가 사흘 만에 서비스로 되돌린 이유. 리포지토리는 Optional만, 판단은 서비스가
-
멘토의 질문 하나가 ID 발번 코드를 세 번 바꿨습니다: long++, AtomicLong, KeyHolder
long++에서 AtomicLong으로, 다시 KeyHolder로. 세 번 다 요구사항은 통과했고 차이는 요청이 겹칠 때만 드러났다
-
생활체조 원칙이 요구하는 줄 알았던 ProductName 클래스
첫 코드리뷰에서 '왜 이렇게 짰나요'를 받고 답하지 못해 지운 클래스, 그리고 지우는 김에 잘못 같이 지운 예외 처리