RAG: 찾아서 읽고 답하기
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 지금 가장 널리 쓰이는 방법이다. 질문이 오면 관련 자료를 찾아(Retrieval), 질문에 덧붙여(Augmented), LLM이 그걸 읽고 답을 쓰게(Generation) 한다.
- RAG의 두 단계(색인 만들기 / 질문마다 검색·생성)를 순서대로 말할 수 있다.
- 검색 결과가 프롬프트에 어떤 모습으로 들어가는지 안다.
- RAG가 잘 맞는 상황과 약점을 말할 수 있다.
도서관 사서를 떠올리자
큰 도서관의 사서는 모든 책을 외우지 않는다. 대신 책을 미리 주제별로 분류하고 색인 카드를 만들어 둔다. 질문을 받으면 카드를 뒤져 관련 페이지 몇 장을 찾아 펼쳐 주고, 그 페이지를 읽으며 답한다. 여기서 색인 카드 만들기 = 색인(indexing), 카드 뒤지기 = 검색(retrieval), 펼친 페이지를 읽고 답하기 = 생성(generation)이다.
RAG의 전체 흐름
아래 흐름은 실제로 계산된다. 질문을 고르거나 직접 입력하고, 다음 단계 →를 눌러 보자. ⑦단계에서 검색 점수, ⑧단계에서 LLM에게 가는 프롬프트가 그대로 보인다.
직접 해 보기: 검색 결과와 프롬프트
흐름의 ⑦~⑩단계를 한 화면에 펼친 실험이다. 위에서 바꾼 질문·k·조각 크기가 그대로 쓰인다. 노란 표시는 질문과 겹친 글자 묶음이다.
검색 → 프롬프트 → 답
세 단계를 조금 더 자세히
① 색인: 미리 한 번
문서를 조각내고(chunking), 조각마다 임베딩 벡터를 만들어, 원문과 함께 벡터 저장소(vector DB)에 넣는다. 문서가 바뀌면 바뀐 조각만 다시 넣으면 된다. 이 ‘부분 갱신’이 쉬운 것이 RAG의 큰 장점이다.
② 검색: 질문마다
질문을 같은 임베딩 모델로 벡터로 바꾸고, 저장된 조각 중 코사인 유사도가 높은 k개를 가져온다. 수백만 개 조각에서도 빠르게 찾도록 근사 검색 기법을 쓰지만, 원리는 2장의 ‘방향 비교’ 그대로다.
③ 증강 + 생성: 질문마다
가져온 조각을 질문과 함께 하나의 프롬프트로 묶는다. 보통 다음 세 부분으로 이뤄진다.
LLM은 1장의 ‘다음 토큰 고르기’를 그대로 하지만, 이번에는 근거가 눈앞에 있으므로 정확한 숫자와 이름을 쓸 수 있다. 어느 자료를 썼는지 번호로 달게 하면 사람이 출처를 확인할 수도 있다.
RAG의 강점과 약점
강점
- 자료가 컨텍스트 창보다 훨씬 커도 된다
- 문서가 바뀌면 그 부분만 다시 색인
- 답의 출처를 보여줄 수 있다
- 질문마다 필요한 만큼만 넣어 비용이 적다
약점
- 검색이 놓치면 끝이다 — LLM은 받지 못한 자료를 모른다
- 조각 크기, k, 임베딩 모델 등 손볼 곳이 많다
- 여러 사실을 이어야 하는 질문에 약하다
- 검색 단계만큼 응답이 늦어진다
질문 칩에서 “오로라 프로젝트 담당자의 팀장은 어디서 일해?”를 고르고 k를 6까지 올려 보자. 그래도 ‘박서준은 B동 3층에서 일한다’는 들어오지 않는다. 이 문장은 질문과 겹치는 말이 하나도 없기 때문이다. 이 문제를 4장에서 진단하고, 5장(CAG)과 6장(KAG)에서 서로 다른 방식으로 푼다.
핵심 정리
- RAG = 검색(Retrieval) + 덧붙이기(Augmented) + 생성(Generation).
- 미리: 문서 → 조각 → 임베딩 → 벡터 저장소. 질문마다: 질문 임베딩 → 유사한 조각 k개 → 프롬프트 조립 → LLM.
- 프롬프트 = 지시문 + 검색된 자료 + 질문. “자료에 없으면 모른다고 하라”가 환각을 줄인다.
- 큰 자료, 자주 바뀌는 자료, 출처가 필요한 경우에 강하다.
- 검색이 필요한 조각을 놓치면 LLM도 답할 수 없다. 특히 여러 단계 질문에 약하다.