Mô hình được huấn luyện thế nào (và vì sao bạn sẽ không làm vậy)
Mọi mô hình chat tải về được đều đi qua cùng một quy trình ba giai đoạn. Gần như chắc chắn bạn sẽ không bao giờ chạy giai đoạn một — đó là lãnh địa của trung tâm dữ liệu — nhưng bạn có thể chạy những người anh em giá rẻ của giai đoạn hai và ba. Hiểu các giai đoạn giải thích hành vi base-vs-instruct, vì sao mô hình ảo giác, và một mô hình "merged" trên Hugging Face thực sự là gì.
Giai đoạn 1: tiền huấn luyện — phần đắt đỏ
Một mục tiêu duy nhất ở quy mô không tưởng: dự đoán token kế tiếp trên hàng nghìn tỉ token văn bản web, code và sách. Đây là nơi kiến thức và kỹ năng đi vào trọng số, và nơi phần lớn sức tính được tiêu thụ.
| Cái gì | Quy mô ước chừng (cấp độ lớn) |
|---|---|
| Dữ liệu | 10–30T token cho các họ hiện đại |
| Phần cứng | hàng nghìn GPU-tháng; các lần chạy hạng đỉnh chiếm cụm máy nhiều tháng |
| Chi phí | ~$1M–$10M+ cho 7B; $10M–$100M+ cho hạng 70B; các lần chạy hạng đỉnh đồn là còn vượt xa thế |
| Đầu ra | một mô hình base — tự hoàn thành hình-dáng-internet, không có hành vi trợ lý |
Đầu ra là một mô hình base: xuất sắc ở tiếp nối, vô dụng làm trợ lý. Bị hỏi một câu, nó trả lời — rồi tiếp tục bằng một câu hỏi khác, một danh sách, một dấu ngắt trang, vì đó là cách văn bản trên internet vận hành.
Giai đoạn 2: tinh chỉnh có giám sát (SFT)
Từ vài chục nghìn đến vài triệu cặp (chỉ dẫn → phản hồi) được tuyển chọn, vài GPU-ngày. Sai số làm tròn so với tiền huấn luyện, nhưng nó tái nối dây hành vi: trả lời chỉ dẫn, theo định dạng hữu ích, rồi dừng. Đây là giai đoạn biến mô hình base thành thứ bạn chat được.
Giai đoạn 3: tinh chỉnh theo sở thích
- RLHF: con người xếp hạng các cặp phản hồi; một mô hình phần thưởng học cách xếp hạng; chính sách được tối ưu theo phần thưởng (PPO). Công thức kinh điển, cỗ máy nặng ký.
- DPO: bỏ qua mô hình phần thưởng và tối ưu trực tiếp trên các cặp sở thích. Đơn giản hơn, ổn định, con cưng của mã nguồn mở.
- Hiệu ứng: phong cách, tính hữu ích, việc từ chối, các tuyên bố hiệu chỉnh tốt hơn. Cả nịnh bợ — mô hình học rằng người ta thưởng cho sự đồng thuận.
Dữ liệu SFT thực tế trông như thế nào — JSONL thường của các cặp chỉ dẫn/phản hồi, chẳng có gì cao siêu:
{"instruction": "Summarize the changelog in three bullets.", "response": "- Adds ..."}
{"instruction": "답변을 존댓말로 작성하세요.", "response": "네, 알겠습니다 ..."}
Hàng nghìn đến hàng triệu cặp như vậy, vài epoch, và mô hình base học được định dạng trợ lý.
Cùng trọng số, khác giai đoạn
prompt: "Write a haiku about GPUs."
base (sau giai đoạn 1):
"Write a haiku about GPUs.
Write a sonnet about CPUs.
1. Choose your topic carefully..." ← tiếp nối tài liệu
instruct (giai đoạn 1+2+3):
"A thousand cores wake,
each chasing one quiet token—
fans hold their breath." ← trả lời, định dạng, dừng
Hậu tố repo cho bạn biết giai đoạn: tên trơn = base; -instruct / -it / -chat = đã tinh chỉnh (xem tham số).
Thêm một mục từ vựng: điểm cắt kiến thức (knowledge cutoff) — ngày kho văn bản tiền huấn luyện được thu thập. Hỏi về bất cứ điều gì sau đó và bạn nhận được hoặc một câu "tôi không biết" trung thực, hoặc tệ hơn, hư cấu tự tin; cả hai đều là hành vi đúng cho trọng số đóng băng (LLM là gì).
Huấn luyện vs tinh chỉnh: cách nhau khoảng 1000 lần
| Tiền huấn luyện | Tinh chỉnh LoRA | |
|---|---|---|
| Dữ liệu | 10^12–10^13 token | 10^6–10^9 token |
| Tham số được cập nhật | tất cả | dưới 1–2% (các ma trận adapter nhỏ) |
| Phần cứng | cụm máy | một GPU |
| Thời gian thực | nhiều tuần–tháng | nhiều giờ–ngày |
| Chi phí | $M–$100M+ | $0–$100 thuê |
| Mục đích | kiến thức + kỹ năng | phong cách, định dạng, hành vi miền hẹp |
| Rủi ro | các lần chạy loss bất ổn, checkpoint hỏng | overfit trên tập dữ liệu tí hon |
| Chế độ hỏng | lỗi dữ liệu âm thầm phát hiện nhiều tháng sau | quên lãng thảm khốc kỹ năng tổng quát |
| Tái lập được? | hiếm (dữ liệu không công khai) | có (tập dữ liệu nằm ngay trong repo) |
| Nguồn dữ liệu | web công khai, code, sách, kho lưu trữ có bản quyền | prompt và câu trả lời lý tưởng của bạn |
| Ai làm được | các phòng thí nghiệm dồi dào ngân sách | chính bạn, cuối tuần này |
Tinh chỉnh vặn các núm; nó không thêm kiến thức. Dạy một mô hình 7B giọng điệu công ty bạn: LoRA, một buổi tối. Dạy nó 50k tài liệu nội bộ: đó là truy xuất, không phải huấn luyện (RAG, tinh chỉnh).
Những gì tinh chỉnh làm được và không làm được, để bạn nhắm đúng đích:
- Làm được: định dạng đầu ra, tông giọng, thuật ngữ, kiểu từ chối, cú pháp gọi công cụ, một tác vụ hẹp thực hiện đáng tin.
- Làm được: chưng cất một tác vụ hẹp từ mô hình lớn xuống mô hình nhỏ.
- Không làm được (đáng tin): thêm sự kiện mới, sửa suy luận yếu, kéo dài điểm cắt kiến thức, biến mô hình nhỏ thành to.
- Quy tắc: nếu vấn đề là "không biết", dùng truy xuất; nếu là "không cư xử đúng", tinh chỉnh.
Checkpoint, merge, và thứ bạn tải về
- Huấn luyện lưu checkpoint dọc đường; bản phát hành thường là trọng số cuối ở giai đoạn instruct — bạn nhận trợ lý thành phẩm, không phải quá trình dựng nên nó.
- Một "merge" lấy trung bình hoặc nội suy nhiều bản tinh chỉnh của cùng mô hình base (model soup). Không có huấn luyện nào diễn ra; đó là số học trọng số thường đáp xuống giữa các bậc cha mẹ. Phổ biến trên Hugging Face, rẻ, đôi khi xuất sắc.
- Nguồn gốc mờ mịt nghĩa là giấy phép mờ mịt: merge thừa hưởng điều khoản của mọi bậc cha mẹ (trọng số mở vs API đóng).
- Trọng số base đằng sau một mô hình chat đôi khi cũng được công bố — chỉ lấy chúng cho tác vụ hoàn thành hoặc làm nền tinh chỉnh.
- Vì sao bản phát hành mở dừng ở giai đoạn cuối: dữ liệu tiền huấn luyện và checkpoint trung gian là tài sản cạnh tranh đắt giá; trọng số thành phẩm chỉ là bản demo.
- Các mô hình instruct cộng đồng chia sẻ công thức và tập dữ liệu hậu huấn luyện, nên nhiều bản cảm giác hoán đổi được: cùng base, cùng kịch bản giai-đoạn-2/3.
- Ưu tiên bản phát hành có model card liệt kê dữ liệu và các giai đoạn; một checkpoint cuối được ghi chép đầy đủ sẽ già đi đẹp hơn một checkpoint được thổi phồng.
Liên quan: tinh chỉnh · RAG · trọng số mở vs API đóng · tham số