RAG hay fine-tuning? Chẩn đoán ba tầng trước khi đổi model

Assistant nội bộ của bạn trả lời sai một chính sách vừa cập nhật tuần trước. Bạn đổi sang model lớn hơn, hóa đơn tăng gấp đôi, câu trả lời vẫn sai. Bài này đưa ra quy trình chẩn đoán ba tầng để xác định lỗi nằm ở đâu trước khi bạn đụng tới model hay dataset fine-tuning.

RAG và fine-tuning sửa hai loại lỗi khác nhau

Bài phân tích của SotaTek tách rõ hai nhóm: "RAG changes what information the model can access at inference time. Fine-tuning changes the behavior learned by the model." Hai ca lỗi kinh điển minh hoạ cho khác biệt đó: assistant trả lời lỗi thời vì chính sách mới chưa bao giờ tới được model — đây là knowledge-access problem; còn hệ thống phân loại có đủ thông tin nhưng liên tục trả về sai định dạng — đây là behavior problem.

Với RAG, trọng số model giữ nguyên; khi chính sách đổi, bạn re-index lại nguồn tri thức mà không cần retrain. Fine-tuning thì ngược lại: mục tiêu không phải dạy model biết sự cố hôm qua, mà làm nó nhất quán hơn ở một tác vụ cụ thể — phân loại chuyên ngành, trích xuất có cấu trúc, biến đổi theo domain.

Ba tầng cần tách ra trước khi kết luận

Tầng	Câu hỏi chẩn đoán	Can thiệp khả dĩ
Retrieval	Hệ thống có tìm đúng bằng chứng không?	Cải thiện search, metadata, chunking, reranking
Context	Bằng chứng liên quan có thực sự tới được model?	Chỉnh context selection và cách dựng prompt
Generation	Model có dùng đúng bằng chứng đó không?	Chỉnh prompt, thêm validation, cân nhắc fine-tuning

Ví dụ trong bài: chính sách bảo mật đúng nằm sẵn trong knowledge base, nhưng retrieval liên tục xếp nó ngoài top 5 kết quả. Một LLM lớn hơn có thể viết câu trả lời nghe thuyết phục hơn, nhưng nó không thể dùng bằng chứng không bao giờ lọt vào context window. Điểm cần sửa nằm ở retrieval pipeline, không phải ở model training.

Đo baseline trước, đổi sau

Trước khi thêm RAG hay fine-tuning, hãy dựng baseline trên tập test đại diện. Bài viết đưa một bảng ví dụ cho assistant nội bộ — tác giả ghi rõ "These figures are illustrative, not benchmark results", nên hãy đọc nó như mẫu cách bày số liệu, không phải số liệu để trích dẫn:

Answer accuracy 71% · Groundedness 68% · Format compliance 91% · Retrieval Recall@5 62%

Ngay cả bộ số nhỏ như vậy đã chỉ hướng: recall yếu tương đối, trong khi format compliance đã khá tốt — fine-tuning không nên là can thiệp đầu tiên. Nguyên tắc vận hành: với ứng dụng RAG, hãy đánh giá retrieval và generation tách rời nhau — một hàm eval trả về recall@k cùng với answer là đủ để bắt đầu (đoạn code trong bài là ví dụ minh hoạ, không phải thư viện có sẵn).

Nếu lỗi thật sự nằm ở tầng generation

Khi bằng chứng đã vào đúng context mà output vẫn trôi, vấn đề thường là prompt được viết như văn xuôi. Một bài khác trên Dev.to lập luận rằng prompt production nên được coi là hợp đồng, với bốn phần bắt buộc: Role (ai đang nói, tối ưu cho điều gì), Task (một deliverable duy nhất, không phải một danh sách), Constraints (điều gì tuyệt đối không được xảy ra), và Output contract (hình dạng chính xác của câu trả lời hợp lệ, và phải làm gì khi input không thoả). Tác giả nói thẳng: thiếu bất kỳ phần nào, model sẽ đoán.

Việc cần làm tuần này

• Lấy một tập câu hỏi thật từ log, gán nhãn tài liệu đúng, chạy recall@k — đây là phép đo rẻ nhất để biết lỗi có nằm ở retrieval không.
• Ghi lại baseline của hệ thống trước khi đổi bất cứ thứ gì — không có baseline thì mọi thay đổi sau đó đều là cảm tính.
• Viết lại prompt đang lỗi theo bốn phần Role/Task/Constraints/Output contract, đo lại, rồi mới tính tới fine-tuning.