RAG는 검색 엔진에 LLM을 붙인 정도가 아닙니다. RAG는 검색된 문서를 생성 과정의 입력으로 넣어서, 모델이 그 문맥을 바탕으로 답을 만들어내는 구조입니다. 이 글에서는 원 논문 기준으로 retrieval, 문맥 결합, generation 흐름을 짧고 정확하게 정리하겠습니다.
RAG를 한 문장으로 정의하면
RAG(Retrieval-Augmented Generation)는 언어모델이 내부 파라미터에만 의존하지 않고, 외부 문서 저장소에서 관련 문서를 가져와 그 문서를 조건으로 답을 생성하는 방식입니다. 원 논문은 이를 parametric memory와 non-parametric memory의 결합으로 설명합니다.
즉 모델이 이미 학습해 둔 지식만 꺼내는 것이 아니라, 필요할 때 외부 문서를 찾아 읽고 그 문맥 위에서 답을 만드는 구조라고 이해하면 됩니다.
RAG는 왜 단순 검색이 아닐까
일반 검색 시스템은 보통 관련 문서 목록을 반환합니다. 사용자는 그 목록을 보고 필요한 내용을 직접 읽어야 합니다. 반면 RAG는 검색 결과를 최종 출력으로 끝내지 않고, 검색된 여러 문서를 생성 모델 입력에 함께 넣어 질문에 맞는 답변을 새로 생성합니다.
- 검색: 관련 문서를 찾는 것이 끝
- RAG: 관련 문서를 찾은 뒤 그 문서를 바탕으로 답을 생성하는 것이 핵심
그래서 RAG는 검색 시스템이 아니라 검색을 포함한 생성 시스템이라고 보는 편이 더 정확합니다.
RAG의 핵심 구조는 이렇게 움직인다
- 사용자 질문이나 입력을 임베딩한다
- 그 임베딩으로 외부 문서 인덱스에서 관련 문서를 찾는다
- 검색된 문서들을 원래 질문과 함께 생성 모델 입력으로 결합한다
- 생성 모델이 여러 문서를 조건으로 최종 답을 만든다
이 흐름에서 retrieval은 앞단이고 generation은 뒷단입니다. 하지만 둘은 따로 노는 단계가 아니라 같은 출력 과정을 함께 구성합니다. 검색 품질이 나쁘면 생성 품질도 흔들리고, 생성 프롬프트가 어색하면 좋은 검색 결과도 제대로 활용되지 못합니다.
retrieval 단계는 왜 키워드 검색과 다르게 느껴질까
원 논문은 Wikipedia의 dense vector index와 pre-trained neural retriever를 사용합니다. 즉 문서를 단어 일치만으로 찾는 것이 아니라, 질문과 문서를 임베딩 공간에서 가깝게 배치해 관련 문서를 찾는 접근입니다.
Dense Passage Retrieval 논문도 전통적인 sparse retrieval인 TF-IDF나 BM25와 대비해 dense representation 기반 검색기를 설명합니다. 이 점 때문에 RAG의 retrieval 단계는 단순 키워드 검색과 완전히 같다고 보기 어렵습니다.
물론 오늘 실무에서는 BM25, hybrid search, reranker까지 섞는 경우가 많습니다. 그래도 기본 감각은 같습니다. 좋은 문서를 찾는 단계와, 그 문서를 바탕으로 답을 쓰는 단계가 함께 있어야 RAG라고 부를 수 있습니다.
생성 단계가 진짜 본체인 이유
검색만으로는 답이 완성되지 않습니다. 검색 결과에는 관련 문서가 여러 개 섞여 있을 수 있고, 일부는 덜 중요하거나 서로 조금씩 다른 표현을 가질 수 있습니다. RAG의 생성 모델은 이 문서들을 입력으로 받아 질문에 맞는 표현으로 다시 조합합니다.
- 검색은 무엇이 관련 있는가를 고른다
- 생성은 그중 무엇을 어떻게 설명할지를 결정한다
결국 RAG의 출력은 문서 목록이 아니라 문맥화된 답변입니다. 이 차이를 놓치면 RAG를 단순한 문서 검색 기능 정도로 오해하게 됩니다.
RAG-Sequence와 RAG-Token은 무엇이 다를까
RAG-Sequence
RAG-Sequence는 한 번 검색한 문서 집합을 전체 답변 시퀀스 동안 공통 문맥으로 사용합니다. 질문에 대해 관련 문서를 먼저 고른 뒤, 그 문서 묶음을 보면서 답 전체를 생성한다고 생각하면 이해하기 쉽습니다.
RAG-Token
RAG-Token은 생성 중인 각 토큰 단계에서 서로 다른 문서를 참조할 수 있는 형태입니다. 개념적으로는 더 유연합니다. 답변 앞부분과 뒷부분에서 중요하게 참고해야 하는 문서가 다를 수 있기 때문입니다.
- RAG-Sequence: 문서 묶음을 먼저 고정하고 답 전체를 생성
- RAG-Token: 생성 과정에서 문서 참조가 더 유동적
아주 간단한 의사코드로 보면
query = "RAG는 왜 단순 검색이 아니지?"
query_vec = embed(query)
retrieved_docs = retriever.search(query_vec, top_k=5)
context = join(retrieved_docs)
prompt = build_prompt(query=query, context=context)
answer = generator.generate(prompt)이 의사코드는 RAG의 감각을 가장 단순하게 보여줍니다. 먼저 찾고, 그다음 붙이고, 마지막에 생성합니다. 겉보기에는 간단하지만 바로 이 결합 때문에 RAG는 검색 단독 시스템과 다른 범주에 들어갑니다.
실무형 RAG에서는 어떤 단계가 더 붙을까
- 문서 수집과 정제
- 청크 분할
- 임베딩 생성
- 인덱싱
- 검색
- 재정렬(reranking)
- 프롬프트 결합
- 최종 답변 생성
오늘 많이 만드는 사내 문서 챗봇이나 지식 기반 QA는 원 논문보다 파이프라인이 조금 더 길 수 있습니다. 그래도 중심 구조는 그대로입니다. 외부 지식을 찾고, 그 지식을 생성 조건으로 넣는다는 점은 변하지 않습니다.
자주 생기는 오해
검색 품질이 나빠도 생성이 알아서 고쳐준다는 오해
그렇지 않습니다. 검색이 엉뚱한 문서를 가져오면 생성 단계도 흔들립니다. 생성 모델이 문장을 자연스럽게 다듬을 수는 있어도, 근거 문맥 자체가 나쁘면 답의 품질 한계도 분명합니다.
문서를 붙였으니 무조건 사실성이 올라간다는 오해
RAG는 사실성 개선에 도움이 될 수 있지만, 항상 자동으로 보장되지는 않습니다. 문서 청크 전략, 검색 결과 품질, 프롬프트 설계에 따라 여전히 부정확한 답이 나올 수 있습니다.
RAG는 검색 기능 하나만 추가하면 된다는 오해
RAG는 검색 API 하나 붙인다고 끝나지 않습니다. 어떤 문서를 어떻게 자를지, 무엇을 임베딩할지, 몇 개 문서를 넣을지, 생성 프롬프트를 어떻게 설계할지까지 모두 결과에 영향을 줍니다. 그래서 품질은 모델 하나보다 파이프라인 전체 설계에 더 크게 좌우되는 경우가 많습니다.
언제 RAG가 특히 유용할까
- 사내 위키, 정책 문서, 매뉴얼처럼 외부 문서를 반드시 읽어야 하는 경우
- 자주 바뀌는 지식이 많아 모델 재학습보다 인덱스 갱신이 현실적인 경우
- 답변과 함께 근거 문서를 추적하고 싶은 경우
- 특정 조직 문맥에 맞는 답변이 필요한 경우
이런 문제에서는 모델이 이미 알고 있을 것이라고 기대하기보다, 필요한 문서를 먼저 찾게 만드는 편이 더 안정적입니다. 외부 참고로는 RAG 원 논문, Dense Passage Retrieval 논문, Hugging Face RAG 문서를 함께 보면 좋습니다.
정리
RAG는 단순 검색이 아닙니다. 검색된 문서를 생성 조건으로 넣어 답을 만드는 구조이기 때문입니다. 원 논문 기준으로 보면 핵심은 파라메트릭 메모리와 비파라메트릭 메모리의 결합, dense retrieval, 그리고 검색된 문서를 바탕으로 한 생성입니다.
그래서 RAG를 제대로 이해하려면 어떤 검색기를 썼는지만 볼 것이 아니라, 검색 결과가 생성 단계에 어떻게 들어가고 답 품질에 어떤 영향을 주는지까지 함께 봐야 합니다.
