AWS vừa giới thiệu một mẫu thiết kế mới nhằm cắt giảm chi phí truy xuất AI trên Amazon Bedrock. Nếu bạn xây dựng các ứng dụng retrieval-augmented generation (RAG), cấu hình này có thể giúp giảm chi tiêu token, nhưng người dùng của bạn có thể phải chờ câu trả lời lâu hơn.
Trong một bài viết đăng ngày 2026-08-21 trên AWS Machine Learning Blog, AWS đã chỉ ra cách đặt một mô hình nhỏ vào giữa quá trình truy xuất và câu trả lời cuối cùng. Thay vì gửi các đoạn văn bản dài tới một mô hình lớn, một mô hình xử lý nhanh sẽ trích xuất chính xác các câu liên quan trước tiên.
Cách thiết lập này hoạt động
Thiết kế tham chiếu này chạy bên trong một AWS Lambda function sử dụng Amazon Bedrock Converse API. Bạn cần có tài khoản AWS, quyền IAM và quyền truy cập mô hình.
Quy trình phân chia công việc giữa hai mô hình:
– Claude Haiku đóng vai trò là bộ nén, chọn các đoạn văn bản nguyên văn khớp với câu hỏi của người dùng.
– Claude Sonnet chỉ đọc văn bản đã được cắt gọn và tạo câu trả lời cuối cùng.
AWS đã thử nghiệm ba phương pháp tiếp cận trên hơn 500,000 tài liệu từ chín loại nguồn doanh nghiệp và 500 câu hỏi thuộc 10 danh mục: baseline RAG, chỉ dùng nén, và rerank kết hợp nén.
Những con số cho thấy điều gì
Theo AWS, việc thu nhỏ ngữ cảnh mang lại mức tiết kiệm lớn:
– Token volume: Giảm xuống còn 12% khi nén (ít hơn 8.6x token) và 10% khi kết hợp rerank cùng nén (ít hơn 10.1x token), so với 100% ở baseline RAG.
– Total cost: Giảm xuống 67% (tiết kiệm 33%) và 64% (tiết kiệm 36%).
– Quality score: Giữ ở mức gần với baseline (97.5% và 97.6% so với 100%), dựa trên đánh giá của LLM judge về độ chính xác, tính đầy đủ, độ chuẩn xác của trích dẫn và tính súc tích.
– Hallucination rate: Giảm từ 51% ở baseline xuống 44% khi nén và 38% khi dùng reranking, với độ tin cậy được theo dõi riêng.
– Latency: Tăng thêm +19% khi nén và +12% khi kết hợp rerank cùng nén. Tốc độ bị ảnh hưởng.
Những tuyên bố bạn nên tự mình xác minh
Những con số này hoàn toàn đến từ các thử nghiệm nội bộ của AWS trên một tập dữ liệu duy nhất và được đánh giá bởi một LLM judge. Chưa có ai bên ngoài AWS kiểm tra độc lập các số liệu này, và chúng không phải là sự đảm bảo về hiệu suất cho các khối lượng công việc, mức giá hoặc mô hình khác. Việc thêm một lệnh gọi mô hình nữa sẽ tạo ra một điểm lỗi tiềm ẩn mới. Bộ nén có thể vô tình loại bỏ các dữ kiện quan trọng, làm suy yếu trích dẫn, hoặc gặp sự cố trước các đoạn văn bản lỗi định dạng và prompt injection.
Cách thử nghiệm mô hình này
Đừng vội thay đổi quy trình production của bạn. Hãy thử nghiệm trên dữ liệu của chính bạn trước.
Hãy thiết lập một bộ truy vấn kiểm thử cố định với retriever, cài đặt top-k, chunking và model ID của bạn. Chạy các truy vấn qua cả ba hướng: baseline RAG, nén, và rerank kết hợp nén. Ghi lại log về token đầu vào, token đầu ra, chi phí Lambda, chi phí mô hình, cùng với độ trễ p50 và p95. Quan trọng nhất là hãy trực tiếp xem xét các đoạn văn bản đã nén. Kiểm tra xem những gì bị lược bỏ. Nếu độ trễ ở vùng biên (tail latency) tăng vọt hoặc các bằng chứng quan trọng bị mất, việc giữ lại quy trình baseline RAG vẫn là lựa chọn an toàn hơn.