최근에 회사 프로젝트에서 RAG(Retrieval-Augmented Generation) 시스템을 처음 제대로 구축해봤는데, 생각보다 훨씬 까다롭네요. 처음엔 임베딩 모델 얹고 벡터 DB 연결하면 끝인 줄 알았는데 실제로는 그게 전부가 아니더라고요.
가장 첫 번째 문제가 청킹 전략이었어요. 문서를 어떻게 나눌지가 생각보다 중요한데, 고정 크기로 나누면 맥락이 끊기고 동적으로 나누려니까 알고리즘이 복잡해지고... 결국 용도별로 다르게 가져가야 한다는 걸 깨달았습니다. 우리 경우엔 문서 구조 기반 청킹을 선택했는데 초반에 많이 시행착오를 거쳤어요.
두 번째는 임베딩 모델 선택이었어요. 오픈소스 모델을 쓸지 API를 쓸지부터 고민이 많았거든요. OpenAI 모델이 성능은 좋은데 매번 비용이 나가고, 오픈소스는 가볍지만 미묘한 느낌의 검색 결과가 나올 때가 있었어요. 결국 회사 데이터 특성에 맞게 여러 모델을 벤치마킹해서 정했는데 시간이 꽤 걸렸습니다.
가장 골치 아팠던 부분은 리랭킹이었어요. retrieval 단계에서 잘못된 문서를 높게 스코어 하는 경우가 자주 생기더라고요. 처음엔 그냥 벡터 유사도만 썼는데, 나중에 크로스 인코더 기반 리랭킹을 추가하니 정확도가 확 올라갔어요. 근데 이게 추가 비용과 레이턴시가 증가하는 trade-off가 있어서 결국 타협점을 찾아야 했습니다.
지금 운영 중이면서 느끼는 건데, RAG도 결국 production에 올리면 계속 모니터링하고 개선해야 한다는 거예요. 검색 결과가 좋지 않은 쿼리들을 주기적으로 분석해서 청킹을 조정하거나 프롬프트를 개선하고... 한 번 세팅하면 끝이 아니더라고요. 혹시 비슷한 경험 하신 분들 있으신가요? 특히 대규모 문서 처리할 때 효율적인 청킹 전략이나 검색 성능 높이는 팁이 있으면 궁금합니다.