Semantic Caching Analysis

Semantic Caching 심층 분석

의미 기반 응답 재사용 · 임베딩 유사도 · 임계값 트레이드오프 · GPTCache · 다층 캐시 · 프리픽스 캐싱과의 대비

시맨틱 캐싱(semantic caching)은 의미가 비슷한 질문에 대해 이전에 생성한 응답 자체를 재사용해 LLM 호출을 줄이는 기법입니다. 정확한 문자열이 일치해야 하는 기존 캐시와 달리, 질문을 임베딩해 의미적 유사도로 매칭하므로 표현만 다른 같은 질문("환불 정책이 뭔가요?" vs "어떻게 반품하나요?")을 한 번의 생성으로 처리합니다.

다만 프리픽스 캐싱이 정확히 같은 토큰의 KV를 무손실 재사용하는 것과 달리, 시맨틱 캐싱은 근사적이라 틀린 답을 반환할 위험이 있습니다. 그래서 임계값 관리, 무효화, 컨텍스트 분리가 핵심이며, FAQ·고객지원·반복 질의가 많은 워크로드에서 특히 유용합니다.

1. 핵심 아이디어 - 의미가 비슷한 질문의 응답을 재사용

프로덕션 LLM 서비스에서는 같은 의도의 질문이 표현만 바뀌어 반복됩니다. 순진하게는 매번 LLM을 호출해 같은 답을 다시 생성하지만, 그것은 낭비입니다. 시맨틱 캐싱은 질문의 의미가 충분히 비슷하면 저장된 응답을 그대로 반환합니다.

그림 1. 같은 의도·다른 표현 → 같은 답, 그리고 임베딩→유사도 검색→hit/miss 흐름

시맨틱 캐싱과 프리픽스 캐싱

• 동작 - 질문을 임베딩해 캐시된 질문 임베딩들과 코사인 유사도를 비교하고, 임계값을 넘으면 그 응답을 반환합니다. 캐시 히트 시 LLM을 아예 호출하지 않으므로 지연과 비용을 함께 줄입니다.

• 인프라 - RAG와 같은 구성요소(임베딩 모델 + 벡터 DB + ANN 검색)를 씁니다. GPTCache도 임베딩 함수, 데이터 저장소, 유사도 평가 모듈을 조합해 이런 흐름을 구성합니다.

• 프리픽스 캐싱과의 결정적 차이 - 프리픽스 캐싱은 정확히 같은 토큰의 KV를 재사용해 무손실이고 KV 레벨에서 동작합니다. 시맨틱 캐싱은 의미가 비슷한 질문의 응답을 재사용해 근사적이고 응답 레벨에서 동작합니다.

2. 동작 메커니즘 - 구성요소와 hit/miss 사이클

시맨틱 캐시는 애플리케이션과 LLM 사이에 위치합니다. 모든 질문이 먼저 캐시를 거치고, 충분히 유사한 항목이 있으면 응답을 반환하며, 없으면 LLM을 호출하고 그 결과를 캐시에 저장합니다.

그림 2. 캐시 미스/히트 사이클과 네 가지 구성요소

시맨틱 캐시 조회 (GPTCache 개념)

def query(q):
    e = embed(q)
    hit, score = vector_store.search(e)
    if score >= tau:
        return hit.response
    r = llm(q)
    vector_store.add(e, r)
    return r

네 가지 구성요소

• 임베딩 모델 - 질문을 의미를 담은 벡터로 변환합니다. 의미를 제대로 못 잡으면 검색이 노이즈가 되어 엉뚱한 응답을 반환하므로, 캐시 품질을 좌우하는 핵심입니다.

• 벡터 저장소 - 임베딩을 보관하고 ANN(HNSW 등)으로 빠른 유사도 검색을 합니다.

• 유사도 평가와 임계값 - 코사인 유사도가 임계값 τ 이상이면 히트로 판정합니다. GPTCache는 거리 기반, 모델 기반, 정확 일치형 유사도 평가를 조합할 수 있습니다.

• 캐시 저장소 - 질문-응답 쌍을 보관하고(Redis 등) 축출을 관리합니다. GPTCache와 Redis 기반 시맨틱 캐시가 대표적이며, 모듈식이라 각 요소를 교체할 수 있습니다.

3. 핵심 트레이드오프 - 유사도 임계값

시맨틱 캐싱의 모든 것은 유사도 임계값 τ로 귀결됩니다. 이 값이 절감과 위험 사이의 슬라이더이며, 프리픽스 캐싱과 가장 다른 지점이기도 합니다. GPTCache 소개 자료도 hit ratio, latency, recall을 함께 보며 이 균형을 맞춥니다.

그림 3. 임계값 슬라이더, 오탐 위험, 정밀도 vs 재현율

임계값의 양면

• τ가 낮으면 - hit율과 비용 절감은 올라가지만, 의미만 비슷하고 답은 달라야 할 질문에 같은 답을 반환하는 오탐(false positive)이 늘어납니다.

• τ가 높으면 - 정밀도(안전)는 올라가지만 패러프레이즈를 놓쳐 hit율이 떨어집니다(false negative, 사실상 정확 일치에 근접).

• 오탐이 가장 치명적 - 사용자는 '환불 정책'과 '환불 소요 기간'에 다른 답을 기대하므로, 틀린 답이 나가면 바로 알아챕니다. 그래서 고위험 FAQ는 정밀도를, 미스가 단지 비용인 검색형 질의는 재현율을 더 중시합니다.

4. 한계와 운영 - 무효화·컨텍스트·드리프트

시맨틱 캐시는 결정적 출력이 아니라 모델이 생성한 답을 저장하므로, 시간·맥락에 따라 유효성이 변합니다. 그래서 '설정하고 잊는' 방식이 아니라 지속적인 관리가 필요합니다.

그림 4. 네 가지 실패 모드와 무효화 전략

실패 모드

무효화 전략

• TTL(시간 만료) - 콘텐츠 수명에 맞춰 차등 설정합니다(뉴스 수시간, FAQ 수일 등).

• 이벤트 기반 - 원본 콘텐츠가 갱신되면 관련 캐시를 무효화합니다.

• staleness 탐지 - 주기적으로 재질의해 캐시된 답의 정확성을 점검합니다.

• 스코프 분리 - 시스템 프롬프트·모델·사용자 유형별로 캐시 버킷을 나눠 잘못된 교차 매칭을 막습니다. 확신이 낮은 항목은 캐시하지 않고 LLM을 호출해 우아한 저하를 택합니다.

5. 다층 캐시에서의 위치와 효과

그림 5. 다층 캐시(정확 해시→시맨틱→프리픽스→추론)와 보고된 효과

다층 캐시에서의 위치

프로덕션 서빙은 여러 캐시 계층을 둡니다. 요청은 정확 해시 매칭(바이트 동일) → 시맨틱 캐시(의미 유사·응답 재사용) → 프리픽스 캐시(KV 재사용) → 전체 추론의 순으로 거치며, 위 계층에서 막을수록 절감이 큽니다. 시맨틱 캐싱과 프리픽스 캐싱은 직교·상보적이어서, 함께 쌓으면 반복 트래픽을 단계적으로 흡수합니다.

보고된 효과

6. 장단점

장점

• 반복 질의가 많은 FAQ, 고객지원, 내부 지식 검색에서 LLM 호출 자체를 생략해 비용과 지연을 함께 줄일 수 있습니다.

• 정확 문자열 캐시보다 hit 범위가 넓어, 표현이 조금씩 다른 패러프레이즈 요청도 한 번의 응답으로 흡수할 수 있습니다.

• 임베딩, 벡터 저장소, Redis 같은 캐시 저장소를 조합하므로 RAG 인프라를 이미 운영하는 팀은 기존 구성요소를 재사용하기 쉽습니다.

단점

• 프리픽스 캐싱과 달리 근사적 판정이므로 false positive가 나면 아예 잘못된 답을 그대로 재사용할 수 있습니다.

• TTL, 이벤트 기반 무효화, 사용자/세션 스코프 분리, 임베딩 모델 버전 관리 같은 운영 규칙이 없으면 품질이 빠르게 흔들립니다.

• 미스가 나더라도 임베딩 생성과 벡터 검색 오버헤드는 남으므로, 반복성이 낮은 워크로드에서는 이득이 작을 수 있습니다.

7. 관련 기술

• GPTCache README: https://github.com/zilliztech/GPTCache
• Redis LangCache overview: https://redis.io/blog/what-is-semantic-caching/
• MeanCache paper: https://arxiv.org/abs/2403.02694

8. 핵심 정리

시맨틱 캐싱은 의미가 비슷한 질문의 응답을 재사용해 LLM 호출을 줄이는 근사적 기법입니다. GPTCache처럼 임베딩, 벡터 저장소, 유사도 평가, 캐시 저장소를 조합해 동작하며, 핵심 다이얼은 유사도 임계값 τ입니다.

프리픽스 캐싱과는 응답 vs KV, 근사 vs 무손실로 다르지만 반복 트래픽을 단계적으로 흡수한다는 점에서 상보적입니다. 다만 오답과 노후화, 개인화 충돌을 막기 위해 TTL, 이벤트 기반 무효화, 스코프 분리가 필요합니다.