Recall/Precision: Đánh Đổi Quyết Định Chất Lượng Retrieval

Yêu cầu một pipeline RAG lấy về nhiều chunk hơn, và một điều thú vị xảy ra: khả năng bắt được đúng chunk trả lời được câu hỏi tăng lên, còn khả năng một chunk bất kỳ trong số đó thực sự liên quan lại giảm xuống. Cả hai điều đều đúng cùng lúc, đi ngược chiều nhau, từ cùng một núm vặn duy nhất. Núm vặn đó là top-k, và coi nó như một con số cần tinh chỉnh thay vì hai chỉ số đối lập cần cân bằng chính là lý do rất nhiều pipeline RAG hoặc bỏ lỡ câu trả lời đáng lẽ tìm được, hoặc nhấn chìm model trong ngữ cảnh không liên quan.

Recall và precision không phải một điểm số "chất lượng retrieval" duy nhất - đó là hai câu hỏi khác nhau, và một pipeline hoàn toàn có thể xuất sắc ở chỉ số này mà thất bại nặng ở chỉ số kia.

Vì Sao Recall Và Precision Kéo Ngược Chiều Nhau

Recall hỏi: trong tất cả các chunk thực sự giúp trả lời được câu hỏi này, chúng ta đã lấy về bao nhiêu? Precision hỏi: trong tất cả những gì đã lấy về, bao nhiêu phần trong đó thực sự hữu ích? Mở rộng top-k chỉ có thể thêm chunk, không bao giờ bớt đi những chunk đã lấy - nên recall chỉ có thể tăng hoặc giữ nguyên khi k tăng, còn precision, bị pha loãng bởi mỗi chunk không liên quan thêm vào, chỉ có thể giảm hoặc giữ nguyên. Đây không phải lỗi của một pipeline hay embedding model cụ thể nào - đó là hệ quả toán học trực tiếp từ cách hai chỉ số này được định nghĩa theo k.

Vì Sao Recall Phải Thắng Trước

Một kết quả retrieval precision thấp vẫn đưa cho model đúng thông tin cần thiết, chỉ là bị chôn trong nhiễu phải lọc qua - đây là vấn đề giải được, vì các model hiện đại khá giỏi bỏ qua ngữ cảnh không liên quan khi phần liên quan vẫn có mặt. Một kết quả retrieval recall thấp thì không đưa cho model thứ nó cần, và không có cách nào sửa được sau đó: không reranker nào đẩy được lên một tài liệu chưa từng nằm trong tập ứng viên, và không kỹ thuật prompt nào khiến LLM bịa ra được sự thật nó chưa từng được thấy. Đây chính là lý do các nghiên cứu đánh giá retrieval (như loạt bài RAG evaluation của Pinecone) coi recall là chỉ số cần tối ưu trước - vấn đề precision khiến bạn mất một ít độ sạch; vấn đề recall khiến bạn mất luôn câu trả lời.

Cái Giá Thật Sự Của Việc Mở Rộng Top-k

Đẩy k lên cao để đuổi theo recall không hề miễn phí, kể cả sau khi recall đã chạm trần. Mỗi chunk thêm vào context là thêm token phải embed, thêm token phải trả phí lúc generate, và thêm nội dung mà model phải tự nhận diện đúng là không liên quan thay vì dùng nó. Phần cuối này không được đảm bảo - một context lớn, nhiễu làm tăng khả năng model bám vào một chunk trông có vẻ hợp lý nhưng sai, hoặc trộn lẫn chi tiết từ một tài liệu không liên quan vào một câu trả lời vốn dĩ đúng. Coi top-k là một ngân sách cần chi tiêu có chủ đích, không phải một núm vặn kéo lên tối đa "cho chắc".

Tự Đo Đường Cong Recall/Precision Của Chính Mình

Tất cả những điều trên vô nghĩa nếu không có cách đo trên chính tài liệu và câu hỏi của bạn. Cần một tập đánh giá nhỏ với đáp án đúng đã biết - một tập câu hỏi thực tế đi kèm đúng những chunk cần được lấy về để trả lời chúng - dựng theo cách y hệt error analysis dựng ra một failure taxonomy: từ traffic thực tế, không phải edge case tự nghĩ ra. Khi đã có ground truth đó, tính recall@k và precision@k trên một dải giá trị k (3, 5, 10, 20...) biến "cảm giác retrieval có vẻ ổn" thành một đường cong đọc được thật sự, và biến "cứ đặt k = 10 đi" thành một quyết định có căn cứ dựa trên chỗ đường cong đó thực sự bão hoà.

Reranking Phù Hợp Ở Đâu (Và Không Phù Hợp Ở Đâu)

Một reranker đứng sau bước retrieval ban đầu, sắp xếp lại một tập ứng viên rộng hơn để đẩy các chunk liên quan nhất lên đầu, giúp bước generation chỉ dùng một lát cắt nhỏ hơn, precision cao hơn từ những gì đã lấy về. Đây là một pattern thực sự hữu ích - retrieve rộng (k cao, ưu tiên recall), rồi rerank xuống một tập hẹp hơn (ưu tiên precision) trước khi generate - nhưng nó chỉ hoạt động trên những tài liệu đã lọt vào tập ứng viên ban đầu ngay từ đầu. Reranker không thể cứu vãn recall; nó chỉ có thể cải thiện precision dựa trên bất kỳ mức recall nào mà bước retrieval đầu tiên đã đạt được. Nếu recall của retrieval ban đầu thấp, reranker chỉ đang sắp xếp lại một tập vốn đã thiếu mất câu trả lời.

Chọn Top-k Cho Chính Pipeline Của Bạn

Không có một giá trị top-k đúng phổ quát, nhưng có một thứ tự thao tác đúng: đo recall@k trên một dải giá trị k trong tập đánh giá của chính bạn, tìm giá trị k nhỏ nhất mà tại đó recall chạm gần trần với tập tài liệu và loại câu hỏi của bạn, rồi mới quyết định precision ở mức k đó đã đủ tốt để generate trực tiếp hay cần thêm bước rerank. Tập tài liệu có nội dung trùng lặp/chồng chéo cao cần k nhỏ hơn để đạt recall cao; tập tài liệu thưa, mỗi chủ đề chỉ có một nguồn duy nhất thường cần k lớn hơn. Đo lại bước này mỗi khi tập tài liệu nền hoặc chiến lược chunking thay đổi, vì cả hai đều dịch chuyển điểm bão hoà thật sự của đường cong recall.

Những Sai Lầm Thường Gặp Khi Tinh Chỉnh Recall/Precision

Một vài sai lầm lặp lại ở đây: chọn một giá trị top-k một lần duy nhất từ sớm trong quá trình phát triển rồi không bao giờ đo lại khi tập tài liệu lớn lên; coi một phàn nàn về precision ("context trông nhiễu quá") là tín hiệu để giảm k, trong khi cách sửa đúng thường là thêm bước rerank; giả định một LLM lớn hơn, mạnh hơn có thể bù đắp được recall thấp, trong khi không model nào trả lời được từ thông tin nó chưa từng được cấp; và bỏ qua hẳn bước dựng tập đánh giá, tinh chỉnh k theo cảm tính qua vài câu hỏi kiểm tra thủ công. Recall và precision đều đo được, và những pipeline chọn đúng top-k là những pipeline chịu đo thay vì đoán.