Cách cắt chunk quyết định chất lượng RAG nhiều hơn cả mô hình bạn chọn
Hệ thống truy hồi chỉ tốt bằng đúng những đoạn văn nó đưa cho mô hình. Nếu câu trả lời nằm trong một đoạn đã bị cắt đôi lúc nạp dữ liệu, mô hình mạnh đến đâu cũng không cứu được.
Cắt theo kích thước cố định làm mất chính thứ bạn cần tìm
Cắt theo số ký tự dễ triển khai và dễ hình dung, nên hầu hết dự án đều bắt đầu như vậy. Nhưng nó cũng cắt ngang giữa điều khoản, giữa dòng bảng và giữa danh sách đánh số. Một điều khoản hợp đồng ghi "mỗi bên có quyền chấm dứt sau ba mươi ngày thông báo bằng văn bản" bị tách thành hai chunk, và không chunk nào tự trả lời được câu hỏi.
Ưu tiên cấu trúc trước, kích thước sau
Thứ tự chạy tốt trong thực tế:
- Tôn trọng cấu trúc sẵn có của tài liệu — tiêu đề, mục danh sách, dòng bảng, điều khoản hợp đồng.
- Gộp các đơn vị liền kề cho tới khi tiệm cận kích thước mục tiêu.
- Chỉ cắt cứng khi một đơn vị thực sự quá lớn.
Cách này giữ nguyên đơn vị ngữ nghĩa và coi giới hạn kích thước là trần, không phải một cái lưới chia đều.
Overlap là miếng vá, không phải thiết kế
Cho các chunk chồng lấn vài trăm token che bớt được thiệt hại của cách cắt cố định, đổi lại phải lưu trùng văn bản và đẩy nội dung lặp vào ngữ cảnh mô hình. Nên có, nhưng nếu overlap đang gánh phần lớn chất lượng thì thứ cần sửa là bộ chunker.
Đo trước, tinh chỉnh sau
Hai chỉ số dịch chuyển rõ nhất khi đổi cách chunk là mức bám nguồn và độ phủ trích dẫn. Hãy dựng một tập đánh giá nhỏ gồm câu hỏi thật kèm nguồn đúng đã biết, rồi thay đổi từng yếu tố một. Phần lớn các đội thấy mức cải thiện ở đây lớn hơn bất kỳ lần đổi mô hình nào.