Cải thiện sự chính xác cho giải pháp RAG của bạn (P1)

Bước đầu tiên bạn hãy bỏ qua những bài post trên mạng xã hội, những video rất đơn giản như việc đưa dữ liệu vào và AI trả lời chính xác những câu hỏi với mức độ thông minh đáng kinh ngạc. Thực tế bạn hãy copy về và làm giống y hệt vậy chỉ với dữ liệu khác và câu hỏi khác thì sẽ thấy chất lượng không đạt như mong đợi.

Kế tiếp bạn hãy tìm hiểu rõ cách xử lý dữ liệu và tương tác với mô hình LLM của giải pháp. Điều này cũng hơi khó khăn cho người không phải dân kỹ thuật, tuy nhiên ở mức độ nào đó bạn sẽ hiểu được giới hạn của giải pháp đang nằm ở đâu.

Cuối cùng mới lựa chọn phương án tốt nhất để giải quyết vấn đề của mình. Không có giải pháp nào mà giải quyết được tốt nhất mọi bài toán đặt ra trong thực tế. Đối với AI còn vất vả hơn ở chỗ vài tuần lại có một giải pháp mới, công nghệ mới để bạn đặt lên bàn so sánh. Chưa kịp so sánh xong lại có 1 giải pháp mới nữa rồi và còn nghe nói nó tốt hơn.

1. Giải pháp RAG đơn giản (mọi người hay gọi là Naïve RAG)

Giải pháp này thời điểm nó sinh ra tạo một làn sóng cho công nghệ AI, giúp các LLM cập nhật được với các thông tin mới và khái niệm RAG được phổ biến từ đây. Nó thay thế cho fine-tune vì dễ phát triển và không làm thay đổi tham số của LLM.

RAG ra đời có sự hỗ trợ từ số lượng token của LLM lớn hơn sau các phiên bản. Ý tưởng của RAG rất đơn giản và hiệu quả là cùng với câu hỏi, chúng ta sẽ đưa luôn cả thông tin để trả lời cho LLM. Kiểu như: “Nay thứ mấy vậy? [Hôm nay là thứ hai]”. Và tổng quan quy trình sẽ như sau.

• Đầu tiên là khâu xử lý dữ liệu, các file dữ liệu sẽ được cắt ra thành nhiều chunk sau đó embedding (vector hóa) các chunk đó lưu vào cơ sở dữ liệu.

• Sau đó mỗi khi user đặt câu hỏi, hệ thống sẽ dùng câu hỏi đó để truy vấn ra chunk cần thiết bằng cosine similarity và đưa chunk đó vào trong context chung với câu hỏi đó

• Cuối cùng là câu hỏi+context hỗ trợ được đưa vào LLM xử lý và trả về câu hỏi chính xác với thông tin cập nhật mới.

Để cho dữ liệu được liền mạch, việc cắt chunk ra sẽ luôn có sự trùng lắp, nghĩa là hai chunk kế nhau cho một nội dung trùng lắp với nhau kiểu như bạn sẽ chắc chắn rằng dữ liệu có 10k ký tự, mỗi chunk 1k ký tự thì không phải cắt ra thành 10 chunk đâu nha. Tùy vào mức độ overlap nhưng sẽ nhiều hơn 10 chunk

Ưu điểm của giải pháp này là nó rất đơn giản và được triển khai nhiều đến nỗi không cần hiểu sâu, cứ đưa file vào sau đó chọn model rồi test chất lượng của vấn đáp.

Vì nó đơn giản vậy nên nhiều công ty lại tập trung vào việc cải thiện system prompt thay vì tập trung vào việc nghiên cứu cải thiện kiến trúc của giải pháp để làm cho nó tốt hơn. Mình vẫn thấy lác đác một vài sản phẩm/demo tung ra trong năm 2025 vẫn đi theo mô hình này và gặp vấn đề với các dữ liệu, truy vấn của mình.

Nếu như hiểu cách hoạt động, bạn sẽ thấy có một số vấn đề như sau

• Hệ thống sẽ phải tìm kiếm nhiều hơn cần thiết để đưa ra chunk cần thiết do sự trùng lặp giữa các chunk.

• Phép toán tìm kiếm ngữ nghĩa semantic search trên cosine similarity có những hạn chế nhất định chứ không phải viên đạn bạc.

• Nếu chỉ trả về 1 chunk duy nhất thì có thể bị sót thông tin, trả về nhiều thì tốn kém cho LLM và tăng thời gian xử lý

• Dữ liệu đưa vào context chưa tối ưu do có nhiều thông tin không liên quan

• Trong đó nổi bật nhất là vấn đề thiếu khả năng xử lý ngữ nghĩa phức tạp. Vì mô hình dữ liệu đơn giản, không tổ chức, liên kết dữ liệu theo cấu trúc để hiểu sâu về ngữ nghĩa mà chỉ máy móc giải quyết vấn đề trên đoạn chunk tìm được

Vì vậy nếu không có những cải tiến nhất định liên quan tới cấu trúc dữ liệu và cách tìm kiếm, naïve RAG của bạn sẽ khó lòng có chất lượng cao đối với các dữ liệu dạng văn bản luật, nghị định…

Trong thực tế, tôi làm việc với ngôn ngữ tiếng Việt còn gặp thêm các vấn đề về đầu vào, nghĩa là xem trên file pdf thì mọi thứ rất ổn và đẹp nhưng khi extract text ra thì … bất ổn và chỉ phát hiện cho tới khi LLM trả lời không đúng.