🔍 RAG 품질이 무너질 때 진짜 원인 찾기

🔍 RAG 품질이 무너질 때 진짜 원인 찾기

– “왜 AI가 엉뚱한 말을 하기 시작했을까?” 운영하면서 겪은 것들
(NestJS + Vector DB + Qdrant + OpenAI 기준, 현업 삽질 기록)

---

RAG를 처음 붙였을 때는 다들 이런 경험을 한다.

“오… 처음엔 진짜 똑똑한데?”
“근데 왜 점점 말이 이상해지지…?”

이게 착각이 아니다.
**RAG는 시간이 지날수록, 데이터가 쌓일수록 ‘망가질 수 있는 구조’**다.

이번 글은

• RAG 품질이 떨어질 때
• “모델이 멍청해진 건지”, “데이터가 문제인지”, “구조가 문제인지”
  를 하나씩 분해해서 원인을 찾는 글이다.

이론 얘기 ❌
운영하면서 실제로 겪은 증상 → 원인 → 해결 흐름으로 간다.

---

🧭 이 글의 목표

• RAG 품질 저하의 대표적인 증상 6가지
• 각 증상별 진짜 원인
• 운영 중 바로 써먹는 체크리스트
• “아, 이 사람은 RAG를 굴려봤구나” 소리 듣는 포인트

---

1️⃣ 증상 1: 분명 문서에 있는데, 엉뚱한 답을 한다

이게 제일 많이 나온다.

“문서에 정확히 써 있는데
왜 전혀 다른 답을 하지?”

❌ 많은 사람들이 하는 오해

• “LLM가 멍청하다”
• “모델을 바꿔야 하나?”

✅ 실제 원인

벡터 검색 단계에서 이미 잘못된 문서를 집어왔다

LLM은 받은 문맥 안에서는 최선을 다한다.
즉, 문제는 거의 항상 Retrieval 쪽이다.

---

🔎 체크 포인트

const results = await qdrant.search("documents", {
  vector,
  limit: 5,
});

이 결과를 로그로 그대로 찍어본 적 있는가?

console.log(results.map(r => r.payload.text));

👉 여기서 이미

• “이게 왜 나오지?”
• “이 문서는 관련이 없는데?”
  라는 생각이 들면 RAG는 이미 실패다.

---

2️⃣ 증상 2: 데이터가 많아질수록 정확도가 떨어진다

이건 거의 100% 재현된다.

초기(문서 50개):

“와, 거의 다 맞네”

운영 2개월 후(문서 5,000개):

“뭔가 예전보다 이상한데…?”

---

✅ 진짜 원인

벡터 DB는 ‘많다고 똑똑해지지 않는다’

특히 이런 경우에서 터진다:

• 한 컬렉션에 서로 다른 주제의 문서를 다 넣음
• 카테고리/도메인 구분 없이 검색
• 모든 문서를 동일한 가중치로 취급

---

❌ 나의 초반 구조

documents
 ├─ FAQ
 ├─ 가이드
 ├─ 정책
 ├─ 공지
 ├─ 실험 데이터

→ 전부 같은 컬렉션 😇

---

✅ 해결 방법 1: 컬렉션 분리 or 필터

await qdrant.search("documents", {
  vector,
  filter: {
    must: [
      { key: "type", match: { value: "guide" } }
    ]
  },
  limit: 4,
});

또는

documents_guide
documents_faq
documents_policy

👉 도메인 경계를 명확히 하는 것만으로도 품질이 확 올라간다.

---

3️⃣ 증상 3: 그럴듯한데 틀린 말을 한다 (hallucination)

반응형

이게 제일 무섭다.
틀린데 자신 있어 보인다.

---

❌ 흔한 착각

• “RAG 쓰면 hallucination 없어지는 거 아님?”

✅ 현실

RAG는 hallucination을 줄일 뿐,
문맥이 애매하면 여전히 만들어낸다.

---

주요 원인 3가지

1) 컨텍스트가 너무 많음

limit: 10 // ❌

문맥이 많아질수록
LLM은 중요한 걸 못 고른다.

👉 3~5개가 상한선

---

2) 문서 품질이 낮음

• 한 문서에 여러 주제 섞임
• 애매한 표현
• “~일 수 있다” 같은 문장

👉 LLM은 애매함을 증폭한다.

---

3) 질문 자체가 애매함

“이거 어떻게 해야 돼요?”

이런 질문은
AI 입장에선 뭘 물어본 건지 모른다.

---

✅ 해결 전략

• 문서 쪼개기 (chunk size 줄이기)
• 문서 저장 시 요약 필드 함께 저장
• 질문 전처리

const normalizedQuery = `
다음 질문을 명확한 한 문장 질문으로 바꿔줘:
"${userQuery}"
`;

---

4️⃣ 증상 4: 비슷한 질문인데 결과가 매번 다르다

운영하다 보면 이런 말 나온다.

“어제는 잘 대답했는데
오늘은 왜 이래요?”

---

✅ 원인

• 검색 결과 순서가 미세하게 바뀜
• LLM temperature 값
• 문맥 길이 변화

---

❌ 초반 설정

temperature: 0.7

---

✅ 운영 기준 설정

temperature: 0.2
top_p: 0.9

👉 RAG는 창의력이 필요 없다
👉 일관성이 중요

---

5️⃣ 증상 5: “관련 없는 문서”가 계속 끼어든다

이건 대부분 임베딩 이전 문제다.

---

주요 원인

• 너무 짧은 chunk (문맥 부족)
• 너무 긴 chunk (주제 섞임)
• 전처리 안 된 텍스트 (HTML, 메뉴, 푸터 포함)

---

실전 chunk 기준 (내 기준)

항목권장

글자 수	300~700자
문단 단위	O
제목 포함	O
불필요한 UI 텍스트	제거

---

6️⃣ 증상 6: RAG 답변이 “얕다”

“뭔가 다 아는 척은 하는데
깊이가 없다…”

---

이건 의외로 Retrieval 문제가 아니다

LLM 프롬프트 문제다.

---

❌ 흔한 프롬프트

다음 문서를 참고해서 답변해줘.

---

✅ 개선된 프롬프트

아래 문서 내용을 기반으로만 답변해.
문서에 없는 내용은 모른다고 말해.
답변은 단계별로 정리해.

👉 이 한 줄 차이로
답변 품질이 완전히 달라진다.

---

7️⃣ RAG 품질 점검 체크리스트 (운영용)

운영 중 이 체크리스트를 쓴다.

• 검색 결과 로그를 직접 확인했는가?
• 컬렉션/도메인 분리가 되어 있는가?
• limit 3~5 유지 중인가?
• 문서 chunk 크기가 적절한가?
• 문서 요약 필드가 있는가?
• temperature 0.3 이하인가?
• 질문 전처리를 하는가?

👉 여기서 2~3개만 틀어져도
RAG는 바로 흔들린다.

---

8️⃣ 실무에서 깨달은 진짜 핵심

이건 정말 중요한 문장이다.

RAG 품질 문제의 80%는
모델이 아니라 데이터와 구조다.

LLM을 바꾸기 전에
반드시 이걸 먼저 보자.

• Retrieval이 맞는가?
• 문서가 좋은가?
• 질문이 명확한가?

---

 

RAG품질, 벡터검색, Qdrant, LLM운영, AI서비스, NestJS, AI삽질기, RAG문제해결, AI백엔드