이 7가지 실수를 바로잡기 전, RAG 인프라에 500달러를 낭비했습니다
개인 문서 검색을 위한 RAG 파이프라인을 구축했습니다. 컴퓨팅 비용으로 500달러를 썼고, 디버깅에 몇 주를 보냈습니다. 결과는 좋지 않았습니다. 사용자는 잘못된 답변을 받았고 쿼리 속도는 느렸습니다.
파이프라인을 감사한 결과, 7가지 실수를 발견했습니다. 이를 수정하자 모든 것이 바뀌었습니다.
- 고정된 토큰 청킹(Fixed Token Chunking) 문서를 512개 토큰 단위로 나누었습니다. 이로 인해 문맥이 파괴되었습니다. API 설명이 문장 중간에서 잘리기도 했습니다. LLM은 파편화된 정보를 받아 쓸모없는 답변을 내놓았습니다. 해결책: 시맨틱 청킹(Semantic Chunking) 사용.
- 단락이나 헤더와 같은 자연스러운 경계에 따라 분할합니다.
- Parent-document retrieval을 사용합니다.
- 검색을 위한 작은 child chunk를 생성합니다.
- LLM에는 전체 parent document를 반환합니다.
- 청크 사이에 10-20%의 중첩(overlap)을 추가합니다.
- 잘못된 하이브리드 검색 가중치 벡터 검색과 키워드 검색에 50/50 비율을 적용했습니다. 기술 문서에서는 이 방식이 통하지 않았습니다. 기술 사용자는 정확한 키워드 일치를 필요로 합니다. 해결책: 동적 가중치 사용.
- 사실 기반 쿼리: 벡터 35%, 키워드 65%.
- 의미 기반 쿼리: 벡터 75%, 키워드 25%.
- 일반 쿼리: 벡터 60%, 키워드 40%.
- HNSW 파라미터 과잉 튜닝
ef_construction을 최댓값으로 설정했습니다. 이로 인해 서버가 다운되었습니다. 사용 가능한 모든 RAM을 점유했습니다. 해결책: 적절한 파라미터 사용.
- M을 8에서 32 사이로 설정합니다.
ef_construction을 200으로 설정합니다.ef_search를 50으로 설정합니다. 메모리 사용량이 70% 감소했습니다.
일반적인 임베딩 모델 Wikipedia로 학습된 모델을 사용했습니다. 제 문서는 기술 엔지니어링 런북(runbook)이었습니다. 모델이 제 도메인을 이해하지 못했습니다. 해결책: 기술 문서나 코드 콘텐츠에 맞춰 파인튜닝된 모델을 사용합니다.
쿼리 재작성(Query Rewriting) 부재 사용자는 자연스러운 질문을 던지지만, 기술 문서는 공식적인 용어를 사용합니다. 이 둘은 서로 일치하지 않습니다. 해결책: 쿼리를 재작성하기 위한 가벼운 LLM 단계를 추가합니다.
- 사용자 질문: "왜 빌드가 느린가요?"
- 시스템 재작성: "CI 파이프라인 성능 최적화"
- 이를 통해 재현율(recall)이 40% 향상되었습니다.
중복된 결과 상위 10개의 청크를 검색하면 동일한 단락이 세 번씩 나오는 경우가 많았습니다. LLM도 같은 말을 반복했습니다. 해결책: 결과의 다양성을 보장하기 위해 MMR(Maximal Marginal Relevance)을 사용합니다.
잘못된 테스트 대상 파이프라인 전체를 한꺼번에 테스트했습니다. 문제가 검색(retrieval)에 있는지 LLM에 있는지 알 수 없었습니다. 해결책: 검색 평가를 분리합니다.
- 히트 레이트(hit rate)를 추적합니다.
- MRR(Mean Reciprocal Rank)을 추적합니다.
- 100개의 쿼리-문서 쌍으로 구성된 테스트 세트를 구축합니다.
수정 후 결과:
- 답변 관련성: 45%에서 85%
- 지연 시간: 3.2s에서 1.8s
- 월간 비용: $180에서 $95
먼저 청킹을 수정하십시오. 그다음 가중치, 마지막으로 임베딩 품질을 수정하십시오.