🔄 RAG 문서 수집·정제 파이프라인 자동화

🔄 RAG 문서 수집·정제 파이프라인 자동화

– 사람이 손대지 않아도 “품질이 유지되는 AI 검색 시스템” 만드는 법
(NestJS + Vector DB + 운영 단계에서 진짜 필요한 구조)

---

앞선 글에서 이런 얘기를 했었죠.

RAG 품질은 모델보다
데이터와 구조에서 무너진다.

그리고 실제 운영에 들어가면,
그 말이 뼈저리게 느껴집니다.

처음엔 문서 20개라서
“아, 이 정도면 괜찮네” 싶다가
한 달, 두 달 지나면 이런 상황이 옵니다.

• 문서는 계속 늘어나고
• 누가 언제 뭘 넣었는지 모르겠고
• 예전엔 잘 맞던 질문이 갑자기 틀리고
• “이 문서, 왜 들어가 있지?” 싶은 게 튀어나오고

이때 대부분의 서비스는 이렇게 됩니다.

“일단 지금은 놔두자…”
→ 그리고 RAG 품질은 서서히 죽어감

이번 글은
이 상태로 안 가기 위해
문서 수집 → 정제 → 임베딩 → 검증 → 배포
전 과정을 자동화 파이프라인으로 만드는 이야기입니다.

---

🧭 이 글의 목표

• RAG 문서가 어디서부터 망가지는지 명확히 알기
• 운영 단계에서 필요한 문서 파이프라인 구조
• 사람이 개입하지 않아도 품질을 유지하는 방법
• “아, 이 사람은 운영까지 해봤구나” 소리 듣는 포인트

---

1️⃣ RAG 문서 파이프라인, 왜 필요한가

처음엔 보통 이렇게 시작합니다.

1. 문서 하나 생김
2. 복사해서 임베딩
3. Vector DB에 넣음

문제는 이게 100번, 1,000번 반복될 때입니다.

실제로 터지는 문제들

• 같은 내용이 조금씩 다른 문서로 여러 번 들어감
• HTML/푸터/메뉴 같은 쓰레기 텍스트 포함
• 너무 긴 문서가 그대로 들어감
• 제목 없는 chunk가 생김
• 요약 없는 문서가 쌓임

👉 이게 쌓이면
RAG는 반드시 품질이 떨어집니다.

그래서 필요한 게
“문서 파이프라인” 입니다.

---

2️⃣ 전체 문서 파이프라인 구조 (운영 기준)

반응형

운영에서 내가 정착시킨 흐름은 이겁니다.

[원본 문서]
   ↓
1. 수집 (Crawler / API / 업로드)
   ↓
2. 정제 (불필요한 텍스트 제거)
   ↓
3. 분할 (Chunking)
   ↓
4. 메타데이터 부여
   ↓
5. 요약 생성
   ↓
6. 임베딩 생성
   ↓
7. Vector DB 저장
   ↓
8. 검증 & 샘플 테스트

👉 중요한 건 “중간 단계”가 많다는 것
이 단계들이 없으면, 품질은 무조건 무너집니다.

---

3️⃣ 1단계: 문서 수집 (여기서부터 기준을 세워야 함)

문서 수집은 크게 3가지로 나뉩니다.

1) 내부 문서

• 관리자 페이지 작성
• Notion / Google Docs
• DB 기반 콘텐츠

2) 외부 문서

• 웹 페이지
• PDF
• 고객 FAQ

3) 사용자 생성 콘텐츠

• 게시글
• 댓글
• 문의 내역

---

❗ 여기서 중요한 원칙

“모든 문서를 다 넣지 않는다”

초반에 다들 이 실수를 합니다.

“많을수록 좋겠지?”

❌ 아닙니다.
RAG는 ‘선별’이 핵심입니다.

---

수집 기준 예시

• 최소 글자 수: 200자 이상
• 광고/홍보 문서 제외
• 오래된 공지 자동 제외
• 카테고리 명확한 문서만 허용

이 기준을 코드로 박아둬야 합니다.

---

4️⃣ 2단계: 문서 정제 (이 단계 안 하면 100% 망함)

문서 정제는
RAG 품질에 가장 큰 영향을 줍니다.

제거해야 할 것들

• HTML 태그
• 메뉴/푸터/사이드바 텍스트
• “관련 글 보기”
• 버튼 텍스트
• 중복 공지 문구

---

실전 정제 코드 예시

function cleanText(raw: string): string {
  return raw
    .replace(/<[^>]*>/g, '')       // HTML 제거
    .replace(/\s+/g, ' ')          // 공백 정리
    .replace(/관련 글 보기.*/g, '') // 불필요 문구 제거
    .trim();
}

👉 이 코드 하나로
검색 결과 관련도가 눈에 띄게 올라갑니다.

---

5️⃣ 3단계: 문서 분할 (Chunking 기준 잡기)

이 단계에서
RAG의 “성격”이 결정됩니다.

내가 최종적으로 정착한 기준

항목기준

길이	300 ~ 700자
단위	문단 기준
제목	반드시 포함
주제	하나만

---

❌ 실패했던 예

• 2,000자 통째로 하나의 chunk
• 문단 나누지 않고 줄바꿈만 있는 텍스트
• 제목 없는 본문만 chunk

---

Chunk 예시 구조

{
  "title": "결제 실패 시 처리 방법",
  "content": "결제 실패가 발생하면...",
  "category": "billing",
  "source": "help-center"
}

👉 제목은
LLM에게 문맥 방향을 잡아주는 앵커 역할을 합니다.

---

6️⃣ 4단계: 메타데이터 설계 (나중에 살려준다)

이 단계,
처음엔 다들 귀찮아서 대충 합니다.

근데 나중에 100% 후회합니다.

---

최소 메타데이터 세트

{
  "type": "guide",
  "category": "billing",
  "source": "admin",
  "createdAt": "2025-01-10",
  "version": "v2"
}

이게 있어야 가능한 것들:

• 특정 카테고리만 검색
• 오래된 문서 제외
• 실험용 문서 분리
• A/B 테스트

👉 메타데이터 없는 RAG는 확장 불가

---

7️⃣ 5단계: 요약 자동 생성 (품질 유지의 핵심)

이건 정말 강력합니다.

“요약 없는 RAG는 반쪽짜리다”

---

왜 요약이 필요한가

• LLM에 긴 원문을 그대로 주지 않기 위해
• 핵심만 컨텍스트로 쓰기 위해
• hallucination 줄이기 위해

---

요약 생성 예시

const summary = await openai.chat.completions.create({
  model: 'gpt-3.5-turbo',
  messages: [
    { role: 'system', content: '아래 문서를 한 문단으로 요약해.' },
    { role: 'user', content: chunk.content }
  ]
});

그리고 Vector DB에는 이렇게 저장합니다.

{
  "content": "...원문...",
  "summary": "...요약본..."
}

👉 검색 후 LLM에는
summary 위주로 전달

---

8️⃣ 6단계: 임베딩 & Vector DB 저장

이 단계는 이미 익숙할 겁니다.
중요한 건 앞 단계를 통과한 문서만 여기로 온다는 점.

await qdrant.upsert("documents", {
  points: [
    {
      id,
      vector: embedding,
      payload: {
        title,
        summary,
        category,
        source
      }
    }
  ]
});

---

9️⃣ 7단계: 자동 검증 (이거 안 하면 결국 터짐)

운영 단계에서 진짜 중요한 단계입니다.

내가 쓰는 간단한 검증 방식

• 샘플 질문 10개 고정
• 문서 추가 후 자동 검색
• 결과 로그 비교

const testQueries = [
  "결제 실패하면 어떻게 되나요?",
  "구독 해지는 어디서 하나요?"
];

👉 결과가 갑자기 바뀌면
바로 알 수 있어야 합니다.

---

10️⃣ 이 파이프라인의 진짜 의미

이 구조를 만들고 나서 느낀 점은 이거였습니다.

RAG는 “AI 기능”이 아니라
**“데이터 파이프라인 문제”**다.

• 문서가 늘어나도
• 사람이 바뀌어도
• 시간이 지나도

품질이 유지되는 구조
이게 진짜 운영입니다.

---

 

RAG파이프라인, 문서정제, 벡터DB운영, AI서비스운영, Qdrant, NestJS, AI백엔드, RAG자동화, AI품질관리