RAG(검색 증강 생성)는 AI 모델이 학습으로 익힌 지식에 더해, 모델 밖에 색인해 둔 문서에서 고른 글을 함께 읽고 답을 쓰게 하는 구조입니다(Lewis 외, 2020). 문서만 바꾸면 모델을 다시 학습시키지 않고도 답의 근거가 바뀌지만, 질문과 어긋난 글을 고르면 그 글을 근거로 틀린 답을 쓸 수 있습니다.
RAG는 Retrieval-Augmented Generation의 머리글자로, 찾아온 글(검색)로 보태어(증강) 답을 만든다(생성)는 뜻입니다. 이 이름은 Facebook AI Research와 유니버시티 칼리지 런던(UCL), 뉴욕 대학교의 연구진이 2020년 인공지능 학회 NeurIPS에서 발표한 논문에서 나왔습니다(Lewis 외, 2020).
언어 모델은 글을 읽고 쓰도록 많은 글로 학습시킨 AI 모델이고, 색인은 필요한 글을 빨리 찾도록 미리 정리해 둔 자료입니다. RAG 논문은 언어 모델이 학습하며 모델 안의 수많은 숫자(매개변수)에 담은 지식을 "매개변수 기억"이라고 부르고, 모델 밖에 둔 위키백과 색인을 "비매개변수 기억"이라고 불렀습니다(Lewis 외, 2020). 사내 문서로 RAG를 만드는 단계는 "RAG 구축 방법: 출처를 밝히며 답하는 AI를 만드는 5단계"에서 따로 다룹니다.
RAG는 어떤 순서로 답을 만드나요?
RAG는 문서를 조각으로 나눠 색인해 두었다가, 질문이 들어오면 질문과 가까운 조각을 골라 질문과 함께 언어 모델에 넣고, 모델이 그 글을 읽고 답을 쓰게 합니다. 색인은 질문이 들어오기 전에 미리 만들어 두고, 나머지 단계는 질문마다 되풀이합니다.
- 문서를 청크라는 조각으로 나누고, 조각마다 글의 뜻을 여러 개의 숫자로 나타낸 목록인 벡터를 만들어 색인에 저장합니다. 글을 벡터로 바꾸는 이 일을 임베딩이라고 합니다.
- 질문이 들어오면 같은 방식으로 질문도 벡터로 바꿉니다.
- 질문의 벡터와 가까운 조각부터 순서대로 몇 개를 고릅니다.
- 고른 조각을 질문과 함께 언어 모델의 입력에 넣고, 모델은 그 글을 읽고 답을 씁니다.
벡터를 저장해 두고 질문의 벡터와 맞춰 보는 저장소를 벡터 데이터베이스(벡터 DB)라고 합니다(AWS). 두 벡터가 얼마나 가까운지는 같은 자리의 숫자끼리 곱해 모두 더한 값(내적) 등으로 계산하며, RAG 논문은 위키백과 조각마다 벡터를 만들어 두고 질문 벡터와의 내적이 큰 순서대로 조각을 골랐습니다(Lewis 외, 2020).
벡터 검색은 질문의 낱말이 든 글을 찾는 낱말 검색(대표적인 방식이 BM25)과 달리, 낱말이 달라도 뜻이 가까운 글을 찾을 수 있습니다. RAG 논문의 검색기인 DPR을 처음 발표한 논문은 "Who is the bad guy in lord of the rings?"라는 질문을 예로 듭니다. 답이 든 글이 bad guy 대신 villain(악역)이라고 적고 있으면 낱말 검색은 그 글을 찾기 어렵지만, 벡터 검색은 두 낱말을 가깝게 볼 수 있다는 것입니다(Karpukhin 외, 2020).
RAG를 써도 AI가 틀리나요?
네, 틀릴 수 있습니다. 질문과 어긋난 조각을 고르는 검색 단계와, 답이 든 조각을 받고도 제대로 쓰지 못하는 읽기 단계에서 모두 오류가 생기며, 출처를 붙인 답도 예외가 아닙니다.
검색 단계의 대표적인 오류는 질문과 문서가 같은 내용을 서로 다른 말로 적을 때 생깁니다. 정보 검색 분야는 이를 어휘 불일치라고 부르며 핵심 과제 가운데 하나로 꼽습니다(Nogueira 외, 2019). 예시로, "3분기 공정별 생산량"을 물었는데 문서에는 "7~9월 라인별 산출 실적"이라고 적혀 있다면, 검색기는 "공정"이라는 낱말과 주제가 겹치는 "반도체 공정이란 …" 같은 정의 문단을 더 가깝게 볼 수 있습니다.
벡터 검색은 드문 이름이 든 질문에도 약할 수 있습니다. 2021년 자연어 처리 학회 EMNLP에서 발표된 연구는 위키데이터(위키미디어 재단이 운영하며 여럿이 함께 편집하는 지식 데이터베이스)의 사실을 정해 둔 질문 틀에 넣어 "아르베 푸르세트(Arve Furset)는 어디에서 태어났나요?" 같은 단순한 질문을 만들고, 이렇게 만든 질문으로 검색기를 시험했습니다. 이 시험에서 상위 20개 조각 안에 답이 든 조각이 있었던 질문의 비율은 Natural Questions라는 질문 모음으로만 학습한 DPR이 평균 49.7%, 질문 모음 네 개로 함께 학습한 DPR이 56.7%, BM25가 72.0%였습니다(Sciavolino 외, 2021). 연구진은 DPR이 위키백과에 자주 나오는 대상을 묻는 질문에서는 잘 찾았지만, 드문 대상일수록 정확도가 빠르게 떨어졌다고 보고했습니다. 아르베 푸르세트가 태어난 곳을 물었을 때 Natural Questions로만 학습한 DPR이 첫째로 고른 조각은, 아르베 푸르세트가 아니라 전설 속 족보에 나오는 Gard Agdi라는 다른 인물에 관한 글이었습니다.
읽기 단계에서는 답이 든 조각이 입력에 들어가도 그 위치가 가운데이면 놓치기 쉽습니다. 2023년에 공개되어 2024년 학술지 TACL에 실린 연구에서 GPT-3.5-Turbo에 위키백과 조각 20개를 주고 답이 든 조각의 위치만 바꿔 물었더니, 정답률은 그 조각이 맨 앞일 때 75.8%, 10번째일 때 53.8%, 맨 끝일 때 63.2%였습니다(Liu 외, 2024). 같은 연구에서 답이 든 조각이 10번째에 있을 때 GPT-3.5-Turbo가 낸 정답률은, 조각을 하나도 주지 않고 물었을 때의 정답률 56.1%보다도 낮았습니다. 이 현상은 컨텍스트 윈도우를 다룬 글에서 자세히 다룹니다.
실제 RAG 시스템에서는 오류가 생기는 곳이 더 다양합니다. 연구, 교육, 생명 의학 분야에서 RAG 시스템을 만든 사례 세 건을 정리한 2024년 연구는 실패 지점을 일곱 가지로 나눴고, 그 가운데 넷은 다음과 같습니다(Barnett 외, 2024).
- 질문이 문서 내용과 관련은 있지만 문서에 답이 없을 때, "모르겠다"고 답하지 않고 답을 내놓을 수 있습니다.
- 답이 든 문서가 있지만 순위가 낮아, 돌려주는 상위 몇 개 안에 들지 못합니다.
- 답이 든 문서가 검색되었지만, 많은 결과를 추려 입력을 만드는 과정에서 빠집니다.
- 입력에 답이 있어도 잡음이나 서로 어긋난 정보가 많으면, 모델이 답을 꺼내지 못합니다.
나머지 셋은 요청한 형식을 어긴 답, 너무 막연하거나 세세한 답, 정보 일부를 빠뜨린 답입니다(Barnett 외, 2024).
출처가 붙은 답이라고 해서 출처가 맞는 것도 아닙니다. AI가 쓴 답이 실제 사실이나 사용자가 건넨 지시와 자료에 맞지 않는 현상을 할루시네이션이라고 하며, 답에 붙은 출처가 틀리는 경우와 그 원인은 할루시네이션을 다룬 글에서 설명합니다.
RAG에서 청크와 청킹은 무엇인가요?
청킹은 검색할 단위로 문서를 잘게 나누는 일이고, 그렇게 나눈 조각 하나하나가 청크입니다. RAG 논문은 위키백과 글을 겹치지 않게 100낱말씩 끊어 청크 2,100만 개를 만들었습니다(Lewis 외, 2020).
DPR 논문은 위키백과 글에서 표와 정보 상자, 목록을 먼저 지운 뒤 본문만 100낱말 단위로 나눴습니다(Karpukhin 외, 2020). 앞뒤 조각이 겹치도록 자르는 방식은 겹치지 않게 자른 쪽보다 낫지 않았다고 적었습니다.
청크를 얼마나 크게 자를지는 정해진 답이 없는 설계 값입니다. IBM은 청크 크기를 RAG 시스템의 중요한 하이퍼매개변수(사람이 미리 정해 주는 설정 값)라고 설명하고(IBM), RAG 시스템 세 건을 만든 앞의 연구도 청크 크기와 청킹 방식, 검색 방식, 입력의 길이를 맞춰야 하고 운영 중에도 계속 다시 맞춰야 한다고 적었습니다(Barnett 외, 2024).
청크의 경계가 내용의 구조와 어긋나면 값과 그 값의 뜻이 서로 다른 청크로 갈라집니다. 아모프 창업팀이 2026년 9월 24일 같은 논문을 PDF와 학술지 XML(논문의 절과 표를 구조째 담은 파일)로 읽어 보니, PDF에서는 표의 한 줄이 숫자만 이어진 글 조각이 되고 열의 머리글은 다른 조각으로 떨어졌지만, XML에서는 표 11개가 모두 행과 열을 유지했습니다. 이런 조각을 그대로 청크로 쓰면, 숫자만 남은 청크에는 질문에 쓰인 낱말이 거의 없어 검색되기 어렵고, 검색되더라도 어느 숫자가 어느 열의 값인지 확실히 알 수 없습니다. 이 비교는 논문 PDF의 표를 다룬 글에 정리했습니다.
조각 대신 요약을 검색하는 RAG는 무엇이 다른가요?
원문 조각을 그대로 검색하지 않고, 언어 모델이 조각마다 미리 써 둔 요약이나 예상 질문을 검색 대상으로 삼는다는 점이 다릅니다. 그래서 질문과 원문의 표현이 달라도 맞는 조각을 찾을 가능성이 커지지만, 요약이 빠뜨리거나 잘못 쓴 내용은 그 내용을 물어도 찾기 어려워집니다.
조각마다 예상 질문을 만들어 붙이는 방식은 검색 분야에서 문서 확장이라는 이름으로 RAG 이전부터 시험되었습니다. 2019년 Doc2Query 연구는 문서마다 사람들이 물을 법한 질문을 모델로 만들어 문서 끝에 붙인 뒤 BM25로 검색했고, MS MARCO 검색 시험의 개발용 질문 모음에서 순위 점수(MRR@10, 정답 문서가 위에 나올수록 높은 점수)를 18.4에서 21.5로 올렸습니다(Nogueira 외, 2019). Doc2Query 연구진이 아주 흔한 낱말을 빼고 세어 보니, 모델이 만들어 붙인 질문의 낱말 가운데 31%가 원래 문서에 없던 낱말이었습니다.
요약을 여러 층으로 쌓는 방법도 있습니다. 2024년 학회 ICLR에서 발표된 RAPTOR는 비슷한 청크를 묶어 요약하고, 그 요약을 다시 묶어 요약하는 일을 되풀이해 요약 트리(아래층에서 위층으로 갈수록 더 넓은 범위를 요약한 나무 모양의 구조)를 만든 뒤, 질문에 맞는 글을 트리의 여러 층에서 찾게 했습니다(Sarthi 외, 2024). 저자들은 RAPTOR 검색을 GPT-4와 함께 썼을 때 긴 글 독해 시험인 QuALITY의 최고 정확도를 20%포인트 높였다고 보고했습니다.
요약에도 오류가 섞일 수 있습니다. 같은 연구진이 GPT-3.5-Turbo가 쓴 요약 가운데 이야기 40편에서 무작위로 고른 150개를 사람이 확인했더니, 6개(4%)에 원문에 없는 내용이 섞여 있었습니다. 연구진은 이 오류가 대체로 사소했고 위층 요약으로 번지지 않았으며, 질문에 답하는 성능에도 뚜렷한 영향이 없었다고 적었습니다(Sarthi 외, 2024). 다만 요약만 검색하는 구성에서는 요약이 빠뜨린 세부를 묻는 질문에 그 청크가 걸리지 않을 수 있고, 색인을 만들 때 청크마다 언어 모델을 불러야 하므로 문서가 많을수록 시간과 비용도 늘어납니다.
RAG와 파인튜닝은 무엇이 다른가요?
파인튜닝은 이미 학습된 모델을 특정 자료로 더 학습시켜 모델 안의 숫자를 바꾸는 방법이고, RAG는 모델 밖의 문서를 답할 때마다 찾아 읽게 하는 방법입니다. 그래서 RAG에서는 문서를 고치는 것만으로 모델이 답에 쓰는 지식을 바꿀 수 있습니다. 다만 RAG를 처음 제안한 논문도 질문을 벡터로 바꾸는 부분과 답을 쓰는 생성 모델을 과제에 맞춰 함께 파인튜닝했고, 모델을 그대로 둔 것은 학습을 마친 뒤 색인만 바꾼 실험이었습니다(Lewis 외, 2020).
RAG 논문은 2016년과 2018년 사이에 바뀐 각국 지도자 82명을 "페루의 대통령은 누구인가요?" 같은 질문으로 물었습니다. 색인이 2016년판 위키백과일 때 2018년 지도자를 맞힌 비율은 4%였지만, 모델은 그대로 두고 색인만 2018년판으로 바꾸자 68%가 되었습니다(Lewis 외, 2020). 같은 논문은 지식을 매개변수에만 담은 모델은 세상이 바뀌면 다시 학습해야 한다고 설명합니다.
다만 RAG도 문서가 바뀌면 그 문서의 임베딩을 실시간으로 또는 주기적으로 다시 만들어 색인을 갱신해야 합니다(AWS).
새 사실을 넣는 일에서는 RAG가 나았다는 비교도 있습니다. 2024년 EMNLP에 실린 연구는 정답이 붙지 않은 문서를 그대로 더 학습시키는 비지도 파인튜닝과 RAG를 비교해, 학습 때 본 지식과 처음 보는 지식 모두에서 RAG가 꾸준히 앞섰고 모델이 비지도 파인튜닝으로는 새 사실을 익히기 어려웠다고 보고했습니다(Ovadia 외, 2024). 두 방법은 함께 쓸 수도 있습니다(IBM).
GraphRAG는 일반 RAG와 무엇이 다른가요?
GraphRAG는 질문과 가까운 조각을 찾아 읽는 일반 RAG와 달리, 언어 모델이 문서에서 사람, 장소, 조직 같은 대상과 관계를 뽑아 지식 그래프(대상과 관계를 점과 선으로 이은 자료)를 만들고, 가깝게 이어진 대상의 묶음마다 요약을 미리 써 두는 방식입니다. Microsoft 연구진이 2024년에 제안한 이 방식은 "이 자료 전체의 주요 주제는 무엇인가?"처럼 문서 전체를 묻는 질문에 일반 RAG가 약하다는 점을 겨냥했고, 묶음별 요약으로 부분 답을 만든 뒤 다시 요약해 최종 답을 씁니다(Edge 외, 2024). 어떤 질문에 강하고 그래프가 틀리면 어떻게 되는지는 "GraphRAG의 뜻과 일반 RAG와의 차이: 그래프로 근거를 찾는 방식"에서 다룹니다.
이 글의 근거와 한계
RAG의 정의와 작동 방식, 색인 교체 실험은 Lewis 외(2020)를, 벡터 검색의 원리와 청크 나누기는 Karpukhin 외(2020)를, 검색과 읽기의 오류는 Nogueira 외(2019), Sciavolino 외(2021), Liu 외(2024), Barnett 외(2024)를, 요약 검색은 Nogueira 외(2019)와 Sarthi 외(2024)를, 파인튜닝과의 비교는 Ovadia 외(2024)를, GraphRAG는 Edge 외(2024)를, 벡터 데이터베이스와 청크 크기, 색인 갱신, 두 방법을 함께 쓰는 일은 AWS와 IBM의 설명 문서를 따랐습니다. 수치는 각 논문이 실험한 모델과 자료, 주로 영어 문서와 영어 질문에서 나온 값이어서, 지금의 모델이나 한국어 사내 문서에서도 같은 크기로 나타난다고 볼 수는 없습니다.
2026년 9월 24일의 관찰은 아모프 창업팀이 공개 논문 한 편을 PDF와 학술지 XML로 각각 읽어 직접 비교한 것이고, 실제 회사의 업무에 쓴 결과가 아닙니다. "예시"라고 적은 질문과 문서 문장은 설명을 위해 지어낸 것입니다.
