Trong nhiều ứng dụng dùng mô hình ngôn ngữ lớn, RAG được xem như cách phổ biến để đưa dữ liệu nội bộ vào câu trả lời mà không cần huấn luyện lại mô hình. Tuy nhiên, một chi tiết thường bị xem nhẹ là cách chia nhỏ tài liệu trước khi đưa vào hệ thống truy xuất. Nếu chia không hợp lý, mô hình có thể nhận được đoạn ngữ cảnh thiếu ý, thừa nhiễu hoặc nằm sai chỗ, dẫn đến câu trả lời nghe có vẻ đúng nhưng không bám sát tài liệu. Vấn đề không nằm ở việc “chunk càng nhỏ càng tốt” hay “chunk càng lớn càng tốt”. Mỗi lựa chọn đều có đánh đổi. Đoạn quá ngắn có thể làm mất ngữ cảnh. Ví dụ, một câu “điều kiện này không áp dụng cho khách hàng doanh nghiệp” nếu bị tách khỏi phần trước thì hệ thống khó biết “điều kiện này” là gì. Ngược lại, đoạn quá dài có thể chứa nhiều chủ đề khác nhau, khiến truy xuất trả về đúng tài liệu nhưng sai phần cần đọc. Một số nguyên tắc thực tế có thể áp dụng: - Chia theo cấu trúc tự nhiên của tài liệu: ưu tiên tiêu đề, mục, điều khoản, câu hỏi trong FAQ thay vì cắt cứng theo số ký tự. - Giữ lại tiêu đề cha: nếu một đoạn thuộc mục “Chính sách hoàn tiền”, nên lưu kèm đường dẫn như “Hỗ trợ khách hàng > Thanh toán > Chính sách hoàn tiền”. Thông tin này giúp mô hình hiểu bối cảnh. - Dùng overlap có kiểm soát: chồng lấn một phần giữa các đoạn giúp tránh mất ý ở ranh giới, nhưng overlap quá nhiều sẽ làm chỉ mục phình to và tăng khả năng trả về các đoạn gần giống nhau. - Tách riêng bảng biểu và danh sách quan trọng: bảng giá, điều kiện áp dụng, ma trận quyền hạn thường cần cách biểu diễn riêng, vì chuyển thành văn bản thô có thể làm mất quan hệ giữa hàng và cột. - Gắn metadata hữu ích: loại tài liệu, ngày hiệu lực, phòng ban, ngôn ngữ, phiên bản. Khi truy xuất, metadata có thể dùng để lọc trước thay vì chỉ dựa vào độ tương đồng vector. Một ví dụ đơn giản: nếu xây chatbot trả lời chính sách nhân sự, đừng đưa cả file “Sổ tay nhân viên” thành các đoạn cắt đều 1.000 ký tự. Hãy tách theo từng chính sách như nghỉ phép, làm thêm giờ, bảo hiểm, thử việc. Với mỗi đoạn, lưu thêm tiêu đề, ngày cập nhật và nhóm nhân sự áp dụng. Khi người dùng hỏi “nhân viên thử việc có được nghỉ phép không?”, hệ thống có cơ hội truy xuất đúng phần “Thử việc” và “Nghỉ phép”, thay vì lôi về một đoạn dài nói chung về phúc lợi. Sau khi thiết kế chunking, cần đánh giá bằng câu hỏi thật hoặc gần thật. Đừng chỉ kiểm tra vài truy vấn dễ. Hãy tạo một bộ câu hỏi bao gồm: câu hỏi trực tiếp, câu hỏi cần kết hợp hai đoạn, câu hỏi có từ đồng nghĩa, câu hỏi về điều kiện ngoại lệ và câu hỏi mà tài liệu không có câu trả lời. Với mỗi câu hỏi, kiểm tra xem hệ thống có truy xuất đúng đoạn cần thiết hay không trước khi đánh giá câu trả lời của LLM. Một lời khuyên quan trọng: khi RAG trả lời sai, đừng vội đổi mô hình lớn hơn. Hãy nhìn vào chuỗi xử lý: tài liệu đã được tách đúng chưa, metadata có đủ không, truy xuất có lấy đúng đoạn không, prompt có yêu cầu mô hình bám vào nguồn không. Trong rất nhiều trường hợp, cải thiện cách chia nhỏ và tổ chức tài liệu đem lại hiệu quả rõ ràng hơn việc tăng kích thước mô hình. RAG không chỉ là “embedding rồi tìm kiếm”. Đó là một bài toán thiết kế luồng thông tin. Chunking tốt giúp mô hình đọc đúng thứ cần đọc; chunking kém khiến mô hình phải đoán trong một đống ngữ cảnh lộn xộn. Với các hệ thống AI dùng trong công việc thật, khác biệt này có thể quyết định độ tin cậy của toàn bộ sản phẩm.