Cache key do LLM sinh: lỗi tách tenant chờ sẵn ở backend

Backend agent của bạn gọi model để tóm tắt mỗi request, rồi lấy chính chuỗi tóm tắt đó làm cache key. Hai tenant có giỏ hàng gần giống nhau sinh ra cụm từ gần giống nhau, key space sập vào nhau, và dữ liệu của tenant này rơi vào response của tenant kia.

Tác giả nói rõ đây là pattern tổng hợp, "not a claim about one named outage". Nhưng nó đủ để chốt một nguyên tắc: có những chỗ trong pipeline agent mà output của LLM không được chạm vào.

Cache key là contract, không phải caption

Tiêu chí của một cache key rất chán và rất rõ: ổn định qua retry và qua replica, tách tenant một cách "cryptographic boredom", và không mã hoá secret vào chuỗi key. Natural language output không đạt bất kỳ điều nào trong số đó.

Lý do kỹ thuật nằm ở tính drift. Cùng một prompt, các model free có thể trả về noun phrase khác nhau theo ngày và theo provider. Một cụm từ đổi thì lặng lẽ tách một object logic thành hai — hoặc gộp hai object lẽ ra không bao giờ được gặp nhau. Nguồn gọi thẳng đó là "a data-isolation bug, not a style issue", không phải vấn đề style.

Search index được phép gom các giỏ hàng giống nhau vì đó là mục đích của nó; response cache thì không được gộp nhầm. Hai nhiệm vụ đó không dùng chung một key function.

Bốn thuộc tính bắt buộc, cộng một cho HTTP cache

• Determinism: input giống nhau phải ra key giống nhau.
• Tenant prefix: mọi key bắt đầu bằng một tenant id ổn định.
• Explicit schema: version, entity và các field được đặt tên rõ ràng.
• No model text: zero token đến từ một generative call.

Với HTTP cache có thuộc tính thứ năm: ETag phải hash bytes chứ không hash caption, để If-None-Match vẫn là một phép so sánh equality thuần tuý. Một paraphrase của model không được phép lật trạng thái freshness của cache.

Red flags: khi nào dừng thiết kế lại

Nguồn liệt kê các trường hợp không được ship model-minted key: key phủ nhiều hơn một tenant hoặc workspace; key gate cart, session hay entitlement state; value chứa PII, payment, health hoặc location data; replica phải thống nhất với nhau mà không gọi chung một model; key đồng thời là ETag, lock name hoặc topic name.

Ngưỡng rất thấp: "Any one flag is enough to stop the design. Two flags mean the design is already unsafe." Demo trên dữ liệu giả có thể bỏ qua một flag; tenant thật đầu tiên thì không.

Chỗ thứ hai: để LLM tự chọn tool

Cùng một dạng lỗi xuất hiện ở tầng tool routing. Model không biết tool nó vừa chọn đang trả 429 Too Many Requests, hay latency vừa nhảy từ 200ms lên 5 giây — với model, tool definition vẫn là tĩnh. Chọn tool chỉ bằng semantic similarity là bỏ qua operational reality.

Hướng xử lý là tách "capability matching" khỏi "operational availability": matching thì để model làm, còn viability thì để một lớp deterministic quyết định, dựa trên headroom rate limit và latency đo được. Tác giả bài nguồn (một bài vendor, giới thiệu sản phẩm của chính họ) đề xuất công thức Selection Score = Capability Alignment × Current Rate Limit Headroom và cho biết trace nội bộ của họ thấy latency trung bình dao động 713ms–1112ms tuỳ tải — hãy đọc đây là con số của họ, không phải benchmark độc lập.

Điểm đáng lấy, không phụ thuộc vendor: fallback kiểu "tool A fail thì gọi tool B" scale kém vì nó đốt reasoning step đúng lúc hệ thống đang hỏng.

Việc nên làm tuần này

Grep codebase tìm mọi chỗ một chuỗi do model sinh ra đi vào key, lock name hoặc topic name, rồi đối chiếu năm thuộc tính ở trên. Snippet Node trong bài nguồn được chính tác giả ghi rõ là bản đề xuất, chưa chạy trên cluster production nào — dùng như starting point, đừng copy thẳng vào service.