Cách tinh chỉnh LLM [và khi nào nên dùng RAG hoặc viết prompt thay thế]

Tinh chỉnh mô hình ngôn ngữ lớn (LLM) là việc tiếp tục huấn luyện một LLM đã được tiền huấn luyện trên một tập dữ liệu nhỏ, dành riêng cho tác vụ, để mô hình tạo ra những đầu ra mà bạn không thể có được chỉ bằng prompt.

Quá trình tinh chỉnh gồm thu thập các cặp ví dụ đầu vào/đầu ra thể hiện hành vi bạn mong muốn, chạy các lượt huấn luyện để điều chỉnh trọng số của mô hình theo hướng đó, rồi đối chiếu kết quả với đầu ra của mô hình ban đầu. Các phương pháp tiết kiệm tham số như LoRA giúp việc này đủ rẻ để chạy trên một GPU duy nhất.

Nếu chưa hài lòng với đầu ra của LLM, trước tiên hãy cải thiện prompt và hệ thống tạo sinh tăng cường truy xuất (RAG). Tinh chỉnh thay đổi cách LLM hành xử. Khi bạn cần mô hình sử dụng thông tin mới hoặc thông tin độc quyền, prompt và RAG thường là lựa chọn tốt hơn.

Dưới đây là hướng dẫn từng bước cách tinh chỉnh LLM, các phương pháp tinh chỉnh chính (LoRA và QLoRA), cùng những thách thức và sai lầm có thể làm hỏng quá trình này.

Tinh chỉnh LLM là gì và khác gì so với tiền huấn luyện LLM

Tiền huấn luyện LLM xây dựng năng lực ngôn ngữ tổng quát của mô hình từ đầu trên một kho ngữ liệu khổng lồ, trong khi tinh chỉnh LLM điều chỉnh một mô hình đã được tiền huấn luyện trên một tập dữ liệu nhỏ cho một công việc cụ thể.

Tiền huấn luyện LLM là giai đoạn tiêu tốn nhiều tài nguyên để tạo ra một mô hình cơ sở. Mô hình học từ một kho văn bản rộng lớn, nhờ đó nắm được ngữ pháp, kiến thức và khả năng lập luận tổng quát nhưng không được chuyên biệt hóa cho tác vụ của bạn.

Tinh chỉnh LLM tiếp tục huấn luyện mô hình cơ sở trên một tập dữ liệu nhỏ, được chọn lọc kỹ để mô hình tạo ra đầu ra mong muốn cho một tác vụ hoặc trường hợp sử dụng cụ thể. Có thể kể đến định dạng nhất quán, giọng văn hoặc văn phong thương hiệu, các khuôn mẫu đặc thù theo lĩnh vực, hay các lệnh gọi công cụ và hàm đáng tin cậy.

Khi nào nên tinh chỉnh LLM và khi nào nên dùng prompt hoặc RAG

Để cải thiện hiệu suất LLM, hãy đi lần lượt từng bậc: prompt -> RAG -> tinh chỉnh.

Hãy cải thiện prompt bằng các chỉ dẫn chi tiết hơn và dùng RAG để cung cấp thông tin cập nhật cho mô hình. Chỉ dùng đến tinh chỉnh khi việc cải thiện prompt và truy xuất không mang lại hiệu quả.

Khi nào cải thiện prompt hiệu quả hơn tinh chỉnh và khi nào là chưa đủ

Viết prompt là đòn bẩy nhanh nhất và rẻ nhất. Trong nhiều trường hợp, prompt chính xác và chi tiết hơn là đủ để đạt được thay đổi hành vi mong muốn.

Nhưng prompt dài hơn sẽ làm công việc chậm lại, tốn kém hơn và không thể khắc phục những hạn chế vốn có của mô hình.

Các dấu hiệu cho thấy việc viết prompt có thể đã chạm đến giới hạn:

• Các trường hợp biên mới liên tục làm hỏng đầu ra: Ví dụ, mô hình trả về văn xuôi khi bạn cần JSON hoặc lệch giọng văn, và bạn phải vá prompt cho từng trường hợp mới.
• Prompt hệ thống ngày càng phình to: Prompt dài đến hàng trăm hoặc hàng nghìn dòng và khó quản lý.
• Bạn phải trả chi phí ở mọi lệnh gọi: Prompt được gửi lại và xử lý lại trong mỗi yêu cầu, nên chi phí token và độ trễ tăng lên.
• Thay đổi không còn tạo ra khác biệt: Các chỉ dẫn mới không cải thiện được đầu ra.

Ngay cả khi đó, hãy thử các cách khắc phục rẻ hơn ở cấp độ prompt trước. Dùng ví dụ few-shot để cho mô hình thấy khuôn mẫu (các cặp đầu vào/đầu ra), nối chuỗi prompt để chia tác vụ khó thành các bước nhỏ hơn, hoặc hook gọi hàm để chuyển các thao tác tra cứu chính xác hay tính toán ra bên ngoài.

Khi nào RAG hợp lý hơn tinh chỉnh mô hình

RAG thay đổi những gì LLM biết, còn tinh chỉnh LLM thay đổi cách nó hành xử. Nếu khoảng trống nằm ở kiến thức, đặc biệt là kiến thức thường xuyên thay đổi hoặc nằm trong tài liệu của riêng bạn, RAG là câu trả lời. Nếu khoảng trống nằm ở hành vi, hãy tinh chỉnh.

Tinh chỉnh cũng làm thay đổi những gì mô hình biết, nhưng mọi dữ kiện mà mô hình tiếp thu đều bị đóng băng tại thời điểm huấn luyện và nhanh chóng lỗi thời trong các lĩnh vực thay đổi nhanh. Hơn nữa, thông tin được tích hợp vào trọng số của mô hình nên không lưu lại dấu vết về nguồn gốc.

Cập nhật các tài liệu nguồn mà lớp truy xuất sử dụng sẽ nhanh hơn và rẻ hơn, đồng thời lớp này có thể trích dẫn chính xác các nguồn đã dùng. Điều này khiến RAG trở thành lựa chọn tốt hơn khi bạn cần thông tin cập nhật và có căn cứ xác đáng.

Nhược điểm của RAG? Đó là một lớp bổ sung cần xây dựng và duy trì, đồng thời làm tăng độ trễ.

Trên thực tế, bạn thường sẽ cần cả hai. Các hệ thống đang vận hành thường kết hợp mô hình đã tinh chỉnh với RAG, dùng một bên để đảm bảo hành vi nhất quán và bên còn lại để cung cấp dữ kiện hiện hành.

Những cạm bẫy, rủi ro và thách thức thường gặp khi tinh chỉnh

Ngay cả khi tinh chỉnh là công cụ phù hợp, nó vẫn đi kèm chi phí và rủi ro:

• Chi phí và thời gian: Việc tổng hợp dữ liệu huấn luyện sạch, mang tính đại diện cùng tài nguyên tính toán cho huấn luyện đều tốn kém.
• Quên thảm khốc: Khi được huấn luyện trên một tập dữ liệu hẹp, mô hình có thể mất đi các kỹ năng tổng quát và phát sinh những kiểu lỗi mới, dẫn đến các lỗi mà mô hình cơ sở không mắc phải.
• Quá khớp: Khi dữ liệu quá ít hoặc quá lặp lại, mô hình ghi nhớ các ví dụ huấn luyện thay vì học các khuôn mẫu, nên hoạt động tốt trên mẫu huấn luyện nhưng kém trên đầu vào thực tế.
• Kiến thức lỗi thời: Kiến thức nằm trong trọng số nhanh chóng cũ đi, nên bạn phải huấn luyện lại trên dữ liệu mới.
• Mô hình lạc hậu: Khi một mô hình mạnh hơn ra mắt, ngay ở dạng nguyên bản nó thường đã vượt qua mô hình bạn tinh chỉnh, và bạn phải làm lại từ đầu.
• Thách thức trong đánh giá và tái lập: Rất khó chứng minh mô hình đã tinh chỉnh vượt trội hơn mô hình cơ sở. Hai lượt huấn luyện trên GPU với cùng thiết lập cũng có thể tạo ra những mô hình hơi khác nhau.
• Quản trị dữ liệu: Huấn luyện trên dữ liệu độc quyền hoặc nhạy cảm đặt ra các vấn đề về quyền riêng tư và cấp phép; về sau, mô hình có thể làm lộ ra những mảnh dữ liệu mà nó đã được huấn luyện.

Các phương pháp tinh chỉnh chính

Các loại tinh chỉnh LLM chính khác nhau ở mức độ thay đổi mô hình: tinh chỉnh toàn phần huấn luyện lại toàn bộ mô hình, trong khi các phương pháp tinh chỉnh tiết kiệm tham số (PEFT) như LoRA và QLoRA chỉ cập nhật một phần trọng số. Các phương pháp PEFT chỉ tốn một phần nhỏ bộ nhớ so với tinh chỉnh toàn phần và, với thiết lập phù hợp, có thể đạt kết quả tương đương.

Tinh chỉnh toàn phần cập nhật mọi trọng số của mô hình. Đây là phương pháp tốn kém nhất và có nguy cơ quên thảm khốc cao nhất. Hãy dành nó cho những thay đổi lớn về hành vi khi bạn có đủ dữ liệu và tài nguyên tính toán.

Giải pháp thay thế là tinh chỉnh tiết kiệm tham số, hay PEFT. Đây là thuật ngữ chung cho các phương pháp đóng băng phần lớn mô hình và chỉ huấn luyện một nhóm nhỏ tham số. PEFT dùng ít bộ nhớ hơn nhiều và ít bị quên hơn, vì mô hình cơ sở được giữ nguyên.

Với hạng (rank) thấp, PEFT học được ít hơn so với tinh chỉnh toàn phần, nhưng việc tăng hạng và điều chỉnh tốc độ học sẽ thu hẹp phần lớn khoảng cách trên các tác vụ tinh chỉnh theo chỉ dẫn.

Các phương pháp PEFT bao gồm:

• LoRA (Low-Rank Adaptation): Điểm khởi đầu thông dụng, đóng băng trọng số gốc và huấn luyện một nhóm nhỏ tham số adapter được bổ sung, thường dưới 1% tổng số, nên có thể chạy trên một GPU phổ thông duy nhất.
• QLoRA (Quantized Low-Rank Adaptation): Nén mô hình cơ sở xuống độ chính xác 4 bit trước khi áp dụng LoRA, cho phép bạn tinh chỉnh một mô hình lớn trên một GPU duy nhất.

Ngoài ra, chúng tôi sử dụng các phương pháp tinh chỉnh theo chỉ dẫn và tinh chỉnh theo sở thích, từ RLHF (Reinforcement Learning from Human Feedback – học tăng cường từ phản hồi của con người) đến các lựa chọn nhẹ hơn như Direct Preference Optimization (DPO) và Odds Ratio Preference Optimization (ORPO), để định hình cách mô hình tuân theo chỉ dẫn và đáp ứng sở thích của con người.

Cách tinh chỉnh LLM từng bước

Khi bạn đã quyết định tinh chỉnh LLM là lựa chọn đúng đắn, dưới đây là quy trình làm việc.

Phóng to

Bước 1: Xác định tác vụ và cách đo lường thành công

Xác định hành vi bạn muốn LLM thể hiện và cách để biết bạn đã đạt được hành vi đó.

Nêu rõ công việc cụ thể bạn muốn mô hình đã tinh chỉnh hoàn thành, chẳng hạn như phân loại phiếu hỗ trợ, tóm tắt hợp đồng theo một định dạng cố định hoặc tạo mã theo phong cách riêng của đội ngũ bạn.

Sau đó, xác định thế nào là thành công. Các lựa chọn phổ biến gồm:

• Tính hợp lệ của đầu ra: Ví dụ, kết quả có phân tích được thành JSON hợp lệ hoặc khớp với cấu trúc Markdown bạn cần không?
• Điểm số tự động: Dùng các chỉ số như BLEU hoặc ROUGE để so sánh văn bản được tạo với câu trả lời tham chiếu, hoặc độ chính xác của tác vụ trên một tập dữ liệu đã gán nhãn.
• Đánh giá của con người: Một bộ tiêu chí chấm điểm hoặc đạt/không đạt cho những phẩm chất mà script tự động khó chấm chính xác, như giọng văn hoặc mức độ hữu ích.
• Độ tin cậy với đầu vào khó: Mô hình có xử lý được những đầu vào bất thường từng khiến mô hình cơ sở gặp khó không?

Bước 2: Chuẩn bị tập dữ liệu

Chất lượng dữ liệu quyết định thành công của quá trình tinh chỉnh, vì vậy hãy đầu tư công sức để thu thập đúng tập dữ liệu tinh chỉnh.

Định dạng dữ liệu thành các cặp chỉ dẫn/phản hồi ở dạng JSONL, trong đó mỗi dòng chứa đầu vào (cùng mọi ngữ cảnh đi kèm) và chính xác đầu ra bạn muốn nhận lại.

Ví dụ, hãy tham khảo các tập dữ liệu công khai như tập dữ liệu chỉ dẫn tổng quát Alpaca-cleaned hoặc Dolly của Databricks, hay tập dữ liệu chuyên biệt cho tác vụ banking77, bao gồm hơn 13.000 truy vấn hỗ trợ thực tế được gán nhãn theo 77 ý định.

Với một tác vụ chuyên biệt, từ vài trăm đến vài nghìn ví dụ sạch và đa dạng có thể làm thay đổi hành vi, miễn là các ví dụ phản ánh đúng đầu vào thực tế trong môi trường vận hành, bao gồm cả các trường hợp biên, và được định dạng nhất quán.

Chưa có cặp đầu vào/đầu ra? Hãy xây dựng tập dữ liệu từ những dữ liệu bạn đã có, chẳng hạn như phiếu hỗ trợ và các câu trả lời tốt nhất cho chúng, hoặc tài liệu và bản tóm tắt của chúng.

Nếu chỉ có đầu ra, hãy dùng một mô hình mạnh hơn để tạo đầu vào hợp lý cho từng đầu ra, hoặc tự viết tay một tập hạt giống nhỏ rồi mở rộng nó bằng một mô hình "giáo viên" lớn hơn, sau đó giữ lại những cặp tốt nhất.

Cuối cùng, chia dữ liệu thành các tập huấn luyện, xác thực và kiểm thử để bạn có thể đo lường trên những ví dụ mà mô hình chưa từng thấy.

Bước 3: Chọn mô hình cơ sở và phương pháp

Hãy bắt đầu với một mô hình mã nguồn mở nhỏ có từ 3 đến 7 tỷ tham số và một phương pháp tinh chỉnh tiết kiệm tham số như LoRA hoặc QLoRA.

Các dòng mô hình mở như Llama, Mistral và Qwen mang lại cho bạn một nền tảng vững chắc có thể tự lưu trữ, còn các phương pháp PEFT giúp giữ yêu cầu phần cứng ở mức thấp: QLoRA lượng tử hóa mô hình cơ sở xuống 4 bit, nên việc tinh chỉnh một mô hình 7B chỉ cần một card phổ thông 16-24 GB. Tinh chỉnh toàn phần cùng mô hình đó cần lượng bộ nhớ gấp nhiều lần.

Bước 4: Thiết lập siêu tham số huấn luyện

Dưới đây là các tham số tinh chỉnh LLM quan trọng và phạm vi khởi đầu được đề xuất:

• Tốc độ học kiểm soát độ lớn của mỗi lần cập nhật trọng số. Một nghiên cứu năm 2024 của Biderman và cộng sự cho thấy tốc độ học tối ưu của LoRA cao hơn khoảng mười lần so với tinh chỉnh toàn phần, thường là từ 5e-5 đến 5e-4 so với từ 1e-5 đến 5e-5. Nghiên cứu khuyên nên thử lần lượt các giá trị từ 1e-5 đến 5e-4 và chọn giá trị cao nhất mà quá trình huấn luyện vẫn ổn định.
• Kích thước lô (batch size) là số ví dụ mà mô hình dùng để học trước mỗi lần cập nhật trọng số. Trên một GPU duy nhất, hãy dùng kích thước lô nhỏ cho mỗi thiết bị, từ 1 đến 8, kết hợp với tích lũy gradient để đạt kích thước lô hiệu dụng khoảng 16 đến 64.
• Số epoch là số lần mô hình duyệt qua toàn bộ tập dữ liệu. Khi huấn luyện mô hình để thực hiện các tác vụ cụ thể, 1-3 epoch là con số hợp lý theo kinh nghiệm, nhưng các lần chạy LoRA thường cần nhiều hơn.
• Hạng LoRA (r) quyết định năng lực của adapter, tức là adapter có thể học được bao nhiêu. Hãy bắt đầu từ 8 đến 32 cho các tác vụ đơn giản và tăng lên cho các tác vụ khó hơn: trong nghiên cứu LoRA của Biderman và cộng sự được trích dẫn ở trên, khi tinh chỉnh theo chỉ dẫn (instruction-tuning) một mô hình 7B trên dữ liệu mã, cần đến hạng 256 mới đạt hiệu quả ngang với tinh chỉnh toàn phần, trong khi với toán học, hạng 64 đã cho kết quả gần tương đương.
• Độ dài chuỗi tối đa là độ dài đầu vào lớn nhất mà lần chạy sẽ xử lý. Hãy đặt giá trị này đủ để bao quát các ví dụ dài nhất của bạn, tối đa bằng cửa sổ ngữ cảnh của mô hình, vì mọi đầu vào dài hơn sẽ bị cắt bớt.
• Khởi động (warmup) và lịch trình tốc độ học kiểm soát cách tốc độ học tăng dần và thay đổi trong suốt lần chạy. Giai đoạn khởi động ngắn và suy giảm cosine là các thiết lập mặc định thông thường. Tuy nhiên, nghiên cứu về mô hình nhỏ của Pareja và cộng sự cho thấy việc bỏ giai đoạn khởi động không làm giảm điểm số cuối cùng.

Hãy xem đây là điểm khởi đầu để quét siêu tham số (sweep), chứ không phải các thiết lập cố định.

Bước 5: Huấn luyện và theo dõi giá trị mất mát

Trong khi huấn luyện, hãy theo dõi các đường cong mất mát huấn luyện và mất mát kiểm định để xem quá trình có hiệu quả hay không.

Giá trị mất mát (loss) đo lường mức độ chênh lệch giữa đầu ra của mô hình và các ví dụ của bạn, và giá trị này cần giảm đều khi lần chạy tiến triển. Mất mát huấn luyện được tính trên dữ liệu mà mô hình học. Mất mát kiểm định được tính trên các ví dụ được giữ riêng.

Nếu mất mát huấn luyện và mất mát kiểm định cùng giảm, mô hình đang học cách khái quát hóa. Nếu mất mát huấn luyện tiếp tục giảm nhưng mất mát kiểm định đi ngang hoặc tăng lên, mô hình đang ghi nhớ tập huấn luyện thay vì học quy luật (quá khớp).

Phóng to

Bước 6: Đánh giá, sau đó triển khai

Mất mát huấn luyện thấp không đảm bảo đầu ra chính xác, vì vậy hãy đánh giá mô hình đã tinh chỉnh dựa trên các tiêu chí bạn đặt ra ở Bước 1.

Khi mô hình đạt yêu cầu, bạn có hai cách để triển khai:

• Phục vụ (serve) adapter trên nền mô hình cơ sở và tải cả hai trong thời gian chạy; cách này giúp bạn dễ dàng hoán đổi adapter.
• Hợp nhất adapter vào trọng số cơ sở để có một mô hình độc lập duy nhất, dễ lưu trữ và vận hành hơn.

Dùng Perplexity để LLM của bạn truy cập thông tin mới nhất

Tinh chỉnh là lựa chọn đúng đắn khi bạn muốn điều chỉnh hành vi của mô hình theo nhu cầu của mình.

Nếu mô hình của bạn cần thông tin cập nhật, đặc biệt là thông tin thay đổi nhanh, bạn cần RAG hoặc một công cụ tìm kiếm bên thứ ba đáng tin cậy.

Một hệ thống truy xuất tùy chỉnh phù hợp nhất với các tập dữ liệu độc quyền, chẳng hạn như wiki nội bộ, lịch sử hỗ trợ khách hàng, hợp đồng hoặc tài liệu sản phẩm của bạn.

Khi kiến thức bạn muốn sử dụng là thông tin công khai, bạn không cần xây dựng một lớp truy xuất riêng. Perplexity là một công cụ trả lời (answer engine), cung cấp câu trả lời kèm trích dẫn nội tuyến có thể nhấp vào từ một chỉ mục web theo thời gian thực. Agent API của Perplexity cung cấp những câu trả lời dựa trên dữ liệu web và có trích dẫn đó chỉ trong một lệnh gọi, giúp ứng dụng của bạn khai thác được các nguồn thông tin mới nhất.

Câu hỏi thường gặp về tinh chỉnh LLM

Có thể tinh chỉnh LLM miễn phí không?

Có, bạn có thể tinh chỉnh miễn phí một LLM mở cỡ nhỏ. Ví dụ, gói miễn phí của Google Colab cung cấp đủ GPU để chạy QLoRA trên mô hình từ 3B đến 8B, dư sức cho một tác vụ chuyên biệt. Bạn sẽ bắt đầu phải trả phí khi cần thêm bộ nhớ, thời gian chạy dài hơn hoặc một mô hình cơ sở lớn hơn mức gói miễn phí có thể đáp ứng.

Bạn có cần GPU riêng không, hay có thể tinh chỉnh trên đám mây?

Bạn không cần sở hữu GPU để tinh chỉnh LLM. Các dịch vụ được quản lý và nhà cung cấp GPU đám mây cho thuê phần cứng theo giờ, vì vậy chỉ một GPU thuê là đủ cho một lần chạy QLoRA với mô hình nhỏ. Việc mua GPU chỉ đáng giá nếu bạn thường xuyên tinh chỉnh hoặc buộc phải lưu giữ toàn bộ dữ liệu trên máy của chính mình.

Tinh chỉnh LLM mất bao lâu?

Với một LLM nhỏ, một lần chạy có thể hoàn tất trong vài phút đến vài giờ, tùy thuộc vào kích thước tập dữ liệu và phần cứng. Chẳng hạn, Oumi đã tinh chỉnh toàn phần một mô hình 0,8B chỉ trong hơn một giờ trên nền tảng được quản lý (hosted) của mình.

Các mô hình lớn hơn hoặc hàng chục nghìn ví dụ sẽ kéo dài thời gian đó lên một ngày hoặc hơn: các lần chạy LoRA của Emburse trên một mô hình 7B mất 8 giờ cho 5.000 ví dụ và khoảng 30 giờ cho 50.000 ví dụ trên một GPU 40 GB duy nhất.

Bạn có thể liên tục cập nhật mô hình đã tinh chỉnh khi dữ liệu thay đổi không?

Bạn có thể tinh chỉnh lại trên dữ liệu mới, nhưng mỗi lần như vậy đều tốn tài nguyên tính toán và có nguy cơ gây ra hiện tượng quên thảm khốc (catastrophic forgetting). Với kiến thức thường xuyên thay đổi, RAG thường là giải pháp tốt hơn, vì bạn chỉ cần cập nhật tài liệu nguồn thay vì huấn luyện lại.