RAG 속도를 50% 높인 엔지니어링 방법

RAG는 LLM의 답변을 대규모 지식 베이스에 기반해 정확도를 높여 AI 에이전트의 성능을 개선합니다. 전체 지식 베이스를 LLM에 전달하는 대신, RAG는 쿼리를 임베딩하고 가장 관련성 높은 정보를 찾아 모델에 컨텍스트로 제공합니다. 저희 시스템에서는 먼저 쿼리 리라이팅 단계를 추가해, 대화 이력을 간결하고 독립적인 쿼리로 정리한 뒤 검색을 진행합니다.

지식 베이스가 아주 작을 때는 모든 정보를 프롬프트에 직접 넣는 것이 더 간단할 수 있습니다. 하지만 지식 베이스가 커지면 RAG가 필수적이며, 모델이 과부하되지 않으면서도 정확한 답변을 유지할 수 있습니다.

많은 시스템이 RAG를 외부 도구로 처리하지만, 저희는 요청 파이프라인에 직접 내장해 모든 쿼리에 적용하고 있습니다. 이는 일관된 정확도를 보장하지만, 동시에 레이턴시 위험도 발생시킵니다.

쿼리 리라이팅이 속도를 늦춘 이유

대부분의 사용자 요청은 이전 대화 내용을 참조하기 때문에, 시스템은 대화 이력을 간결하고 독립적인 쿼리로 정리해야 합니다.

예를 들어:

• 사용자가 이렇게 질문하면: “우리의 피크 트래픽 패턴에 따라 그 한도를 맞춤 설정할 수 있나요?”
• 시스템은 이를 다음과 같이 리라이팅합니다: “엔터프라이즈 요금제의 API 속도 제한을 특정 트래픽 패턴에 맞게 맞춤 설정할 수 있나요?”

이렇게 리라이팅하면 “그 한도”와 같은 모호한 표현이 검색 시스템이 활용할 수 있는 명확한 쿼리로 바뀌어, 최종 답변의 컨텍스트와 정확도가 높아집니다. 하지만 외부에 호스팅된 단일 LLM에 의존하면 속도와 가용성에 크게 영향을 받게 됩니다. 이 단계만으로도 RAG 레이턴시의 80% 이상을 차지했습니다.

모델 레이싱으로 해결한 방법

쿼리 리라이팅을 레이스 방식으로 재설계했습니다:

• 여러 모델을 병렬로 실행. 각 쿼리는 여러 모델에 동시에 전달되며, 여기에는 자체 호스팅한 Qwen 3-4B와 3-30B-A3B 모델도 포함됩니다. 가장 먼저 유효한 답변을 내놓는 모델이 선택됩니다.
• 대화 흐름을 유지하는 폴백. 1초 이내에 어떤 모델도 응답하지 않으면, 사용자의 원본 메시지를 그대로 사용합니다. 다소 부정확할 수 있지만, 대화가 멈추지 않고 자연스럽게 이어집니다.

성능에 미친 영향

이 새로운 아키텍처로 RAG의 중간 레이턴시가 326ms에서 155ms로 절반 가까이 줄었습니다. 많은 시스템이 RAG를 외부 도구로 선택적으로 실행하는 것과 달리, 저희는 모든 쿼리에 적용합니다. 중간 레이턴시가 155ms로 낮아져 오버헤드는 거의 없습니다.

레이턴시 변화:

• 중간값: 326ms → 155ms
• p75: 436ms → 250ms
• p95: 629ms → 426ms

이 아키텍처는 모델 성능 변동에도 시스템이 더 안정적으로 동작하도록 만들었습니다. 외부 호스팅 모델은 피크 시간대에 느려질 수 있지만, 내부 모델은 비교적 일관된 속도를 유지합니다. 여러 모델을 레이싱하면 이런 변동성이 줄어들어, 예측 불가능한 개별 모델 성능이 더 안정적인 시스템 동작으로 바뀝니다.

예를 들어, 지난달 LLM 공급업체 중 한 곳에서 장애가 발생했을 때도 자체 호스팅 모델로 대화가 끊김 없이 이어졌습니다. 이미 다른 서비스 운영을 위해 이 인프라를 사용하고 있기 때문에 추가적인 컴퓨팅 비용도 거의 들지 않습니다.

이 방식이 중요한 이유

200ms 이하의 RAG 쿼리 리라이팅은 대화형 에이전트의 주요 병목을 제거합니다. 그 결과, 대규모 엔터프라이즈 지식 베이스에서도 컨텍스트를 인식하고 실시간으로 동작하는 시스템을 구현할 수 있습니다. 검색 오버헤드가 거의 사라지면서, 대화형 에이전트는 성능 저하 없이 확장할 수 있습니다.