Ch.12

RAG: 검색으로 환각 줄이기

RAG 한눈에

Closed-book은 암기 시험, RAG는 교과서 찾아보고 답하는 오픈북 과 비슷합니다.

같은 질문'환불 정책이 뭐야?' 에 Closed-book LLM 은 학습 기억 만으로 답하고, RAG 는 문서 저장소 에서 임베딩\cdot유사도\cdotTop-k 로 근거 청크 를 찾아 프롬프트에 넣은 뒤 생성합니다.

Closed-book: 기억만 · RAG: 검색 후 생성

Closed-book

외부 검색 없음

RAG

Top-k 선택

유사도 상위 k개 청크

Closed-book — 검색 없이 생성 · RAG — 검색·증강·생성

Closed-book외부 문서 없이 LLM 파라미터 기억만으로 답하면 환각·구식 정보 위험이 큽니다.

RAG저장소 → 임베딩 → Top-k 검색 → 프롬프트 증강 → 생성 순으로 근거를 붙입니다.

한 질문이 어떻게 처리되나

사용자 질문 이 들어옵니다. 목표는 최신\cdot사내 문서에 근거한 답 입니다. 질문\cdot문서 청크를 임베딩 해 같은 벡터 공간에서 유사도 를 잴 수 있게 합니다. Closed-book 은 검색 없이 생성합니다. RAG 는 Top-k 로 관련 청크 를 고릅니다. 고른 청크를 프롬프트 템플릿 에 넣고 Augment 합니다. 컨텍스트 예산 을 넘지 않게 조절합니다. LLM이 Generate 합니다. 출처\cdot유사도\cdotk 를 로그로 남기며 환각 을 모니터링합니다.

회사에서 사내 규정 챗봇 을 쓴다고 가정해 보세요. 직원이 「 올해 연차는 며칠까지 쌓이나요? 」라고 물었는데, 모델이 작년에 흔히 보던 일반적인 답 을 그럴듯하게 말해 버리면 곧바로 신뢰가 무너집니다. 문장은 매끄러운데 근거가 없거나 낡았을 때 우리는 환각(Hallucination) 이라고 부릅니다. 쉽게 말하면, AI가 출처 없이 그럴듯하게 말하는 상황입니다. RAG(검색 증강 생성) 는 이런 문제를 오픈북 방식으로 풉니다. 답하기 전에 회사 문서에서 관련 페이지를 찾아 질문지에 붙인 뒤 쓰게 하는 것입니다. LLM만 쓰는 Closed-book(클로즈드북) 은 학습 때 본 기억만 으로 답하는 암기 시험 에 가깝고, 학습이 끝난 뒤 새로 생긴 PDF\cdot뉴스\cdot사내 DB 를 항상 정확히 알기 어렵습니다. RAG는 검색(Retrieve) \to 빈칸 채우기(Augment) \to 답 쓰기(Generate) 순으로 동작합니다. 실무에서 자주 만나는 말만 짚으면, 긴 문서는 청크(한 장) 로 자르고 임베딩 으로 뜻을 숫자 좌표 에 옮깁니다. 벡터 DB 는 비슷한 글을 빨리 찾는 색인 이고, Top-k 는 관련도 위에서 k개만 고르는 것입니다. cos(코사인) 은 두 글이 방향이 비슷한지 보는 점수이고, ctx 는 모델이 한 번에 읽을 수 있는 최대 길이입니다. 프롬프트 는 지시문+질문 전체, 토큰 은 대략 단어\cdot음절 크기의 글자 묶음입니다. budget = ctx-prompt-query 는 시험지에서 문제 설명을 뺀 뒤 남은 칸 이라고 기억하면 됩니다. 이 장은 위 개념을 비유와 숫자 예시 로 이어서 읽습니다.

수식, 이렇게 읽으면 됩니다 (RAG)

\text{cos}(\mathbf{q},\mathbf{c})=\dfrac{\mathbf{q}\cdot\mathbf{c}}{\|\mathbf{q}\|\|\mathbf{c}\|}

RAG: 검색으로 근거 있는 답 만들기

k

왜 중요한지

어떻게 쓰이는지

k

요약

k

문제 풀이를 위한 설명

k

RAG: 검색으로 근거 있는 답 만들기

1. 오픈북 vs 클로즈드북: RAG의 탄생

LLM만 쓰는 방식을 Closed-book(클로즈드북) 이라고 부릅니다. 교과서를 들고 오지 못하는 암기 시험과 같아서, 모델은 학습 때 본 기억만으로 답합니다. 반면 RAG(검색 증강 생성) 는 오픈북 시험에 가깝습니다. 답하기 전에 도서관(문서 저장소) 에서 관련 페이지 한 장(청크) 을 찾아 질문지에 붙입니다.

실제 흐름은 검색(Retrieve) → 빈칸 채우기(Augment) → 답 쓰기(Generate) 입니다. 먼저 질문에 맞는 청크를 고르고, 그다음 프롬프트의 `{context}` 자리에 붙인 뒤, 마지막에 LLM이 문장을 만듭니다.

직원이 「올해 연차 규정이 어떻게 바뀌었어?」라고 물었다고 해 보세요. Closed-book은 작년에 흔하던 상식으로 그럴듯하게 말할 수 있고, RAG는 올해 인사 규정 PDF 7페이지를 찾아 그 문장을 근거로 답합니다. 차이는 「말이 예쁜가」가 아니라 「어느 페이지를 봤는가」 입니다.

2. 임베딩(Embedding): 글자를 컴퓨터의 좌표로

컴퓨터는 「환불」「반품」 같은 뜻을 그대로 비교하기 어렵습니다. 그래서 임베딩으로 문장을 숫자 목록(벡터) 에 옮깁니다. 비슷한 주제는 좌표 공간에서 가깝게, 다른 주제는 멀게 놓이도록 학습합니다. 마치 지도에서 「카페」들이 한곳에 모이는 것과 비슷합니다.

검색할 때는 코사인 유사도(cos) 를 씁니다. 두 문장 벡터가 같은 방향을 가리키는지(각도) 를 보는 점수로, 직선 거리보다 「주제가 겹치는가」에 가깝습니다. 「환불」과 「반품·결제 취소」는 cos가 높게 나오고, 「점심 메뉴」는 낮게 나옵니다. RAG는 이 점수로 질문과 가장 관련 있는 청크부터 골라 냅니다.

3. 청킹(Chunking)과 Top- $k$ 검색

회사 규정 PDF가 500페이지라도, 모델 프롬프트에 통째로 넣을 수는 없습니다. 청킹은 긴 문서를 한 입 크기(예: 200토큰) 로 잘라 조각(청크) 으로 보관하는 일입니다. 잘게 자를수록 찾을 단위는 많아지지만, 한 장이 너무 짧으면 문맥이 끊길 수 있습니다.

질문이 오면 임베딩·cos로 비슷한 청크를 순위 매기고, Top- $k$ 로 상위 k장만 LLM에 넘깁니다. k=3이면 가장 관련 있는 3장만 붙입니다. 수만 장의 청크를 빠르게 찾기 위해 벡터 DB를 씁니다. 도서관 카드 색인처럼, 전체 PDF를 매번 읽지 않고 비슷한 조각만 꺼냅니다.

k를 너무 크게 잡으면 엉뚱한 문단이 섞이고 비용도 늘어납니다. 그래서 「많이 넣을수록 좋다」가 아니라 적당한 k가 중요합니다.

4. 컨텍스트 예산과 프롬프트 템플릿

모델은 한 번에 읽을 수 있는 길이에 한도(ctx, 컨텍스트 한도) 가 있습니다. A4 시험지 한 장이라고 생각하면 됩니다. 먼저 지시문(prompt) 과 사용자 질문(query) 이 자리를 쓰고, 남은 칸에만 검색한 청크를 붙입니다. 이 남은 분량이 청크 예산이며, budget = ctx−prompt−query 로 계산합니다.

붙일 때는 프롬프트 템플릿이라는 고정 양식을 씁니다. `{context}` 자리에 검색 결과를, `{question}` 자리에 사용자 질문을 넣습니다. 「아래 문서만 보고 답하라」는 문장도 함께 넣어, 모델이 빈칸 밖을 추측하지 않게 합니다.

숫자로 보면, ctx=4096, 지시문=512, 질문=200이면 예산은 3384입니다. 청크 한 장이 200 토큰이면 대략 3384 // 200 ≈ 16장까지 들어갑니다. 뺄셈(예산) 과 // (최대 장 수) 는 같은 이야기의 앞뒤 단계입니다.