Fine-tuning LLM là quá trình huấn luyện thêm một mô hình ngôn ngữ lớn (Large Language Model) đã được huấn luyện trước trên một tập dữ liệu chuyên biệt, để mô hình học được phong cách, thuật ngữ, định dạng đầu ra hoặc nhiệm vụ cụ thể của doanh nghiệp. Khác với prompt engineering — chỉ thay đổi câu lệnh đầu vào — và RAG — bổ sung kiến thức bên ngoài lúc suy luận, fine-tuning thay đổi trực tiếp trọng số của mô hình, nên hành vi mới được “khắc” vào trong mô hình và áp dụng nhất quán ở mọi lượt tương tác. Bài viết giải thích bản chất và cơ chế của fine-tuning, so sánh các phương pháp Full Fine-tuning, LoRA, QLoRA, RLHF và DPO, đưa ra bảng so sánh tài nguyên và chi phí, quy trình thực tế từ chuẩn bị dữ liệu đến triển khai, cùng checklist tránh các lỗi thường gặp như overfitting và catastrophic forgetting.
Fine-tuning LLM là gì?
Fine-tuning (tinh chỉnh) là giai đoạn huấn luyện tiếp theo sau quá trình pre-training của một mô hình ngôn ngữ lớn. Trong pre-training, mô hình học ngôn ngữ nói chung từ hàng nghìn tỷ token văn bản trên internet, sách và mã nguồn, và thu được khả năng ngôn ngữ tổng quát. Fine-tuning lấy mô hình đã huấn luyện trước đó làm điểm khởi đầu, rồi tiếp tục huấn luyện nó trên một tập dữ liệu nhỏ hơn nhưng chuyên biệt — ví dụ các đoạn hội thoại chăm sóc khách hàng của công ty, các hợp đồng và văn bản pháp lý, hay các cặp câu hỏi — câu trả lời theo chuẩn của một ngành nghề — để mô hình điều chỉnh hành vi theo đúng nhu cầu đó.
Về mặt kỹ thuật, fine-tuning không khác gì huấn luyện thông thường: mô hình dự đoán token tiếp theo, tính hàm mất mát (loss) so với đáp án đúng, rồi dùng thuật toán lan truyền ngược (backpropagation) và tối ưu hóa gradient descent để cập nhật trọng số. Điểm khác biệt nằm ở quy mô và mục tiêu: dữ liệu ít hơn nhiều (hàng nghìn đến hàng trăm nghìn mẫu thay vì hàng nghìn tỷ token), tốc độ học (learning rate) nhỏ hơn nhiều để không phá hỏng kiến thức đã học, và số vòng huấn luyện (epoch) ít hơn — thường chỉ 1 đến 3 epoch là đủ cho phần lớn tác vụ fine-tuning. Mục tiêu không phải dạy mô hình kiến thức mới từ đầu, mà là “căn chỉnh” mô hình có sẵn cho một nhiệm vụ, một phong cách hoặc một miền kiến thức cụ thể.
Một ví dụ thực tế giúp hình dung rõ: một công ty bảo hiểm muốn chatbot trả lời khách hàng bằng đúng thuật ngữ bảo hiểm Việt Nam, đúng quy trình bồi thường của công ty, và luôn kết thúc bằng câu hỏi xác nhận nhu cầu. Mô hình nền dù giỏi tiếng Việt vẫn không biết quy trình nội bộ của công ty này. Fine-tuning trên vài nghìn đoạn hội thoại mẫu — bao gồm cả các trường hợp khách hỏi về quyền lợi, hồ sơ bồi thường, thời hạn chi trả — sẽ dạy mô hình phong cách trả lời, thuật ngữ và cấu trúc câu trả lời mong muốn, để mỗi lần tương tác đều nhất quán mà không cần nhồi toàn bộ quy trình vào prompt.
Fine-tuning không phải là phép màu và cũng không phải lúc nào cũng là lựa chọn đúng. Nó không tạo ra kiến thức mà mô hình chưa từng thấy trong pre-training; nó chủ yếu “đánh thức” và định hình lại kiến thức đã có. Nếu doanh nghiệp cần mô hình trả lời về dữ liệu nội bộ luôn thay đổi — giá sản phẩm hôm nay, tồn kho hiện tại, chính sách mới ban hành tuần trước — fine-tuning không phải công cụ phù hợp, vì mỗi lần dữ liệu thay đổi lại phải huấn luyện lại. Trong những trường hợp đó, RAG (Retrieval-Augmented Generation) — truy xuất tài liệu rồi đưa vào ngữ cảnh — thường hiệu quả hơn. Phần dưới đây phân tích ranh giới này một cách cụ thể.
Fine-tuning khác prompt engineering và RAG như thế nào?
Có ba cách chính để “dạy” một LLM hành vi mong muốn: prompt engineering, RAG và fine-tuning. Ba cách này không loại trừ nhau — nhiều hệ thống sản phẩm dùng cả ba cùng lúc — nhưng mỗi cách can thiệp ở một tầng khác nhau của hệ thống, với chi phí và giới hạn khác nhau.
Prompt engineering là nghệ thuật viết câu lệnh đầu vào: hướng dẫn hệ thống (system prompt), ví dụ mẫu (few-shot examples), định dạng yêu cầu đầu ra. Nó không thay đổi mô hình, chỉ thay đổi ngữ cảnh mà mô hình nhìn thấy. Ưu điểm: triển khai ngay trong vài phút, không cần GPU huấn luyện, dễ thử nghiệm và chỉnh sửa. Nhược điểm: mỗi lượt gọi đều tốn token cho phần hướng dẫn, hành vi có thể không ổn định khi prompt dài và phức tạp, và mô hình vẫn có thể “quên” hướng dẫn ở giữa đoạn hội thoại dài. Prompt engineering phù hợp khi yêu cầu thay đổi thường xuyên hoặc khi nhiệm vụ nằm trong khả năng vốn có của mô hình.
RAG là kỹ thuật bổ sung kiến thức bên ngoài: khi người dùng hỏi, hệ thống truy xuất các đoạn tài liệu liên quan từ cơ sở dữ liệu của doanh nghiệp, rồi đưa chúng vào ngữ cảnh để mô hình trả lời dựa trên tài liệu đó. Ưu điểm: kiến thức luôn cập nhật (chỉ cần thêm tài liệu mới vào kho), có thể trích dẫn nguồn, và không cần huấn luyện lại. Nhược điểm: chất lượng phụ thuộc vào bước truy xuất — tài liệu sai hoặc thiếu thì câu trả lời cũng sai; độ trễ tăng vì phải truy xuất trước khi sinh văn bản; và RAG không thay đổi được phong cách hay định dạng đầu ra một cách triệt để.
Fine-tuning thay đổi trực tiếp trọng số mô hình. Ưu điểm: hành vi được “khắc” vào mô hình nên nhất quán trong mọi lượt gọi, không tốn token cho hướng dẫn dài, phản hồi nhanh hơn (prompt ngắn hơn), và mô hình học được phong cách, định dạng và thuật ngữ chuyên ngành một cách sâu sắc. Nhược điểm: cần dữ liệu huấn luyện chất lượng, cần GPU và kỹ năng kỹ thuật, mỗi lần cập nhật kiến thức phải huấn luyện lại, và có rủi ro làm mô hình quên kiến thức cũ (catastrophic forgetting) nếu làm sai.
| Tiêu chí | Prompt engineering | RAG | Fine-tuning |
|---|---|---|---|
| Can thiệp vào | Câu lệnh đầu vào | Ngữ cảnh truy xuất | Trọng số mô hình |
| Thời gian triển khai | Vài phút đến vài giờ | Vài ngày đến vài tuần | Vài ngày đến vài tuần |
| Cần GPU huấn luyện | Không | Không (chỉ cần embedding) | Có |
| Cần dữ liệu huấn luyện | Không, chỉ cần ví dụ mẫu | Cần kho tài liệu | Cần tập dữ liệu có nhãn |
| Kiến thức cập nhật | Thay prompt là xong | Thêm tài liệu là xong | Phải huấn luyện lại |
| Tính nhất quán hành vi | Trung bình, có thể dao động | Phụ thuộc truy xuất | Cao, ổn định |
| Chi phí suy luận | Cao (prompt dài) | Cao hơn (thêm truy xuất) | Thấp (prompt ngắn) |
| Phù hợp nhất khi | Nhiệm vụ chung, thay đổi nhanh | Cần kiến thức nội bộ mới | Phong cách, định dạng, thuật ngữ ổn định |
Nguyên tắc lựa chọn thực tế: hãy bắt đầu từ prompt engineering, vì nó rẻ nhất và cho kết quả ngay. Nếu mô hình trả lời đúng nội dung nhưng sai định dạng, sai phong cách hoặc không dùng đúng thuật ngữ ngành — và yêu cầu đó ổn định theo thời gian — hãy cân nhắc fine-tuning. Nếu mô hình thiếu kiến thức nội bộ hoặc kiến thức thay đổi liên tục, hãy dùng RAG. Nhiều hệ thống tốt nhất kết hợp cả hai: fine-tune để mô hình học phong cách và cách dùng công cụ, RAG để cung cấp kiến thức cập nhật. Một chatbot chăm sóc khách hàng điển hình sẽ được fine-tune để nói đúng giọng điệu thương hiệu và trả lời đúng cấu trúc, đồng thời dùng RAG để tra cứu chính sách và giá mới nhất trước khi trả lời.
Khi nào nên fine-tune LLM và khi nào không nên?
Fine-tuning mang lại giá trị lớn nhất trong bốn tình huống. Thứ nhất, phong cách và giọng điệu thương hiệu: khi mọi câu trả lời phải mang đúng giọng điệu của công ty — trang trọng hay thân thiện, dùng xưng hô nào, cấu trúc câu ra sao. Prompt có thể mô tả phong cách, nhưng fine-tuning làm cho phong cách trở thành “bản năng” của mô hình, áp dụng đều trong mọi tình huống kể cả khi prompt ngắn. Thứ hai, định dạng đầu ra cố định: mô hình phải luôn trả về JSON đúng schema để hệ thống khác xử lý, luôn trả lời theo một mẫu biểu, hay luôn gọi công cụ (function calling) theo đúng thứ tự. Đây là trường hợp fine-tuning tỏ ra vượt trội rõ rệt so với prompt, vì độ chính xác định dạng có thể tăng từ mức 80–90% lên gần như tuyệt đối.
Thứ ba, thuật ngữ và kiến thức ngành ổn định: y khoa, pháp lý, tài chính, kỹ thuật — các lĩnh vực có từ vựng chuyên môn và quy ước riêng ít thay đổi. Fine-tuning trên dữ liệu ngành giúp mô hình dùng đúng thuật ngữ, hiểu đúng ngữ cảnh chuyên môn và tránh các lỗi “nghe có vẻ đúng nhưng sai chuyên môn”. Thứ tư, nhiệm vụ hẹp, lặp lại với khối lượng lớn: phân loại văn bản, trích xuất thông tin từ hợp đồng, tóm tắt báo cáo theo mẫu, chấm điểm bài viết. Với các nhiệm vụ hẹp, một mô hình nhỏ được fine-tune tốt thường cho kết quả ngang hoặc hơn mô hình lớn dùng prompt chung — mà chi phí suy luận thấp hơn nhiều.
Ngược lại, có những tình huống không nên fine-tuning. Khi kiến thức cần cập nhật liên tục — giá cả, chính sách, dữ liệu thời gian thực — hãy dùng RAG. Khi nhiệm vụ nằm ngoài khả năng của mô hình nền — ví dụ yêu cầu mô hình 7 tỷ tham số làm toán cao cấp như mô hình hàng trăm tỷ tham số — fine-tuning không thể bù đắp khoảng cách năng lực nền tảng; giải pháp là chọn mô hình nền mạnh hơn hoặc kết hợp công cụ bên ngoài. Khi dữ liệu huấn luyện quá ít (chỉ vài chục mẫu) hoặc chất lượng kém, fine-tuning dễ gây overfitting: mô hình học thuộc lòng vài chục mẫu đó mà không khái quát được. Khi yêu cầu thay đổi hàng tuần, chi phí huấn luyện lại liên tục sẽ vượt lợi ích. Và khi chưa thử prompt engineering kỹ lưỡng — nhiều trường hợp chỉ cần viết prompt tốt hơn và thêm vài ví dụ mẫu là đã đủ, không cần đến fine-tuning.
Một câu hỏi thường gặp là: fine-tuning có giúp mô hình “biết thêm kiến thức mới” không? Câu trả lời là có, nhưng hạn chế. Fine-tuning có thể dạy mô hình các sự kiện mới nếu dữ liệu huấn luyện chứa chúng, nhưng hiệu quả kém hơn nhiều so với việc đưa kiến thức đó vào ngữ cảnh qua RAG, và mô hình có thể học sai hoặc “ảo giác” khi bị ép ghi nhớ quá nhiều sự kiện mới. Các nghiên cứu trong ngành cho thấy fine-tuning hiệu quả nhất khi dạy cách làm — phong cách, định dạng, quy trình — chứ không phải dạy sự kiện. Hãy nhớ nguyên tắc này khi quyết định đầu tư vào fine-tuning.
Full fine-tuning: tinh chỉnh toàn bộ mô hình
Full fine-tuning (FFT) là phương pháp cổ điển và trực tiếp nhất: cập nhật toàn bộ trọng số của mô hình trên dữ liệu chuyên biệt. Mọi tham số đều tham gia huấn luyện, nên mô hình có khả năng thích ứng tối đa với nhiệm vụ mới. Đây là phương pháp cho chất lượng cao nhất trong nhiều trường hợp, đặc biệt khi dữ liệu huấn luyện lớn và nhiệm vụ khác xa với phân phối dữ liệu pre-training.
Tuy nhiên, full fine-tuning rất tốn tài nguyên. Một mô hình 7 tỷ tham số ở độ chính xác 16-bit (FP16/BF16) cần khoảng 14GB bộ nhớ chỉ để chứa trọng số; cộng thêm gradient, trạng thái của bộ tối ưu hóa (optimizer states — với Adam, cần thêm 2 bản sao số thực 32-bit cho mỗi tham số, tức khoảng 56GB nữa cho mô hình 7B), và các vùng đệm kích hoạt (activations) trong quá trình huấn luyện, tổng nhu cầu VRAM thực tế có thể lên tới khoảng 60–100GB cho một mô hình 7 tỷ tham số. Với mô hình 70 tỷ tham số, con số này tăng lên hàng trăm GB và cần nhiều GPU nối với nhau. Đó là lý do full fine-tuning thường chỉ khả thi với các tổ chức có hạ tầng GPU mạnh hoặc ngân sách thuê GPU cloud lớn.
Full fine-tuning cũng có rủi ro catastrophic forgetting cao nhất: khi cập nhật toàn bộ trọng số với tốc độ học không phù hợp hoặc dữ liệu quá hẹp, mô hình có thể “quên” nhiều kiến thức tổng quát đã học trong pre-training, trở nên giỏi một nhiệm vụ duy nhất nhưng kém hẳn ở các nhiệm vụ khác. Ngoài ra, mỗi phiên bản fine-tune là một bản sao đầy đủ của mô hình — một mô hình 7B chiếm khoảng 14GB, một mô hình 70B chiếm khoảng 140GB — nên việc lưu trữ và triển khai nhiều phiên bản chuyên biệt trở nên cồng kềnh. Với phần lớn doanh nghiệp, full fine-tuning chỉ nên dùng khi dữ liệu huấn luyện lớn (hàng trăm nghìn mẫu trở lên), nhiệm vụ khác biệt rõ rệt so với khả năng vốn có của mô hình, và đội ngũ có đủ hạ tầng cũng như kinh nghiệm vận hành.
LoRA là gì? Tinh chỉnh hiệu quả với Low-Rank Adaptation
LoRA (Low-Rank Adaptation), được giới thiệu trong bài báo của Microsoft Research năm 2021, là phương pháp fine-tuning hiệu quả tham số (Parameter-Efficient Fine-Tuning — PEFT) phổ biến nhất hiện nay. Ý tưởng cốt lõi của LoRA xuất phát từ một quan sát: khi fine-tune một mô hình lớn, sự thay đổi của ma trận trọng số có “hạng thấp” (low rank) — nghĩa là phần lớn thông tin của sự thay đổi có thể được biểu diễn bằng hai ma trận nhỏ thay vì một ma trận lớn. Thay vì cập nhật toàn bộ ma trận trọng số W có kích thước d × k, LoRA giữ nguyên W và cộng thêm một ma trận cập nhật ΔW được phân tích thành tích của hai ma trận nhỏ: B (d × r) và A (r × k), trong đó r là hạng (rank), thường chỉ bằng 8, 16 hoặc 32 — nhỏ hơn rất nhiều so với d và k (thường là hàng nghìn).
Con số minh họa: với một lớp tuyến tính có d = k = 4096, ma trận đầy đủ có khoảng 16,7 triệu tham số. Với LoRA hạng r = 16, hai ma trận A và B chỉ có tổng cộng 4096×16 + 16×4096 = 131.072 tham số — giảm khoảng 128 lần. Trên toàn bộ mô hình, LoRA thường chỉ huấn luyện khoảng 0,1–1% tổng số tham số. Điều này mang lại ba lợi ích lớn. Thứ nhất, tiết kiệm bộ nhớ huấn luyện: gradient và trạng thái optimizer chỉ cần cho các tham số LoRA, nên một mô hình 7B có thể fine-tune được trên một GPU 24GB, thay vì cần nhiều GPU cao cấp. Thứ hai, trọng số gốc không đổi: mô hình nền được giữ nguyên, các adapter LoRA được lưu riêng thành tập tin nhỏ (thường chỉ vài chục đến vài trăm MB), có thể gắn vào hoặc tháo ra linh hoạt. Thứ ba, giảm catastrophic forgetting: vì phần lớn trọng số không thay đổi, kiến thức tổng quát của mô hình được bảo toàn tốt hơn.
Trong thực tế triển khai, LoRA thường được gắn vào các lớp attention (query, key, value, output projection) và đôi khi cả các lớp MLP của mô hình Transformer. Hai siêu tham số quan trọng nhất là rank (r) — hạng càng cao thì adapter càng có khả năng học, nhưng càng tốn bộ nhớ — và alpha (α) — hệ số tỉ lệ áp dụng cho đầu ra của adapter, thường đặt bằng 2 lần rank. Các thực nghiệm trong ngành cho thấy với hầu hết tác vụ, rank 16 hoặc 32 là đủ; tăng rank lên 64 hoặc 128 chỉ cải thiện thêm một chút trong khi tốn gấp đôi bộ nhớ. Một điểm cần lưu ý: sau khi huấn luyện, adapter LoRA có thể được “hợp nhất” (merge) vào trọng số gốc để tạo thành một mô hình hoàn chỉnh, không còn chi phí suy luận thêm; hoặc giữ tách riêng để có thể thay đổi adapter theo nhiệm vụ — ví dụ cùng một mô hình nền nhưng gắn adapter khác nhau cho chăm sóc khách hàng, cho tóm tắt văn bản, cho phân loại tài liệu.
LoRA cũng có giới hạn. Vì chỉ một phần nhỏ tham số được cập nhật, khả năng thích ứng của LoRA thấp hơn full fine-tuning khi nhiệm vụ rất khác với dữ liệu pre-training hoặc khi cần dạy mô hình kiến thức hoàn toàn mới. Trong các so sánh thực nghiệm, LoRA đạt chất lượng gần bằng full fine-tuning trên các tác vụ như tóm tắt, phân loại và theo hướng dẫn (instruction following), nhưng khoảng cách có thể lớn hơn ở các tác vụ đòi hỏi thay đổi sâu về kiến thức. Với đa số ứng dụng doanh nghiệp — phong cách, định dạng, thuật ngữ ngành, nhiệm vụ hẹp — LoRA là lựa chọn mặc định hợp lý nhất, và chỉ cân nhắc full fine-tuning khi LoRA đã thử mà chưa đạt yêu cầu.
QLoRA là gì? Fine-tuning mô hình lớn trên một GPU duy nhất
QLoRA (Quantized LoRA), giới thiệu năm 2023, kết hợp LoRA với lượng tử hóa (quantization) để giảm mạnh nhu cầu bộ nhớ. Ý tưởng: lượng tử hóa trọng số của mô hình nền xuống 4-bit (NF4 — NormalFloat 4-bit, một định dạng lượng tử hóa được thiết kế riêng cho phân phối trọng số của mô hình ngôn ngữ, vốn gần với phân phối chuẩn), rồi áp dụng LoRA lên trên mô hình đã lượng tử hóa đó. Trong quá trình huấn luyện, trọng số 4-bit được giải lượng tử hóa (dequantize) tạm thời sang 16-bit để tính toán, còn các adapter LoRA được huấn luyện ở độ chính xác 16-bit như bình thường.
Hiệu quả tiết kiệm bộ nhớ của QLoRA rất ấn tượng. Một mô hình 7B ở 16-bit cần 14GB chỉ cho trọng số; ở 4-bit chỉ còn khoảng 3,5GB. Một mô hình 65B — vốn cần hơn 130GB chỉ để chứa trọng số — có thể được fine-tune bằng QLoRA trên một GPU 48GB duy nhất. Đây là bước đột phá thực sự về khả năng tiếp cận: các nhóm nhỏ, các công ty khởi nghiệp và thậm chí cá nhân có một GPU cao cấp cũng có thể fine-tune các mô hình lớn mà trước đây chỉ các phòng lab lớn mới làm được.
QLoRA có ba kỹ thuật bổ trợ đáng chú ý. Thứ nhất, lượng tử hóa kép (double quantization): các hằng số lượng tử hóa (quantization constants) vốn cần lưu ở 32-bit cũng được lượng tử hóa xuống 8-bit, tiết kiệm thêm khoảng 0,4 bit cho mỗi tham số. Thứ hai, bộ tối ưu hóa phân trang (paged optimizer): khi bộ nhớ GPU sắp đầy, trạng thái optimizer được chuyển tạm sang RAM CPU rồi chuyển lại khi cần, tránh lỗi tràn bộ nhớ giữa chừng. Thứ ba, định dạng NF4 được thiết kế để giữ độ chính xác tốt hơn so với lượng tử hóa 4-bit thông thường trên phân phối trọng số của mô hình ngôn ngữ.
Câu hỏi thực tế: QLoRA có làm giảm chất lượng so với LoRA 16-bit không? Các thực nghiệm trong bài báo gốc cho thấy với cùng một nhiệm vụ, QLoRA đạt chất lượng tương đương LoRA 16-bit trên hầu hết các bài đánh giá, với mức chênh lệch không đáng kể. Tuy nhiên, cần lưu ý hai điểm. Thứ nhất, QLoRA huấn luyện chậm hơn LoRA thường một chút vì có thêm bước giải lượng tử hóa trong mỗi lần tính toán. Thứ hai, mô hình sau khi fine-tune bằng QLoRA thường được triển khai ở dạng lượng tử hóa hoặc sau khi hợp nhất adapter — nếu hợp nhất adapter 16-bit vào trọng số 4-bit thì cần cẩn thận về mất mát độ chính xác. Với doanh nghiệp, QLoRA là lựa chọn lý tưởng khi ngân sách GPU hạn chế nhưng vẫn muốn dùng mô hình nền lớn; còn khi có sẵn GPU 24GB trở lên và mô hình nền 7–13B, LoRA 16-bit thông thường đơn giản và nhanh hơn.
PEFT nói chung: họ phương pháp tinh chỉnh hiệu quả tham số
LoRA và QLoRA là hai thành viên nổi tiếng nhất của họ PEFT (Parameter-Efficient Fine-Tuning) — các phương pháp chỉ cập nhật một phần nhỏ tham số của mô hình. Ngoài LoRA, còn một số phương pháp khác đáng biết. Prompt tuning và prefix tuning không cập nhật trọng số mô hình mà học một chuỗi vector liên tục gắn vào đầu vào (soft prompt) để “dẫn dắt” mô hình; chúng cực kỳ tiết kiệm (chỉ vài nghìn đến vài chục nghìn tham số) nhưng hiệu quả thường thấp hơn LoRA trên các nhiệm vụ phức tạp. Adapter (theo nghĩa hẹp) chèn các lớp nhỏ có thể huấn luyện được vào giữa các lớp của Transformer; phương pháp này ra đời trước LoRA nhưng hiện ít được dùng hơn vì LoRA đơn giản và hiệu quả hơn. IA3 (Infused Adapter by Inhibiting and Amplifying Inner Activations) chỉ học các vector tỉ lệ để khuếch đại hoặc ức chế các kích hoạt bên trong mô hình — rất ít tham số nhưng hiệu quả hạn chế hơn LoRA.
Thư viện PEFT của Hugging Face đã chuẩn hóa hầu hết các phương pháp này thành một giao diện thống nhất, cho phép chuyển đổi giữa LoRA, prompt tuning, prefix tuning hay IA3 chỉ bằng cách thay đổi cấu hình. Trong thực tế doanh nghiệp, lời khuyên là: dùng LoRA làm mặc định; dùng QLoRA khi bộ nhớ GPU là nút thắt; và chỉ thử các phương pháp PEFT khác khi có lý do đặc biệt — ví dụ cần adapter cực nhỏ để triển khai trên thiết bị biên, hoặc cần thử nghiệm nhanh nhiều biến thể phong cách khác nhau. Việc chọn đúng phương pháp PEFT ít quan trọng hơn việc chuẩn bị dữ liệu tốt — một adapter LoRA huấn luyện trên dữ liệu chất lượng cao sẽ vượt xa full fine-tuning trên dữ liệu cẩu thả.
RLHF và DPO: dạy mô hình “nên trả lời như thế nào”
Fine-tuning có giám sát (Supervised Fine-Tuning — SFT) dạy mô hình “trả lời đúng nội dung”. Nhưng trong nhiều ứng dụng, điều quan trọng không kém là mô hình trả lời “đúng cách”: lịch sự, an toàn, hữu ích, phù hợp với sở thích của con người. Đó là nhiệm vụ của học tăng cường từ phản hồi con người (RLHF — Reinforcement Learning from Human Feedback) và phương pháp thay thế trực tiếp hơn là DPO (Direct Preference Optimization).
RLHF là quy trình ba giai đoạn đã làm nên thành công của ChatGPT. Giai đoạn 1 là SFT như đã mô tả. Giai đoạn 2 là huấn luyện một mô hình thưởng (reward model): cho người đánh giá xem hai câu trả lời cho cùng một câu hỏi và chọn câu họ thích hơn; mô hình thưởng học cách chấm điểm câu trả lời theo sở thích con người. Giai đoạn 3 là tối ưu hóa bằng PPO (Proximal Policy Optimization): mô hình ngôn ngữ sinh ra câu trả lời, mô hình thưởng chấm điểm, và thuật toán học tăng cường cập nhật mô hình để tối đa hóa điểm thưởng — đồng thời có một ràng buộc KL để mô hình không lệch quá xa khỏi mô hình SFT ban đầu. RLHF rất mạnh nhưng phức tạp: cần ba mô hình chạy cùng lúc (mô hình chính sách, mô hình thưởng, mô hình tham chiếu), cần nhiều dữ liệu so sánh do con người gắn nhãn, và quá trình huấn luyện PPO nổi tiếng là khó ổn định — cần điều chỉnh nhiều siêu tham số và dễ gặp hiện tượng mô hình “lách” mô hình thưởng (reward hacking) bằng cách sinh ra câu trả lời dài dòng, nịnh bợ để được điểm cao mà không thực sự hữu ích hơn.
DPO, được giới thiệu trong bài báo năm 2023 của các nhà nghiên cứu tại Stanford, đơn giản hóa RLHF một cách triệt để. Thay vì huấn luyện mô hình thưởng riêng rồi tối ưu hóa bằng học tăng cường, DPO chứng minh rằng bài toán tối ưu hóa của RLHF có thể được viết lại thành một hàm mất mát trực tiếp trên các cặp câu trả lời được ưa thích và không được ưa thích. Cụ thể, với mỗi cặp (câu trả lời được chọn, câu trả lời bị loại), DPO cập nhật mô hình sao cho tăng xác suất sinh ra câu được chọn và giảm xác suất sinh ra câu bị loại, so với mô hình tham chiếu. Không cần mô hình thưởng, không cần PPO, không cần vòng lặp lấy mẫu phức tạp — chỉ cần dữ liệu cặp ưu tiên và một hàm mất mát dạng phân loại nhị phân.
Trong thực tế, DPO đã trở thành lựa chọn mặc định cho bước căn chỉnh sở thích (preference alignment) ở nhiều đội ngũ, vì nó đơn giản, ổn định và cho kết quả tương đương RLHF trên nhiều bài đánh giá. Tuy nhiên, DPO cũng có điểm yếu cần biết: nó có thể làm giảm xác suất của cả hai câu trả lời trong cặp (cả câu được chọn lẫn câu bị loại) nếu dữ liệu không cân bằng, và nó phụ thuộc hoàn toàn vào chất lượng của các cặp ưu tiên — nếu người gắn nhãn có thiên kiến, mô hình sẽ học luôn thiên kiến đó. Một biến thể cải tiến là ORPO (Odds Ratio Preference Optimization), kết hợp SFT và căn chỉnh sở thích trong một giai đoạn duy nhất; và SimPO, đơn giản hóa DPO thêm bằng cách bỏ mô hình tham chiếu. Với doanh nghiệp, khuyến nghị thực tế là: bắt đầu bằng SFT chất lượng cao; nếu sau SFT mô hình vẫn trả lời dài dòng, thiếu lịch sự hoặc chưa đúng “gu” mong muốn, hãy thu thập vài nghìn cặp ưu tiên (câu trả lời tốt so với câu trả lời chưa tốt cho cùng một câu hỏi) và chạy DPO. Chỉ cân nhắc RLHF đầy đủ khi có đội ngũ nghiên cứu chuyên sâu và dữ liệu phản hồi quy mô lớn.
Bảng so sánh các phương pháp fine-tuning
| Phương pháp | Tham số cập nhật | VRAM cần (mô hình 7B) | Dữ liệu cần | Chi phí | Chất lượng | Rủi ro quên kiến thức cũ |
|---|---|---|---|---|---|---|
| Full fine-tuning | 100% tham số | Khoảng 60–100GB | Lớn (hàng trăm nghìn mẫu) | Rất cao | Cao nhất | Cao |
| LoRA (r=16–32) | 0,1–1% tham số | Khoảng 16–24GB | Trung bình (vài nghìn mẫu) | Thấp | Gần bằng FFT | Thấp |
| QLoRA (4-bit) | 0,1–1% tham số | Khoảng 8–16GB | Trung bình (vài nghìn mẫu) | Rất thấp | Tương đương LoRA | Thấp |
| Prompt tuning | Dưới 0,01% | Khoảng 12–16GB | Trung bình | Rất thấp | Thấp hơn LoRA | Rất thấp |
| RLHF (PPO) | 100% + reward model | Rất cao (nhiều GPU) | Cần cặp ưu tiên quy mô lớn | Rất cao | Rất cao về sở thích | Trung bình |
| DPO | Thường kết hợp LoRA | Tương tự LoRA/SFT | Vài nghìn cặp ưu tiên | Thấp–trung bình | Tương đương RLHF | Thấp–trung bình |
Lưu ý: các con số VRAM trong bảng là ước tính thực tế cho quá trình huấn luyện với độ dài ngữ cảnh vừa phải (khoảng 2.000 token) và kích thước batch nhỏ; VRAM thực tế tăng theo độ dài ngữ cảnh, kích thước batch và việc có bật gradient checkpointing hay không. Gradient checkpointing — kỹ thuật tính lại các kích hoạt thay vì lưu trữ chúng — có thể giảm đáng kể VRAM cần thiết với chi phí huấn luyện chậm hơn khoảng 20–30%, và là một công cụ quan trọng khi GPU bị giới hạn.
Quy trình fine-tuning thực tế cho doanh nghiệp
Một dự án fine-tuning thành công không bắt đầu từ GPU mà bắt đầu từ việc xác định rõ bài toán. Dưới đây là quy trình sáu bước đã được kiểm chứng trong thực tế.
Bước 1: Xác định mục tiêu và tiêu chí thành công đo được
Trước khi viết một dòng dữ liệu nào, hãy trả lời: mô hình sau fine-tune phải làm tốt hơn mô hình hiện tại ở điểm nào, đo bằng gì? Ví dụ: “tỉ lệ câu trả lời đúng định dạng JSON tăng từ 82% lên trên 98%”, “điểm hài lòng của khách hàng với chatbot tăng từ 3,8 lên 4,5 trên thang 5”, hay “thời gian xử lý mỗi yêu cầu tóm tắt giảm từ 12 giây xuống 4 giây nhờ dùng mô hình nhỏ hơn”. Tiêu chí phải đo được, vì nếu không đo được thì không thể biết fine-tuning có hiệu quả hay chỉ tốn tiền. Đồng thời, hãy chuẩn bị một tập đánh giá (evaluation set) độc lập — khoảng 100–500 mẫu đại diện cho nhiệm vụ thực tế — và không bao giờ dùng tập này để huấn luyện. Tập đánh giá là thước đo duy nhất đáng tin để quyết định có triển khai mô hình đã fine-tune hay không.
Bước 2: Chuẩn bị dữ liệu — chất lượng hơn số lượng
Dữ liệu là yếu tố quyết định chất lượng fine-tuning, quan trọng hơn cả phương pháp và siêu tham số. Một nguyên tắc đã được nhiều nghiên cứu khẳng định: vài nghìn mẫu chất lượng cao thường cho kết quả tốt hơn hàng chục nghìn mẫu chất lượng thấp. Dữ liệu SFT thường ở định dạng instruction: mỗi mẫu gồm một hướng dẫn (instruction), đầu vào tùy chọn (input) và đầu ra mong muốn (output). Ví dụ cho chatbot chăm sóc khách hàng: instruction là “Trả lời khách hàng về chính sách đổi trả theo giọng điệu thân thiện, ngắn gọn”; input là câu hỏi của khách; output là câu trả lời mẫu đúng chuẩn.
Quy trình chuẩn bị dữ liệu gồm bốn công việc. Thứ nhất, thu thập: từ lịch sử hội thoại thật (đã ẩn danh hóa và được khách hàng đồng ý sử dụng), từ tài liệu nội bộ, từ các mẫu do chuyên gia trong ngành viết, hoặc từ việc dùng mô hình lớn hơn để sinh dữ liệu mẫu rồi cho con người kiểm duyệt. Thứ hai, làm sạch: loại bỏ mẫu trùng lặp, mẫu có lỗi chính tả hoặc thông tin sai, mẫu quá dài hoặc quá ngắn, mẫu chứa thông tin cá nhân nhạy cảm. Thứ ba, cân bằng: đảm bảo dữ liệu bao phủ đều các tình huống thực tế — nếu 90% mẫu là câu hỏi về giá và chỉ 10% là khiếu nại, mô hình sẽ xử lý khiếu nại rất kém. Thứ tư, kiểm tra chất lượng bằng con người: ít nhất một chuyên gia trong ngành đọc qua một mẫu ngẫu nhiên vài trăm mẫu và chấm điểm; nếu tỉ lệ mẫu lỗi vượt quá vài phần trăm, cần làm lại bước làm sạch.
Một lưu ý quan trọng về dữ liệu tiếng Việt: dữ liệu huấn luyện phải là tiếng Việt tự nhiên, đúng chính tả và đúng ngữ pháp, không phải văn bản dịch máy thô. Mô hình học phong cách từ dữ liệu, nên dữ liệu có lỗi chính tả sẽ dạy mô hình viết sai chính tả. Với các ngành có thuật ngữ riêng — y khoa, pháp lý, tài chính — hãy nhờ chuyên gia trong ngành rà soát dữ liệu, vì lỗi thuật ngữ trong dữ liệu huấn luyện sẽ được mô hình khuếch đại lên trong mọi câu trả lời sau này.
Bước 3: Chọn mô hình nền mở trọng số
Doanh nghiệp thường fine-tune các mô hình nền mở trọng số (open-weight) như Llama, Qwen, Mistral, Gemma hay các mô hình tiếng Việt được cộng đồng phát triển. Tiêu chí chọn mô hình nền gồm: khả năng tiếng Việt (hãy thử trực tiếp vài câu hỏi tiếng Việt phức tạp thay vì tin vào bảng xếp hạng), kích thước phù hợp với ngân sách suy luận (mô hình 7–8B thường là điểm cân bằng tốt giữa chất lượng và chi phí; mô hình 70B mạnh hơn nhưng tốn gấp nhiều lần chi phí vận hành), giấy phép sử dụng (một số mô hình có giấy phép hạn chế sử dụng thương mại — hãy đọc kỹ trước khi triển khai sản phẩm trả phí), độ dài ngữ cảnh tối đa (mô hình hỗ trợ 32K hay 128K token sẽ quan trọng nếu nhiệm vụ cần đọc tài liệu dài), và hệ sinh thái công cụ (mô hình phổ biến có nhiều hướng dẫn, công cụ fine-tune và cộng đồng hỗ trợ hơn).
Cũng cần cân nhắc các dịch vụ fine-tuning của nhà cung cấp mô hình đóng (như OpenAI): ưu điểm là không cần tự vận hành GPU, quy trình đơn giản; nhược điểm là dữ liệu phải gửi ra ngoài, chi phí suy luận cao hơn, và doanh nghiệp không sở hữu trọng số mô hình. Với dữ liệu nhạy cảm hoặc yêu cầu kiểm soát hoàn toàn, tự fine-tune mô hình mở trên hạ tầng của mình (hoặc GPU cloud thuê riêng) là lựa chọn an toàn hơn.
Bước 4: Huấn luyện — siêu tham số và các điểm cần theo dõi
Với LoRA/QLoRA, các siêu tham số khởi đầu an toàn cho phần lớn tác vụ là: learning rate khoảng 1e-4 đến 2e-4 (cao hơn nhiều so với full fine-tuning, thường chỉ dùng 1e-5 đến 2e-5, vì chỉ một phần nhỏ tham số được cập nhật), số epoch 2–3, kích thước batch hiệu dụng 8–32 (có thể dùng gradient accumulation để đạt batch lớn trên GPU nhỏ), rank LoRA 16 hoặc 32, alpha gấp đôi rank, và bật gradient checkpointing nếu VRAM hạn chế. Trong quá trình huấn luyện, theo dõi hai đường cong: training loss (mất mát trên dữ liệu huấn luyện) và validation loss (mất mát trên tập kiểm định tách riêng). Training loss giảm đều là bình thường; validation loss giảm rồi tăng trở lại là dấu hiệu overfitting — cần dừng sớm (early stopping) hoặc giảm số epoch.
Một lỗi phổ biến là đặt learning rate quá cao: mô hình học nhanh nhưng “phá” kiến thức nền, sinh ra văn bản lặp lại hoặc vô nghĩa. Dấu hiệu nhận biết là loss giảm rất nhanh rồi tăng vọt, hoặc mô hình sau huấn luyện trả lời kém hẳn so với mô hình gốc ngay cả ở câu hỏi chung. Ngược lại, learning rate quá thấp khiến mô hình gần như không thay đổi sau nhiều epoch. Cách làm an toàn: chạy thử một lần huấn luyện ngắn (vài trăm bước) với learning rate dự kiến, kiểm tra mẫu đầu ra, rồi mới chạy huấn luyện đầy đủ. Các công cụ như TRL (Transformer Reinforcement Learning) của Hugging Face, Axolotl hay LLaMA-Factory đã đóng gói sẵn toàn bộ quy trình này và là điểm khởi đầu tốt cho đội ngũ chưa có nhiều kinh nghiệm.
Bước 5: Đánh giá — tránh overfitting và catastrophic forgetting
Đánh giá là bước quyết định mô hình có được triển khai hay không, và cần làm nghiêm túc hơn nhiều so với việc “đọc thử vài câu trả lời thấy hay”. Đánh giá gồm ba lớp. Lớp thứ nhất là đánh giá tự động trên tập kiểm định: đo độ chính xác nhiệm vụ (ví dụ tỉ lệ định dạng đúng, độ chính xác phân loại) và so sánh với mô hình gốc trên cùng tập đó. Lớp thứ hai là đánh giá bằng mô hình khác (LLM-as-a-judge): dùng một mô hình mạnh độc lập chấm điểm câu trả lời theo thang điểm định sẵn — cách này nhanh và rẻ hơn đánh giá bằng con người, nhưng cần thiết kế tiêu chí chấm cẩn thận và kiểm tra độ nhất quán của “giám khảo”. Lớp thứ ba là đánh giá bằng con người: chuyên gia trong ngành đọc và chấm một mẫu câu trả lời thật, vì chỉ con người mới phát hiện được các lỗi tinh tế về chuyên môn.
Ngoài việc đo nhiệm vụ chính, bắt buộc phải kiểm tra catastrophic forgetting: đánh giá mô hình đã fine-tune trên các nhiệm vụ chung (trả lời câu hỏi kiến thức, suy luận cơ bản, viết văn bản chung) và so sánh với mô hình gốc. Nếu mô hình sau fine-tune giỏi nhiệm vụ chuyên biệt nhưng trả lời sai cả những câu hỏi chung đơn giản, đó là dấu hiệu đã huấn luyện quá mức hoặc learning rate quá cao. Cách khắc phục: giảm số epoch, giảm learning rate, thêm một tỉ lệ nhỏ dữ liệu chung (replay data) vào tập huấn luyện để mô hình “ôn lại” kiến thức cũ, hoặc chuyển từ full fine-tuning sang LoRA.
Bước 6: Triển khai và giám sát sau triển khai
Sau khi mô hình vượt qua đánh giá, bước triển khai gồm: hợp nhất adapter LoRA vào mô hình nền (hoặc giữ adapter riêng nếu cần thay đổi linh hoạt), lượng tử hóa mô hình để giảm chi phí suy luận (ví dụ từ 16-bit xuống 8-bit hoặc 4-bit — cần kiểm tra lại chất lượng sau lượng tử hóa vì một số nhiệm vụ nhạy cảm với độ chính xác thấp), và triển khai bằng một engine suy luận hiệu quả như vLLM, TGI (Text Generation Inference) hoặc TensorRT-LLM. Các engine này dùng kỹ thuật như continuous batching và paged attention để tăng thông lượng suy luận lên nhiều lần so với việc chạy mô hình thô bằng thư viện Transformers.
Triển khai xong chưa phải là hết: cần giám sát mô hình trong vận hành thực tế — ghi lại tỉ lệ lỗi, thời gian phản hồi, phản hồi tiêu cực của người dùng — và đặt lịch đánh giá lại định kỳ. Khi dữ liệu hoặc yêu cầu thay đổi đủ lớn, cần fine-tune lại trên dữ liệu mới. Một thực hành tốt là duy trì phiên bản hóa (versioning) cho cả dữ liệu huấn luyện, cấu hình huấn luyện và mô hình đầu ra, để khi mô hình mới có vấn đề, đội ngũ có thể quay lại phiên bản cũ ngay lập tức.
Lỗi thường gặp khi fine-tuning LLM và cách tránh
Lỗi 1: Dữ liệu huấn luyện kém chất lượng. Đây là nguyên nhân thất bại phổ biến nhất. Dữ liệu trùng lặp, chứa lỗi, không nhất quán về phong cách hoặc chứa thông tin sai sẽ dạy mô hình đúng những lỗi đó. Cách tránh: đầu tư thời gian làm sạch dữ liệu, kiểm tra bằng con người, và loại bỏ mạnh tay các mẫu nghi ngờ — thà ít mẫu tốt còn hơn nhiều mẫu kém.
Lỗi 2: Huấn luyện quá nhiều epoch. Nhiều đội ngũ nghĩ “huấn luyện càng lâu càng giỏi”, nhưng sau 2–3 epoch, mô hình bắt đầu học thuộc lòng dữ liệu thay vì khái quát. Dấu hiệu: training loss tiếp tục giảm nhưng validation loss tăng, và mô hình trả lời rập khuôn theo mẫu huấn luyện. Cách tránh: theo dõi validation loss và dừng sớm khi nó ngừng cải thiện.
Lỗi 3: Learning rate quá cao hoặc quá thấp. Quá cao phá hỏng mô hình nền; quá thấp khiến fine-tuning gần như vô tác dụng. Cách tránh: bắt đầu từ các giá trị đã được kiểm chứng (LoRA: 1e-4 đến 2e-4; full fine-tuning: 1e-5 đến 2e-5) và chạy thử ngắn trước khi huấn luyện đầy đủ.
Lỗi 4: Không có tập đánh giá độc lập. Nhiều dự án đánh giá mô hình trên chính dữ liệu huấn luyện, cho kết quả đẹp nhưng sai lệch hoàn toàn. Cách tránh: tách tập đánh giá ngay từ đầu và không bao giờ đưa nó vào huấn luyện.
Lỗi 5: Fine-tuning khi nên dùng RAG hoặc prompt engineering. Tốn hàng tuần và chi phí GPU để fine-tune kiến thức thay đổi hàng tháng, trong khi RAG giải quyết trong vài ngày. Cách tránh: xác định rõ bản chất yêu cầu — kiến thức động thì dùng RAG, hành vi ổn định thì fine-tune.
Lỗi 6: Bỏ qua bảo mật và quyền riêng tư dữ liệu. Đưa dữ liệu khách hàng chưa ẩn danh vào huấn luyện, hoặc dùng dịch vụ fine-tuning của bên thứ ba mà không kiểm tra điều khoản xử lý dữ liệu. Cách tránh: ẩn danh hóa dữ liệu trước khi huấn luyện, loại bỏ thông tin cá nhân, và đọc kỹ điều khoản của nhà cung cấp dịch vụ.
Lỗi 7: Không phiên bản hóa và không có kế hoạch quay lại. Mô hình mới triển khai gặp lỗi nhưng không còn bản cũ để khôi phục. Cách tránh: lưu trữ đầy đủ dữ liệu, cấu hình và mô hình của mỗi phiên bản, và kiểm tra quy trình khôi phục trước khi triển khai.
Checklist fine-tuning LLM cho doanh nghiệp
- Mục tiêu: đã xác định rõ fine-tuning cải thiện chỉ số nào, đo bằng gì, và tập đánh giá độc lập đã được chuẩn bị.
- Phương pháp: đã thử prompt engineering trước; đã chọn LoRA làm mặc định, QLoRA nếu GPU hạn chế, DPO nếu cần căn chỉnh sở thích, và chỉ dùng full fine-tuning khi có lý do rõ ràng.
- Dữ liệu: ít nhất vài nghìn mẫu chất lượng cao, đã làm sạch, cân bằng các tình huống, được chuyên gia kiểm duyệt; đã loại bỏ thông tin cá nhân nhạy cảm.
- Mô hình nền: đã thử trực tiếp khả năng tiếng Việt, kiểm tra giấy phép thương mại, và chọn kích thước phù hợp ngân sách suy luận.
- Huấn luyện: siêu tham số khởi đầu an toàn, bật gradient checkpointing nếu cần, theo dõi cả training loss và validation loss, có kế hoạch dừng sớm.
- Đánh giá: đo trên tập kiểm định độc lập, kiểm tra catastrophic forgetting trên nhiệm vụ chung, có đánh giá bằng con người trước khi triển khai.
- Triển khai: đã hợp nhất adapter, kiểm tra lại chất lượng sau lượng tử hóa, dùng engine suy luận hiệu quả (vLLM, TGI), và có phiên bản hóa đầy đủ.
- Giám sát: có theo dõi chất lượng sau triển khai, lịch đánh giá lại định kỳ, và quy trình fine-tune lại khi dữ liệu thay đổi.
Fine-tuning LLM không phải là mục tiêu tự thân mà là một công cụ trong bộ công cụ của doanh nghiệp — đứng cạnh prompt engineering và RAG. Giá trị lớn nhất của nó nằm ở những nơi hành vi cần nhất quán, phong cách cần ổn định và nhiệm vụ đủ hẹp để một mô hình nhỏ chuyên biệt vượt qua mô hình lớn dùng chung. Với LoRA và QLoRA, rào cản kỹ thuật và tài chính của fine-tuning đã thấp hơn bao giờ hết: một đội ngũ nhỏ với một GPU duy nhất cũng có thể tinh chỉnh một mô hình lớn cho nhu cầu của mình. Điều quyết định thành công không phải là GPU mạnh nhất hay phương pháp mới nhất, mà là dữ liệu chất lượng, mục tiêu đo được và quy trình đánh giá nghiêm túc.
Câu hỏi thường gặp (FAQs)
Fine-tuning LLM là gì?
Fine-tuning LLM là quá trình huấn luyện thêm một mô hình ngôn ngữ lớn đã được huấn luyện trước trên tập dữ liệu chuyên biệt, để mô hình học phong cách, thuật ngữ, định dạng đầu ra hoặc nhiệm vụ cụ thể của doanh nghiệp. Khác với prompt engineering chỉ thay đổi câu lệnh đầu vào, fine-tuning thay đổi trực tiếp trọng số của mô hình, nên hành vi mới được áp dụng nhất quán ở mọi lượt tương tác mà không cần hướng dẫn dài trong prompt. Mục tiêu chính là căn chỉnh mô hình có sẵn cho một nhiệm vụ cụ thể, chứ không phải dạy mô hình kiến thức hoàn toàn mới từ đầu.
LoRA là gì và khác full fine-tuning như thế nào?
LoRA (Low-Rank Adaptation) là phương pháp fine-tuning hiệu quả tham số: thay vì cập nhật toàn bộ trọng số mô hình, LoRA giữ nguyên trọng số gốc và chỉ huấn luyện hai ma trận nhỏ (adapter) có hạng thấp, thường chỉ chiếm 0,1–1% tổng số tham số. Nhờ đó, LoRA cần ít VRAM hơn nhiều — một mô hình 7B có thể fine-tune trên GPU 24GB — và giảm rủi ro quên kiến thức cũ, trong khi chất lượng đạt gần bằng full fine-tuning trên hầu hết tác vụ doanh nghiệp. Full fine-tuning cập nhật 100% tham số nên có khả năng thích ứng tối đa, nhưng tốn hàng chục đến hàng trăm GB VRAM và dễ gây catastrophic forgetting hơn.
QLoRA là gì và khi nào nên dùng?
QLoRA là phương pháp kết hợp LoRA với lượng tử hóa 4-bit (NF4): trọng số mô hình nền được nén xuống 4-bit, rồi áp dụng LoRA lên trên để huấn luyện. Nhờ đó, một mô hình 65B có thể được fine-tune trên một GPU 48GB duy nhất, điều mà trước đây cần nhiều GPU cao cấp. Nên dùng QLoRA khi ngân sách GPU hạn chế nhưng vẫn muốn dùng mô hình nền lớn, và khi đội ngũ chấp nhận huấn luyện chậm hơn một chút so với LoRA 16-bit. Chất lượng của QLoRA tương đương LoRA trên hầu hết bài đánh giá, nên đây là lựa chọn lý tưởng cho các nhóm nhỏ và công ty khởi nghiệp.
DPO khác RLHF như thế nào?
DPO (Direct Preference Optimization) và RLHF đều dạy mô hình trả lời theo sở thích của con người, nhưng DPO đơn giản hơn nhiều. RLHF cần ba giai đoạn: huấn luyện mô hình thưởng từ dữ liệu so sánh của con người, rồi tối ưu hóa mô hình bằng thuật toán học tăng cường PPO — phức tạp, tốn tài nguyên và khó ổn định. DPO chứng minh rằng bài toán này có thể viết lại thành một hàm mất mát trực tiếp trên các cặp câu trả lời được ưa thích và không được ưa thích, không cần mô hình thưởng và không cần PPO. Trong thực tế, DPO cho kết quả tương đương RLHF trên nhiều bài đánh giá, nên đã trở thành lựa chọn mặc định cho bước căn chỉnh sở thích ở nhiều đội ngũ.
Khi nào nên fine-tune thay vì dùng RAG?
Nên fine-tune khi yêu cầu ổn định theo thời gian: phong cách và giọng điệu thương hiệu, định dạng đầu ra cố định (ví dụ luôn trả về JSON đúng schema), thuật ngữ ngành ít thay đổi, hoặc nhiệm vụ hẹp lặp lại với khối lượng lớn. Nên dùng RAG khi kiến thức cần cập nhật liên tục — giá cả, chính sách, dữ liệu thời gian thực — vì RAG chỉ cần thêm tài liệu mới vào kho mà không phải huấn luyện lại. Nhiều hệ thống tốt nhất kết hợp cả hai: fine-tune để mô hình học phong cách và cách dùng công cụ, RAG để cung cấp kiến thức cập nhật. Hãy thử prompt engineering trước, vì nó rẻ nhất và cho kết quả ngay.
Fine-tuning LLM cần bao nhiêu dữ liệu?
Với LoRA hoặc QLoRA, vài nghìn mẫu chất lượng cao thường là đủ cho phần lớn tác vụ doanh nghiệp, và chất lượng dữ liệu quan trọng hơn số lượng. Vài nghìn mẫu tốt cho kết quả tốt hơn hàng chục nghìn mẫu cẩu thả. Với full fine-tuning, thường cần dữ liệu lớn hơn nhiều — hàng chục đến hàng trăm nghìn mẫu — mới phát huy hết lợi thế. Với DPO, cần vài nghìn cặp câu trả lời được ưa thích và không được ưa thích cho cùng một câu hỏi. Nguyên tắc chung: đầu tư vào làm sạch và kiểm duyệt dữ liệu bằng con người thay vì cố gắng thu thập thật nhiều mẫu.
Fine-tuning có làm mô hình quên kiến thức cũ không?
Có, hiện tượng này gọi là catastrophic forgetting: khi cập nhật trọng số trên dữ liệu hẹp, mô hình có thể mất một phần kiến thức tổng quát đã học trong pre-training. Rủi ro cao nhất ở full fine-tuning với learning rate cao và nhiều epoch, thấp hơn nhiều ở LoRA và QLoRA vì phần lớn trọng số được giữ nguyên. Cách giảm thiểu: dùng learning rate thấp, huấn luyện 2–3 epoch và dừng sớm khi validation loss ngừng cải thiện, thêm một tỉ lệ nhỏ dữ liệu chung vào tập huấn luyện, và luôn kiểm tra mô hình đã fine-tune trên các nhiệm vụ chung trước khi triển khai.
Doanh nghiệp nhỏ có tự fine-tune LLM được không?
Được, nhờ LoRA và QLoRA, rào cản đã thấp hơn rất nhiều so với trước đây. Một đội ngũ nhỏ với một GPU 24GB có thể fine-tune mô hình 7–8B bằng LoRA, hoặc mô hình lớn hơn nhiều bằng QLoRA, với chi phí thuê GPU cloud theo giờ. Các công cụ mã nguồn mở như TRL, Axolotl và LLaMA-Factory đã đóng gói sẵn quy trình huấn luyện, nên đội ngũ không cần phải viết code huấn luyện từ đầu. Điều quan trọng nhất không phải là hạ tầng mà là dữ liệu chất lượng, mục tiêu đo được và quy trình đánh giá nghiêm túc — những thứ này doanh nghiệp nhỏ hoàn toàn có thể làm tốt.
Liên hệ AIA qua hotline 0939 936 168 để được tư vấn giải pháp AI phù hợp với dự án của bạn.
