Caching Structure

- 🧠 전체 구조 그림

사용자 Query
    │
    ▼
[1] 메모리 캐시 조회 (Fast, RAM)
    │ └─ Hit → 바로 응답
    │ └─ Miss → 디스크 캐시 조회
    ▼
[2] 디스크 캐시 조회 (sqlite or diskcache)
    │ └─ Hit → 바로 응답
    │ └─ Miss → 벡터DB 검색
    ▼
[3] VectorDB (Chroma/FAISS 등)
    │
    ▼
[4] Reranker (선택)  →  top-k 정제
    │
    ▼
[5] Prompt 조립
    │
    ▼
[6] LLM 호출 (ZeroGPU 느림 주의)
    │
    ▼
[7] 결과 저장
      ├─ 메모리 캐시 업데이트
      └─ 디스크 캐시 업데이트

- 📚 각 단계 설명

단계설명기술 스택 추천
1. 메모리 캐시 조회최근 사용한 검색어-결과를 RAM에서 바로 응답in-memory dict, cachetools
2. 디스크 캐시 조회오래된 결과는 디스크(SSD)에 저장하고 꺼내기sqlite3, diskcache, tinydb
3. VectorDB 검색실제 RAG 검색 (law_db, exam_db)chromadb, faiss
4. RerankerBGE-reranker로 top-k를 다시 정렬bge-reranker-base-ko
5. Prompt 조립Retrieved 문서들을 하나로 묶어 prompt로 만들기직접
6. LLM 호출ZeroGPU로 LLM 호출 (느리지만 정확)Gradio SDK, spaces.GPU
7. 캐시 업데이트생성된 답변을 메모리+디스크에 동시 업데이트dict + sqlite

- 🗺️ 전체 흐름 한눈에 요약

  • RAM 캐시 (0.01초 이내)
  • 디스크 캐시 (0.1초 이내)
  • 벡터DB 검색 + Rerank (1~2초)
  • LLM 호출 (5~20초, ZeroGPU)

캐시 성공률을 높이면 → LLM 호출을 최소화해서
속도 10배 빨라지고, 비용 절감도 가능해.

- 🔥 추가 심화

  • 메모리 캐시는 LRU(Least Recently Used) 알고리즘 적용 (최신 것 유지)
  • 디스크 캐시는 TTL(Time to Live)로 오래된 것 자동 삭제
  • 검색어를 해시(hash)해서 캐시 키(key)로 사용
  • 캐시는 Retrieval 결과 + 생성 답변 둘 다 저장할 수 있음

- ✨ 정리해서 요약하면

키워드설명
Memory CacheRAM에 질문-답변 저장 (초고속)
Disk CacheSQLite에 질문-답변 저장 (내구성)
VectorDBChromaDB에서 관련 법령/문제 검색
RerankerBGE로 유사도 높은 문서 재정렬
LLMPrompt 기반 문제 생성

📢 정말 중요한 핵심:
VectorDB 검색이 느리면 캐시가 1차 방어선이고,
LLM이 느리면 캐시가 2차 방어선이야.
이걸 잘 짜면 ZeroGPU 환경에서도 실사용 가능하게 만들어.

👉 원하면 바로 이 구조로 코드 스캐폴딩(템플릿) 만들어줄게.

질문:

  • Memory Cache는 어떤 라이브러리로 할까? (cachetools / built-in dict / fastapi-cache 등)
  • Disk Cache는 sqlite3 + custom? 아니면 diskcache 라이브러리?
    (추천은 diskcache야, 빠르고 간편해)

Was this page helpful?