Fine-tuning hay RAG: đừng chọn kỹ thuật, hãy chẩn đoán vấn đề

Năm 2024, một nghiên cứu mang tên “Fine-Tuning or Fine-Failing?” công bố một kết quả trái với kỳ vọng của nhiều người. Trong thiết lập RAG họ thử, mô hình sau khi fine-tune lại kém hơn mô hình gốc.

Cũng năm đó, nhóm của Microsoft fine-tune mô hình trên dữ liệu nông nghiệp và tăng thêm hơn 6 điểm phần trăm độ chính xác. Khi gắn thêm RAG, họ được thêm 5 điểm nữa. Cùng một cặp kỹ thuật mà kết quả ngược chiều, dù hai nhóm thử nghiệm trong những thiết lập khác nhau nên không thể coi là phủ định trực tiếp lẫn nhau.

Nếu làm FDE, bạn sẽ gặp câu hỏi này ngay tuần đầu: “Fine-tune cho chúng tôi hay làm RAG?” Câu trả lời tốt không phải là tên một kỹ thuật mà là một chẩn đoán.

Hai kết quả ngược chiều ở trên nhắc rằng chẳng có kỹ thuật nào mặc định thắng, và chỉ có số đo trong đúng điều kiện của khách mới cho bạn biết mình đang ở trường hợp nào.

Mô hình không biết, hay biết mà làm sai?

Tài liệu về tối ưu độ chính xác của OpenAI chia lỗi của mô hình thành hai loại. Loại đầu tiên là mô hình thiếu kiến thức vì thông tin đó không có trong tập huấn luyện. OpenAI gọi đây là bài toán tối ưu ngữ cảnh, và RAG là công cụ dành cho nó.

Loại thứ hai là mô hình cho kết quả không ổn định hoặc sai định dạng. Đây là bài toán tối ưu bản thân mô hình, và câu trả lời là fine-tuning.

Theo OpenAI, RAG hữu ích nhưng chỉ sửa được những gì mô hình cần lấy từ ngữ cảnh, nên nó không dạy mô hình một thói quen mới. Ngược lại, fine-tuning cũng không nạp được cho mô hình bản hợp đồng khách vừa ký tuần trước.

Thử hình dung bạn triển khai trợ lý nội bộ cho một công ty bảo hiểm có vài nghìn trang quy định bồi thường. Đến ngày demo, mô hình bịa ra một điều khoản không hề tồn tại. Đó là lỗi thiếu kiến thức, và thứ cần sửa là retrieval.

Còn nếu mô hình trích đúng điều khoản nhưng lúc trả lời bằng bảng, lúc bằng đoạn văn, lúc lại quên ghi mã hồ sơ, thì đó là lỗi hành vi. Đổi chunk thế nào cũng không sửa được.

Vì thế, trước khi chọn kỹ thuật nào, việc đầu tiên là gom các lỗi thật của khách và phân loại chúng. Cột nào dài hơn sẽ quyết định bạn làm gì trong tuần tiếp theo.

Đừng fine-tune khi retrieval còn dở

Nếu sau khi phân loại, cột bên trái dài hơn, đừng vội nghĩ đến chuyện huấn luyện. Tầng retrieval có thể còn nhiều dư địa. Trong bài giới thiệu Contextual Retrieval, Anthropic cho thấy chỉ riêng việc kết hợp contextual embeddings với contextual BM25 đã giảm 49% tỉ lệ truy xuất thất bại ở top-20 chunk.

Thêm một bước rerank, mức giảm lên tới 67%.

Để có kết quả ấy, không một tham số nào của mô hình bị thay đổi. Vì vậy, hãy làm cho pipeline RAG tốt hết mức có thể rồi mới nhắc đến huấn luyện. Kiểm tra xem chunk có mang theo ngữ cảnh không, đã kết hợp tìm kiếm từ khóa chưa, đã có rerank chưa.

Có khi bạn còn chưa cần đến RAG. Anthropic lưu ý rằng nếu cơ sở tri thức nhỏ hơn 200.000 token, tức khoảng 500 trang, bạn có thể đưa toàn bộ vào prompt. Vậy trước khi dựng pipeline, hãy hỏi khách xem tổng lượng tài liệu thực sự cần dùng là bao nhiêu.

Nếu nằm gọn trong giới hạn đó, đưa thẳng vào prompt là phương án nên thử trước.

Khi nào fine-tuning xứng đáng với chi phí

Fine-tuning hợp lý khi cột bên phải dài, tức là mô hình đã có đủ thông tin nhưng không làm theo cách khách muốn. Lúc này, hướng dẫn của OpenAI có một nguyên tắc đáng ghi nhớ: chất lượng dữ liệu huấn luyện quan trọng hơn số lượng.

Áp vào thực tế, một bộ ví dụ nhỏ được chuyên gia nghiệp vụ của khách duyệt kỹ từng dòng đáng để ưu tiên hơn một kho log chat thô khổng lồ.

Chi phí cũng không chỉ là tiền GPU. Bài nghiên cứu của Microsoft về nông nghiệp nhấn mạnh rằng chi phí ban đầu rất cao vì fine-tune trên dữ liệu mới đòi hỏi nhiều công sức, và chi phí inference về sau cũng phải tính vào.

Mỗi lần khách cập nhật quy định, pipeline RAG chỉ cần index lại, còn mô hình fine-tune có thể phải huấn luyện lại.

Rồi còn rủi ro mà bài “Fine-Tuning or Fine-Failing?” đã chỉ ra: fine-tune xong, mô hình có thể kém hơn lúc chưa làm gì. Nếu không có bộ eval và con số baseline từ trước, bạn sẽ không biết mình vừa để khách tốn tiền mà nhận về một hệ thống tệ hơn.

Hai kết quả trái ngược dạy điều gì

Quay lại hai nghiên cứu ở đầu bài. Kết quả của Microsoft cho thấy hai kỹ thuật có thể cộng dồn: hơn 6 điểm từ fine-tuning, thêm 5 điểm từ RAG. Nghiên cứu còn lại nhắc rằng sự cộng dồn ấy không có sẵn. Bài học cho người triển khai là phải đo riêng phần đóng góp của từng lớp, để biết lớp nào thật sự đang giúp.

Cũng có những hướng lai ghép có chủ đích. RAFT huấn luyện mô hình học cách bỏ qua những tài liệu truy xuất không liên quan, và cải thiện kết quả một cách nhất quán trên ba bộ dữ liệu PubMed, HotpotQA và Gorilla. Ở đây fine-tuning không dạy kiến thức mới mà dạy mô hình dùng RAG khéo hơn.

Nói cách khác, nó dạy một hành vi, đúng như cách OpenAI phân loại.

Thứ cần cho vào CV không phải tên kỹ thuật

Với một developer Việt Nam đang nhắm tới vị trí FDE, điều cần học nằm ở thứ tự làm việc chứ không ở công nghệ. Hãy tập thói quen xây bộ eval trước khi viết dòng code pipeline đầu tiên: 30-50 câu hỏi thật của khách, đáp án mong muốn và con số baseline.

Từ đó trở đi, mọi quyết định, dù là thêm reranker, đổi cách chunking hay fine-tune, đều phải đi kèm một con số so với baseline ấy.

Khi đọc mô tả công việc, hãy xem vị trí đó có nhắc tới evaluation hay chất lượng retrieval không. Nếu có, đó là chỗ bạn nên đưa kinh nghiệm xây bộ eval lên đầu hồ sơ.

Trong CV, thay vì viết “có kinh nghiệm fine-tuning”, hãy ghi những gì đo được: giảm bao nhiêu phần trăm lỗi truy xuất, tăng bao nhiêu điểm trên bộ eval của khách, và vì sao bạn chọn cách này mà không chọn cách kia.

Khách hàng sẽ còn hỏi “fine-tune hay RAG” trong nhiều năm nữa. Một FDE giỏi trả lời câu đó bằng một bộ eval và một bảng phân loại lỗi, chứ không bằng tên một kỹ thuật.