7가지 실수를 저지르기 전, RAG 인프라에 500달러를 낭비했습니다
개인 문서 검색을 위한 RAG 파이프라인을 구축했습니다. 컴퓨팅 비용으로 500달러를 썼고, 디버깅에 몇 주를 보냈습니다. 결과는 좋지 않았습니다. 사용자는 관련 없는 답변을 받았고 쿼리 속도는 느렸습니다.
파이프라인을 감사한 결과 7가지 흔한 실수를 발견했습니다. 이를 수정하자 모든 것이 바뀌었습니다.
- 고정 토큰 청킹 (Fixed Token Chunking) 문서를 고정된 토큰 수로 나누었습니다. 이로 인해 문맥이 파괴되었습니다. 문장이 중간에 잘려버렸습니다. LLM은 파편화된 데이터를 전달받아 부실한 답변을 내놓았습니다.
- 해결책: Parent-document retrieval을 활용한 시맨틱 청킹(semantic chunking) 사용.
- 단락이나 헤더와 같은 자연스러운 경계로 분할.
- 검색을 위한 작은 자식 청크(child chunks) 생성.
- 매칭이 발생하면 LLM에 전체 부모 문서(parent document)를 반환.
- 청크 사이에 10-20%의 중첩(overlap) 추가.
- 기본 검색 가중치 (Default Search Weights) 벡터 검색과 키워드 검색에 50/50 비율을 사용했습니다. 기술 문서의 경우 정확한 키워드가 더 중요합니다.
- 해결책: 동적 가중치 사용.
- 사실 기반 쿼리: 벡터 35%, 키워드 65%.
- 의미 기반 쿼리: 벡터 75%, 키워드 25%.
- HNSW 파라미터 과최적화
ef_construction을 최대값으로 설정했습니다. 대규모 인덱스에서 이는 서버를 다운시키고 모든 RAM을 점유했습니다.
- 해결책: 적절한 HNSW 설정 사용.
M은 8에서 32 사이로 유지.ef_construction은 200으로 설정.ef_search는 50으로 설정.
- 잘못된 임베딩 모델 웹 텍스트로 학습된 일반 모델을 사용했습니다. 이 모델은 저의 기술 엔지니어링 문서를 이해하지 못했습니다.
- 해결책: 기술 문서나 코드 콘텐츠에 맞춰 미세 조정(fine-tuned)된 모델로 교체.
- 자연어 불일치 (Natural Language Mismatch) 사용자는 "왜 빌드가 느린가요?"와 같이 질문하지만, 문서는 "CI 파이프라인 최적화"와 같은 용어를 사용합니다. 두 사이에는 접점이 전혀 없었습니다.
- 해결책: LLM 쿼리 재작성(query rewrite) 단계 추가.
- 검색 전 사용자 쿼리를 기술 용어로 재작성.
- 중복된 컨텍스트 상위 10개의 청크를 검색하면 동일한 단락이 세 번씩 나오는 경우가 많았습니다. 이는 환각(hallucination) 현상을 유발했습니다.
- 해결책: 결과의 다양성을 보장하기 위해 MMR(Maximal Marginal Relevance) 사용.
- 엔드 투 엔드(End-to-End) 평가만 수행 최종 답변만 확인했습니다. 문제가 검색(retrieval)에 있는지 LLM에 있는지 알 수 없었습니다.
- 해결책: 검색 성능을 별도로 평가.
- 히트 레이트(hit rate)와 평균 역순위(MRR, Mean Reciprocal Rank) 추적.
- 100개의 쿼리-문서 쌍으로 구성된 테스트 세트 구축.
수정 후 결과: • 답변 관련성: 45% -> 85% • 쿼리 지연 시간: 3.2s -> 1.8s • 월간 비용: $180 -> $95
먼저 청킹부터 해결하세요. 그다음은 가중치, 마지막은 임베딩 품질입니다.
RAG를 사용하며 겪는 가장 큰 고민은 무엇인가요? 댓글로 알려주세요.
학습 커뮤니티(선택 사항): https://t.me/GyaanSetuAi