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	정답이 몇 등인가	얼마나 위에 올렸는가?

[k9425mino]

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

RAG는 사용자의 질문과 관련된 정보를 신뢰할 수 있는 외부 지식 저장소에서 검색한 뒤, 프롬프트와 그 내용을 LLM에 함께 제공하여 더욱 정확한 답변을 생성하도록 돕는 기술이다. 즉, 모델 파라미터 안의 학습한 지식만 사용한는 것이 아니라 필요한 정보를 외부에서 실시간으로 참조하여 활용한다.

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

RAG의 동작을 단순화하면 다음과 같다.

사용자 질문 → 관련 문서 검색 → 질문과 검색 문서를 LLM에 입력 → 근거 기반 답변 생성

예를 들어 사내 규정에 대해 질문하는 챗봇이 있다고 가정해 보자. 사용자가 “경조사 휴가는 며칠인가?”라고 질문하면, RAG 시스템은 먼저 사내 인사 규정에서 경조사 휴가 관련 문단을 검색한다. 이후 검색된 규정과 질문을 함께 언어 모델에 전달하고, 모델은 해당 규정을 근거로 답변한다.

즉, RAG는 언어 모델 자체를 거대한 데이터베이스로 사용하는 대신, 모델이 필요할 때 외부 지식을 조회하도록 만든 구조이다.

LLM을 특정 기업 데이터나 최신 정보에 맞게 커스텀할 때 사용하는 파인튜닝만으로 부족한 이유는 다음과 같다.

• 최신 지식을 반영하기 어려움 : 파인튜닝은 특정 시점의 스냅샷 지식을 모델에 굳혀 넣는 것이라, 이후 바뀐 정보(가격, 정책, 최신 뉴스 등)를 반영하려면 매번 재학습해야 한다. 비용과 시간이 많이 들게된다.
• 정확한 사실을 안정적으로 저장하기 어려움 : 파인튜닝은 "그럴듯한 문장을 생성하는 능력"을 강화할 뿐, 사실 여부를 검증하는 메커니즘이 없다. 모델이 모르는 걸 아는 것처럼 답할 위험은 그대로 남게 된다.
• 출처를 제시하기 어려움 : 파인튜닝된 지식은 파라미터 속에 암묵적으로 녹아 있어서 "이 답변의 근거가 무엇인지"를 명시적으로 보여줄 수 없다. RAG는 검색된 문서를 citation처럼 제시할 수 있다.
• 대규모 문서를 파라미터에 모두 학습시키는 것은 비효율적이다 : 사내 문서, 매뉴얼처럼 방대하고 자주 바뀌는 데이터를 전부 파인튜닝에 넣기엔 비효율적이고, 민감 정보 보안 관리도 어렵다.
• 접근 권한을 세밀하게 설정하기 어려움 : 파인튜닝으로 민감 정보를 모델에 학습시키면 특정 사용자가 해당 정보를 요청하지 않았는데도 모델이 이를 생성할 위험이 있다. 반면 RAG에서는 검색 단계에서 사용자 권한에 따라 검색 가능한 문서를 제한할 수 있다.
• 많은 비용 부담 : 파인튜닝은 GPU 자원과 시간이 크게 드는 반면, RAG는 벡터DB에 문서만 새로 추가/삭제하면 되므로 훨씬 저렴하고 빠르게 지식을 업데이트할 수 있다.

따라서 실무에서는 두 기술을 경쟁 관계로 보기보다 역할을 구분하는 것이 적절하다.

• 파인튜닝: 모델의 행동 방식, 말투, 형식, 전문 작업 능력 개선
• RAG: 최신 정보, 세부 사실, 대규모 외부 지식 제공

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

< 1단계, Indexing(인덱싱) >

인덱싱 단계에서는 원본 문서를 검색 가능한 형태로 변환한다.

문서 수집 → 문서 정제 → 청킹 → 임베딩 생성 → 벡터DB 저장

1. 문서 수집과 전처리 : PDF, 웹페이지, 데이터베이스, 워드 파일 등의 데이터를 수집하고 텍스트를 추출한다. 이때 머리글, 바닥글, 광고, 중복 문장, 깨진 문자 등을 제거해야 한다.
2. 청킹 : 긴 문서를 일정 크기의 작은 단위인 청크(chunk)로 나눈다. 검색은 보통 문서 전체가 아니라 청크 단위로 수행된다.
3. 임베딩 : 각 청크를 임베딩 모델에 입력해 의미를 표현하는 고차원 벡터로 변환한다.
4. 벡터DB 저장 : 생성된 벡터와 원문, 문서 제목, 작성일, 카테고리 등의 메타데이터를 벡터 데이터베이스에 저장한다.

인덱싱 단계에서 발생가능한 문제

• 청킹 전략 문제 : 청크가 너무 작으면 문맥이 끊기고, 너무 크면 노이즈가 섞여 검색 정확도가 떨어진다. 표, 코드, 리스트 같은 구조화된 데이터는 단순 텍스트 분할 시 의미가 깨질 수 있다.
• 메타데이터 손실 : 문서의 제목, 섹션, 출처, 날짜 등 컨텍스트 정보를 청크에 함께 저장하지 않으면 검색 후 활용도가 낮아진다.
• 임베딩 모델의 도메인 불일치 : 일반 목적 임베딩 모델이 특정 전문 도메인(의료, 법률 등) 용어를 잘 표현하지 못할 수 있다.
• 업데이트 동기화 : 원본 문서가 바뀌었을 때 벡터DB를 갱신하지 않으면 최신성이 깨진다. (stale index 문제).

결국 RAG의 품질은 언어 모델보다 먼저 데이터 품질과 인덱싱 품질에 의해 제한될 수 있다.

< 2단계, Retrieval(검색) >

검색 단계에서는 사용자의 질문을 임베딩 벡터로 변환하고, 벡터DB에서 의미적으로 가까운 문서 청크를 찾는다.

질의 벡터를 (q), 문서 벡터를 (d)라고 하면 코사인 유사도는 일반적으로 다음과 같이 계산된다.

$$\frac{q \cdot d}{|q||d|}$$

유사도 점수가 높은 상위 (k)개의 청크를 선택해 생성 모델에 전달한다.

검색 단계에서 발생가능한 문제

• 의미적 유사도 ≠ 답변 관련성 : 벡터 유사도가 높다고 해서 실제로 질문에 답하는 데 필요한 정보인 것은 아니다. (semantic gap).
• Lexical(어휘적) 매칭 실패 : 임베딩 기반 검색은 고유명사, 숫자, 코드처럼 정확한 키워드 매칭이 중요한 경우 취약하다.
• Top-K 설정 문제 : K가 너무 작으면 필요한 정보를 놓치고, 너무 크면 노이즈가 많아져 생성 단계에서 방해가 된다.
• 질의-문서 표현 불일치 : 사용자의 질문 표현과 문서의 표현 방식이 다를 때(질문은 짧고 구어체, 문서는 formal) 검색 성능이 저하된다.

검색 단계에서 정답 근거를 찾지 못하면, 생성 모델이 아무리 뛰어나도 정확한 답을 만들기 어렵다. 이를 흔히 Garbage In, Garbage Out 문제로 설명할 수 있다.

< 3단계, Generation(생성) >

생성 단계에서는 검색된 문서와 사용자의 질문을 프롬프트에 함께 넣고 LLM이 최종 답변을 생성한다.

이 단계의 핵심은 모델이 검색 문서를 단순히 참고하는 수준을 넘어, 문서에 근거한 답변을 생성하도록 하는 것이다.

생성 단계에서 발생가능한 문제

• Lost in the middle : 컨텍스트가 길어질수록 모델이 중간에 위치한 정보를 덜 활용하는 경향이 있다. (긴 컨텍스트에서 앞/뒤 정보에 집중하는 편향).
• 검색된 문서 간 모순 : 여러 청크가 서로 상충되는 정보를 담고 있을 때 모델이 이를 어떻게 종합할지 애매하다.
• 여전히 남는 환각 : 검색된 문서에 답이 없는데도 모델이 그럴듯하게 답을 지어낼 수 있다. (문서를 참고하되 완전히 근거하지 않는 경우).
• 컨텍스트 길이 제한 : 검색된 청크 수가 많아지면 토큰 제한에 걸리거나 비용이 커진다.

검색 문서 자체의 관련성뿐 아니라, 문서가 실제 정답을 뒷받침하는 증거성(evidentiality)​도 중요하다. 관련성이 낮은 문서를 바탕으로 생성하면 모델이 허위 단서를 학습하거나 잘못된 답을 생성할 수 있다는 연구도 존재한다.

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

벡터DB 검색 품질은 단순히 더 좋은 벡터DB 제품을 사용하는 것으로 해결되지 않는다. 데이터 구성, 임베딩 모델, 검색 방식, 질의 처리, 재정렬 및 평가를 함께 개선해야 한다.

(1) 청킹 최적화

• 문장/문단 경계를 존중하는, semantic chunking, 혹은 overlap을 둔 sliding window 방식 사용하기
• 표, 코드 블록 등은 별도 처리 로직 적용
• 청크에 상위 문맥(제목, 섹션 정보)을 함께 임베딩하거나 메타데이터로 첨부

(2) 하이브리드 검색 (Hybrid Search)

• 벡터 검색(semantic) + BM25/키워드 검색(lexical)을 결합하기
• 고유명사, 숫자, 특정 용어가 포함된 질의에서 특히 효과적
• 두 결과를 RRF(Reciprocal Rank Fusion) 등으로 결합하기

(3) Re-ranking (재순위화)

• 1차로 벡터DB에서 넉넉하게 후보를 뽑은뒤, Cross-encoder 기반 reranker(Cohere Rerank, BGE-reranker)로 질의-문서 쌍을 재평가하여 최종 Top-K를 선별하기
• 순수 벡터 유사도보다 훨씬 정밀한 관련성 판단 가능

(4) 쿼리 변환/확장 (Query Transformation)

• Query rewriting : 사용자의 애매한 질의를 더 명확하고 구체적인 형태로 재작성한다.
• HyDE(Hypothetical Document Embeddings) : LLM이 가상의 답변을 먼저 생성하고, 그 답변을 임베딩해 검색에 사용하기 (질문보다 답변 형태가 문서와 더 유사하기 때문)
• Multi-query : 하나의 질문을 여러 관점으로 변형하여 여러 번 검색 후 결과 통합하기

(5) 임베딩 모델 개선

• 도메인 특화 데이터로 임베딩 모델을 파인튜닝 (예: 대조학습 기반)
• 최신 고성능 임베딩 모델 채택 및 벤치마크(MTEB 등)로 검증하기

(6) 메타데이터 필터링

• 날짜, 카테고리, 출처, 접근 권한 등 메타데이터를 활용한 필터링으로 검색 범위를 좁혀 정확도 향상시키기

(7) 인덱스 구조/파라미터 튜닝

• HNSW, IVF 등 ANN 인덱스의 파라미터(ef_search, nprobe 등) 조정으로 재현율(recall)과 속도의 균형 조절하기

(8) 피드백 루프 구축

• 실제 사용자 쿼리 로그와 클릭/평가 데이터를 활용해 검색 품질을 지속적으로 모니터링 하고 개선(예: Golden dataset으로 Retrieval 성능 평가 - Recall@K, MRR, nDCG 등 지표 활용)

[eunji719]

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

RAG란 AI가 답변을 생성하기 전에 필요한 정보를 외부 DB나 문서에서 먼저 검색한 뒤, 검색한 정보를 바탕으로 답변을 생성하는 기술이다. 즉, 학습된 지식만 사용하는 것이 아닌, 최신 정보나 회사 내부 문서와 같은 외부 데이터를 함께 활용하여 더욱 정확한 답변을 제공할 수 있다.

파인튜닝이란, 특정 분야의 데이터를 이용하여 모델 자체를 추가 학습 시키는 방법으로 이를 통해 업무나 말투 면에서는 능력이 향상될 수 있지만, 새로운 정보가 생길 때 마다 다시 학습해야 하므로 시간과 비용이 많이 든다는 한계가 있다.

따라서 파인튜닝만으로는 자주 변경되는 정보나 최신 데이터를 반영하기어렵다. RAG는 필요한 정보를 실시간으로 검색하여 활용하기 때문에, 최신성을 유지할 수 있고, 모델을 다시 학습 시키지 않고 새로운 데이터를 바로 사용할 수 있다. 따라서 모델의 능력을 향상시켜야 하는 전문적인 작업에서는 파인튜닝, 새로운 외부 지식을 실시간으로 빠르게 활용해야 하는 작업에서는 RAG를 사용하여 모델의 전문성과 최신성을 동시에 확보하는 것이 중요하다.

---

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

1. Indexing

Indexing은 쉽게 말해서 자료를 AI가 찾기 쉽게 미리 정리하는 과정을 말한다. 처음부터 질문이 들어올 때마다 모든 자료를 읽어버리면 너무 오래 걸린다. 그래서 미리 자료를 잘게 나누고(Chunking), 그 나눈 문장을 AI가 이해할 수 있는 숫자 벡터로 변환하고(Embedding) 벡터DB에 저장한다. 그래서 나중에 비슷한 내용을 빠르게 찾을 수 있다. 이 과정에서 문서를 너무 크게 나누면, 필요한 정보만 정확하게 찾기 어렵고, 반대로 너무 작게 나누면 문맥이 끊어져 의미를 제대로 이해하지 못하는 문제가 발생할 수 있다.

2. Retrieval

검색 단계에서도 사용자의 질문을 임베딩 한 후에, 벡터DB에서 가장 관련성이 높은 문서를 검색한다. 하지만 여기서 질문과 관련된 문서를 제대로 찾지 못하거나 관련성이 낮은 문서를 검색하면 이후 생성되는 답변의 품질도 함께 떨어지는 문제가 발생할 수 있다.

3. Generation

생성 단계는 검색된 문서를 LLM의 프롬프트에 함께 전달하여 최종 답변을 생성하는 단계이다. 이 단계에서는 검색된 정보를 충분히 활용하지 못하거나, 검색 결과와 무관한 내용을 생성하는 환각이 발생할 수 있다.

---

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

RAG에서 검색 품질은 최종 답변의 정확도에 큰 영향을 미친다. 때문에 벡터 DB에서 관련성 높은 문서를 찾기 위한 여러 방법이 있다. 먼저 Chunking을 적절하게 수행하는 것이 중요하다. 문서를 너무 크게 또는 작게 나누면 문제가 생길 수 있기 때문에 적절한 크기로 문서를 분할해야 하고, 적절한 임베딩모델을 선택해야 한다. 임베딩 모델의 성능이 좋을수록 문장의 의미를 더 정확하게 벡터로 표현할 수 있어 사용자의 질문과 관련성이 높은 문서를 검색할 가능성이 높아진다. 또한 Hybrid Search를 사용할 수 있다. 벡터 검색은 문장의 의미를 기반으로 검색하는 반면, 키워드 검색은 동일한 단어나 용어를 정확하게 찾는 데 강점이 있다. 따라서 두 방식을 함께 사용하면 의미와 키워드를 모두 고려할 수 있어 검색 품질을 높일 수 있다. 마지막으로 Reranking기법을 사용할 수 있다. 벡터 DB에서 검색된 여러 문서를 그대로 사용하는 것이 아니라, 별도의 모델이 문서들의 관련성을 다시 평가하여 가장 적합한 순서로 재정렬한 뒤 LLM에 전달하는 방식이다. 이를 통해 더 정확한 문서에게 우선순위를 높게 줄 수 있다.