RAG 정리하기

RAG(retrieval-augmented generation)

---

llm은 학습한 것만 안다

→ 검색기로 필요한 정보를 가져와서
→ 생성기로 답을 생성하게 하자

---

기본 구조는

• Query Encoder: 유저 질문을 임베딩
• Retriever: 유사한 문서/패시지를 벡터 DB에서 검색
• LLM Generator: 검색된 내용을 기반으로 응답 생성
• (선택) Fusion Module: 여러 결과를 합쳐 정리하거나 재랭킹

작동 흐름은
유저 입력 → 쿼리 인코딩 → 벡터 db 검색(top k) → llm 생성(답)

---

원래 첫 논문은

"Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"

특징:

• Retriever: DPR (Dense Passage Retriever)
• Generator: BART
• Fusion-in-Decoder 방식 (retrieved document들을 하나의 입력으로 넣음)

거의 transformer 급 paper 아닐까?

---

RAG의 핵심 설계 포인트 (Technical Deep Dive)

1. Retriever 선택

• Sparse:
  BM25, TF-IDF 기반
  속도 빠름, 구조 단순
• Dense:
  DPR, OpenAI Ada, Sentence-BERT 등
  의미 기반 유사도 측정, 성능 높음
• Hybrid:
  위 둘을 결합해 recall 향상

---

2. Chunking 전략

문서를 어떻게 쪼갤지 결정
(sliding window, recursive chunking, semantic splitting 등)

• chunk size가 너무 작으면 문맥 손실
• 너무 크면 검색 성능 하락

---

3. Top-k 설정

• 검색 문서 개수 (예: 3~10)
• 너무 많으면 노이즈
• 너무 적으면 정보 부족

---

4. Prompt 구성 전략

• Question: 사용자 질문
• Context: Retrieved Passages
  → generate answer

LLM에게 넣을 때 context formatting 중요함
bullet로 줄 건지, json으로 줄 건지, 인라인 주석 포함할 건지 등

---

5. Re-Ranking

검색 결과를 LLM이나 별도 모델로 다시 점수 매겨 재정렬

---

내가 찾아봤던 거

1. 문서를 왜 쪼개야 해?

• 벡터 검색 정확도: 문서가 길면 중간 정보가 묻혀지고, 유사도 계산이 흐릿해짐
• LLM context 길이 제한
• 쪼개야, 누가누가 더 비슷한 건지 학습이 더 잘됨
  (첫 번째 이유와 같은 맥락이긴 함)

---

2. Retriever라는 말이 참 마음에 안 든다

• 인코더나 탐색기 정도가 더 낫지 않나?
• Retriever가 하는 일은:
  쿼리를 벡터화(혹은 임베딩)하고
  유사도 계산해서
  top-k 찾아주는 것

---

3. top-k는 어떻게 계산하지?

• 입력 쿼리 벡터랑, 벡터 db에 있는 모든 chunk와 유사도 계산
• 스코어 계산
• 높은 순으로 k개 고르기 = top-k

근데 실전에서는 계산 효율을 위해
ANN(예: FAISS, HNSW)을 써서 top-k를 근사적으로 계산함

---

봐봐, nlp도 결국은 추천 시스템이 맞자나?