Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
Một trợ lý luôn trả lời đúng nội dung nhưng sai cấu trúc biểu mẫu. Trợ lý khác dùng giá bán đã hết hạn. Cả hai đều “chưa tốt”, nhưng chỉ lỗi thứ nhất gợi ý trực tiếp nhu cầu học một hành vi ổn định. Lỗi thứ hai trước hết cần nguồn dữ liệu cập nhật.
Trước khi học, bạn nên hiểu prompt, tập huấn luyện, tập kiểm thử và dự đoán token. Bài này xây dựng quy trình quyết định; các kích thước tập và kết quả minh họa đều giả định, không phải số liệu triển khai.
Đặt tên đúng cho lỗi cần sửa
Hãy thu các ví dụ thất bại rồi gắn nguyên nhân: thiếu dữ kiện, truy xuất sai, hiểu sai yêu cầu, định dạng sai hoặc năng lực nền chưa đủ. Một lỗi có thể có nhiều nguyên nhân. Đổi trọng số khi dữ liệu đầu vào sai có thể giúp mô hình che lỗi bằng câu trả lời trôi chảy hơn.
Fine-tuning tiếp tục huấn luyện một mô hình đã có trên tập dữ liệu dành cho nhiệm vụ hay miền. Tài liệu fine-tuning của Hugging Face giải thích cách bắt đầu từ trọng số đã huấn luyện thay vì khởi tạo ngẫu nhiên. Bài này dùng nguyên tắc đó, không cung cấp lệnh phụ thuộc phiên bản thư viện.
Một ứng viên hợp lý là hành vi có thể mô tả bằng nhiều ví dụ nhất quán: phân loại theo bộ nhãn riêng, chuyển dữ liệu sang một cấu trúc hoặc viết theo quy ước nghiệp vụ. Tần suất thay đổi yêu cầu cũng quan trọng: quy tắc đổi hằng ngày có thể phù hợp hơn với cấu hình hoặc ngữ cảnh.
Xây đường cơ sở trước khi học
Giữ một bộ thử đại diện rồi chạy mô hình gốc với prompt rõ, kèm vài ví dụ phù hợp. Nếu ứng dụng cần dữ kiện bên ngoài, thử thêm truy xuất. Những đường cơ sở ấy cho biết phần cải thiện nào thực sự cần cập nhật tham số.
Giả sử 100 tình huống có 40 lỗi do thiếu tài liệu, 35 lỗi định dạng và 25 lỗi hiểu sai. Đây là số giả định để phân tích. Sửa truy xuất có thể tác động trực tiếp nhóm 40 lỗi; fine-tuning trên biểu mẫu có thể nhắm nhóm 35 lỗi. Không nên cộng hai nhóm rồi hứa xử lý toàn bộ 75 lỗi.
Viết tiêu chí thành công trước: chẳng hạn đầu ra hợp lệ theo schema, giữ đúng dữ kiện và không suy giảm nhóm ngôn ngữ khác. Định dạng hợp lệ là điều kiện cần, chưa phải nội dung đúng.
Mẫu huấn luyện và loss phải cùng mục tiêu
Với supervised fine-tuning cho hội thoại, một mẫu gồm ngữ cảnh, yêu cầu và câu trả lời mong muốn. Mục tiêu thường dựa trên tổng âm log xác suất các token mục tiêu: L = −sum log p(y_t | x, y_<t). Cách che loss quyết định token nào thực sự được học trực tiếp.
Nếu mục tiêu là sinh phần trả lời, cần hiểu pipeline có tính loss trên phần prompt hay chỉ phần đáp án. Chat template, token kết thúc và cách cắt chuỗi đều có thể làm mẫu sai. Một đáp án dài bị cắt mất đoạn cuối không còn dạy hành vi kết thúc đúng.
Mô hình nhận ví dụ đã gán nhãn, tạo dự đoán, đo sai lệch rồi điều chỉnh tham số. Khả năng áp dụng cần được kiểm tra trên dữ liệu chưa dùng để học.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Ví dụ có nhãn
Các phản hồi về quán cà phê đi kèm nhãn đúng: đồ uống, phục vụ hoặc không gian.
02 / Tạo dự đoán
Mô hình dùng tham số hiện tại để dự đoán chủ đề của phản hồi.
03 / Đo sai lệch
So dự đoán với nhãn đúng. Hàm mất mát biểu diễn mức sai lệch cần giảm.
04 / Điều chỉnh
Thuật toán cập nhật tham số và lặp lại trên dữ liệu học. Sau đó đánh giá bằng các ví dụ được giữ riêng.
Minh họa giản lược cho học máy có giám sát. Một lần điều chỉnh không bảo đảm dự đoán tiếp theo sẽ đúng.
Sơ đồ thể hiện vòng cập nhật từ dữ liệu và sai số. Nó không chỉ rõ response masking hay chat template; đó là các cấu hình bạn phải kiểm riêng trước một lần chạy.
Đọc vài mẫu sau tokenization, không chỉ tệp JSON nguồn. Kiểm tra trường dữ liệu, dấu tiếng Việt, token đặc biệt và đoạn thực sự được tính loss. Một lỗi tiền xử lý lặp trên cả tập có thể lớn hơn lợi ích của việc tinh chỉnh learning rate.
Chia dữ liệu theo nguồn gây trùng lặp
Nếu nhiều câu hỏi là biến thể của cùng hồ sơ, hãy giữ chúng cùng một phía khi chia tập. Đưa bản diễn đạt lại vào test có thể tạo cảm giác khái quát hóa trong khi mô hình chỉ nhớ sự kiện quen thuộc. Chia theo khách hàng, tài liệu hoặc thời gian tùy loại ứng dụng.
Theo dõi cả chất lượng nhiệm vụ mới và năng lực cũ cần giữ. Loss validation giảm không đảm bảo hành vi sản phẩm cải thiện. Kiểm thử cần nhìn câu trả lời, nhóm lỗi và tác động của cách giải mã trong điều kiện dùng thật.
Chi phí fine-tuning còn gồm quản lý phiên bản dữ liệu, đánh giá hồi quy và quay lại checkpoint cũ. Khi chưa có quy trình ấy, chạy thêm một mô hình mới có thể tạo nợ vận hành lớn hơn lợi ích.
Bài tập lập quyết định một trang
Chọn một lỗi thật hoặc tự tạo 20 mẫu giả định. Viết ba cột: bằng chứng lỗi, biện pháp không đổi trọng số, lý do còn cần fine-tuning. Dành riêng một nhóm test chưa dùng để chọn prompt hoặc tham số.
Bạn hoàn thành khi nêu được một điều kiện khiến mình quyết định không huấn luyện, và một ngưỡng thất bại khiến phải quay lại mô hình gốc. Đọc LoRA nếu bài toán đã đủ dữ liệu và thực sự cần thích nghi tham số.