지연(Latency) vs 응답 품질

production RAG의 또 다른 균형은 하나의 쿼리가 걸리는 시간(latency) vs 응답 품질이다. retriever만 붙여도 latency가 늘고, re-ranking·agentic처럼 품질을 높이는 component를 더할수록 latency는 커진다. 이번 편은 이 trade-off와 균형 찾는 법을 정리한다.

 

 

1. 맥락에 따른 latency 중요도

latency의 중요도는 사용 맥락에 크게 좌우된다. e-commerce 고객은 느린 응답을 못 참으므로, 완벽한 추천을 포기하더라도 추천 서비스를 아주 낮은 latency로 최적화한다. 반대로 희귀 질환 진단을 돕는 RAG는 응답이 오래 걸려도 품질을 우선 최적화한다.

그림 1. latency 중요도는 맥락에 따라 — e-commerce는 속도 우선, 의료 진단은 품질 우선.

 

 

 

2. latency의 주된 원인, LLM 호출 (Transformer)

기억하기 쉬운 지침: latency의 거의 대부분이 트랜스포머 실행에서 온다. 따라서 가장 큰 원인은 LLM 호출이다. 검색도 약간(특히 일부 트랜스포머 기반 re-ranking) latency를 더하지만, 현대 벡터 DB는 매우 빠르고 확장성이 좋다. 그래서 latency를 줄이려면 core LLM부터 손대는 게 최선이다.

그림 2. latency의 범인 — 쿼리 처리·검색·생성 중 LLM 생성이 주 병목(트랜스포머).

 

 

 

3. LLM latency 줄이기 — 작은 모델 · router

효과적인 방법은 더 작은 LLM(또는 양자화 모델)이다 — 같은 하드웨어·메모리라면 항상 더 빠르다. 또 작은 router LLM을 둬, 프롬프트를 보고 작은/큰 모델 중 적합한 쪽을 고르게 한다. 복잡한 추론이 필요하면 큰 모델로, 단순한 쿼리는 작고 빠른 모델로 보낸다 — 단순한 프롬프트의 latency는 낮게 유지하고 정말 필요한 프롬프트에서만 latency가 오르게 한다.

그림 3. LLM latency 기법 — 작은/양자화 모델, router LLM으로 쿼리별 모델 선택.

 

 

 

4. 캐싱 (Caching)

비슷한 프롬프트를 자주 받는 시스템은 캐싱이 도움이 된다. 자주 들어오는 프롬프트–응답 캐시를 유지하고, 새 프롬프트가 오면 캐시 항목과 유사도를 빠르게 계산해 충분히 가까운 것이 있으면 느린 생성을 완전히 건너뛰고 캐시 응답을 즉시 반환한다(direct caching). 어느 정도 개인화도 원한다면, 캐시 응답과 사용자 프롬프트를 작고 빠른 LLM에 넣어 프롬프트에 더 맞게 조금 다듬는다(personalized caching).

그림 4. 캐싱 — 유사 프롬프트는 캐시 응답 즉시 반환(direct), 필요 시 작은 LLM으로 개인화(personalized).

 

 

 

5. 다른 트랜스포머 component 정리

core LLM을 최적화했다면, 다음은 파이프라인의 다른 트랜스포머 기반 component — query rewriter·re-ranker·router LLM 등이다. 각각 중요한 역할을 하지만 latency도 더한다. 조언은 각 component가 더하는 latency와 제공하는 품질 이득을 모두 측정하라는 것 — 예컨대 query rewriter에서 이득이 적다면 제거한다.

그림 5. 각 트랜스포머 component의 latency vs 품질 이득을 측정해, 이득이 없으면 제거한다.

 

 

 

6. 검색 latency 줄이기

생성이 보통 최대 원인이지만, retriever latency도 줄일 수 있다. binary 양자화 임베딩을 쓰면 벡터 거리 계산이 단순해져 검색이 빨라진다. 또 큰 DB를 여러 인스턴스로 sharding하면(특히 아주 클 때) 검색 latency가 준다. 이는 모든 DB의 일반적 기법이며 대부분의 벡터 DB가 도구를 제공한다.

그림 6. 검색 latency — binary 양자화 임베딩·DB sharding·provider 도구로 줄인다.

 

순서. 거의 항상 latency vs 품질 trade-off가 있다. ① 시스템이 감당 가능한 latency를 먼저 이해하고, ② 줄여야 하면 core LLM → 다른 트랜스포머/LLM feature → 파이프라인의 나머지 component 순으로 다룬다. 관측성이 있으면 변경의 영향을 보며 필요한 수준까지 반복적으로 latency를 줄일 수 있다.

 

다음 글에서는 production RAG의 또 다른 필수 축 — 보안(Security) — 을 다룬다.