Hầu hết các hướng dẫn về RAG đều chỉ dừng lại ở mức demo. Bạn chia nhỏ dữ liệu (chunking) theo số lượng token, nhồi tất cả vào một cơ sở dữ liệu vector, và coi như xong việc. Cách này hiệu quả khi người dùng hỏi "Chính sách đổi trả là gì?" trong một bộ FAQ sạch sẽ. Nhưng nó sẽ thất bại khi ai đó dán nửa bản hợp đồng và hỏi về điều khoản thứ ba, hoặc khi một lập trình viên nhập một mã lỗi khó hiểu vào thanh tìm kiếm tài liệu.

Các cửa sổ token cố định làm cắt ngang các thỏa thuận pháp lý ngay giữa câu. Các chunk lớn chôn vùi các tham chiếu API dưới những đoạn văn nhiễu thông tin. Tệ nhất là việc truy xuất chậm khiến người dùng từ bỏ truy vấn trước khi mô hình kịp bắt đầu tạo câu trả lời. Chúng tôi đã học được bài học này một cách xương máu. Khi chúng tôi chuyển lớp truy xuất từ việc "hy vọng" sang "đo lường", chúng tôi đã giảm độ trễ xuống 40% và đẩy tỷ lệ recall lên 95%. Dưới đây là chính xác những gì đã thay đổi.

Chia nhỏ thông minh (Smart Chunking)

Đừng coi kích thước chunk là một con số thần kỳ. Một cửa sổ 512 token là vô nghĩa đối với một tài liệu pháp lý nơi một điều khoản duy nhất trải dài qua nhiều đoạn văn, và nó cũng vô dụng tương tự đối với tài liệu API nơi chữ ký hàm (function signature) và phần mô tả hai dòng của nó cần phải đi cùng nhau. Chúng tôi đã chuyển sang phương pháp chia nhỏ dựa trên cấu trúc (structure-aware splitting).

Đối với văn bản pháp lý, phương pháp chia nhỏ đệ quy (recursive chunking) tôn trọng phân cấp tài liệu. Các điều khoản được giữ nguyên vẹn. Đối với tài liệu API, chúng tôi sử dụng phương pháp chia nhỏ dựa trên hàm (function-aware splitting) để giữ các chữ ký, tham số và ví dụ đi cùng nhau như các đơn vị nguyên tử (atomic units). Các phiếu hỗ trợ (support tickets) và dữ liệu hội thoại cần các ranh giới ngữ nghĩa, chia nhỏ tại nơi chủ đề thay đổi thay vì tại một số lượng ký tự tùy ý. Kết quả là mỗi chunk mang đủ ngữ cảnh để hữu ích nhưng không quá nhiều đến mức làm loãng tín hiệu. Mô hình embedding của bạn có ngân sách chú ý (attention budget) hạn chế. Hãy sử dụng nó một cách khôn ngoan.

Truy xuất hỗn hợp (Hybrid Retrieval)

Tìm kiếm vector (Vector search) rất xuất sắc trong việc tìm nội dung tương đồng về mặt khái niệm. Hỏi về các truy vấn cơ sở dữ liệu chậm và nó sẽ hiển thị các hướng dẫn tối ưu hóa hiệu suất. Nhưng nếu hỏi về "Error 0x80070057", tìm kiếm ngữ nghĩa sẽ lạc sang những vùng không liên quan vì dense embeddings không xử lý tốt các khớp chính xác (exact matches). Ngược lại, BM25 xử lý cực tốt các chuỗi chính xác và các thuật ngữ hiếm, nhưng nó lại không biết rằng "latency" và "slow response time" có cùng ý nghĩa.

Chúng tôi chạy cả hai song song và hợp nhất chúng bằng Reciprocal Rank Fusion (RRF). RRF rất đơn giản và hiệu quả. Nó lấy các danh sách xếp hạng từ mỗi phương pháp và chấm điểm các tài liệu dựa trên vị trí của chúng, tạo cơ hội công bằng cho các ứng viên tiềm năng từ cả hai hệ thống. Sau khi hợp nhất, chúng tôi chạy một bộ xếp hạng lại (reranker) cross-encoder trên các kết quả kết hợp và chỉ trả về năm kết quả hàng đầu. Bộ reranker này làm tăng độ trễ thêm khoảng 50 mili giây nhưng đã cải thiện tỷ lệ recall của chúng tôi thêm 15%. Sự đánh đổi đó mang lại giá trị gấp nhiều lần về chất lượng tạo câu trả lời.

Mở rộng truy vấn (Query Expansion)

Người dùng thường rất tệ trong việc đặt câu hỏi truy vấn. Họ viết tắt, viết sai chính tả, hoặc nhồi nhét ba câu hỏi vào một đoạn văn dài dòng. Nếu bạn tìm kiếm chính xác những gì họ đã nhập, bạn sẽ bỏ lỡ những tài liệu mà họ thực sự cần.

Giờ đây, chúng tôi biến đổi mọi truy vấn trước khi nó được đưa vào chỉ mục (index). Đầu tiên, chúng tôi tạo ra nhiều phiên bản diễn đạt lại của câu hỏi gốc để bao quát các từ đồng nghĩa và cách diễn đạt thay thế. Thứ hai, chúng tôi phân tách các câu hỏi phức tạp thành các câu hỏi phụ nhỏ hơn. Một truy vấn như "Tại sao việc hoàn tiền cho khách hàng quốc tế lại thất bại và làm thế nào để khắc phục?" sẽ trở thành hai tìm kiếm riêng biệt: một về lỗi hoàn tiền quốc tế và một về các bước khắc phục. Chỉ riêng việc mở rộng truy vấn đã giúp nâng tỷ lệ recall của chúng tôi từ 78% lên 94%. Bài học rất đơn giản: đừng tin vào bản nháp đầu tiên của người dùng. Hãy giúp họ.

Ngừng đoán mò, hãy bắt đầu tìm kiếm

Kích thước chunk, tỷ lệ chồng lấp (overlap percentage), ngưỡng cắt top-k và độ sâu của reranker tương tác với nhau theo những cách không thể tinh chỉnh bằng tay. Chúng tôi đã tốn quá nhiều thời gian để tranh luận xem 256 token có tốt hơn 512 hay không, trong khi lại bỏ qua cài đặt overlap vốn đang thực sự phá hủy tính mạch lạc.

Chúng tôi đã thay thế trực giác bằng tối ưu hóa Bayesian (Bayesian optimization). Thay vì tìm kiếm lưới (grid search) — vốn lãng phí tài nguyên tính toán vào các vùng rõ ràng là không hiệu quả — các phương pháp Bayesian xây dựng một mô hình xác suất về những gì hoạt động tốt và chủ động tìm kiếm biên Pareto (Pareto frontier) nhằm tối đa hóa recall trong khi vẫn giảm thiểu độ trễ. Đối với hệ thống của chúng tôi, điều đó có nghĩa là tìm ra sự kết hợp cụ thể giữa kích thước chunk, độ chồng lấp và top-k để đạt được tỷ lệ recall 95% mà không vượt quá ngân sách độ trễ. Các

Những con số đã nói lên tất cả. Chỉ số Recall@10 của chúng tôi đã tăng từ 78% lên 95%. Độ trễ p95 đã giảm từ 850 mili giây xuống còn 320 mili giây. Và vì cuối cùng mô hình đã nhận được ngữ cảnh liên quan thay vì nhiễu, tỷ lệ ảo giác (hallucination rate) đã giảm từ 12% xuống còn 3%. Khả năng truy xuất tốt hơn không chỉ giúp câu trả lời nhanh hơn. Nó còn giúp chúng trở nên chính xác.

Việc cần làm tiếp theo

Nếu bạn đang xây dựng lại lớp truy xuất (retrieval layer) của mình, hãy bắt đầu tại đây:

  • Chia nhỏ (chunk) theo cấu trúc tài liệu, không phải theo số lượng token. Hãy điều chỉnh chiến lược chia nhỏ sao cho phù hợp với hình thái dữ liệu của bạn.
  • Sử dụng truy xuất hỗn hợp (hybrid retrieval). Kết hợp tìm kiếm vector và BM25, hợp nhất bằng Reciprocal Rank Fusion, và thực hiện xếp hạng lại (rerank) trước khi tạo câu trả lời.
  • Mở rộng truy vấn để có độ bao phủ tốt hơn. Diễn đạt lại và phân tách truy vấn trước khi thực hiện tìm kiếm.
  • Xây dựng bộ dữ liệu chuẩn (golden dataset) để kiểm thử. Bạn không thể tối ưu hóa những gì bạn không đo lường được.
  • Tối ưu hóa các tham số bằng các công cụ tự động. Tìm kiếm Bayesian (Bayesian search) sẽ tìm ra các thiết lập tốt hơn là dựa vào cảm tính của bạn.

Truy xuất không phải là một tệp cấu hình mà bạn chỉ thiết lập một lần rồi bỏ mặc. Nó là một phần của hạ tầng, và hạ tầng xứng đáng được xử lý nghiêm ngặt như mã nguồn production: kiểm thử, đo lường và tối ưu hóa liên tục. Hãy đối xử với nó như vậy, và hệ thống RAG của bạn sẽ không còn là một bản demo nữa mà sẽ thực sự trở thành một sản phẩm.

Cộng đồng học tập tùy chọn: GyaanSetu AI