질문의 뜻이 예전 질문과 비슷하면 LLM을 다시 부르지 않고 저장해 둔 답을 돌려주는 캐시로, "환불 어떻게 해요?"와 "환불 절차 알려줘"처럼 문장이 달라도 같은 답을 다시 쓴다. 입력 문자열이 똑같아야 하는 일반 캐시와 달리 뜻으로 비교하므로, FAQ처럼 비슷한 질문이 자주 반복되는 서비스에서 비용과 응답 시간을 줄일 때 쓴다.
| 방식 | 재사용하는 것 | 적용 조건 |
|---|---|---|
| 일반 캐시 | 답변 전체 | 입력 문자열이 완전히 같을 때 |
| 시맨틱 캐시 | 답변 전체 | 뜻이 충분히 비슷할 때 |
| 프롬프트 캐싱 | 입력 앞부분 처리 결과 | 앞부분이 똑같을 때 (답은 새로 생성) |
질문을 임베딩(뜻을 담은 숫자 벡터)으로 바꾸고, 저장된 과거 질문들과 코사인 유사도를 잰다. 기준값을 넘는 질문이 있으면 그 답을 돌려주고, 없으면 LLM을 부른 뒤 질문과 답을 함께 저장한다.
| 순서 | 하는 일 |
|---|---|
| 1 | 새 질문을 임베딩으로 변환 |
| 2 | 벡터 저장소에서 가장 가까운 과거 질문 검색 |
| 3 | 유사도가 임계값 이상이면 캐시 답 반환 |
| 4 | 미만이면 LLM 호출 후 결과 저장 |
직접 만들 필요는 없다. GPTCache 같은 오픈소스 라이브러리나 Redis, Azure Cosmos DB처럼 벡터 검색을 지원하는 저장소의 시맨틱 캐시 기능을 LLM 호출 앞단에 끼우면 된다. 정할 것은 임베딩 모델, 유사도 임계값, 캐시 유지 기간(TTL) 정도다.
임계값을 높이면(예: 0.95) 거의 같은 질문만 걸려 안전하지만 캐시 적중이 적다. 낮추면 적중은 늘지만 엉뚱한 답이 나갈 위험이 커진다. 높게 시작해 실제 로그에서 잘못 걸린 사례를 확인하며 조금씩 내리는 게 무난하다.
| 상황 | 판단 | 이유 |
|---|---|---|
| 고객지원 FAQ, 사내 규정 문의 | 적합 | 같은 질문이 반복되고 답이 고정됨 |
| 실시간 정보 (재고·가격·날씨) | 주의 | TTL을 짧게 둬야 함 |
| 사용자별 주문·계정 조회 | 부적합 | 다른 사람의 답이 나갈 수 있음 |
| 창작, 코드 생성 | 부적합 | 맥락에 따라 답이 달라야 함 |
캐시는 한 번 저장된 답을 검증 없이 계속 내보낸다. 처음 답이 틀렸거나 원본 정보가 바뀌면 오류가 반복되므로, TTL을 두고 원본 문서가 바뀌면 관련 캐시를 지워야 한다.
"환불 가능해?"와 "환불 불가능해?"처럼 단어 하나로 뜻이 뒤집히는 질문도 임베딩은 가깝게 나올 수 있다. 앞선 대화에 따라 뜻이 달라지는 질문은 사용자·세션별로 캐시를 나누거나 아예 캐시하지 않는다.
가장 흔한 방식은 질문이 반복되는 챗봇의 LLM 호출 앞단에 두는 것이다. 자주 나오는 질문은 캐시가 바로 답하고, 처음 보는 질문만 LLM으로 넘어가서 같은 답을 만드는 데 비용이 다시 들지 않는다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 고객지원 챗봇 | 배송·환불·가입 같은 반복 문의는 캐시로 바로 답하고, 주문·계정 조회는 캐시를 건너뛴다 |
| 사내 규정·문서 Q&A | 휴가·경비 규정처럼 답이 고정된 질문을 캐시하고, 문서가 바뀌면 관련 캐시를 지운다 |
| 문서 검색 기반 답변(RAG) | 비슷한 질문이 오면 검색과 답변 생성을 둘 다 건너뛰어 응답을 빠르게 한다 |