Câu hỏi mà tôi nhận được nhiều nhất từ các tech lead khi bắt đầu làm việc với AI không phải là “nên dùng model nào?” — mà là “khi nào thì fine-tune, và pipeline đó trông như thế nào từ đầu đến cuối?”
Câu trả lời ngắn: fine-tune muộn hơn bạn nghĩ là cần thiết, nhưng hãy chuẩn bị pipeline sẵn sàng trước khi cần dùng. Đây là toàn bộ bức tranh.
Khi Nào Fine-Tuning Là Quyết Định Đúng
Bắt đầu với prompt engineering. Rẻ hơn, lặp lại nhanh hơn, và có thể hoàn tác được. Chỉ chuyển sang fine-tuning khi một trong những điều sau đây là đúng:
- Yêu cầu format nhất quán: Bạn cần JSON có cấu trúc hoặc schema output cụ thể mọi lúc, và chỉ dùng prompt không thể đảm bảo được điều đó một cách đáng tin cậy.
- Từ vựng chuyên ngành: Model nền cứ hallucinate các thuật ngữ đặc thù của domain (mã y tế, tên sản phẩm nội bộ, điều khoản pháp lý) không xuất hiện trong dữ liệu training.
- Ngân sách latency: Bạn đang trả tiền cho context window lớn để nhét ví dụ vào. Fine-tuning bake các ví dụ đó vào weights, thu nhỏ context và cắt giảm chi phí inference.
- Tính nhất quán hành vi: LLM-as-judge eval cho thấy variance vượt ngưỡng chịu đựng, và nguyên nhân gốc rễ là model không “nói đúng ngôn ngữ” của bạn.
Một bài kiểm tra hữu ích: nếu 20 ví dụ viết tay trong system prompt đưa bạn đến 80% mục tiêu chất lượng, thì fine-tuning phần còn lại với 500 ví dụ được chọn lọc kỹ nhiều khả năng là đáng đầu tư. Nếu prompt 20 ví dụ chỉ đạt 20%, vấn đề nằm ở kiến trúc, không phải fine-tuning.
Bức Tranh Kỹ Thuật 2026
Ba cách tiếp cận thống trị fine-tuning production năm nay:
LoRA (Low-Rank Adaptation) — thay vì cập nhật toàn bộ weights model, bạn inject các ma trận phân tích hạng thấp nhỏ vào attention layers và chỉ train những phần đó. Mức sử dụng bộ nhớ giảm hơn 90% so với full fine-tuning. Trên hầu hết các task phân loại và generation, nó đạt 95–99% chất lượng full fine-tuning. Lựa chọn mặc định khi có đủ GPU.
QLoRA — LoRA trên model nền đã được quantize. Weights nền bị đóng băng ở độ chính xác 4-bit; LoRA adapters train ở 16-bit. Model 13B fine-tune trên một A100 duy nhất. Stack open-source (Unsloth, BitsAndBytes, Hugging Face PEFT) coi đây là mặc định chi phí thấp trong 2026.
DPO (Direct Preference Optimization) — dùng sau SFT (Supervised Fine-Tuning) để align output với sở thích con người. Đã thay thế RLHF trong hầu hết các team production vì không cần reward model riêng, không có PPO instability, và toán học là một contrastive loss gọn gàng trên các cặp preference. Pipeline thực tế: SFT trước, sau đó DPO trên dataset preference được chọn lọc.
Con đường production điển hình: QLoRA trên model open-weight 8B (Llama 3.1, Mistral Nemo, Qwen 2.5), SFT trên ví dụ domain, DPO để alignment, vLLM để serving. Tổng chi phí tính toán dưới $50 cho hầu hết task; một tuần engineering cho lần chạy đầu tiên.
Kích Thước Dataset — Các Con Số Thực Tế
Hướng dẫn 2026 đã hội tụ về các phạm vi sau:
| Loại task | Tối thiểu | Vùng tối ưu |
|---|---|---|
| Phân loại / trích xuất | 200 | 500 |
| Tạo nội dung | 500 | 1.000–2.000 |
| Task domain phức tạp | 1.000 | 3.000–5.000 |
Dưới 50–100 ví dụ, bạn đang làm few-shot prompting được ngụy trang thành fine-tuning — tiết kiệm compute đi.
Chất lượng đánh bại số lượng. 1.000 ví dụ được chọn lọc kỹ lưỡng liên tục vượt qua 100.000 ví dụ nhiễu. Điểm thất bại không phải “không đủ dữ liệu” — mà là catastrophic forgetting (quên thảm họa), khi training trên dataset hẹp làm suy giảm các khả năng chung của model. Cách khắc phục: thêm 10–15% ví dụ general-domain vào training set của bạn như một regularizer.
Dữ liệu tổng hợp từ model giáo viên mạnh hơn (Claude Sonnet, GPT-4o) hiện là thực hành tiêu chuẩn để bootstrap. Tạo ra 3–5× số lượng mục tiêu, chạy qua bộ lọc chất lượng (LLM-as-judge chấm điểm liên quan và độ chính xác theo rubric của bạn), giữ lại một phần ba tốt nhất.
Tích Hợp Fine-Tuning vào CI/CD
Đây là nơi hầu hết các team thất bại: họ fine-tune thủ công, deploy thủ công, và phát hiện regression trong production metrics ba ngày sau.
Pattern hoạt động là coi fine-tuning pipeline của bạn như một software release:
# .github/workflows/finetune-eval.yml
name: Fine-tune Eval Gate
on:
push:
paths:
- 'training-data/**'
- 'training-config/**'
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run eval suite
run: |
python scripts/run_evals.py \
--model-checkpoint ${{ env.CANDIDATE_MODEL }} \
--dataset evals/golden-set-v3.jsonl \
--threshold-faithfulness 0.90 \
--threshold-relevancy 0.85 \
--fail-on-regression
- name: Gate deployment
if: steps.eval.outcome == 'failure'
run: |
echo "Eval gate FAILED — chặn deployment"
exit 1Các thành phần then chốt:
- Version hóa training data cùng với model config. Một git diff của
training-data/phải cho bạn biết chính xác điều gì đã thay đổi giữa các lần chạy. - Duy trì golden eval set — 100–200 ví dụ với câu trả lời đã biết tốt, không bao giờ đưa vào training. Coi nó như test database: chỉ thêm vào, không bao giờ sửa đổi.
- Xác định ngưỡng số học trước khi ship phiên bản đầu tiên. Faithfulness > 0.90, Answer Relevancy > 0.85, Context Precision > 0.80 là điểm khởi đầu hợp lý cho RAG. Task phân loại dùng F1 hoặc accuracy — chọn một cái trước khi training, không phải sau.
- Theo dõi regression, không chỉ điểm số. Một model cải thiện task mới nhưng giảm 3 điểm trên khả năng đã có trước đó là một regression. Eval gate của bạn cần bắt cả hai.
Các tool trong 2026 tích hợp tốt với pattern này: DeepEval (pytest plugin, open-source, CI-ready), Braintrust (chặn PR merge khi điểm giảm), RAGAS (metrics đặc thù cho RAG). Chọn một cái và làm chủ nó — kết quả tệ nhất là ba tool chạy metrics khác nhau mà không có nguồn sự thật duy nhất.
Vấn Đề Catastrophic Forgetting
Catastrophic forgetting bị đánh giá thấp trong các cuộc thảo luận của team. Tôi đã thấy một chatbot hỗ trợ được fine-tune trả lời câu hỏi domain cực kỳ tốt nhưng hoàn toàn mất khả năng xử lý phép toán đơn giản trong tool-call response. Không ai chú ý đến khi có khiếu nại từ khách hàng.
Các biện pháp giảm thiểu thực tế:
- Trộn dữ liệu chung vào — 10–15% ví dụ general-domain từ domain model nền.
- LoRA thay vì full fine-tuning — đóng băng hầu hết weights vốn đã giới hạn forgetting.
- Eval breadth — golden set của bạn nên bao gồm ví dụ về các khả năng bạn muốn bảo tồn, không chỉ task mục tiêu.
- Checkpoint comparison — trước khi promote một fine-tune, so sánh nó với model nền trên benchmark khả năng rộng (MMLU, GSM8K, regression suite của bạn).
Timeline Thực Tế
Tuần 1: Thu thập và làm sạch dữ liệu. Tối thiểu 500 ví dụ được chọn lọc. Thiết lập eval golden set song song — đừng đợi đến khi model đã được train.
Tuần 2: Lần chạy training đầu tiên (QLoRA, chỉ SFT). Chạy evals. Kỳ vọng 70–80% chất lượng mục tiêu. Xác định failure modes.
Tuần 3: DPO trên preference pairs, data augmentation có mục tiêu cho failure modes. Lần chạy eval thứ hai.
Tuần 4: Tích hợp vào CI, đặt ngưỡng, deploy lên staging. Chạy shadow traffic so với production baseline.
Tuần 5+: Lặp lại trên chất lượng dữ liệu. Model không cải thiện nhiều sau điểm này nếu không có thêm dữ liệu hoặc kiến trúc khác.
Những Gì Không Nên Fine-Tune
Một vài thứ tôi thấy các team fine-tune trong khi không nên:
- Khả năng reasoning — fine-tuning trên ví dụ reasoning thường overfit vào format, không phải reasoning. Dùng model có base reasoning mạnh và prompt tốt hơn.
- Tool-calling schemas — các model nền có khả năng tool-calling mạnh. Một vài ví dụ trong system prompt hầu như luôn đủ.
- Safety behaviors — loại bỏ từ chối hoặc hạn chế qua fine-tuning là một thảm họa governance đang chờ xảy ra. Dùng safety layer của riêng bạn ở trên cùng.
Mental Model Đúng
Hãy coi fine-tuning như một schema migration: bạn thực hiện thay đổi có mục tiêu, chạy tests, và nếu tests pass thì bạn promote. Bạn không tự kiểm tra từng hàng một cách thủ công.
Các team tôi thấy thành công với fine-tuning trong production có ba điểm chung: họ xây dựng eval pipeline trước khi cần đến, họ coi training data như một artifact kỹ thuật hạng nhất, và họ định nghĩa “đủ tốt” bằng con số trước lần chạy training đầu tiên. Mọi thứ còn lại là chi tiết implementation.
Nguồn tham khảo: