Tóm tắt
Kapa thêm một bước context pruning giữa reranker và generator trong pipeline RAG. Một LLM nhỏ đọc câu hỏi cùng toàn bộ chunk đã retrieve, chấm từng chunk theo vai trò của nó trong câu trả lời, rồi bỏ các chunk không cần thiết trước khi gọi model lớn.
Cấu hình họ chọn bỏ khoảng 68% context, giữ 96% recall trên tập câu hỏi đã gán nhãn, và giảm khoảng 34% chi phí mỗi query sau khi tính cả chi phí của pruner. Đổi lại, hệ thống thêm khoảng 0,7 giây latency cho mỗi query.
Vấn đề: chunk bị bỏ qua vẫn tốn tiền
Trong RAG, retriever thường ưu tiên recall: lấy nhiều chunk hơn mức cần thiết để giảm nguy cơ thiếu thông tin. Reranker sắp xếp lại kết quả, rồi top K được đưa vào generator.
Cách này an toàn nhưng đắt. Với assistant của Kapa, retrieved chunks chiếm khoảng hai phần ba chi phí của một query, nhiều hơn cả câu trả lời, lịch sử hội thoại và system prompt cộng lại. Mỗi chunk bớt đi giảm khoảng 4% chi phí query.
Trong agent, vấn đề còn nặng hơn vì mỗi tool call lại đổ thêm output vào context. Context càng phình, model càng tốn tiền và càng dễ phải xử lý nhiều noise.
Vì sao chỉ dùng rerank score không đủ
Giải pháp dễ nghĩ tới là đặt ngưỡng cho rerank score: chunk nào dưới 0,7 thì bỏ. Kapa nói cách này thất bại vì hai lý do.
Thứ nhất, rerank score thường là thứ hạng tương đối, không phải measurement đã calibrate giữa các query. Một score 0,7 ở query này không chắc cùng nghĩa với 0,7 ở query khác.
Thứ hai, relevance không phải thuộc tính của từng chunk riêng lẻ. Có chunk không trả lời trực tiếp câu hỏi nhưng là định nghĩa hoặc nửa còn lại của câu trả lời. Pointwise reranker chỉ nhìn query và một chunk, nên không thấy chunk đó quan trọng khi kết hợp với chunk khác.
Kapa cũng thử anchor documents: chèn các chunk synthetic với mức độ liên quan đã biết để calibrate thang điểm. Cách này xử lý phần calibration, nhưng không xử lý được lỗi gốc: reranker vẫn không đánh giá được vai trò của chunk trong cả tập context.
Thiết kế: để LLM chấm cả danh sách chunk
Kapa đưa vào một call listwise LLM. Model nhận câu hỏi và toàn bộ chunk, rồi chấm từng chunk theo thang 5 mức:
- 5 Essential: Không có chunk này thì không trả lời được.
- 4 Contributing: Không đủ để trả lời một mình, nhưng cung cấp thông tin cần thiết khi kết hợp với chunk khác.
- 3 Supporting: Cùng chủ đề và có thể giúp ích, nhưng câu trả lời nhiều khả năng vẫn hoàn chỉnh nếu thiếu nó.
- 2 Tangential: Cùng domain hoặc cùng thuật ngữ, nhưng không đóng góp cụ thể.
- 1 Unrelated: Không liên quan thực chất.
Các chunk đạt ngưỡng sẽ được giữ lại. Kapa còn giữ top vài chunk theo reranker bất kể grade để giảm rủi ro pruner bỏ nhầm chunk mạnh nhất.
Có ba knob chính:
- Model: phải nhỏ và rẻ, vì pruner được trả bằng phần tiền nó tiết kiệm.
- Threshold: điều chỉnh tradeoff giữa compression và recall.
- keep-top-k: bảo vệ các chunk đứng đầu khỏi lỗi grading.
Kết quả đo được
Kapa đánh giá trên tập câu hỏi thật có nhãn chunk cần thiết, rồi replay cấu hình trên một tháng hội thoại production.
Ở mức 98% recall, cắt top-N đơn giản chỉ bỏ được khoảng 7% chunk. Các chiến lược dùng LLM đều vượt xa baseline này; scoring theo thang 5 mức là đường Pareto tốt nhất.
Cấu hình production của họ nằm gần phía aggressive:
- Bỏ khoảng 68% retrieved chunks.
- Giữ khoảng 96% recall.
- Một trong khoảng 25 câu hỏi mất một chunk cần thiết.
- Giảm khoảng 34% chi phí mỗi query, đã tính cả pruner.
Latency và nơi nên bật
Pruner nằm trên critical path nên thêm latency trực tiếp. Cấu hình Kapa chọn chạy khoảng 0,7 giây/query. Việc generator đọc ít token hơn chỉ bù được một phần nhỏ, không đủ triệt tiêu call mới.
Vì vậy, pruning hợp lý nhất ở các agent có nhiều tool call và context dài. Trong single-shot chat path cần phản hồi cực nhanh, 0,7 giây có thể là giá phải cân nhắc kỹ.
Kapa bật mặc định tính năng này trong Product Agent SDK cho knowledge base search, và để tùy chọn trong retrieval API và MCP servers.
Dev nên rút gì ra
Bài này có một thông điệp khá thực dụng: tối ưu RAG không chỉ là chọn embedding tốt hơn hay reranker mạnh hơn. Khi context đã qua nhiều tầng retrieve/rerank, phần tốn tiền nhất có thể là noise còn sót lại trong top K.
Nếu hệ thống của bạn có retrieval over docs, support thread hoặc tool output dài, hãy đo ba số cùng lúc: compression, recall và latency. Chỉ giảm token mà không đo recall là tự mua bug. Chỉ giữ recall mà không đo chi phí thì RAG sẽ tiếp tục đốt tiền trong im lặng.