Tối ưu hóa chi phí sử dụng LLM với Semantic Cache

Tôi đã xây dựng một hệ thống báo cáo ngôn ngữ chat bot tự nhiên, được cung cấp bởi Retrieval Augmented Generation (RAG). Nó cung cấp một trải nghiệm tuyệt vời cho người dùng, họ có thể truy vấn dữ liệu và nhận được báo cáo được cắt và cắt theo kích thước mà họ muốn. Nó trực quan và cung cấp hiệu quả. Nó biến hàng tấn dữ liệu thành vàng lỏng. Sau đó, dự luật API LLM đã đến. Đó là khi tôi nhận ra rằng trong nhiệm vụ của tôi để xây dựng trí thông minh này, tôi đã tạo ra một lỗ đen tài chính. Sau đó, dự luật API LLM đã đến. Đó là khi tôi nhận ra rằng trong nhiệm vụ của tôi để xây dựng trí thông minh này, tôi đã tạo ra một lỗ đen tài chính. Trong thế giới CNTT ngày nay, mỗi đội đang tìm cách xây dựng một hệ thống AI Agentic.Trong mỗi môi trường, các hệ thống AI Agentic này thực hiện hàng trăm và hàng ngàn cuộc gọi LLM, bắt đầu với phát triển, eval, kiểm tra sự chấp nhận của người dùng và sau đó trong môi trường sản xuất. Để tạo ra các câu trả lời có nền tảng, chúng tôi thực hiện Retrieval Augmented Generation (RAG). Điều này có nghĩa là chúng tôi truy vấn các cửa hàng vector cho nội dung tương tự và truyền dữ liệu thu được với các câu hỏi của người dùng, lời nhắc, ví dụ, hướng dẫn bảo vệ, sơ đồ phản hồi có cấu trúc, v.v. đến LLM. Điều này có nghĩa là cho một câu hỏi đơn giản, chúng tôi thêm hàng trăm token bổ sung trong tên ngữ cảnh, bảo vệ và một vài lời nhắc bắn vv Các mô hình ngôn ngữ lớn (LLM) phân tích chúng dưới dạng token và làm công việc của nó để tạo ra câu trả lời và sau đó chúng tôi nhận được câu trả lời cho câu hỏi của chúng tôi. Câu trả lời này có thể là câu trả lời cho câu hỏi của chúng tôi hoặc nó có thể là một câu trả lời có cấu Trong hệ thống của tôi, hệ thống rút dữ liệu từ Vector DB và Knowledge Graph để đặt nền tảng cho câu trả lời. Tôi quan sát khoảng ~2000 token đầu vào trong cửa sổ ngữ cảnh. LLM sau đó tạo ra một phản ứng, 500 token phản hồi. Ở cái nhìn đầu tiên, đó chỉ là một vài xu. Nhưng với 200.000 truy vấn một ngày, những "cents" biến thành một con quái vật. Chỉ cần thêm rằng sử dụng với nhiều người dùng trong giai đoạn phát triển và đánh giá cũng. Hiện tại chi phí cho mỗi triệu token sử dụng như đầu vào và đầu ra trông rẻ hơn như chúng ta đang ở giai đoạn đầu của việc áp dụng LLM api và các nhà cung cấp dịch vụ đã cố ý cung cấp rất nhiều giảm giá. Trong tương lai những giá này sẽ cao hơn, và sau đó chi phí tổng thể từ phát triển đến sản xuất để hỗ trợ và bảo trì Bạn cũng có thể tham khảo một vài bài viết trích dẫn những thách thức xung quanh chi phí LLM. Cuộc chiến giá LLM đang làm tổn thương giáo dục - và các công ty khởi nghiệp Làm thế nào để mở rộng AI doanh nghiệp với LLM sai có thể khiến bạn phải trả giá Tôi đã xây dựng các hệ thống dựa trên RAG bằng cách sử dụng LangGraph, Neo4j, ChromaDB và Redis. Tôi mang mẫu kiến trúc này có tên Semantic Cache và chi tiết triển khai để giảm đốt token trong sản xuất. Mô hình này có thể làm giảm chi phí sử dụng LLM của bạn bằng cách lưu trữ và trả lời các câu hỏi tương tự thay vì kêu gọi LLM mỗi lần. Cache là gì Cache đã tồn tại trong nhiều thế kỷ trong kiến trúc hệ thống CNTT của chúng tôi. Nó bắt đầu với In-Memory, sau đó nó đã được phân phối. Ban đầu có rất ít ưu đãi giới hạn cho triển khai dựa trên VM hoặc on-prem. Với sự xuất hiện của đám mây, nhiều ưu đãi đám mây đã phát triển. Ngày nay, chúng tôi có các hệ thống bộ nhớ cache khá trưởng thành. Tuy nhiên, việc sử dụng hệ thống bộ nhớ cache đã được dựa trên các cặp giá trị khóa. Chìa khóa được hash và lưu trữ trong một cấu trúc dữ liệu loại bảng Hash. Caching luôn luôn là một tìm kiếm dựa trên khóa chính xác. Nếu khóa của bạn hiện diện, hệ thống bộ nhớ cache sẽ trả về các giá trị cho khóa của bạn, và nếu khóa không, điều đó có nghĩa là nó không được lưu trữ hoặc nó đã bị trục Semantic Cache là gì Các vector với nhiều chiều và tìm kiếm vector bằng cách sử dụng tương tự cosine hoặc các cơ chế tương tự cũng đã tồn tại trong một thời gian dài. Tuy nhiên, với LLM và RAG, việc nhúng vector và tìm kiếm tương tự đã trở nên khá phổ biến. Vector RAG là một trong những lựa chọn chính của giải pháp cho các hệ thống dựa trên RAG. Điều này giúp tìm thấy nội dung tương tự. Đây không phải là một cái nhìn chính xác, thay vào đó, điều này giúp tìm thấy các vector nhúng tương tự theo ngữ nghĩa. Khả năng này ban đầu đã được phát triển trong cơ sở dữ liệu Vector. nhưng bây giờ, khả năng này cũng có sẵn trong các hệ thống bộ nhớ đệm như redis và bây giờ các nhà cung cấp dịch vụ đám mây cũng đã giới thiệu khả năng này trong các dịch vụ bộ nhớ đệm của họ. Chúng ta có thể định nghĩa Semantic Cache là một bộ nhớ cache thu thập các mục cache dựa trên ý nghĩa của nội dung hoặc tài liệu thay vì hash của khóa. Chúng ta có thể định nghĩa Semantic Cache là một bộ nhớ cache thu thập các mục cache dựa trên ý nghĩa của nội dung hoặc tài liệu thay vì hash của khóa. Semantic Cache khác nhau như thế nào Hãy làm một sự khác biệt nhanh chóng giữa Cache, Semantic Cache và RAG. Các bảng sau đây có thể giúp làm rõ sự khác biệt giữa Cache truyền thống và Cache ngữ nghĩa. Factors Traditional Cache Semantic Cache Approach Key based Meaning based Key Search Exact match Similar match Best For APIs LLMs Example Key, Value (Student_Id, Student_Obj) 2025081520, StudentObject1 2025091640, StudentObject2 if key used while doing look up is different, then it wont's return any result Statements Where did Alex graduate from? Which university did Alex graduate from? both will fetch the same entry from cache. Cách tiếp cận Key dựa Ý nghĩa dựa Key tìm kiếm Trận đấu chính xác Game tương tự Tốt nhất cho APIs LLMs Ví dụ Chìa khóa, Giá trị (Student_Id, Student_Obj) 2025081520, Đối tượng sinh viên1 2025091640, Đối tượng sinh viên2 Nếu phím được sử dụng trong khi thực hiện tìm kiếm lên là khác nhau, sau đó it won's return bất kỳ kết quả nào Tuyên bố Alex tốt nghiệp từ đâu? Đại học nào mà Alex tốt nghiệp? Cả hai sẽ nhận được cùng một mục nhập từ bộ nhớ cache. Bảng sau đây có thể giúp làm rõ sự khác biệt giữa RAG và Semantic Cache. Factors RAG Semantic Cache Use To generate new response To return previously generated and cached answer Data External data sources like Vector databases Previously generated Questions and Answer Cost Medium to High Low Best For Grounded response generation Repeated but similar question Sử dụng Để tạo ra phản ứng mới Trả về câu trả lời được tạo và lưu trữ trước đó dữ liệu Nguồn dữ liệu bên ngoài như cơ sở dữ liệu vector Những câu hỏi và câu trả lời trước đây Chi phí Trung bình đến cao thấp Tốt nhất cho Trả lời: Grounded response generation Repeated but similar question Chúng ta có thể thấy rằng sự khác biệt giữa bộ nhớ cache RAG và Semantic là đơn giản nhưng tác động tài chính là lớn. RAG thu thập thông tin thô và tạo ra câu trả lời. Nếu câu hỏi của bạn là lặp đi lặp lại, câu trả lời bộ nhớ cache chiến thắng bởi vì nó bỏ qua việc thu thập, tổ chức công cụ, và sản xuất. Kiến trúc RAG dựa trên Semantic Cache Tôi đã thiết kế kiến trúc sau đây cho bộ nhớ cache ngữ nghĩa trên kiến trúc RAG tiêu chuẩn. Các thành phần của kiến trúc Người dùng: Từ bất kỳ máy khách nào như trình duyệt hoặc ứng dụng di động, một API Q&A được gọi khi người dùng nhập bất kỳ câu hỏi nào bằng ngôn ngữ tự nhiên. API Gateway: yêu cầu API được xác thực và được ủy quyền trong Gateway GraphRAG + VectorRAG Agent System(FastAPI) A LangGraph ReAct agent, this orchestrates the workflow. It decides whether to check the cache, query the graph store or vector store, or respond to the user. Guardrails: Implemented via system prompts and specific instruction sets to ensure safe and accurate responses. MCP (Model Context Protocol): Semantic Cache MCP Client: Connects to the cache server using Server-Sent Events (SSE). Semantic Cache MCP Server: A FastMCP server that exposes tools (cache_lookup, cache_store) and manages cache server(Redis) interactions. Semantic Cache Server(Redis): Acts as a Semantic Cache. It stores vector embeddings of questions and corresponding answers to provide fast retrieval for similar queries. LLM: Công cụ lý luận cho đại lý và máy phát điện cho các truy vấn Cypher cho GraphRAG và câu trả lời ngôn ngữ tự nhiên. Observability (LangSmith): Cung cấp theo dõi, giám sát và gỡ lỗi cho các bước thực hiện của đại lý. Các Knowledge Graph(Neo4j): Nó lưu trữ các mối quan hệ có cấu trúc (ví dụ, (Người)-[:WORKS_AT]->(Tổ chức)) và được truy vấn thông qua Cypher được tạo ra bởi LLM. Vector Store (ChromaDB): Lưu trữ các nhúng vector được tạo ra từ tài liệu kiến thức. Để thực hiện bộ nhớ cache ngữ nghĩa, chủ yếu là thành phần MCP bộ nhớ cache ngữ nghĩa mới đã được thêm vào hệ thống đại lý dựa trên RAG tiêu chuẩn. The agent first does a cache look up. Semantic Cache MCP client uses cache_lookup tool to check if the question is already answered and cached Semantic Cache MCP Server uses CACHE_SIMILARITY_THRESHOLD of >95% to decide whether a similar question is cached in the server. I tested similarity thresholds ranging from 80% to 99%. Below 90%, false positives increased and I started getting incorrect cached answers for loosely similar phrases. Above 97%, cache hit rates were significantly bad. In my use case, finally 95% provided the best trade off between precision and reuse. The right balance, however, depends on your specific use case and data distribution. Nếu hit bộ nhớ cache xảy ra, sau đó nó trả về câu trả lời mà không thực hiện bất kỳ cuộc gọi RAG nào, có nghĩa là không có cuộc gọi Vector db cũng như cuộc gọi biểu đồ kiến thức cũng như cuộc gọi LLM. Nếu thiếu bộ nhớ cache xảy ra, thì nó thực hiện RAG tiêu chuẩn và tạo ra câu trả lời. Nó đảm bảo lưu trữ câu hỏi với câu trả lời trong máy chủ bộ nhớ cache, được sử dụng cho các cuộc gọi tiếp theo. đoạn mã sau đây hiển thị mã máy chủ MCP cho tìm kiếm bộ nhớ cache.Tôi đã sử dụng tìm kiếm tương đồng dựa trên KNN và chỉ trả về 1 kết hợp gần nhất.Tôi sử dụng khoảng cách như điểm số và (1- điểm) như điểm tương đồng.Một điểm quan trọng hơn là sử dụng phương ngữ 2 là một điều cần thiết cho các truy vấn vector trong Redis, nếu không truy vấn sẽ thất bại. @mcp.tool() def cache_lookup(question: str) -> str: """ Look up a semantically similar question in the cache. Args: question: The question to look up Returns: JSON with cached answer if found (similarity >= 95%), or cache miss indication """ global _hits, _misses client = get_redis_client() ensure_index_exists(client) # Compute embedding for the query query_embedding = compute_embedding(question) query_vector = np.array(query_embedding, dtype=np.float32).tobytes() # Vector similarity search try: q = ( Query(f"*=>[KNN 1 @embedding $vec AS score]") .return_fields("question", "answer", "expires_at", "score") .sort_by("score") .dialect(2) ) results = client.ft(INDEX_NAME).search( q, query_params={"vec": query_vector} ) if results.total > 0: doc = results.docs[0] score = float(doc.score) similarity = 1 - score # Convert distance to similarity expires_at = float(doc.expires_at) # Check expiration if time.time() > expires_at: logger.info(f"Cache entry expired for: '{question[:50]}...'") # Delete expired entry client.delete(doc.id) _misses += 1 return json.dumps({ "found": False, "reason": "expired" }) # Check similarity threshold if similarity >= CACHE_SIMILARITY_THRESHOLD: _hits += 1 logger.info(f"Cache HIT: similarity={similarity:.4f} for '{question[:50]}...'") return json.dumps({ "found": True, "answer": doc.answer.decode() if isinstance(doc.answer, bytes) else doc.answer, "similarity": round(similarity, 4), "original_question": doc.question.decode() if isinstance(doc.question, bytes) else doc.question }) _misses += 1 logger.info(f"Cache MISS for: '{question[:50]}...'") return json.dumps({ "found": False, "reason": "no_similar_question" }) except Exception as e: logger.error(f"Cache lookup error: {e}") _misses += 1 return json.dumps({ "found": False, "reason": f"error: {str(e)}" }) Đầu tiên tôi đã tính toán các nhúng của câu hỏi, được lưu trữ cùng với câu hỏi thô và trả lời là giá trị cho khóa đó là hash md5 tiêu chuẩn của câu hỏi. @mcp.tool() def cache_store(question: str, answer: str) -> str: """ Store a question-answer pair in the semantic cache. Args: question: The original question answer: The answer to cache Returns: JSON confirmation of storage """ client = get_redis_client() ensure_index_exists(client) try: # Compute embedding embedding = compute_embedding(question) embedding_bytes = np.array(embedding, dtype=np.float32).tobytes() # Generate unique key key_hash = hashlib.md5(question.encode()).hexdigest()[:12] cache_key = f"cache:{key_hash}" current_time = time.time() # Store in Redis hash client.hset(cache_key, mapping={ "question": question, "answer": answer, "embedding": embedding_bytes, "created_at": current_time, "expires_at": current_time + CACHE_TTL_SECONDS }) # Set TTL on the key client.expire(cache_key, CACHE_TTL_SECONDS) logger.info(f"Cached answer for: '{question[:50]}...' (TTL: {CACHE_TTL_SECONDS}s)") return json.dumps({ "stored": True, "key": cache_key, "ttl_seconds": CACHE_TTL_SECONDS }) except Exception as e: logger.error(f"Cache store error: {e}") return json.dumps({ "stored": False, "error": str(e) }) Ảnh chụp nhanh sau đây cho thấy việc lưu trữ các câu hỏi và câu trả lời trong Redis với các nhúng. Sau đây là đoạn trích hiển thị mã máy khách MCP để gọi cache_lookup def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) Sau đây là đoạn trích hiển thị mã máy khách MCP để gọi cache_store. def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) Dấu vết sau đây cho chúng ta thấy dòng chảy của việc thực hiện. Trace được làm nổi bật tại cuộc gọi cache_lookup, và bạn có thể thấy đầu ra như cache_hit là sai với lý do no_similar_question. Do đó, trong luồng này, RAG tiêu chuẩn được thực hiện. Bạn có thể thấy nút graph_rag_query trong đường dẫn tiếp theo là một cuộc gọi LLM. Bây giờ, đó là khoảnh khắc của sự thật, khi một câu hỏi tương tự được hỏi một lần nữa. Chúng ta có thể thấy trong ảnh chụp nhanh sau đây, cache_hit là đúng. Có một sự thay đổi nhỏ trong cách diễn đạt của câu hỏi, nhưng nó tương tự như câu hỏi trước, do đó điểm tương đồng là 0.9866 như được hiển thị dưới đây. Do đó, câu trả lời được lấy trực tiếp từ bộ nhớ cache và bạn sẽ không thấy việc thực hiện dòng chảy RAG. Câu trả lời được trả về trực tiếp từ bộ nhớ cache ngữ nghĩa. Kết quả Thêm bộ nhớ cache ngữ nghĩa vào một hệ thống GraphRAG hoặc VectorRAG cung cấp hiệu suất và lợi ích chi phí có thể đo lường được. Trước đây, hệ thống mất 5 đến 6 giây cho mỗi yêu cầu, bao gồm tìm kiếm vector, tạo và thực hiện truy vấn số biểu đồ kiến thức, và tạo câu trả lời cuối cùng bởi LLM. Khi hit bộ nhớ cache xảy ra, câu trả lời trên màn hình của người dùng trong 900 ms đến 1,2 giây. Trung bình, điều này cung cấp giảm 24% trong các cuộc gọi LLM hàng ngày, làm giảm hóa đơn API LLM. Chiến lược Semantic Cache Nơi Semantic Cache chiến thắng Khi một hệ thống xử lý lưu lượng truy cập có thể dự đoán cao, một lớp bộ nhớ cache thêm một lợi ích về hiệu suất. Nó giành chiến thắng khi nhiều người dùng yêu cầu cùng một kiến thức, như trong trường hợp sử dụng "Customer Support & Helpdesks", nơi các câu hỏi như "Làm thế nào để đặt lại mật khẩu của tôi?", "Các chính sách hoàn tiền của bạn là gì?". Trong trường hợp sử dụng Tài liệu sản phẩm, nơi người dùng đang truy vấn cùng một hướng dẫn sản phẩm. Điều này thậm chí xảy ra khi các nhà phát triển truy vấn cùng một tài liệu kỹ thuật và các tài liệu API. Trong trường hợp sử dụng nội bộ HR & Onboarding, nơi các câu hỏi như "Làm thế nào để đăng ký bảo hiểm y tế?" và "Lịch trình nghỉ phép là gì?" xuất hiện bởi mỗi nhân viên. Khi nào nên tránh Semantic Caching Nó thất bại đặc biệt trong những hệ thống cung cấp siêu cá nhân hóa. Nếu hai người dùng hỏi cùng một câu hỏi nhưng yêu cầu các câu trả lời khác nhau dựa trên lịch sử y tế hoặc hồ sơ hoặc số dư tài khoản của họ, một bộ nhớ cache ngữ nghĩa có thể cung cấp các câu trả lời không chính xác. Nó thậm chí thất bại khi tài liệu, cơ sở kiến thức và dữ liệu của bạn biến động hoặc đó là thời gian thực, như khi bạn cần câu trả lời về giá cổ phiếu hoặc hàng tồn kho trực tiếp, một bộ nhớ cache là kẻ thù của bạn. Chiến lược Semantic Cache Invalidation Một bộ nhớ cache cần được làm mới và bộ nhớ cache ngữ nghĩa cần có chiến lược vô hiệu hóa bổ sung. Mỗi mục nhập bộ nhớ cache phải được gắn thẻ với một created_at timestamp để quản lý giá trị thời gian của nó để sống (TTL). Trong bộ nhớ cache ngữ nghĩa thêm document_version và embedding_model được sử dụng trong quá trình tạo nên cũng nên được gắn thẻ. Điều này rất quan trọng bởi vì nếu bạn nâng cấp mô hình nhúng, không gian vector của bạn thay đổi. Điều này làm cho các mục nhập bộ nhớ cache cũ bị lỗi thời. Chúng tôi cần theo dõi các biến số này, vì vậy chúng tôi có thể kích hoạt vô hiệu hóa bộ nhớ cache bất cứ khi nào một nguồn tài liệu được cập nhật hoặc mô hình nhúng được thay đổi hoặc cập nhật. Điều này đảm bảo rằng hệ thống của chúng tôi không đáp ứng với câu trả lời Giấy phép và cân nhắc an ninh Trong bất kỳ hệ thống bộ nhớ cache nào, bạn phải đảm bảo rằng nó ủy quyền trước khi nó cung cấp dữ liệu cho người dùng. Nó cũng phải đảm bảo rằng dữ liệu được lưu trữ trong bộ nhớ cache cũng được bảo mật khi nghỉ ngơi. Việc thực hiện bộ nhớ cache ngữ nghĩa phải tuân thủ các nguyên tắc này, nó không nên chỉ được xem là thêm một lớp cho hiệu suất hoặc lợi ích chi phí. Trong một hệ thống nhiều người thuê, các phím cô lập người thuê phải được thực hiện trong bộ nhớ cache.Cũng giống như trong hệ thống người dùng siêu cá nhân hóa, phân vùng không gian tên cấp người dùng phải được thực hiện trong bộ nhớ cache.Điều này đảm bảo rằng tìm kiếm tương đồng vector được giới hạn vào thùng chứa cụ thể thuộc về người dùng cụ thể của tổ chức tương ứng. Điểm quan trọng nhất về ủy quyền là tạo các khóa bộ nhớ cache nhận thức quyền, nơi hash của khóa bao gồm vai trò cụ thể của người dùng hoặc mức truy cập. Điều này đảm bảo rằng người dùng có ít quyền hạn không nhận được một câu trả lời được lưu trữ từ người dùng có đặc quyền hơn. Một hit bộ nhớ cache không phải là một cơ chế thu thập dữ liệu không được ủy quyền. Nếu người dùng không có quyền thu thập một tài liệu cụ thể hoặc hàng cơ sở dữ liệu thông qua đường ống RAG, thì họ không thể rút câu trả lời được tạo ra từ bộ nhớ cache. Cuối cùng, để đáp ứng các yêu cầu tuân thủ khác nhau như HIPPA hoặc SOC2, câu trả lời của bạn phải được mã hóa trước khi được lưu trữ trong bộ nhớ cache. Kết luận Các bản thảo kiến trúc, đoạn mã và các snapshots khác nhau chứng minh rằng có thể lưu trữ ngữ nghĩa các câu hỏi và thực hiện một tìm kiếm tương đồng dựa trên nhúng vector để trả về các câu trả lời được tạo trước đó để tránh các cuộc gọi LLM dựa trên RAG cho các câu hỏi tương tự. Ví dụ được hiển thị ở trên khá đơn giản, tuy nhiên chúng ta có thể mở rộng lựa chọn kiến trúc này cho nhiều điểm chạm LLM xảy ra trong hệ thống AI của Agentic để đưa ra quyết định không chỉ cho câu hỏi và câu trả lời của người dùng cuối. Semantic caching là một cách đơn giản để giảm chi phí token trong khi duy trì chất lượng phản hồi. Nếu hệ thống của bạn nhận được các truy vấn tương tự để trả lời, thêm một lớp bộ nhớ cache trước khi các bước thu thập và tạo ra là một lợi thế. phần dễ nhất là bạn không phải sửa đổi kiến trúc RAG của bạn, bạn chỉ cần tối ưu hóa dòng chảy bằng cách xử lý ý định lặp đi lặp lại sớm hơn trong chuỗi.