RAG Đốt tiền – Tôi đã xây dựng một lớp kiểm soát chi phí để khắc phục vấn đề này

Mô hình ngôn ngữ lớn RAG đang đốt tiền — Tôi đã xây dựng một lớp kiểm soát chi phí để khắc phục vấn đề này Hầu hết các hệ thống RAG tối ưu hóa cho mức độ liên quan, không phải chi phí. Tôi đã xây dựng một lớp kiểm soát chi phí sẵn sàng sản xuất kết hợp bộ nhớ đệm ngữ nghĩa, định tuyến truy vấn và thực thi ngân sách, giúp giảm chi phí LLM tới 85% mà không làm giảm chất lượng câu trả lời. Emmimal P Alexander Ngày 29/5/2026 22 phút đọc Chia sẻ Hình ảnh do tác giả cung cấp, được tạo bằng Google Gemini Tóm tắt Bài viết này trình bày một triển khai hoạt động đầy đủ bằng Python thuần túy, cùng với kết quả đánh giá từ một thiết lập cục bộ. Các hệ thống RAG không chỉ thất bại về chất lượng. Chúng cũng có thể trở nên kém hiệu quả về chi phí, thường theo những cách không thể nhìn thấy ngay lập tức. Mỗi token được truy xuất thêm đều có chi phí. Trong hệ thống của tôi, việc truy xuất quá mức ngữ cảnh dao động từ 3–8 lần so với những gì truy vấn thực sự yêu cầu. Trong nhiều triển khai cơ bản, các truy vấn lặp lại được xử lý độc lập, không có sự tái sử dụng kết quả trước đó. Trong các thiết lập mô hình đơn, một phần lớn các truy vấn đơn giản có thể được xử lý bởi các mô hình chi phí cao, ngay cả khi các lựa chọn thay thế chi phí thấp hơn là đủ. Với bộ nhớ đệm ngữ nghĩa (tỷ lệ truy cập lên tới 98,5% trong một đánh giá bộ nhớ đệm được khởi tạo trước, làm nóng), định tuyến truy vấn (khoảng 81% yêu cầu được chuyển sang mô hình chi phí thấp hơn trong hỗn hợp đánh giá) và một lớp ngân sách token với bộ ngắt mạch, hệ thống đã đạt được mức giảm chi phí lên tới 85,8% với 10.000 yêu cầu mỗi ngày, đồng thời duy trì chất lượng phản hồi trong thiết lập được đánh giá. Những kết quả này dựa trên các lần chạy đánh giá cục bộ theo cấu hình cơ bản được mô tả dưới đây. Hệ thống hoạt động tốt — và âm thầm tiêu tốn tiền Tôi đã xây dựng một hệ thống RAG hoạt động hoàn hảo và tôi đã chạy các truy vấn tương tự thông qua cùng một quy trình và nhận được cùng một kết quả mỗi lần. Trong quá trình thử nghiệm, không có gì sai, độ trễ ổn định và câu trả lời chính xác. Sau đó, tôi đã xem xét nhật ký token. Trong thiết lập của tôi, ngay cả những câu hỏi đơn giản như “RAG là gì?” hoặc “Định nghĩa tìm kiếm ngữ nghĩa.” cũng đang truy cập mô hình đắt nhất. Mỗi truy vấn lặp lại đều được tính phí đầy đủ, ngay cả khi tôi đã trả lời chính xác câu hỏi đó mười phút trước. Mỗi yêu cầu đều truy xuất mười đoạn trong khi hai đoạn đang thực hiện công việc thực tế. Hệ thống không bị hỏng. Nó chỉ mù quáng về mặt tài chính. Và ở quy mô lớn, sự khác biệt đó không còn quan trọng nữa. Việc chạy một quy trình RAG trên máy tính xách tay cục bộ rất dễ dàng. Nhưng bản thiết kế tiêu chuẩn: truy xuất, nhắc, gọi để lại những khoảng trống vận hành lớn. Hành vi chi phí sản xuất thường không phải là trọng tâm chính trong nhiều hướng dẫn triển khai RAG. Trong thế giới thực, bạn phải theo dõi hiệu quả tính toán và token của mình. Bạn có đang đốt ngân sách để xử lý lại chính xác truy vấn đã truy cập máy chủ ba phút trước không? Một tra cứu thông tin đơn giản có thực sự cần phải định tuyến qua cùng một đường dẫn mô hình nặng, đắt tiền như một truy vấn suy luận đa bước không? Tôi đã xây dựng một lớp kỹ thuật ngữ cảnh cho hệ thống trước đây của mình [7] để kiểm soát những gì đi vào cửa sổ ngữ cảnh vì lý do chất lượng. Nhưng chất lượng và chi phí là những lĩnh vực thất bại khác nhau. Bạn có thể có kiểm soát ngữ cảnh hoàn hảo và vẫn phải trả gấp 8 lần số tiền bạn cần. Đây là lớp kiểm soát chi phí tôi đã xây dựng thêm — với các số liệu và mã thực tế bạn có thể chạy. Tất cả các kết quả dưới đây đều từ các lần chạy thực tế của hệ thống (Python 3.12.6, Windows 11, chỉ CPU, không GPU), trừ khi được ghi chú rõ ràng là đã tính toán. Tại sao RAG mù quáng về tài chính theo thiết kế RAG được thiết kế để giải quyết vấn đề chất lượng truy xuất [1]. Nó không được thiết kế để giải quyết vấn đề chi phí. Đây không phải là một lời chỉ trích, mà chỉ là một lớp khác của hệ thống. Tuy nhiên, trong quá trình sản xuất, hai lớp này xung đột. Và sự xung đột này gây tốn kém. Có ba chế độ lỗi cụ thể. Chế độ lỗi 1: Truy xuất quá mức cửa sổ ngữ cảnh Hầu hết các triển khai mặc định truy xuất 10 đoạn hàng đầu. "Chỉ để an toàn." Vấn đề là: trên thực tế, 2-3 đoạn chứa câu trả lời. 7-8 đoạn còn lại là nhiễu – ngữ cảnh dư thừa làm tăng số lượng token mà không bổ sung thông tin. Người dùng phải trả tiền cho những token đó mỗi lần. Với 500 token cho mỗi truy vấn, và truy xuất 10 đoạn hàng đầu trong đó 7 đoạn không cần thiết: Số token không cần thiết cho mỗi truy vấn: ~350 Với 10.000 yêu cầu/ngày: 3.500.000 token không cần thiết/ngày Với $0,015/1K token: $52,50/ngày lãng phí Hàng tháng: $1.575 cho ngữ cảnh không cần thiết Con số đó được tính toán từ các giả định đã nêu, không được đo lường từ đầu đến cuối. Chế độ lỗi 2: Không có lớp bộ nhớ đệm Hai người dùng hỏi "RAG là gì?" cách nhau mười phút, và hệ thống tạo ra cùng một embedding, truy xuất cùng các đoạn, và trả về cùng một câu trả lời. Người dùng phải trả toàn bộ chi phí LLM hai lần. Không có bộ nhớ ngữ nghĩa giữa các yêu cầu trong một pipeline RAG tiêu chuẩn. Mỗi truy vấn được xử lý như thể nó chưa từng được hỏi trước đây. Với tỷ lệ truy vấn lặp lại 30%, một ước tính thận trọng dựa trên lưu lượng truy cập chuyên biệt của tôi – người dùng phải trả tiền cho 30% lưu lượng truy cập của mình hai lần. Chế độ lỗi 3: Không có định tuyến mô hình Một số pipeline mặc định sử dụng một mô hình có khả năng cao duy nhất cho tất cả các truy vấn, bất kể độ phức tạp. Ngay cả khi truy vấn là: "LLM là viết tắt của từ gì?" Câu hỏi đó không cần GPT-4.5 hoặc Claude Opus. Nó không cần suy luận đa bước. Nó không cần cửa sổ ngữ cảnh 200K. Nó cần một mô hình nhanh, rẻ và cần hoàn thành trong 200ms. Sử dụng các giả định về giá trong thiết lập này, mô hình cấp cao nhất đắt hơn khoảng 90 lần mỗi token so với cấp thấp nhất [2]. Với việc 81% các truy vấn chuẩn là các tra cứu dữ kiện đơn giản, việc không định tuyến chúng một cách thích hợp dẫn đến sự gia tăng đáng kể và có thể tránh được trong chi phí phục vụ. Các mô hình này có thể xuất hiện trong các thiết lập RAG đơn giản hơn, đặc biệt khi các tối ưu hóa có ý thức về chi phí không được bao gồm. Mã nguồn đầy đủ: https://github.com/Emmimal/rag-cost-control-layer/ Thực tế chi phí ở quy mô lớn Trước khi xây dựng bất cứ thứ gì, tôi muốn xem các con số một cách trung thực. Một thiết lập RAG cơ bản thường chạy truy xuất cho mỗi yêu cầu và không sử dụng các lớp bộ nhớ đệm hoặc định tuyến. Trong các triển khai đơn giản hơn, nó cũng dựa vào một si