RAG hay tinh chỉnh? Các dự án thực tế với khách hàng đã dạy chúng tôi điều gì về cách lựa chọn

Hầu như cuộc trao đổi nào về AI trong doanh nghiệp mà tôi tham gia cũng đi đến cùng một ngã rẽ ngay trong giờ đầu tiên. Khách hàng có một mô hình ngôn ngữ lớn gây ấn tượng khi trình diễn, nhưng mô hình lại không biết sản phẩm, chính sách hay cách hành văn của họ. Một người trong phòng đặt câu hỏi: chúng ta nên tinh chỉnh mô hình bằng dữ liệu của mình, hay xây dựng hệ thống tạo sinh tăng cường truy xuất (RAG) cho mô hình?

Câu trả lời thẳng thắn là câu hỏi này thường được đặt không đúng cách. RAG và tinh chỉnh giải quyết những vấn đề khác nhau. Các nhóm xem chúng là hai lựa chọn cạnh tranh thường mất hàng tháng trời và tiêu tốn một khoản ngân sách GPU lớn để khắc phục sai vấn đề. Sau đây là cách chúng tôi đưa ra quyết định trong thực tế, cùng những điều chúng tôi chứng kiến diễn ra thành công và thất bại.

Trước tiên, hãy xác định mô hình còn thiếu điều gì

Khi mô hình trả lời kém trong một tác vụ kinh doanh, nó đang thiếu một trong hai thứ.

Mô hình thiếu kiến thức. Nó không biết bảng giá mới nhất của bạn, điều khoản trong hợp đồng với nhà cung cấp năm 2025 hay các bước khắc phục sự cố cho một sản phẩm ra mắt vào tháng trước. Đây là vấn đề về dữ kiện.

Mô hình thiếu kỹ năng thực hiện. Nó biết đủ, nhưng không phản hồi theo cách bạn cần. Nó bỏ qua định dạng đầu ra, viết sai giọng điệu, hiểu nhầm mã nội bộ hoặc không thể thực hiện một tác vụ hẹp, lặp đi lặp lại như phân loại phiếu hỗ trợ vào 40 danh mục của bạn. Đây là vấn đề về kỹ năng.

RAG là công cụ giải quyết vấn đề thứ nhất. Tinh chỉnh là công cụ giải quyết vấn đề thứ hai. Phần lớn sự nhầm lẫn tôi gặp bắt nguồn từ việc cố dùng tinh chỉnh để dạy mô hình các dữ kiện.

Vì sao tinh chỉnh không phải là cách tốt để bổ sung kiến thức

Ta dễ nghĩ rằng nếu huấn luyện mô hình bằng tài liệu của mình, nó sẽ “biết” những nội dung đó. Trên thực tế, mô hình học phong cách của tài liệu đáng tin cậy hơn nhiều so với các dữ kiện bên trong. Các nhà nghiên cứu tại Microsoft đã trực tiếp so sánh hai phương pháp này với những câu hỏi đòi hỏi nhiều kiến thức và nhận thấy RAG luôn vượt trội so với tinh chỉnh không giám sát, cả với những dữ kiện mô hình đã gặp trong quá trình huấn luyện lẫn những dữ kiện hoàn toàn mới.

Còn có những vấn đề thực tế khác. Dữ kiện thay đổi. Mỗi khi chính sách hoặc danh mục sản phẩm của bạn thay đổi, mô hình đã tinh chỉnh sẽ trở nên lỗi thời cho đến khi được huấn luyện lại. Bạn cũng mất khả năng truy xuất nguồn gốc: khi mô hình đã tinh chỉnh đưa ra một con số, bạn không thể chỉ ra tài liệu mà con số đó xuất phát từ đâu. Với khách hàng thuộc các lĩnh vực chịu sự quản lý như bảo hiểm và chăm sóc sức khỏe, chỉ riêng điều này thường đã đủ để chấm dứt cuộc thảo luận.

RAG, lần đầu được mô tả trong bài báo năm 2020 của Lewis và cộng sự, lưu trữ kiến thức bên ngoài mô hình. Khi nhận câu hỏi, bạn truy xuất các đoạn văn bản liên quan rồi đưa chúng cho mô hình làm ngữ cảnh. Để cập nhật kiến thức, chỉ cần cập nhật chỉ mục, không phải huấn luyện lại mô hình. Mỗi câu trả lời cũng có thể dẫn nguồn.

Một khách hàng trong ngành logistics của chúng tôi là ví dụ điển hình. Khách hàng của họ muốn nhận ngay câu trả lời về vị trí lô hàng và những giấy tờ còn thiếu. Thông tin đó thay đổi vài phút một lần. Dù huấn luyện đến đâu cũng không thể giúp mô hình luôn cập nhật, vì vậy trợ lý chúng tôi xây dựng lấy câu trả lời từ dữ liệu theo dõi trực tiếp và dữ liệu IoT tại thời điểm nhận câu hỏi, thay vì dựa vào trí nhớ. Truy xuất là thiết kế duy nhất có thể đáp ứng yêu cầu này.

Khi nào nên dùng tinh chỉnh

Tinh chỉnh chưa lỗi thời. Chỉ là phạm vi ứng dụng của nó hẹp hơn mọi người nghĩ. Chúng tôi cân nhắc dùng phương pháp này trong ba trường hợp:

• Định dạng đầu ra nghiêm ngặt, lặp đi lặp lại. Khi mô hình phải tạo cùng một định dạng đầu ra có cấu trúc hàng nghìn lần mỗi ngày, chẳng hạn trích xuất các trường từ hóa đơn theo một lược đồ JSON cố định, mô hình nhỏ đã tinh chỉnh thường đáng tin cậy hơn và rẻ hơn nhiều so với việc dùng lời nhắc để điều khiển một mô hình lớn.
• Ngôn ngữ chuyên ngành. Một số lĩnh vực sử dụng cách viết tắt mà mô hình nền tảng thường hiểu sai. Mã trạng thái trong ngành logistics, chữ viết tắt lâm sàng và mã sản phẩm nội bộ là những ví dụ phổ biến. Tinh chỉnh ở mức độ vừa phải có thể khắc phục vấn đề này.
• Chi phí và độ trễ khi mở rộng quy mô. Khi một tác vụ đã được xác định rõ, mô hình nhỏ đã tinh chỉnh có thể thay thế mô hình tổng quát lớn. Các phương pháp như LoRA giúp việc này trở nên hợp túi tiền, vì bạn chỉ huấn luyện một nhóm nhỏ trọng số bổ sung thay vì toàn bộ mô hình.

Lưu ý rằng không trường hợp nào trong số này liên quan đến dữ kiện. Đây đều là việc dạy mô hình cách thực hiện một tác vụ mà bạn đã hiểu rõ.

Phần lớn lỗi của RAG bắt nguồn từ khâu truy xuất

Khi một nhóm nói với tôi rằng “chúng tôi đã thử RAG nhưng không hiệu quả”, vấn đề hiếm khi nằm ở mô hình. Vấn đề nằm ở khâu truy xuất. Chất lượng của mô hình chỉ có thể tốt bằng chất lượng các đoạn văn bản được cung cấp cho nó.

Các cách khắc phục không hào nhoáng nhưng hiệu quả:

• Chia đoạn theo ý nghĩa, không theo số ký tự. Cắt hợp đồng theo từng 500 ký tự sẽ khiến các điều khoản bị chia đôi. Chia theo mục và tiêu đề giúp giữ nguyên ngữ cảnh.
• Bổ sung ngữ cảnh cho từng đoạn. Một đoạn ghi “giới hạn là 30 ngày” sẽ vô ích nếu không biết nó thuộc chính sách nào. Anthropic cho biết việc bổ sung ngữ cảnh ngắn từ tài liệu vào mỗi đoạn trước khi lập chỉ mục — phương pháp mà họ gọi là truy xuất có ngữ cảnh — đã giúp giảm 49% số lần truy xuất thất bại, và giảm 67% khi kết hợp với xếp hạng lại.
• Kết hợp tìm kiếm từ khóa và tìm kiếm véc-tơ. Tìm kiếm véc-tơ hiểu tốt ý nghĩa nhưng xử lý kém các thuật ngữ chính xác như mã phụ tùng. Tìm kiếm kết hợp đáp ứng được cả hai.
• Kiểm tra riêng chất lượng truy xuất. Hãy lập một bộ câu hỏi thực tế có sẵn các đoạn nguồn chính xác, rồi đo lường xem đoạn phù hợp có xuất hiện trong nhóm kết quả hàng đầu hay không trước khi đánh giá câu trả lời cuối cùng.

Khi nào nên kết hợp cả hai

Trong môi trường thực tế, các hệ thống hiệu quả nhất thường kết hợp cả hai. RAG cung cấp dữ kiện. Một mô hình được tinh chỉnh nhẹ sẽ xử lý định dạng, giọng điệu và ngôn ngữ chuyên ngành. Nghiên cứu cũng đang đi theo hướng đó: phương pháp RAFT của UC Berkeley tinh chỉnh mô hình nhằm giúp mô hình sử dụng tài liệu được truy xuất tốt hơn và bỏ qua những tài liệu không liên quan.

Tuy nhiên, thứ tự rất quan trọng. Hầu như lúc nào chúng tôi cũng xây dựng RAG trước, đo lường những điểm còn hạn chế, rồi mới quyết định liệu có đáng tinh chỉnh mô hình hay không. Nếu bắt đầu bằng việc tinh chỉnh, bạn sẽ phải trả chi phí huấn luyện trước khi biết vấn đề thực sự nằm ở đâu.

Danh sách kiểm tra quyết định đơn giản

1. Nhiệm vụ có phụ thuộc vào những dữ kiện thay đổi hơn một lần mỗi quý không? Hãy dùng RAG.
2. Người dùng hoặc kiểm toán viên có cần biết câu trả lời bắt nguồn từ đâu không? Hãy dùng RAG.
3. Vấn đề nằm ở định dạng, giọng điệu hoặc từ vựng của câu trả lời, chứ không phải dữ kiện? Hãy cân nhắc tinh chỉnh mô hình.
4. Đây có phải là một nhiệm vụ chuyên biệt, được thực hiện với khối lượng lớn, trong đó chi phí hoặc tốc độ là yếu tố quan trọng không? Hãy cân nhắc tinh chỉnh một mô hình nhỏ hơn.
5. Bạn đã đo lường riêng chất lượng truy xuất chưa? Nếu chưa, hãy làm điều đó trước tiên.

Điều cần ghi nhớ

RAG và tinh chỉnh mô hình không đối đầu nhau. Một phương pháp cung cấp cho mô hình thông tin phù hợp, phương pháp kia định hình cách mô hình hoạt động. Hãy xác định rõ vấn đề thực sự của bạn là gì, cải thiện khả năng truy xuất trước khi đổ lỗi cho mô hình, và chỉ xem việc tinh chỉnh là bước tối ưu hóa xứng đáng thực hiện sau khi hệ thống đã hoạt động, chứ không phải lối tắt để khiến hệ thống hoạt động.