Giảm độ trễ và chi phí của hệ thống RAG cấp doanh nghiệp bằng cách gọi LLM ít hơn, không phải bằng cách mua mô hình nhanh hơn.

Mô hình ngôn ngữ lớn (LLM) Giảm độ trễ và chi phí của hệ thống RAG cấp doanh nghiệp bằng cách gọi LLM ít hơn, không phải bằng cách mua mô hình nhanh hơn Thông tin doanh nghiệp về tài liệu [Tập 1 #9ter] – Hệ thống từ Bài viết 9 gọi một mô hình ở nhiều bước để đảm bảo tính chính xác. Đối với những câu hỏi dễ, điều này gây ra độ trễ không cần thiết. Một tín hiệu theo từng câu hỏi sẽ định tuyến chúng vượt qua mô hình, tiết kiệm khoảng hai giây cho một kết quả khớp từ khóa. Angela Shi Ngày 13/8/2026 13 phút đọc Ảnh của Chen EdisoN, qua Pexels. Ngày càng nhiều, các hệ thống RAG được xây dựng theo cách tác nhân: đặt một mô hình vào bất cứ nơi nào cần phán đoán quyết định và để nó quyết định. Điều đó có nghĩa là rất nhiều lời gọi mô hình. Hệ thống từ Bài viết 9 (một hệ thống RAG sản xuất cho các tệp PDF) được xây dựng chính xác như vậy. Hỏi "Phí bảo hiểm hàng năm là bao nhiêu?" và nó chạy ba lời gọi mô hình nối tiếp: một để phân tích câu hỏi, một để phân xử các ứng viên được truy xuất, một để tạo ra câu trả lời đã được nhập. Mỗi lời gọi đều mang lại giá trị thực. Lời gọi phân tích hấp thụ lỗi chính tả và cách diễn đạt mơ hồ trước khi truy xuất chạy. Lời gọi phân xử ngăn một trang sai đến bước tạo câu trả lời. Lời gọi tạo câu trả lời trả về một câu trả lời đã được nhập với một trích dẫn mà người dùng có thể kiểm tra trên trang. Đối với một câu hỏi khó, ba lời gọi này là điều làm cho câu trả lời đáng tin cậy, và đó là lý do tại sao Bài viết 9 đặt chúng ở đó. Vấn đề là chúng ta không thể chi trả cho điều này đối với mọi câu hỏi, vì nó chậm. Ba lời gọi nối tiếp có nghĩa là người dùng phải đợi khoảng hai giây và trả phí token cho mỗi câu hỏi, bao gồm cả những câu hỏi dễ. Và nhiều câu hỏi của doanh nghiệp chưa bao giờ khó: "Phí bảo hiểm hàng năm là bao nhiêu?" chỉ có một câu trả lời, trên một dòng, và kết quả khớp từ khóa xác định đã cô lập nó ngay từ lần đầu tiên. Vì vậy, bài viết này bổ sung một bộ định tuyến: một tín hiệu rẻ tiền theo từng câu hỏi, được đọc trước bất kỳ lời gọi mô hình nào, gửi các câu hỏi dễ đi theo con đường nhanh và giữ cả ba lời gọi cho những câu hỏi khó. Bài viết này là bản đồ của việc định tuyến đó: tín hiệu (một điểm số mà hệ thống đã tính toán), biên độ làm cho nó trung thực, những gì nó tiết kiệm (khoảng hai giây cho một kết quả khớp từ khóa), và những câu hỏi mà nó phải từ chối đi theo con đường nhanh. Mọi con số đều là kết quả chạy thực tế trên kho dữ liệu môi giới hư cấu, có thể tái tạo trong sổ tay đi kèm. 🧭 Mới tham gia chuỗi bài? Bắt đầu với bản đồ: Lời nhắc, Ngữ cảnh, Vòng lặp trình bày ba lớp kỹ thuật mà mọi hệ thống RAG được xây dựng dựa trên, lời nhắc (lời gọi), ngữ cảnh (những gì lấp đầy cửa sổ của mô hình), vòng lặp (khi lời gọi tiếp theo được kích hoạt và khi nó dừng lại), và xem xét toàn bộ chuỗi bài qua lăng kính đó, từng bài viết một. Đây là cách ngắn nhất để xem những gì được đề cập và vị trí của bài viết này. Vị trí của bài viết này: một phần bổ sung cho Phần III của Bài viết 9, tối ưu hóa hệ thống mà nó đã xây dựng – Hình ảnh của tác giả 📓 Sổ tay có thể chạy được cho bài viết này có trên GitHub: doc-intel/notebooks-vol1. Nó chạy bộ định tuyến trên kho dữ liệu môi giới, in điểm tin cậy theo từng câu hỏi và cho biết câu hỏi nào bỏ qua mô hình và câu hỏi nào giữ lại mô hình. 1. Mọi câu hỏi đều phải trả chi phí cho toàn bộ hệ thống Hệ thống được nâng cấp đáng giá chi phí của nó đối với những câu hỏi khó. Vấn đề là nó tính cùng một chi phí đối với những câu hỏi dễ. Theo dõi một câu hỏi duy nhất qua hệ thống và các lời gọi mô hình sẽ chồng chất lên nhau: một để chuẩn hóa câu hỏi và trích xuất từ khóa của nó, một cho bộ phân xử xếp hạng các ứng viên được truy xuất, một để tạo ra câu trả lời đã được nhập. Ba chuyến đi khứ hồi đến một mô hình được lưu trữ, nối tiếp, trước khi người dùng nhìn thấy một từ. Đối với một câu hỏi khó, đây là khoản chi tiêu xứng đáng. Về câu hỏi "phí bảo hiểm là bao nhiêu?", cần ba bước nhảy mạng để trả về một giá trị mà việc khớp từ khóa đã xác định được ngay từ lần đầu tiên. Độ trễ là có thật và đó là phần người dùng cảm nhận được. Chi phí token cho mỗi lần gọi nhỏ hơn, nhưng nó được tính phí cho mọi câu hỏi, mãi mãi, và những câu hỏi dễ lại là những câu hỏi người dùng lặp lại nhiều nhất. Trước khi bất kỳ trong ba cuộc gọi đó được thực hiện, quy trình có thể đưa ra một quyết định mà không cần gọi mô hình, từ câu hỏi đã được phân tích cú pháp và dữ liệu `line_df` của tài liệu: liệu câu hỏi này có thể được trả lời chỉ bằng đường dẫn từ khóa hay không? Quyết định này cần một tín hiệu. Nó phải rẻ, vì mục đích chính là không tốn kém gì khi câu trả lời dễ, và nó phải trung thực, vì một bộ định tuyến gửi một câu hỏi khó đi theo đường dẫn nhanh sẽ trả về một câu trả lời sai nhưng tự tin, chính xác là lỗi mà chuỗi bài viết này cố gắng tránh. 2. Không phải mọi câu hỏi đều cần mô hình Tín hiệu đã có sẵn trong quy trình. Hệ thống truy xuất chấm điểm từng dòng dựa trên mức độ các từ khóa của câu hỏi cùng xuất hiện trên đó, và điểm số đó, trước bất kỳ cuộc gọi trọng tài hay tạo sinh nào, đã phân tách những câu hỏi tự trả lời được khỏi những câu hỏi không. 2.1 Một câu hỏi tự trả lời Lấy ví dụ câu hỏi "phí bảo hiểm hàng năm là bao nhiêu?" đối với một hợp đồng bảo hiểm nhà ở. Bộ chấm điểm từ khóa xác định từ Bài viết 7 (truy xuất dưới dạng lọc trên `line_df`), `co_occurrence_score`, đếm số lượng từ khóa của câu hỏi xuất hiện trên mỗi dòng, trọng số một thuật ngữ chính (`premium` - phí bảo hiểm) cùng với các tín hiệu phụ cho thấy một câu trả lời thực sự (EUR, `annual` - hàng năm, `payable` - phải trả). Chạy nó và một dòng sẽ thắng tuyệt đối. Dòng trên cùng, "Phí bảo hiểm hàng năm là 1.200 EUR, phải trả...", đạt 5 điểm. Mọi dòng khác đều đạt 0 điểm. Một người thắng cuộc rõ ràng, với chênh lệch 5 điểm so với người về nhì, và dòng thắng cuộc đã mang hình dạng của câu trả lời, một loại tiền tệ và một số tiền. Không có gì để mô hình phải làm rõ. Đường dẫn từ khóa đã trả lời câu hỏi, và một cuộc gọi tạo sinh ở đây sẽ chỉ định dạng lại một giá trị đã được xác định. 2.2 Một câu hỏi cần mô hình Bây giờ hãy hỏi "tôi có thể tránh những đảm bảo nào trong trường hợp của mình?" đối với cùng một hợp đồng bảo hiểm. Bộ chấm điểm từ khóa chạy theo cùng một cách, nhưng kết quả khác về bản chất. Ba dòng hòa nhau ở điểm 2: hai đảm bảo tùy chọn và dòng đề cập đến việc điều chỉnh chúng. Chênh lệch giữa vị trí thứ nhất và thứ hai là 0. Không có dòng nào nổi bật, vì câu hỏi không yêu cầu một dòng cụ thể. "Trong trường hợp của tôi" yêu cầu mô hình cân nhắc tình huống của người dùng với một số đảm bảo tùy chọn và suy luận xem những đảm bảo nào có thể bỏ qua một cách an toàn. Điều đó