Semantic Caching cho LLM: Tại sao con số 95% là ảo ảnh và dữ liệu thực tế nói gì?

Mặc dù các nhà cung cấp quảng cáo có thể giảm 90% chi phí nhờ Semantic Caching, dữ liệu thực tế sản nghiệp cho thấy tỷ lệ命中 thường chỉ dao động từ 20-45%. Bài viết phân tích cơ chế hoạt động, so sánh giữa Exact và Semantic Caching, và chỉ ra những use case thực sự hiệu quả để tối ưu hóa chi phí LLM.

Bạn vừa mở bảng điều khiển OpenAI vào buổi sáng và cảm thấy nặng nề. Con số lại cao hơn tháng trước. Lần nữa. Ai đó đã đề cập đến "semantic caching" — "chỉ cần cache các phản hồi, cắt giảm chi phí 90%". Vì thế, bạn bắt đầu tìm hiểu.

Các trang bán hàng đều nói một điều giống nhau: tỷ lệ命中 cache (cache hit rate) 95%, giảm 90% chi phí, phản hồi trong vài mili-giây. Nhưng khi bạn chạy số liệu trên lưu lượng truy cập của chính mình, thực tế lại hoàn toàn khác.

Bài viết này sẽ phân tích cách semantic caching thực sự hoạt động, các tỷ lệ命中 thực tế được công bố (không phải con số marketing), và những trường hợp sử dụng nào sẽ获益 — cũng như những trường hợp nào không.

Tóm tắt nhanh

Tỷ lệ命中 thực tế trong sản phẩm dao động từ 20-45%, không phải 90-95%. Con số 95% thực chất đề cập đến độ chính xác (accuracy) của các kết quả khớp cache, không phải tần suất命中.
Ngay cả tỷ lệ命中 20% cũng tiết kiệm được tiền thật — khoảng 1.000 USD/tháng trên hóa đơn 5.000 USD cho LLM — đồng thời giảm độ trễ từ 2-5 giây xuống dưới 5ms với các yêu cầu đã được cache.
Hãy bắt đầu với exact caching. Chỉ thêm semantic caching nếu sự cải thiện biên đáng kể để bù đắp cho sự phức tạp.

Exact Caching so với Semantic Caching: Hai vấn đề khác nhau

Trước khi đi sâu vào kiến trúc, sự phân biệt này rất quan trọng vì hầu hết các đội nên bắt đầu với exact caching và chỉ thêm semantic caching nếu exact caching một mình là chưa đủ.

Exact Caching (Cache chính xác)

Sử dụng thuật toán băm (hash) toàn bộ prompt (bao gồm tên mô hình, nhiệt độ và các tham số khác) với SHA-256. Nếu băm khớp với một yêu cầu đã lưu, hãy trả về phản hồi được cache. Không có sự mơ hồ nào — prompt là giống hệt nhau, nên phản hồi là hợp lệ.

cache_key = sha256(model + prompt + str(temperature) + str(max_tokens))
cached = redis.get(cache_key)
if cached:
    return cached  # <5ms, chi phí LLM bằng 0

response = call_llm(prompt)
redis.set(cache_key, response, ttl=3600)
return response

Ưu điểm: Không có dương tính giả (false positives). Tra cứu dưới mili-giây. Dễ thực hiện. Nhược điểm: Bỏ lỡ các bản sao được diễn đạt lại. "Làm thế nào để đặt lại mật khẩu của tôi?" và "trợ giúp đặt lại mật khẩu" là các băm khác nhau.

Exact caching một mình bắt được nhiều lưu lượng hơn bạn nghĩ. Ứng dụng sản phẩm trung bình gửi 15-30% yêu cầu giống hệt nhau — các đường ống tự động, thử lại và người dùng hỏi cùng một câu hỏi FAQ.

Semantic Caching (Cache ngữ nghĩa)

Tạo một vector nhúng (embedding) của prompt, so sánh nó thông qua độ tương đồng cosine với các nhúng đã lưu, và trả về phản hồi được cache nếu độ tương đồng vượt quá ngưỡng. Điều này bắt được các bản sao được diễn đạt lại.

embedding = embed_model.encode(prompt)  # ~2-5ms
matches = vector_db.search(embedding, threshold=0.92)
if matches:
    return matches[0].response  # <5ms tổng cộng

response = call_llm(prompt)
vector_db.upsert(embedding, response, ttl=3600)
return response

Ưu điểm: Bắt được các yêu cầu tương đồng về mặt ngữ nghĩa với cách diễn đạt khác nhau. Nhược điểm: Việc tạo embedding thêm 2-5ms. Có thể xảy ra dương tính giả. Việc tinh chỉnh ngưỡng (threshold) rất quan trọng và phụ thuộc vào trường hợp sử dụng.

Huyền thoại 95%: Số liệu thực tế nói gì

Tuyên bố "tỷ lệ命中 cache 95%" xuất hiện trên các trang marketing của nhà cung cấp. Dưới đây là những gì dữ liệu được công bố thực tế cho thấy:

Nguồn	Tỷ lệ命中	Bối cảnh	Loại
Portkey (sản phẩm)	~20%	Các trường hợp RAG, độ chính xác khớp 99%	Dữ liệu nhà cung cấp
Nền tảng EdTech (sản phẩm)	~45%	Hỏi đáp sinh viên — lặp lại cao	Nghiên cứu điển hình
GPT Semantic Cache (học thuật)	61-69%	Benchmark được kiểm soát, dữ liệu tuyển chọn	Giấy tờ nghiên cứu
Ước tính sản phẩm chung	30-40%	Lưu lượng hỗn hợp trên các trường hợp	Trung bình ngành
Chat mở (sản phẩm)	10-20%	Cuộc trò chuyện độc nhất, lặp lại thấp	Phạm vi quan sát

Con số 95%, khi bạn lần theo dấu vết, gần như luôn luôn đề cập đến độ chính xác của sự khớp (match accuracy) — nghĩa là 95% thời gian cache trả về một phản hồi, phản hồi đó là chính xác cho truy vấn. Không phải là 95% truy vấn命中 cache. Đây là hai chỉ số hoàn toàn khác nhau.

Phạm vi trung thực cho semantic caching trong sản phẩm: 20-45% tỷ lệ命中, tùy thuộc nhiều vào trường hợp sử dụng.

Tại sao các benchmark học thuật gây hiểu lầm: Các benchmark học thuật kiểm tra against các bộ dữ liệu được tuyển chọn nơi các câu hỏi tương tự được nhóm lại cố ý. Lưu lượng sản phẩm lộn xộn hơn nhiều — 60-70% truy vấn thực sự là độc nhất. Tỷ lệ命中 61-69% từ các bài báo nghiên cứu không thể tồn tại khi tiếp xúc với sự đa dạng của môi trường sản xuất.

Tỷ lệ命中 theo Use Case: Nơi Cache hoạt động (và không)

Use Case	Tỷ lệ命中 dự kiến	Tại sao
FAQ / Hỗ trợ khách hàng	40-60%	Người dùng hỏi cùng một câu hỏi theo những cách hơi khác nhau. Lặp lại cao, không gian câu trả lời có giới hạn.
Phân loại / Gán nhãn	50-70%	Các đường ống tự động thường gửi các đầu vào giống hệt hoặc gần giống hệt nhau.
Hỏi đáp cơ sở kiến thức nội bộ	30-45%	Nhân viên hỏi các câu hỏi tương tự về chính sách, quy trình, tài liệu.
RAG với truy xuất tài liệu	15-25%	Bối cảnh thay đổi theo từng truy vấn ngay cả khi câu hỏi tương tự.
Chat mở	10-20%	Các cuộc trò chuyện là độc nhất. Bối cảnh nhiều lượt làm cho mỗi yêu cầu trở nên khác nhau.
Tạo mã nguồn (Code gen)	5-15%	Độ cụ thể cao cho mỗi yêu cầu. Người dùng muốn các đầu ra đa dạng.

Mô hình: Không gian câu trả lời có giới hạn với các đầu vào lặp lại sẽ cache tốt. Các tác vụ mở, phụ thuộc bối cảnh hoặc sáng tạo thì không.

Vấn đề về Ngưỡng (Threshold): 0.85 so với 0.92 so với 0.98

Ngưỡng độ tương đồng cosine là cấu hình quan trọng nhất — và được thảo luận ít nhất — trong semantic caching. Đó là nút vặn xác định xem cache của bạn có hữu ích hay nguy hiểm.

Ngưỡng 0.85 (aggressive - tích cực): Nhiều cache命中 hơn, nhưng tỷ lệ dương tính giả cao hơn. "Làm thế nào để đặt lại mật khẩu của tôi" có thể khớp với "Làm thế nào để thay đổi email của tôi" — ý định tương tự, nhưng câu trả lời sai. Tốt cho các trường hợp kiểu FAQ nơi một câu trả lời hơi không chính xác là chấp nhận được.
Ngưỡng 0.92 (balanced - cân bằng): Điểm ngọt ngào (sweet spot) cho hầu hết các trường hợp sử dụng sản phẩm. Bắt được các cách diễn đạt lại rõ ràng trong khi từ chối các truy vấn khác biệt nhưng tương tự.
Ngưỡng 0.98 (conservative - bảo thủ): Khớp gần như chính xác. Rất ít dương tính giả, nhưng bạn chỉ bắt được những cách diễn đạt lại rõ ràng nhất. Tại thời điểm này, exact caching bắt được gần như nhiều như vậy với rủi ro dương tính giả bằng không.

Không có ngưỡng chính xác chung nào. Nó phụ thuộc vào chi phí của một câu trả lời sai trong ứng dụng của bạn. Bot hỗ trợ khách hàng trả về một câu trả lời FAQ hơi sai là có thể chấp nhận. Ứng dụng lời khuyên y tế trả về một câu trả lời được cache cho một tình trạng khác là nguy hiểm.

Năm Chế độ Thất bại mà Không ai Cảnh báo cho Bạn

1. Các truy vấn phụ thuộc bối cảnh trông giống hệt nhau

"Tình trạng là gì?" được hỏi bởi Người dùng A về Đơn hàng #4521 và Người dùng B về Đơn hàng #7893 sẽ có các nhúng gần giống hệt nhau. Nếu không có các khóa cache theo phạm vi người dùng hoặc phiên, Người dùng B nhận được tình trạng đơn hàng của Người dùng A. Các khóa cache phải bao gồm bối cảnh liên quan — không chỉ là văn bản prompt.

2. Các truy vấn nhạy cảm về thời gian trả về câu trả lời cũ

"Giá mới nhất cho GPT-5 là bao nhiêu?" được cache tuần trước là sai trong tuần này nếu giá đã thay đổi. TTL giúp ích, nhưng TTL phù hợp thay đổi theo loại truy vấn. Câu hỏi giá cả cần TTL tính bằng giờ. Câu trả lời FAQ có thể cache trong vài ngày. TTL một kích cỡ cho tất cả là sự đảm bảo cho các câu trả lời cũ hoặc tỷ lệ命中 thấp.

3. Drift của mô hình nhúng (Embedding model drift)

Nếu bạn cập nhật mô hình nhúng của mình, tất cả các nhúng được cache trước đó trở nên không hợp lệ. Các điểm tương đồng giữa các nhúng cũ và mới là vô nghĩa. Bạn cần một chiến lược vô hiệu hóa cache (cache invalidation) gắn liền với phiên bản mô hình nhúng của mình. Hầu hết các đội học bài học này theo cách khó khăn sau khi cập nhật mô hình gây ra sự gia tăng các phản hồi cache không chính xác.

4. Cache poisoning từ các phản hồi kém

Nếu LLM trả về một phản ứng ảo giác hoặc không chính xác và bạn cache nó, mọi truy vấn tương tự trong tương lai nhận được cùng một câu trả lời sai đó. Cache khuếch đại lỗi. Giảm thiểu: thêm các kiểm tra chất lượng trước khi cache (điểm tin cậy, xác thực độ dài, kiểm tra định dạng), hoặc để người dùng gắn cờ các phản hồi được cache là không chính xác để kích hoạt loại bỏ cache.

5. Sự phức tạp của cache phản hồi streaming (luồng)

Hầu hết các cuộc gọi LLM sử dụng streaming (stream: true). Bạn không thể cache một phản hồi streaming giữa luồng — bạn cần lưu trữ toàn bộ phản hồi, sau đó lưu nó. Khi命中 cache, bạn要么 trả về toàn bộ phản hồi ngay lập tức (phá vỡ hợp đồng streaming mà máy khách của bạn mong đợi) hoặc mô phỏng streaming bằng cách phân đoạn phản hồi được cache với các độ trễ nhân tạo. Cả hai đều là chi phí kỹ thuật mà các nhà cung cấp hiếm khi đề cập.

Toán học Dollar: Cache thực sự tiết kiệm được gì

Đối với một đội chi tiêu 5.000 USD/tháng cho các API LLM:

Tỷ lệ命中	Tiết kiệm hàng tháng
10%命中	500 USD/tháng
20%命中	1.000 USD/tháng
30%命中	1.500 USD/tháng
45%命中	2.250 USD/tháng

Tiết kiệm đến từ hai nơi: tránh các cuộc gọi LLM (cái hiển nhiên) và giảm độ trễ (cái ẩn giấu). Một cache命中 trả về trong dưới 5ms thay vì 2-5 giây. Đối với các ứng dụng hướng tới khách hàng, sự cải thiện độ trễ này thường quan trọng hơn tiết kiệm tiền.

Chi phí vận hành chính bản thân cache là tối thiểu. Việc tạo nhúng sử dụng một mô hình nhỏ (text-embedding-3-small với giá 0,02 USD/1M token). Lưu trữ vector trong Redis hoặc một vector DB chuyên dụng thêm 50-200 USD/tháng tùy thuộc vào kích thước cache. Chi phí cơ sở hạ tầng dưới 5% của số tiền tiết kiệm được ngay cả ở tỷ lệ命中 10%.

Kiến trúc Đúng: Phân lớp Exact và Semantic Caching

Cách tiếp cận tốt nhất là một cache hai lớp kiểm tra các kết quả chính xác trước (nhanh, rủi ro bằng không) và quay lại khớp ngữ nghĩa chỉ khi cần thiết:

# Layer 1: Exact cache (sub-ms, không có dương tính giả)
exact_key = sha256(model + prompt + params)
if exact_hit := cache.get(exact_key):
    return exact_hit

# Layer 2: Semantic cache (2-5ms, có cổng ngưỡng)
embedding = embed(prompt)
semantic_hit = vector_db.search(embedding, threshold=0.92)
if semantic_hit:
    return semantic_hit.response

# Cache miss: gọi LLM
response = call_llm(prompt)

# Ghi vào cả hai lớp
cache.set(exact_key, response, ttl=3600)
vector_db.upsert(embedding, response, ttl=3600)

return response

Ứng dụng trung bình mà chúng tôi onboarding phát hiện ra rằng 18% yêu cầu là bản sao chính xác vào ngày đầu tiên — trước khi khớp ngữ nghĩa được kích hoạt.

Các backend cache quan trọng ít hơn bạn nghĩ. In-memory hoạt động cho các proxy thể hiện đơn. Redis hoạt động cho các triển khai phân tán. Các vector DB chuyên dụng (Qdrant, Pinecone) chỉ đáng giá nếu cache của bạn vượt quá 1 triệu mục — dưới mức đó, Redis với tìm kiếm vector là đủ và đơn giản hơn để vận hành.

Bắt đầu Với Đo lường, Không phải Triển khai

Lỗi phổ biến nhất: xây dựng một lớp cache trước khi hiểu lưu lượng truy cập của bạn trông như thế nào. Bạn có thể dành hai tuần để triển khai semantic caching chỉ để phát hiện ra rằng lưu lượng của bạn là 90% truy vấn độc nhất, phụ thuộc bối cảnh với trần tỷ lệ命中 12%.

Đo lường trước:

Ghi nhật ký tất cả các prompt trong một tuần. Băm chúng. Đếm các bản sao chính xác. Đó là sàn của bạn.
Lấy mẫu 1.000 yêu cầu. Tạo nhúng. Phân cụm chúng. Đếm xem bao nhiêu rơi vào trong ngưỡng tương đồng 0.92. Đó là trần của bạn.
Ước tính tiết kiệm. Tỷ lệ命中 sàn × chi phí LLM hàng tháng = tiết kiệm được đảm bảo. Tỷ lệ命中 trần × chi phí hàng tháng = tiết kiệm tối đa có thể. Nếu cả hai số dưới 200 USD/tháng, caching không đáng giá công sức kỹ thuật.

Nếu cả hai số đều biện minh cho công sức, hãy bắt đầu chỉ với exact caching. Chạy nó trong hai tuần. Sau đó thêm semantic caching lên trên và so sánh sự cải thiện biên. Nếu semantic caching chỉ thêm 5-8 điểm phần trăm so với exact caching, rủi ro dương tính giả có thể không biện minh cho sự phức tạp.

Bài viết này được chuyển ngữ và biên tập dựa trên phân tích chuyên sâu từ Preto.ai — nền tảng tối ưu hóa chi phí LLM.