Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
RAG(Retrieval + Augmentation + Generation)는 LLM의 환각 현상과 지식 구식 문제를 해결하는 핵심 아키텍처입니다. RAG는 모델 자체를 변경하지 않고, 외부 검색된 정보를 프롬프트에 추가하여 답변 품질을 향상시킵니다. 실제 프로덕션급 시스템은 데이터 수집(Ingestion) 및 검색(Retrieval)의 두 가지 주요 파이프라인으로 구성됩니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이전 기사(previous article)에서 우리는 Large Language Models(LLMs)가 왜 환각 현상(hallucinate)을 일으키는지, 그리고 RAG가 왜 필요한지에 대해 탐구했습니다.
우리는 LLM이 모든 것을 마법처럼 알지 못한다는 것을 배웠습니다. 그 지식은 학습하는 과정에 한정되어 있으며, 이 지식은 결국 구식이 됩니다. RAG는 질문에 답변할 때 관련 외부 정보를 제공함으로써 이 문제를 해결하는 데 도움을 줍니다.
하지만 이것은 또 다른 질문을 제기합니다. RAG 시스템 내부에서는 실제로 무슨 일이 일어날까요?
사람들이 RAG에 대해 이야기할 때, chunking, embeddings, vector databases, hybrid search, reranking, 그리고 evaluations와 같은 용어들이 자주 함께 등장합니다. 여정을 시작하는 사람에게는 압도적으로 느껴질 수 있습니다.
따라서 각 주제를 깊이 파고들기 전에, 먼저 큰 그림을 이해해 봅시다.
RAG는 Retrieval + Augmentation + Generation의 약자입니다.
각 단어는 프로세스의 한 단계를 나타냅니다.
Retrieval (검색) — 사용자의 질문과 관련된 정보를 찾습니다.
Augmentation (증강) — 검색된 정보를 모델에 전송되는 프롬프트나 컨텍스트에 추가합니다.
Generation (생성) — 모델은 그 컨텍스트를 사용하여 응답을 생성합니다.
매우 높은 수준에서 흐름은 다음과 같습니다:
RAG의 핵심 아이디어
자주 오해되는 중요한 점이 하나 있습니다. RAG는 모델에 새로운 지식을 가르치지 않습니다. 모델 자체는 변경되지 않습니다. 대신, RAG는 생성 과정에서 사용 가능한 정보를 바꿉니다.
동료에게 질문하는 것을 생각해 보세요. 만약 그들이 필요한 정보를 가지고 있지 않다면, 추측할 수 있습니다. 하지만 답변하기 전에 관련 문서를 제공한다면, 답변의 품질은 극적으로 향상됩니다.
그들의 지능은 변하지 않았습니다. 그들에게 제공되는 정보가 바뀐 것입니다.
RAG 역시 같은 원리를 따릅니다.
처음에는 이전 다이어그램이 RAG를 놀라울 정도로 간단하게 보이게 했습니다. 정보를 검색합니다. 프롬프트에 첨부합니다. 답변을 생성합니다. 끝입니다.
하지만 프로덕션급(production-grade) RAG 시스템을 탐색하기 시작하면서, 저는 백그라운드에서 훨씬 더 많은 일이 일어나고 있다는 것을 깨달았습니다. 대부분의 실제 시스템은 두 가지 주요 파이프라인으로 구성됩니다:
두 가지를 살펴보겠습니다.
사용자가 질문을 하기 전에, 시스템은 지식 기반을 준비해야 합니다.
단순화된 데이터 수집 파이프라인은 다음과 같습니다:
문서(Documents) -> 청킹(Chunking) -> 임베딩(Embeddings) -> 검색 가능한 저장소(Searchable Storage)
이것들은 PDF, 지원 문서(support articles), 제품 카탈로그, 내부 문서, 지식 기반 기사, 릴리스 노트 또는 기타 모든 정보 출처일 수 있습니다.
대용량 문서는 관련 정보를 효율적으로 검색할 수 있도록 더 작은 조각들로 분할됩니다.
각 청크는 의미를 기반으로 나중에 검색될 수 있는, 기계가 이해할 수 있는 표현(representation)으로 변환됩니다.
처리된 청크들은 검색에 최적화된 시스템에 저장됩니다.
이 시점에서 지식은 사용 준비가 완료되었습니다.
이제 사용자가 질문을 하는 상황을 상상해 보세요. 검색 파이프라인이 작동합니다.
사용자 질문(User Question) -> 관련 컨텍스트 검색(Retrieve Relevant Context) -> 프롬프트 구성(Prompt Construction) -> LLM -> 응답(Response)
하지만 프로덕션 시스템에서는, 이러한 단계들 사이에 여러 추가 단계가 종종 존재합니다. 질문이 변환될 수 있습니다. 결과가 필터링될 수 있습니다. 검색된 콘텐츠가 재순위화(reranked)될 수 있습니다. 인용문(Citations)이 첨부될 수 있습니다. 응답은 품질과 충실도 측면에서 평가될 수 있습니다.
더 현실적인 모습은 다음과 같습니다.
HLD OF Retrieval Augmented Generation(RAG)
이 시점에서, 저는 마침내 RAG를 이해했다고 느꼈습니다. 하지만 아키텍처의 모든 상자가 새로운 질문들을 제기하기 시작했습니다.
더 깊이 파고들수록, RAG가 단순히 **“검색 + AI”**가 아님을 깨달았습니다. 각 구성 요소는 특정 문제를 해결하기 때문에 존재하는 것입니다.
이러한 아키텍처들을 공부하는 동안, 한 가지 질문이 계속해서 저에게 돌아왔습니다. 만약 목표가 모델에 컨텍스트(context)를 제공하는 것이라면, 왜 단순히 사용 가능한 모든 문서를 주지 않을까요? 왜 작은 하위 집합만 검색할까요? 모델이 스스로 모든 것을 읽고 관련성 있는 정보를 파악하도록 내버려 두면 안 될까요? 그것은 합리적인 아이디어처럼 들립니다. 실제로 저도 처음에는 그렇게 생각했습니다.
나중에 알게 된 바로는, 이러한 접근 방식은 컨텍스트 창(context-window)의 한계, 비용, 지연 시간(latency), 그리고 관련성 문제 때문에 놀라울 정도로 빨리 무너집니다. 그리고 그러한 한계를 이해하는 것이 제가 이 시리즈에서 다음 주제로 나아가게 된 정확한 계기였습니다.
왜 검색만 하는 대신 LLM에게 사용 가능한 모든 컨텍스트를 줄 수 없을까요?
다음 기사에서 탐구할 내용입니다.
