프로덕션용 고성능 RAG 애플리케이션 구축하기
프로덕션용 고성능 RAG 애플리케이션 구축하기
RAG 애플리케이션 프로토타입은 쉽지만, 성능과 견고성, 큰 지식 코퍼스에 대한 확장성을 갖추기는 어려워요. 검색과 생성을 최적화해 더 복잡한 데이터셋에서 질문에 정확히 답하는 방법을 배워봅시다.
출처: 문서
본문
RAG 애플리케이션을 프로토타이핑하는 것은 쉽지만, 성능과 견고성, 큰 지식 코퍼스로의 확장성을 갖추는 것은 어렵습니다.
이 가이드에는 RAG 워크플로의 성능을 개선하기 위한 다양한 팁과 요령이 포함되어 있습니다. 먼저 몇 가지 일반적인 기법을 개략적으로 설명합니다. 가장 직관적인 것부터 가장 어려운 것 순으로 느슨하게 정렬했습니다. 그런 다음 각 기법, 해결하는 사용 사례, 그리고 LlamaIndex로 구현하는 방법을 더 깊이 다룹니다.
최종 목표는 검색과 생성 성능을 최적화해 더 복잡한 데이터셋에 걸쳐 더 많은 쿼리에 정확하게, 그리고 환각 없이 답하는 것입니다.
프로덕션급 RAG 구축을 위한 일반 기법
프로덕션급 RAG 구축을 위한 주요 고려사항은 다음과 같습니다.
- 검색에 사용하는 청크와 합성에 사용하는 청크 분리하기
- 더 큰 문서 세트를 위한 구조화된 검색
- 태스크에 따라 청크를 동적으로 검색하기
- 정밀도를 위해 검색된 노드 리랭킹하기
- 컨텍스트 임베딩 최적화하기
이 내용과 더 많은 것을 Production RAG 웨비나에서 다뤘습니다. 더 요약된 내용은 이 트윗 스레드를 확인하세요.
검색에 사용하는 청크와 합성에 사용하는 청크 분리하기
더 나은 검색을 위한 핵심 기법은 검색에 사용하는 청크를 합성에 사용하는 청크와 분리하는 것입니다.
동기
검색에 최적적인 청크 표현은 합성에 사용하는 최적의 고려사항과 다를 수 있습니다. 예를 들어 원시 텍스트 청크에는 쿼리가 주어졌을 때 LLM이 더 상세한 답변을 합성하는 데 필요한 세부 정보가 포함되어 있을 수 있습니다. 그러나 임베딩 표현을 편향시킬 수 있는 필러 단어/정보가 포함되어 있거나, 전역 컨텍스트가 부족해 관련 쿼리가 들어와도 전혀 검색되지 않을 수 있습니다.
핵심 기법
이 아이디어를 활용하는 두 가지 주요 방법이 있습니다.
1. 문서 요약을 임베딩하고, 문서와 연관된 청크로 연결한다.
이는 (관련 없는 문서에 있을 수 있는) 청크를 직접 검색하기보다, 높은 수준에서 관련 문서를 먼저 검색하는 데 도움이 될 수 있습니다.
자료:
2. 문장을 임베딩한 뒤, 그 문장 주변의 윈도우로 연결한다.
이를 통해 관련 컨텍스트를 더 세밀하게 검색할 수 있고(거대한 청크를 임베딩하면 "중간 유실(lost in the middle)" 문제가 생김), LLM 합성에 충분한 컨텍스트도 보장합니다.
자료:
더 큰 문서 세트를 위한 구조화된 검색
동기
표준 RAG 스택(top-k 검색 + 기본 텍스트 분할)의 큰 문제는 문서 수가 늘어날수록 잘 작동하지 않는다는 것입니다. 예를 들어 100개의 서로 다른 PDF가 있다면 말이죠. 이런 설정에서 쿼리가 주어지면 더 정밀한 검색을 위해 구조화된 정보를 사용하고 싶을 수 있습니다. 예를 들어 두 개의 PDF에만 관련된 질문을 한다면, 청크의 원시 임베딩 유사도 너머로 그 두 PDF가 반환되도록 구조화된 정보를 사용하는 것입니다.
핵심 기법
프로덕션 품질의 RAG 시스템을 위한 더 구조화된 태깅/검색을 수행하는 몇 가지 방법이 있으며, 각각 장단점이 있습니다.
1. 메타데이터 필터 + 자동 검색 (Auto Retrieval) 각 문서에 메타데이터를 태깅한 뒤 벡터 데이터베이스에 저장합니다. 추론 시점에 LLM을 사용해 시맨틱 쿼리 문자열에 더해 벡터 db를 쿼리할 올바른 메타데이터 필터를 추론합니다.
- 장점 ✅: 주요 벡터 db에서 지원됩니다. 여러 차원으로 문서를 필터링할 수 있습니다.
- 단점 🚫: 올바른 태그를 정의하기 어려울 수 있습니다. 태그가 더 정밀한 검색에 필요한 충분한 관련 정보를 담지 못할 수 있습니다. 또한 태그는 문서 수준의 키워드 검색을 나타내므로 시맨틱 조회가 불가능합니다.
자료:
2. 문서 계층(요약 -> 원시 청크) 저장 + 재귀 검색 (Recursive Retrieval) 문서 요약을 임베딩하고 문서별로 청크에 매핑합니다. 청크 수준보다 먼저 문서 수준에서 가져옵니다.
- 장점 ✅: 문서 수준에서 시맨틱 조회가 가능합니다.
- 단점 🚫: 구조화된 태그로 키워드 조회가 불가능합니다(시맨틱 검색보다 더 정밀할 수 있음). 또한 요약을 자동 생성하는 데 비용이 들 수 있습니다.
자료
태스크에 따라 청크를 동적으로 검색하기
동기
RAG는 top-k 유사도가 최적화된 특정 사실에 대한 질문-답변만을 위한 것이 아닙니다. 사용자가 물을 수 있는 다양한 범위의 쿼리가 있습니다. "2023년 이 회사의 D&I 이니셔티브에 대해 알려줘" 또는 "화자가 Google에서 보낸 시간 동안 무엇을 했나요" 같은 특정 사실에 대해 묻는 쿼리는 순진한 RAG 스택으로 처리됩니다. 그러나 쿼리에는 "이 문서의 높은 수준 개요를 줄 수 있나요" 같은 요약이나 "X와 Y를 비교/대조해 줘" 같은 비교도 포함될 수 있습니다. 이러한 모든 사용 사례는 다른 검색 기법을 요구할 수 있습니다.
핵심 기법
LlamaIndex는 태스크별 검색을 돕는 몇 가지 핵심 추상화를 제공합니다. 여기에는 router 모듈과 data agent 모듈이 포함됩니다. 또한 일부 고급 쿼리 엔진 모듈과 구조화/비구조화 데이터를 결합하는 다른 모듈도 포함됩니다.
이러한 모듈을 사용해 질문-답변과 요약을 결합하거나 구조화 쿼리와 비구조화 쿼리를 결합할 수 있습니다.
핵심 모듈 자료
상세 가이드 자료
정밀도를 위해 검색된 노드 리랭킹하기
동기
밀집 리트리버와 하이브리드 리트리버는 재현율에 맞춰 튜닝됩니다. 쿼리와 시맨틱하게 가까운 후보를 반환하지만, top-1이 항상 가장 관련 있는 것은 아닙니다. 프로덕션에서 이것은 "검색은 맞아 보이는데 모델이 여전히 잘못된 질문에 답한다"로 나타납니다. 리랭커는 top-k 후보에 더 강력하고 느린 모델을 실행해 LLM에 도달하기 전에 재정렬함으로써 이를 해결합니다.
핵심 기법
더 넓은 후보 집합(예: similarity_top_k=10-20)을 검색한 뒤 더 작은 top_n(3~5)으로 리랭크합니다. 비용 순 옵션:
- 로컬 cross-encoder via
SentenceTransformerRerank, 권장 기본값. API 키가 없고 임베딩과 같은 인프라에서 실행됩니다. 속도를 위해cross-encoder/ms-marco-MiniLM-L6-v2, 더 강한 다국어 품질을 위해Qwen/Qwen3-Reranker-0.6B같은 모델을 사용하세요. - 호스팅 리랭커 API:
CohereRerank,JinaRerank,VoyageAIRerank,MixedbreadAIRerank. 연결이 간단하고 관리할 인프라가 없지만, 쿼리당 지연 시간과 비용이 추가됩니다. - LLM-as-reranker:
LLMRerank,RankGPTRerank,RankLLMRerank. 가장 강한 품질, 가장 비쌉니다. 정확도가 비용을 지배하는 프로덕션 흐름에 사용하세요.
의사결정 트리는 rerankers 개요를, 전체 통합 목록은 node postprocessors 가이드를 참고하세요.
컨텍스트 임베딩 최적화하기
동기
이는 위에서 "검색에 사용하는 청크와 합성에 사용하는 청크 분리"에서 설명한 동기와 관련이 있습니다. 특정 데이터 코퍼스에 대한 더 나은 검색을 위해 임베딩이 최적화되도록 하고 싶습니다. 사전 학습된 모델은 사용 사례와 관련된 데이터의 두드러진 특성을 포착하지 못할 수 있습니다.
핵심 기법
위에 나열된 몇 가지 기법 외에도 임베딩 모델을 파인튜닝해 볼 수 있습니다. 실제로 비구조화 텍스트 코퍼스에서 라벨 없이(label-free) 파인튜닝을 수행할 수 있습니다.
가이드를 확인하세요.