Giải thích về max_length: File cấu hình tier mặc định đặt max_length=1024. Tuy nhiên, kết quả đo đạc thực tế từ token_stats.json cho thấy độ dài token có mean = 93.1, p50 = 93, p95 = 98, p99 = 100 và max = 101. Do đó, việc đặt max_length=256 là hoàn toàn an toàn (bao phủ 100% các mẫu trong tập dữ liệu), giúp loại bỏ padding thừa, giảm đáng kể bộ nhớ VRAM kích hoạt (activation memory) và tối ưu hóa tốc độ huấn luyện cũng như đánh giá.
Template có giữ khối <think> không?có — (results/template_check.json: open_tag_present = true, body_present = true, verdict: "reasoning preserved — safe to train on traces")
Nếu không: bạn đã xử lý thế nào?
Chat template của Qwen3.5 bảo toàn khối <think>...</think>, không tự ý cắt bỏ thẻ suy luận. Tuy nhiên, vì bài toán phân loại ticket CSKH yêu cầu xuất trực tiếp định dạng JSON ngắn gọn không kèm chuỗi suy luận dài, quá trình sinh (generation) sử dụng enable_thinking=False và MASK_MODE=assistant-only để giám sát chính xác phần phản hồi JSON sau thẻ </think>.
(b) có thật sự mạnh hơn (a) không?có — Baseline (b) vượt trội hoàn toàn so với (a) trên mọi phương diện: độ chính xác target tăng từ 0.000 lên 0.765, tuân thủ định dạng format đạt tuyệt đối 1.000 (so với 0.000 của a), và độ trễ giảm hơn 3.1 lần (từ 3149.3 ms xuống 996.9 ms/mẫu).
Bạn có sửa OPTIMIZED_PROMPT không? Nếu có: làm mạnh lên hay yếu đi, và vì sao?
Tôi không sửaOPTIMIZED_PROMPT (mã băm SHA giữ nguyên 719e74d3b6232053). Baseline (a) thất bại hoàn toàn vì prompt ngây thơ không cung cấp cấu trúc schema và danh sách nhãn enum, khiến mô hình sinh văn xuôi tự do dài dòng đến kịch trần token. Ngược lại, prompt (b) đã được tối ưu hóa chuẩn xác với định nghĩa 4 trường JSON và ràng buộc kiểu dữ liệu, giúp base model đạt mốc chuẩn rất cao (76.5%) trước khi bước vào fine-tuning.
4. Giải phẫu cấu hình sai (NB4)
Run
vị trí
r
trainable
LR
train loss (NB4)
target (NB5 §4)
s
VRAM GB
correct
text-linear
16
32,464,896
0.0001
0.6263
0.965
968.5
12.01
attn_only
q,v
283 (matched)
32,456,704
0.0001
0.5375
0.970
793.5
12.02
wrong_lr
text-linear
16
32,464,896
0.00001
1.5704
0.000
922.4
12.01
qlora
text-linear
16
32,464,896
0.0001
0.7058
0.940
992.3
7.09
Xếp hạng bằng cột target, không bằng cột train loss — chấm bằng chỉ số thay thế
chính là Lỗi #3. Nếu hai cột cho hai thứ tự khác nhau, nói thẳng điều đó ở 4.1: đó là
kết quả đáng giá nhất bạn đo được trong lab này.
Trả lời ba câu (mỗi câu ≥3 câu văn):
4.1 — attn_only có cùng số tham số huấn luyện với correct. Trên tập target nó
thắng, thua, hay hoà? Thứ tự đó có giống thứ tự theo train loss không? Điều đó nói gì về
rank so với vị trí gắn adapter?
Run attn_only được nâng rank lên r=283 để khớp chính xác ngân sách tham số (32,456,704 so với 32,464,896 của correct, độ lệch chỉ 0.025%). Trên tập target, attn_only đạt 0.970, cao hơn một chút so với correct (0.965), và trên train loss nó cũng đạt mức thấp hơn (0.5375 so với 0.6263), tức thứ tự theo target trùng khớp với thứ tự theo train loss. Điều này cho thấy trên một tập dữ liệu nhỏ và hẹp (225 mẫu trích xuất thông tin), việc tập trung dung lượng rank cực lớn vào cơ chế self-attention có thể giúp mô hình ghi nhớ và khớp mẫu context rất tốt. Tuy nhiên, việc phải đẩy rank lên mức cực đoan r=283 ở 2 module thay vì phân bổ đều r=16 trên toàn bộ 12 khối text-linear (bao gồm cả các lớp Gated DeltaNet linear-attention của Qwen3.5) là cách tiếp cận kém ổn định, tiêu tốn nhiều bộ nhớ tham số cục bộ và vi phạm nguyên lý tổng quát hóa "LoRA Without Regret".
4.2 — wrong_lr chỉ khác đúng một con số. Đường loss khác nhau ra sao? Nếu chỉ nhìn
loss mà không biết LR, bạn sẽ kết luận sai điều gì?
Run wrong_lr hạ learning rate từ 1e-4 (chuẩn LoRA) xuống 1e-5 (chuẩn Full Fine-Tuning), khiến đường loss tụt rất chậm và kết thúc ở mức 1.5704 (cao gấp hơn 2.5 lần so với correct), dẫn đến mô hình hoàn toàn mất khả năng sinh đúng định dạng với target = 0.000 và format = 0.000. Nếu chỉ quan sát loss dừng ở mức cao mà không biết nguyên nhân là do LR quá nhỏ, người làm sẽ dễ kết luận sai rằng bài toán cần thêm nhiều epoch huấn luyện, kiến trúc adapter r=16 không đủ dung lượng biểu diễn, hoặc tập dữ liệu bị nhiễu. Thực tế, vì các ma trận LoRA B được khởi tạo bằng 0 và số lượng tham số tinh chỉnh chỉ chiếm tỷ lệ nhỏ (~1-2%), LoRA bắt buộc phải có bước cập nhật gradient lớn hơn 5–10 lần so với Full FT thì mới có thể dịch chuyển biểu diễn tiềm ẩn hiệu quả trong 30 steps.
4.3 — qlora tiết kiệm bao nhiêu VRAM, trả giá bằng gì? Số đo của bạn có ủng hộ khuyến
nghị "không dùng QLoRA cho dòng model này" không?
Run qlora với lượng tử hóa 4-bit (NF4) đã giảm dung lượng VRAM đỉnh từ 12.01 GB xuống 7.09 GB, tức tiết kiệm tới 41% bộ nhớ VRAM (gần 5 GB). Sự đánh đổi ở đây là tốc độ huấn luyện giảm nhẹ (992.3s so với 968.5s do chi phí dequantize on-the-fly) và điểm target giảm nhẹ từ 0.965 xuống 0.940 (suy giảm 2.5% độ chính xác). Số đo thực nghiệm cho thấy khuyến nghị "không dùng QLoRA" chỉ đúng khi bạn có dư dả phần cứng (như GPU 16GB–24GB có thể chạy thẳng 16-bit LoRA mượt mà); còn trong bối cảnh môi trường phần cứng hạn chế (<8GB VRAM), QLoRA vẫn hoàn thành nhiệm vụ xuất sắc với điểm số 94.0% (vượt xa baseline b 76.5%) mà không hề bị sụp đổ chất lượng.
Diễn giải (≥100 từ). Nếu FAILED: vì sao, và điều đó nói gì về bài toán của bạn?
(Một FAILED được phân tích tốt ăn điểm cao hơn một PASSED không giải thích được.)
Cổng hồi quy 4 nhóm trả về kết quả FAILED dù điểm target đạt mức xuất sắc 0.965 (tăng trưởng target Δ = +0.200 so với baseline b 0.765). Nguyên nhân trượt cổng là do năng lực tổng quát bị suy giảm nặng nề với regression Δ = -0.324 (từ 0.7578 tụt xuống 0.4333, vượt xa ngưỡng cho phép tolerance 0.020).
Kết quả này phản ánh bản chất của hiện tượng quên thảm họa (catastrophic forgetting) khi fine-tune một mô hình ngôn ngữ 4B hoàn toàn trên 100% dữ liệu miền hẹp (250 mẫu CSKH) mà không có cơ chế giữ tri thức nền. Bản fine-tune đã chuyên biệt hóa toàn bộ trọng số adapter vào cấu trúc phân loại ticket, vô tình làm hỏng các kênh suy luận logic và kiến thức phổ thông. Điều này chứng minh rằng mô hình fine-tune hiện tại phù hợp để triển khai độc lập như một chuyên viên phân loại vé tự động (specialized triage worker) trong pipeline CSKH, nhưng chưa an toàn để làm trợ lý đàm thoại đa năng. Để khắc phục và đưa cổng hồi quy về PASSED, giải pháp bắt buộc là trộn 1%–5% dữ liệu tổng quát (general replay data) vào tập huấn luyện.
6. Định tính — bắt buộc có cả ca THUA
#
Ticket (rút gọn)
Nhãn đúng
(b) prompt
(c) fine-tune
Nhận xét
1
Cho mình hỏi, mình đặt chuột không dây mã đơn VN232232. Cho tôi trả lại. Gấp. Shop hỗ trợ tốt. (i=0)
doi_tra, cao, chuột không dây, tich_cuc
intent: hoi_thong_tin (Sai intent do bẫy "Cho mình hỏi")
doi_tra, cao, chuột không dây, tich_cuc
✅ FT thắng: FT nhận diện đúng hành động "trả lại" quan trọng hơn câu mở đầu xã giao.
2
Shop ơi, mình đặt ốp lưng điện thoại mã đơn VN812931. Hoàn tiền. Sớm nhé. Bực mình. (i=1)
hoan_tien, trung_binh, ốp lưng điện thoại, tieu_cuc
urgency: cao (Sai urgency do thấy từ "Bực mình")
hoan_tien, trung_binh, ốp lưng điện thoại, tieu_cuc
✅ FT thắng: FT học được ánh xạ quy ước cụm "Sớm nhé" = mức trung_binh.
3
Cho mình hỏi, mình đặt bình giữ nhiệt mã đơn VN804124. Chưa thấy tiền. Khi nào tiện. Cảm ơn shop nhiều. (i=3)
hoan_tien, thap, bình giữ nhiệt, tich_cuc
hoan_tien, thap, bình giữ nhiệt, tich_cuc (Đúng 4/4)
hoan_tien, trung_binh, bình giữ nhiệt, tich_cuc
❌ FT thua: FT dự đoán sai urgency: trung_binh thay vì thap.
4
Shop ơi, mình đặt nồi chiên không dầu mã đơn DH249548. Thiếu phụ kiện. Khi nào tiện. Cho tôi hỏi. (i=5)
san_pham_loi, thap, nồi chiên không dầu, trung_tinh
san_pham_loi, thap, nồi chiên không dầu, trung_tinh (Đúng 4/4)
san_pham_loi, trung_binh, nồi chiên không dầu, trung_tinh
❌ FT thua: FT nhầm cụm "Khi nào tiện" thành mức độ khẩn cấp trung_binh.
5
Shop ơi, mình đặt áo khoác gió mã đơn VN613097. Bị lỗi. Khi nào tiện. Cảm ơn shop nhiều. (i=12)
❌ FT thua: FT tiếp tục nhầm cụm "Khi nào tiện" thành mức độ trung_binh.
Có mẫu chung nào ở các ca FT thua không?
Có. Toàn bộ 7 ca mà mô hình fine-tune bị trừ điểm (đạt 0.75 thay vì 1.0) bao gồm cả 3 ca tệ nhất ghi nhận tại output Colab (i=3, i=5, i=12) đều có cùng một quy luật sai sót: dự đoán sai trường urgency từ thap thành trung_binh. Các cụm từ chỉ mức độ ưu tiên thấp như "Khi nào tiện", "Hỏi cho biết thôi", "Không vội" bị adapter gán nhầm vào nhãn đa số. Nguyên nhân là do hiện tượng mất cân bằng lớp (class imbalance) trong tập dữ liệu huấn luyện hạt giống (225 mẫu), nơi các nhãn trung_binh và cao chiếm đa số áp đảo, khiến mô hình bị inductive bias thiên vị về nhãn phổ biến khi gặp mẫu biên.
7. Kết luận & điều tôi học được
Kết luận (≥150 từ). Bạn có nên deploy bản fine-tune này không, và vì sao? Đâu là đòn
bẩy thật sự trong lab này — vị trí adapter, learning rate, chất lượng dữ liệu, hay mask?
Quyết định triển khai (deploy) bản fine-tune này phụ thuộc vào vai trò kiến trúc của nó trong hệ thống tổng thể. Nếu mục đích là triển khai một mô hình LLM độc lập vừa phục vụ đối thoại người dùng vừa phân loại dữ liệu, câu trả lời là KHÔNG NÊN DEPLOY, bởi mô hình đã trượt cổng hồi quy (regression Δ = -0.324), gây suy thoái nghiêm trọng khả năng trả lời tri thức phổ thông. Tuy nhiên, nếu mục đích là triển khai một micro-service chuyên trách (dedicated triage worker) trong luồng xử lý backend, bản fine-tune này RẤT ĐÁNG ĐỂ DEPLOY NGAY. Bản fine-tune đã nâng độ chính xác nhiệm vụ từ 76.5% lên 96.5%, format chuẩn 100%, và quan trọng nhất là loại bỏ hoàn toàn nhu cầu sử dụng prompt dài dòng kèm schema phức tạp, giúp giảm chi phí token đầu vào và tăng tính ổn định của hệ thống.
Đòn bẩy thực sự mang tính quyết định trong lab này chính là sự phối hợp giữa loss mask chính xác và prompt alignment giữa train - eval, cùng với thang đo learning rate phù hợp cho LoRA. Việc lệch prompt format từng khiến target rớt về 0.000 dù loss giảm đẹp; cấu hình sai LR (1e-5) khiến mô hình hoàn toàn bất động; trong khi việc gắn adapter toàn diện (text-linear) mang lại nền tảng tổng quát hóa vững chắc hơn việc tinh chỉnh cục bộ.
Ba điều tôi học được (cụ thể, không generic):
Thiết lập Baseline (b) đo trước khi train là kỷ luật bắt buộc: Prompt engineering tốt mang lại kết quả rất mạnh (target 76.5%, format 100%, latency <1s). So sánh bản fine-tune với một prompt ngây thơ vô nghĩa (baseline a) chỉ là tự huyễn hoặc về hiệu quả của fine-tuning.
Loss Mask và Prompt Alignment phải được chứng minh bằng giải mã ngược: Loss trên bảng điều khiển chỉ là chỉ số thay thế (proxy metric). Nếu không giải mã ngược offset token (chứng minh question bị mask và answer được tính loss) và kiểm tra sự tương thích tuyệt đối giữa prompt lúc huấn luyện với prompt lúc inference, ta rất dễ tạo ra một adapter "tự học trong vô vọng".
Hiểu rõ trade-off phần cứng và "LoRA Without Regret": Cấu hình text-linear với LR 1e-4 là vùng không hối tiếc chuẩn mực. QLoRA 4-bit giúp cắt giảm 41% VRAM trên GPU 16GB/8GB nhưng phải trả giá bằng 2.5% độ chính xác và cần kiểm soát chặt chẽ kiểu dữ liệu (tránh bẫy ép kiểu bf16 trên phần cứng Turing T4).
Nếu có thêm 2 giờ nữa, tôi sẽ thử:
Trộn 3%–5% dữ liệu hội thoại và suy luận tổng quát (từ tập GSM8k / Alpaca) vào tập huấn luyện để giải quyết triệt để vấn đề quên thảm họa (catastrophic forgetting), đưa cổng hồi quy về trạng thái PASSED.
Cân bằng lại phân phối nhãn cho trường urgency (tăng cường thêm các mẫu mang nhãn thap với các biến thể diễn đạt phong phú) để khắc phục 7 ca lỗi biên đã phân tích ở mục 6.
Thực hiện merge trọng số adapter vào base model bằng NB6 và xuất ra định dạng GGUF q4_k_m để đo đạc thông lượng suy luận thực tế trên môi trường CPU/Edge.
Finetuned from model [optional]: [More Information Needed]
Model Sources [optional]
Repository: [More Information Needed]
Paper [optional]: [More Information Needed]
Demo [optional]: [More Information Needed]
Uses
Direct Use
[More Information Needed]
Downstream Use [optional]
[More Information Needed]
Out-of-Scope Use
[More Information Needed]
Bias, Risks, and Limitations
[More Information Needed]
Recommendations
Users (both direct and downstream) should be made aware of the risks, biases and limitations of the model. More information needed for further recommendations.
