🧪 RAG 품질을 ‘감’이 아니라 ‘숫자’로 판단하는 법

🧪 RAG 품질을 ‘감’이 아니라 ‘숫자’로 판단하는 법

– A/B 테스트로 문서 구조·프롬프트·모델을 비교하는 실전 운영기
(NestJS + Vector DB + 실제 SaaS에서 굴려본 방식 그대로)

---

RAG 운영을 하다 보면 꼭 이 대화가 나옵니다.

“이번에 좀 좋아진 것 같지 않아?”
“음… 그런 것 같기도 하고…”

이 상태가 제일 위험해요.
감으로 튜닝하기 시작하면, RAG는 끝없이 흔들립니다.

그래서 어느 순간부터 저는 이렇게 바꿨습니다.

“느낌 얘기 말고, 숫자 보자.”

이번 글은
RAG에 A/B 테스트를 붙여서 품질을 ‘정량화’하는 방법을
실제 서비스에 적용한 방식 그대로 정리합니다.

---

🧭 이 글의 목표

• RAG 품질을 수치로 비교하는 기준 만들기
• 문서 구조 / 프롬프트 / 모델을 A/B 테스트하는 방법
• “이번 변경이 진짜 좋아졌는지” 판단하는 지표
• 운영 단계에서 써먹는 실전 체크리스트

---

1️⃣ RAG에서 A/B 테스트가 필요한 이유

RAG는 변수가 너무 많습니다.

• 문서 chunk 크기
• 요약 유무
• Vector DB 필터
• 검색 limit
• 프롬프트 문장 한 줄
• LLM 모델

이 중 하나만 바꿔도 결과가 달라집니다.

문제는 이거죠.

바뀐 결과가 좋아진 건지, 그냥 달라진 건지 모른다.

그래서 A/B 테스트가 필요합니다.

---

2️⃣ RAG A/B 테스트의 기본 원칙

반응형

❌ 흔한 실수

• 사용자마다 다른 설정
• 테스트 기준 없는 비교
• “괜찮아 보이는데?”로 결론

✅ 운영에서 지킨 원칙

1. 동일한 질문 세트
2. 동일한 사용자 조건
3. 동일한 문서 풀
4. 한 번에 하나만 변경
5. 결과는 로그로 저장

이 다섯 개 안 지키면
A/B 테스트 의미가 없습니다.

---

3️⃣ 가장 먼저 준비할 것: 기준 질문 세트

이게 제일 중요합니다.

기준 질문은 이렇게 만든다

• 실제 사용자 질문
• 애매한 질문 포함
• 쉬운 질문 + 까다로운 질문 섞기
• 최소 10개, 가능하면 20개

const benchmarkQueries = [
  "결제 실패하면 어떻게 하나요?",
  "구독 해지는 어디서 하나요?",
  "환불은 언제 되나요?",
  "AI 사용량은 언제 초기화되나요?",
  "요금제 변경하면 바로 적용되나요?"
];

👉 이 질문 세트는 절대 바꾸지 않습니다.

---

4️⃣ A/B 테스트 구조 설계

제가 쓰는 구조는 단순합니다.

Request
 ├─ Variant A (기존)
 └─ Variant B (변경)
        ↓
   결과 저장
        ↓
   점수 계산

Variant 예시

• A: chunk 500자 / summary 있음
• B: chunk 300자 / summary 있음

또는

• A: prompt v1
• B: prompt v2

---

5️⃣ NestJS에서 A/B 테스트 분기 구현

1) 실험 설정 테이블 (간단 버전)

type RagVariant = 'A' | 'B';

interface RagExperiment {
  variant: RagVariant;
  chunkSize: number;
  useSummary: boolean;
  promptVersion: number;
}

---

2) 실험 분기 로직

function pickVariant(userId: number): RagVariant {
  // 사용자 기준으로 항상 동일한 variant
  return userId % 2 === 0 ? 'A' : 'B';
}

👉 중요

• 한 사용자는 항상 같은 Variant
• 테스트 기간 동안 절대 바뀌면 안 됨

---

3) Variant별 RAG 실행

const variant = pickVariant(user.id);

const config =
  variant === 'A'
    ? { chunkSize: 500, prompt: promptV1 }
    : { chunkSize: 300, prompt: promptV2 };

const result = await ragService.answer({
  query,
  config
});

---

6️⃣ 결과를 어떻게 저장할까 (이게 핵심)

RAG A/B 테스트에서 결과 로그가 전부입니다.

최소 저장 항목

{
  query: "결제 실패하면 어떻게 하나요?",
  variant: "B",
  retrievedDocs: 4,
  responseTimeMs: 2100,
  tokenUsage: 480,
  answer: "...",
  createdAt: new Date()
}

이 데이터가 있어야
“왜 B가 더 좋은지”를 설명할 수 있습니다.

---

7️⃣ RAG 품질을 수치로 평가하는 지표

여기서 다들 막힙니다.

“AI 답변을 어떻게 점수로 매기죠?”

정답은 이겁니다.

완벽할 필요 없다.
비교만 가능하면 된다.

---

내가 실제로 쓰는 지표 5개

1️⃣ 응답 시간 (Response Time)

• 빠를수록 좋음
• UX에 직결

2️⃣ 토큰 사용량

• 비용 지표
• context 과다 여부 판단

3️⃣ 검색 문서 수

• 너무 많으면 잡음
• 너무 적으면 정보 부족

4️⃣ “문서 기반 응답 비율”

• 답변에 문서 내용이 실제로 반영됐는지
• 단순 생성 vs 근거 기반

5️⃣ 사용자 피드백 (가능하면)

• 👍 / 👎
• 이거 하나면 끝나기도 함

---

8️⃣ 자동 점수 계산 예시 (간단 버전)

function score(result) {
  let score = 0;

  if (result.responseTimeMs < 3000) score += 1;
  if (result.tokenUsage < 600) score += 1;
  if (result.retrievedDocs >= 3 && result.retrievedDocs <= 5) score += 1;

  return score; // 0 ~ 3
}

👉 중요한 건
A와 B를 같은 기준으로 재는 것

---

9️⃣ 실제로 가장 효과 있었던 A/B 테스트들

✅ 1위: summary 사용 vs 미사용

• summary 있음 → 압도적 승
• hallucination 감소
• 토큰 사용량 감소

✅ 2위: chunk 크기 500 vs 300

• 300자 쪽이 일관성 더 좋음
• 단, 문서 구조 잘 돼 있을 때만

❌ 효과 없었던 것

• LLM 모델 미세 변경
• temperature 0.1 차이

👉 문서 구조 > 프롬프트 > 모델

이 순서가 거의 고정입니다.

---

10️⃣ A/B 테스트 운영 체크리스트

운영 중 이걸 항상 봅니다.

• 한 번에 하나만 바꿨는가?
• 기준 질문 세트 고정했는가?
• 결과 로그를 남겼는가?
• 사용자 섞이지 않았는가?
• 최소 하루 이상 데이터 모았는가?

이거 안 지키면
테스트 결과 믿으면 안 됩니다.

---

11️⃣ 이 과정을 거치고 나서 달라진 점

이제 이런 말이 가능합니다.

“이번 변경은
응답 시간 22% 감소했고,
토큰 사용량 18% 줄었고,
사용자 👍 비율이 12% 올랐어요.”

이 한 문장으로
회의가 끝납니다.

---

마무리하면서 (진짜 하고 싶은 말)

RAG는 감각적인 영역 같지만,
운영 단계에선 완전히 공학적인 문제입니다.

• 감으로 튜닝 ❌
• 로그와 지표로 판단 ⭕

이 차이가
“데모 AI”와
“실서비스 AI”를 가릅니다.

 

---

 

RAGAB테스트, AI품질관리, 벡터DB운영, Qdrant, NestJS, AI서비스운영, RAG튜닝, AI실무