Fine-tune model — khi nào xứng đáng, khi nào không

TL;DR: Fine-tune train tiếp một model trên dữ liệu riêng — dịch chuyển trọng số, nên dạy được hành vi: format, giọng điệu, thuật ngữ domain, tuân thủ schema. Nó không phải cách nạp sự kiện mới đáng tin — kiến thức trong trọng số mờ, không cập nhật theo ngày; việc đó thuộc về RAG. Cái giá: data nhãn sạch, catastrophic forgetting, và vòng đời vận hành — model gốc đổi bản là phải train lại, đánh giá lại. Xứng đáng khi hành vi lặp lại ở quy mô lớn tới mức prompt dài không gánh nổi.

Đội tester một ngân hàng dán log giao dịch thô vào chat để model quy về JSON nội bộ chuẩn — vài trăm dòng/ngày trong đợt UAT, tăng dần. Prompt đã kèm ba ví dụ mẫu, model đúng phần lớn thời gian, nhưng cứ vài chục log lại lệch schema: sai kiểu amount, thiếu status, hoặc chèn giải thích mà downstream không parse được.

Câu hỏi tự nhiên là "vậy fine-tune model đi cho xong". Bài này trả lời nghiêm túc cho cả case trên lẫn những case fine-tune không giúp được gì, dù nghe rất giống.

1. Ba tình huống ngân hàng — fine-tune có giúp không?

Cả ba ở môi trường dev/UAT nội bộ, không phải dữ liệu khách hàng thật. Với mỗi tình huống, tự trả lời có/không và một câu vì sao trước khi đọc mục 2.

Tình huống A — chuẩn hoá log giao dịch test. Đúng tình huống mở bài: model trả JSON đúng schema nội bộ (transactionId, amount, currency, status) từ log thô, khối lượng hàng trăm dòng/ngày và tăng dần suốt đợt UAT.

Tình huống B — trả lời câu hỏi về API mới. Đội dev vừa ra mắt endpoint /api/v3/refund tuần trước, muốn chatbot trả lời đúng field, đúng status code của endpoint này.

Tình huống C — chuẩn hoá report cho một team nhỏ. Team 3 người muốn report tuần luôn đúng định dạng, gọi model chừng 20 lần/ngày.

Analogy — đào tạo nhân viên theo quy trình nội bộ

Đào tạo nhân viên mới theo quy trình nội bộ dạy được cách làm — mẫu báo cáo, giọng email, thứ tự duyệt. Nó không dạy tin tức sáng nay: bản tin đầu ngày mới làm việc đó, ai cũng phải đọc lại dù đã được đào tạo từ lâu. Học dồn một quy trình mới cũng có thể khiến nhân viên quên lẫn thói quen cũ tốt. Ba khái niệm bài này map đúng ba hiện tượng đó:

2. Cơ chế bên dưới — fine-tune dịch chuyển trọng số, không "học thêm sự thật"

Fine-tune train tiếp một base model đã có, nhưng trên ví dụ do bạn chọn — cặp input/output đúng định dạng bạn muốn — thay vì khối văn bản khổng lồ của pretraining. Mỗi bước train chỉnh trọng số để output khớp ví dụ hơn, cùng cơ chế pretraining, chỉ khác dữ liệu và quy mô.

Vì tác động nằm ở trọng số — cấu trúc phân tán hàng tỷ con số, không phải bảng tra cứu chèn/xoá được — fine-tune dạy tốt đúng cái nó vốn giỏi: hành vi lặp lại. Format đúng cấu trúc, giọng điệu nhất quán, thuật ngữ domain chuẩn, schema được tuân thủ mà không cần liệt kê ví dụ mỗi request. "Luôn trả đúng JSON schema dù log lệch" là một hành vi — và hành vi thì huấn luyện được vào trọng số, đây là lý do tình huống A hợp lý.

Nhưng cơ chế đó khiến fine-tune không phải cách đáng tin để nạp sự kiện mới: một chi tiết như "endpoint /api/v3/refund nhận field reasonCode" không nằm ở một vị trí trọng số cụ thể, mà hoà vào hàng tỷ tham số — mức model "nhớ" đúng nó là mờ. Ovadia và cộng sự (Fine-Tuning or Retrieval?, EMNLP 2024) kết luận định tính: fine-tune không đáng tin để nắm chắc dữ liệu sự kiện, RAG tốt hơn — nhưng paper đo unsupervised fine-tuning (train tiếp trên văn bản thô), khác supervised fine-tune trên cặp input-output có nhãn như log→JSON ở bài này. Lập luận cơ chế vẫn mở rộng hợp lý, nhưng cần nói rõ phạm vi khi trích dẫn.

Có một trục thời gian ẩn: trọng số là bản chụp cố định tại thời điểm train xong — sự kiện phát sinh sau đó (API mới, policy vừa đổi) không "vào" được cho tới lần fine-tune tiếp theo. Đây là staleness: khoảng cách giữa "thứ model biết" và "thứ đang đúng bây giờ". Tình huống B vì vậy không giúp: endpoint mới cần có mặt ngay và tiếp tục đúng khi đổi tiếp — việc của RAG, không phải train lại mỗi lần docs đổi.

Tình huống C chưa trả lời được ở đây — không phải câu hỏi "hành vi hay sự kiện" (rõ ràng là hành vi), mà là "hành vi đó có đáng chi phí không". Mục 4 quay lại nó.

3. Cái giá thật của fine-tune

Ba khoản chi phí dưới đây không nằm trên hoá đơn API — chúng là chi phí ẩn khiến fine-tune đắt hơn con số "train một lần" gợi ý.

3.1 Data gán nhãn chất lượng

Fine-tune học từ ví dụ input/output do bạn cung cấp — chất lượng ví dụ quyết định chất lượng hành vi học được, đúng nguyên tắc nhãn là expected đã gặp ở bài dữ liệu/nhãn.

Với tình huống A, "data nhãn" nghĩa là vài trăm cặp log-thô → JSON-chuẩn được review xác nhận đúng, không phải vài ví dụ viết nhanh trong prompt.

3.2 Catastrophic forgetting

Khi train tiếp trên một tập hẹp (chỉ log giao dịch, một định dạng), trọng số bị kéo mạnh về tối ưu cho tập đó — có thể kéo lệch khả năng tổng quát từ pretraining. Đây là catastrophic forgetting: model giỏi hẳn ở việc vừa train, nhưng có thể sa sút ở việc từng làm tốt mà không nằm trong tập fine-tune — ví dụ mất khả năng trò chuyện tự nhiên. Chỗ sa sút thường chỉ lộ ra khi người dùng gặp phải.

3.3 Vòng đời vận hành

Fine-tune không phải việc làm một lần rồi xong: base model sẽ được thay bằng bản mới, và mỗi lần đó bạn cần train lại rồi đánh giá lại từ đầu, vì hành vi học trên bản cũ không đảm bảo giữ nguyên trên bản khác. Đây là chi phí lặp lại mà ước lượng "train một lần, dùng mãi" bỏ sót.

4. Khung quyết định — khi nào hành vi lặp lại xứng đáng fine-tune

Quay lại tình huống C: team 3 người, ~20 lần gọi/ngày. Đây là hành vi lặp lại — nhưng quy mô nhỏ, vài ví dụ mẫu (few-shot) đã đủ ổn định và rẻ hơn nhiều so với gán nhãn + train + duy trì vòng đời fine-tune. Câu trả lời là chưa đáng — không vì nó không phải hành vi, mà vì quy mô chưa tới ngưỡng.

Tình huống A khác ở trục quy mô: hàng trăm log/ngày, tăng dần, và few-shot đã cho thấy giới hạn — sai lệch xảy ra đều đặn. Chi phí token cộng dồn mỗi request, còn độ ổn định vẫn thua một hành vi đã "khắc" vào trọng số — chi phí một lần của fine-tune giờ rẻ hơn chi phí lặp lại vô hạn của một prompt vẫn sai một phần nhỏ mỗi lần.

Khung rút gọn còn hai câu hỏi lọc:

1. Hành vi lặp lại hay sự kiện mới? Sự kiện mới → dừng, dùng RAG (mục 2). Hành vi → đi tiếp câu 2.
2. Hành vi đó có lặp ở quy mô đủ lớn để prompt dài không gánh nổi? Quy mô nhỏ, few-shot còn rẻ và ổn định → chưa đáng (C). Quy mô lớn, few-shot đã lộ giới hạn hoặc chi phí token vượt chi phí train + duy trì → fine-tune xứng đáng (A).

5. Pitfall tổng hợp

❌ Nhầm 1 — coi fine-tune là cách nạp "cơ sở dữ liệu nội bộ" vào model: ✅ Fine-tune dạy hành vi, không nạp sự kiện đáng tin — trả lời đúng theo tài liệu công ty là việc của RAG.

❌ Nhầm 2 — chỉ test đúng use case fine-tune, không kiểm việc khác model từng làm: ✅ Catastrophic forgetting lộ ở việc KHÔNG nằm trong tập fine-tune (3.2) — giữ một bộ eval tổng quát bên cạnh eval riêng.

❌ Nhầm 3 — dùng chung một đợt log vừa để train vừa để đánh giá: ✅ Đúng bẫy rò rỉ dữ liệu — tách eval từ một đợt log khác với train, nếu không điểm đánh giá không phản ánh khả năng tổng quát.

6. 📚 Đào sâu

7. Liên hệ các bài khác

• Mini-challenge — chọn kiến trúc cho ba bài toán thật — bảng trade-off prompt-only/RAG/fine-tune; bài này đào sâu riêng nhánh fine-tune.
• Dữ liệu, nhãn và ba tập không được trộn — nguyên tắc nhãn sạch và tách tập đúng, áp vào mục 3.1.
• Bài tiếp theo — Agent: vòng lặp và công cụ — quyết xong model nên "biết" gì, tiếp theo là nó hành động ra sao.

8. Tóm tắt

• Fine-tune train tiếp trên dữ liệu riêng, dịch chuyển trọng số — nên dạy hành vi (format, giọng điệu, thuật ngữ domain, tuân thủ schema).
• Fine-tune không phải cách nạp sự kiện mới đáng tin: kiến thức trong trọng số mờ, là bản chụp cố định (staleness) — nạp sự kiện mới thuộc về RAG.
• Ba khoản chi phí ẩn: data nhãn sạch (và bẫy rò rỉ khi tách eval), catastrophic forgetting ngoài tập fine-tune, và vòng đời vận hành — train lại mỗi khi base model đổi bản.
• Khung quyết định hai bước: hành vi hay sự kiện; nếu là hành vi, quy mô có đủ lớn để prompt dài không gánh nổi hay chưa.
• Có kỹ thuật rẻ hơn full fine-tune (LoRA), nhưng đó là câu hỏi làm-thế-nào, không đổi câu trả lời khi-nào.

9. Tự kiểm tra

Bài tiếp theo: Agent — vòng lặp và công cụ