Redis 시맨틱 캐시

Redis 시맨틱 캐시 (Semantic cache)

바이트 단위로 동일한 쿼리가 아니라 의미적으로 유사한 쿼리에 대해 LLM 응답을 재사용해 토큰 비용을 줄이고 대기 시간을 낮추며 검증된 답변을 사용자·세션 간 공유하는 캐시 패턴입니다. 캐시 항목이 prompt + 임베딩 + 응답 + 메타데이터를 보관하고, Redis Search 벡터 인덱스로 유사도 KNN 조회를 수행합니다.

출처: 공식문서 — Redis semantic cache

언제 Redis를 시맨틱 캐시로 쓰는가

바이트 단위 동일이 아닌 의미적으로 유사한 쿼리에 대해 LLM 응답을 재사용해야 할 때 사용합니다. 의역·근사 중복 질문이 전체 embed-retrieve-generate 파이프라인을 건너뛰고 수십 밀리초 안에 이전에 검증된 답변을 반환하게 합니다.

왜 이 문제가 어려운가

LLM에 도달하는 모든 반복·의역 질문은 임베딩·검색·생성 전체 파이프라인을 촉발해 캐시 조회 대비 쿼리당 비용을 10~100배 끌어올리고 P95 대기 시간을 수 초대로 밀어냅니다. 대안의 단점:

  • 전통적인 정확 매치 캐시(문자열 키 → 응답): 쿼리가 바이트 단위 동일할 때만 히트 — "What's your return policy?" vs "How do I return an item?" 같은 근사 중복을 놓침. 바로 FAQ 스타일 워크로드를 지배하는 쿼리들입니다.
  • 독립 벡터 데이터베이스: 유사한 과거 쿼리는 찾을 수 있지만 본질적으로 캐싱 문제인 것에 운영 오버헤드를 추가하고, 대부분 일급 TTL 관리·퇴출·메타데이터 필터링이 부족 — 캐시가 변동 속에서 정확성을 유지하려면 필요한 기능입니다.
  • 캐시 생략 + 모델 제공자 프롬프트 캐싱: 반복 prefix를 할인하지만 매 호출마다 모델을 끝까지 실행해, 대기 시간 문제와 사용자 간 전체 응답 재사용은 해결하지 못함

핵심 어려움은 임계값 튜닝입니다. 너무 느슨하면 틀린 답변을 서빙하고, 너무 빡빡하면 히트율이 붕괴됩니다. 효과적인 시맨틱 캐싱은 소프트 유사도 매칭과 하드 메타데이터 경계(테넌트, 로케일, 모델 버전, 안전 플래그)를 결합해 재사용이 잘 정의된 한도 안에 머물게 합니다.

이 패턴은 RAG 벡터 검색용 Redis 사용과 다릅니다. 시맨틱 캐싱은 완전한 LLM 응답(문서 청크가 아님)을 저장하고, 히트 시 검색된 컨텍스트를 LLM에 먹이는 게 아니라 LLM 호출 자체를 건너뛰는 것이 목표입니다.

Redis 솔루션에서 기대할 수 있는 것

  • 의역·근사 중복 쿼리에 수 초대의 LLM 왕복 대신 수십 밀리초로 캐시된 답변 반환
  • 반복 쿼리 패턴(FAQ 봇, 헬프데스크, 내부 지식 어시스턴트)에서 측정 가능한 품질 저하 없이 LLM 토큰 지출 30% 이상 절감
  • 테넌트·로케일·모델 버전별로 캐시된 답변 스코프 — 재사용을 정의된 경계 안에, 유사도 쿼리 안에서(앱 코드가 아닌) 적용
  • 오래된 답변 자동 만료 + 메모리 압박 시 콜드 항목 퇴출 — 수동 정리 없이
  • 비작위(non-authoritative)이고 언제든 재구축 가능한 캐시로, 검증된 고품질 답변을 사용자·세션·채널 간 공유
  • 별도 벡터 DB·캐시 서비스 프로비저닝 없이 기존 Redis 배포에 시맨틱 캐시 추가 — 같은 인스턴스의 추가 인덱스·키 패턴일 뿐

Redis가 이 솔루션을 어떻게 지원하는가

실제로 각 캐시 항목은 prompt, 임베딩 벡터, LLM 응답, 메타데이터 필드(테넌트, 로케일, 모델 버전, 안전 플래그)를 보관하는 단일 Hash 또는 JSON 문서입니다. Redis Search 인덱스가 임베딩 필드를 메타데이터 필드와 함께 커버합니다. 그래서 단일 FT.SEARCH 호출이 캐시된 prompt에 대해 KNN을 수행하며, 같은 패스에서 TAG·NUMERIC 사전 필터를 적용합니다. 구성된 거리 임계값을 넘는 히트 시 애플리케이션이 캐시된 응답을 직접 서빙하고, miss 시 LLM을 실행해 새 prompt·응답·메타데이터를 TTL과 함께 같은 키 패턴에 씁니다.

  • Hashes/JSON이 prompt·임베딩·응답·메타데이터를 한 키 아래에 저장 — 캐시 히트 시 애플리케이션이 필요한 모든 것을 한 왕복에 반환
  • Redis Search + HNSW 벡터 인덱스가 구성 가능한 유사도 임계값 위의 가장 가까운 캐시 prompt를 서브 밀리초에 찾고, 같은 FT.SEARCH가 TAG·NUMERIC 필터를 적용해 테넌트 격리·네임스페이스 스코프를 앱 로직이 아닌 쿼리 안에서 처리
  • EXPIRE가 각 캐시 항목에 TTL 설정 — 오래된 답변이 수동 정리 없이 사라져 캐시를 기반 지식과 정렬
  • DB 수준 eviction 정책(LRU/LFU)이 압박 시 메모리 경계 + 콜드 항목 자동 퇴출 — prompt 분포가 바뀌어도 캐시가 예산 안에 유지
  • 메모리의 서브 밀리초 읽기·쓰기로 세션·레이트 리밋·RAG 검색을 이미 처리하는 같은 Redis 인스턴스에 한계 비용 0으로 탑승

에코시스템

더 알아보기 (Learn more)

  • LLM 호출 앞에 놓는 Redis 시맨틱 캐시를 직접 만드는 코드 예제: redis-py, node-redis, go-redis, redis-rs, NRedisStack(C#), Jedis, Lettuce, Predis, redis-rb — 들어오는 prompt 임베딩, 테넌트·로케일 필터의 임계값 KNN, 히트 시 캐시 응답 서빙, miss 시 LLM 호출 + TTL 재기록 데모.
  • Redis Search·Query — 벡터·하이브리드 검색 심화.
  • Redis 만료·퇴출 정책 — 캐시 메모리 한도 관리.