RAG란 무엇인가?

[eunji719]

📆 일자: 26년 7월 28일(화)

Q. RAG (Retrieval-Augmented Generation)에 대해서 자유롭게 서술해주세요.

1. RAG는 무엇이고, 왜 파인튜닝만으로는 부족한가?
2. RAG의 핵심 파이프라인 3단계는 무엇인가? (+각 단계에서 발생 가능한 문제)
3. RAG에서 벡터DB 검색 품질을 높이는 방법에는 뭐가 있나?

[vvineey]

RAG는 무엇이고 왜 파인튜닝만으로는 부족한가?

RAG ( Retrieval-Augmented Generation )

LLM이 답변을 생성하기 전에 외부 지식 저장소에서 관련 문서를 검색하고 그 검색 결과를 프롬프트 컨텍스트에 넣어 답변을 생성하게 하는 방식

왜 파인튜닝만으로는 부족할까?

LLM은 학습 시점에 일반 지식은 잘 다루지만 모든 최신 정보와 조직 내부 정보를 알고 있지는 않다.
모델 파라미터 안에 지식을 넣어두면 언제, 어떤 근거로 답했는지 추적하기 어렵다.

방식	잘하는 것	부족한 점
Prompting	빠른 지시, 형식 제어	긴 지식 저장에는 부적합
Fine-tuning	말투, 정책, 태스크 수행 패턴 학습	최신 사실 반영과 근거 추적이 어려움
RAG	외부 지식 검색, 최신성, 출처 제공	검색 품질과 컨텍스트 구성에 성능이 크게 좌우됨

-> 파인튜닝은 모델의 말투, 출력 형식, 특정 작업의 패턴이나 도메인 적응에는 유용 but, 자주 바뀌는 정보나 대량의 사내 지식 정보 등을 계속 반영하는데 부담이 크다. ( 데이터가 바뀔 때마다 학습 데이터를 준비하고 다시 학습하고 평가하고 배포해야하는 과정을 거쳐야 함)

RAG의 핵심 파이프라인 3단계는 무엇인가?

1. Indexing
2. Retrieval
3. Generation

1단계 Indexing : 문서를 수집하고 검색 가능한 형태로 저장하는 단계

1. 원문 문서를 수집한다.
2. HTML, md, PDF 등등의 형태의 데이터를 텍스트 형태로 정제한다.
3. 긴 문서를 chunk단위로 나눈다.
4. 각 chunk를 embedding model로 vector로 변환한다.
5. vector, 원문, 메타데이터, 출처 등등을 Vector DB나 검색 엔진에 저장한다.

이때 발생할 수 있는 문제

문제	설명
Chunking 실패	너무 작으면 맥락이 끊기고, 너무 크면 검색 정확도와 토큰 효율이 떨어짐
문서 정제 실패	메뉴, footer, 중복 문구, 깨진 텍스트가 검색 결과를 오염시킴
Metadata 부족	권한, 문서 버전, 작성일, 서비스명으로 필터링하기 어려움
인덱스 최신성 문제	문서가 바뀌었는데 vector index가 갱신되지 않아 오래된 답을 함
임베딩 모델 불일치	query와 document 임베딩 방식이 맞지 않으면 유사도 검색 품질이 떨어짐

2단계 Retrieval : 사용자 질문과 관련된 문서 조각을 찾는 단계

1. 사용자 질문을 정제하거나 재작성한다.
2. 질문을 embedding vector로 변환한다.
3. Vector DB에서 유사한 chunk를 top-k로 검색한다.
4. metadata filter나 keyword search를 함께 적용한다.
5. reranker로 후보 문서의 순서를 다시 매긴다.
6. 너무 중복되거나 관련 없는 chunk를 제거한다.

이때 발생할 수 있는 문제

문제	설명
Query ambiguity	질문이 짧거나 모호해서 엉뚱한 문서가 검색됨
Semantic mismatch	의미는 비슷하지만 실제 답과 관련 없는 문서가 높은 점수를 받음
Recall 부족	필요한 문서가 top-k 안에 들어오지 않음
Precision 부족	검색 결과는 많지만 잡음이 많아 생성 품질이 떨어짐
권한 필터 누락	사용자가 볼 수 없는 문서가 컨텍스트로 들어갈 수 있음

3단계 Generation : 검색된 문서를 프롬프트에 넣고 LLM이 답변을 생성하는 단계

1. 검색 결과를 정렬하고 필요한 부분만 추린다.
2. 시스템 프롬프트에 답변 규칙을 넣는다.
3. 문서 조각과 출처를 컨텍스트로 넣는다.
4. 모델이 근거 기반 답변을 생성한다.
5. 필요하면 출처 표시, 후처리, 검증을 수행한다.

이때 발생할 수 있는 문제

문제	설명
Context overflow	검색 결과가 너무 많아 중요한 근거가 잘리거나 비용이 증가함
Lost in the middle	긴 컨텍스트 중간의 중요한 정보가 모델에게 덜 반영됨
Prompt injection	외부 문서 안의 악성 지시를 모델이 따를 수 있음
근거 없는 답변	검색 결과에 답이 없는데 모델이 아는 척 답할 수 있음
출처 왜곡	답변 내용과 실제 근거 문서가 맞지 않을 수 있음

RAG에서 벡터DB 검색 품질을 높이는 방법에는 뭐가 있나?

Vector DB

• 벡터와 원문, metadata를 저장하고 유사도 검색을 수행한다

방법	설명
Chunk size 조정	문서 구조에 맞게 chunk 크기와 overlap을 조절한다
구조 기반 chunking	제목, 섹션, 표, 코드 블록 단위로 의미가 끊기지 않게 나눈다
Metadata 강화	서비스명, 버전, 날짜, 권한, 문서 타입 등을 저장해 필터링한다
Hybrid search	vector search와 BM25/keyword search를 결합해 의미 검색과 정확한 용어 검색을 모두 챙긴다
Query rewriting	짧거나 모호한 사용자 질문을 검색에 적합하게 재작성한다
Multi-query retrieval	여러 관점의 query를 만들어 recall을 높인다
Reranking	top-k 후보를 cross-encoder나 LLM reranker로 재정렬한다
Deduplication	중복 chunk를 제거해 컨텍스트 낭비를 줄인다
Domain-specific embedding	도메인 용어가 중요한 경우 적합한 embedding model을 선택하거나 학습한다
Evaluation set 관리	실제 질문-정답-근거 문서 쌍으로 검색 품질을 지속 측정한다

[9ga0]

1. RAG는 무엇이고, 왜 파인튜닝만으로는 부족한가?

RAG이전에 LLM과 파인튜닝이 있었습니다. 파인튜닝이란 학습이 끝난 LLM을 특정 목적에 맞게 추가로 학습시키는 것을 말합니다. 그러나 파인튜닝은 행동이나 표현 방식을 바꾸는 데는 좋지만, 바뀐 지식이 적용되지 않은 답변을 도출할 수 있다는 점과 모든 지식을 모델에 넣기 어렵다는 점에서 단점이 있습니다. 이를 해결하기 위해 등장한 것이 RAG이며, RAG는 LLM이 답변을 만들기 전에 외부 지식 검색(Retrieval)을 한 뒤에, 그걸 바탕으로 답변을 생성(Generation)하는 방식입니다. 즉 모델이 자기 기억만으로 답하는 게 아니라, 실제 존재하는 최신 문서를 근거로 답변을 생성하기에 신뢰도가 향상됩니다. 따라서 최신성이 중요한 서비스에서는 RAG가 매우 효과적이며, 실제로는 파인튜닝과 RAG를 함께 사용하는 경우가 많다고 합니다.

2. RAG의 핵심 파이프라인 3단계는 무엇인가? (+각 단계에서 발생 가능한 문제)

1. 검색(Retrieval) 단계로, 사용자의 질문과 관련있는 문서를 찾는 단계입니다. 질문을 임베딩으로 변환한 후, 벡터DB에서 유사한 문서를 검색하고, 필요한 경우 키워드 검색도 병행하여 문서를 찾습니다. 이 단계에서는 질문이 문서 의미와 잘 안 맞아 관련 문서를 못찾거나, 너무 많은 문서를 가져와서 노이즈가 섞이는 등의 문제가 발생할 수 있습니다.
2. 증강(Augmentation) 단계로, 찾아온 문서를 프롬프트에 넣어, 모델이 참고할 수 있게 만드는 단계입니다. 검색된 문서 일부를 시스템 프롬프트나 컨텍스트에 삽입하고, 질문+참고문서+답변 지시문이 함께 구성됩니다. 이 단계에서는 상대적으로 덜 중요한 문서가 앞에 와서 답변의 품질이 떨어질 수 있으며, 컨텍스트 길이를 초과할 수 있고, 너무 많은 정보가 주입되면 모델이 헷갈릴 수도 있습니다.
3. 생성(Generation)단계로, 모델이 검색된 근거를 바탕으로 최종 답변을 만드는 단계입니다. 여기서는 문서를 줬는데도 근거로 반영하지 못하고, 일반적인 답변을 생성하여 환각(Hallucination)을 일으킬 수 있으며, 출처를 명확히 드러내지 못할 수도 있습니다.

3. RAG에서 벡터DB 검색 품질을 높이는 방법에는 뭐가 있나?

검색 대상 문서를 잘 만들고, 검색 방식을 잘 고르고, 검색 결과를 다시 다듬는 것이 핵심이다.

1. Chunking을 잘해야한다. 문서를 너무 크게 자르면 검색이 부정확하고, 너무 작게 자르면 문맥이 끊깁니다. 따라서 문단이나 의미 단위로 자르거나, overlap을 줘서 문맥 손실을 줄이는 것이 좋다.
   * chunk overlap : 조각을 나눌 때, 조각 사이의 일부 내용을 겹치게 자르는 것.

    A B C D E F G H I J  
    # overlap을 2개 정도 주고 자르면  
    Chunk 1: A B C D E  
    Chunk 2: D E F G H  
    Chunk 3: G H I J  
   

2. 임베딩 모델을 잘 선택해야한다. 임베딩 품질이 검색 품질에 직접적인 영향을 주기 떄문에, 도메인에 맞는 임베딩 모델을 사용해야하며, 한국어 성능을 확인하고, 짧은 질의와 긴 문서 모두 잘 처리하는지 검토한다.

3. 하이브리드 검색을 쓴다. 키워드는 정확한 용어 탐색에 강하며, 벡터는 의미 유사도 탐색에 강하기 때문에. 벡터 검색만 쓰지 말고 키워드 검색과 함께 쓰면 좋다.

4. Re-ranking을 적용한다. 1차 검색으로 후보를 넓게 가져오고, 2차로 더 정교한 모델이 순위를 다시 매기면 품질이 좋아진다.

5. 메타데이터 필터링을 활용한다. 날짜, 문서 유형, 권한, 제품 버전 등을 함께 붙여 검색하면 잡음이 준다.

6. 질의 확장. 사용자 질문이 너무 짧거나 모호할 때, 질문을 여러 표현으로 바꿔 검색하면 성능이 좋아질 수 있다.

7. 문서 전처리를 잘한다. 검색 품질은 원본 데이터 품질 영향을 많이 받습니다. 중복 문서 제거, 깨진 텍스트 정리, 표/코드/목차 분리, 불필요한 페이지 제거 등의 작업이 필요하다.

8. 평가와 튜닝을 반복한다. 정답이 있는 질의셋을 만들어 top-k recall, precision, MRR, 실제 답변 품질을 보며 계속 개선해야한다.

   • top-k recall : 정답 문서가 검색 결과 상위 k개 안에 '포함'되었는지를 테스트

   • precision : 검색한 문서들 중에서 실제로 '관련 있는 문서의 비율'(쓸데없는 문서를 얼마나 적게 가져왔는가)

   • MRR(Mean Reciprocal Rank) : 정답 문서가 '몇 번째'에 나왔는지 평가하는 지표

     지표	무엇을 평가?	쉽게 말하면
     Recall@k	정답이 Top-k 안에 있는가	찾았는가?
     Precision	검색 결과가 얼마나 정확한가	엉뚱한 문서를 적게 가져왔는가?
     MRR	정답이 몇 등인가	얼마나 위에 올렸는가?