RAG 파이프라인을 영구적 KV 캐시로 대체해 본 경험 공유
We replaced our RAG pipeline with persistent KV cache. It works. Here’s what we found.
핵심 요약
RAG의 복잡한 유지보수 문제를 해결하기 위해 전체 문서를 KV 캐시로 처리하는 방식을 실험하고 그 결과를 공유함.
- RAG 유지보수 — 임베딩, 청킹, 검색 등 복잡한 파이프라인 관리의 어려움 해결
- KV 캐시 활용 — 전체 문서를 컨텍스트에 로드하고 KV 상태를 영구 캐싱하여 검색 단계 제거
- 성능 및 효율성 — 검색 누락 방지로 답변 품질 향상 및 문서 업데이트 속도 대폭 개선
- 현재 한계점 — 약 120k 토큰 제한으로 인해 대규모 데이터셋에는 부적합
저희는 한동안 프로덕션 환경에서 RAG를 운영해 왔습니다. 작동은 잘 됐지만 유지보수가 끊임없는 세금처럼 느껴졌습니다. 데이터가 바뀔 때마다 재임베딩해야 하고, 청킹 전략을 튜닝하고, 검색 실패를 디버깅하고, 벡터 데이터베이스를 관리해야 했습니다. 움직이는 모든 부품이 고장 날 수 있는 잠재적 위험 요소였습니다.
그래서 실험을 하나 해봤습니다. 문서를 청킹하고 임베딩하는 대신, 전체 문서를 컨텍스트에 로드하고 KV 상태를 영구적으로 캐싱한 뒤 모든 쿼리에 그 캐시를 재사용했습니다.
벡터 데이터베이스도, 임베딩 파이프라인도, 검색 단계도 없습니다. 그냥 모델에 전체 문서 컨텍스트를 미리 따뜻하게 준비해두는 방식입니다. 결과는 다음과 같습니다.
• 답변 품질이 눈에 띄게 좋아졌습니다. 검색 누락이나 잘못된 청크가 없고 항상 전체 컨텍스트를 참조합니다.
• 업데이트 속도가 훨씬 빨라졌습니다. 문서를 수정하고 캐시를 재생성하면 몇 분 만에 끝납니다. 재인덱싱에 몇 시간씩 걸리던 것과 비교하면 엄청난 차이입니다.
• 운영 복잡도가 크게 줄었습니다. 유지보수할 파이프라인이나 검색 품질을 모니터링할 필요가 없습니다.
• 현재 제한은 약 120k 토큰 정도입니다. 대부분의 비즈니스 문서에는 적합하지만, 방대한 데이터셋에는 무리입니다.
한계점은 다음과 같습니다:
• 컨텍스트 윈도우보다 큰 문서는 여전히 문제입니다.
• 매우 큰 문서 컬렉션은 다른 접근 방식이 필요합니다.
• 첫 로드 시 캐시가 차가우면 시간이 걸리지만, 워밍업된 쿼리는 빠릅니다.
다른 분들도 시도해봤는지 궁금합니다. 특히 다음 내용이 궁금합니다:
• 사용 사례가 컨텍스트 윈도우 제한과 어떻게 매핑되는지
• 검색 품질이 RAG의 가장 큰 고충이었는지, 아니면 다른 문제였는지
• RAG 파이프라인을 완전히 대체하려면 무엇이 필요한지
실제 워크로드를 가진 분들을 위해 작은 베타를 열었습니다. LangChain을 사용 중이고 관심 있다면 DM이나 댓글 남겨주세요.
질문 있으면 언제든 환영합니다.
