Lab 03: RAG 이론

• RAG가 모델 성능을 높이는 여러 방법(파인튜닝·지속 사전학습 등) 중 어디에 위치하는지 설명할 수 있습니다
• 임베딩이 텍스트를 “의미를 담은 숫자 벡터”로 바꾸는 과정임을 설명할 수 있습니다
• 벡터 검색이 코사인 유사도로 “질문과 가까운 청크”를 찾는 원리를 이해합니다
• 문서를 왜 잘라야 하는지(청킹)와 고정 크기 vs 의미 단위의 차이를 구분합니다
• 메타데이터(출처/날짜)가 검색 품질에 어떻게 기여하는지 압니다
• RAG가 어디서 무너지는지(garbage in) 한계를 말로 설명할 수 있습니다

내부 부품을 뜯어보기 전에, 한 걸음 물러나 큰 지도를 봅시다. “모델이 내 일을 더 잘하게 만드는” 길은 RAG 하나가 아닙니다. 여러 갈래가 있고 RAG는 그중 하나입니다. 이 지도를 알면 “왜 파인튜닝이 아니라 RAG인가?”에 스스로 답할 수 있습니다.

크게 세 갈래입니다.

FM(Foundation Model)은 Bedrock이 제공하는 기반 모델(Claude, Titan 등)을 가리킵니다.

RAG는 세 번째, ‘FM 활용’에 속합니다. 모델을 전혀 건드리지 않습니다. 이 성격이 RAG의 장단점을 결정합니다 — 빠르고, 상대적으로 싸고, 문서만 갈아끼우면 지식이 갱신됩니다.

1. FM 커스터마이징 — 모델을 직접 고친다

가중치를 조정하거나 새 데이터를 학습시켜 새로운 모델을 만들어 냅니다. 가장 근본적이지만 가장 비싼 길입니다.

2. FM 정렬(Alignment) — 행동을 사람에게 맞춘다

성능을 높이는 게 아니라, 모델이 어떻게 답하는지(톤·가치·윤리)를 사람 기준에 맞춥니다.

3. FM 활용 — 모델은 그대로, 쓰는 법만 바꾼다

모델을 학습시키지도 튜닝하지도 않습니다. 입력을 잘 주거나 외부 정보를 붙여 더 나은 답을 끌어냅니다. 구현 비용이 가장 낮습니다.

그래서, 왜 RAG인가

“내 문서로 답하게 만들고 싶다”는 목표만 보면 두 길이 떠오릅니다 — 파인튜닝으로 문서를 모델에 새겨 넣거나, RAG로 그때그때 검색해 오거나. 둘의 성격은 정반대입니다.

RAG가 “어제 추가된 문서”, “출처가 분명한 답”에 강한 이유가 여기 있습니다. 모델을 건드리지 않고 외부 지식을 실시간으로 빌려오기 때문입니다. 이제 그 RAG의 내부 — 검색이 어떻게 “비슷한 문서”를 찾아오는지 — 를 아래 토글들에서 하나씩 분해합니다.

오전에 콘솔에서 한 일을 다시 떠올려 봅시다. 우리는 클릭 몇 번으로 다음을 했습니다.

1. S3에 문서를 올렸다
2. Knowledge Base를 만들면서 청킹 방식(Fixed-size), 임베딩 모델(Titan Embeddings V2), 벡터 저장소(S3 Vectors)를 골랐다
3. Sync를 눌렀다 — 이 순간 문서가 잘리고, 임베딩되어, 벡터로 저장됐다
4. Test에서 질문을 던졌다 — 질문과 비슷한 조각을 찾아(retrieve), 그걸 근거로 모델이 답을 썼다(generate)

콘솔은 이 모든 단계를 대신 해준 GUI였습니다. 화면 뒤에서 실제로 돌아간 부품은 네 개입니다.

graph TD
  subgraph 색인["① 데이터 준비 — 오프라인 (Sync)"]
      A["내 문서 (PDF/텍스트)"] --> B["청킹: 조각으로 자르기"]
      B --> C["임베딩: 각 조각 → 벡터"]
      C --> D["벡터 저장소에 저장"]
  end
  subgraph 질의["② 검색과 생성 — 실시간 (Test)"]
      Q["사용자 질문"] --> E["임베딩: 질문 → 벡터"]
      E --> F["벡터 검색: 가까운 청크 top-k"]
      F --> G["프롬프트 조립: 질문 + 검색된 청크"]
      G --> H["모델이 답 생성 + 출처"]
  end
  D -.저장된 벡터.-> F

이 그림이 RAG의 핵심 골격입니다. 위아래 두 묶음은 성격이 전혀 다른 두 단계입니다 — 하나는 미리, 하나는 그때그때 돕니다.

① 데이터 준비 — 오프라인(배치)

문서를 검색 가능한 형태로 미리 가공해 두는 단계입니다. 계산이 무겁기 때문에 질문과 상관없이 한 번 돌려 둡니다.

• 청킹(Chunking) — 원본 문서를 의미 있는 작은 단위(chunk)로 자릅니다. 검색 때 질문과 관련성 높은 부분(contextual relevancy)을 정확히 집어내기 위한 사전 작업입니다.
• 임베딩 & 인덱싱 — 각 청크를 벡터로 변환(임베딩)하고, 검색 가능한 벡터 인덱스에 저장합니다. 새 문서가 추가될 때마다 주기적으로 다시 돌려야 검색에 반영됩니다.

콘솔에서 누른 Sync가 바로 이 데이터 준비 전체였습니다.

② 검색 및 생성 — 실시간

사용자 질문이 들어올 때마다 매번 도는 단계입니다.

• 질문을 임베딩으로 변환합니다(색인 때와 같은 모델이어야 합니다).
• 인덱스에서 관련성 높은 청크를 **검색(Retrieval)**합니다.
• 검색된 청크와 질문을 함께 LLM에 넣어 최종 **답변을 생성(Generation)**합니다.

콘솔의 Test가 바로 이 검색·생성이었습니다.

“한 번 미리(색인) vs 그때그때(질의)” — 이 구분이 RAG 운영의 핵심입니다. “어제 올린 문서를 왜 못 찾지?”의 답은 대개 “아직 Sync(재색인)를 안 했다”입니다.

핵심 한 문장: “RAG = 질문과 비슷한 내 문서 조각을 찾아서(retrieve), 그걸 근거로 모델이 답을 쓰게(generate) 하는 것.” 아래 토글에서 이 네 부품을 하나씩 분해합니다.

임베딩이란

임베딩(embedding)은 텍스트를 의미를 담은 숫자 벡터로 바꾸는 변환입니다. 벡터는 그냥 숫자들의 나열입니다. 예를 들어 콘솔에서 고른 Titan Embeddings V2는 어떤 텍스트를 넣든 1024개의 숫자로 바꿔 내놓습니다. 짧은 단어 “사과”도, 긴 문단도, 결과는 똑같이 1024차원 벡터입니다.

여기서 중요한 건 숫자 자체가 아니라 숫자가 배치된 위치입니다. 임베딩 모델은 방대한 텍스트로 학습되면서 “비슷한 뜻을 가진 텍스트는 비슷한 위치(가까운 벡터)에 놓이도록” 만들어졌습니다.

”비슷한 뜻 = 가까운 벡터”

이 한 줄이 RAG 전체를 떠받칩니다.

• “졸업 요건이 뭐야?”와 “졸업하려면 무엇이 필요한가요?”는 글자는 다르지만 뜻이 비슷합니다 → 벡터 공간에서 가깝습니다.
• “졸업 요건”과 “학교 식당 메뉴”는 뜻이 멀기 때문에 → 벡터 공간에서 멉니다.

즉 임베딩은 “단어가 똑같은지”가 아니라 “의미가 통하는지”를 숫자로 표현합니다. 키워드 검색은 “졸업”이라는 글자가 들어 있는 문서만 찾지만, 임베딩 기반 검색은 “졸업”이라는 단어가 한 번도 안 나와도 졸업에 관한 내용이면 찾아낼 수 있습니다. 이것이 전통적인 키워드 검색과 결정적으로 다른 점입니다.

차원(dimension)이라는 개념

“1024차원”이라는 말이 낯설 수 있습니다. 2차원이면 종이 위의 점(x, y), 3차원이면 공간 속의 점(x, y, z)입니다. 1024차원은 그저 좌표 축이 1024개라는 뜻입니다. 사람은 1024차원을 그림으로 그릴 수 없지만, 컴퓨터는 그 안에서 두 점 사이의 거리를 계산하는 데 아무 문제가 없습니다. 차원이 많을수록 미묘한 의미 차이를 더 풍부하게 담을 수 있습니다.

주의: 임베딩 모델이 다르면 차원도 의미 공간도 다릅니다. 색인을 만들 때 쓴 모델과 검색할 때 쓴 모델은 반드시 같아야 합니다. Titan V2로 저장한 벡터를 다른 모델의 질문 벡터와 비교하면 결과가 엉망이 됩니다.

검색은 “거리 계산”이다

문서 조각들을 모두 벡터로 만들어 저장해 두었다고 합시다. 사용자가 질문하면, 질문도 똑같은 임베딩 모델로 벡터로 바꿉니다. 이제 할 일은 단순합니다. 질문 벡터와 가장 가까운 문서 벡터들을 찾는 것. 검색이 곧 거리 계산입니다.

graph LR
  Q["질문 벡터"] --> S["저장된 청크 벡터들과<br/>유사도 계산"]
  S --> R["가장 가까운<br/>top-k개 청크 반환"]

코사인 유사도

두 벡터가 “얼마나 가까운가”를 재는 대표적인 방법이 코사인 유사도(cosine similarity)입니다. 두 벡터가 가리키는 방향이 얼마나 비슷한지를 측정합니다.

• 방향이 같으면(완전히 같은 의미) → 유사도 1에 가까움
• 방향이 직각(서로 무관) → 유사도 0에 가까움
• 방향이 반대 → 유사도 음수

길이가 아니라 방향을 본다는 점이 중요합니다. 그래서 짧은 질문과 긴 문단을 비교해도 “의미의 방향”이 통하면 높은 점수가 나옵니다. 콘솔의 Test 화면에서 검색 결과마다 붙어 있던 점수(score)가 바로 이 유사도 값입니다.

top-k: 몇 개를 가져올까

검색은 가장 가까운 청크를 k개 골라 옵니다. 이 k가 top-k입니다.

• k가 너무 작으면(예: 1) — 정답이 들어 있는 청크를 놓칠 위험이 커집니다. 검색이 살짝만 빗나가도 답이 통째로 틀어집니다.
• k가 너무 크면 — 관련 없는 청크까지 프롬프트에 섞여 들어가 모델이 혼란스러워지고, 토큰 비용도 늘어납니다.

보통 3~5개에서 시작해 결과를 보며 조정합니다. “검색 결과를 몇 개나 모델에게 보여줄 것인가”는 RAG 품질을 좌우하는 핵심 손잡이 중 하나입니다.

코사인 유사도와 top-k가 아직 추상적이라면, 우리가 매일 쓰는 기능을 떠올리면 됩니다. 온라인 쇼핑몰의 비슷한 상품 추천이 바로 벡터 검색입니다. 청바지 하나를 보고 있으면 “같은 핏의 다른 워싱”, “비슷한 스타일의 다른 브랜드”를 띄워 주는 그것입니다.

전통적인 키워드 검색은 상품명에 똑같은 단어가 들어가야 찾습니다. 벡터 검색은 의미가 비슷하면 찾아냅니다 — 단어가 달라도 “느낌이 통하는” 청바지를 골라냅니다. RAG가 “졸업 요건”과 “졸업하려면 뭐가 필요해?”를 같은 뜻으로 잇는 것과 똑같은 원리입니다.

이런 시스템은 네 단계로 만들어집니다. 오른쪽 칸은 우리 RAG에서 대응되는 부분입니다.

핵심은 1~3단계가 앞에서 본 RAG 파이프라인과 글자 그대로 같다는 것입니다. 쇼핑몰은 “비슷한 상품”, RAG는 “비슷한 청크”를 찾을 뿐, 원리는 하나입니다 — 의미를 벡터로 바꿔 거리를 잰다. 그래서 벡터 검색은 전자상거래 추천, 넷플릭스 콘텐츠 추천, 의료 영상 비교처럼 분야를 가리지 않고 같은 방식으로 쓰입니다.

왜 자르는가

문서를 통째로 임베딩하지 않고 조각(chunk)으로 잘라 저장합니다. 이유는 두 가지입니다.

1. 검색 정확도 — 100페이지 문서를 하나의 벡터로 만들면, 그 벡터는 문서 전체의 “평균적 의미”가 되어 버립니다. 특정 질문에 딱 맞는 한 문단을 콕 집어낼 수 없습니다. 반대로 적당한 크기로 잘라 두면, 질문과 가장 관련 있는 그 한 조각만 골라낼 수 있습니다.
2. 토큰 비용과 한계 — 검색된 내용을 프롬프트에 넣어 모델에 보냅니다. 청크가 너무 크면 프롬프트가 길어져 비용이 오르고, 관련 없는 내용까지 섞입니다. 모델의 입력 길이에도 한계가 있습니다.

콘솔에서 KB를 만들 때 Fixed-size 청킹을 골랐던 것을 기억하나요? 그게 바로 “문서를 어떻게 자를지”를 결정한 선택이었습니다.

고정 크기 vs 의미 단위

콘솔이 기본으로 권하는 Fixed-size는 가장 단순하고 안정적인 출발점입니다. 다만 문단 한가운데가 잘려 “답의 절반은 이 청크, 절반은 저 청크”가 되는 일이 생길 수 있습니다.

오버랩(overlap)

이런 “경계에서 잘림” 문제를 줄이려고 오버랩을 줍니다. 인접한 청크가 일부 내용을 겹쳐 공유하게 하는 것입니다. 예를 들어 청크 크기 500, 오버랩 50이면, 다음 청크가 이전 청크의 마지막 50토큰을 다시 포함합니다. 경계에 걸친 정보가 양쪽 청크 어딘가에는 온전히 들어 있도록 보장하는 안전장치입니다.

청크 크기와 오버랩은 정답이 없습니다. 너무 작으면 문맥이 끊겨 답을 못 담고, 너무 크면 한 청크에 여러 주제가 섞여 검색이 둔해집니다. 다음 Lab들에서 직접 값을 바꿔 보며 “어디서 무너지나”를 관찰하게 됩니다.

벡터만 저장하는 게 아닙니다. 각 청크에는 메타데이터(metadata)가 함께 붙습니다. 메타데이터는 청크에 대한 부가 정보입니다.

• 출처(source) — 어느 문서, 몇 페이지에서 나온 조각인가
• 날짜(date) — 언제 만들어진 문서인가
• 그 밖에 부서, 문서 종류, 작성자 등

메타데이터는 두 가지로 쓰입니다.

1. 출처 표시(citation) — 콘솔 Test에서 답변마다 “이 답은 이 문서의 이 부분을 근거로 했다”는 출처를 클릭해 확인했습니다. 그게 가능했던 건 청크마다 출처 메타데이터가 붙어 있었기 때문입니다. RAG가 “근거 있는 답”을 줄 수 있는 이유가 여기 있습니다.
2. 필터링 — “2024년 이후 문서에서만 찾아줘”, “인사팀 문서만” 같은 조건으로 검색 범위를 좁힐 수 있습니다. 의미 유사도만으로는 구분하기 어려운, 최신성이나 권한·범위 같은 조건을 메타데이터로 거릅니다.

예를 들어 “올해 휴가 규정”을 물었는데 작년 규정 문서가 의미상 더 비슷하게 잡힌다면, 날짜 메타데이터로 “최신 문서 우선”을 걸어 오답을 막을 수 있습니다. 의미 검색만으로 부족한 빈틈을 메타데이터가 메웁니다.

RAG는 강력하지만 마법이 아닙니다. 검색이 절반이고, 검색이 흔들리면 답도 같이 흔들립니다. 한계를 정확히 아는 것이 RAG를 잘 쓰는 출발점입니다.

1. 청크가 답을 안 담으면 못 찾는다

검색은 “저장된 청크 중에서” 가장 비슷한 걸 고를 뿐입니다. 애초에 답이 어느 청크에도 들어 있지 않으면, 검색은 아무리 잘해도 정답을 가져올 수 없습니다. 청크를 너무 잘게 잘라 답이 두 조각으로 쪼개졌거나, 문서 자체에 그 정보가 없으면 RAG는 답하지 못합니다(또는 엉뚱한 청크로 그럴듯하게 지어낼 위험).

2. 검색이 틀리면 답도 틀린다 (garbage in, garbage out)

모델은 검색해 준 청크를 근거로 답을 씁니다. 검색이 엉뚱한 청크를 가져오면, 모델은 그 엉뚱한 내용을 충실히 요약해 자신 있게 틀린 답을 내놓습니다. 들어간 게 쓰레기면 나오는 것도 쓰레기다 — garbage in, garbage out. 모델의 답이 그럴듯해 보여도, 그 뿌리인 검색이 부실하면 답 전체를 믿을 수 없습니다.

3. 표현이 조금만 달라도 검색이 빗나갈 수 있다

임베딩이 의미를 잡아주긴 하지만 완벽하지 않습니다. 질문을 살짝 다르게 표현하면 다른 청크가 잡히기도 합니다. 그래서 같은 질문도 표현을 바꿔 가며 테스트해 “검색이 안정적인가”를 확인해야 합니다.

그래서 무엇을 점검하나

핵심 교훈: “RAG는 검색이 절반이다.” 답이 이상하면 모델을 탓하기 전에 검색이 무엇을 가져왔는지 먼저 보세요. 다음 Lab들에서 이 손잡이들을 직접 돌려 보며 “어디서 무너지나”를 손으로 확인하게 됩니다.

• 코사인 유사도 대신 유클리드 거리를 쓰면 검색 결과가 달라질까요? 임베딩이 정규화돼 있다면?
• 정답이 어느 청크에도 안 담겨 있으면 검색은 어떻게 실패할까요? (‘garbage in’)