Kapa tối ưu RAG: Dùng LLM nhỏ để lọc 68% ngữ cảnh thừa mà vẫn giữ 96% độ chính xác

Kapa xây dựng các trợ lý AI có khả năng trả lời những câu hỏi phức tạp dựa trên các cơ sở tri thức sản phẩm quy mô lớn. Hãy hình dung đến tài liệu kỹ thuật, tài liệu tham khảo API, tệp PDF, diễn đàn và các chuỗi thảo luận hỗ trợ. Các nhà phát triển sử dụng API truy xuất của chúng tôi để cung cấp ngữ cảnh về sản phẩm cho các tác nhân (agent) của họ, và chính lớp truy xuất đó cũng vận hành các trợ lý end-to-end của chúng tôi.

Bất chấp mọi tranh luận trong năm 2026 về việc liệu các tác nhân có còn cần RAG hay không, trong lĩnh vực của chúng tôi, không gì có thể sánh bằng khi các cơ sở tri thức trở nên lớn và phức tạp. Quá trình truy xuất của chúng tôi có nhiều hình thức, một số mang tính tác nhân (agentic), một số là truy xuất một lần (single-pass), nhưng tất cả đều có chung một cấu trúc: một bộ truy xuất (retriever) giúp tìm ra các đoạn tài liệu liên quan đến câu hỏi, và một bộ tạo (generator) – chính là LLM – giúp viết câu trả lời từ những đoạn đó.

Tóm tắt ngắn gọn bài viết này: chúng tôi đã thêm một bước thứ ba vào giữa hai bước trên. Một mô hình LLM nhỏ, chi phí thấp sẽ đọc câu hỏi cùng tất cả các đoạn văn bản đã truy xuất, sau đó loại bỏ những đoạn không cần thiết trước khi mô hình đắt tiền kịp nhìn thấy chúng. Cách này giúp loại bỏ khoảng 68% ngữ cảnh, duy trì khoảng 96% độ chính xác (recall) và cắt giảm 1/3 chi phí cho mỗi truy vấn, ngay cả khi đã tính đến chi phí vận hành của chính nó. Bài viết này giải thích cách chúng tôi đạt được kết quả đó.

Các đoạn văn bị bỏ qua vẫn tốn chi phí

Bộ truy xuất giống như một cái phễu. Việc nhúng (embedding) và tìm kiếm theo từ khóa giúp thu hẹp cơ sở tri thức từ hàng trăm nghìn đoạn văn xuống còn vài trăm ứng viên, sau đó một bộ xếp hạng lại (reranker) sẽ sắp xếp chúng, và khoảng 15 đoạn hàng đầu sẽ được gửi đến bộ tạo – mô hình lớn và đắt đỏ nhất trong chuỗi. Ngay cả khi đó, phần lớn những gì bộ tạo đọc đều không cần thiết cho câu hỏi. Điều này là có chủ đích: các bộ truy xuất hướng tới độ chính xác tối đa và tin tưởng rằng bộ tạo sẽ biết cách bỏ qua những thông tin nhiễu.

Tuy nhiên, bộ tạo vẫn bị tính phí cho mỗi đoạn văn mà nó bỏ qua. Trong các trợ lý của chúng tôi, các đoạn văn được truy xuất chiếm khoảng 2/3 chi phí của một truy vấn, nhiều hơn cả chi phí cho câu trả lời, lịch sử hội thoại và lời nhắc hệ thống (system prompt) cộng lại. Mỗi đoạn văn được cắt giảm sẽ giúp giảm khoảng 4% chi phí truy vấn. Và trong một tác nhân, mỗi lần gọi công cụ (tool call) đều đổ kết quả của nó vào cùng một ngữ cảnh, khiến ngữ cảnh tăng lên nhanh chóng; kết quả truy xuất tinh gọn hơn sẽ tạo không gian cho mọi thứ khác mà tác nhân cần lưu trữ và giảm bớt lượng ngữ cảnh dư thừa.

Vấn đề nằm ở độ chính xác (recall). Nếu loại bỏ một đoạn văn cần thiết cho câu trả lời, bạn đã đánh đổi vài xu lấy một câu trả lời sai. Một bộ cắt tỉa (pruner) chỉ tốt khi sự đánh đổi đó đạt hiệu quả: nén được bao nhiêu dữ liệu trên mỗi điểm recall bị mất đi.

Giải pháp hiển nhiên lại không hiệu quả

Chúng tôi đã thực hiện xếp hạng lại trước khi trả về top K, vì vậy đôi khi chúng tôi được yêu cầu chỉ cần hiển thị điểm số xếp hạng lại và để người gọi tự cắt giảm dựa trên đó: giữ lại mọi thứ trên 0.7, loại bỏ phần còn lại. Cách này thất bại vì hai lý do, và lý do thứ hai đã định hình mọi thứ chúng tôi xây dựng.

Thứ nhất, điểm số xếp hạng lại là một thứ tự, không phải là một phép đo. Nó chỉ cho biết đoạn A tốt hơn đoạn B đối với truy vấn này, không hơn không kém. Các điểm số này không được hiệu chuẩn (calibrate) giữa các truy vấn, chính Cohere cũng thừa nhận điều đó, vì vậy không có ngưỡng cắt cố định nào hiệu quả. Ngưỡng duy nhất mà việc xếp hạng hỗ trợ là theo vị trí (top-N), và cách này sẽ loại bỏ đoạn cuối cùng bất kể đó là nhiễu hay là câu trả lời.

Thứ hai, và điều này vẫn đúng ngay cả khi có sự hiệu chuẩn hoàn hảo: mức độ liên quan không phải là thuộc tính của một đoạn văn đơn lẻ. Các bộ xếp hạng lại trong hầu hết các quy trình là các cross-encoder theo từng điểm (pointwise). Chúng chấm điểm từng cặp truy vấn-đoạn văn một cách độc lập, không bao giờ đặt chúng cạnh các đoạn văn khác được truy xuất cùng lúc. Dưới đây là một ví dụ thực tế đã được ẩn danh:

Đoạn văn thứ hai không hề nhắc đến "audit logs", nên nó bị chấm điểm là nhiễu, nhưng thực tế nó lại chứa một nửa câu trả lời, và không điểm số pointwise nào có thể thấy được điều đó, vì đoạn văn chỉ liên quan khi đặt cạnh đoạn thứ nhất. Các đoạn văn cũng thường chia nhỏ các câu hỏi nhiều phần, mỗi đoạn đứng riêng lẻ đều vô dụng. Câu hỏi thực sự không bao giờ là liệu một đoạn văn có liên quan khi đứng một mình hay không, mà là liệu nó có thuộc về một tập hợp cùng nhau trả lời được câu hỏi đó hay không.

Một giải pháp thông minh nhưng thất bại theo cùng một cách

Trước khi từ bỏ bộ xếp hạng lại, chúng tôi đã thử dùng các tài liệu neo (anchor documents - Sinhababu và cộng sự): làm cho thang điểm của bộ xếp hạng lại trở nên tuyệt đối bằng cách chèn các đoạn văn tổng hợp (synthetic chunks) đã biết rõ mức độ liên quan vào bảng xếp hạng, mỗi đoạn được viết cho một cấp độ từ "Thiết yếu" đến "Không liên quan", sau đó loại bỏ mọi đoạn văn thực tế xếp hạng dưới mức của đoạn neo thấp nhất mà bạn muốn giữ. Đây là một lần gọi LLM bổ sung trên nền tảng xếp hạng lại mà bạn đã chạy, và thực sự rất tinh tế.

Nó không hiệu quả, vì cùng một lý do cơ bản. Các đoạn neo giúp hiệu chuẩn thang điểm, nhưng chúng không thể sửa được điểm số, và bộ xếp hạng lại vẫn tiếp tục đặt các đoạn văn liên quan một phần hoặc gián tiếp xuống dưới các đoạn văn hoàn toàn không liên quan. Để giữ lại chúng, đoạn neo phải được đặt ở mức thấp đến mức hầu như không có gì bị cắt tỉa cả.

Sự thất bại đó lại là kết quả hữu ích: bất cứ thứ gì thực hiện cắt tỉa đều phải nhìn thấy câu hỏi và tất cả các đoạn văn cùng một lúc, vì thứ cần được đánh giá chính là tập hợp đó.

Vì vậy, chúng tôi để LLM chấm điểm các đoạn văn

Những gì chúng tôi đã triển khai là một lần gọi LLM theo danh sách (listwise) giữa bộ xếp hạng lại và bộ tạo. Nó nhận câu hỏi và tất cả các đoạn văn, sau đó chấm điểm từng đoạn dựa trên thang năm cấp độ được viết trong lời nhắc (prompt):

Điểm LLM

Cấp độ

Ý nghĩa

THIẾT YẾU (ESSENTIAL)

Không thể tạo ra câu trả lời nếu thiếu đoạn này, dù nó trả lời trực tiếp hay là một định nghĩa/điều kiện tiên quyết mà các đoạn khác phụ thuộc vào.

ĐÓNG GÓP (CONTRIBUTING)

Không tự trả lời được, nhưng cung cấp thông tin cần thiết cho một câu trả lời hoàn chỉnh khi kết hợp với các đoạn khác.

HỖ TRỢ (SUPPORTING)

Đúng chủ đề và có vẻ hữu ích, nhưng câu trả lời có khả năng vẫn hoàn chỉnh nếu thiếu nó.

LIÊN QUAN GIÁN TIẾP (TANGENTIAL)

Cùng lĩnh vực hoặc chia sẻ thuật ngữ, nhưng không đóng góp cụ thể.

KHÔNG LIÊN QUAN (UNRELATED)

Không có kết nối ý nghĩa nào.

Các đoạn văn đạt ngưỡng trở lên sẽ được giữ lại. Thiết kế này giải quyết cả hai thất bại trước đó. Vì mỗi cấp độ được định nghĩa bằng từ ngữ, điểm 4 sẽ có ý nghĩa như nhau trong mọi truy vấn, vì vậy một ngưỡng cắt cố định cuối cùng đã hiệu quả. Và vì mô hình nhìn thấy câu hỏi cùng tất cả các đoạn văn cùng lúc, nó có thể đánh giá cả tập hợp, giúp các đoạn văn liên quan một phần hoặc gián tiếp cuối cùng cũng có chỗ đứng.

Ba yếu tố cần lưu ý:

Mô hình: bộ cắt tỉa được chi trả bằng chính số tiền nó tiết kiệm được, vì vậy các mô hình hàng đầu (flagship) bị loại trừ ngay từ đầu; các mô hình nhỏ, nhanh đều cho kết quả tương đương, vì vậy chúng tôi chọn mô hình nhanh nhất và rẻ nhất với mức độ suy luận thấp.

Ngưỡng (threshold): nút điều chỉnh chính giữa khả năng nén và độ chính xác (recall).

keep-top-k: một vài đoạn văn hàng đầu sau khi xếp hạng lại sẽ được giữ lại bất kể điểm số, nhằm bảo vệ các đoạn văn quan trọng nhất khỏi sai sót khi chấm điểm.

Chúng tôi cũng đã chạy thử hai thiết kế đơn giản hơn để đảm bảo tính khách quan. Budget-select: giữ lại một vài đoạn hàng đầu, để LLM thêm tối đa N đoạn nữa; kích thước có thể dự đoán được, nhưng một khi đã hết ngân sách, mọi đoạn văn tiếp theo đều bị loại bỏ bất kể chúng liên quan đến mức nào. Và bộ cắt tỉa đơn giản nhất có thể: chỉ cần hỏi LLM nên giữ lại những đoạn nào, không dùng thang điểm. Nếu một phương án không thể vượt qua việc hỏi trực tiếp, thì nó không đáng để xây dựng.