LLM 캐싱, 정확히 일치 vs 의미 기반 — 적중률만 믿으면 안 되는 이유

LLM API 호출 비용을 줄이려고 캐싱을 도입한 경험담이다. 먼저 정확 일치(exact-match) 캐싱을 썼다. 요청 전체를 해시로 만들어 모델, 메시지, 파라미터가 완전히 같을 때만 캐시를 사용하는 방식이다. 한 글자만 달라도 캐시가 적중하지 않아 안전하지만, 실제 사용자 질문에는 거의 무용지물이었다.

예를 들어 "비밀번호를 어떻게 재설정하나요?", "비밀번호를 잊어버렸는데 어떻게 다시 들어가나요?", "비밀번호를 잃어버려서 로그인이 안 돼요"는 사람이 보기엔 같은 의도지만 문자열은 전혀 달라서 해시 기반 캐시는 이런 경우를 거의 다 놓쳤다. 그래서 의미 기반(semantic) 캐싱을 시도했다. 프롬프트를 임베딩(embedding, 텍스트를 숫자 벡터로 바꾼 것)으로 변환하고, 벡터 공간에서 가까운 것을 찾아 캐시로 쓰는 방식이다. 적중률 그래프만 보면 훨씬 좋아 보였다.

하지만 실제로 어떤 프롬프트 쌍이 매칭됐는지 하나하나 확인해보니, 의미상 비슷해 보이지만 실제로는 다른 질문에 엉뚱한 답을 재사용하는 '근접 오매칭' 사례들이 있었다. 결국 두 방식을 함께 쓰되, 적중률이 올라간다고 해서 그 자체로 신뢰하지 않고 실제 매칭된 프롬프트 쌍을 직접 읽어보는 검증 과정을 유지하고 있다.