RAG 구축하기 - 2. Retrieval과 Generation

지난 글에서는 RAG를 구축할 때 가장 중요한 데이터 파이프라인에 대해서 다뤘다.

즉, 문서를 불러오고(Load), 파싱하고 (Parsing), 청크로 나누고 (Chunking), 문맥을 붙이고(Contextualize), 임베딩하고 (Embedding), 벡터DB에 저장(Upsert)하는 과정을 살펴보았다.

 

2025.08.19 - [인공지능/자연어처리] - RAG 구축하기 - 1. Data Pipeline 구축

RAG 구축하기 - 1. Data Pipeline 구축

 

 

이번 글에서는 그 다음 단계인 Retrieval(검색)과 Generation(생성) 부분을 살펴보겠다. 실제로 사용자가 질문을 던졌을 때, 이 준비된 데이터들이 어떻게 활용되어 답변을 생성하는지의 과정이다.

 

---

 

1. Retrieval (검색 단계)

사용자가 질문을 던지면, 가장 먼저 하는 일은 질문을 벡터화 하여 검색하는 것이다.
데이터 파이프라인에서 모든 문서를 임베딩해 DB에 저장해둔 것처럼, 사용자의 질문 역시 같은 임베딩 모델을 통과시켜 숫자 벡터 형태로 만들어야한다.

 

그 다음 DB안의 문서 벡터와 질문을 임베딩한 벡터를 비교해,  가장 유사한 청크들을 가져온다.

이 과정이 바로 Retrieval(검색)이다.

 

여기서 중요한 포인트 몇 가지를 짚자.

• Dense Search (임베딩 기반 검색)
  질문과 문서의 의미적 유사도를 계산해 검색하는 방식. Synonym이나 문장 뉘앙스를 잘 잡아낼 수 있음.
  예:“자동차 연비 개선” 질문에 대해 “연료 효율 최적화”라는 문서도 찾아낼 수 있음.
• Sparse Search (키워드 기반 검색)
  BM25 같은 전통 IR 기법으로 키워드 매칭을 수행. 도메인 용어 검색에 강함.
  예: “제34조” 같은 법령 검색.
• Hybrid Search (혼합 검색)
  두 방식을 결합해 서로의 단점을 보완. RAG에서 가장 자주 쓰이는 전략.

검색 단계에서 중요한 포인트는 Top-K를 어떻게 설정하느냐이다. 너무 많이 가져오면 LLM 입력 길이를 초과하고, 너무 적게 가져오면 필요한 맥락이 빠질 수 있다.

---

2. Rerank 

Retrieval을 통해 문서 10개를 가져왔다고 해보자.
그런데 이 중에는 애매하게 걸린 문서도 섞여 있을 수 있다.

 

이때 활용하는 게 Re-Ranker다.
Cross-Encoder 같은 모델을 사용해 질문과 문서 쌍을 하나씩 넣고, 진짜 관련성이 얼마나 높은지 점수화한다.
그 결과, 애매한 문서는 뒤로 밀리고 핵심 문서만 상위에 오게 된다.

 

예를 들어,

• Query: “자율주행 보트의 충돌 회피 방법”
• Candidate 문서: “보트 충돌 사고 통계” vs “자율주행 경로 계획 알고리즘”

이 경우 단순 벡터 유사도는 두 문서를 비슷하게 볼 수 있지만, Re-Ranker는 질문에 직접 답할 가능성이 높은 후자를 더 높게 평가한다.

---

3. Generation (답변 생성 단계)

이제 정제된 문맥들을 가지고 LLM에게 답변을 요청한다.
중요한 점은 LLM이 혼자 상상해서 답하지 않도록, 검색된 문맥을 반드시 프롬프트에 넣는 것이다. 검색된 문맥을 LLM에게 넣고, 사용자의 질문과 함께 답변을 생성하는 단계이다.

 

간단한 프롬프트 구조는 아래와 같다.

[사용자 질문] 
자율주행 보트의 충돌 회피 방법은 무엇인가요?

[검색 문맥] 
1) 연구 보고서: "자율주행 보트는 LiDAR 기반 경로 계획을 활용해 장애물을 탐지하고 회피한다."
2) 논문: "충돌 위험 상황에서는 Rule-based 제어를 우선 적용하고, 이후 최적화 알고리즘으로 보정한다."

[지시] 
위 문맥을 참고해 답변을 작성하라.

 

• Context Injection:
  검색된 문서를 그대로 프롬프트에 붙여 넣음 → “이 문서를 참고해서 답변하라”는 지시를 함께 줌
• Chain-of-Thought 유도:
  “출처를 기반으로 단계별 reasoning을 하라”고 지시해 더 논리적인 답변을 유도
• Hallucination 최소화:
  모델이 근거 없는 답변을 하지 않도록, 반드시 문맥 기반으로 생성되도록 프롬프트 설계 필요
• Answer Formatting
  답변을 표, bullet, 문단 등 원하는 형식으로 맞출 수 있음

 

---

4. Post-Processing (후처리)

LLM이 답을 냈다고 해서 그대로 사용자에게 전달하는 건 위험하다. 생성된 답변을 그대로 쓰기보다는, 답변을 가공하는 post-process 를 통해 완성도를 높일 수 있다. 

• 출처 문서 표시 : Ref 번호 달기
• 형식 변환 : Markdown, JSON, HTML 등 시스템에 맞는 포맷으로 변환
• 응답 정제 :중복 제거, 중요한 키워드 강조 

---

Retrieval + Generation = RAG의 본질

정리하자면, RAG에서 Retrieval은 “무엇을 참고할 것인가”, Generation은 “그걸 어떻게 답변으로 풀어낼 것인가”의 과정이다.

이 두 단계가 합쳐져야만, 단순한 챗봇이 아니라 지식 기반의 신뢰도 높은 응답 시스템이 완성된다.

 

이전 내용까지 포함한 RAG 전체 흐름을 요약하면 

 

1. 데이터 파이프라인: 문서를 불러오고 → 파싱하고 → 청크 나누고 → 임베딩 후 DB에 저장
2. Retrieval: 질문을 벡터화해서 DB에서 관련 문서 검색
3. Rerank(선택): 결과 순위를 정밀하게 조정
4. Generation: 검색된 문맥을 기반으로 답변 생성
5. Post-Processing: 답변을 다듬고 출처를 달아 최종 출력

결국 RAG의 핵심은 단순히 "LLM이 답하는 것"이 아니라, 좋은 문서를 잘 찾아와서 올바른 맥락 속에서 답하도록 만드는 것이다.

 

데이터 파이프라인이 밭을 갈아놓는 과정이었다면, Retrieval과 Generation은 그 밭에서 수확해 요리를 내는 과정이라고 할 수 있다.
검색이 잘못되면 재료가 엉망이 되고, 생성이 부실하면 요리가 맛없어진다.
따라서 두 단계를 균형 있게 설계하는 것이 RAG 성공의 핵심이다.

---

다음글에서는 RAG 성능을 높이는 방법인 Chunk 전략, Hybrid Search 최적화 , Re-ranker 모델 활용, 프롬프트 엔지니어링 같은 실전 노하우에 대해서 더 자세히 다뤄볼까 한다.