Redis, RedisVL: 다시 써도 되는 답만 캐시하기

✎ 이 문서 수정하기 GitHub에서 수정

Redis는 key/value 기반 재사용과 상태 저장에, RedisVL은 벡터 검색과 의미 캐시에 쓸 수 있다. 질문이 비슷해도 같은 답을 재사용할 수 있는 것은 아니다.

Bookway의 캐시 범위

공개 배송, 반품 정책은 후보가 될 수 있지만, 내 주문, 환불, 재고 같은 개인화, 실시간, 거래 결과는 기본적으로 완성 답변 캐시에서 제외한다. 정책에도 국가, 회원 유형, 구매일 조건이 있으면 그 범위를 키와 검색 필터에 포함한다.

인증, 허용 범위 결정
  → cache scope 생성
  → 동일 scope 안에서만 정확/의미 검색
  → 적중 답의 source, 유효 시점, release 검사
  → 통과하면 반환
  → 미적중이면 RAG 후 저장 가능성 판단

먼저 정확 캐시의 키를 고정하기

아래는 외부 Redis 없이 실행되는 키 설계 예제이다. 해시는 식별에 사용하며 암호화나 익명화의 보증이 아니다.

import hashlib
import json

scope = {
    "tenant": "bookway",
    "access_scope": "public-policy",
    "release": "help-r8",
    "policy": "policy-v3",
    "locale": "ko-KR",
    "question": "Synthetic return-policy question",
}
encoded = json.dumps(
    scope, sort_keys=True, ensure_ascii=False, separators=(",", ":")
).encode("utf-8")
key = "bookway:answer:" + hashlib.sha256(encoded).hexdigest()
print(key)

실제 앱은 이 키에 검증된 답, source, 생성 시점, 유효 기한을 함께 저장하고 TTL을 적용한다. Redis 연결 오류는 cache miss와 구분해 계측한다. 우회 생성은 권한, 예산이 허용한 정책일 때만 사용하고 비용 폭증에 대비한다.

RedisVL 의미 캐시를 추가하는 절차

벡터 검색을 지원하는 Redis 배포와 RedisVL, embedding provider를 준비한다. SemanticCache의 이름, vectorizer, distance threshold, TTL, filter schema를 고정하고, 저장과 조회 양쪽에 같은 권한, release 필터를 강제한다. 이름만 테넌트별로 만들면 세부 ACL까지 해결되는 것은 아니다.

처음에는 정확 캐시와 미적중 RAG를 기준선으로 둔다. “종이책을 반품할 수 있나요?”와 “전자책을 반품할 수 있나요?”처럼 표현은 비슷하고 조건은 다른 질문으로 오적중을 평가한 뒤 threshold를 정한다. cosine 거리의 낮은 값과 정답 확률은 다르다.

무효화와 비용

정책, 프롬프트, 모델, 검색 설정이 바뀌면 namespace를 새 release로 분리하거나 명시적으로 무효화한다. TTL만 짧게 둔다고 정책 변경 직후의 오류가 없어지지는 않는다. 삭제된 source를 참조한 답도 제거한다.

관측은 hit율뿐 아니라 오적중, 허용 범위 위반, 절약한 생성 비용, embedding 조회 비용, p95를 본다. vLLM의 KV cache, embedding cache, 완성 답변 cache는 다른 계층이며 같은 무효화 규칙을 쓰지 않는다.

RedisVL 공식 저장소 / 공식 의미 캐시 가이드 / 출시 버전과 무효화